segher at kernel.crashing.org
Fri Jun 15 16:53:42 CEST 2007
> One example is VGA. It's not a bus. But if you are saying it is not the
> BIOS' task to enable VGA. Whose is it.
The kernel (or some userland, preferably/partially) needs
to be able to initialise graphics controllers from the
ground up, to support sleep modes (and also to support
more-than-one-card setups, in the legacy BIOS case).
This is a well-understood problem in the Linux graphics
world, but quite hard to solve it seems -- it is taking
forever. Some progress is being made though.
If LB wants to use the graphics hardware by itself, i.e.
for the boot menu or something similar, it of course
has to init the graphics and contain a minimal driver,
> Calling a VGA option rom in a
> bootloader is about as wrong in my opinion as initializing DRAM in an
> kernel is.
It is philosophically wrong, and hard to make it work
reliably too, esp. in a generic cross-vendor way. It
is more of a band-aid than an actual solution.
>> Devices are never _driven_ by LinuxBIOS after the payload has been
>> started however,
It can be useful to have a single callback into LB to
display debug output on whatever the debug output device
is. Anything more than that is quite not in line with
the LB philosophy I'd say; you'd be better of using a
full blown Open Firmware implementation if you want a
feature-rich boot environment.
>> However - LinuxBIOS will need to "hand over" the system to the
>> payload and I guess that the formalization of this handover is what
>> this thread is all about.
> honestly, I dont think so. The handover is loading an ELF file. How
> unformalized can that be.
The handover is the jumping to the ELF entry point, instead ;-)
More information about the coreboot