stuge-linuxbios at cdy.org
Fri Jun 15 02:40:56 CEST 2007
On Thu, Jun 14, 2007 at 06:24:47PM -0600, Jordan Crouse wrote:
> On 15/06/07 02:08 +0200, Peter Stuge wrote:
> > 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. 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.
> Ah - perhaps thats the problem. I read the request as saying "We
> don't want to set up the serial, so set it up and tell us how you
> did it", but perhaps the request was really "if you set up the
> serial, then tell me, and I'll do it the same way".
No need to set it up again - but with the payload knowing how the
system _is_ set up it can just adapt and start using the system
without doing any setup.
> So let me ask you this - under the proposal, what if I choose to
> tell the payload that the baud rate is 0. Does the payload then
> pick a sane baud rate of its own, and program the 16550 itself, or
> does it collapse in a heap
This depends completely on the payload.
If you tell the payload (via LB or directly) that the baud rate is 0
it can't do much for you.
If you tell LB that the rate is 0 but the payload that the rate is
115200 I expect the payload to set up the UART so you will get
serial from the payload.
> and claim that LinuxBIOS didn't work because the serial settings
> are not sane?
There is no spec so there can't really be any expectations yet.
In practice, it has turned out that a serial port is usually there
> If its the first scenario - then I'm on board. Its the second that
> I am worried about.
Payloads should be smart and handle all configs that make sense but
LB needs to provide data points to support those smart decisions.
IMHO if a payload does not work because of something it can not
control (the mainboard has no serial, but payload requires serial)
then it is broken or applied where it does not fit. Broken because it
could have looked at the (future) system spec (which could be the
device tree) and figured out how to fail gracefully when no serial
port exists all on it's own.
More information about the coreboot