[coreboot] Rebuilding coreboot image generation

[Julius Werner]

Whoops... sorry, I meant to keep the discussion on the list.

On Fri, Nov 6, 2015 at 3: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?
>
> 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?
>
>> 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).
>
>> 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.
>
> 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.