[coreboot] Lenovo N20p Chromebook
John Lewis
jlewis at johnlewis.ie
Fri Oct 3 16:44:43 CEST 2014
On 03/10/14 15:23, Aaron Durbin wrote:
> On Thu, Oct 2, 2014 at 4:48 PM, John Lewis <jlewis at johnlewis.ie> wrote:
>>
>>
>> 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'm in the same boat as you. I'm capable of ripping pads off and
> general destruction. That said, I think you could probably do it. You
> really just need to attach a few wires.
>
> http://www.chromium.org/chromium-os/servo
>
> On that page is a link titled "schematic and layout for this cable".
> In that tar.gz file is a schematic pdf. There is a header labeled "DUT
> SIDE" that shows the pin out of the pads on your board. (DUT stands
> for device under test).
>
> The pins you care about:
>
> GND - which can be picked up off of pin 1 or the other pins on there.
> UART2_DUT_SERVO_TX - pin 17
> UART2_SERVO_DUT_TX - pin 16
> PPDUT_UART2_VREF - pin 18
> UART1_DUT_SERVO_TX - pin 33
> UART1_SERVO_DUT_TX - pin 32
> PPDUT_UART1_VREF - pin 34
>
> Here's the decoder ring:
>
> UART2_DUT_SERVO_TX - x86 TX
> UART2_SERVO_DUT_TX - x86 RX
>
> Both of those signals are 1.8V which you can pick up on
> PPDUT_UART2_VREF if you need to.
>
> UART1_DUT_SERVO_TX - EC TX
> UART1_SERVO_DUT_TX - EC RX
>
> Both of those signals are 3.3 which you can pick up on
> PPDUT_UART1_VREF if you need to.
>
> Some example cables that should work (you can find the equivalent
> across the internets).
> http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm
>
> TTL-232RG-VIP-WE - "Cable features voltage reference input for setting
> UART signalling levels."
>
> That one you would need the VREF signals, but that cable should then
> work for both x86 and EC side. Or you can go with a TTL serial cable
> that has an internal regulator but then you need to match the
> voltages.
>
> The EC will provide you the post codes sent by the x86 port80 on its
> console. The x86 obviously will output all the coreboot messages.
>
>
>>
>> I could also do with pointing in the right direction on making the cable up
>> - again, another thing I'm mostly unfamiliar with.
>
> Sorry for having to go down this path. It's the most immediate thing
> to get information as I haven't had too much time to think about how
> else to debug your setup as we're flying blind at the moment.
>
No problem at all, Aaron. I certainly feel a bit more confident now
you've given me all that information. I'll get one of those cables
ordered, probably the first one as it sounds easier than trying to
regulate anything. ;)
Thanks a mill,
John.
More information about the coreboot
mailing list