rom files in Config.lb

[Myles Watson]

Here's the usage:

# Tyan s2892
romimage "fallback"
    option USE_FALLBACK_IMAGE=1
    option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback"
    payload ../payload.elf
end

buildrom ./coreboot.rom ROM_SIZE "fallback"

pci_rom ../ragexl.rom vendor_id = 0x1002 device_id = 0x4752
pci_rom ../nic.rom vendor_id = 0x1100 device_id = 0x4152

Here are the results:

rm -f coreboot.cbfs
./cbfstool ./coreboot.romfs create 1048576 98304 ./coreboot.rom.bootblock
if [ -f coreboot.romfs ]; then ./cbfstool coreboot.romfs add
../ragexl.rom pci1002,4752.rom 48; fi
if [ -f coreboot.romfs ]; then ./cbfstool coreboot.romfs add
../nic.rom pci1100,4152.rom 48; fi
if [ -f fallback/cbfs-support ]; then ./cbfstool ./coreboot.romfs
add-payload ../payload.elf fallback/payload `cat
fallback/cbfs-support`; fi
./cbfstool ./coreboot.romfs print
./coreboot.romfs: 1024 kB, bootblocksize 98304, romsize 1048576, offset 0x0
Alignment: 16 bytes

Name                           Offset     Type         Size
pci1002,4752.rom               0x0        optionrom    36864
pci1100,4152.rom               0x9040     optionrom    36864
fallback/payload               0x12080    payload      65620

Signed-off-by: Myles Watson

Thanks,
Myles

[ron minnich]

it's really wonderful with one question: I note there is a hardcode
'48' in the config util. Shouldn't we be able to do without that kind
of number?

Also, will we ever want normal/something.rom and
fallback/something.rom? Not sure.

Thanks, this is a *great* thing to have. If you can get back to me on
that '48' I think this is ready to go in.

ron

[Kevin O'Connor]

On Thu, Apr 16, 2009 at 04:31:20PM -0700, ron minnich wrote:
> it's really wonderful with one question: I note there is a hardcode
> '48' in the config util. Shouldn't we be able to do without that kind
> of number?
>
> Also, will we ever want normal/something.rom and
> fallback/something.rom? Not sure.
>
> Thanks, this is a *great* thing to have. If you can get back to me on
> that '48' I think this is ready to go in.

48 == 0x30 == CBFS_TYPE_OPTIONROM

-Kevin

[ron minnich]

On Thu, Apr 16, 2009 at 5:55 PM, Kevin O'Connor  wrote:
> 48 == 0x30 == CBFS_TYPE_OPTIONROM

we really need to make that a symbolic name ... I completely forgot about that.

ron

[ron minnich]

Acked-by: Ronald G. Minnich

wonderful.

I didn't think I'd get to this for another long while :-)

ron

[Myles Watson]

Thanks Kevin for answering.
> > 48 == 0x30 == CBFS_TYPE_OPTIONROM
>
> we really need to make that a symbolic name ... I completely forgot about that.

Agreed.
> Also, will we ever want normal/something.rom and
> fallback/something.rom? Not sure.

I implemented it that way the first time, but I decided that most of
the time we want the same option ROMs for all images.  I guess that
might not be true if you were testing different versions of gpxe.

I ended up doing what I thought would be the most common case.

It makes me wonder if we should allow people to add payloads this way
too.  Is cbfs flexible enough to allow us to have one payload for
normal and fallback?

On Thu, Apr 16, 2009 at 8:34 PM, ron minnich  wrote:
> Acked-by: Ronald G. Minnich
>
> wonderful.
>
> I didn't think I'd get to this for another long while :-)

Rev 4127.

Thanks,
Myles

[ron minnich]

On Fri, Apr 17, 2009 at 6:50 AM, Myles Watson  wrote:
> It makes me wonder if we should allow people to add payloads this way
> too.  Is cbfs flexible enough to allow us to have one payload for
> normal and fallback?

Sure. it's just a name. It's all in how you walk the file system.

ron

[Myles Watson]

> > It makes me wonder if we should allow people to add payloads this way
> > too.  Is cbfs flexible enough to allow us to have one payload for
> > normal and fallback?
>
> Sure. it's just a name. It's all in how you walk the file system.

You're right.  The correct question was something more along the lines of
"How are we going to make it intuitive for people to be able to use the same
payload for multiple images?"

Are we going to always search for fallback/foo if we can't find normal/foo?
What about /foo?

I think it should be implemented once somewhere so that it's consistent.

Thanks,
Myles

[Marc Jones]

On Fri, Apr 17, 2009 at 9:30 AM, Myles Watson  wrote:
> > > It makes me wonder if we should allow people to add payloads this way
> > > too.  Is cbfs flexible enough to allow us to have one payload for
> > > normal and fallback?
> >
> > Sure. it's just a name. It's all in how you walk the file system.
>
> You're right.  The correct question was something more along the lines of
> "How are we going to make it intuitive for people to be able to use the same
> payload for multiple images?"
>
> Are we going to always search for fallback/foo if we can't find normal/foo?
> What about /foo?
>
> I think it should be implemented once somewhere so that it's consistent.

The cbfs types are meant to be extended as needed. A type for fallback
is a good idea.
CBFS_TYPE_STAGE_FALLBACK? I don't think that we are using the stage
concept yet but I think that it still fits v2.  I wonder if the
failover/fallback stuff can be cleaned up to be more like v3?

Marc

[ron minnich]

On Fri, Apr 17, 2009 at 9:21 AM, Marc Jones  wrote:
> I wonder if the
> failover/fallback stuff can be cleaned up to be more like v3?

I'm working on that. I just committed the first step: documenting How
It Works Now, since it is so confusing that I wanted to document it
first. I do have a first cut at v3-like startup in v2. My proposed
console.c patch came from that work. I'd still like to see an ack or
nak on that. I recommend an ack. The current 'initialized' variable in
console.c is just a bandaid for broken code.

The documentation is going to take a few more days, then I will use it
to revise my v3-to-v2 work, and you should see patches inside the next
two weeks. But it can be done.

At some point, all targets should have a failover.c, and failover.c
will use cbfs to locate the ROM image (fallback or normal) to run. I
think it can end up being very clean.

ron