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. > 4. 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 -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
