[LinuxBIOS] Specifications

[Brendan Trotter]

Hi,

On 6/14/07, Stefan Reinauer <stepan at coresystems.de> wrote:
> * Brendan Trotter <btrotter at gmail.com> [070612 16:51]:
> >  The file "src/include/boot/linuxbios_tables.h" defines 3 types of memory
> >  ranges:
> >
> >  #define LB_MEM_RAM       1   /* Memory anyone can use */
> >  #define LB_MEM_RESERVED  2   /* Don't use this memory region */
> >  #define LB_MEM_TABLE     16  /* Ram configuration tables are kept in */
>
> first two are types, third is the magic for the linuxbios table ("table
> type")
>
> >  The file "util/lbtdump/lbtdump.c" doesn't agree:
> >
> >               switch(rec->map[i].type) {
> >               case 1: mem_type = "ram"; break;
>
> >               case 3: mem_type = "acpi"; break;
> >               case 4: mem_type = "nvs"; break;
>
> so these two are missing above. Maybe they were never used..

For legacy BIOSs, the ACPI memory type defines an area that contains
the ACPI tables, that the OS may free and use as normal RAM after it's
finished parsing the ACPI tables. In this case (IMHO) for
compatability purposes LinuxBIOS should also use the ACPI memory type
to tell payloads (and OSs, via. the payload/s) that the area can be
freed and used as normal RAM. BTW I'm assuming the LB_MEM_TABLE may be
used by an OS in the same way (ie. the area can be used as RAM if the
OS is finished with the tables).

The ACPI NVS memory type also has special meaning, although to be
honest I've never fully understood it's purpose. As far as I can tell
there's at least 2 reasons for it.

The first is that an OS may access CMOS/RTC, and the firmware (the
BIOS's SMI handler and/or the ACPI AML interpretter) may also access
CMOSs. For some (most?) motherboards the CMOS has a single index and
data I/O port, which creates a problem when both try to access the
CMOS at the same time (for e.g. OS sets the index I/O port before
reading a CMOS location, firmware changes the index I/O port and reads
from the data I/O port, then the OS reads from data I/O port without
knowing the firmware messed with it and gets the wrong location). To
avoid this the BIOS creates a copy of CMOS's contents and stores it in
NVS, so that the AML interpretter and/or BIOS's SMI handler can access
NVS instead of the CMOS.

The ACPI NVS area is also involved with system power management
somehow - IIRC an OS must save the NVS area before entering some sleep
states (e.g. "hybernate") and restore it when waking up from that
sleep state.

To simplify documentation (and compatability problems for OSs not
designed for LinuxBIOS, given that payloads like GRUB would probably
just copy memory ranges from the LinuxBIOS Table to their own data
structures), it may be reasonable for LinuxBIOS to use the same values
for memory types as ACPI, plus define the additional LB_MEM_TABLE
memory type.

> >  Alternatively, could/would a payload search for strings to find CMOS
> >  values (e.g. search for the cmos_entry with the name string
> >  "power_on_after_fail" to see if additional hardware testing can be
> >  skipped, search for "baud_rate" to determine the serial port
> >  configuration, etc)?
>
> Yes.

Hehe - is there a master list of standard strings defined by LinuxBIOS
for the "cmos_entry" structures?

> > > Yes, the emulation/qemu-i386 is per default not supporting SMP.
> >
> >  I'm becoming skeptical here. I can't find anything in LinuxBIOS source
> >  code that starts AP CPUs, but in "src/arch/i386/smp/mpspec.c" I did
> >  find:
>
> check src/cpu/x86/lapic/lapic_cpu_init.c

My apologies - you are of course correct. I'll look into enabling Qemu
SMP support (and LinuxBIOSv3 and VGA) soon :-)


On 6/14/07, Stefan Reinauer <stepan at coresystems.de> wrote:
> * Brendan Trotter <btrotter at gmail.com> [070614 19:31]:
> > If I nag enough, would LinuxBIOS developers be willing to define a few
> > tags for the LinuxBIOS table that a payload can use to determine what
> > LinuxBIOS was using for text output immediately before starting the
> > payload?
>
> We should maybe write this down in an architecture or requirements
> specification, something which i started a while ago but never continued
> on it yet
> http://coresystems.de/PDFs/LinuxBIOS-testing/RequirementsSpecification.pdf
>
> Or we should get things porperly documented here instead:
> http://qa.linuxbios.org/docs/doxygen/

A project like LinuxBIOS involves 4 seperate groups of people -
LinuxBIOS developers, motherboard manufacturers, payload developers,
and end-users. Each group of people has different requirements.

LinuxBIOS developers need the source code itself, plus (optionally)
something to guide them on the future direction of the project and
something to make becoming familiar with the inner workings easier.
AFAIK this group is adequately addressed via. the mailing list,
docbook and the wiki.

Motherboard manufacturers are completely different. They need
something they can use while determining whether or not to support
LinuxBIOS - e.g. a concise document that describes all the benefits of
supporting LinuxBIOS, plus information on how to become a LinuxBIOS
developer (in case they become willing to offer direct support) and a
list of what information existing LinuxBIOS developers would need to
support their product/s (in case they become willing to offer indirect
support).

Payload developers are different again. The only thing that really
matters to these people is a document describing the state of hardware
when their code is started, and what format their code needs to be in.
This could be compared to things like the multi-boot specification,
the ELF specification, the OpenFirmware specification, and (to a much
lesser extent, due to the ugly mess it's become) the many
specifications and other documentation that makes up the legacy PC
BIOS "standard".

End-users are different again. All they want is something to describe
how to configure, install and use LinuxBIOS. They don't necessarily
care about any of the documentation and other resources used by any of
the other groups. Currently this group is addressed by the "Build
Tutorials" section of the wiki, and possibly other parts of the wiki.

In general, the best documentation for one group isn't really the best
documentation for any other group.

> In v3 we are going to export the complete device tree in the linuxbios
> table (are we?)

If it was my descision, I'd use something similar to the approach ACPI
used - ie. LinuxBIOS includes information that can't be obtained in
other standard ways (like scanning PCI configurations space, the ISA
Plug & Play specification, MP specification, ACPI specification, etc).

I'd have 3 exceptions to this (for 80x86):
1) basic text output, so that if a problem occurs while attempting to
use those other standard ways, then the payload can still let the
end-user know what the problem is.
2) motherboard resources, as the only standard way of detecting them
is ACPI, but it requires a large and over-complicated AML interpretter
to find out the simplest of things.
3) crappy old ISA cards, where no sane method of detection exists (for
OSs, payloads, or LinuxBIOS itself).

> > drop back to real mode, do a STI, and use BIOS interrupts). It'd be
> > nice if this code could check if the BIOS environment is a legacy BIOS
> > environment or LinuxBIOS... ;-)
>
> LinuxBIOS has no such environment, except the linuxbios table. If you
> want callbacks, openfirmware might be a good payload for you.