[LinuxBIOS] Specifications

[Stefan Reinauer]

* Brendan Trotter <btrotter at gmail.com> [070613 07:28]:
>  I just think it'd be annoying for end-users if (for e.g.) the payload
>  decided to use the 28800 8N1 for serial communication when LinuxBIOS
>  is using 57600 8N1 because there was no way for the payload to
>  determine how LinuxBIOS is currently configured.

Often, the payloads have the choice to expect the serial port being
initialized, so they don't change the speed. But I agree your approach
makes sense.

One thing we are lacking though is a library or small set of functions
that allows the (os less) payload to access the cmos and parse those
parts of the lb table. all a payload ever parsed that i know of is the
"memory" part of the memory tables

>  If LinuxBIOS told the payload "use the frambuffer, which is in ? * ?
>  mode at ?" or "use the serial port at ? at ? baud and ? protocol",
>  then the payload could seemlessly autodetect at run-time and continue
>  using the same method for text output that LinuxBIOS used. Without
>  this end-users would need to mess about with compile-time settings for
>  the payload, and possibly recompile the payload if CMOS settings are
>  changed after LinuxBIOS is installed.

Yes. We must export a lot more information in the LB table. 
I like this idea. And I think v3 will be a lot more like that.

>  I'm not sure googling for the information about the strings the
>  LinuxBIOS project may or may not use in future for it's identifiers
>  would help, unless (for e.g.) the "payload hand-off specification"
>  explicitly states that the identifiers (if present) must be identical
>  to those used by SMI/DMI, in which case I could google for SMI/DMI
>  identifiers....

Nope, any similarities are coincidential. And not intended? ;-)

>  As far as I can tell, Stefan's "You choose." either implies that it's
>  my choice what LinuxBIOS developers do or that it's my choice how
>  end-users configure LinuxBIOS. I doubt I've got that much influence
>  with either group.

When you build a LinuxBIOS image, you can decide whether this image will
call PCI option ROMs or not. Of course the developers will try to set
reasonable defaults. Of course the user might remove all plugin cards
from his machine.. :-) 

>  I'll assume that whether or not ROMs are assigned physical addresses,
>  whether or not device may be left in a power saving state, and whether
>  or not MSI may still be setup is all "undefined" - not guaranteed
>  either way.
 
No device will end up with ROMs assigned, as the PCI standard forbids
that. No device will be left in a power saving state. No idea about MSI,
I never did that on AMD hw

>  There is little practical difference between reverse engineering in
>  the traditional sense, and "reverse engineering" source code.

You are no doubt coming from a "legacy grade environment" or "commercial
grade source code quality". Since we are trying to get more people into
the project, we try to make the source code as easily understandable as
possible, and we work on improving it.

> In both
>  cases it tells you nothing about what is guaranteed and what is
>  coincedence (or what is incorrect behaviour), which values are valid
>  for different fields, or what may or may not be implemented in future
>  or past versions.

"guaranteed" is a difficult word. You can always fork for a specific
application and thus guarantee that the environment will not change.

We might break compatibility since hardware is living fast and we rather
want to do a good job on supporting hardware well. 

Since we are a heterogenous group, it is hard to forsee what may be
implemented in the future (heck, no homogenous group can do that either,
except the illuminati)
It's mostly "requirement driven development".

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