[coreboot] Lenovo N20p Chromebook
Aaron Durbin
adurbin at google.com
Tue Sep 16 00:10:44 CEST 2014
On Mon, Sep 15, 2014 at 5:00 PM, John Lewis <jlewis at johnlewis.ie> wrote:
>
>
> On 15/09/14 22:50, Aaron Durbin wrote:
>>
>> 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.
>
>
> Yes, I extracted all the necessary files from the shellball ROM for Clapper.
> No, no life from the display (no backlight even).
>
> coreboot.rom: 8192 kB, bootblocksize 1184, romsize 8388608, offset 0x400000
> alignment: 64 bytes, architecture: x86
>
> Name Offset Type Size
> cmos_layout.bin 0x400000 cmos_layout 1164
> pci8086,0f31.rom 0x4004c0 optionrom 65536
> cpu_microcode_blob.bin 0x410500 microcode 103424
> config 0x429980 raw 4298
> fallback/refcode 0x42aa80 raw 4296
> (empty) 0x42bb80 null 17368
> fallback/romstage 0x42ff80 stage 35171
> fallback/coreboot_ram 0x438980 stage 71515
> fallback/payload 0x44a140 payload 34866
> img/Jeltka 0x4529c0 payload 2970296
> (empty) 0x727cc0 null 492248
> mrc.bin 0x79ffc0 (unknown) 70168
> (empty) 0x7b1240 null 240984
> spd.bin 0x7ebfc0 (unknown) 1536
> (empty) 0x7ec600 null 79064
>
>>
>> After bricking the device can you re-flash the spi part back to a
>> released image?
>>
> I don't see why not, but it's getting late here and people are sleeping so
> I'll have to do that in the morning. If there's anything else quick I'll
> hang around this end for 10 or so minutes to answer.
Understood. The only thing I can think of trying really quickly is
making the type of the file to be a stage instead of raw. You'll need
to hexedit the rom to change the type.
-Aaron
More information about the coreboot
mailing list