[LinuxBIOS] Specifications

[Stefan Reinauer]

* Brendan Trotter <btrotter at gmail.com> [070612 16:51]:
>  Hehe - by the time you've finished answering all my questions you'd
>  wish you'd written the documentation beforehand... ;-)

:-) Well, unless someone asks it's often not clear what documentation is
required, so I think this is a good way of finding out. 

>  Is "uint32_t" always little-endian or is it architecture specific
>  (reverse engineering ruled out "always big-endian"), and would the
>  "lb_header.signature" field always have an ASCII 'L' at the lowest
>  address (or is that architecture specific too)?

It's probably arch specific. But we might want to change this.

>  		if (head->header_bytes != sizeof(*head)) {
>  			fprintf(stderr, "Header bytes of %d are incorrect\n",
>  				head->header_bytes);
>  			continue;
>  		}
> 
>  From this can I assume that the size of the LinuxBIOS Table header
>  will always be 24 bytes, and the LinuxBIOS Table header will never be
>  extended in the future (or is this just a bug that makes "lbtdump"
>  unable to handle forward/backward compatability)?
 
The header will never change. Dont think it should

>  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..

>  		default:
>  		case 2: mem_type = "reserved"; break;
>  		}

>  Can I assume that the defines in "linuxbios_tables.h" are out-of-date,
>  and that the memory type field is the same as specified by version 2
>  of the ACPI specification (but perhaps not version 3, as that defines
>  a new "5 = faulty RAM" type)? If "linuxbios_tables.h" is out-of-date,
>  is "16 = RAM configuration tables are stored in" still possible on
>  older versions of LinuxBIOS (and how would I detect which version of
>  LinuxBIOS is present, considering there's no version number in the
>  LinuxBIOS Table header)?

LinuxBIOS table format has not changed from v1 to v2. It will be
enhanced in v3. But nothing will break.

>  Would I also be correct to assume that a payload doesn't need to care
>  about any of the "cmos_entries" and "cmos_enums", unless a BIOS
>  setup/configuration utility is being built into the payload?

yes. A payload only cares for that information it needs, or cares about.
It can skip the other table entries in the lbtable. This way old
payloads and tools will always work with new tables. (But not promote
their benefits of course)

But of course the bios setup utility does not need to be a payload. The
most common case is that it is a linux userspace program. 

>  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.

>  Of course - it's similar to the way SMI/DMI does strings, yet are the
>  strings themselves guaranteed to be unique, or is it possible for one
>  manufacturer to use an identifying string in the future that another
>  (possibly out of business) manufacturer had used in the past?

No, the name strings are unique.

Unless in cases where, hmm.., AMD buys ATI and we port LinuxBIOS to a
piece of ATI hardware but still might call it AMD something if AMD
changes the name as well.

>  Motherboard manufacturer identification is one of the things that
>  (IMHO) should be unique. The motherboard part number string should
>  also be unique for that manufacturer ID. Otherwise it'd be difficult
>  for payloads/utilities/OSs to use these IDs to avoid any hardware
>  problems in specific motherboards.

Yes, absolutely right! 

> > 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

>  In any case, I'm guessing I need to get LinuxBIOS to generate MP
>  specification and ACPI tables to suit the number of CPUs being
>  emulated by Bochs/Qemu. 

You need to enable CONFIG_SMP and possibly fix some of the Qemu cpu
specific code, as it removed most of the init code of real CPUs as it is
not required. Alternatively, you could try to use real code, ie that of
a P6.

> Is this as simple as adding something like
>  "option CPUs = ?" to the "targets/emulation/qemu-i386/Config.lb" file?

>  I'm guessing it's more involved than this, as I couldn't find an
>  example in the "Config.lb" of other targets.

About half of the files have this:

default CONFIG_SMP=1
default CONFIG_MAX_CPUS=2

> > yes, either c or d. You choose.
> 
>  You mean all LinuxBIOS developers are willing to make sure all PCI
>  device ROMs either have physical addresses assigned or don't have
>  physical addresses assigned based on my advice? Perhaps I've
>  misunderstood... :-)

No, both is possible. You choose what you want. I choose what I want.  ;-)

You can disable option rom execution and drop a lot of cruft if you know
you wont have option roms anyways.

>  My (limited) reverse engineering has already shown that there's CMOS
>  entries for a serial port (possibly intended for setting up a serial
>  cable to communicate with a terminal emulator?).
 
Yes, basically all LinuxBIOS debugging happens over serial console with
a null modem cable

>  Next question would be how to get that to work under Qemu and/or
>  Bochs. I realise this may not be easy (I've had problems with Bochs
>  before, as the VGA ROM seems to behave like an ISA card ROM and
>  doesn't behave like a PCI card ROM - i.e. the ROM ignores settings in
>  PCI configuration space)...

I fixed the ROM a while ago so it behaves right. If you do Qemu, I
suggest that you look at LinuxBIOSv3 as it is where we are trying to go
now. svn://linuxbios.org/repository/LinuxBIOSv3

Lots of stuff is still missing, but it is tested and working with the
(patched) vga rom.



-- 
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/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vgabios-0.6a-pcidata.diff
Type: text/x-patch
Size: 960 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070614/931580b1/attachment.diff>