[PROPOSAL] extended payload handling

Eric W. Biederman ebiederman at lnxi.com
Mon Jun 14 12:40:00 CEST 2004

Stefan Reinauer <stepan at openbios.org> writes:

> There has been a similar proposal on this list a while ago, but nothing 
> happened so far, so I want to put this pack to discussion.
> Objectives
> ----------
> 1.) 
> LinuxBIOS is kind of hard to set up for project newbies, since it 
> does not only require manually tweaking the configuration files for
> basically every situation, but also necessarily needs an external
> payload to do anything useful.
> LinuxBIOS currently sets a high barrier due to the modular concepts it
> uses.

>  - LinuxBIOS itself is sometimes very sensitive to the build
>    environment. See requirement for setting LANG for example.

?  The only time I have heard this is with buggy perl when building
>  - For a project outsider it is hard to determine the best payload
>    solution for a specific purpose. There is basically no information
>    except the mailing list archives.

That are documentation is sketchy is a problem.  Half the problem is
that many of the payloads are not terribly mature.  ADLO for example
has to be hacked for each board for example.  That can only be fixed
by fixing the payloads.

>  - Config files have to be tweaked to explicitly suit the user's
>    directory structure. There is no proposal, nothing that works out of
>    the box. One just _has to_ edit the config files.

Agree that is an issue.  
>  - LinuxBIOS requires the user to specify a size for the payload instead
>    of determining the required size and doing the needed calculations
>    itself. This is very hand-crufted and can be pretty mind wasting.

I sort of agree.  This is more a matter of reserving a whole you can
place a payload in.  Ideally the payloads can be flashed
independently.  In any case this should be once per board port, and
not something the user needs to mess with. 

And a couple more.

- Too many linuxbios options need to be specified in the top level
  configuration file, or they don't work.

- We don't have stable releases.  You get snapshot of they day instead.

>  * LinuxBIOS therefore needs a way to automatically determine payload
>    sizes when building the image and later when executing payloads.
>    Hardcoding the size values in the config files is inadequate and will
>    lead to unnecessary overhead

There is certainly an issue with flash device layout here.  But I
don't think it is quite as simple as your intuition.
>  * LinuxBIOS should, to be consequent, remove all streaming code except

On some platforms like the alpha after you have loaded yourself
from an srom.  Or if your primary ROM chip is a Disk-On-Chip that you
need code for reading a ROM.  The IDE driver is certainly interesting.

>  * Payloads should have the possibility to add their own enhancements to 
>    the LinuxBIOS table.

They do they can rewrite it.

>  * A least one payload should be "default payload" with the possibility 
>    to build this automatically and link it into the image. 

To make things easier I largely agree. 
>    This is why I checked the "util/extensions" directory into v2 during
>    the last discussion. It should hold possible choices to payloads that
>    can automatically be built and included. Potentially one could add
>    more payloads by symlinking their source tree to this directory to make
>    it available to LinuxBIOS without major reconfiguration.
>    People feel a lot safer with creating a symlink than with changing
>    config files they do not fully understand.

Likely but....

>    Since these can later be executed in row by elfboot, the minimum
>    overhead design of LinuxBIOS itself will not be hurt.
>    At this point I want to put an idea to discussion: If we are going
>    more and more modular and some of us think the current tree is too 
>    bloated: Why do we not modularize code like pci resource allocation
>    into a payload as well. My favorite bootloader may already do this 
>    and I can't stand this bloat everywhere, you know ;) Even though this
>    may sound funny, I am serious about this issue. I do not see why 
>    allocating PCI resources should really be part of the lowlevel code,
>    except for the fact that the NEXT payload in row, potentially Linux
>    itself is too stupid to do that. Bummer.

You cannot use hardware unless it has been allocated resources.  You
cannot do device resource allocation except by looking at all devices.
So largely this is a catch 22 type situation.

The problem with implementing device resource allocation in Linux is
that it requires motherboard specific knowledge.   Frequently onboard
devices have BARs in non-standard locations, the kernel does not know
about, or there are non-enumerable devices like sio chips that have
resources as well.

If a general purpose way of exporting the motherboard specific
information (which devices are present and how they are hooked up) 
can be developed.  And we can teach Linux to use it.  Possibly making
it a CONFIG_EMBEDDED option.  I have no problem with pushing out most
of the code and letting Linux handle it.  And I am even willing to
help with that as time permits.   But until such time as we can reset
OS's expectations of what to expect from the hardware/firmware
combination I am not ready to remove that code.

Beyond that the pci enumeration code is totally optional.  The
mainboard code just needs not to call it.   

There are couple of sticky points I see.  On boxes like the Opteron I
have a hard time seeing how to setup something that is reasonably sane
with hypertransport routing without find which resources are needed by
the devices.  I also have a hard time seeing how much memory you can
report and how to set the memory BARs without knowing how large
your memory mapped pci resources are.

Absolute minimal size and trivial configuration are conflicting
goals.  Getting things as small as possible will require some serious
user tweaking of configuration and possibly likely even the code.
For example to remove the calls into the pci configuration code
requires changing the motherboard code.

>  * LinuxBIOS configuration should have an easier mechanism for choosing 
>    payloads from the "default" directory, allowing them to be built
>    automatically. Right now I am doing:
>      cd filo-0.4.2
>      linux32 make CC="gcc -m32" LD="ld -melf_i386"
>      cd ..
>      freebios2/targets/buildtarget amd/solo $PWD/freebios2
>      cd build-solo
>      make
>      cd ..
>      cp build-solo/solo.rom .
>    My target Config.lb comes with these constructs:
>      target  ../../../../build-solo
>      payload ../../filo-0.4.2/filo.elf
>    So I build everything completely out of the freebios2 tree, because
>    building in-tree sucks. The only thing left is to get filo and the
>    other payloads to build out-of-tree as well.

Hmm.  I always have payload set to something like: 

payload ../../bootloader.ebi

So the symlink part comes naturally.  

Given that building out of the tree is our encouraged state.  What we
likely need to do is to actually have something like configuration
that sets up the environment for the user.  

That way it can be as simple as:
../freebios2/configure --mainboard=arima/hdama 

What I should probably do is dig out the LinuxBIOS source rpms that I
use and see if there is something that the community can adopt from


More information about the coreboot mailing list