[coreboot] Lenovo N20p Chromebook
John Lewis
jlewis at johnlewis.ie
Fri Sep 19 19:20:18 CEST 2014
On 19/09/14 18:07, Aaron Durbin wrote:
> On Fri, Sep 19, 2014 at 12:01 PM, John Lewis <jlewis at johnlewis.ie> wrote:
>>
>>
>> On 16/09/14 02:05, Aaron Durbin wrote:
>>>
>>> On Mon, Sep 15, 2014 at 3:46 PM, John Lewis <jlewis at johnlewis.ie> wrote:
>>>>
>>>> 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'.
>>>>>
>>
>> I'm trying to flash the ROM externally now, but it's telling me it can't
>> disable block protection. It gets as far as trying to erase 0x600000, then
>> goes through all the erase functions, finally crapping out. Do you know how
>> I can work-around that?
>
> The write protect screw is removed, right? After that the flash's
> write protect register needs to be updated. Do you know the status
> register values? Flashrom should be able to do that.
>
Yes, it is definitely removed - I didn't put it back in after the
initial brick. It says the register value is 0x94 - I did also hook up
the Bus Pirate for use with statically linked ChromeOS Flashrom (as the
particular version I have doesn't have Dediprog support) - I had an idea
running --wp-disable might help, but it didn't recognise the chip and
said the register was already 0x94 (paraphrasing). I am currently
compiling a newer statically linked version of ChromeOS Flashrom using
the SDK, in the hope that might be able to do the job. Am I barking up
the wrong tree though, or is there something else I could do?
John.
More information about the coreboot
mailing list