yeeee ha!

[Ronald G. Minnich]

(from the web page ...)

---

New as of 3/20/00: Success!

We're now booting linux out of NVRAM. It gets to the point of wanting to
mount a disk, and since I have no disk attached to the motherboard it
naturally dies. It seems to
properly configure the PCI bus, and finds the Ethernet and other devices
and configures them. So now I need to go grab an IDE disk and get it the
rest of the way up ...

---

Oen remaining problem is speed. I have caching enabled but it takes a very
long time to get the gunzip done. I figure there is some other bit I need
to set ... I'll do that one later. For now, it's time to attach an IDE
disk and see how it goes.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Horatio B. Bogbindero]

could i ask for the website URL again. thanks.

On Mon, 20 Mar 2000, Ronald G. Minnich wrote:
> (from the web page ...)
>
> New as of 3/20/00: Success!
>
> We're now booting linux out of NVRAM. It gets to the point of wanting to
> mount a disk, and since I have no disk attached to the motherboard it
> naturally dies. It seems to
> properly configure the PCI bus, and finds the Ethernet and other devices
> and configures them. So now I need to go grab an IDE disk and get it the
> rest of the way up ...
>
> Oen remaining problem is speed. I have caching enabled but it takes a very
> long time to get the gunzip done. I figure there is some other bit I need
> to set ... I'll do that one later. For now, it's time to attach an IDE
> disk and see how it goes.
>
> ron
>
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

---------------------
[e-mail]

The meek will inherit the earth -- if that's OK with you.

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Ronald G. Minnich]

I'd better put this in my .sig.

The linux bios is at www.acl.lanl.gov/linuxbios

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Alan Grimes]

My main computer is *WAY* too old and trashy to hack on but still I am very
currious about eggzacktlie how this is done? How do I figure out how tho flash
one of these suckahs? Is there a standard BIOS flashing interface? How do I
figure out the funky quirks that my pecular BIOS knows about my board? How
safe is this? How would I go about restoring a foobar BIOS. =\ It definitely
sounds like something I would want to do on a spare board.. Contrary to the
previous post, I feel that I WILL need a programmer to safely revert the
BIOS...) After that How do I get $30,000,000 to develop an operating system
worth putting on a new computer? =(

[Ronald G. Minnich]

On Mon, 20 Mar 2000, Alan Grimes wrote:
> How do I figure out
> how tho flash one of these suckahs? Is there a standard BIOS flashing
> interface?

you flash it by either (1) using devbios in linux or (2) for stupid
companies (no names here :-)) using the company's bios flasher program.
> How do I figure out the funky quirks that my pecular BIOS
> knows about my board?

With good companies (e.g. SiS) ask them. With bad companies
(e.g. Intel) trial and error.
> How safe is this?

Very safe on, e.g., the L440GX+, since there is a jumper that uses a
different NVRAM chip for reloading the main NVRAM chip.
> How would I go about restoring
> a foobar BIOS. =\

what motherboard.

Everything depends on what motherboard you have.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Edwin Rhodes]

well done! fantastic,
keep up the good work, let us know how you get on. :)
edwin

----- Original Message -----
From: Ronald G. Minnich 
To: 
Sent: Monday, March 20, 2000 3:03 PM
Subject: [OpenBIOS] yeeee ha!
> (from the web page ...)
>
> New as of 3/20/00: Success!
>
> We're now booting linux out of NVRAM. It gets to the point of wanting to
> mount a disk, and since I have no disk attached to the motherboard it
> naturally dies. It seems to
> properly configure the PCI bus, and finds the Ethernet and other devices
> and configures them. So now I need to go grab an IDE disk and get it the
> rest of the way up ...
>
> Oen remaining problem is speed. I have caching enabled but it takes a very
> long time to get the gunzip done. I figure there is some other bit I need
> to set ... I'll do that one later. For now, it's time to attach an IDE
> disk and see how it goes.
>
> ron
>
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Erwin Rol]

