[coreboot] patch: add romfs to V2

ron minnich rminnich at gmail.com
Tue Mar 31 07:09:06 CEST 2009

On Mon, Mar 30, 2009 at 9:36 PM, Peter Stuge <peter at stuge.se> wrote:

> Hmm, I remember Jordan didn't like the archive concept, and ISTR he
> prefered fs, as suggested by the romfs name too. I think an *fs name
> makes sense when there is a master structure like here.

I don't want it to become ext2. Sure, we can make it complicated, but
that's a mistake.

>> 2. ORBC->LAR2
> Shouldn't 1. and 2. be in sync somehow?

Sure. Suggest something! :-)

> Yeah. I don't know. :\ It depends on how early in the stack this
> problem is relevant. For coreboot+SeaBIOS it will never become an
> issue. Want to make use of more stuff - then maybe you need better
> hardware. Does that seem fair?

Yes. I think we ought to be willing, when confronted with stupid
hardware, to say "Sorry, your hardware is too stupid to run coreboot".
We just can't cover every single piece of hardware -- right now we
don't cover much at all, and diverting huge effort for bad hardware
doesn't make sense to me.

look, long term, if EFI happens, or if bigger BIOS happens, ROM will
be memory addressable.

I don't think stupid hardware designs will continue to be the rule. I hope not.

> I do however think it would suck to intentionally regress on m57sli,
> or any other board.

I should mention that the patch I will submit (once this one goes
through) won't regress anything. The old way continues to work fine
(tested). The new way works too. You pick which one you want in either
the target or mainboard file. The default is CONFIG_ROMFS=0.

I.e. it is quite backward compatible (abuild tested; tested with
ROMFS^H^H^H^H^HLCAR on qemu and kontron).
It only builds an LCAR image if CONFIG_ROMFS^H^H^H^H^HLCAR is 1.

This is designed to be a very painless transition.

OK, this is going to be a question. Why am I suddenly back on v2? The
reason is simple. We've been baking v3 for 30 months and ... we're not
there except on a very few boards. Most vendors are still doing v2 for
the most part. V2 has grown tremendously since Oct. 2006 when we
designed v3. The development on v2 has been so good, in fact, that in
many feature areas v2 is now far ahead of v3: ACPI, SMM, S3 resume,
etc. etc.

To put it simply, I think we have to use v3 as the "good ideas and
lessons learned" testbed, and bring ideas we learned from there back
into v2. And that is what I am doing. LCAR is the first step.

I don't plan to put LCAR into v3. In fact I think I am done with v3.
It was a beautiful thing but it is time to move forward and bring the
good parts of v3 into v2 ... and realize that a lot of very fine work
has been done on v2, and it's simply not possible at this point to
move all that work to v3. We have to evolve, now, and do so in a way
that merges the best ideas of v3 back into v2.

I don't think v3 will end. It is the definitive Geode platform, in my
view. But the geode will end someday.

So I'm back.

> As for the name I can not stress enough how important it is to come
> as close as possible to something unique, especially when there is a
> unique purpose (and noone has publically standardized firmware flash
> chip content before), and this particular area is a very confusing
> minefield for newcomers already. We lose way more by ignoring that
> and making things worse than we can ever gain from the best technical
> storage solution. :\

The thing is, I use a lot more than linux, so this naming thing
doesn't bother me that much. I use several different OSes that have a
rom or ram or whatever fs.

But if you want a name that is evocative of coreboot .... we can do
the "core" thing in the name (corefs?) or we can just go with LCAR
(wow, that is hard to say in many places! -- can we possibly put a few
more vowels in there?) or we can try to pick a good name in the next
few days. But I don't want to hold this new stuff up forever while we
debate on a name.


More information about the coreboot mailing list