[coreboot] Rebuilding coreboot image generation

[Aaron Durbin]

And I didn't notice it was not on the list when it 'a' in gmail...

On Fri, Nov 6, 2015 at 5:32 PM, Aaron Durbin <adurbin at google.com> wrote:
> On Fri, Nov 6, 2015 at 5:17 PM, Julius Werner <jwerner at chromium.org> wrote:
>>> That suggestion leads to different software using fmap vs CBFS for
>>> finding and locating specifics assets that are required for booting.
>>> In fact that would fundamentally break x86 w.r.t. common stage loading
>>> because of the xip requirement. I don't think that's a good thing.
>>
>> Hmm... I don't really understand where you're seeing problems
>> regarding XIP there. I've got to admit I don't understand that area
>> very well though, especially since a lot of that changed recently.
>>
>> Just to be clear, I didn't mean to say that all XIP stages should go
>> into separate FMAP sections... those can stay in CBFS as they
>> currently are. I didn't intend to include everything XIP with "needs
>> to be placed exactly"... because they theoretically can be placed
>> anywhere (right? or are there limits?), they just need to be
>> explicitly linked to that offset once it has been decided. I know that
>> we used to link the romstage to offset 0x0, take the resulting binary
>> size of that to help layout CBFS, then link it again with the now
>> known offset... seems like all of that moved into cbfstool now, but in
>> theory it should still work just as well (regardless of the order the
>> files get added in and where the stage ends up being placed in the
>> end), right?
>
> Yes. That will work. However, we need to pass flags to cbfstool when
> we do add-stage to make that work.
>
>>
>> I think the case of that microcode blob is different because it seems
>> to need an exact offset (at least that's what the whole hardcoded
>> CONFIG_CPU_MICROCODE_CBFS_LOC thing looks like to me). Same for the
>> bootblock, which always needs to be placed into the reset vector (and
>> hasn't previously been a CBFS "file" anyway). Does that make it
>> clearer or did I misunderstand your concerns?
>
> Well there are few subtleties:
>
> 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.
> 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.
> 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.
>
>>
>>> Those requirements are not necessarily known until link time.
>>
>> Which ones are you thinking of in particular?
>> CONFIG_CPU_MICROCODE_CBFS_LOC seems to be hardcoded right now (unless
>> I misread how that works). The bootblock size is determined at link
>> time, but I don't think it needs to be... i.e. I think it's fine to
>> just reserve a certain bootblock FMAP section with the maximum size we
>> expect to need, and waste a few K of space if necessary. We could also
>> make it configurable with a Kconfig to allow more fine tuning by
>> preprocessing FMD files. I think that would be much more reasonable
>> and easier to work with than the current model of mushing the
>> bootblock somewhere in the CBFS area in a way that even cbfstool
>> cannot modify/extract again after the fact. It would also allow us to
>> further simplify the CBFS format (removing the need of the master
>> header and the concept that only a certain part of the full CBFS image
>> is space available for files... which was another goal of the CBFS
>> redesign earlier this year that had unfortunately not been finished).
>
> It can be changed, yes. However, I was just noting that's not how
> things work. As noted above bootblock is not the only thing.
>
>>
>>> But some files need special flags. One of the harder things is
>>> identifying all the assets to fit into those 2 buckets. I personally
>>> think one stop shopping in a single file is way better than digging
>>> through Makefiles.
>>
>> Well, but I don't think Patrick's proposal is one-stop-shopping
>> either... rather, it splits both layout and file information across
>> multiple manifests in the same way that CBFS file rules are already
>> split across our Makefiles.
>
> 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.
>
>>
>> Personally, I'm more concerned with keeping the layout in one place.
>> For the decision of which files are included I think the current split
>> is reasonable... especially since you need to add extra files based on
>> chipset or board much more often than you need to add extra sections,
>> and in an "ideal" CBFS (where no file has magic placement
>> requirements) it doesn't really matter that much how many files get
>> included in the end (as long as the total size is sufficient which
>> usually doesn't seem to be a problem).
>>
>> But I'd be open to discuss how to handle the files more centrally if
>> you have a good idea for that... I just think that it should be
>> separated from the (central) FMAP layout.
>
> 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).