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.
Patrick
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
On 03/27/2014 03:13 PM, Patrick Georgi 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.
Patrick
Can we think of building vortex86ex raminit in bootblock? Having a quick look at it, it seems SPD / SMBus is not involved and only the bank geometry is programmed in PCI config space.
We are still stuck with romcc for x86 bootblock for quite some time. And microcode updates done in bootblock will continue to use MSRs and CPUID so is there much that can be cleaned out there?
I have patches in review queue that effectively remove the duplicate implementation of UART console for ROMCC boards. But the macros like print_debug() are used all over the tree, not just ROMCC boards.
Kyösti
2014-03-27 21:55 GMT+08:00 Kyösti Mälkki kyosti.malkki@gmail.com:
On 03/27/2014 03:13 PM, Patrick Georgi wrote:
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.
Can we think of building vortex86ex raminit in bootblock? Having a quick look at it, it seems SPD / SMBus is not involved and only the bank geometry is programmed in PCI config space.
Yes, I believe I can simplify and move RAM init code from romstage into bootblock. But we still need romcc to compile this part, doesn't it?
Andrew
2014-03-27 21:13 GMT+08:00 Patrick Georgi patrick@georgi-clan.de:
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.
Sorry for late reply. Vortex86EX romstage code relies on coreboot library mainly for CPU and hardware I/O register access, and debug messages(print_debug/print_emerg, etc). So I think it is not hard to rewrite this part.
Andrew