[LinuxBIOS] Specifications

Brendan Trotter btrotter at gmail.com
Thu Jun 14 19:31:29 CEST 2007


On 6/13/07, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
> On Wed, Jun 13, 2007 at 05:28:02AM +0000, Brendan Trotter wrote:
> > I just think it'd be annoying for end-users if (for e.g.) the
> > payload decided to use the 28800 8N1 for serial communication when
> > LinuxBIOS is using 57600 8N1 because there was no way for the
> > payload to determine how LinuxBIOS is currently configured.
> It can just not set up the serial port but use it immediately and it
> will keep the settings that LinuxBIOS used.
> Granted, which one to choose must still be specified in the payload.
> > As far as I can tell, Stefan's "You choose." either implies that
> > it's my choice what LinuxBIOS developers do or that it's my choice
> > how end-users configure LinuxBIOS. I doubt I've got that much
> > influence with either group.
> You would be surprised how receptive and tolerant this group of
> people is. Ron even writes code the way I want if I nag him enough.
> (Hi, Ron! :)

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

For example, in "src/include/boot/linuxbios_tables.h" add something like:


#define LB_TAG_OUTPUT_UNKNOWN	0x????
struct lb_output_unknown {
	uint32_t tag;
	uint32_t size;

#define LB_TAG_OUTPUT_SERIAL	0x????
struct lb_output_serial {
	uint32_t tag;
	uint32_t size;
	uint32_t  base_port;   // Base I/O port for pre-configured serial port
        uint32_t IRQ                // PIC input number for
pre-configured serial port

#define LB_TAG_OUTPUT_VIDEO	0x????
struct lb_output_video {
	uint32_t tag;
	uint32_t size;

struct lb_output_ext_video {
	uint32_t tag;
	uint32_t size;
        uint64_t phys_address;  // Physical address of first byte of
frame buffer
        uint32_t resolution_x;     // Horizontal resolution of video mode
        uint32_t resolution_y;     // Vertical resolution of video mode
        uint32_t bytes_per_line; // Number of bytes per screen line
        uint32_t bpp;                  // Bits per pixel:
                                               //  0 = text mode
                                               //  4 = standard VGA
planar 16 colour mode
                                               //  8 = standard VGA
256 colour mode (with VGA pallete)
                                               //  15 = a 5:5:5 pixel format
                                               //  16 = a 5:6:5 pixel format
                                               //  24 = a 8:8:8 pixel format
                                               //  32 = a 8:8:8:8 pixel format
        uint32_t red_mask;        // Mask of bits that control red
colour component (unused if "bpp" <= 8)
        uint32_t green_mask;    // Mask of bits that control green
colour component (unused if "bpp" <= 8)
        uint32_t blue_mask;      // Mask of bits that control blue
colour component (unused if "bpp" <= 8)


Then in the "LinuxBIOS to payload hand-off specification", have
something like this (with standard definitions for words like
"should", "may", "must", etc):


The firmware should use one (and only one) of LB_TAG_OUTPUT_UNKNOWN,
LB_TAG_OUTPUT_EXTENDED_VIDEO to inform the payload of details for the
device it was using immediately before starting the payload. The
LB_TAG_OUTPUT_VIDEO tag is provided as an abbreviated version of
LB_TAG_OUTPUT_EXTENDED_VIDEO where 80 * 25 text mode (with 160 bytes
per line) is implied rather than specified directly.

The firmware may also provide none of these tags in the LinuxBIOS
Table, and payloads must handle this as a "no text output possible"

If the LB_TAG_OUTPUT_UNKNOWN tag is specified by the firmware, the
payload may either assume that no text output is possible or attempt
to use alternative methods to determine if a suitable output device is

If the firmware is configured to send output to a serial port, it
should include a LB_TAG_OUTPUT_SERIAL tag (and leave the baud rate and
communication protocol setup) regardless of whether or not the
firmware knows if anything (e.g. a terminal emulator) is connected to
that serial port.


The intention here is to allow payloads to auto-detect the method they
should use for text output, such that no end-user configuration of the
payload is necessary.

For a seperate issue, would it be possible to modify LinuxBIOS so that
the size of the ROM and the amount used by LinuxBIOS is stored at a
fixed locations within the ROM (e.g. so that these values can be read
at physical address 0xFFFFFFE8 and 0xFFFFFFEC, just below the first
instruction executed by the CPU at power-on)?

Also, would it be possible to have (or is there already) a firmware
signature somewhere in the ROM, so that if/when GRUB is used as a
payload then software booted by GRUB could check if the signature is
present in the ROM (e.g. by checking an 8-byte signature at
0xFFFFFFE0) to determine if legacy BIOS services are still present (no
signature) or if LinuxBIOS (and the LinuxBIOS Table) is still present?

The multi-boot specification states that the BIOS environment must be
preserved by the boot loader (but doesn't specify *which* BIOS
environment). I've written code in the past that relies on this (e.g.
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... ;-)

> > I'll assume that whether or not ROMs are assigned physical
> > addresses, whether or not device may be left in a power saving
> > state, and whether or not MSI may still be setup is all "undefined"
> > - not guaranteed either way.
> I think this is belittling the effort in this project to initialize
> hardware.

It's belittling the specification for the hand-off between LinuxBIOS
and payloads, that both LinuxBIOS developers and payload developers
would be attempting to comply with.

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.



More information about the coreboot mailing list