[coreboot] Fwd: [patch] tint payload update

[Uwe Hermann]

On Thu, Sep 16, 2010 at 03:37:24PM -0600, Marc Jones wrote:
> On Wed, Sep 15, 2010 at 3:09 PM, Peter Stuge <peter at stuge.se> wrote:
> > Marc Jones wrote:
> >> > As for the build things, can we not get around stuffing all of that
> >> > into each payload?
> >>
> >> What do you mean? It seems to me that we want each payload
> >> responsible for building its own version of libpayload.
> >
> > I hadn't thought of that! Do we? Interesting.
> >
> > In a way it makes sense because different payloads need different
> > parts of libpayload. But thinking of it as a replacement for glibc or
> > at least crt0 then it isn't so nice to have more than one. This is
> > how I've always thought of it until now.

There are pros and cons to both variants, but I think we cannot make a
fully generic libpayload build that gets installed somewhere and then
used by multiple payloads directly.

We could drop most "Add support for xyz" kconfig options from libpayload
that simply add new functions to the API and just always compile them in
directly, and let the linker do its magic to only link in those
functions the respective payloads actually uses.
This is possible (but not yet in the Makefiles I think).

However, there are various options (and more will follow) that modify
the _behavior_ of libpayload functions thus making it impossible to
satisfy all possible payloads from one libpayload build.

Example: There's a kconfig option which decides whether libpayload
printf()/putchar() etc. should print to both serial and VGA or only one
of them. The putchar() function is always compiled in, but it's
behaviour is different.
Another example: Some boards (VIA I think) need different CMOS/NVRAM
config port locations (0x72/0x73 vs. 0x74/0x75). And there are others.

So I think one libpayload build/checkout per payload will be indeed
required usually.


> > But ok, say we want local libpayload per payload, then I think we
> > should still try to simplify things.

Yes, definately.


> Updating the wiki now.

Marc, can you please add the full build instructions to the wiki page,
including how and where libpayload should be checked out
(or "svn export"ed) relative to tint, whether or not libpayload should
use the "make install" step before building tint etc. etc.

The current code in svn plus wiki instructions didn't work for me,
various issues it seems. First the "libpayloadbin" is never found (if
you do "make install" in the libpayload dir it installs into an
"install" subdir of the libpayload dir currently. Also, in some
situations lpgcc yields errors as $CC seems to be not set or similar
(probably due to incorrect placement of the libpayload dir?)


Maybe it's simpler to just assume a full coreboot checkout for building
payloads per default? I.e. in payloads/external/tint, we assume a
../../libpayload to be there and contain a built libpayload per default?

Of course, there should be an option to override this and build a
payload by itself with only a libpayload checkout (without the full
coreboot checkout).


Thanks, Uwe.
-- 
http://hermann-uwe.de     | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org