[coreboot] Rebuilding coreboot image generation

[Aaron Durbin]

On Fri, Nov 6, 2015 at 5:17 PM, Julius Werner <jwerner at chromium.org> wrote:
>>> 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?

Well, some of those code paths are common to many x86 systems. And the
biggest thing I don't particularly like about that approach (ignoring
how one would need to handle things different at compile time) is the
lack of consistency. I don't mind the mix of cbfs and fmap, but I
think using both for the granularity of a single "file" is odd.

w.r.t. to a "big rearchitecture" I don't think it's that. It was my
understanding that the cbfs-file-* entries in the Makefiles would be
used to generate the manifest. As it currently stands fmd hasn't been
rolled out yet. Both approaches need to parse the file to know fmap
location such that we don't *require* a Kconfig and the fmap
description to make things line up. The second pass is adding the
files (and where they go).

>
> 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.)

I don't think Patrick's proposal is too complicated either. I think
Patrick was attempting to solve both sets of problems (the one FMD
solves currently and the cbfs file scheduler). The scheduler problem
leverages the description of the fmap.

>
>>> 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.

I understand your proposal. It sounds straight forward -- not sure how
big of a pain it is. Definitely doable though. Just solves one issue.

>
>>> 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?

The current situation is that relocation *does not* work now.  The
assembly code expects it to be at a specific place. There is both
compile time and runtime relocation doing for Chrome OS because of the
RO, RW-A, and RW-B region. However, the RO one is a hard coded
location.

>
> 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.

Again then this becomes an inconsistency on Chrome OS. FSP lives in
RO, RW-A, and RW-B regions. RW-A and RW-B will be CBFS. So do make it
it partly CBFS and partly FMAP such that the code is consistent to use
FMAP APIs throughout? In my opinion that isn't appropriate. From a
"change this little bit of code here" thing it's doable. But from
looking at source code I standpoint such it's inconsistent. Sure FMAP
would be used in certain places, but I'd argue those are in the
infrastructure parts that many people porting things don't deal with.
I don't want people to head scratch where something should live and
then figure out 1. how to access it and 2. how to add it properly. The
latter is still not plumbed in anywhere in the build system.

>
>>> 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.

No. It's not rolled out. Nothing uses it. header files aren't
generated to replace Kconfig, etc. fmd files aren't used for building,
etc. Yes, the code is there. The realization of utilizing it as a
first-class citizen is not complete. Therefore, it is speculation on
everyone's part  to know how much duplication there is or not. In
either case (sorry beating a dead horse) the scheduling of cbfs file
addition is not fixed, but I think your suggestion is: all those
special cases punt to fmap and have a fixed size because it makes it
easier?

>
>>> 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.)

I like the CPP, but I still don't think utilizing it w/ FMD solves all
problems w.r.t. cbfs file adding.