Hi,
On 6/12/07, Stefan Reinauer stepan@coresystems.de wrote:
- Brendan Trotter btrotter@gmail.com [070612 06:23]:
I'm wondering if there's a specification describing the state of the computer at the hand-off between LinuxBIOS and a payload.
So far I've got LinxBIOS booting a dummy "for(;;)" payload in Bochs, and I've found out there's a "LinuxBIOS Table" and that it can be found by searching for "LBIO" in the first 4 KB of RAM and in the area between 0xF000 and 0xFFFFF. I don't know if there's a checksum or any other validation, and have been unable to find anything describing what this table contains.
check LinuxBIOSv2/util/lbtdump
I've found "src/include/boot/linuxbios_tables.h" and have also looked at the source for LinuxBIOSv2/util/lbtdump.
However, I fail to see how any source code can be considered a viable alternative to documentation for something that is (hopefully) a non-proprietory common standard. Reverse engineering (including relying on assumptions derived from the source code of any specific implementation) is what people do when they have no documentation and are willing to stumble around in the dark hoping to implement something that works until the wind changes.
For a simple example, which piece of source code would tell me if "lb_mainboard.vendor_idx" is guaranteed to be unique both now and in the future?
I assume there may also be ACPI, MP specification, PIRQ routing and/or (possibly) SMI/DMI tables, and I'm guessing that (if present) these tables can be searched for using the same methods as described in their corresponding specifications.
They're not used by payloads (except the Linux kernel)
Surely LinuxBIOS isn't intended as a "Linux only" BIOS though....
- are AP CPUs started (or waiting for a SIPI sequence)?
yes, hardware is completely up when linuxbios is done.
I tried it on a dual CPU Bochs emulation (second CPU was left in "wait for SIPI" state) - I'm guessing I need to enable multi-CPU support via. some compile time option for the "emulation/qemu-i386" target?
- can the payload assume anything about the state of the PIC, I/O
APIC/s and local APIC/s, PIT, RTC, ISA DMA controllers, serial ports, etc?
yes. they're initialized.
:-)
Initialised to which states? For e.g. would the PIT be guaranteed to be initialised to generate IRQ0 at a certain frequency, and would the PIC (and/or I/O APIC?) be guaranteed to be initialised to generate specific interrupt when IRQ0 occurs; or (from the payload's perspective) are these things left in an undefined state (i.e. the state they happened to be left in when/if LinuxBIOS used them)?
- what state are PCI buses and devices left in (would a payload need
to do full PCI bus enumeration, or..)?
They have their resources.
What do you mean by full pci bus enumeration? What would be the opposite?
Either: a) PCI buses and bridges aren't guaranteed to be enumerated, or b) PCI buses and bridges are guaranteed to be enumerated but PCI devices aren't guaranteed to be assigned resources, or c) PCI buses and bridges are guaranteed to be enumerated and PCI devices are guaranteed to have resources assigned (including ROMs) d) PCI buses and bridges are guaranteed to be enumerated and PCI devices are guaranteed to have resources assigned (except ROMs)
"They have their resources." would mean either c) or d), where each device may or may not be in a power saving state (if supported by the device), and may or may not be still configured to use MSI (if supported by the device)....
- is there anything in the LinuxBIOS table that could be used to
determine if the computer is "headless" and which serial port or other device to use if it is?
Not at the moment. But in General this is easy. If no VGA class PCI device is there, the machine is 99.99% headless.
And if a VGA class PCI device is present, you've got no idea if no monitor is attached...
- can anything be assumed about AGP and the first video card (if the
computer isn't headless)?
What would you like to assume?
Video card set to default "80 * 25" text mode accessible at 0xB8000; or some video mode set with display memory directly accessible at some physical address (where video mode details and physical address included in LinuxBIOS Table); or AGP aperture configured, AGP transfer speed set, MTRRs set to "write combining" and some video mode set with display memory directly accessible at some physical address; or anything else, as long as a payload writer knows how much or how little they can assume about it (and hopefully doesn't need to implement a wide range of video drivers just to do a "Hello World" that works on all video cards)... ;)
Cheers,
Brendan