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 <adur...@google.com> wrote: > On Fri, Nov 6, 2015 at 5: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? > > 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).
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot