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.
John.
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. :)
-Aaron
-
Aaron Durbin -
John Lewis