Does the order of the devices in /src/maniboard/../../Config.lb actually effect the order in which the devices are initialized in coreboot?
If not, what is the preferred method if one device or register needs to be set before others?
-Bari
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of bari Sent: Sunday, June 08, 2008 6:16 PM To: coreboot@coreboot.org Subject: [coreboot] V2 Orders of Initialization of Devices
Does the order of the devices in /src/maniboard/../../Config.lb actually effect the order in which the devices are initialized in coreboot?
If not, what is the preferred method if one device or register needs to be set before others?
If you need to initialize a device early you can always do it in auto.c, but it depends which device it is..... For example, if it is a PCI device, you will need to initialize the PCI bridge first, and then you can initialize the PCI device.
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
Joseph Smith wrote:
Does the order of the devices in /src/maniboard/../../Config.lb actually effect the order in which the devices are initialized in coreboot?
If not, what is the preferred method if one device or register needs to be set before others?
If you need to initialize a device early you can always do it in auto.c, but it depends which device it is..... For example, if it is a PCI device, you will need to initialize the PCI bridge first, and then you can initialize the PCI device.
Yes, but if you don't use auto.c does the order in Config.lb have an effect on the order in which registers are written to or read from?
-Bari
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of bari Sent: Sunday, June 08, 2008 11:52 PM To: joe@settoplinux.org Cc: coreboot@coreboot.org Subject: Re: [coreboot] V2 Orders of Initialization of Devices
Joseph Smith wrote:
Does the order of the devices in /src/maniboard/../../Config.lb
actually
effect the order in which the devices are initialized in coreboot?
If not, what is the preferred method if one device or register needs to be set before others?
If you need to initialize a device early you can always do it in auto.c,
but
it depends which device it is..... For example, if it is a PCI device, you will need to initialize the PCI bridge first, and then you can initialize the PCI device.
Yes, but if you don't use auto.c does the order in Config.lb have an effect on the order in which registers are written to or read from?
Hmm, only one way to find out. Move some stuff around Config.lb, and compare the bootlog with past bootlogs. I'd be curious to find out the results.
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
Hello, Does anyone know the mathematical formula for converting memory clock cycles into microseconds (us)??
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
Hello, Does anyone know the mathematical formula for converting memory clock cycles into microseconds (us)??
1 MHz means 1 million clock cycles per second, so 1 clock cycle per microsecond.
166 MHz -> 166 clock cycles per microsecond.
Thanks, Myles
On Mon, 9 Jun 2008 09:53:02 -0600, "Myles Watson" mylesgw@gmail.com wrote:
Hello, Does anyone know the mathematical formula for converting memory clock cycles into microseconds (us)??
1 MHz means 1 million clock cycles per second, so 1 clock cycle per microsecond.
166 MHz -> 166 clock cycles per microsecond.
Thanks Myles:-) I didn't realize it was that easy. So, for example if a memory initialization datasheet says you should delay for 3 clocks than that means 3us, correct?
On Mon, Jun 09, 2008 at 01:06:08PM -0400, Joseph Smith wrote:
Does anyone know the mathematical formula for converting memory clock cycles into microseconds (us)??
1 MHz means 1 million clock cycles per second, so 1 clock cycle per microsecond.
166 MHz -> 166 clock cycles per microsecond.
Thanks Myles:-) I didn't realize it was that easy. So, for example if a memory initialization datasheet says you should delay for 3 clocks than that means 3us, correct?
Only if the memory clock is 1MHz, but if it's 166MHz then delay for 3/166 microseconds = 18 nanoseconds
The formula is: t=1/f
If f=1000000, each cycle is 1/1000000 seconds, or 1 microsecond. If f=166000000, each cycle is 1/166000000 seconds, or 1/166 us = 6 ns
//Peter
On Mon, 9 Jun 2008 19:14:32 +0200, Peter Stuge peter@stuge.se wrote:
On Mon, Jun 09, 2008 at 01:06:08PM -0400, Joseph Smith wrote:
Does anyone know the mathematical formula for converting memory clock cycles into microseconds (us)??
1 MHz means 1 million clock cycles per second, so 1 clock cycle per microsecond.
166 MHz -> 166 clock cycles per microsecond.
Thanks Myles:-) I didn't realize it was that easy. So, for example if a memory initialization datasheet says you should delay for 3 clocks than that means 3us, correct?
Only if the memory clock is 1MHz, but if it's 166MHz then delay for 3/166 microseconds = 18 nanoseconds
The formula is: t=1/f
If f=1000000, each cycle is 1/1000000 seconds, or 1 microsecond. If f=166000000, each cycle is 1/166000000 seconds, or 1/166 us = 6 ns
Ok, let me get this straight. So in my case the memory is PC133 which is 133 MHz. So each clock cycle is 1/133 us? And, to delay for 3 clocks would be 3/133 us = 22 ns?
On Mon, Jun 09, 2008 at 01:36:29PM -0400, Joseph Smith wrote:
Does anyone know the mathematical formula for converting memory clock cycles into microseconds (us)??
1 MHz means 1 million clock cycles per second, so 1 clock cycle per microsecond.
166 MHz -> 166 clock cycles per microsecond.
The formula is: t=1/f
If f=1000000, each cycle is 1/1000000 seconds, or 1 microsecond. If f=166000000, each cycle is 1/166000000 seconds, or 1/166 us = 6 ns
Ok, let me get this straight. So in my case the memory is PC133 which is 133 MHz. So each clock cycle is 1/133 us? And, to delay for 3 clocks would be 3/133 us = 22 ns?
Yes sir, that's correct!
//Peter
On Mon, 9 Jun 2008 19:47:24 +0200, Peter Stuge peter@stuge.se wrote:
On Mon, Jun 09, 2008 at 01:36:29PM -0400, Joseph Smith wrote:
Does anyone know the mathematical formula for converting memory clock cycles into microseconds (us)??
1 MHz means 1 million clock cycles per second, so 1 clock cycle per microsecond.
166 MHz -> 166 clock cycles per microsecond.
The formula is: t=1/f
If f=1000000, each cycle is 1/1000000 seconds, or 1 microsecond. If f=166000000, each cycle is 1/166000000 seconds, or 1/166 us = 6 ns
Ok, let me get this straight. So in my case the memory is PC133 which is 133 MHz. So each clock cycle is 1/133 us? And, to delay for 3 clocks would be 3/133 us = 22 ns?
Yes sir, that's correct!
Ok then, that brings me to my next question. In alot of our raminit.c's we use udelay() between the memory initialization steps. We could probably cut the memory initialization time in half buy using nanoseconds instead or microseconds.
How hard would it be to add a nanoseconds delay to delay.h?
On Mon, Jun 09, 2008 at 03:15:46PM -0400, Joseph Smith wrote:
How hard would it be to add a nanoseconds delay to delay.h?
It would probably have to be a busy wait with compensation for the current CPU frequency.
//Peter
On Mon, 9 Jun 2008 23:43:10 +0200, Peter Stuge peter@stuge.se wrote:
On Mon, Jun 09, 2008 at 03:15:46PM -0400, Joseph Smith wrote:
How hard would it be to add a nanoseconds delay to delay.h?
It would probably have to be a busy wait with compensation for the current CPU frequency.
I'm not sure what you mean, Peter?
On Mon, Jun 09, 2008 at 05:48:11PM -0400, Joseph Smith wrote:
On Mon, 9 Jun 2008 23:43:10 +0200, Peter Stuge peter@stuge.se wrote:
On Mon, Jun 09, 2008 at 03:15:46PM -0400, Joseph Smith wrote:
How hard would it be to add a nanoseconds delay to delay.h?
It would probably have to be a busy wait with compensation for the current CPU frequency.
I'm not sure what you mean, Peter?
Busy wait is a loop of some number of NOP instructions, as opposed to relying on some CPU peripheral such as a timer to signal elapsed time. The number of NOP instructions has to be calculated from the current CPU frequency.
//Peter
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Monday, June 09, 2008 6:03 PM To: coreboot@coreboot.org Subject: Re: [coreboot] Memory clock cycles -> microseconds (us)
On Mon, Jun 09, 2008 at 05:48:11PM -0400, Joseph Smith wrote:
On Mon, 9 Jun 2008 23:43:10 +0200, Peter Stuge peter@stuge.se wrote:
On Mon, Jun 09, 2008 at 03:15:46PM -0400, Joseph Smith wrote:
How hard would it be to add a nanoseconds delay to delay.h?
It would probably have to be a busy wait with compensation for the current CPU frequency.
I'm not sure what you mean, Peter?
Busy wait is a loop of some number of NOP instructions, as opposed to relying on some CPU peripheral such as a timer to signal elapsed time. The number of NOP instructions has to be calculated from the current CPU frequency.
That seems more complicated than it needs to be. Here is what I am thinking: JEDEC specifies what the wait/delay is supposed to be between memory initialization steps. They specify/measure these in memory clock cycles. Currently we just guess, and round up in microseconds (us) (I guess it is better to wait too long than not enough). But, even if we wait 1/2 a microsecond or more than needed on each step, That's 3 or 4 microseconds longer than needed. See where I am going with this?
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On Mon, Jun 09, 2008 at 09:37:45PM -0400, Joseph Smith wrote:
See where I am going with this?
Sorry, not at all.
Of course it would be nice to not spend more time than neccessary on waits during RAM init.
But nanosecond precision is more difficult than microsecond precision, and unless there are on the order of 1000 or 10000 delays where we wait microseconds instead of nanoseconds I don't think it is a worthwhile optimization.
//Peter
On Tue, 10 Jun 2008 05:37:46 +0200, Peter Stuge peter@stuge.se wrote:
On Mon, Jun 09, 2008 at 09:37:45PM -0400, Joseph Smith wrote:
See where I am going with this?
Sorry, not at all.
Of course it would be nice to not spend more time than neccessary on waits during RAM init.
But nanosecond precision is more difficult than microsecond precision, and unless there are on the order of 1000 or 10000 delays where we wait microseconds instead of nanoseconds I don't think it is a worthwhile optimization.
Peter's point is that it probably does not matter too much. Even if you rounded up 5 individual delays to 1 usec each, that is only 5us. You can reclaim a lot of it, but it may be more work than it is worth.
Ok, nevermind then. I just thought it would be something to speed up the boot process even more.
Busy wait is a loop of some number of NOP instructions, as opposed to relying on some CPU peripheral such as a timer to signal elapsed time. The number of NOP instructions has to be calculated from the current CPU frequency.
That seems more complicated than it needs to be. Here is what I am thinking: JEDEC specifies what the wait/delay is supposed to be between memory initialization steps. They specify/measure these in memory clock cycles. Currently we just guess, and round up in microseconds (us) (I guess it is better to wait too long than not enough). But, even if we wait 1/2 a microsecond or more than needed on each step, That's 3 or 4 microseconds longer than needed. See where I am going with this?
It really can't be less complicated, but a lot of the work is already done. Take a look at delay_tsc.c, which uses the tsc for delays (which is a little bit nicer than counting NOPs) It does the tsc calibration vs. the PIT (or even vs. port 80s) to get the CPU frequency. delay_tsc has udelay now, but could reasonably easily have ndelay too. Precision in the 10s of ns should be possible.
Peter's point is that it probably does not matter too much. Even if you rounded up 5 individual delays to 1 usec each, that is only 5us. You can reclaim a lot of it, but it may be more work than it is worth.
-
bari -
Joseph Smith -
Myles Watson -
Peter Stuge -
Tom Sylla