New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 862703 link

Starred by 1 user

Issue metadata

Status: Duplicate
Owner:
Last visit > 30 days ago
Closed: Jul 24
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

recovery image fails to update bios RW on auron-yuna

Project Member Reported by apronin@chromium.org, Jul 11

Issue description

What steps will reproduce the problem?
On auron-yuna:
 - The device is in dev mode, WP is on.
 - Download signed recovery image from GE, flash to usb stick.
 - Esc-Power-Refresh to initiate recovery.
 - Insert recovery stick.

What is the expected result?
Recovery completes.

What happens instead?
For M69-10860.0.0, recovery fails (see below).
A later recovery using M68-10718.50.0 image succeeds.


Recovery fails while attempting to update coreboot RW. Here is the corresponding part of recovery.log from the failed attempt:

Starting Google_Auron_yuna firmware updater v4 (recovery)...
 - Updater package: [RO:Google_Auron_yuna.6301.59.100 RW:Google_Auron_yuna.6301.59.116 / EC:yuna_v1.1.2302-c2730ea]
 - Current system:  [RO:Google_Auron_yuna.6301.59.5 , ACT:Google_Auron_yuna.6301.59.5 / EC:yuna_v1.1.2302-c2730ea]
 - Write protection: Hardware: ON, Software: Main=ON EC=ON
recovery: update main/RW:A,B,SHARED
 * invoke: flashrom -p host -r _current/bios.bin
 * invoke: flashrom -p host --fast-verify -w bios.bin -i RW_SECTION_A
 Execution failed (1): flashrom -p host --fast-verify -w bios.bin -i RW_SECTION_A
 Messages:
Calibrating delay loop... OK.
coreboot table found at 0x7ce3c000.
Erasing and writing flash chip... FAILED
flashrom v0.9.9  : 622128c : Jul 05 2018 14:19:12 UTC on Linux 3.14.0 (x86_64)
Block protection could not be disabled!
spi_block_erase_52 failed during command execution at address 0x228000
ERASE FAILED!
FAILED!
Uh oh. Erase/write failed. Checking if anything changed.
Your flash chip is in an unknown state.


The M68 recovery image later performs the update w/o any issues:
Starting Google_Auron_yuna firmware updater v4 (recovery)...
 - Updater package: [RO:Google_Auron_yuna.6301.59.100 RW:Google_Auron_yuna.6301.59.116 / EC:yuna_v1.1.2302-c2730ea]
 - Current system:  [RO:Google_Auron_yuna.6301.59.5 , ACT:Google_Auron_yuna.6301.59.5 / EC:yuna_v1.1.2302-c2730ea]
 - Write protection: Hardware: ON, Software: Main=ON EC=ON
recovery: update main/RW:A,B,SHARED
 * invoke: flashrom -p host -r _current/bios.bin
 * invoke: flashrom -p host --fast-verify -w bios.bin -i RW_SECTION_A
 * invoke: flashrom -p host --fast-verify -w bios.bin -i RW_SECTION_B
 * invoke: flashrom -p host --fast-verify -w bios.bin -i RW_SHARED
recovery: EC may be restored or updated in next boot.
Firmware update (recovery) completed.


Full recovery logs are attached.
 
recovery_fail_69.log
132 KB View Download
recovery_success_68.log
160 KB View Download
Cc: jwer...@chromium.org vbendeb@chromium.org adurbin@chromium.org
Aaron, Julius, do you know who can take a closer look at this?
Vadim, you made a few changes to flashrom recently. Any chance they could have caused this?
Cc: sjg@chromium.org
Adding Simon again since Vadim is out. This seems to be similar but not quite the same (in the error message) as issue 860142. Note that Auron uses the lm4 EC, not the mec1322. Still those flashrom changes seem like the most likely culprit.

If nobody who's around right now has time and/or expertise to figure out this issue, I'd suggest reverting those changes for now.
I m not sure. I suppose there is a reasonable chance that it is related, perhaps trying to disable block protection on too large a block?

Vadim seems to be back on Monday: can it wait until then?
It's not that last flashrom change from https://crbug.com/860142#c11 that breaks things.

There was a number of flashrom changes that landed recently:
https://crrev.com/c/1107394 - 10806.0.0 [that CL from issue 860142]
https://crrev.com/c/1098533 - 10787.0.0
https://crrev.com/c/1098532 - 10786.0.0

After that we know that 10773.0.0 worked in issue 860142 and  10718 .50.0 worked on my asuka. So, the earlier ones should be ok:
https://crrev.com/c/1068269 - 10738.0.0
https://crrev.com/c/1060121 - ???
https://crrev.com/c/1058043 - 10683.0.0
https://crrev.com/c/1053405 - 10683.0.0
https://crrev.com/c/1036654 - 10646.0.0

I tried running several recovery images on lulu.

10806.0.0, 10805.0.0, 10787.0.0 failed with the same/similar error:
Starting Google_Lulu firmware updater v4 (recovery)...
 - Updater package: [Google_Lulu.6301.136.57 / EC:lulu_v1.1.2323-8b1aa45]
 - Current system:  [RO:Google_Lulu.6301.136.57 , ACT:Google_Lulu.6301.136.57 / EC:lulu_v1.1.2323-8b1aa45]
 - Write protection: Hardware: ON, Software: Main=off EC=off
recovery: update RO+RW
 * invoke: flashrom -p host --fast-verify -w bios.bin
 Execution failed (1): flashrom -p host --fast-verify -w bios.bin
 Messages:
Calibrating delay loop... OK.
coreboot table found at 0x7ce3c000.
Erasing and writing flash chip... Good. It seems nothing was changed.
FAILED
flashrom v0.9.9  : d2da987 : Jun 21 2018 23:31:30 UTC on Linux 3.14.0 (x86_64)
spi_block_erase_52 failed during command execution at address 0x3e0000
ERASE FAILED!
FAILED!
Uh oh. Erase/write failed. Checking if anything changed.
Writing to the flash chip apparently didn't do anything.

10786.0.0 doesn't have artifacts in GE for lulu (that build succeeded only for two beaglebone boards).

10785.0.0 succeeded (and flashrom -p host --fast-verify -w bios.bin was successfully run there)

So, if it was a flashrom change that broke things, it must be in https://crrev.com/c/1098533 and/or https://crrev.com/c/1098532.
I am taking a look.
Owner: vbendeb@chromium.org
Status: Assigned (was: Untriaged)
Assigning to Vadim per comment #5 (hope that's OK - complain if not :-D)
Mergedinto: 860142
Status: Duplicate (was: Assigned)

Sign in to add a comment