Hi,
On 6/14/07, Stefan Reinauer stepan@coresystems.de wrote:
- Brendan Trotter btrotter@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@coresystems.de wrote:
- Brendan Trotter btrotter@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.
From my perspective, it's simply about knowing what can and can't be
used. For e.g. if my code knows it can't drop back to real mode and use legacy BIOS interrupts, then it can skip it or use an alternative (in this specific case, I only used legacy BIOS interrupts to allow the user to select and change the video mode).
Consider the multi-boot specification. OS developers can write code that complies with the multi-boot specification without regard to any bootloader, and bootloader writers can write code with that complies with the multi-boot specification without caring about any OS. Despite this, all OSs and all boot loaders that comply with the multi-boot specification will work together without problems. The same applies to EFI and OpenFirmware.
I think some of this is actually more in the domain of EFI and Open Firmware than in LinuxBIOS, which is more a low level firmware. So we should work on getting EFI / OFW easily usable as an interface for everyone instead of defining a third interface. to the OS and user. Our interface is to OFW / EFI though (plus other options of course)
Put more generally, all interfaces between components developed by different parties should be adequately documented. This includes the interface between hardware and LinuxBIOS, the interface between LinuxBIOS and it's payloads, the interface/s between payloads and anything that use the payload/s, the interface between boot loaders and OSs, the interface between an OS and software designed for that OS, etc.
BTW I'm more interested in "boot from ROM" systems, where the "OS" is stored in ROM, and doesn't require or rely on disk drives or networking (but may use disk drives and/or networking if present, after the system is running). GRUB, Openfirmware and EFI payloads would consume too much of the limited space in ROM.
Cheers,
Brendan