On Thu, Mar 27, 2014 at 6:13 AM, Patrick Georgi patrick@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