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 bootblock.
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.
Regards, Thomas