I guess, in this direction of development, you will most certainly have to implement more legacy BIOS services (realmode INTxx).
And, once SCSI BIOS worked, you automatically get INT13 (disk services) because SCSI BIOS hooks it. You already have INT10 (video services) by external VGA BIOS. Also you already have IDE and floppy drivers to implement your own INT13.
OTOH, loading first sector of first drive into 0x7c00 and jumping into it is an easy task, because you already have pieces of code to support it (realmode switching, bounce buffer, etc.)
So, will you add a few more legacy services to run LILO and bzImage directly from LinuxBIOS? Even more services to boot Windows? What do you think?
-- Takeshi
On Fri, 8 Aug 2003, SONE Takeshi wrote:
I guess, in this direction of development, you will most certainly have to implement more legacy BIOS services (realmode INTxx).
And, once SCSI BIOS worked, you automatically get INT13 (disk services) because SCSI BIOS hooks it. You already have INT10 (video services) by external VGA BIOS. Also you already have IDE and floppy drivers to implement your own INT13.
OTOH, loading first sector of first drive into 0x7c00 and jumping into it is an easy task, because you already have pieces of code to support it (realmode switching, bounce buffer, etc.)
So, will you add a few more legacy services to run LILO and bzImage directly from LinuxBIOS? Even more services to boot Windows? What do you think?
No one really wants LinuxBIOS to support legacy BIOS services. However, the need for them keeps creeping in (I believe Ron plans to add int15 to have better support for some vga roms). In the meantime, with a little hacking you can probably get LinuxBIOS working with Bochs BIOS to do the same job. Please see freebios/util/ADLO, it currently works for booting Windows 2000 on SiS630 boards with LinuxBIOS and you probably only need to make a few changes in loader.S to get it to work on your board too.
- Adam Agnew
Adam Agnew agnew@cs.umd.edu writes:
On Fri, 8 Aug 2003, SONE Takeshi wrote:
I guess, in this direction of development, you will most certainly have to implement more legacy BIOS services (realmode INTxx).
And, once SCSI BIOS worked, you automatically get INT13 (disk services) because SCSI BIOS hooks it. You already have INT10 (video services) by external VGA BIOS. Also you already have IDE and floppy drivers to implement your own INT13.
OTOH, loading first sector of first drive into 0x7c00 and jumping into it is an easy task, because you already have pieces of code to support it (realmode switching, bounce buffer, etc.)
So, will you add a few more legacy services to run LILO and bzImage directly from LinuxBIOS? Even more services to boot Windows? What do you think?
No one really wants LinuxBIOS to support legacy BIOS services. However, the need for them keeps creeping in (I believe Ron plans to add int15 to have better support for some vga roms). In the meantime, with a little hacking you can probably get LinuxBIOS working with Bochs BIOS to do the same job. Please see freebios/util/ADLO, it currently works for booting Windows 2000 on SiS630 boards with LinuxBIOS and you probably only need to make a few changes in loader.S to get it to work on your board too.
Given that Bochs BIOS aka ADLO works. That is solution for supporting binary only x86 options roms.
Nothing I have seen requires these things to be up terribly early, and without source we can't bring them up early anyway.
Other directions similar directions are OpenBIOS for Open firmware support. And at some point we might even do EFI support.
However none of this will get into the core of LinuxBIOS, they will all be separate ELF loadable components like etherboot.
The project will still work on them, but they are not components of the core.
To grow beyond a certain point support it is required to support legacy hardware, and hardware without open source drivers. But by no means do we want to encourage that kind of hardware.
The really fun prospect is to put general option ROM support into ADLO and have Etherboot as an Option ROM implementing the network boot support.
Legacy services are expedient.
Eric
On Thu, Aug 07, 2003 at 03:17:26PM -0600, Eric W. Biederman wrote:
Adam Agnew agnew@cs.umd.edu writes:
No one really wants LinuxBIOS to support legacy BIOS services. However, the need for them keeps creeping in (I believe Ron plans to add int15 to have better support for some vga roms). In the meantime, with a little hacking you can probably get LinuxBIOS working with Bochs BIOS to do the same job. Please see freebios/util/ADLO, it currently works for booting Windows 2000 on SiS630 boards with LinuxBIOS and you probably only need to make a few changes in loader.S to get it to work on your board too.
Given that Bochs BIOS aka ADLO works. That is solution for supporting binary only x86 options roms.
Nothing I have seen requires these things to be up terribly early, and without source we can't bring them up early anyway.
Other directions similar directions are OpenBIOS for Open firmware support. And at some point we might even do EFI support.
However none of this will get into the core of LinuxBIOS, they will all be separate ELF loadable components like etherboot.
The project will still work on them, but they are not components of the core.
I thought I would get comments like this.
So, we need an external program that provides legacy BIOS compatibility, like ADLO.
However, using Bochs BIOS as a base does not look very good idea to me. Adding more code to such a fragile piece of code is almost impossible to me. It's already broken in many ways when dealing with real hardware, for instance, IDE detection is wrong, it tries to probe device presence by writing and reading registers without checking BSY bit cleared. It's violation of ATA spec and that's why one of my drive is not detcted while spinning up. Bochs BIOS is all written this way since Bochs' emulated hard drives never spin up. Also, Bochs BIOS is providing deep level of compatibility, such as hardcoded entry points, and I guess they are unneeded to support option ROMs (and loading modern OS), they only contribute to make it hard to maintain.
OTOH, current VGABIOS support in LinuxBIOS can be extended in a lot cleaner way, since it's 32-bit GCC code.
So, my suggestion is to move the legacy BIOS support of LinuxBIOS to a new standalone ELF executable, and extend it to support general PCI option ROMs, and optionally IPL from first drive.
The really fun prospect is to put general option ROM support into ADLO and have Etherboot as an Option ROM implementing the network boot support.
Last time I tried ADLO->Etherboot worked. ADLO reserves 64KB for VGABIOS but my VGABIOS is 48KB and ide_disk.zrom is just 16KB so it was easy to have it there. Bochs BIOS already has code to find and call option ROMs when they are on memory already.
-- Takeshi
On Fri, 8 Aug 2003, SONE Takeshi wrote:
On Thu, Aug 07, 2003 at 03:17:26PM -0600, Eric W. Biederman wrote:
However none of this will get into the core of LinuxBIOS, they will all be separate ELF loadable components like etherboot.
So, we need an external program that provides legacy BIOS compatibility, like ADLO.
I don't have quite the same opinion on this one. I would like to have Linux in flash -- we do that now.
If I plug in the linux vga support, by boot path is simple.
Linuxbios->Linux
The VGA support code is very simple.
If I stick with this requirement that the VGA roms get supported by an external ELF piece, I have to do this:
linuxbios -> external ELF bit that does VGA ROMs -> some other bit that loads linux from flash -> linux
More and more pieces. ADLO is far more capability than I need. Therefore I intend to bring the VGA support forward to FreeBIOS2, based on my needs and comments from other linuxbios users.
I agree that in some sense it is "cleaner" to have VGA support in some external binary blob, but it is far more convenient to have it right in linuxbios itself. It works today, so I can't see strong reasons not to continue using it.
ron
If I stick with this requirement that the VGA roms get supported by an external ELF piece, I have to do this:
linuxbios -> external ELF bit that does VGA ROMs -> some other bit that loads linux from flash -> linux
I tend to agree with Sone that much of these functions should be seperated into ELFs, but I did so on the assumption that we had a framework to return to LinuxBIOS already. Is that still in the works? It seemed to me like a utility such as Steven James' Bare Metal Toolkit, which seeks out ELF images in ROM could then execute them in order:
linuxBIOS -> VGA Search and Init ROM ELF <- Back to linuxBIOS linuxBIOS -> Polled IDE & File Systems Support ELF Success: -> Linux Failure <- Back to LinuxBIOS LinuxBIOS -> Etherboot tftp boot ELF Success: -> Linux Failure <- Back to LinuxBIOS LinuxBIOS -> Last Ditch Effort Floppy Boot ELF Success: -> Linux Failure <- Back to LinuxBIOS LinuxBIOS out of options and says so.
All of that could fit in a 256KB part while providing several fallbacks and choices. And it still serves a purpose when EEPROMs are big and roomy, as tasks like a VGA Seek and Init ELF can perform their task without getting LB2 dirty before going to Linux. The complexity of returning to LB to then execute the next ELF image seems trivial next to maintaining polled ide, floppy, INT15, and all these other features right in LB.
Thanks for concideration before flames :)
- Adam Agnew
I guess I have a hard time seeing the difference between linking functions into LB via the static device tree, and calling ELFs, except that you get no space savings with the ELF approach. You're going to create printk etc. functions in every single ELF image, and in fact you'll have a whole "BIOS library" in each and every ELF iamge.
All things considered I'd rather link them in. I am very tight for space no the K8 with 1 MB flash, so growing things larger is not an option.
Now if we want to have a way to choose seperate ELF payloads or direct linking them in at build time, that makes lots of sense to me. We can try to look at that.
ron
ron minnich rminnich@lanl.gov writes:
I guess I have a hard time seeing the difference between linking functions into LB via the static device tree, and calling ELFs, except that you get no space savings with the ELF approach. You're going to create printk etc. functions in every single ELF image, and in fact you'll have a whole "BIOS library" in each and every ELF iamge.
Possibly. But that library can be made very small. printk is a fairly trivial function. At least when you are talking the serial console.
All things considered I'd rather link them in. I am very tight for space no the K8 with 1 MB flash, so growing things larger is not an option.
And this is a real issue that will drive a lot of this. The standard flash on the K8's I have seen is 512K.
Now if we want to have a way to choose seperate ELF payloads or direct linking them in at build time, that makes lots of sense to me. We can try to look at that.
I am not certain about multiple payloads.
But beyond that having etherboot separate has proved very valuable.
1) It totally separates the chipset initialization from booting. 2) It allows usage of a known good etherboot on a development platform.
And only by reusing binaries does this work so well.
As for space constraints once I get romcc fixed to not inline everything Opteron LinuxBIOS should get as small as the rest of them.
Taking boot loaders to the next step is a very interesting question. For the normal case where traditional BIOS's work ADLO looks to be a very satisfying solution. For the HPC side this are much trickier.
For things to think about. The reason traditional BIOS's are 16bit real mode beasts is because Windows runs parts of them in vm86 mode. Which is why 32bit extensions are not common.
Eric
On 8 Aug 2003, Eric W. Biederman wrote:
But beyond that having etherboot separate has proved very valuable.
agree. In general, having "THE PAYLOAD" separate is a good deal. I would not want to link, e.g., 9load into linuxbios, and I can't even build those two on the same system.
My doubts concern the multiple payload scenario.
ron
On Fri, Aug 08, 2003 at 10:51:23AM -0600, Eric W. Biederman wrote:
Now if we want to have a way to choose seperate ELF payloads or direct linking them in at build time, that makes lots of sense to me. We can try to look at that.
I am not certain about multiple payloads.
I've seen there is no way to ensure images to not overwrite each other. When LinuxBIOS loads ELF image at the same location as itself, it moves itself to top of memory (below 4GB). Etherboot (>=5.1) relocates itself to the same top memory, since it is usually safe place when loading kernel. Other future bootloaders would do the same.
Probably this could be resolved by indicating LinuxBIOS's location in the memory map of LinuxBIOS table?
Taking boot loaders to the next step is a very interesting question. For the normal case where traditional BIOS's work ADLO looks to be a very satisfying solution.
If ADLO works at all.
For things to think about. The reason traditional BIOS's are 16bit real mode beasts is because Windows runs parts of them in vm86 mode. Which is why 32bit extensions are not common.
I've been thinking about the same thing. I guess you refer to the DOS-based Windows (-95/98/Me). Of couse the DOS applications like EMM386 and things like DPMI won't run with a BIOS which does it's job in 32-bit. And nowadays nobody uses those application.
Open source applications I've seen so far (setup of Linux, GRUB, Etherboot, LILO...) are calling BIOS from pure real mode, so they won't notice if the BIOS services they are calling are in fact 32-bit code. I'm not sure but I guess NT-based Windows and its bootloader are like Linux and its bootloaders.
If we cut off some of lagacy applications, we can implement a clean 32-bit minimum legacy layer.
SONE Takeshi ts1@tsn.or.jp writes:
On Fri, Aug 08, 2003 at 10:51:23AM -0600, Eric W. Biederman wrote:
Now if we want to have a way to choose seperate ELF payloads or direct linking them in at build time, that makes lots of sense to me. We can try to look at that.
I am not certain about multiple payloads.
I've seen there is no way to ensure images to not overwrite each other. When LinuxBIOS loads ELF image at the same location as itself, it moves itself to top of memory (below 4GB). Etherboot (>=5.1) relocates itself to the same top memory, since it is usually safe place when loading kernel. Other future bootloaders would do the same.
Probably this could be resolved by indicating LinuxBIOS's location in the memory map of LinuxBIOS table?
Yes that would resolve the problem.
Taking boot loaders to the next step is a very interesting question. For the normal case where traditional BIOS's work ADLO looks to be a very satisfying solution.
If ADLO works at all.
True. ADLO is not quite ready to handle that yet.
For things to think about. The reason traditional BIOS's are 16bit real mode beasts is because Windows runs parts of them in vm86 mode. Which is why 32bit extensions are not common.
I've been thinking about the same thing. I guess you refer to the DOS-based Windows (-95/98/Me).
Correct.
Of couse the DOS applications like EMM386 and things like DPMI won't run with a BIOS which does it's job in 32-bit. And nowadays nobody uses those application.
Dosemu which uses DPMI still has a surprising number of users.
So while I don't think it is absolutely mandatory to support that kind of think I think it is worth considering very carefully.
I believe FreeBSD also does BIOS calls from vm86 mode.
Open source applications I've seen so far (setup of Linux, GRUB, Etherboot, LILO...) are calling BIOS from pure real mode, so they won't notice if the BIOS services they are calling are in fact 32-bit code. I'm not sure but I guess NT-based Windows and its bootloader are like Linux and its bootloaders.
Possibly.
If we cut off some of lagacy applications, we can implement a clean 32-bit minimum legacy layer.
That is a hard question. Remember thought that we have 256KB to work with. So it may not be too bad. Traditional BIOS services are pretty stupid.
I guess my preference would be to make a 16bit clean core that supports option ROMS and those options roms could be like etherboot and do the extension.
Also of course we can put all of the 32bit entry points in high memory.
By and large I want to support as many legacy uses as we can. That allows use to be a complete replacement for AMI, and Phoenix.
Eric
On Fri, Aug 08, 2003 at 01:51:16PM -0600, Eric W. Biederman wrote:
Of couse the DOS applications like EMM386 and things like DPMI won't run with a BIOS which does it's job in 32-bit. And nowadays nobody uses those application.
Dosemu which uses DPMI still has a surprising number of users.
I thought dosemu emulates all the BIOS calls itself, and never calls the underlying real BIOS.
I guess my preference would be to make a 16bit clean core that supports option ROMS and those options roms could be like etherboot and do the extension.
In my opinion, 16-bit code is never clean. :) (except the case everything is in 64KB)
Even if using GCC with .code16gcc to make a realmode code, the compiler knows nothing about segmentation, 64KB barrier... so we have to take care of segments in all over the code. "Flat real mode" (setting segment limits to 4G) is out of question because it will not run in vm86 either.
-- Takeshi
Greetings,
I solved that for payloads built from the baremetal toolkit. They create a simple data structure at the top of RAM with a signature in it so that the first payload to run will know to set it up.
Each payload is expected to take what it needs from the top of available memory and alter the structure to reflect the new top of available memory. Upon exit, the old value is written back to release the memory.
A 'terminal' target such as linux ignores the structure since it will never return anyway.
G'day, sjames
On Sat, 9 Aug 2003, SONE Takeshi wrote:
On Fri, Aug 08, 2003 at 10:51:23AM -0600, Eric W. Biederman wrote:
Now if we want to have a way to choose seperate ELF payloads or direct linking them in at build time, that makes lots of sense to me. We can try to look at that.
I am not certain about multiple payloads.
I've seen there is no way to ensure images to not overwrite each other. When LinuxBIOS loads ELF image at the same location as itself, it moves itself to top of memory (below 4GB). Etherboot (>=5.1) relocates itself to the same top memory, since it is usually safe place when loading kernel. Other future bootloaders would do the same.
Probably this could be resolved by indicating LinuxBIOS's location in the memory map of LinuxBIOS table?
Taking boot loaders to the next step is a very interesting question. For the normal case where traditional BIOS's work ADLO looks to be a very satisfying solution.
If ADLO works at all.
For things to think about. The reason traditional BIOS's are 16bit real mode beasts is because Windows runs parts of them in vm86 mode. Which is why 32bit extensions are not common.
I've been thinking about the same thing. I guess you refer to the DOS-based Windows (-95/98/Me). Of couse the DOS applications like EMM386 and things like DPMI won't run with a BIOS which does it's job in 32-bit. And nowadays nobody uses those application.
Open source applications I've seen so far (setup of Linux, GRUB, Etherboot, LILO...) are calling BIOS from pure real mode, so they won't notice if the BIOS services they are calling are in fact 32-bit code. I'm not sure but I guess NT-based Windows and its bootloader are like Linux and its bootloaders.
If we cut off some of lagacy applications, we can implement a clean 32-bit minimum legacy layer.
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Could I trouble the list, and you three gentleman in particular, for a list of E7501 motherboards which have worked for you? It would really help me out so that I don't have to figure out what exactly is wrong with this SuperMicro X5DPL-iGM in a short amount of time, as any E7501 working would do. Thanks!
- Adam Agnew
Greetings,
The clearwater itself (se7501cw2), Tyan (s2723 I believe) Several of the Supermicro X5dpr and x5dpe It looks like the new Superio on the DPL is the real problem there.
G'day, sjames
On Fri, 8 Aug 2003, Adam Agnew wrote:
Could I trouble the list, and you three gentleman in particular, for a list of E7501 motherboards which have worked for you? It would really help me out so that I don't have to figure out what exactly is wrong with this SuperMicro X5DPL-iGM in a short amount of time, as any E7501 working would do. Thanks!
- Adam Agnew
On Fri, 8 Aug 2003, Adam Agnew wrote:
Could I trouble the list, and you three gentleman in particular, for a list of E7501 motherboards which have worked for you? It would really help me out so that I don't have to figure out what exactly is wrong with this SuperMicro X5DPL-iGM in a short amount of time, as any E7501 working would do. Thanks!
The trouble we've just found with the X5DAE is that something else is needed to enable SPD. It appears that it's not just the GPIO2 on the superio. I am hoping supermicro will tell me what. It's even possible that they're not using the Intel ICH4 for SMBUS at this point, but are using the superio; we just can't tell.
ron
On Fri, 8 Aug 2003, Adam Agnew wrote:
for example;
linuxBIOS -> VGA Search and Init ROM ELF
with its own printk, etc?
<- Back to linuxBIOS linuxBIOS ->
with its own printk, etc?
Polled IDE & File Systems Support ELF
Success: -> Linux Failure <- Back to LinuxBIOS LinuxBIOS ->
with its own printk, etc?
Etherboot tftp boot ELF Success: -> Linux Failure <- Back to LinuxBIOS LinuxBIOS ->
with its own printk, etc?
Last Ditch Effort Floppy Boot ELF
with its own printk, etc?
Success: -> Linux Failure <- Back to LinuxBIOS
I just don't see this as the best approach. If we're going to have some flexibilty in boot modules, why not just compile them in in a flexible way, as opposed to building them all separately? What's the advantage?
ron
On Fri, Aug 08, 2003 at 08:28:34AM -0600, ron minnich wrote:
I agree that in some sense it is "cleaner" to have VGA support in some external binary blob, but it is far more convenient to have it right in linuxbios itself. It works today, so I can't see strong reasons not to continue using it.
Then it's convenient to have a few more INTs and generic PCI ROM enabling routine to enable the SCSI adapter. That code would be simple and small anyway. Then, at this point, why not adding a simple code to load IPL and jumping it in real mode? It's smaller than a printk.
On Sat, 9 Aug 2003, SONE Takeshi wrote:
Then it's convenient to have a few more INTs and generic PCI ROM enabling routine to enable the SCSI adapter. That code would be simple and small anyway.
It doesn't bother me. I am fine with it. I believe that the VGA BIOS support can be used for this as well, with very little extra work.
Then, at this point, why not adding a simple code to load IPL and jumping it in real mode? It's smaller than a printk.
Sure.
Eric is concerned that it not be in the "core". I am willing to call it a compiled-in extension if everyone is ok with that. We could have a src/extensions directory, and put items such as the VGA BIOS support etc. in there. Such extensions have to be explicitly enabled. The static device mechanism gives us an easy way to hook into them.
But for reasons of space at least, I would really like to keep the ability to compile VGA BIOS support directly into linuxbios. The ELF chaining that Adam mentioned, while interesting, is complex enough to worry me.
Takeshi did I apply your last patch to VGA BIOS support? Can you check?
thanks
ron
ron minnich rminnich@lanl.gov writes:
On Sat, 9 Aug 2003, SONE Takeshi wrote:
Then it's convenient to have a few more INTs and generic PCI ROM enabling routine to enable the SCSI adapter. That code would be simple and small anyway.
It doesn't bother me. I am fine with it. I believe that the VGA BIOS support can be used for this as well, with very little extra work.
Several bugs fixes later and we have put the Bochs BIOS into LinuxBIOS. Which doesn't work on anything but x86....
Then, at this point, why not adding a simple code to load IPL and jumping it in real mode? It's smaller than a printk.
Sure.
Eric is concerned that it not be in the "core".
I am concerned in large part with feature creep and future maintainability. I drew a line in the sand so we can see when we are going over it and are close to being in trouble.
In the core we don't drive the hardware we initialize the hardware. We only drive the hardware that is needed to initialize other parts.
I am willing to call it a compiled-in extension if everyone is ok with that. We could have a src/extensions directory, and put items such as the VGA BIOS support etc. in there. Such extensions have to be explicitly enabled. The static device mechanism gives us an easy way to hook into them.
It might be possible to convince me. But doing it because it is most convenient this way is not one I like.
But for reasons of space at least, I would really like to keep the ability to compile VGA BIOS support directly into linuxbios. The ELF chaining that Adam mentioned, while interesting, is complex enough to worry me.
And why can't you do this a kernel patch for your magic kernel bootloader?
Takeshi did I apply your last patch to VGA BIOS support? Can you check?
Eric
On 8 Aug 2003, Eric W. Biederman wrote:
Several bugs fixes later and we have put the Bochs BIOS into LinuxBIOS. Which doesn't work on anything but x86....
I take your point, but is there any harm done if this is packaged as an extension, not a part of the core? I just can't see the harm in it. It lies somewhere between ELF modules and integration into the core.
I am concerned in large part with feature creep and future maintainability. I drew a line in the sand so we can see when we are going over it and are close to being in trouble.
No problem.
In the core we don't drive the hardware we initialize the hardware. We only drive the hardware that is needed to initialize other parts.
Yep, but that means we still actually do drive the hardware in some cases. We do that because Linux can't do it, or because we should do it in one place, not in every payload.
The problem is the complete lack of vga support is a common complaint I hear all the time. I'd like to resolve that complaint in a simple way. Bochs is neat, but not simple. Maybe, however, we can make it simpler. I really don't want to write x86 asm at this point, however. If I do this I want to do it by building on the VGA BIOS stuff I wrote for 1.0.
The VGA BIOS code in 1.0 has proven to be pretty easy to use for people, it's 32-bit code, and it's pretty easy to fix. Also, like the rest of LinuxBIOS, it has a very small assembly bit and the rest is C.
I think chain-loading ELF modules or calling multiple ELF modules is a harder, more complex, harder to build, and less efficient way to go.
And why can't you do this a kernel patch for your magic kernel bootloader?
yes, that's an interesting idea. I can do it for Linux. If we use Linux as the bootloader we're ok. But if people want 9load or plan 9 in there, then I have to do it over again for them. It's not just a linux world.
As it happens, I just found out that Plan 9 can boot Plan 9, so Plan 9 in the FLASH is not at all unrealistic. And I already have 9load in flash, and VGA support would be very nice.
ron
On Fri, Aug 08, 2003 at 03:23:42PM -0600, ron minnich wrote:
Bochs is neat, but not simple. Maybe, however, we can make it simpler. I really don't want to write x86 asm at this point, however. If I do this I want to do it by building on the VGA BIOS stuff I wrote for 1.0.
That's what I'm intersted in doing. Also I felt that doing this in LinuxBIOS core could be wrong direction for the project, so I posted the first question. I think Ron's src/extension idea makes a lot of sense.
The VGA BIOS code in 1.0 has proven to be pretty easy to use for people, it's 32-bit code, and it's pretty easy to fix. Also, like the rest of LinuxBIOS, it has a very small assembly bit and the rest is C.
Yes, that is why I like this code. This can be easily and cleanly extended, unlike Bochs BIOS. As Eric pointed out, this approach has drawbacks, with regard to full compatibility, it still has many advantages over the way Bochs doing. -- Takeshi
* SONE Takeshi ts1@tsn.or.jp [030809 19:40]:
On Fri, Aug 08, 2003 at 03:23:42PM -0600, ron minnich wrote:
Bochs is neat, but not simple. Maybe, however, we can make it simpler. I really don't want to write x86 asm at this point, however. If I do this I want to do it by building on the VGA BIOS stuff I wrote for 1.0.
That's what I'm intersted in doing. Also I felt that doing this in LinuxBIOS core could be wrong direction for the project, so I posted the first question. I think Ron's src/extension idea makes a lot of sense.
going all the way to the end this could mean that the elf loader goes to the extensions directory as well, reducing the LinuxBIOS kernel to three parts: * Assembler starter: switching to protected mode * romcc code: initializing ram controller and starting LinuxBIOS C payload * gcc code: initializing static and dynamic devices so that they can be used by the extensions
Extensions could be "stackable" and configurable for certain application goals: * legacy emulation for VGA and SCSI init * elf loader * openbios kernel
My OpenBIOS multiboot kernel is currently 6.6k big, implementing all forth primitives needed to build an Open Firmware implementation on top of it. It includes a small console implementation for serial and vga.
The extensions idea could integrate this kernel sanely and even reduce the code as the interface to LinuxBIOS and the console code could be dropped.
The VGA BIOS code in 1.0 has proven to be pretty easy to use for people, it's 32-bit code, and it's pretty easy to fix. Also, like the rest of LinuxBIOS, it has a very small assembly bit and the rest is C.
Yes, that is why I like this code. This can be easily and cleanly extended, unlike Bochs BIOS. As Eric pointed out, this approach has drawbacks, with regard to full compatibility, it still has many advantages over the way Bochs doing.
On the other hand, it has certain advantages as well, the code can probably easier integrate an x86 emulation, like milo/srm do on alpha and some free ARM firmware implementation does as well..
Stefan
On Sat, Aug 09, 2003 at 08:26:55PM +0200, Stefan Reinauer wrote:
Extensions could be "stackable" and configurable for certain application goals:
- legacy emulation for VGA and SCSI init
- elf loader
- openbios kernel
Something like splash image support could be in the extension. I have one for VESA SVGA but it's a too strange thing to be in the core. I know supercomputer guys will hate it, but I believe some kinds of embedded systems will need it. It will be displayed ealier than disk spin up.
I also developed a standalone bootloader, by putting together the IDE driver from Etherboot 5.1 and filesystem code from GRUB, with keyboard (as well as serial) support and a simple line input routine to boot arbitrary ELF files in the filesystem of disk. It's an ELF image for now, but could be ported to LinuxBIOS, then I can save space for printk etc.
On the other hand, it has certain advantages as well, the code can probably easier integrate an x86 emulation, like milo/srm do on alpha and some free ARM firmware implementation does as well..
I'm totally ignorant about non-x86 architecture, but it sounds cool.
-- Takeshi
so, in the config file, we have something like:
extension pcbios extension vgabios extension elfboot
and the system linkes these in via src/extionsions/whatever.
They are each run in turn.
reasonable?
ron
At 6:04 PM -0600 10/8/03, ron minnich wrote:
so, in the config file, we have something like:
extension pcbios extension vgabios extension elfboot
and the system linkes these in via src/extionsions/whatever.
They are each run in turn.
reasonable?
Sounds good, but what does the 'extension' keyword actually do? Is there stuff that needs to be called early on, then after elfboot? Or can it all be done after elfboot?
Greg
ron minnich rminnich@lanl.gov writes:
so, in the config file, we have something like:
extension pcbios extension vgabios extension elfboot
and the system linkes these in via src/extionsions/whatever.
They are each run in turn.
reasonable?
Not really.
I haven't seen the numbers on the dreaded size overhead. So that argument does not yet convince me. If I can fit a whole IP/UDP stack a network driver, and printk in 16K I have trouble seeing the problem.
Most of the things proposed so far are things I am primarily opposed to, at least except way out on the periphery. Callbacks are bad. Binary only code is bad. Maintenance would be a pain, and we have not even succeeded in doing a single stable release off of either of our public trees yet.
I would much rather see these things prototyped with something like Steve James bare metal tool kit. We can easily open another tree just for that up on sourceforge, like we did with the freebios2 tree.
And the biggest reason I don't want to go there is because simple things tend to be reliable. And complex things tend to broken. And the extension extension looks to allow a lot of needless complexity into LinuxBIOS.
Also the problems being solved with the extension mechanism are vary different from what is solved with the core of LinuxBIOS so there are very different evolutionary pressures. And there are a different group of people working on those problems, and the evolution happens at different rates.
I am not opposed to solving those problems, not even expediently. But I don't want a solution in the public tree that causes maintenance problems.
My mind can be changed, but I need to see a good reason to do this. The biggest piece of code everyone has been arguing for including, the code to run a vgabios option rom, simply doesn't work in a lot of cases, and unless I have overlooked something the reason it doesn't work in a lot of cases is a design flaw, it doesn't aim for complete pcbios compliance.
Eric
On 10 Aug 2003, Eric W. Biederman wrote:
I haven't seen the numbers on the dreaded size overhead. So that argument does not yet convince me. If I can fit a whole IP/UDP stack a network driver, and printk in 16K I have trouble seeing the problem.
multiply that by, let's just say 4, for 4 elf payloads for 4 functions. At that point, I can no longer fit a kernel + linuxbios in 1 MB flash. At present I can barely fit one linuxbios + 1 stripped kernel.
I am right on the edge of being able to fit right now. Either I statically link in the VGABIOS code or I can't fit it. That's the issue for me.
Yes, I am well aware that we hope to have more compact ROMCC code, but that is not there right now.
Most of the things proposed so far are things I am primarily opposed to, at least except way out on the periphery. Callbacks are bad.
Callbacks are required if we hope to support VGA. There is no way around this.
Binary only code is bad.
Binary code support is required for future chipsets that, e.g., build wireless into the chipset. There will be many future software radios that are in chipsets, and you will not be able to get that in open source -- the FCC has a few things to say about that. Binary code support is inevitable. We won't be able to compile this code in, or build it as an ELF module. That's not going to be an option.
For linuxbios to succeed in future, we'll need support for these two things. I think this is a lamentable state of affairs. But that's how it is.
I think long-term the best way to fix it for all architectures is via emulation, but for the immediate-term we can make callback/binary support for the common(-est) case: the x86.
And the biggest reason I don't want to go there is because simple things tend to be reliable. And complex things tend to broken. And the extension extension looks to allow a lot of needless complexity into LinuxBIOS.
But the limits of poor PC design limit our ability to be simple. The original LinuxBIOS idea -- "Let Linux do it" -- was simple. We have found we need a bit more than that to be workable.
The single most common request I hear for LinuxBIOS is early VGA support -- early enough to see linuxbios messages. You have no idea how often this comes up -- or maybe you do :-)
I think we're going to need to do this in a reasonable way, or somebody will do it for us in an unreasonable way.
The biggest piece of code everyone has been arguing for including, the code to run a vgabios option rom, simply doesn't work in a lot of cases, and unless I have overlooked something the reason it doesn't work in a lot of cases is a design flaw, it doesn't aim for complete pcbios compliance.
That's a factor of time people have had to work on it. The code itself, I am told, has proven to be pretty solid for those operations it supports.
It's possible, the more I think of it, that what we really need is a payload for solid x86 emulation. That would buy us architecture-independence which we need. No callbacks either -- just emulate the trap and do the code for the callback. Much more reliable than callbacks. Very portable.
Still thinking .... more discussion welcome.
ron
Hi,
I haven't seen the numbers on the dreaded size overhead. So that argument does not yet convince me. If I can fit a whole IP/UDP stack a network driver, and printk in 16K I have trouble seeing the problem.
multiply that by, let's just say 4, for 4 elf payloads for 4 functions. At that point, I can no longer fit a kernel + linuxbios in 1 MB flash. At present I can barely fit one linuxbios + 1 stripped kernel. I am right on the edge of being able to fit right now. Either I statically link in the VGABIOS code or I can't fit it. That's the issue for me. Yes, I am well aware that we hope to have more compact ROMCC code, but that is not there right now.
Maybe we can separate LinuxBIOS into 2 parts. The first part contains the core of LinuxBIOS, and the second part contains different extensions for different archs and elf loader at the end. We could have something like the following in the config which is pretty much like Ron suggested before
extension1 extension2 extension3 elfloader ide usb net
-Andrew
Andrew Ip aip@cwlinux.com writes:
Hi,
I haven't seen the numbers on the dreaded size overhead. So that argument does not yet convince me. If I can fit a whole IP/UDP stack a network driver, and printk in 16K I have trouble seeing the problem.
multiply that by, let's just say 4, for 4 elf payloads for 4 functions. At that point, I can no longer fit a kernel + linuxbios in 1 MB flash. At present I can barely fit one linuxbios + 1 stripped kernel. I am right on the edge of being able to fit right now. Either I statically link in the VGABIOS code or I can't fit it. That's the issue for me. Yes, I am well aware that we hope to have more compact ROMCC code, but that is not there right now.
Maybe we can separate LinuxBIOS into 2 parts. The first part contains the core of LinuxBIOS, and the second part contains different extensions for different archs and elf loader at the end. We could have something like the following in the config which is pretty much like Ron suggested
We already have LinuxBIOS separated into 2 parts, and the ELF loader is the glue between them. What we don't have is a good second part to hold the Video code, and other random hacks. Except for possibly Steve James bare metal toolkit.
Eric
On Mon, 11 Aug 2003, ron minnich wrote:
For linuxbios to succeed in future, we'll need support for these two things. I think this is a lamentable state of affairs. But that's how it is.
I think long-term the best way to fix it for all architectures is via emulation, but for the immediate-term we can make callback/binary support for the common(-est) case: the x86.
I contradict myself. Either we need callbacks or we don't. If we get emulation, we don't need them. Sorry for my confusing note.
Eric, I am sympathy with what you are saying. There is a reality here -- people want VGA and they want it on early. I want to accomodate this.
Is emulation a suitable, architecture-independent way to achieve this? I'm thinking it might be. Can we then build it in as an option when we build a linuxbios?
thanks
ron
Eric, I am sympathy with what you are saying. There is a reality here -- people want VGA and they want it on early. I want to accomodate this.
ron
There is always the direct register programming approach that we have for the sis630 and stpc, but in the case of the sis630, vga is not available immediately due to the PCI init not done yet. Right after PCI init, it comes on. I suspect this just a few bits in some bridge registers, but I have not cared enough to go look. The stpc is immediate.
Most if not all of the chips and cards support the legacy registers for text mode. But there are always a few magic registers that need to be setup to enable legacy mode, and when you don't have the docs, it means reverse engineering the BIOS.
I do this quite a bit with the IDA disassembler (comm'l product on Windows from datarescue), and it is not so difficult, but very time consuming. And right now I am very busy.
So in the end the most expedient way to get VGA is with the BIOS calls and a binary.
I will someday get to more work on VGA disassembly, it is a hobby, some people play chess, I disassemble BIOSes.
So how many requests do you get for direct booting vmlinuz.gz from IDE (linux fs compatible ala grub or lilo)?
-Steve
On Mon, 11 Aug 2003, Steve Gehlbach wrote:
I will someday get to more work on VGA disassembly, it is a hobby, some people play chess, I disassemble BIOSes.
we can't use that code, however, or some idiot will decide to sue.
we don't ever use code based on disassembly.
So how many requests do you get for direct booting vmlinuz.gz from IDE (linux fs compatible ala grub or lilo)?
A fair number ...
ron
ron minnich wrote:
we can't use that code, however, or some idiot will decide to sue.
we don't ever use code based on disassembly.
I understand, although they would lose the suit (Sony v. Connectix and related cases), it is not the kind of trouble we need. Would that idiot be named SCO?
I amend my statement. I use my oscilloscope and logic analyzer to determine the register numbers and settings.
Anyhow, I never use the code in any fashion or form, only register numbers and bit settings. The actual code is useless, it is 16-bit, you might catch a bad disease (urge to write spaghetti code or something) if you copy 16-bit code. I write a spec, then use the spec to write the code.
Where did the VGABIOS code come from (the binary thing we are talking about)?
-Steve
PS: I am a pretty big student of title 17 (US copyright law) and the DMCA portion (chapter 12). But so is IBM and they got sued. So lawsuits happens no matter what you do, it happens with probability one when the $$ get big.
On Mon, 11 Aug 2003, Steve Gehlbach wrote:
Where did the VGABIOS code come from (the binary thing we are talking about)?
??
which one.
ron
ron minnich wrote:
Where did the VGABIOS code come from (the binary thing we are talking about)?
which one.
The point was, is it a proprietary BIOS from a mfr of the video/motherboard? I got the impression we were talking of copying a binary into the project, and wanted to know if it was a copyrighted and proprietary work. Or did I miss the point? The issue is that just because you bought the board doesn't mean you have the right to copy the BIOS code, unless the mfr is specifically giving us the license to do that.
-Steve
On Mon, 11 Aug 2003, Steve Gehlbach wrote:
The point was, is it a proprietary BIOS from a mfr of the video/motherboard? I got the impression we were talking of copying a binary into the project, and wanted to know if it was a copyrighted and proprietary work. Or did I miss the point?
you missed the point. We will never copy a vga bios into the tree in any place unless given permission.
The issue is that just because you bought the board doesn't mean you have the right to copy the BIOS code, unless the mfr is specifically giving us the license to do that.
Fair use says, I think, that you can copy a bios from your machine to your machine for personal use. Certainly that's what you do when you load a new bios image from a web site. You can't distribute it. So ADLO supports getting the VGA bios out of your on-card bios and building it into linuxbios. That's how it is done: copy it from your machine to your machine.
VGABIOS, on the other hand, just finds the on-card bios and runs it.
ron
ron minnich wrote:
Fair use says, I think, that you can copy a bios from your machine to your machine for personal use. Certainly that's what you do when you load a new bios image from a web site. You can't distribute it. So ADLO supports getting the VGA bios out of your on-card bios and building it into linuxbios. That's how it is done: copy it from your machine to your machine.
VGABIOS, on the other hand, just finds the on-card bios and runs it.
Does this mean that VGABIOS would not work for boards that have integrated video and have the video BIOS combined into the system BIOS?
Bari
On Mon, 11 Aug 2003, Bari Ari wrote:
Does this mean that VGABIOS would not work for boards that have integrated video and have the video BIOS combined into the system BIOS?
Currently, it means it won't work, but that is pretty straightforward to fix.
ron
For integrated chipsets, I think you have to go the ADLO way. The space for integrated BIOS is very tight (256KB for System + VGA instead of System along) such that it is a common practice to make VGA BIOS as a compressed "payload" of System BIOS. The only thing knows where and how to uncompress the VGA BIOS part is the System BIOS.
----- Original Message ----- From: "Bari Ari" bari@onelabs.com To: "ron minnich" rminnich@lanl.gov Cc: "Steve Gehlbach" steve@nexpath.com; "Eric W. Biederman" ebiederman@lnxi.com; "SONE Takeshi" ts1@tsn.or.jp; "Stefan Reinauer" stepan@suse.de; linuxbios@clustermatic.org Sent: Tuesday, August 12, 2003 7:41 AM Subject: Re: Supporting extension ROMs and beyond...
ron minnich wrote:
Fair use says, I think, that you can copy a bios from your machine to
your
machine for personal use. Certainly that's what you do when you load a
new
bios image from a web site. You can't distribute it. So ADLO supports getting the VGA bios out of your on-card bios and building it into linuxbios. That's how it is done: copy it from your machine to your machine.
VGABIOS, on the other hand, just finds the on-card bios and runs it.
Does this mean that VGABIOS would not work for boards that have integrated video and have the video BIOS combined into the system BIOS?
Bari
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Ollie can't we use the x86 emulator + bios support?
I am sympathetic to Eric's concerns about callbacks, in spite of my having written callback support into the vgabios for linuxbios. It's so easy to lose control of that vgabios off running on its own. It seems like the emulator would let us keep things under control.
ron
ron minnich wrote:
you missed the point. We will never copy a vga bios into the tree in any place unless given permission.
Okay, I saw something about putting binaries into linuxbios, and made the assumption...
-Steve
ron minnich rminnich@lanl.gov writes:
On Mon, 11 Aug 2003, ron minnich wrote:
For linuxbios to succeed in future, we'll need support for these two things. I think this is a lamentable state of affairs. But that's how it is.
I think long-term the best way to fix it for all architectures is via emulation, but for the immediate-term we can make callback/binary support for the common(-est) case: the x86.
I contradict myself. Either we need callbacks or we don't. If we get emulation, we don't need them. Sorry for my confusing note.
Eric, I am sympathy with what you are saying. There is a reality here -- people want VGA and they want it on early. I want to accomodate this.
Early is a problem unless we intimately know the video chipset. We can never accomodate early (as in all LinuxBIOS messages) with an option ROM.
For the option ROM solution the best we can do reliably is to run it right after we run the LinuxBIOS core.
Is emulation a suitable, architecture-independent way to achieve this? I'm thinking it might be. Can we then build it in as an option when we build a linuxbios?
Where to put this functionality, because we want it no matter which bootloader we use is a good question. My hunch is we make it some sort of header.
Because by early all we can really promise are the bootloader and the kernel messages, at least via this route.
Eric
Greetings,
One other call for modular binary support is end users. It's one thing to get them to use a provided tool to flash in one of several mix and match modules, it's quite a different matter to get them to actually compile something correctly and then flash it.
An idea I have for baremetal is to have it set up a callback table at the top of RAM for all of the useful (and possibly hardware dependant) functions. It's not too much of a leap to make a compile time decision to either:
1. End up by calling elfload and running baremetal which has it's own function library 2. link the baremetal setup in static and just call it.
With a bit of designing any payload should potentially be linkable againmst either LinuxBIOS to be called directly, or an ELF stub to be called externally.
The stub would likely have something like:
int printk(char *format, ...) { return call_table("printk", format ...); }
Otherwise, the payload will just link against LinuxBIOS.
The rest would be similar to the way mon can be standalone or linked in to init for beoboot.
I think some of the different opinions here really come not so much from philosophical differences as just different goals.
G'day, sjames
On Mon, 11 Aug 2003, ron minnich wrote:
On 10 Aug 2003, Eric W. Biederman wrote:
I haven't seen the numbers on the dreaded size overhead. So that argument does not yet convince me. If I can fit a whole IP/UDP stack a network driver, and printk in 16K I have trouble seeing the problem.
multiply that by, let's just say 4, for 4 elf payloads for 4 functions. At that point, I can no longer fit a kernel + linuxbios in 1 MB flash. At present I can barely fit one linuxbios + 1 stripped kernel.
I am right on the edge of being able to fit right now. Either I statically link in the VGABIOS code or I can't fit it. That's the issue for me.
Yes, I am well aware that we hope to have more compact ROMCC code, but that is not there right now.
Most of the things proposed so far are things I am primarily opposed to, at least except way out on the periphery. Callbacks are bad.
Callbacks are required if we hope to support VGA. There is no way around this.
Binary only code is bad.
Binary code support is required for future chipsets that, e.g., build wireless into the chipset. There will be many future software radios that are in chipsets, and you will not be able to get that in open source -- the FCC has a few things to say about that. Binary code support is inevitable. We won't be able to compile this code in, or build it as an ELF module. That's not going to be an option.
For linuxbios to succeed in future, we'll need support for these two things. I think this is a lamentable state of affairs. But that's how it is.
I think long-term the best way to fix it for all architectures is via emulation, but for the immediate-term we can make callback/binary support for the common(-est) case: the x86.
And the biggest reason I don't want to go there is because simple things tend to be reliable. And complex things tend to broken. And the extension extension looks to allow a lot of needless complexity into LinuxBIOS.
But the limits of poor PC design limit our ability to be simple. The original LinuxBIOS idea -- "Let Linux do it" -- was simple. We have found we need a bit more than that to be workable.
The single most common request I hear for LinuxBIOS is early VGA support -- early enough to see linuxbios messages. You have no idea how often this comes up -- or maybe you do :-)
I think we're going to need to do this in a reasonable way, or somebody will do it for us in an unreasonable way.
The biggest piece of code everyone has been arguing for including, the code to run a vgabios option rom, simply doesn't work in a lot of cases, and unless I have overlooked something the reason it doesn't work in a lot of cases is a design flaw, it doesn't aim for complete pcbios compliance.
That's a factor of time people have had to work on it. The code itself, I am told, has proven to be pretty solid for those operations it supports.
It's possible, the more I think of it, that what we really need is a payload for solid x86 emulation. That would buy us architecture-independence which we need. No callbacks either -- just emulate the trap and do the code for the callback. Much more reliable than callbacks. Very portable.
Still thinking .... more discussion welcome.
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Adam Agnew wrote:
No one really wants LinuxBIOS to support legacy BIOS services. However, the need for them keeps creeping in (I believe Ron plans to add int15 to have better support for some vga roms).
True, and too bad if any int's are added, I agree with Linus' original comment that "we don't need no stinking BIOS...", but I agree that reverse engineering these complex VGA chips is no easy task. However, I am going to continue to do it as I have time. I don't know if there is a good argument for this other than religious convictions. I seem to get a certain amount of self satisfaction out of booting linux without ever going into 16-bit mode, save the first instruction or two. And it is disconcerting to see that linux is starting to use BIOS calls in some places, like power management stuff (AFAIR).
-Steve
On Thu, 7 Aug 2003, Steve Gehlbach wrote:
is disconcerting to see that linux is starting to use BIOS calls in some places, like power management stuff (AFAIR).
that's a big mistake ...
ron
-
??? -
Adam Agnew -
Andrew Ip -
Bari Ari -
ebiederman＠lnxi.com -
Greg Watson -
ron minnich -
SONE Takeshi -
SONE Takeshi -
Stefan Reinauer -
Steve Gehlbach -
steven james