[coreboot] Lenovo N20p Chromebook

[Aaron Durbin]

On Mon, Sep 15, 2014 at 4:29 PM, John Lewis <jlewis at johnlewis.ie> wrote:
> On 15/09/14 22:03, Aaron Durbin wrote:
>>
>> On Mon, Sep 15, 2014 at 3:35 PM, John Lewis <jlewis at johnlewis.ie> wrote:
>>>
>>> Hello,
>>>
>>> I've purchased the subject Chromebook with a view to getting some sort of
>>> custom ROM going for Baytrail based Chromebooks, and I have my first
>>> brick
>>> of the day.
>>>
>>> I'm using ChromeOS coreboot and the firmware-clapper-5218.B branch. As
>>> per
>>> the advice Aaron gave me regarding the ASUS C200 some time ago, I
>>> extracted
>>> the reference code binary and changed line 111 in
>>> src/arch/x86/Makefile.inc
>>> as follows:
>>>
>>>          $(CBFSTOOL) $@.tmp add -f $(CONFIG_REFCODE_BLOB_FILE) -n
>>> $(CONFIG_CBFS_PREFIX)/refcode -t raw
>>>
>>
>> I think I might know. You are using upstream, right? This is my fault.
>> The rmodule format changed. We didn't bump the version, and dropped
>> the old code. Can you run readelf -e on that blob you extracted? I
>> think I allowed ELF packaging for that file. If that doesn't work
>> (hexdump -C) would be helpful.
>>
> No, I'm using ChromiumOS coreboot. With readelf -e I get:
>
> readelf -e refcode.bin
> readelf: Error: Unable to read in 0x7115 bytes of section headers
> readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
>
> hexdump -C:
>
> hexdump -C refcode.bin
> 00000000  01 00 00 00 00 10 00 00  00 00 00 00 00 00 00 00
> |................|
> 00000010  00 00 00 00 ac 10 00 00  b8 4b 00 00 01 00 60 00
> |.........K....`.|
> 00000020  00 a0 4b 00 00 00 00 00  00 00 7f 3f ec 22 15 71
> |..K........?.".q|

snip

> 000010b0  ea 88 85 74 8b 20 1e db  6b 09 b3 c0 40 c3 eb ed  |...t.
> ..k... at ...|
> 000010c0  48 a8 8d c4 08 32 85 80                           |H....2..|
> 000010c8
>
> You may want to snip that. ;)

OK. A couple of things. Bear with me as I use this thread to think
things through. This file is compressed. We extracted it, and added it
back using 'raw'.  That means cbfs_file->type != CBFS_TYPE_STAGE. So
refcode loading would not work. Would it create a brick? I wouldn't
think so, but I haven't tried.

Offhand, do you have the option rom? Do we see any life out of the
display? I'm trying to think of ways to see how far we've gotten
without serial console. Is MRC in the same place as the released
firmware? Perhaps a cbfstool print might be instructive on your
resulting image.

After bricking the device can you re-flash the spi part back to a
released image?