Whoops... sorry, I meant to keep the discussion on the list.
On Fri, Nov 6, 2015 at 3:17 PM, Julius Werner jwerner@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.