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

[Patrick Georgi]

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

[announce] coreboot for the 21st century

[Aaron Durbin]

On Thu, Mar 27, 2014 at 6:13 AM, 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.

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

[announce] coreboot for the 21st century

[Kyösti Mälkki]

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

[announce] coreboot for the 21st century

[Andrew Wu]

2014-03-27 21:13 GMT+08:00 Patrick Georgi :
> 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

[announce] coreboot for the 21st century

[Andrew Wu]

2014-03-27 21:55 GMT+08:00 Kyösti Mälkki :
> 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