OpenBIOS

openbios@openbios.org

4297 discussions

Re: [Fwd: Re: OpenFirmware and interrupt-map]
by Stefan Reinauer 04 Feb '04

04 Feb '04

* Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> [040204 01:05]: > >Interesting. The observation that powerful firmware eventually > >becomes an OS so you might as well use an OS, seems true :) > > One benefit we're hoping for is to not have to write multiple drivers > every time we go to a new technology (e.g., infiniband). Right now, > we're facing the possibility of needing to write a Solaris driver, > a Linux driver, an IEEE-1275 FCode driver, and a real-mode BIOS > driver. All for one technology, and with the probability of having > to repeat for the next i/o technology to come along, since we are > going forward with both SPARC and Opteron-based systems. > With LinuxBIOS, it looks like it should be possible to re-use > the Linux driver in the PROM. If so, it would mean that a new > platform based on a particular i/o technology could contain the > drivers for that particular technology (e.g., for Infiniband, > IPoIB and SRP drivers), and not have to worry about option ROMs. Infiniband is a technology that you won't find on expansion cards iirc, so it makes sense to include support in the firmware. But is the setup work you do in firmware really the same as what an operating system driver does? Many device option roms do a completely different job than the appropriate os device driver. As for graphics adapters, there is initialization code in the option rom, that initializes the onboard memory, sets an initial mode and allows some output. You won't get 3d acceleration on firmware level. OTOH, you won't get lowlevel initialization in most drivers. I haven't seen any sun opteron hardware, but it seems that this hardware could, from the os level, be handled very similar to the current sparc hardware when using a combination of LinuxBIOS and OpenBIOS. IEEE 1275 provides a good layer of abstraction while still having the powerful and open LinuxBIOS base that lets you reuse drivers and such. > I can believe it. My task right now is to determine if LinuxBIOS > is feasible, and if so, at what size. We have some flexibility in that > we design our own boards, so if we can justify a large PROM, we > could get it in. Better if we can fit it in a 1MB prom, however. Opteron systems need a lot more complex initialization than most other x86(-like) systems, but with 1MB / 8MBit you won't run into flash rom limits except adding lots of additional code. > A Sun video card comes with an OpenFirmware driver. That means that > Sun has either designed and built the card itself, or has signed a > deal with a vendor to re-sell their video cards after writing a driver > and putting it on the option ROM. The usual arrangement is that this > driver is still intellectual property of the video card vendor, so > that he can maintain secrecy on how to use his card. Don't know why. This reminds me a lot of the discussion I have had with vendors when talking about getting initialization code for LinuxBIOS/OpenBIOS. > To some extent, cards can be moved between Suns, Apples, IBM PowerPC > platforms and some HP systems, all of which use the IEEE 1275 standard. > Each implementation has slightly diverged from each other, and now that > the 1275 committee isn't meeting any more, quirks are tending cause > further divergence. With Hypertransport, Infiniband and other technologies, there might awake some demand for new supplements. Competing with EFI, Open Firmware should have at least recommendations on how to cope with this divergence (which is a natural fact looking at the number of contributors) > Note that an openfirmware video driver isn't particularly feature-rich. > It primarily provides a dumb scrolling ascii text window. There are > definitions for fancier capabilities (cursor positioning, color, > character insertion), but I've never seen anyone use them - or even > know if these capabilities work in our drivers. Are you talking about the CHRP Linear Frame Buffer Display Device Binding and the Recommended Practices for 16 Colors and 8bit Framebuffers? Best regards, Stefan Reinauer

1 0

Re: OpenFirmware and interrupt-map
by Stefan Reinauer 04 Feb '04

04 Feb '04

* ron minnich <rminnich(a)lanl.gov> [040203 22:46]: > I don't expect the cards to come with fcode any time soon, if ever. Four > reasons: first, the market is more or less zero, and the all the non-x86 > systems support x86 emulators to support the x86 option roms; second, > if they support two option roms (fcode, x86) that makes for lots more > work; third, the PC market will probably never go to fcode; and fourth, I > bet they (naively) think that fcode would make reverse engineering easier. I fully agree that using ndisasm is by no means more complicated than using my fcode detokenizer detok. All x86/efi option rom discussion sounds rather like a game of not stepping on the others' toes rather than technologically driven reasoning. OpenBIOS can be used on top of a PC BIOS as well, thus it could allow to use any Open Firmware compliant pci card in a machine that still has different firmware in rom. This is one step towards the great unification.. If the concept of having a diversity of hardware architectures available is going to survive, there has to be a generic solution to the early initialization issues. Best regards, Stefan Reinauer

1 0

Re: OpenFirmware and interrupt-map
by Stefan Reinauer 04 Feb '04

