Hi Cameron,
Cameron Craig wrote:
I have managed to create a bootable image using an out of date copy of coreboot and U-Boot, provided by Intel under NDA.
coreboot code is always covered by the GPL, regardless of where it came from. If Intel tries to bind you in a contradictory agreement I don't think that holds. Check with a lawyer.
I think U-Boot is GPL-licensed too.
The stitching process used to generate the image is a little ugly: a set of Windows tools are provided (or pointed at) by Intel to stitch the various blobs together to create an 8MB image. We would like to move away from this process. Using the cbfs tool it looks like we are getting a legacy image composed entirely of a single CBFS.
What does a current cbfstool print output for that image?
However, as far as I understand, the latest coreboot release (v4.6) should be capable of producing a 16MB working image without the use of external tools.
I would suggest reducing variables. So start with the same size. And reuse as many bits and pieces (descriptors, blobs, etc.) as possible from the working image.
Extract Flash Descriptor from an existing Leaf Hill UEFI image (./ifdtool --extract leaf_hill_ref_board_uefi.bin)
What about the flash descriptor from the working forked coreboot build?
Other than that, I currently have no working theories as to what the root cause is ☹
Firmware development is lots of fun! :)
Is there anything obviously wrong with this process?
If the flash descriptors match and bar the added variables then no, not really.
I would recommend to focus on increasing debug capability. If all else fails then even looking at the SPI flash clock and data signals with a scope or logic analyzer can be useful.
If there's a speaker on the board then you can try spkmodem. It's noisy, but fun, and works early.
//Peter