- 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.
Sure, we might have to change code that looks for it... but I'd presume (without knowing that code) that it should be a minor and pretty straight-forward change compared to this big rearchitecture of our build system, right?
Also, I'm not saying we should do this on all Intel platforms (although we might, depending on what makes it easier). We could only do it for the ones that need it (Skylake?) and make those use a different FMD file.
(About the FMD files, I think there are many small differences that could be solved by either making separate FMD files (and living with a bit of code duplication), or using Kconfig variables and #ifdefs to make one file fit multiple cases. I think taking either of those options to the extreme would be bad, and we'd probably want a middle road of both depending on what works best for a certain situation. I still think that's a good system... the FMD format is dead simple to read/understand, and every developer already knows how #ifdefs and Kconfigs work without having to become familiar with some completely custom system.)
- 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.
Right. That's why I'm saying I would change that... make the bootblock area a pre-defined size (maybe based on a Kconfig). Sure, we'll waste some space... but that's at most a few kilobytes of ROM, and in return I think it makes the whole thing much easier to understand and work with than the current CBFS-style bootblocks.
- 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.
Is this runtime or compile-time relocation we're talking about? Because I would presume compile-time relocation (which would be good enough for cbfstool) shouldn't make a difference about pre-/post-CAR?
Anyway... from a purist's perspective (without knowing any details), this also sounds to me like if the FSP (or those parts of it) absolutely *must* be placed at an exact offset, it doesn't belong in CBFS and should have its own FMAP section. I mean, I think this is the whole reason why we (want to) have an FMAP... we could also keep a whole Chrome OS image inside CBFS if we just carefully adjust the offsets enough, but that would be terribly unmanageable, because CBFS just isn't a good tool for exact placement.
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.
Sure, I see FMD as a building block of a whole solution, not the solution itself. (And I'd say that building block is pretty rolled out already... all the code for it is checked in and you can already run 'fmaptool input.fmd output_fmap.bin' today.
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).
I'm not married the preprocessor, I certainly agree that there are a lot of ugly things about it. I was suggesting #include as a concept for FMD, not necessarily implemented through CPP. We also don't need to make one FMD file per board (which would then usually just #include a generic one, like memlayout)... we could instead think about symlinks, or using some kind of CONFIG_MAINBOARD_HAS_CUSTOM_FMD... I'm more arguing for general concept than details right now. (The one nice thing that has to be said about CPP, though, is that every developer already knows how it works. I think it has a much lower barrier to entry than any custom mechanism for this we could whip up, and it is quite flexible... I think for the uses I'm suggesting here, those qualities would make it the best choice.)