[coreboot] Questions about CBFS

Thomas Jourdan tjourdan at neuf.fr
Thu Aug 20 22:38:33 CEST 2009

Patrick, all

> > - When a payload is parsed and added in the CBFS rom, is there any way
> > to know if this is 32 or 64 code ? I added a field elfclass in the
> > cbfs_payload structure to keep the information.
> >    
> Sounds good to me, that's what the subheaders are for.

I just send some patches for 64 bits payloads. More details in them.

> > Other question : what is the correct way to insert code running from ram
> > (a stage) in the bootblock or at a fixed location ? In my case, after
> >    
> The bootblock should be left alone after it's generated. CBFS has 
> nothing to do with it.
> > But I need to be sure that this custom stage lives in the top block (64
> > KB) of my FWH (2MB). Is there any way to specify this ?
> >    
> Right now, the top 64kb are usually managed by the bootblock. The code 
> that coreboot jumps to after CAR is also there, the stages in CBFS are 
> the compressed RAM stages.
> So you'll have to shove your recovery stage into the bootblock 
> "somehow". The easiest solution in the old buildsystem is probably to 
> add another stage (besides failover/fallback/normal), and special case 
> its build somehow (so the ram stage isn't built or linked).
> The new build system only supports building one variant for now, until 
> we figured out how to properly do it with the capabilities CBFS gives us.

In my case CBFS is mandatory, I can not use the old buildsystem. I found
a solution to solve my problem with CBFS. As I said, I need to have the
bootblock and the recover stage in the top block of the FWH.

First of all, I reduced the size of the bootblock to 48 KB, which gives
me 16 KB for the recover stage, which is enough. Then, I modified the
cbfstool to add files backwards. In CBFS, when a file is added, the free
space is split in 2. The "left" part (with lowest offset) will hold the
file we are adding, and the right part (with highest offset) will be the
remaining free space. I swapped this so files are inserted backwards.
This way, if I add the recover stage first, it will be right before the

I don't know much for amd southbridges, but with intel SB, there is a
top swap block bit in a register of the LPC bridge. This is usefull to
backup and swap the topblock when updating the firmware. This way, there
is always a valid bootblock, even if the power fails during update. In
order to always be able to reflash, the top block must contain the
bootblock and some code to recover.

It's easier to handle this kind of behaviour when files that compose the
firmware are stored from the top of the FWH. 


More information about the coreboot mailing list