"Ronald G. Minnich" wrote:
> Oen remaining problem is speed. I have caching enabled but it takes a very
> long time to get the gunzip done. I figure there is some other bit I need
> to set ... I'll do that one later. For now, it's time to attach an IDE
> disk and see how it goes.

What times are we talking about ?
Could you give any benchmarks ? like how long it takes from turning on
the
computer until init is called ?

It would be _very_ interesting to have a (custom) init running within 2
second or less
after powerup, could you see this happening ?

(of course that will exclude slow starting things like SCSI controlers
and the like,
and no auto probing , everything preconfigured in the kernel)

thanx and keep up the great work,

Erwin
> ron
>
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Ronald G. Minnich]

On Tue, 21 Mar 2000, Erwin Rol wrote:
> What times are we talking about ?

really slow!
> Could you give any benchmarks ? like how long it takes from turning on
> the
> computer until init is called ?

right now the gunzip step takes up to ONE MINUTE. I've got something set
up wrong, and I hear that there is a needed step in the PII to make it
"run fast". It seems to be running at 8086 speeds ...
> It would be _very_ interesting to have a (custom) init running within 2
> second or less
> after powerup, could you see this happening ?

I think it is possible.

The big issue is bandwidth to the NVRAM. You need to suck 512K out of the
NVRAM. If the NVRAM has 1 MB/sec bandwidth, this step takes 1/2 second. If
we had 16 MB/second nvram, then obviously we're faster.

Sad to say, there's only an 8-bit path to NVRAM. And flash is slow. This
is a long-term problem.

The faster the NVRAM, the better.
> (of course that will exclude slow starting things like SCSI controlers
> and the like,
> and no auto probing , everything preconfigured in the kernel)
> From what I'm seeing the scsi is slow but not terrible. The scsi bioses

stink, though.

ron
p.s. my goal for a cluster node is cold boot in 7 seconds, reboot in 5
seconds. I think it's quite possible.

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Erwin Rol]

"Ronald G. Minnich" wrote:
> On Tue, 21 Mar 2000, Erwin Rol wrote:
> > What times are we talking about ?
>
> really slow!
> > Could you give any benchmarks ? like how long it takes from turning on
> > the
> > computer until init is called ?
>
> right now the gunzip step takes up to ONE MINUTE. I've got something set
> up wrong, and I hear that there is a needed step in the PII to make it
> "run fast". It seems to be running at 8086 speeds ...

Hmmm that sucks :-/ but i am sure it is just a mather of time before 
you (or someone else) will find the problem.
> > It would be _very_ interesting to have a (custom) init running within 2
> > second or less
> > after powerup, could you see this happening ?
>
> I think it is possible.
>
> The big issue is bandwidth to the NVRAM. You need to suck 512K out of the
> NVRAM. If the NVRAM has 1 MB/sec bandwidth, this step takes 1/2 second. If
> we had 16 MB/second nvram, then obviously we're faster.
>
> Sad to say, there's only an 8-bit path to NVRAM. And flash is slow. This
> is a long-term problem.
>
> The faster the NVRAM, the better.

Not much one can do about the hardware, appart from choosing the
motherboard
wizely.
> > (of course that will exclude slow starting things like SCSI controlers
> > and the like,
> > and no auto probing , everything preconfigured in the kernel)
> > From what I'm seeing the scsi is slow but not terrible. The scsi bioses
>
> stink, though.

Time for a open SCSI BIOS :-) ?
> ron
> p.s. my goal for a cluster node is cold boot in 7 seconds, reboot in 5
> seconds. I think it's quite possible.

Hmmm that will be the absolute maxium. 
And what do you understand in "cold boot"?
This is what happens:

1) reset/poweron
2) BIOS sets up hardware
3) BIOS loads/unzips kernel in RAM
4) BIOS jumps to kernel
5) kernel sets up the hardware 
6) kernel creates the init process
7) init starts the application processes

Ofcourse step 6 and 7 depend on where you load those applications from
slow floppy, HD, FLASH disk, CMOS-RAM disk etc.

so what is included in your 5-7 seconds ? :-) Faster is better.
the best would be an up and running X11 desktop with netscape and all
within 500 mseconds  :-)