04 Feb '04

CCing the OpenBIOS mailinglist. * Eric W. Biederman <ebiederman(a)lnxi.com> [040203 20:07]: > Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> writes: > > > Eric W. Biederman wrote: > > > Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> writes: > > > > > >>If you have any specific questions about OpenFirmware, I'd be > > >>delighted to provide assistance. I've been doing IEEE 1275 since > > >>1996, and was at one time a voting member of that committee (since > > >>pretty much defunct). The specs are engraved upon my skull by now. :-) That is good to know. There will be a lot of things to clarify when the base implementation of OpenBIOS is complete and operable. > > The main problem is that cards don't usually come with IEEE 1275 FCode > > on them. We've pretty much had to write all of ours, and have gotten > > tired of it - we're actually looking at LinuxBIOS as a way to get > > out of that business, and just build in the drivers we care to in the > > Linux kernel on the prom. But I can answer questions any questions > > about writing FCode, it's most of what I've done in recent years. One big problem in the picture is that there is a certain amount of hardware that assumes firmware did a job before running the linux driver. So basically there is no real way around having an x86 option rom. It seems. Intel is trying to break out and move firmware developers to their EFI bytecode, which does the same thing OpenFirmware FCode does, just with the need of 4*8MBit Flash to store all of the virtual machine in (An OpenBIOS+LinuxBIOS solution easily fits in 2MBit) I've dropped the illusion of getting convinced some day that EFI is the way to go, but if there's a wave of change now anyway, it's high time for some educational advertising of using "long term industry proven standards" instead of KUAI-Implementations. I don't see it all that negative for FCode firmware in option roms. It's just not going to happen in small numbers. For this to happen, there have to be _many_many_many_ machines with an IEEE 1275 compliant boot firmware. Such a system could for example still use expansion cards with x86 pcbios compliant option roms - Generating the needed OpenFirmware wrapper nodes based on the device type (display, block, ... ) is no magic once the initialization of the device itself is done. This would allow to use such cards in an open firmware environment while the OS can rely on the fact that there is a device that can be operated using the Open Firmware interface. > Interesting. The observation that powerful firmware eventually > becomes an OS so you might as well use an OS, seems true :) If you use EFI, you even get all the old DOS tools. > The one problem with using Linux so far has been size constraints. > The primary interim solution has been to use etherboot. You have to > port the Linux drivers to it but it close enough you don't have to > rewrite them from scratch, and it is small. 16K-32K is typical with > one network driver and a IP stack. 128K when you build in all the > network drivers. OpenBIOS is currently only reusing filesystem drivers from grub, but an interface for network booting so that etherboot drivers can be used should not overtop the fs efforts a lot. > The location where option roms come into play in the pc world are > scsi adapters, raid controllers, and video. For scsi adapters and > raid controllers every case I have looked at the linux drivers are > good enough that you don't need the option roms. Video drivers are > still problematic. This is not true for many Opteron boards, ie those coming with the LSI 1020/1030 scsi controllers. There might be a fix for this on the horizon, but it only solves the problem for this specific controller. If there is a way to clean out these issues generically without having to think in terms of single controller or video cards, we should definitely provide this as an option. > How has sun coped with getting video drivers for high end video > cards. I know Apple seems to have succeeded in working with > NVIDIA. I suspect that is with open firmware side but I don't know. Apple succeeded by putting all of the actual driver code in a special property of the device node, and have the fcode rom not initialize the device but just create the device node. A good example of how _not_ to do it. Stefan

1 0

Bootloader
by Alex Owen 06 Jan '04

06 Jan '04

I have been watching this project from the early days and I'm impressed with the recient progress. This is probably old news but a quick search of the archives here did not show anything up. Yaboot. Yaboot is the bootloader used by owners of macintosh and other ppc machines with open firmware to boot linux from openfirmware. The home page seems to be http://penguinppc.org/projects/yaboot/ Perhaps when the time comes to boot an operating system with openbios yaboot and linux will be good candidates. Of course I may be completely off track! Bye for now Alex Owen

5 8

Dictionary Compression vs eXecute In Place
by Stefan Reinauer 20 Nov '03

20 Nov '03

Hi,. since the openbios dictionary is growing and growing as it becomes more complete, I've looked at different ways to optimize the dictionary handling. There's two methods of "safing" memory: compression and execute in place. 1) Compression Some numbers, taking 32bit dictionary (x86) method | size/bytes ---------------+------------- uncompressed | 62668 nrv2b | 22466 gzip | 20982 bzip2 | 19388 The current kernel is slightly below 8k (8172 bytes) * pro: small(er) flash parts can be used. * con: code has to be decompressed to memory first, higher memory usage. 2) XIP (eXecute In Place) If not compressing the dictionary, it could be changed so that all but the readwriteable data can be executed directly from ROM. This would decrease the use of RAM in embedded systems noticeably, but it is also slower on about every system. * pro: extremely low memory usage ( < code size) * con: slow execution. Looking at the amount of code this is about, (2) is pretty much neglectable for most systems whereas (1) is an interesting option. Comments? Stefan

