Re: Interrupts needed by LILO
I thought, a main topic for OpenBIOS development is full access to the hard drives so there is no trouble with large disks, large partitions and kernels laying somewhere on them.
Perhaps I'm confused. Shouldn't OpenBIOS be able implement the functionality of LILO? I thought that LILO existed because BIOS16 are incapable of loading anything that isn't DOS-like. Doesn't LILO look to the BIOS like DOS? In other words, when a BIOS is loading LILO, doesn't it "think" it's loading DOS?
I thought, a main topic for OpenBIOS development is full access to the hard drives so there is no trouble with large disks, large partitions and kernels laying somewhere on them.
That sounds right. So why have a new LILO? Why not just not need LILO anymore? M
On 26 Nov, M Carling wrote:
Perhaps I'm confused. Shouldn't OpenBIOS be able implement the functionality of LILO? Not necessarily, but of cause, we could.
I thought that LILO existed because BIOS16 are incapable of loading anything that isn't DOS-like. No, the BIOS can't load DOS either. The BIOS loads the first sector of the first floppy if it ends with 0x55, 0xaa, if not it applies the same test to the first sector of the first hard disk. Then it tries to enter the ROM_basic :) There is a DOS boot loader the fist sector if a bootable floppy or DOS partition. In the first sector of a hard disk there is a master boot program which loads and executes the first sector of the active partition.
Doesn't LILO look to the BIOS like DOS? No, the LILO boot sector looks like a boot sector as does the DOS boot sector.
That sounds right. So why have a new LILO? Why not just not need LILO anymore? Because of flexibility? And we don't need to use LILO. We might tech the firmware of a (OS independent) boot FS that could hold the boot loader. Afaik. Sun does something like this.
/Daniel --
That sounds right. So why have a new LILO? Why not just not need LILO anymore? Because of flexibility? And we don't need to use LILO. We might tech the firmware of a (OS independent) boot FS that could hold the boot loader. Afaik. Sun does something like this.
I like the idea of having the BIOS know how to load the kernel itself. Most filesystems can be read from with a fairly small amount of code. Let people compile into their BIOS however much code they want depending on which filesystems they actually plan to use. If we can allow the kernel and BIOS to use much of the same source code for drivers, then there is no need to ever call into the BIOS once the kernel is loaded. This eliminates stupid problems caused by the BIOS wanting parts of the system to be one way and the kernel wanting them to be another. The main reason I do not like OpenFirmware is that it presumes a slow, frozen driver in ROM with its own frozen idea of how interrupts and DMAs should work will be good enough that my kernel will never want to replace it. Yeah, right. Todd Whitesel toddpw @ best.com
On 28 Nov, Todd Whitesel wrote:
I like the idea of having the BIOS know how to load the kernel itself. Most filesystems can be read from with a fairly small amount of code. Let people compile into their BIOS however much code they want depending on which filesystems they actually plan to use. I don't like the idea of putting OS-specific knowledge in the firmware, I think the firmware should load a file from the disk to a well-known place in memory. This file could be the OS kernel if the kernel can cope with this environment directly or it could be a secondary loader with some OS specific knowledge that loads and perhaps relocated the kernel in some arcane way.
If we can allow the kernel and BIOS to use much of the same source code for drivers, then there is no need to ever call into the BIOS once the kernel is loaded. This eliminates stupid problems caused by the BIOS wanting parts of the system to be one way and the kernel wanting them to be another. I don't think that the OS should have to call the FW after boot either, but during the boot, however...
The main reason I do not like OpenFirmware is that it presumes a slow, frozen driver in ROM with its own frozen idea of how interrupts and DMAs should work will be good enough that my kernel will never want to replace it. Yeah, right. Well, that was a property to OF that I was unaware of. What I like about OF is the Forth code, the device tree and that is is a standard.
Daniel --
The main reason I do not like OpenFirmware is that it presumes a slow, frozen driver in ROM with its own frozen idea of how interrupts and DMAs should work will be good enough that my kernel will never want to replace it. Yeah, right. Well, that was a property to OF that I was unaware of. What I like about OF is the Forth code, the device tree and that is is a standard.
Agreed. I guess I'm just cranky because I think OpenFirmware is limping because their mission is limited to "like the PC BIOS, only cleaner and interpreted". This means they don't provide compelling value to the hardware vendor who only cares about x86. So it's no wonder the PC market ignores them and it's the SPARCs and Macintoshes that use OpenFirmware. If OpenBIOS wants to go the OpenFirmware route, that would actually speed adoption among some groups, as the NetBSD guys have quite a bit of experience already using OF drivers to boot their kernel. http://www.netbsd.org/Hardware/ofw.html Todd Whitesel toddpw @ best.com
participants (3)
-
daniel.engstrom＠riksnett.no -
M Carling -
Todd Whitesel