Fwd: Re: Hello

[Daniel Engstrom]

On 13 Oct, Stefan Reinauer wrote:
> Hi...
>
> On Tue, 13 Oct 1998 [e-mail] wrote:
> > Here is what I thought:
> > A free Open Firmware implementation that runs on my PC would be utterly
> > cool and the Right Thing To Do <tm>.
>
> This is generally correct I would say. But what could/should be discussed
> is whether we should really implement what is IEEE Std 1275-1994
> (Official Name of Sun's OpenFirmware). I am a bit in fear that we might
> get problems implementing a forth interpreter in 128k together with the
> whole stuff we need to get a machine running. (This may be because I am
> not familiar with Forth, though) :)

Some boards have 4MBit (256k byte) flash these days... And IO though one
could use compression. The gunzip object code in linux is 14k bytes and
the kernel compresses about 2.5:1 which means that if we total 16k
uncompressed code we have 112k left in the PROM. If we get 2.5x as well
it will give 280k. If we only get 2x it will still be 224k binary code.

I am more worried about NVRAM space, the standard RTC only have 64 bytes
of which 50 bytes are general purpose. Ofcuse most board have
RTC versions with more RAM up to 4k, but we will need compression or
some token based system to fit the needed boot variables.

My idea of boot sequence (with my limited knowledge on what IEEE1275
says)...

1: Initialize DRAM controller and check 1st 64k DRAM 
2: Enter PM
3: Load segments, TSS, stuff
4: Initialize rest of memory, set DRAM timing CONSERVATIVE, 
5: Uncompress main firmware
6: Initialize PIC, DMA, Super IO chip and VGA (If boot console is VGA)
7: Parse NVRAM
8: Scan for FORTH code
9: Execute any FORTH code
10: Boot system
> > The boring part is that I believe the Open Firmware specs cost money.
>
> They are available as a book. I ordered it today :-)
> It's ISBN Number 1-55937-426-8 IEEE Std 1275-1994: IEEE Standard for Boot
> Firmware.

What did they charge?
> > In order to to this one fist should get the specs (anyone here who has
> > them?) And then make an architecture addendum for the i386 and submit
> > it to the Open Firmware folks. (Las time I checked their web site there
> > were none for the i386, the web site is unresponsive at the moment.)
>
> I found http://playground.sun.com/1275/home.html
> which might be interesting as a starting point, but I haven't had a closer
> look at it.

Thats the page I remember looking at.

They have "Instruction Set Architecture Supplement"s for 
Sparc, PPC and ARM. So if we choose that path we'll need to specify
Open Firmware for IA-32 and the PC platform. Everything else (PCI, ISA,
VGA, etc, seems to be specified already for CHRP I suppose.)
> .signature: No such file or directory

:)

/Daniel
--

Hello

[Philipp Rumpf]

On Tue, Oct 13, 1998 at 09:20:34PM +0200, Daniel Engstrom wrote:
> On 13 Oct, Stefan Reinauer wrote:
> > On Tue, 13 Oct 1998 [e-mail] wrote:
>
> Some boards have 4MBit (256k byte) flash these days... And IO though one
> could use compression. The gunzip object code in linux is 14k bytes and
> the kernel compresses about 2.5:1 which means that if we total 16k
> uncompressed code we have 112k left in the PROM. If we get 2.5x as well
> it will give 280k. If we only get 2x it will still be 224k binary code.
>
> I am more worried about NVRAM space, the standard RTC only have 64 bytes
> of which 50 bytes are general purpose. Ofcuse most board have

Wrong. Most newer systems (i.e., those that have Flash ROMs, more or less)
have 128 bytes, of which 114 bytes are usable (one could think about abusing
the century and alarm fields, however). These bytes are accessible just like
normal CMOS is (out 0x70,index / in data,0x71).
And there are extensions or possibilities for extension on PS/2s and Compaqs
(they used to store the serial number there).

Philipp Rumpf

IEEE1275

[Stefan Reinauer]

On Tue, 13 Oct 1998, Daniel Engstrom wrote:
> Some boards have 4MBit (256k byte) flash these days... And IO though one
> could use compression. The gunzip object code in linux is 14k bytes and
> the kernel compresses about 2.5:1 which means that if we total 16k
> uncompressed code we have 112k left in the PROM. If we get 2.5x as well
> it will give 280k. If we only get 2x it will still be 224k binary code.

I fear that you can't rely on this. Even many PII Systems are not equipped
with 2MBit (256kbyte) Flash chips. I also heard, that bios manufacturers
are about to lower their bios sizes again to fit into smaller chips,
because it's really not neccessary to see the cpu temperature in bios
setup for example. But on the other hand, we could say that we don't
support older boards very well in general. If you have a look at how fast
development is going at the moment, it may be acceptable because there are
no pentiums anymore until we have OpenBios ready and bootable :-)

Another idea that comes to my mind is the question for a general bios
concept. If Intel switches to ia64 at about y2k, we would only support old
and obsolete hardware if we specialize on intel ia32 architecture.
> I am more worried about NVRAM space, the standard RTC only have 64 bytes
> of which 50 bytes are general purpose. Ofcuse most board have
> RTC versions with more RAM up to 4k, but we will need compression or
> some token based system to fit the needed boot variables.

We can say that every PC better than an 386 has at least 128bytes today.
4 or 8k versions are used in EISA boards. But as you might know, the Award
BIOS uses parts of the flash rom to save it's PnP information.
> 7: Parse NVRAM
> 8: Scan for FORTH code
> 9: Execute any FORTH code

Does anyone have an idea how much code is needed for this one?? :-)
A java bytecode interpreter comes to my mind :-)
> > > The boring part is that I believe the Open Firmware specs cost money.
> >
> > They are available as a book. I ordered it today :-)
> > It's ISBN Number 1-55937-426-8 IEEE Std 1275-1994: IEEE Standard for Boot
> > Firmware.
>
> What did they charge?

I don't know yet. They told me it would take about 6 weeks because you
don't get it in Germany and it will be about DM100-DM250, which is about
70-180US$ I think
> They have "Instruction Set Architecture Supplement"s for 
> Sparc, PPC and ARM. So if we choose that path we'll need to specify
> Open Firmware for IA-32 and the PC platform. Everything else (PCI, ISA,
> VGA, etc, seems to be specified already for CHRP I suppose.)

Hmm.. Do you have an idea where to get those "Instruction Set Architecture
Supplement"s??

Stefan.