[coreboot] Lenovo N20p Chromebook

[John Lewis]

On 21/09/14 14:06, Aaron Durbin wrote:
> On Sun, Sep 21, 2014 at 7:44 AM, John Lewis <jlewis at johnlewis.ie> wrote:
>> snip
>>
>>
>>>>>>>
>>>>>>> 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.
>>>
>>
>> I've sorted it out now - had to bridge pins 3,7 and 8 using a large
>> paper-clip, as alluded to in the OSCON presentation, referenced by Barry
>> Schultz. Never had to do that before, oddly.
>
> Interesting. You had to hard pull WP# and HOLD#. I need to take a look
> at that circuit. I wouldn't have expected you to do that either.
>
I don't understand it obviously, but I thought the main point was to get 
voltage to the WP pin to disable the hard write-protect.

Anyway, back to our original problem - the ROM with the refcode section 
changed from type 50 to type 10, still doesn't give us anything. As an 
experiment, I tried extracting one of my own kernel payloads, then 
adding it back in unchanged as a raw file, and changing the type to 50 
on my Falco, and that doesn't work either.

Could we try turning the extracted refcode binary back into an elf? How 
would I go about that?