On 2017-03-28 13:24, Aaron Durbin wrote:
On Tue, Mar 28, 2017 at 3:20 PM, <[email protected]> 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
--
coreboot mailing list: [email protected]
https://www.coreboot.org/mailman/listinfo/coreboot
