btrotter at gmail.com
Tue Jun 12 12:43:47 CEST 2007
On 6/12/07, Stefan Reinauer <stepan at coresystems.de> wrote:
> * Brendan Trotter <btrotter at 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
> > 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
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)... ;)
More information about the coreboot