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