Jeff Garzik wrote: >Justin Cormack wrote: > >>>Ronald G Minnich wrote: >>> >>>>On Mon, 4 Mar 2002, Jeff Garzik wrote: >>>> >>>>>However... why don't you add basic BIOS INT support as an option? ;-) >>>>> >>>>ow. I'll let someone else do that. It makes my brain hurt SO MUCH. >>>> >>>The masses will cheer your name and elevate you from Man to God, if you >>>do it, though ;-) >>> > >BIOS INT support is not critical for booting linux kernel from flash. > >BIOS INT support -is- critical for the goal of a 100% free software BIOS >that end users may use. > >So far there is no free software which does this. This is really the >last bastion of proprietary software. Free software exists for all >other usages after the BIOS boots. We have free bootloaders, free >kernels, and free userland. But no free BIOS. > >So... BIOS INT -must- be supported. However, it IMO is best to keep >that separate from linuxbios. As I keep pointing out, this can (and >should!) be a separate piece of the puzzle: > > linuxbios + freebios == can boot MS-DOG > >"freebios" would be the piece that provides BIOS INT services, console >services, etc. If/when freebios exists, freebios users will likely >-disable- some code, such as PCI or IDE init... or anything besides >basic CPU/DRAM init. freebios would be the one that initializes the PCI >bus(es), spins up IDE drives according to spec, etc. > >Of course, this is completely a pipe dream until I (or someone else) >sits down to code it. ;-) > > Jeff >
What is currently needed for BIOS INT support? Is it just setting up an interrupt vector table with default handlers, and initializing the Interrupt Controller per PC/AT spec? About a thousand lines of assembly usually does this. Whats the status of the extension of the classic INT 15h for ACPI, and also an ACPI table? Bari
