[coreboot] Lenovo N20p Chromebook

John Lewis jlewis at johnlewis.ie
Tue Sep 16 00:30:42 CEST 2014


On 15/09/14 23:17, Aaron Durbin wrote:
> On Mon, Sep 15, 2014 at 5:13 PM, John Lewis <jlewis at johnlewis.ie> wrote:
>> On 15/09/14 23:10, Aaron Durbin wrote:
>>>
>>> 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
>>>
>>
>> Okay, fire away, I have it open and ready.
>
> In your rom, find the "LARCHIVE"  tombstone with the appropriate name
> afterwards ('fallback/refcode). It should be around offset 0x42aa80.
> For reference:
>
> struct cbfs_file {
>> -------char magic[8];
>> -------uint32_t len;
>> -------uint32_t type;
>> -------uint32_t checksum;
>> -------uint32_t offset;
> } __attribute__((packed));
>
> We want to change the type field. There should be a hex 0x50
> associated with the fallback/refcode file. Change that number to be
> 0x10. Save and then cbfstool print should list the type as 'stage'.
>
Okay it says "stage" now. I'll try flashing that in the morning then?

build/cbfstool build/coreboot.rom print
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   stage        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



More information about the coreboot mailing list