[coreboot] Lenovo N20p Chromebook
John Lewis
jlewis at johnlewis.ie
Thu Oct 2 23:48:10 CEST 2014
On 02/10/14 22:25, Aaron Durbin wrote:
> On Thu, Oct 2, 2014 at 3:51 PM, John Lewis <jlewis at johnlewis.ie> wrote:
>> On 02/10/14 19:31, Aaron Durbin wrote:
>>>
>>> On Mon, Sep 22, 2014 at 3:21 PM, John Lewis <jlewis at johnlewis.ie> wrote:
>>>>
>>>> On 22/09/14 19:59, Aaron Durbin wrote:
>>>>>
>>>>>
>>>>> On Mon, Sep 22, 2014 at 12:24 PM, John Lewis <jlewis at johnlewis.ie>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 22/09/14 17:39, Aaron Durbin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Sep 21, 2014 at 8:14 AM, John Lewis <jlewis at johnlewis.ie>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I looked at the schematics. There's a lot of complexity in that area
>>>>>>> because of voltage differences. I'm not surprised you had to short WP#
>>>>>>> to SPI VCC to make it work. I'm guessing this is most likely required
>>>>>>> for all baytrail based ChromeOS devices.
>>>>>>>
>>>>>>>>
>>>>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'm told firmware-clapper-5216.199.B is the correct firmware branch
>>>>>>> to use. The other one is old and may not be working (this issue?).
>>>>>>>
>>>>>>> I'd be curious to see if you can get anything from your image.
>>>>>>> http://www.chromium.org/chromium-os/servo has the servo pin
>>>>>>> definitions for the cable. You could get uarts from EC and the
>>>>>>> baytrail part.
>>>>>>>
>>>>>>> As for changing that thing back to ELF, it's definitely possible. Can
>>>>>>> we try using the proper branch first? If not, the refcode is an
>>>>>>> rmodule so you'll just need to take the relocation information and the
>>>>>>> code to create a new ELF. We don't have a tool to do that right now,
>>>>>>> but it wouldn't be too too hard.
>>>>>>>
>>>>>>
>>>>>> I already switched to 5216.199.B today as that's the one the shellball
>>>>>> is
>>>>>> using. Unfortunately, it didn't make too much difference.
>>>>>>
>>>>>> That's a bit over my head - I am a complete dunce when it comes to
>>>>>> electronics, can't even use a soldering iron. I don't know how to read
>>>>>> schematics even. Unless you or someone else can illustrate further what
>>>>>> would need to be done there, it's going to be a no go. I think Ron did
>>>>>> semi-promise me a servo board near the start of the year though. ;)
>>>>>>
>>>>>> I also tried recreating the elf using the commands on the Hacking VMX
>>>>>> page
>>>>>>
>>>>>>
>>>>>> http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-sandy-bridge/coreboot-vmx-hack
>>>>>> but I'm fairly sure some of those values would be wrong. Happily
>>>>>> though,
>>>>>> the
>>>>>> elf ended up exactly the right size once it was in the ROM (4296
>>>>>> bytes).
>>>>>> Still didn't help though.
>>>>>>
>>>>>> Finally, I enabled the i915 driver in my Jeltka embedded Linux in the
>>>>>> hope
>>>>>> that there was just something wrong with SeaBIOS/video so it might get
>>>>>> as
>>>>>> far as the payload and give me a display regardless. But again, that
>>>>>> didn't
>>>>>> help. Tried with refcode done both ways.
>>>>>>
>>>>>
>>>>> My concern is that we are focusing on this refcode thing, though
>>>>> valid, but we're tripping over other issues. The only way I can see of
>>>>> obtaining proof of life is to either get an LPC debug decoder (could
>>>>> attach to TPM) or getting uarts from the EC and x86. The servo
>>>>> connector has the EC and x86 uarts on it. We could tap into that.
>>>>>
>>>>> Could you load your SPI image to a place I could pull it down and
>>>>> inspect it? I may be able to magically find some issue. But don't hold
>>>>> your breath. :)
>>>>>
>>>>
>>>> The only other thing that sticks out to me is vboot. Even though I have
>>>> "#
>>>> CONFIG_VBOOT_VERIFY_FIRMWARE is not set" in the config, the build still
>>>> expects to find vboot_api.h from platform/vboot_reference. I've managed
>>>> with
>>>> some help to reasonably reliably get other models working using ChromeOS
>>>> coreboot in the past, so I have to assume it's something new like this or
>>>> refcode, causing the issue. It seems to me that a few problems are caused
>>>> by
>>>> code from one feature being tightly integrated with code from another,
>>>> and
>>>> when you don't want to use one of the features, things break.
>>>>
>>>> I've uploaded my last go to
>>>> https://johnlewis.ie/coreboot-clapper-220914.rom
>>>
>>>
>>> I apologize for not getting back to this. It's been sitting in my
>>> inbox, and I just realized last night that it's been over a week. The
>>> mrc.bin is in the wrong part of the rom. It needs to be moved 1KiB
>>> back.
>>>
>>> Current:
>>>
>>> $ cbfstool coreboot-clapper-220914.rom print
>>> coreboot-clapper-220914.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 104448
>>> config 0x429d80 raw 4852
>>> fallback/refcode 0x42b0c0 stage 4296
>>> (empty) 0x42c1c0 null 15768
>>> fallback/romstage 0x42ff80 stage 35539
>>> fallback/coreboot_ram 0x438ac0 stage 77305
>>> fallback/payload 0x44b900 payload 3263688
>>> (empty) 0x768600 null 227736
>>> mrc.bin 0x79ffc0 (unknown) 70168
>>> (empty) 0x7b1240 null 240984
>>> spd.bin 0x7ebfc0 (unknown) 2048
>>> (empty) 0x7ec800 null 78552
>>>
>>> mrc.bin in this is actually an ELF file and there's 0x40 bytes of cbfs
>>> metadata at 0x79ffc0. So ELF file lives at 0xfffa0000, but we want the
>>> XIP code to live at that address.
>>>
>>> $ cbfstool coreboot-clapper-220914.rom extract -n mrc.bin -f mrc.elf
>>> $ readelf -e mrc.elf
>>> ELF Header:
>>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>>> Class: ELF32
>>> Data: 2's complement, little endian
>>> Version: 1 (current)
>>> OS/ABI: UNIX - System V
>>> ABI Version: 0
>>> Type: EXEC (Executable file)
>>> Machine: Intel 80386
>>> Version: 0x1
>>> Entry point address: 0xfffa0000
>>> Start of program headers: 52 (bytes into file)
>>> Start of section headers: 69848 (bytes into file)
>>> Flags: 0x0
>>> Size of this header: 52 (bytes)
>>> Size of program headers: 32 (bytes)
>>> Number of program headers: 3
>>> Size of section headers: 40 (bytes)
>>> Number of section headers: 8
>>> Section header string table index: 7
>>>
>>> Section Headers:
>>> [Nr] Name Type Addr Off Size ES Flg Lk
>>> Inf Al
>>> [ 0] NULL 00000000 000000 000000 00 0
>>> 0 0
>>> [ 1] .MRC PROGBITS fffa0000 001000 00dadc 00 AX 0
>>> 0 4
>>> [ 2] .GUID PROGBITS fffadadc 00eadc 000318 00 WA 0
>>> 0 4
>>> [ 3] .VARS NOBITS fe008000 001000 002e08 00 WA 0
>>> 0 4
>>> [ 4] .STACK NOBITS fe00ae08 001000 0051f8 00 WA 0
>>> 0 1
>>> [ 5] .rel.MRC REL 00000000 00edf4 002110 08 0
>>> 1 1
>>> [ 6] .rel.GUID REL 00000000 010f04 0001a8 08 0
>>> 2 1
>>> [ 7] .shstrtab STRTAB 00000000 0110ac 00002b 00 0
>>> 0 1
>>> Key to Flags:
>>> W (write), A (alloc), X (execute), M (merge), S (strings)
>>> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
>>> O (extra OS processing required) o (OS specific), p (processor
>>> specific)
>>>
>>> Program Headers:
>>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>>> LOAD 0x001000 0xfe008000 0xfe008000 0x00000 0x08000 RW
>>> 0x1000
>>> LOAD 0x001000 0xfffa0000 0xfffa0000 0x0ddf4 0x0ddf4 RWE
>>> 0x1000
>>> GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
>>>
>>> Section to Segment mapping:
>>> Segment Sections...
>>> 00 .VARS .STACK
>>> 01 .MRC .GUID
>>> 02
>>>
>>> The .MRC section is where the code lives (01 load segment). We want
>>> that to live at 0xfffa0000 which is at offset 0x1000 into the elf
>>> file. Therefore, we want this file to be added at 0xfffa0000 - 0x1000.
>>>
>>> You could manually move this or just 'cbfstool remove' then 'cbfstool
>>> add' with the appropriate address.
>>>
>>> Hope that helps.
>>>
>>
>> No worries at all. At least it's not had chance to gather too much dust
>> upstairs. Don't you mean 4k back, as 0x1000 hex is 4096 bytes?
>
> Yes. I thought that's what I said with '0xfffa0000 - 0x1000', but I
> didn't mention that is where we want it in the end.
>
>>
>> When I tried to add mrc.bin with a base address of 0x79efc0, it ended up at
>> 0x79ef80. Using a base address of 0x79f000 got it in the right place, but
>> there is still no output.
>
> You need to account for the 0x40 bytes of cbfs metadata. 'cbfstool
> print' shows offsets of files starting with their cbfs metadata -- not
> the data they contain. It seems like you figured that out though.
>
>>
>> Just to make sure I hadn't got the wrong end of the stick, I edited
>> src/soc/intel/baytrail/Makefile.inc, changed mrc.bin-position to 0xfff9f000,
>> and built again. The mrc.bin ended up at 0x79efc0, but again still no
>> output.
>
> That should be correct.
>
> (gdb) p/x -((8 << 20) - (0x79efc0 + 0x40))
> $14 = 0xfff9f000
>
>>
>> The only discernible difference is that the power button now switches off
>> immediately, instead of requiring a long press.
>
> Well that tells me we booted far enough to get SMIs flowing in that a
> power button press does an immediate S5 transition. It seems like we
> could be in the payload somewhere (that or around MP init).
>
> Do you know anyone who can solder? Tapping into the serial pins will
> be really helpful.
>
My brother's great with a soldering iron, but he's over 300 miles away.
I have a soldering iron, but I also have a psychological block about
using it. I take it that the copper pads that are the "serial port" are
what I will need to connect to? Do you think a bog standard soldering
iron is small enough to manage it?
I could also do with pointing in the right direction on making the cable
up - again, another thing I'm mostly unfamiliar with.
John.
More information about the coreboot
mailing list