Delay in copying Linuxbios to ram

[Shubhangi Jadhav]

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

[Steve Gehlbach]

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

[Deepak Kotian]

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(a)nexpath.com>
To: "Shubhangi Jadhav" <shubhangi.jadhav(a)patni.com>
Cc: "LinuxBIOS" <linuxbios(a)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(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios

[ron minnich]

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

[Steve Gehlbach]

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

[SONE Takeshi]

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

[Steve Gehlbach]

  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(a)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

[SONE Takeshi]

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(a)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

[Steve Gehlbach]

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(a)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

[SONE Takeshi]

On Mon, Apr 28, 2003 at 01:55:16PM -0600, Eric W. Biederman wrote:
  Steve Gehlbach <steve(a)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(a)cma.co.jp> writes:

  On Mon, Apr 28, 2003 at 01:55:16PM -0600, Eric W.
Biederman wrote:
  Steve Gehlbach <steve(a)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

[SONE Takeshi]

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

[ron minnich]

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