2 1

Device Tree and FCode evaluator
by Stefan Reinauer 19 Nov '03

19 Nov '03

Hi, the current openbios cvs contains a lot of new code from the device interface. We have a device tree now and can evaluate FCode on device option ROMs. Now OpenBIOS lacks a whole lot of Open Firmware "support packages" like the deblocker, tftp booting for network interfaces, the terminal emulator, filesystem support, etc etc. And of course: OpenBIOS needs device drivers! Open Source drivers, vendor FCode, everything that helps OpenBIOS to support a wide range of hardware ;-) I started setting the framework for the support packages in openbios/forth/packages, find one source file per support package. Also, there's an example fcode driver coming with the QT-Plugin of the openbios kernel: openbios/kernel/plugins/plugin_qt/qt_rom.fs I'll attach a simple example to this mail that executes the QT Plugins FCode. To test it, do: ~/openbios $ make ~/openbios $ make rungui < device-example.fs It will use the FCode binary built into the plugin to initialize the virtual graphics hardware and output a character. Next thing I'm going to work on is to finish the terminal emulator and other support packages, then facing the client interface code to finally boot an operating system For the client interface it should make sense to reuse a lot of existing code, i.e filesystem drivers (GRUB), elf booting (Filo, LinuxBIOS), etc. by using the calling interfaces from forth to C and the other way round. Stefan

1 0

APIC 82489 datasheet
by fizjm＠univ.gda.pl 18 Nov '03

18 Nov '03

Hi all, Does anyone have a datasheet for APIC 82489 chip? I could not find it anywhere.. I understand that this chip is a replacement for I8259 used till now as an interrupt controller on a PC/AT. I would like to learn more, and to play with extra IRQs (IRQ15+) it provides. Most modern PC chipsets support this chip am I correct? Thanks for help. Janusz

2 1

Re: lib.fs missing in CVS
by Stefan Reinauer 10 Nov '03

10 Nov '03

Hi, good news. The fcode evaluator is working. init-fcode-table probably needs some work (table.fs) since iirc a child node should be able to see fcode words defined by the parent. At least byte-load now cleanly creates an fcode lookup table in alloc-mem'ed memory and frees it after evaluation which it did not do at all before. The verbosity of the fcode evaluator can be switched on/off with the value ?fcode-verbose. This also enables warnings about missing words during fcode table initialization. The latest code is in CVS. Test with following test-fcode.fs: ------------- 10 30 pci-l@ /n 8 = if 10 34 pci-l@ 20 << or then 0 byte-load bye ------------ After doing a make in the toplevel, do a make rungui < test-fcode.fs bye, Stefan

1 0

[PATCH] variable instatiation support
by Samuel Rydh 03 Nov '03

03 Nov '03

Hi, This patch adds variable instantiation support. It is intended to be used for device node instantiation. Some implementational details: - all template data is put into the dictionary. The thought behind this is to make it possible to put both methods and template data in a single wordlist. - instantiated variables are stored in a continuous block of memory (in contrast to the template data which is spread out in the dictionary). A small example file is also attached to this e-mail. Regards, /Samuiel

1 0

C bindings
by Samuel Rydh 31 Oct '03

31 Oct '03

Wouldn't it make sense to add some C-bindings to the forth kernel? I have examined all the built-in tokens and as far as far as I can tell there is currently no way to call an external function (well, save abusing the inb/outb mechanism). Some background: The forth kernel and the MOL OF loader are statically linked as a single binary (the ROM image). The MOL part of the code contains low-level support for exceptions and similar things. It also contains filesystem support, SCSI support, boot disk search algorithms, device tree handling and the OF client interface (and some other stuff). To make the C-code and the forth code interoperate, I would like to be able to 1. Call C-functions from forth code by pushing the address of the function on the stack. Something like call ( function_addr -- <whatever> ) 2. Be able to invoke the forth interpreter from C-code (I think this can be implementable without modifying the kernel code, but I haven't looked into it yet). I can of course solve the first point be adding a primitive to the words[] table, but wouldn't it make sense also for other projects? I imagine that a real-world implementation will implement some things in C (more people are familiar with C and there are already plenty of code written in C that can be reused; filesystems for instance...). /Samuel

2 6

Jump to page: