OpenBIOS

openbios@openbios.org

4297 discussions

Re: A little patch
by Philipp Rumpf 14 Nov '98

14 Nov '98

On Sun, Nov 15, 1998 at 02:40:24AM +0100, daniel.engstrom(a)riksnett.no wrote: > On 15 Nov, Philipp Rumpf wrote: > >> Can anybody figure out why the memtest fails? (boot/init32/memtest.S) > > > > %edx is 0 ? > > cause you write > > > > cmpl $0, %edx # did we relocate earlier ? > > je .out > > ^^^^ does not reset %eax, which is 0x10000 in the moment > Thanks, (blaming the coffee) fixed now, time to hunt the next bug. What one ? Apropos bug: Stefan, when do you want to put a new devbios version on the net, here is my patch (against 0.2.100) again (I'll post it here cause it's small enough and if some people are brave enough to flash OpenBIOS sometime soon they should be sure they don't run into one of the bugs and cause their system to hard-reboot half-way of flashing a new BIOS(as this is definitely _no_ good time to reboot)). I am currently reading the 82371 / 82430 documentation, perhaps I'll be able to write something tomorrow, but my 3am code is not that good normally. Philipp Rumpf (prumpf(a)jcsbs.lanobis.de)

1 0

A little patch
by Daniel Engstrom 14 Nov '98

14 Nov '98

This is against gfw-0.1 (I have note switched to Stepans version yet) * exception cleanup * console in works * the beginnings of a memory tester Can anybody figure out why the memtest fails? (boot/init32/memtest.S) /Daniel --

2 1

Re: New Code :-)
by daniel.engstrom＠riksnett.no 14 Nov '98

14 Nov '98

On 13 Nov, Stefan Reinauer wrote: > Dear OpenBIOS readers, > > I had the time to have a closer look at Daniel Engstroems code now and I > think we should use this as a code base for further developments. (Daniel, > I hope, you allow this :>) Ok. :) About the name, when I thought of the name I very delibraty(sp?) avoided the use of the word 'BIOS', since we're actually not trying to clone the BIOS, but doing something rather generic. Not that this is important or anything... > > We only have support for 3 chipsets right now. 2, the Ali 1510 support does not work yet... > which is definitely not > enough. I will try to write support for the Intel 430HX/TX/VX/.. chipsets, > as I have an old HX board at home. If anyone is capable of doing this > (it's not really hard, as you just need the datasheets for your chipset > and a board containing the chipset itself to test) I must admit that having the data sheets helps, but the only chipset I have found data sheets for is the ACC1287. Having a working bios image on disk is what really helps, ndissasm is your friend. Hint: the bios enters at 0xffff0 (eg. 'ndissasm -e 0xfff0 -o 0xffff0 rom.bin > bin.txt' for a 64k bios) > I thought about building something like an eprom simulator which can be > plugged into the bios socket of a board and to the parallel port of > another computer which just holds a file with the bios image. This would > make defelopment and testing *quite* faster. Has anyone experiences with > this or does anyone know whether there are ready, cheap solutions for > this? I know they exist. A one Mbit version costs about $500 here. They can be bough from DanBit http://www.danbit.dk (Danish languge pages only) A friend of mine is thinking of designing one for other reasons, he can be found at http://www2.e.kth.se/~e92_jre/ . A port 0x80 decoder is very useful... > Now, at the moment, we don't have hardware drivers for any bootdevices. > Should we go the way linux goes and write our own drivers or should we try > to use other bioses (i.e. scsi bios on host adapter) for that? I think we need to do at least floppy and IDE ourself. That will keep us busy for a while... I still haven't given up on the idea of being 100% OpenFrimware compatible at some point in the future. > Well.. I wrote this just to start discussion again :-) Some notes on the current code: The chipset drives are not finished. I am planning of having a 2nd stage C part of them that runs shortly after the console is initialized, it would probe and test the memory above 1MB. (The 16 bit asm version should enable memory below 1MB with a safe timing.) The last part, also in C should set the memory timings to a value specified by the user (saved in the NVRAM, obiusly) the boot/init32 directory should be moved to the top level firmware dir. Only MDA displays are working, the EGA/VGA stuff is some bone headed attempt to get those working without using their BIOSes, it might work for some cards some day, the other plan is to steal some 386-emulator to parse the video BIOS with, like the ppc/alpha people do (calling the video BIOS directly would just postpone the problem 'til we port this to a non-386 compatible processor, besides the BIOS is 16bit anyway). Console in is not done yet. I can read the keyboard, but I don't keep track of the shift-state, etc. Serial console in is not done yet. (What terminal emulation should we use? Some very basic I think.) Serial console is fixed to com1,9600,8n1 Oh, and the board I have been using are Ampro CM2/3SXi, CM2/4DXi, LB3/P5i. I also have an old ASUS 486 board with a SIS chipset, that I plan on doing (I have the chipset manual, but the board have an Eprom istead of a flash, and I have no 28pin flashes around) /Daniel --

