Hi, While trying to boot using linuxbios , I get a message " Copying LinuxBIOS to ram " and then the system pauses for 3-4 secs, before printing the next message - "Jumping to Linuxbios" Could someone tell me what causes this delay, does the process of uncompressing and copying linuxbios to RAM take this long? Any suggestions on how to reduce this delay? Here's the log of the debug messages. ***************log********************************* LinuxBIOS-1.0.0 Thu Apr 24 06:42:06 IST 2003 starting... Ram1 Ram2 Ram3 Ram Enable 1 Ram Enable 2 Ram Enable 3 Ram Enable 4 Ram Enable 5 Ram4 Ram5 Ram6 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.0.0 Thu Apr 24 06:42:06 IST 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 handle_superio start, nsuperio 1 handle_superio Pass 0, check #0, s 0000cde0 s->super 0000e138 handle_superio: Pass 0, Superio w83627hf handle_superio port 0x0, defaultport 0x2e handle_superio Using port 0x2e handle_superio Pass 0, done #0 handle_superio done Scanning PCI bus...PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [8086/7124] PCI: 00:1e.0 [8086/2418] PCI: 00:1f.0 [8086/2410] PCI: 00:1f.1 [8086/2411] PCI: 00:1f.2 [8086/2412] PCI: 00:1f.3 [8086/2413] PCI: 00:1f.5 [8086/2415] PCI: 00:1f.6 [8086/2416] PCI: pci_scan_bus for bus 1 PCI: 01:04.0 [10ec/8139] PCI: 01:05.0 [10ec/8139] PCI: pci_scan_bus returning with max=01 PCI: pci_scan_bus returning with max=01 done Allocating PCI resources... ASSIGN RESOURCES, bus 0 PCI: 00:1e.0 1c <- [0x00001000 - 0x00001fff] bus 1 io PCI: 00:1e.0 24 <- [0xfec00000 - 0xfebfffff] bus 1 prefmem PCI: 00:1e.0 20 <- [0xfeb00000 - 0xfebfffff] bus 1 mem ASSIGN RESOURCES, bus 1 PCI: 01:04.0 10 <- [0x00001000 - 0x000010ff] io PCI: 01:04.0 14 <- [0xfeb00000 - 0xfeb000ff] mem PCI: 01:05.0 10 <- [0x00001400 - 0x000014ff] io PCI: 01:05.0 14 <- [0xfeb01000 - 0xfeb010ff] mem ASSIGNED RESOURCES, bus 1 PCI: 00:1f.1 20 <- [0x000028e0 - 0x000028ef] io PCI: 00:1f.2 20 <- [0x000028c0 - 0x000028df] io PCI: 00:1f.3 20 <- [0x000028f0 - 0x000028ff] io PCI: 00:1f.5 10 <- [0x00002000 - 0x000020ff] io PCI: 00:1f.5 14 <- [0x00002880 - 0x000028bf] io PCI: 00:1f.6 10 <- [0x00002400 - 0x000024ff] io PCI: 00:1f.6 14 <- [0x00002800 - 0x0000287f] io ASSIGNED RESOURCES, bus 0 done. Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06 PCI: 00:1e.0 cmd <- 07 PCI: 00:1f.0 cmd <- 0f PCI: 00:1f.1 cmd <- 01 PCI: 00:1f.2 cmd <- 01 PCI: 00:1f.3 cmd <- 01 PCI: 00:1f.5 cmd <- 01 PCI: 00:1f.6 cmd <- 01 PCI: 01:04.0 cmd <- 03 PCI: 01:05.0 cmd <- 03 done. Initializing PCI devices... PCI devices initialized DRP0 = 0x9 DIMM0 - size = 64M DIMM1 - size = 0M DRP1 = 0x0 DIMM2 - size = 0M totalram: 64M Initializing CPU #0 Updating microcode microcode_info: sig = 0x00000678 pf=0x00000001 rev = 0x00000000 Enabling cache... Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 64MB, type WB DONE variable MTRRs Clear out the extra MTRR's call intel_enable_fixed_mtrr() call intel_enable_var_mtrr() Leave setup_mtrrs done. Max cpuid index : 1 Vendor ID : CentaurHauls Processor Type : 0x00 Processor Family : 0x06 Processor Model : 0x07 Processor Mask : 0x00 Processor Stepping : 0x08 Feature flags : 0x00803035 MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Configuring L2 cache...Not 'GenuineIntel' Processor Enable Cache done. Disabling local apic...done. CPU #0 Initialized ioapic southbridge enabled 180 RTC Init Invalid CMOS LB checksum set power on after power fail Please turn on nvram handle_superio start, nsuperio 1 handle_superio Pass 1, check #0, s 0000cde0 s->super 0000e138 handle_superio: Pass 1, Superio w83627hf handle_superio port 0x2e, defaultport 0x2e handle_superio Using port 0x2e Call init Enabling com device: 03 iobase = 0x02f8 irq=3 handle_superio Pass 1, done #0 handle_superio done handle_superio start, nsuperio 1 handle_superio Pass 2, check #0, s 0000cde0 s->super 0000e138 handle_superio: Pass 2, Superio w83627hf handle_superio port 0x2e, defaultport 0x2e handle_superio Using port 0x2e handle_superio Pass 2, done #0 handle_superio done Wrote linuxbios table at: 00000500 - 00000664 checksum 7535 Jumping to linuxbiosmain()... Welcome to start32, the open sourced starter. This space will eventually hold more diagnostic information. January 2000, James Hendricks, Dale Webster, and Ron Minnich. Version 0.1 Regards, Shubhangi
Shubhangi Jadhav wrote:
While trying to boot using linuxbios , I get a message " Copying LinuxBIOS to ram " and then the system pauses for 3-4 secs, before printing the next message - "Jumping to Linuxbios" Could someone tell me what causes this delay, does the process of uncompressing and copying linuxbios to RAM take this long? Any suggestions on how to reduce this delay?
Sounds like the decompression time. Try disabling compression (option CONFIG_COMPRESS=0) and see if it speeds up. What is biosbase set to (default is 0xf0000)? It might be caching is not set for the region of your flash, since it is executing from flash at this point. -Steve
3-4 seconds looks a long time, should uncompression of few 100 KBbytes take that long. Also, could someone please elaborate the signifigance of biosbase set with this reference. Regards Deepak ----- Original Message ----- From: "Steve Gehlbach" <steve@nexpath.com> To: "Shubhangi Jadhav" <shubhangi.jadhav@patni.com> Cc: "LinuxBIOS" <linuxbios@clustermatic.org> Sent: Thursday, April 24, 2003 8:47 PM Subject: Re: Delay in copying Linuxbios to ram
Shubhangi Jadhav wrote:
While trying to boot using linuxbios , I get a message " Copying LinuxBIOS to ram " and then the system pauses for 3-4 secs, before printing the next message - "Jumping to Linuxbios" Could someone tell me what causes this delay, does the process of uncompressing and copying linuxbios to RAM take this long? Any suggestions on how to reduce this delay?
Sounds like the decompression time. Try disabling compression (option CONFIG_COMPRESS=0) and see if it speeds up. What is biosbase set to (default is 0xf0000)? It might be caching is not set for the region of your flash, since it is executing from flash at this point.
-Steve
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Thu, 24 Apr 2003, Deepak Kotian wrote:
3-4 seconds looks a long time, should uncompression of few 100 KBbytes take that long.
sure, if you are running un-cached. I had it take 20 seconds on an L440GX+ before we got caching right. ron
Deepak Kotian wrote:
3-4 seconds looks a long time, should uncompression of few 100 KBbytes take that long. Also, could someone please elaborate the signifigance of biosbase set with this reference.
biosbase defaults to 0xf0000 and I believe this region is automatically cached by linuxbios (maybe not?). If biosbase is set to 0xffff0000, then in your config you need to set: option XIP_ROM_SIZE= 0x01000000 option XIP_ROM_BASE= 0xff000000 This will cache the upper 16M of the 4G address space. Basically, the chipsets generally map both to the same physical memory, the flash, ie, they aliasing 0xf0000 to 0xffff0000. You can cover 0xf0000 with ram, by setting proper bits in the bridge, but not 0xffff0000. But on startup by default most if not all chipsets alias the top 64k under 1M to the top 64k under 4G. It all has to do with legacy, real-mode stuff. linuxbios is in 32-bit mode, though, after a few initial instructions. -Steve
On Thu, Apr 24, 2003 at 12:59:27PM -0700, Steve Gehlbach wrote:
Deepak Kotian wrote:
3-4 seconds looks a long time, should uncompression of few 100 KBbytes take that long. Also, could someone please elaborate the signifigance of biosbase set with this reference.
biosbase defaults to 0xf0000 and I believe this region is automatically cached by linuxbios (maybe not?). If biosbase is set to 0xffff0000, then in your config you need to set:
option XIP_ROM_SIZE= 0x01000000 option XIP_ROM_BASE= 0xff000000
I have the same delay problem on VIA EPIA board. It didn't run with biosbase set to 0xffff0000 (hangs after first banner, and I don't have a POST card to track it down). In cpu/p6/earlymtrr.inc, 0xf0000-0xfffff is left uncached. (Only 0-640KB is cached, 640KB-1M is uncached) I will try adding code there to set fixed MTRR for 0xf0000-0xfffff WP caching. It should be harmless for other boards that do not need this, what do you think? -- Takeshi
I have the same delay problem on VIA EPIA board. It didn't run with biosbase set to 0xffff0000 (hangs after first banner, and I don't have a POST card to track it down).
Not surprising, some implementations depend on executing at 0xf0000. If the serial port is working, you can put in prints etc and track it down without a POST card.
In cpu/p6/earlymtrr.inc, 0xf0000-0xfffff is left uncached. (Only 0-640KB is cached, 640KB-1M is uncached) I will try adding code there to set fixed MTRR for 0xf0000-0xfffff WP caching. It should be harmless for other boards that do not need this, what do you think?
Not sure. Need to see if the RAM is turned on for this region later after the C-code starts, if so, then the cache memory type may have to be changed from WP to normal. -Steve
Steve Gehlbach <steve@nexpath.com> writes:
I have the same delay problem on VIA EPIA board. It didn't run with biosbase set to 0xffff0000 (hangs after first banner, and I don't have a POST card to track it down).
Not surprising, some implementations depend on executing at 0xf0000. If the serial port is working, you can put in prints etc and track it down without a POST card.
In cpu/p6/earlymtrr.inc, 0xf0000-0xfffff is left uncached. (Only 0-640KB is cached, 640KB-1M is uncached) I will try adding code there to set fixed MTRR for 0xf0000-0xfffff WP caching. It should be harmless for other boards that do not need this, what do you think?
Not sure. Need to see if the RAM is turned on for this region later after the C-code starts, if so, then the cache memory type may have to be changed from WP to normal.
The generic code should handle this. I believe all of the mtrrs are rebuilt. Eric
On Fri, Apr 25, 2003 at 06:55:37PM -0600, Eric W. Biederman wrote:
In cpu/p6/earlymtrr.inc, 0xf0000-0xfffff is left uncached. (Only 0-640KB is cached, 640KB-1M is uncached) I will try adding code there to set fixed MTRR for 0xf0000-0xfffff WP caching. It should be harmless for other boards that do not need this, what do you think?
Not sure. Need to see if the RAM is turned on for this region later after the C-code starts, if so, then the cache memory type may have to be changed from WP to normal.
I tried it anyway and it worked great. Now I can't see anything between 'Copying LinuxBIOS to ram' and IDE loading message because it's too fast!
The generic code should handle this. I believe all of the mtrrs are rebuilt.
I think it's rebuilt in mtrr.c. My modification is below. -- Takeshi Index: earlymtrr.inc =================================================================== RCS file: /cvsroot/freebios/freebios/src/cpu/p6/earlymtrr.inc,v retrieving revision 1.4 diff -u -r1.4 earlymtrr.inc --- earlymtrr.inc 8 Aug 2001 02:45:09 -0000 1.4 +++ earlymtrr.inc 28 Apr 2003 18:17:51 -0000 @@ -35,6 +35,22 @@ movl $0x06060606, %edx movl $0x06060606, %eax wrmsr + +#if _ROMBASE < 0x100000 + /* enable Write Protect Cache for 0x000f0000-0x000fffff */ + movl $MTRRfix4K_F0000_MSR, %ecx + rdmsr + movl $0x05050505, %edx + movl $0x05050505, %eax + wrmsr + + movl $MTRRfix4K_F8000_MSR, %ecx + rdmsr + movl $0x05050505, %edx + movl $0x05050505, %eax + wrmsr +#endif /* _ROMBASE < 0x100000 */ + #endif /* MEMORY_HOLE */ set_var_mtrr:
SONE Takeshi <ts1@tsn.or.jp> writes:
On Fri, Apr 25, 2003 at 06:55:37PM -0600, Eric W. Biederman wrote:
In cpu/p6/earlymtrr.inc, 0xf0000-0xfffff is left uncached. (Only 0-640KB is cached, 640KB-1M is uncached) I will try adding code there to set fixed MTRR for 0xf0000-0xfffff WP caching. It should be harmless for other boards that do not need this, what do you think?
Not sure. Need to see if the RAM is turned on for this region later after the
C-code starts, if so, then the cache memory type may have to be changed from WP
to normal.
I tried it anyway and it worked great. Now I can't see anything between 'Copying LinuxBIOS to ram' and IDE loading message because it's too fast!
The generic code should handle this. I believe all of the mtrrs are rebuilt.
I think it's rebuilt in mtrr.c.
My modification is below.
``Write Protect'' in the mtrrs does not mean write protected. It is a strange messed up form of write-through. In particular it dumps the cache on writes it does not forbid writes. Unless you know of a situation where write protect is more appropriate please use write-through. It is less confusing, and since no one is writing to that area anyway it gives the exact same result, reads are cached. Eric
Eric W. Biederman wrote:
``Write Protect'' in the mtrrs does not mean write protected. It is a strange messed up form of write-through. In particular it dumps the cache on writes it does not forbid writes.
Unless you know of a situation where write protect is more appropriate please use write-through. It is less confusing, and since no one is writing to that area anyway it gives the exact same result, reads are cached.
Eric
Good point, but do you think it would matter for reflashing?. I don't know if Linux resets the MTRRs when booting, or assumes the BIOS has already done that. I got into the habit of using the WP setting because MS does it this way for the ROM areas for the Xbox (copying MS is probably not a good reason for doing anything!). For all to reference, Intel manual: • Write protected (WP)—Reads come from cache lines when possible, and read misses cause cache fills. Writes are propagated to the system bus and cause corresponding cache lines on all processors on the bus to be invalidated. Speculative reads are allowed. This memory type is available in the Pentium 4, Intel Xeon, and P6 family processors by programming the MTRRs (seeTable 10-6). --------- -Steve
Steve Gehlbach <steve@nexpath.com> writes:
Eric W. Biederman wrote:
``Write Protect'' in the mtrrs does not mean write protected. It is a strange
messed up form of write-through. In particular it dumps the cache on writes it does not forbid writes. Unless you know of a situation where write protect is more appropriate please use write-through. It is less confusing, and since no one is writing to that area anyway it gives the exact same result, reads are cached. Eric
Good point, but do you think it would matter for reflashing?.
Neither type will work reliably when reflashing. The read caching prevents polling of the status bits, to function properly.
I don't know if Linux resets the MTRRs when booting, or assumes the BIOS has already done that.
LinuxBIOS does that. And it is at least legal to manipulate that in an mtd map driver if necessary.
I got into the habit of using the WP setting because MS does it this way for the ROM areas for the Xbox (copying MS is probably not a good reason for doing anything!).
WP is the least aggressive form of caching. And in principle I don't have any problems with it. But it's name is very non-intuitive.
For all to reference, Intel manual: Write protected (WP)Reads come from cache lines when possible, and read
misses cause cache fills. Writes are propagated to the system bus and cause corresponding cache lines on all processors on the bus to be invalidated. Speculative reads are allowed. This memory type is available in the
Pentium 4, Intel Xeon, and P6 family processors by programming the MTRRs (seeTable 10-6). ---------
-Steve
On Mon, Apr 28, 2003 at 01:55:16PM -0600, Eric W. Biederman wrote:
Steve Gehlbach <steve@nexpath.com> writes:
Eric W. Biederman wrote:
``Write Protect'' in the mtrrs does not mean write protected. It is a strange
messed up form of write-through. In particular it dumps the cache on writes it does not forbid writes. Unless you know of a situation where write protect is more appropriate please use write-through. It is less confusing, and since no one is writing to that area anyway it gives the exact same result, reads are cached. Eric
So why did you use WP cache for "XIP" area? Using same type for both area makes sense. -- Takeshi
SONE Takeshi <ts1@cma.co.jp> writes:
On Mon, Apr 28, 2003 at 01:55:16PM -0600, Eric W. Biederman wrote:
Steve Gehlbach <steve@nexpath.com> writes:
Eric W. Biederman wrote:
``Write Protect'' in the mtrrs does not mean write protected. It is a strange
messed up form of write-through. In particular it dumps the cache on
writes
it does not forbid writes. Unless you know of a situation where write protect is more appropriate please
use write-through. It is less confusing, and since no one is writing to that
area anyway it gives the exact same result, reads are cached. Eric
So why did you use WP cache for "XIP" area? Using same type for both area makes sense.
Yep. Good catch. It looks like the XIP area needs to be fixed as well. Actually now that I think about it, is there any reason to not use XIP infrastructure for running the rom at 0xf000 as well as at higher addresses? Sure it's a waste but we have mtrr registers to burn at that point. Eric
On Wed, Apr 30, 2003 at 05:07:10AM -0600, Eric W. Biederman wrote:
Actually now that I think about it, is there any reason to not use XIP infrastructure for running the rom at 0xf000 as well as at higher addresses? Sure it's a waste but we have mtrr registers to burn at that point.
Do you mean the configuration like this? option XIP_ROM_SIZE=65536 option XIP_ROM_BASE=0xf0000 Actually, I've tried this at first, and it was not successful. I guess it is because fixed MTRR overrides the variable MTRR setting (so states intel manual). Totally disabling fixed MTRR (do everything in variable MTRR) looks cleaner solution, but wasteful. -- Takeshi
On Wed, 30 Apr 2003, SONE Takeshi wrote:
Totally disabling fixed MTRR (do everything in variable MTRR) looks cleaner solution, but wasteful.
I thought we tried this at one point but there were machines that it had trouble on. ron
participants (7)
-
Deepak Kotian -
ebiederman＠lnxi.com -
ron minnich -
Shubhangi Jadhav -
SONE Takeshi -
SONE Takeshi -
Steve Gehlbach