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@google.com wrote:
On Fri, Nov 6, 2015 at 5: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?
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:
- 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).