3 3

Re: New Code :-)
by Qiwei Xiao 13 Nov '98

13 Nov '98

Stefan Reinauer wrote: > > Dear OpenBIOS readers, > > ... > > I thought about building something like an eprom simulator which can be > plugged into the bios socket of a board and to the parallel port of > another computer which just holds a file with the bios image. This would > make defelopment and testing *quite* faster. Has anyone experiences with > this or does anyone know whether there are ready, cheap solutions for > this? > I have been thinking about building such eprom simulator as well. The circuit needs at least 10 74xx/40xx ICs to build. I can post the schematic if anybody is interested but I don't know if it is worth the effort to build such a simulator. The solution I am thinking of using is this: (1) Buy an EPROM/Flash ROM writer. The cheapest I have found is around US$150. It can handle a ROM up to 8M of size. (2) Build a small board with a ZIP socket and hook it up to the EPROM socket on the MB so I don't have to worry about damaging the MB when insert/remove the ROM frequently. This, although not as fast as eprom simulator, should work well. The only thing I am not happy with is that the EPROM writer only works on Windows. I hate to boot up Windows for a single minute. Another viable solution is to use devbio (thanks, Stefan). But still I need to build a board with two ROM sockets and a soft "switch" so that I can boot up the PC using the good bios on one ROM, switch to the other ROM, write the new bios image to it using devbio, reboot and test. But the circuit is not substantially simpler than the ROM simulator. Cheers, Qiwei

1 0

New Code :-)
by Stefan Reinauer 13 Nov '98

13 Nov '98

Dear OpenBIOS readers, I had the time to have a closer look at Daniel Engstroems code now and I think we should use this as a code base for further developments. (Daniel, I hope, you allow this :>) I've played around a bit with the Makefiles and you can now configure the firmware setup by using make menuconfig or make config, like in the linux kernel. make xconfig doesn't work correctly right now, because I had to add some changes to the whole bunch of Linux configuration scripts to allow a more general usage. Get OpenBIOS 0.0.1 (completely based on Daniel's gfw-0.1) from http://www.freiburg.linux.de/OpenBIOS/ We only have support for 3 chipsets right now, which is definitely not enough. I will try to write support for the Intel 430HX/TX/VX/.. chipsets, as I have an old HX board at home. If anyone is capable of doing this (it's not really hard, as you just need the datasheets for your chipset and a board containing the chipset itself to test) I thought about building something like an eprom simulator which can be plugged into the bios socket of a board and to the parallel port of another computer which just holds a file with the bios image. This would make defelopment and testing *quite* faster. Has anyone experiences with this or does anyone know whether there are ready, cheap solutions for this? Now, at the moment, we don't have hardware drivers for any bootdevices. Should we go the way linux goes and write our own drivers or should we try to use other bioses (i.e. scsi bios on host adapter) for that? The second thing may be simpler and shorter, but I guess the first one is the way to go because we need drivers for floppies, parport devices etc, too.. :) Well.. I wrote this just to start discussion again :-) Best regards, Stefan. -- Sex is one of the nine reasons for reincarnation ... the other eight are unimportant. -- Henry Miller

1 0

Announce: a little peace of actual code
by daniel.engstrom＠riksnett.no 09 Nov '98

09 Nov '98

Hello! The last few weeks I have been experimenting with some boot up code, and I though some one might want to look at and/or play with it. It can boot, enter protected mode uncompress the main firmware and jump to it. I currently work on some RAM detection testing routines. my current stuff (as of before the weekend) can be downloaded from http://www.lillfab.se/gfw-0.1.tar.gz /Daniel -- ************ Daniel Engström Tech Support ************ * Lilla Fabriken in Norway * * Norway: Phone +47-69182030 Mobile +47-91606292 * * Sweden: Phone +46-8-286287 Fax +46-8-288802 * *********************************************************

2 1

EPROM/FLASH Memory writers?
by Qiwei Xiao 29 Oct '98

29 Oct '98

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

2 1

Re: Hello
by Simon Richter 27 Oct '98

27 Oct '98

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

2 1

Re: Hello
by Simon Richter 27 Oct '98

27 Oct '98

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

2 1

Re: IEEE1275
by daniel.engstrom＠riksnett.no 14 Oct '98

14 Oct '98

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/ --

1 0

Jump to page: