[LinuxBIOS] Specifications

[Stefan Reinauer]

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

> ----8<---
> #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;
> };
> 
> #define LB_TAG_OUTPUT_EXTENDED_VIDEO	0x????
> 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)
> };
> 
> ----8<---
 

Any comments?


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

Maybe we should go and define the above as properties of the devices
they are provided by.

> 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.
 
This is a very good idea.

> 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)?
 
There are plans to do this in v3.

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

It could look for the linuxbios table in ram. Then it does not need to
assume where the rom is.

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

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

Stefan

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