[coreboot] Lenovo N20p Chromebook

[John Lewis]

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'.
>

Out of interest, the "Developer Information for Chrome OS Devices" page 
now lists a baseboard for each device - would it be worth compiling 
upstream rambi with EHCI debug if we get stuck with ChromiumOS coreboot?