Why bios(generic) is slow?

Hi

Can you tell me why generic bios is so slow compared to linuxbios. 
In other word, why linuxbios is fast? 
I think "do little thing" is not enough to explain x10 time difference. 
What does bios do other than linuxbios does and where it spend so much
time?

Regard, 
Heechul

-
HeeChul Yun,          
Embedded S/W Team at ETRI
phone: [phone]

[Kim Jin-Kwon]

Why bios(generic) is slow?Well, IMHO, that's because, normal conventional BIOS do spend much of time in
de-compressing its <<modules>>. as you can see those "modular BIOS" banner.
load one module, decomp it, execute it, report module exit status and etc..
256kb is not so vast space for even bios written in full .asm language.
and some modules require the cpu to be in real 'real mode' some others run in something like
flat mode. so there should be some resets also.
hope it helps.

----- Original Message ----- 
  From: [e-mail] 
  To: [e-mail] 
  Cc: [e-mail] 
  Sent: Sunday, December 29, 2002 7:21 PM
  Subject: Why bios(generic) is slow?

Hi

Can you tell me why generic bios is so slow compared to linuxbios. 
  In other word, why linuxbios is fast? 
  I think "do little thing" is not enough to explain x10 time difference. 
  What does bios do other than linuxbios does and where it spend so much time?

Regard, 
  Heechul

- 
  HeeChul Yun,          
  Embedded S/W Team at ETRI 
  phone: [phone]

[Ronald G. Minnich]

On Sun, 29 Dec 2002 [e-mail] wrote:
> Can you tell me why generic bios is so slow compared to linuxbios. 
> In other word, why linuxbios is fast?

it would require us to profile the bios which we can't do (we don't have 
source).

I am told by those who have sources that commercial bios'es are an large 
mess of assembly code with lots of repeated code and fixes for hardware 
that has not existed for 10 years. I find these stories believable ...

ron

[Andrew Kohlsmith]

> I am told by those who have sources that commercial bios'es are an large
> mess of assembly code with lots of repeated code and fixes for hardware
> that has not existed for 10 years. I find these stories believable ...

Actually that brings up a few questions I had about the 430TX chipset support 
in LinuxBIOS...  The DRAM initialization seems to be utterly mangled, with 
Eric's code winning out (since it seems to work.  :-) -- but I have seen a 
few register initializations which I haven't been able to find in my 430TX 
documentation.

Things like register 0x90 (in raminit.inc it's called "Error Control 
Register") and using eight read cycles to reset either the memory or the 
controller, I'm not sure...  Does anyone have any recollection of where this 
type of information was found?  If I do a (fairly large) cleanup of the 430TX 
ram init code, would it be accepted into CVS or is it how it is for specific 
reasons?

BTW: I found out why LinuxBIOS kept resetting -- the FDC37N958FR's internal 
8051 core has a watchdog which is initialized to about 4s on POR...  I was 
playing with the ramtest.inc and delays in the mem init of the northbridge 
and got nearer or farther in the boot.

[Ronald G. Minnich]

On Sun, 29 Dec 2002, Andrew Kohlsmith wrote:
> Actually that brings up a few questions I had about the 430TX chipset
> support in LinuxBIOS...  The DRAM initialization seems to be utterly
> mangled, with Eric's code winning out (since it seems to work.  :-) --
> but I have seen a few register initializations which I haven't been able
> to find in my 430TX documentation.

it's a mess, due to 430tx bugs and problems and doc errors, and the fact 
that the chipset is seeing so little use nowadays that almost nobody 
cares. But a clean implementation would still be of interest.
> Things like register 0x90 (in raminit.inc it's called "Error Control 
> Register") and using eight read cycles to reset either the memory or the 
> controller, I'm not sure...  Does anyone have any recollection of where this 
> type of information was found?

trial and error and error and error and ... until it worked. Then we 
stopped and moved on to other things and never got back to it.
> If I do a (fairly large) cleanup of the 430TX ram init code, would it be
> accepted into CVS or is it how it is for specific reasons?

If it doesn't break anything like the smartcore-p5 we'll take it.

ron

[e-mail] writes:
> Hi
>
> Can you tell me why generic bios is so slow compared to linuxbios. 
> In other word, why linuxbios is fast? 
> I think "do little thing" is not enough to explain x10 time difference. 
> What does bios do other than linuxbios does and where it spend so much
> time?

I have wondered that and looked, and on some desktop systems boot up
with a standard BIOS is something like the time LinuxBIOS takes.  But
for server systems, and other lower volume systems I suspect someone
just does a lousy job.

Beyond that.  The easy things to mess up are things like the MTRRs.
If they are not turned on at the appropriate time you can easily get
a 10x slowdown.

Eric