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 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?
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.
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.
The only discernible difference is that the power button now switches off immediately, instead of requiring a long press.
Thank you so much for all your help so far, and for coming back to this.
John.
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 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.
-Aaron
-
Aaron Durbin -
John Lewis