Whoops... sorry, I meant to keep the discussion on the list. On Fri, Nov 6, 2015 at 3:17 PM, Julius Werner <jwer...@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.
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot