Re: [coreboot] [announce] coreboot for the 21st century

[Patrick Georgi]

      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

[announce] coreboot for the 21st century

[Andrew Wu]

      2014-03-27 22:26 GMT+08:00 Patrick Georgi <patrick(a)georgi-clan.de&gt;:
  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.
I agree your idea. It should be not difficult for Vortex86EX. :)


Andrew