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.
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
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).
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
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.
u-boot.dtb is an ancient leftover that we haven't bothered to remove yet (or, rather, I think it might actually be gone from the latest boards... try a Kevin image). IIRC it actually contains the coreboot config or something weird? Anyway, red herring.
I welcome pointers to online documentation (either coreboot or chromiumos) that more clearly discuss coreboot inclusion within chromiumos build and development cycle.
Not much documentation unfortunately, in part because it keeps changing too often to be worth documenting. Your best bet is to just look at the ebuild sources directly:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/m... https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/m... https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/m... https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/m...
Hope you like portage, because that's all we have! ;)
-
Aaron Durbin -
Julius Werner -
tturne＠codeaurora.org