[coreboot] Rebuilding coreboot image generation

[Julius Werner]

>> 1. Some platforms want it in a fixed placed. I'd like that to change,
>> but there is a need currently. Also, if we put microcode in a
>> different place then we'd have to change the code which reads cbfs to
>> get the microcode file later when loading microcode for other cpus,
>> etc.

Sure, we might have to change code that looks for it... but I'd
presume (without knowing that code) that it should be a minor and
pretty straight-forward change compared to this big rearchitecture of
our build system, right?

Also, I'm not saying we should do this on all Intel platforms
(although we might, depending on what makes it easier). We could only
do it for the ones that need it (Skylake?) and make those use a
different FMD file.

(About the FMD files, I think there are many small differences that
could be solved by either making separate FMD files (and living with a
bit of code duplication), or using Kconfig variables and #ifdefs to
make one file fit multiple cases. I think taking either of those
options to the extreme would be bad, and we'd probably want a middle
road of both depending on what works best for a certain situation. I
still think that's a good system... the FMD format is dead simple to
read/understand, and every developer already knows how #ifdefs and
Kconfigs work without having to become familiar with some completely
custom system.)

>> 2. bootlbock is a little different too. While the reset vector is at
>> at the end of the region mapped just below 4GiB we don't have it be a
>> fixed size currently. Because of that you effectively have downward
>> growing stack behavior w.r.t. where things eventually land. That's
>> currently handled by the linker proper.

Right. That's why I'm saying I would change that... make the bootblock
area a pre-defined size (maybe based on a Kconfig). Sure, we'll waste
some space... but that's at most a few kilobytes of ROM, and in return
I think it makes the whole thing much easier to understand and work
with than the current CBFS-style bootblocks.

>> 3. FSP on these newer intel platforms is linked XIP. However, we did
>> add relocation to that as well so that we no longer had to fix the
>> location. But that's only effective for the FSP requirements post
>> cache-as-ram. Currently cache-as-ram on these FSP platforms is brought
>> up in FSP. And identifying the location of FSP w/o a stack is leads to
>> the current fixed location. I'm hoping to rectify this situation going
>> forward because these requirements are unnecessarily binding us,
>> however this is the current situation as of today.

Is this runtime or compile-time relocation we're talking about?
Because I would presume compile-time relocation (which would be good
enough for cbfstool) shouldn't make a difference about pre-/post-CAR?

Anyway... from a purist's perspective (without knowing any details),
this also sounds to me like if the FSP (or those parts of it)
absolutely *must* be placed at an exact offset, it doesn't belong in
CBFS and should have its own FMAP section. I mean, I think this is the
whole reason why we (want to) have an FMAP... we could also keep a
whole Chrome OS image inside CBFS if we just carefully adjust the
offsets enough, but that would be terribly unmanageable, because CBFS
just isn't a good tool for exact placement.

>> I think the coreboot manifest just decided which cbfs region to add a
>> file. The other stuff was flash layout. Sadly, I haven't seen fmd
>> fully rolled out or this so I can't tell with certainty what either
>> looks like. fmd proper is just flash layout and doesn't fix the "what
>> cbfs region and what flags" for each file nor the scheduling for
>> optimal placement.

Sure, I see FMD as a building block of a whole solution, not the
solution itself. (And I'd say that building block is pretty rolled out
already... all the code for it is checked in and you can already run
'fmaptool input.fmd output_fmap.bin' today.

>> I think Patrick's concern w/ the layout having a chipset portion was
>> so that one didn't have to touch every mainboard when changing
>> something in the chipset that required such a layout change. I think
>> you suggested #include files and he was opposed to it. I think the
>> disagreement using the c preprocessor is where the design changes stem
>> from (If i'm reading things correctly).

I'm not married the preprocessor, I certainly agree that there are a
lot of ugly things about it. I was suggesting #include as a concept
for FMD, not necessarily implemented through CPP. We also don't need
to make one FMD file per board (which would then usually just #include
a generic one, like memlayout)... we could instead think about
symlinks, or using some kind of CONFIG_MAINBOARD_HAS_CUSTOM_FMD... I'm
more arguing for general concept than details right now. (The one nice
thing that has to be said about CPP, though, is that every developer
already knows how it works. I think it has a much lower barrier to
entry than any custom mechanism for this we could whip up, and it is
quite flexible... I think for the uses I'm suggesting here, those
qualities would make it the best choice.)