[coreboot] Lenovo N20p Chromebook
John Lewis
jlewis at johnlewis.ie
Sat Sep 20 20:43:42 CEST 2014
On 19/09/14 19:11, Aaron Durbin wrote:
> On Fri, Sep 19, 2014 at 12:20 PM, John Lewis <jlewis at johnlewis.ie> wrote:
>>
>>
>> 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?
>
> You are in the right spot. The fact that it failed at 6MiB is very
> indicative of the SPI part write protection. There are, however, more
> than one status register. There should be 3 of them:
>
> Read Status Register-1 (05h), Status Register-2 (35h) & Status Register-3 (15h)
>
> Btw, I'm referencing W25Q64FW datasheet.
>
> -Aaron
>
Yeah, using --wp-status with Clapper's Flashrom tells me that the write
protect *is* enabled, after all. But I can't see where, apart from the
screw I took out right next to the battery, the write-protect screw
would be? And I'm confused as to why it let me write initially if the
write-protect wasn't enabled.
This is the output I get trying to run --wp-disable:
w25_set_srp0: old status: 0x94
w25_set_srp0: new status: 0x94
w25q_disable_writeprotect(): error=1.
No -i argument is specified, set ignore_fmap.
FAILED
Setting SPI voltage to 0.000 V
restore_power_management: Re-enabling power management.
John.
More information about the coreboot
mailing list