I took the discussion to IRC, to avoid endless back-and-forth by mail.
In summary:
The plan is to enable us to write romstage code with the expectation
that at least some RAM (through CAR) is available. (while bootblock is
expected to work without RAM of any kind, and ramstage has the full RAM
available)
If someone wants to use romcc for romstage, that means working without
other object files (since romcc never emits a "call" instruction, except
when hand-assembled). Thus reusing other .c files in romcc means
"#include *.c" as it always did.
Proposal: If someone goes that route, and things break due to the .c
files of the coreboot core being too complex for romcc to handle, they
get to keep the pieces - it's unsupported.
I expect special cases like Vortex (or old chipsets like Via C3, if
someone has the interest and time to do the port) to have a simple
enough RAM initialization that they can be implemented as standalone C
code. That's still _much_ more comfortable than writing assembly, and
it'll work: it has one entry-point (like CAR code), one exit point
(calling into common C code to load the next stage), and everything
inbetween is compiled by romcc to work without RAM.
Should we find out that all the hundred ancient ram inits we get
contributed reimplement the same things over and over, we can still
consider moving those parts to src/lib/romcc, neatly separated from
regular romstage code.
Regards,
Patrick
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
