[LinuxBIOS] Specifications

[Stefan Reinauer]

* Brendan Trotter <btrotter at 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.



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/