OpenBIOS February 2004

openbios@openbios.org

4 participants
9 discussions

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

05 Feb '04

* Peter Lister <prl(a)peterlister.co.uk> [040205 00:32]: > Digressing slightly, please note that Etherboot is more than just the > drivers - there is a significant amount of network code (now even TCP if > one wants it), and it would benefit us all to share as much as possible; > there is, for instance, an NFS client already. I agree! Etherboots features are really nice. > GRUB people now discuss "porting" Etherboot drivers, which is > disappointing (have a look at the GRUB support forum and FAQ to see > how little help there is on the network code compared to disk and fs). > It would have made far more sense to co-operate on an open firmware > network API, but hey ho... I'd like to see this happening fairly soon, > so that any driver created for Etherboot immediately works with GRUB. > So I encourage OpenBIOS to peacefully co-exist with GRUB and Etherboot > rather than fork which is not a good way to encourage driver writers. It was my initial goal when taking the grub filesystem drivers, to leave them completely untouched. Unfortunately this is only possible when staying with 32bit little endian architectures. So I started cleaning these drivers up. When things are done, I'll try to feed them back into grub, even though I doubt grub will ever make it to non-x86 hw. Well.. there's still hope for PUPA (http://www.nongnu.org/pupa/) and FILO ;-) OpenBIOS' goal is to provide a useful and simple API to driver writers and still allow reusing as much code as possible. Therefore it should coexist nicely with any other project ... Stefan

1 0

Re: OpenFirmware and interrupt-map
by ebiederman＠lnxi.com 05 Feb '04

05 Feb '04

Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> writes: > Stefan Reinauer wrote: > [...] > > 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 > > Actually, my understanding is that the multi-megabyte flash is only > required for the IA-64 implementation. The IA-32 implementation of EFI > from some vendors is reported to fit comfortably in 1MB. The EFI guys have been working really hard to get their footprint down. IA-64 native code gives you an automatic 3x code bloat so it trivially requires 3x more rom space. > One thing we've discovered recently is that the x86 firmware world > is rife in rumors, FUD, and propaganda. It's pretty startling. > > I've dropped the illusion of getting convinced some day that EFI is the > > way to go, > > It certainly looks good; they seem to have learned a bunch of > lessons from the OpenFirmware experience. Unfortunately, we > got stopped by license issues - to go any further than just the > basic spec, there is a "click to agree" license button on the > web page which our legal team told us not to click. They missed the simplicity part. But they did at least spec something that did not use interrupts. OF was not picked at least in part because they did not want to dilute ACPI. Eric

2 1

Re: OpenFirmware and interrupt-map
by ebiederman＠lnxi.com 05 Feb '04

05 Feb '04

Peter Lister <prl(a)peterlister.co.uk> writes: > On Wed, 2004-02-04 at 14:31, Stefan Reinauer wrote: > > > 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. > > Digressing slightly, please note that Etherboot is more than just the > drivers - there is a significant amount of network code (now even TCP if > one wants it), and it would benefit us all to share as much as possible; > there is, for instance, an NFS client already. Regardless the etherboot driver model and the open firmware driver model are essentially the same. (Independently derived though). The big difference is I believe OF drivers can have multiple cards working at once. > For some reason best known to themselves, the GRUB developers decided to > use only Etherboot's drivers and brew their own network code. The result > is that GRUB netboot is now lagging noticeably behind Etherboot in > functionality, drivers etc - GRUB people now discuss "porting" Etherboot > drivers, which is disappointing (have a look at the GRUB support forum > and FAQ to see how little help there is on the network code compared to > disk and fs). It would have made far more sense to co-operate on an open > firmware network API, but hey ho... I'd like to see this happening > fairly soon, so that any driver created for Etherboot immediately works > with GRUB. So I encourage OpenBIOS to peacefully co-exist with GRUB and > Etherboot rather than fork which is not a good way to encourage driver > writers. After seeing the GRUB code the amazing part is that it works. The problem is totally GRUB, the etherboot core is much more powerful. Some pieces of GRUB at the periphery are OK, like the FS drivers but the rest is not even worth thinking about. There is a reason GRUB has never been ported to run under LinuxBIOS. > BTW, there is work now on implementing PXE on top of Etherboot - > pxelinux has already been demonstrated on top of Etherboot. This may > force the issue somewhat, since even if PXE isn't the API one wants, it > will at least help focus people into deciding what APIs they *do* want. I've already implemented the API I do want. Open source and no callbacks. Eric

1 0

Re: OpenFirmware and interrupt-map
by ron minnich 04 Feb '04

04 Feb '04

On Wed, 4 Feb 2004, Tarl Neustaedter wrote: > Actually, my understanding is that the multi-megabyte flash is only > required for the IA-64 implementation. The IA-32 implementation of EFI > from some vendors is reported to fit comfortably in 1MB. that may change when people start to use it, not sure. Some of the Intel boards we got recently had really large flash parts. > One thing we've discovered recently is that the x86 firmware world > is rife in rumors, FUD, and propaganda. It's pretty startling. it's pretty weird. I've gotten all kinds of strange stuff from different places :-) > It certainly looks good; they seem to have learned a bunch of lessons > from the OpenFirmware experience. Unfortunately, we got stopped by > license issues - to go any further than just the basic spec, there is a > "click to agree" license button on the web page which our legal team > told us not to click. and that's the way it will stay, I'm told. I'm unhappy with a bios that needs CHKDSK in any event. ron

1 0

Re: OpenFirmware and interrupt-map
by ron minnich 04 Feb '04

04 Feb '04

On Wed, 4 Feb 2004, Stefan Reinauer wrote: > 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. I agree completely. It is sad that the generic solution so far is x86 instructions. We can hope this improves, but I am pessimistic. ron

1 0

bk openbios questions.
by Balint Cristian 04 Feb '04

04 Feb '04

Hi ! I played a little bit with today's bk tree, remarked that has lots of feauters and lots of intentions like ide driver. I use grub to play with, but remarked that there is a lot of dictionary, not only the "unix.dict" wich appeal from Makefile via "make run". My question is how can i load via grub all dictionaries, or more than one ? (or i ask stupid thing ?) My grub line --------------------////////---------------------------------> title openbios kernel (hd0,1)/boot/multiboot.image module (hd0,1)/boot/unix.dict ----------------------///////-------------------------------> My second question is how can i convince via grub that openbios to use framebuffer ? I try to make menuconfig and select qt plugin but only VGA console will appear no framebuffer, must pass some extra thing for that ? Thanks, cristian

2 1

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