Hi,
On 6/14/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> * Brendan Trotter <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> wrote:
> * Brendan Trotter <[EMAIL PROTECTED]> [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
--
linuxbios mailing list
[email protected]
http://www.linuxbios.org/mailman/listinfo/linuxbios
