* Peter Stuge stuge-linuxbios@cdy.org [070615 02:08]:
I think so, for the specific case of the console serial port (or a replacement).
The serial port (or replacement) is crucial for developers and initially it was also crucial for users. Those users are still around but now we also want to help users that consider other devices to be crucial.
Yes, serial port is at least crucial until we get linuxbios shipped on a given board as default boot firmware
I think LinuxBIOS is there to initalize and enumerate the hardware at a very low level. I don't think it is there to be a surrogate serial / smbus / IDE / VGA / whatever driver for payloads that don't wish to implement those things on their own.
This is a very important point and I agree completely.
LinuxBIOS is not a set of drivers and does not provide services.
So are you saying we should drop VGA init from v3 completely and make that a seperate payload? While rather working on making payloads executable serially than to push this code into LinuxBIOS?
But then the LB table needs to be enhancable by any payload any time later.
LinuxBIOS should provide all information it knows about the hw to the code that runs afterwards. This "we leave everything undefined" game does not work out. Because no one else feels responsible to change the "undefined" state later on either. The bootloader does not care except for the boot device, the OS does not do the job. Houston we have a problem. Bringing the hardware into a defined state is what we want. Power on default can very well be a defined state for many/most devices.
Software needs system buses to be in a "working" state where devices are "reachable" and some of us considers this to imply that devices are "initialized" and set to some state because they have in fact been touched while others consider only the bus itself to be initialized.
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 bootloaders? Come on, that would not be an improvement of design. Also we have more bootloaders than we have low level firmware. It would be a desaster for the workload and thus stability of bootloader writers. Calling a VGA option rom in a bootloader is about as wrong in my opinion as initializing DRAM in an OS kernel is.
Initializing VGA in the kernel is too late for 90% of real world applications. Imagine someone wants to change the boot device. And no, we do not have 16MBit flashes to pack Linux into on most systems. Not this year and not next year. And the opportunities in 2009 should be discussed, but not be a problem for our use today.
Devices are never _driven_ by LinuxBIOS after the payload has been started however, and most devices aren't driven before the payload starts either.
Most devices, like video output do not need to be driven. Drivers in LinuxBIOS context means initialization. Thats all LinuxBIOS ever does: Initialize HW. No, no sound cards. But: Basic I/O subsystems. The machine needs to talk to us.
The first computer I was working on was an ITT3030. It's firmware would have you start the OS loader from disk by typing a blind sequence of debugger commands into the firmware prompt (that I never saw, I had no idea about a console at the time. I just knew the sequence). I feel we should not go back to 1984 or earlier with our standards.
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.
It should include providing the payload with information about how the system is set up as of now so that good payloads can be written which will work on any setup.
yes!