[coreboot] Lenovo N20p Chromebook
Aaron Durbin
adurbin at chromium.org
Fri Oct 3 16:23:47 CEST 2014
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.
-Aaron
More information about the coreboot
mailing list