On Fri, Nov 6, 2015 at 5:17 PM, Julius Werner jwerner@chromium.org wrote:
- 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?
Well, some of those code paths are common to many x86 systems. And the biggest thing I don't particularly like about that approach (ignoring how one would need to handle things different at compile time) is the lack of consistency. I don't mind the mix of cbfs and fmap, but I think using both for the granularity of a single "file" is odd.
w.r.t. to a "big rearchitecture" I don't think it's that. It was my understanding that the cbfs-file-* entries in the Makefiles would be used to generate the manifest. As it currently stands fmd hasn't been rolled out yet. Both approaches need to parse the file to know fmap location such that we don't *require* a Kconfig and the fmap description to make things line up. The second pass is adding the files (and where they go).
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.)
I don't think Patrick's proposal is too complicated either. I think Patrick was attempting to solve both sets of problems (the one FMD solves currently and the cbfs file scheduler). The scheduler problem leverages the description of the fmap.
- 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.
I understand your proposal. It sounds straight forward -- not sure how big of a pain it is. Definitely doable though. Just solves one issue.
- 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?
The current situation is that relocation *does not* work now. The assembly code expects it to be at a specific place. There is both compile time and runtime relocation doing for Chrome OS because of the RO, RW-A, and RW-B region. However, the RO one is a hard coded location.
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.
Again then this becomes an inconsistency on Chrome OS. FSP lives in RO, RW-A, and RW-B regions. RW-A and RW-B will be CBFS. So do make it it partly CBFS and partly FMAP such that the code is consistent to use FMAP APIs throughout? In my opinion that isn't appropriate. From a "change this little bit of code here" thing it's doable. But from looking at source code I standpoint such it's inconsistent. Sure FMAP would be used in certain places, but I'd argue those are in the infrastructure parts that many people porting things don't deal with. I don't want people to head scratch where something should live and then figure out 1. how to access it and 2. how to add it properly. The latter is still not plumbed in anywhere in the build system.
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.
No. It's not rolled out. Nothing uses it. header files aren't generated to replace Kconfig, etc. fmd files aren't used for building, etc. Yes, the code is there. The realization of utilizing it as a first-class citizen is not complete. Therefore, it is speculation on everyone's part to know how much duplication there is or not. In either case (sorry beating a dead horse) the scheduling of cbfs file addition is not fixed, but I think your suggestion is: all those special cases punt to fmap and have a fixed size because it makes it easier?
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.)
I like the CPP, but I still don't think utilizing it w/ FMD solves all problems w.r.t. cbfs file adding.