- Erwin
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

POST speeds.

[Alan Grimes]

I like the idea of an OpenBoot to compliant BIOS that boots quickly. But I
must insist on a full un-abridged POST sequence! I currently run the slow RAM
test because I have had some problems with it in the past.

As for the P2 bootup problems, I am almost certain the problem is that you
aren't switching on the L2 cache. Get the free intel manuals for more info. =)
(It's probably a matter of setting some funky bit somewhere)

POST speeds.

[Ronald G. Minnich]

On Tue, 21 Mar 2000, Alan Grimes wrote:
> I like the idea of an OpenBoot to compliant BIOS that boots quickly. But I
> must insist on a full un-abridged POST sequence! I currently run the slow RAM
> test because I have had some problems with it in the past.

no problem. we'll have one in C. And you won't have to buy a POST card ...
> As for the P2 bootup problems, I am almost certain the problem is that you
> aren't switching on the L2 cache. Get the free intel manuals for more info. =)
> (It's probably a matter of setting some funky bit somewhere)

I'm sure you are right. I was clearing the cache disable bit but I suppose
there is more to do.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

POST speeds.

[Alan Grimes]

> I'm sure you are right. I was clearing the cache disable bit but I >suppose there is more to do.

I think that's missguided. 
My memory tells me that the bit is called "Cache Enable" with

1 = enable
0 = dissable.

That's for the L1 cache, the L2 cache is neccessarily somewhere else in the
MSRs for all Pentium pro and derivatives.

POST speeds.

[David Christensen]

Don't forget to set the MTRRs (Memory Type and Range Registers I believe) in
the CPU.  Enabling the L2 cache isn't enough, you have to tell the CPU what
memory ranges it can cache.  At a minimum you want to enable write-back on
the 0-640K and 1M-TOM (top-of-memory) memory ranges.  Setting the ROM ranges
to read-only would be good too.

Dave

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of
Alan Grimes
Sent: Tuesday, March 21, 2000 11:28 PM
To: [e-mail]
Subject: Re: [OpenBIOS] POST speeds.
> I'm sure you are right. I was clearing the cache disable bit but I
> suppose there is more to do.

I think that's missguided.
My memory tells me that the bit is called "Cache Enable" with

1 = enable
0 = dissable.

That's for the L1 cache, the L2 cache is neccessarily somewhere else in the
MSRs for all Pentium pro and derivatives.

http://users.erols.com/alangrimes/
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

POST speeds.

[Ronald G. Minnich]

On Tue, 21 Mar 2000, David Christensen wrote:
> Don't forget to set the MTRRs (Memory Type and Range Registers I believe) in
> the CPU.  Enabling the L2 cache isn't enough, you have to tell the CPU what
> memory ranges it can cache.  At a minimum you want to enable write-back on
> the 0-640K and 1M-TOM (top-of-memory) memory ranges.  Setting the ROM ranges
> to read-only would be good too.

Well, if anyone wants to contribute code :-)

I'm kind of overloaded right now.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

POST speeds.

[Ronald G. Minnich]

On Tue, 21 Mar 2000, Alan Grimes wrote:
> I think that's missguided. 
> My memory tells me that the bit is called "Cache Enable" with
>
> 1 = enable
> 0 = dissable.

no, believe it or not it is a cache disable bit.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

POST speeds. -- OOPS!

[Alan Grimes]

> > As for the P2 bootup problems, I am almost certain the problem is that you
> > aren't switching on the L2 cache. Get the free intel manuals for more info. =)
> > (It's probably a matter of setting some funky bit somewhere)
>
> I'm sure you are right. I was clearing the cache disable bit but I 
> suppose there is more to do.

Oops, I was wrong you were right. I just looked it up in the manual. Chapter
8.3 describes how to enable the cache, chapter 9 describes the various caches
in detail. It says you have to clear two bits in CR0, the CD bit and another
called the "NW" flag.
    Hmm, Another thing that could be affecting your performance is wheather you
have shaddowed your ROMs? I would suppose you have thought of that already.

POST speeds. -- OOPS!

[Ronald G. Minnich]

alan, what book are you using? I don't think I have it, which is part of
my problem. Do you have a URL?

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

POST speeds. -- OOPS!

[Alan Grimes]

Ronald G. Minnich wrote:
> alan, what book are you using? I don't think I have it, which is part 
> of my problem. Do you have a URL?

The book is "Intel Architecture Software Developer's Manual" It's a
three-volume set. You see clearly how kludgy the intel architecture is when
you count the number of pages it takes to discribe it adiquately. =P

http://developer.intel.com/design/litcentr/index.htm

You can also call:

1-800-548-4725

The best thing is that they don't ask for yor credit card number when they
take your order! (It's FREE!!) the last I checked... Also be sure to snag the
"devolper's Insight CD" ( I only have the NOV 1998 edition), and whatever
motherboard/chipset manuals you can get your hands on.

POST speeds.

[Edwin Rhodes]

hi ron, i know this is probably too far ahead but, have you thought about a
user interface yet? ... i cant get the loadbios prog to work on my computer
so i cant check out what it looks like :) but i would like to help program
the user interface??? that  is if nobody else is doing that... what sort of
UI will it be? command line or gui? i know youre really buisey trying to ket
this cache sorted out, im just offering my help if ya want it :)  <<
hardware programming is not my speciality.
edwin

----- Original Message -----
From: Ronald G. Minnich 
To: 
Sent: Tuesday, March 21, 2000 7:19 PM
Subject: Re: [OpenBIOS] POST speeds.
> On Tue, 21 Mar 2000, Alan Grimes wrote:
> > I like the idea of an OpenBoot to compliant BIOS that boots quickly. But

I
> > must insist on a full un-abridged POST sequence! I currently run the

slow RAM
> > test because I have had some problems with it in the past.
>
> no problem. we'll have one in C. And you won't have to buy a POST card ...
> > As for the P2 bootup problems, I am almost certain the problem is that

you
> > aren't switching on the L2 cache. Get the free intel manuals for more

info. =)
> > (It's probably a matter of setting some funky bit somewhere)
>
> I'm sure you are right. I was clearing the cache disable bit but I suppose
> there is more to do.
>
> ron
>
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

POST speeds.

[Ronald G. Minnich]

for now my user interface is simple: it's linux. You get to control/config
via /dev/bios, or maybe even via sysctl and /proc/bios. To get at these
things you can come in over the net via ssh (it's linux, remember: all
things are possible), or run a TK-based tool that accesses and changes
this stuff, or use a nice GNOME thing, or linuxconfig, or emacs bios-mode,
or if you really need it have a simple command interpreter in the
kernel. But I am utterly opposed to having BIOS do full-screen junk: let
a user program running under the OS do that.

The standard BIOS makes a total mismash of control and UI because of bad
decisions made 20-odd years ago. We can discard these bad decisions. Life
improves.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

POST speeds.

Ronald G. Minnich  wrote:
> for now my user interface is simple: it's linux. You get to control/config
> via /dev/bios, or maybe even via sysctl and /proc/bios. To get at these
> things you can come in over the net via ssh (it's linux, remember: all
> things are possible), or run a TK-based tool that accesses and changes
> this stuff, or use a nice GNOME thing, or linuxconfig, or emacs bios-mode,
> or if you really need it have a simple command interpreter in the
> kernel. But I am utterly opposed to having BIOS do full-screen junk: let
> a user program running under the OS do that.

Agreed, userland is a much better place for such things.
To blow my own trumpet *parp*, This kind of stuff probably
fits in quite well in Powertweak (http://linux.powertweak.com)

A lot of the stuff already included is the sort of stuff that
Award have been offering for some time in their BIOSen.
Ability to play with RAM timings etc, L2 cache latencies etc..
Though I currently only support the chipsets I have here to
experiment on, it's not much work for someone to add support
for their own chipsets.

There's also code already in place to deal with setting some
Linux-specific options in /proc. Could easily be extended to
deal with /dev (and probably will be now that devfs is
getting more and more mainstream)

regards,