[coreboot] [PROPOSAL] Obsoleting support for non-CAR boards

Alex G. mr.nuke.me at gmail.com
Sun Feb 27 13:28:48 CET 2011


We've all been thinking about it, though never said it much. It's
obvious that non-CAR boards have become a drag recently: we have to find
workarounds the romstage linking system in order to move forward with
some ideas.

Let's take for example removing .c includes from the source tree. We
have an elegant way to specify which files should be compiled and link
into romstage by
romstage-y: your_favorite_file.c
This works fine if we put it in the board's Makefile.inc, yet is ugly,
and will break non-CAR boards if we happen to put it in the Makefile.inc
of a device that is used by a non-CAR board.

I can see non-CAR being a problem for any sub-point that deals with
avoiding code duplication, including, but not limited to, removing .c
includes, refactoring smbus code, and many of the refactoring ideas
having to do with romstage

I assume that CPUs and boards which do not support cache-as-ram in the
hardware are already old enough to be considered obsolete. Maintaining
those is an extra effort that nobody here really seems to be willing too
put up with.

As a result, I propose we continue with the code refactoring described
here http://www.coreboot.org/Infrastructure_Projects without regard to
non CAR-capable hardware. If we happen to break the build for such a
board, we let it broken, and if it can not be fixed without going back
on the new design philosophy, remove it from the tree entirely.
Interested individuals, if any, can still checkout older revisions, and
we can move forward with a cleaner, more efficient build system

Alex

Signed-off-by: Alexandru Gagniuc <mr.nuke.me at gmail.com>
Acked-by: Alexandru Gagniuc <mr.nuke.me at gmail.com>




More information about the coreboot mailing list