CBFS breaks relative payload paths

[Richard Smith]

Without CBFS a payload path like

payload ../../bios.vx855.090330.bin.elf

works.  This is nice because I don't lose my binaries everytime I blow 
away the work directory and keeps them in a location where copying (or 
tarballing) the trees around keeps the images with them.

If you try to build with CBFS then this fails.  Looks like the cbfstool 
runs in a directory that is one level above from 'image'.

I see a tools directory but cbfstool is not build there but rather one 
level up.

Seems reasonable to me that the build should copy the working files into 
the image directory and work with them from there.

[ron minnich]

On Tue, Apr 14, 2009 at 2:49 PM, Richard Smith  wrote:
> Without CBFS a payload path like
>
> payload ../../bios.vx855.090330.bin.elf
>
> works.  This is nice because I don't lose my binaries everytime I blow away
> the work directory and keeps them in a location where copying (or
> tarballing) the trees around keeps the images with them.
>
> If you try to build with CBFS then this fails.  Looks like the cbfstool runs
> in a directory that is one level above from 'image'.

It is. It's a fundamental change. I don't know an easy way to fix it.

But my payload path of ../payload.elf works ok anyway.
> Seems reasonable to me that the build should copy the working files into the
> image directory and work with them from there.

Depends on what you mean by image directory. Do you mean normal/ or do
you mean the top level build directory? It used to be that the payload
was attached to, e.g., normal/coreboot.strip. no longer. It's now
attached to coreboot.rom. Relative paths continue to work -- but they
are going to be one less .. from before, because the cbfs utility is
run one level higher.

Anyway, if you have a patch to improve this, it might be good to see.

Thanks!

ron