On 2017-03-28 13:24, Aaron Durbin wrote:
On Tue, Mar 28, 2017 at 3:20 PM, tturne@codeaurora.org wrote:
On 2017-03-24 17:42, Julius Werner wrote:
- Google's recovery manifest (from linux_recovery.sh) can pull a
recovery image for a specific product, I have yet to find depthcharge as a payload
- Obviously I haven't pulled all of the recovery images, but have
looked at ~10
- those interested in recovery image,
/usr/sbin/chromeos_firmwareupdate --sb_extract yields a bios.bin file that cbfstool can parse (i.e. is a coreboot.rom file)
All non-x86 Chromebooks that use coreboot also use depthcharge. What exactly do you mean when you say you can't find it? If you parse bios.bin with cbfstool print, you should see a "fallback/payload" file... that is depthcharge. (coreboot always requires the payload to just be called "payload" in CBFS, regardless of what it actually is.) You can extract it and run 'strings' on it to confirm.
This was my understanding (Depthcharge being used as payload for all recent Chromebooks). What led me to question this understanding was:
- limited number of libpayload config files in coreboot source tree
- chromiumos build tree explicitly setting CONFIG_PAYLOAD="n" for all
coreboot boards
- u-boot.dtb file being present in all bios.bin files I looked at
from linux_recovery.sh manifest (including Kevin)
As fallback/payload is compressed in bios.bin, I'm not sure what strings will provide. I did run strings on bios.bin (as well as looking at it in hex editor) and found nothing explicitly suggesting depthcharge (or u-boot for that matter) was the payload. I made assumption u-boot was payload based on presence of u-boot.dtb file in bios.bin.
FWIW, you can 'cbfstool extract' the fallback/payload file from an existing image. It'll write an ELF file that you should be familiar with for inspection purposes (strings, readelf, objdump, etc).
Thanks for this heads-up, I didn't realize extract would decompress. I have extracted the payload and based on the symbols concur that it is depthcharge. Cheers, T.mike
As has already been explained in this thread the coreboot build within chromiumos tree does not include building payload, this is a later step. My work to date has been solely within confines of coreboot build tree and directly generating depthcharge, etc. so this deferred building of the payload came as a surprise.
I welcome pointers to online documentation (either coreboot or chromiumos) that more clearly discuss coreboot inclusion within chromiumos build and development cycle.
Thanks to all who have contributed to my current level of knowledge and I know I am just scratching the surface. Cheers, T.mike