10:29 a.m.
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
12:37 p.m.
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:44 p.m.
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 
5:19 p.m.
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
6:38 a.m.
On Thu, Apr 24, 2003 at 12:59:27PM -0700, Steve Gehlbach wrote:
Deepak Kotian wrote:
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
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
3:17 p.m.
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
10:18 p.m.
Steve Gehlbach <steve(a)nexpath.com> writes:
The generic code should handle this. I believe all of the mtrrs are rebuilt.
Eric
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. 
5:04 p.m.
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:
4:39 p.m.
SONE Takeshi <ts1(a)tsn.or.jp> writes:
On Fri, Apr 25, 2003 at 06:55:37PM -0600, 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
> > 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.
5:11 p.m.
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
5:17 p.m.
Steve Gehlbach <steve(a)nexpath.com> writes:
Eric W. Biederman wrote:
Neither type will work reliably when reflashing. The read caching prevents
polling of the status bits, to function properly.
``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.
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
6:48 a.m.
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
8:28 a.m.
SONE Takeshi <ts1(a)cma.co.jp> writes:
On Mon, Apr 28, 2003 at 01:55:16PM -0600, Eric W.
Biederman wrote:
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
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.
9:25 a.m.
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
6041
days inactive
6053
days old
15 comments
7 participants
participants (7)
-
Deepak Kotian -
ebiederman＠lnxi.com -
ron minnich -
Shubhangi Jadhav -
SONE Takeshi -
SONE Takeshi -
Steve Gehlbach