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

[Aaron Durbin]

On Thu, Mar 27, 2014 at 6:13 AM, Patrick Georgi <patrick at georgi-clan.de> wrote:
> Am 2014-03-27 14:00, schrieb Andrew Wu:
>
>> So if I want to get rid of romcc, maybe I have to write DRAM init code
>> in assembly, That is not very easy. :(
>
> If you can make it compile in romcc without relying on coreboot base
> libraries, we could keep Vortex86 RAM init building via romcc. As I
> understand Stefan, his main motivation for this push is to clean out all the
> romcc related special cases in coreboot's core.
>

That's part of it. If we want a richer set of APIs that all
boards/chipsets can use in at least romstage and ramstage then we have
to draw the line on having a "memory". Otherwise we carry a lot of
inconveniences for a minority of boards/chipsets that can't
accommodate that requirement. I personally don't think that's a
trade-off that should be made.

As for the Vortex86, I'm sure we can come up with something. Off the
top of my head I'd suggest having raminit in bootblock then there
isn't a possibility of running into issues. The current classes for
compilation (ramstage, romstage, bootblock) don't come with strong
semantics w/ what is supported. For example, an ARM SOC would
typically have ram in all 3, but x86 device currently can only assert
there is ram in ramstage. That's a lot of combinations to handle that
entirely depends on the chipset/board. If one wants to use the same
core code in many (all?) of those stages then the least common
denominator is required of *all* chipsets/boards.

-Aaron