* Brendan Trotter btrotter@gmail.com [070612 12:43]:
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.
Yes, no doubt. You are perfectly right, and we are looking forward to your patches to fix this problem. Of course you do not have to reverse engineer, but just read the code, as we are non-proprietary. And of course we are always here to be asked.
So please, submit any documentation to this list for inclusion as soon as you wrote it.
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?
It is of course not unique. It is the index of the vendor name within the strings array of struct lb_mainboard. Since we're not trying to close things down, we don't have to work with magic numbers. So nothing needs to stay unique.
But I suggest you have a look at the code and document it as you start understanding it.
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....
Of course not. ACPI is not really useful for payloads though, unless the payload wants to carry a full blown ACPI interpreter. Which rules out basically anything but an OS.
- 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?
Yes, the emulation/qemu-i386 is per default not supporting SMP.
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)....
yes, either c or d. You choose.
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...
Obviously not. and if the device does not do EDD you have no reliable way of finding out either.
- 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)... ;)
Ok, the video hardware is in the state that the VGA Option ROM sets it to. Since that is closed source, we can not guarantee anything, obviously. A rule of thumb tells you that 80x25 at B8000 is a reasonable assumption. The AGP setup is chipset specific, so it might vary from chipset to chipset.