[coreboot] CBFS transition plan
mylesgw at gmail.com
Tue May 5 17:24:26 CEST 2009
On Tue, May 5, 2009 at 9:20 AM, ron minnich <rminnich at gmail.com> wrote:
> On Tue, May 5, 2009 at 8:13 AM, Myles Watson <mylesgw at gmail.com> wrote:
>> b. Normal should be stored in CBFS, not concatenated into the bootblock.
> I would argue that fallback should also be in CBFS. Which is fine, but ...
I agree. I just think that it can be a future step.
>> 2. Delete - Delete works on the assumption that you want contiguous files
>> a. I'm not convinced that fixed CBFS areas will be simpler than
>> ldscripts. I consider them both ugly.
> How are we going to support code that runs at a fixed address? I can
> only come up with
> these two options. I think the PIE stuff from v3 is not an option:
> we've been warned about
> it for a while now, and I now believe the warnings.
I wish I knew the best answer here.
>> 4. Geode ROM handling in CBFS.
>> a. It would be nice to change the code so that it doesn't have to
>> be in a fixed location (maybe via a copy to RAM?)
>> I guess the short version is that I'd like to keep all the ugly
>> details in the bootblock and peel them out one at a time. I think
>> we'll break fewer boards that way. I feel like we've been lucky to
>> catch some of the little glitches lately, and we've had help from
>> people being willing to bisect.
> good points. But, we're at step 1b and we need to make a decision. Our
> current decision, by default, is 'use ldscripts to create fallback and
> normal images, not cbfs'.
I think we can put off the decision if we insert CBFS code to find the
normal image and jump to it.
> If you look at how the normal symbol is created in the fallback image,
> I don't see that fixed-location cbfs files are any uglier ...
It's ugly. I hope that adding normal images in CBFS without changing
fallback will help us see the pathway forward.
More information about the coreboot