[coreboot] Group demographics

[tturne at codeaurora.org]

On 2017-03-28 13:24, Aaron Durbin wrote:
> On Tue, Mar 28, 2017 at 3:20 PM,  <tturne at 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