On 03/10/14 15:23, Aaron Durbin wrote:
On Thu, Oct 2, 2014 at 4:48 PM, John Lewis jlewis@johnlewis.ie wrote:
On 02/10/14 22:25, Aaron Durbin wrote:
On Thu, Oct 2, 2014 at 3:51 PM, John Lewis jlewis@johnlewis.ie wrote:
On 02/10/14 19:31, Aaron Durbin wrote:
On Mon, Sep 22, 2014 at 3:21 PM, John Lewis jlewis@johnlewis.ie wrote:
On 22/09/14 19:59, Aaron Durbin wrote: > > > > On Mon, Sep 22, 2014 at 12:24 PM, John Lewis jlewis@johnlewis.ie > wrote: >> >> >> >> >> >> On 22/09/14 17:39, Aaron Durbin wrote: >>> >>> >>> >>> >>> On Sun, Sep 21, 2014 at 8:14 AM, John Lewis jlewis@johnlewis.ie >>> wrote: >>>> >>>> >>>> >>>> >>>> On 21/09/14 14:06, Aaron Durbin wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Sep 21, 2014 at 7:44 AM, John Lewis jlewis@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-devi... >> 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 printcoreboot-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 02The .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.
-
John Lewis