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
Hi Peter,
What does a current cbfstool print output for that image?
See the attached cbfs output, it doesn’t look very useful.
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.
Yeah, I think I've ruled out the flash descriptor being the problem.
What about the flash descriptor from the working forked coreboot build?
I tried the flash descriptor from the working coreboot flash image, still nothing.
Firmware development is lots of fun! :)
I'm beginning to see that :)
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 I exhaust my options then yes, I'll have to dance with the electrons :)
If there's a speaker on the board then you can try spkmodem. It's noisy, but fun, and works early.
No speaker unfortunately, it does found like fun.
Cheers, Cameron
Cameron Craig | Graduate Software Engineer | Exterity Limited tel: +44 1383 828 250 | fax: | mobile: e: Cameron.Craig@exterity.com | w: www.exterity.com
-----Original Message-----
From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: 27 September 2017 20:44 To: coreboot@coreboot.org Subject: Re: [coreboot] Intel Leaf Hill Coreboot Trouble
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
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __________________________________________________________ ____________
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________