Greetings from the U.S.
I would like to help with the development but I have a question that
I'd like to ask:
Do I need an EPROM/FLASH memory writers for the work? Is it enough to
just buy a motherboard with FLASH memory and download the new bios to
the chip?
If I just need a motherboard with FLASH, could somebody give me some
suggestions as what motherboards are good?
If I need an EPROM/FLASH memory burner, or any special circuitry,
could somebody give me a little advice also?
Regards,
Qiwei Xiao
Lucent Technologies
Asbjoernsen(a)atntr.telemax.no schrieb:
> > Linking wrapper functions is the better way IMHO, since it would not require
> > too much memory and let us run OpenBIOS in the background of these OSs.
> Yes, but in the early stages of development, it would be nice to have a working
> biosloader flashed on the chip, and then test new versions by loading them from
> disk. If we have a legacy bios loadable on disk, we can use that as a fallback
> then thing goes wrong.
Well, I'm currently working on a hardware solution, such as 512k RAM, writable from
another machine, possibly even with access to that machine's video RAM and keyboard
input (for remote testing... :-) ).
> This way we could also get started making some code. I
> don't know how much work this would take, but a simple thing that gets the first
> 128k from a floppy and then boots that would be a good start, wouldn't it?
Yes, of course, but how do you intend to test the BIOS loader code? I think this
code is much harder to write than the actual BIOS code, because of the memory
testing code which would clear the BIOS out of memory, I think. We would need some
kind of protected addtional memory.
CU
Simon
Stefan Reinauer schrieb:
> 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) :)
Well, I personally do not need Forth to get my computer running, but I'd
rather like to see ACPI implemented.
> > I also think that providing legacy OS support though loading a
> > traditional BIOS from disk is the way to go.
>
> Yes. fully true.
Well, I'm not too sure about that. It would require a Windows user to store
some BIOS file on disk, which would be either on a Windows partition, where it
could be accidentally deleted, on a special partition, which would require a
partition entry, or outside any partitions, where it would be hard to protect
the file from fdisk.
Linking wrapper functions is the better way IMHO, since it would not require
too much memory and let us run OpenBIOS in the background of these OSs.
CU
Simon
On 14 Oct, Stefan Reinauer wrote:
>
> 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.
Yeah I meant 2Mbit too.
> I also heard, that bios manufacturers are about to lower their bios
> sizes again to fit into smaller chips,
Note that the 220-280k figure above is based on a 128k flash and gzip
compression. Or do you mean that they are trying to squeeze it in to a
64k flash?
> 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.
Yeah, thats the point of IEEE-1275. It's a general, cross-platform
approach and any code base produces will make sense on any platform.
> 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.
Well that's one solution, maybe we'll have to do something like that for
NVRAM-starved systems. One other way would be to use the boot prom
socket "everybody" have sitting empty on their NICs to add more flash
or a NVRAM module.
> Hmm.. Do you have an idea where to get those "Instruction Set Architecture
> Supplement"s??
They're linked from the main page, but I'll include the URLs here:
Sparc: http://playground.sun.com/1275/bindings/sparc/d14a/12751d1a.ps
PPC: http://playground.sun.com/1275/bindings/ppc/release/ppc-2_1.ps
ARM: http://playground.sun.com/1275/bindings/arm/arm0_3d.pdf
>> 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 :-)
Me thinks FORTH is smaller than java...
GNU forth 0.3.0 static and dynamic linking.
-rwxrwxr-x 1 root root 240928 Oct 14 12:08 gforth
-rwxrwxr-x 1 danne danne 38628 Oct 14 12:20 gforth
Note that this is supposed to be a general-purpose forth and I think a
Open Firmaware compilant Forth dosent have to be 250kb.
/Daniel
Here is a mail that appeared on linux-kernel about forth (in the kernel
this time):
>From humbubba(a)raptor.cqi.com Wed Oct 14 11:40:44 1998
Date: Fri, 18 Sep 1998 17:57:46 -0400 (EDT)
From: RHS Linux User <humbubba(a)raptor.cqi.com>
To: linux-kernel(a)vger.rutgers.edu
Subject: Helge, Forth is not an interpreter.
In reference to the wish for an "interpreter" in the kernel for
device drivers...
Forth is machine language for a virtual 2-stack machine.
This is a machine with no registers, not stacks implemented in
registers.
This machine language has ops at a very low level to implement
a compiler and an interpreter.
Open Firmware is the example. The author of Open Firmware, Mitch
Bradley, was a bigwig on the ANSI Forth Standard commitee.
How the Forth virtual machine is implemented varies from silicon
to Java. A Forth running on a silicon 2 stack machine OUTperforms
anything else. gForth uses the labels-as-values capability of GNU
C ( which egcs seems to have also) to "thread" Forth primitives
together in what is called Indirect Threading in the Forth world.
This gives a level of performance unattainable in ANSI C. The first
Forth-in-C was written by the above Mitch Bradley, who invented
"switch-threading" for it. His CForth was a single C switch statement.
One of the authors of GForth has an x86 Forth called BigForth.
It outperforms GNU C for some floating-point operations.
The reason for Open Firmware is this...
a driver manufacturer writes ONE driver in ANSI Forth. It is
distributed as ANSI Forth sourcecode. How it performs is
entirely up to the OS. If that OS was on a silicon Forth engine
CPU that driver would compile to the screamingest stuff you've
ever seen.
I don't know the specifics of Open Firmware, since Open here
has the usual meaning, but Forth compiles fully, to the limit
of how the Forth VM is implemented.
There would be a performance hit on Forth drivers in any Linux
scenario currently existing, but not in the scale that the
term "interpreter" implies.
Having a compiler running in kernel space would be pretty wacky.
The unknowns that emerge is beyond my imagination. But due to the
succinct, efficient, minimalist design of Forth, those unknowns are
far less with Forth than anything else.
Rick Hohensee http://cqi.com/~humbubba
colorg on EFnet IRC #linux chanop
Forth C Linux Perl graphics music Md., USA
This is your brain on colorg --> (@#*%@#() <---~~~_()()(
Any questions?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
--
On 13 Oct, Stefan Reinauer wrote:
> Hi...
>
> On Tue, 13 Oct 1998 daniel.engstrom(a)riksnett.no 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
--
