Issue 18002 in chromium-os: fwb_tries is not set to zero and mainfw-act remains 'B' even after running chromeos-firmwareupdate --mode=todev

23 views
Skip to first unread message

chrom...@googlecode.com

unread,
Jul 21, 2011, 6:44:25 PM7/21/11
to chromium...@chromium.org
Status: Untriaged
Owner: ----
CC: kr...@chromium.org, rche...@chromium.org, venkatar...@chromium.org,
hun...@chromium.org
Labels: Type-Bug Pri-2 Area-Firmware Sev-2 Arch-ARM

New issue 18002 by sivag...@chromium.org: fwb_tries is not set to zero and
mainfw-act remains 'B' even after running chromeos-firmwareupdate
--mode=todev
http://code.google.com/p/chromium-os/issues/detail?id=18002

Chrome OS Version : 0.14.787.0
Type of computer : ARM

Please specify Area-* of the system to which this bug/feature applies.

What steps will reproduce the problem?
1. Boot the device in developer mode
2. Set crossystem fwb_tries=3 and reboot
3. Make sure that crossystem mainfw_act=B amd fwb_tries=2
4. Run chromeos-firmwareupdate --force --mode=todev

What is the expected output?
Running "chromeos-firmwareupdate --force --mode=todev" should clear
fwb_tries and set mainfw_act=A on next boot

What do you see instead?
After updating to dev firmware, it loads "B" firmware until fwb_tries count
becomes '0'


Please use labels and text to provide additional information.


chrom...@googlecode.com

unread,
Jul 22, 2011, 3:37:54 AM7/22/11
to chromium...@chromium.org

Comment #2 on issue 18002 by hun...@chromium.org: fwb_tries is not set to
zero and mainfw-act remains 'B' even after running chromeos-firmwareupdate
--mode=todev
http://code.google.com/p/chromium-os/issues/detail?id=18002

I think this is not a blocking issue.

For ARM two-stop firmware, the --mode=todev currently only changes the USB
booting feature, so we can preserve fwb_tries.

However since it would be better to sync with alex/zgb behavior, I've filed
http://gerrit.chromium.org/gerrit/4553 for that.

chrom...@googlecode.com

unread,
Jul 22, 2011, 3:41:55 AM7/22/11
to chromium...@chromium.org
Updates:
Status: Started
Cc: rspang...@chromium.org

Comment #3 on issue 18002 by hun...@chromium.org: fwb_tries is not set to

zero and mainfw-act remains 'B' even after running chromeos-firmwareupdate
--mode=todev
http://code.google.com/p/chromium-os/issues/detail?id=18002

(No comment was entered for this change.)

chrom...@googlecode.com

unread,
Jul 22, 2011, 4:20:19 AM7/22/11
to chromium...@chromium.org

Comment #4 on issue 18002 by bugdro...@chromium.org: fwb_tries is not set
to zero and mainfw-act remains 'B' even after running
chromeos-firmwareupdate --mode=todev
http://code.google.com/p/chromium-os/issues/detail?id=18002#c4

Commit: 4ad9a0cca66efddd7125aa7b4dd3d80d61da8a56
Email: hun...@chromium.org

firmware: allow todev in two_stop firmware even if firmware is incompatible

In two_stop firmware, todev/tonormal does not need to update firmware
image; so
it's free to invoke even if the firmware itself is not compatible.

todev/tonormal should also clear the updater cookies in two-stop mode.

BUG=chromium-os:18012, chromium-os:18002
TEST=chromeos-firmwareupdate --mode=todev

Change-Id: I864594386a40e4dd554b3b78b3308f45980ba59d
Reviewed-on: http://gerrit.chromium.org/gerrit/4553
Reviewed-by: Tom Wai-Hong Tam <wai...@chromium.org>
Tested-by: Hung-Te Lin <hun...@chromium.org>

M pack_dist/updater.sh

chrom...@googlecode.com

unread,
Jul 22, 2011, 4:42:28 AM7/22/11
to chromium...@chromium.org
Updates:
Status: Fixed

Comment #5 on issue 18002 by hun...@chromium.org: fwb_tries is not set to

zero and mainfw-act remains 'B' even after running chromeos-firmwareupdate
--mode=todev

chrom...@googlecode.com

unread,
Jul 22, 2011, 7:45:08 PM7/22/11
to chromium...@chromium.org
Updates:
Status: Verified

Comment #6 on issue 18002 by sivag...@chromium.org: fwb_tries is not set to

zero and mainfw-act remains 'B' even after running chromeos-firmwareupdate
--mode=todev
http://code.google.com/p/chromium-os/issues/detail?id=18002

Chrome OS: 0.14.793.0
Verified on ARM device

chromeos-firmwareupdate --mode=todev failed in ZGB on latest build.
Regression issue
http://code.google.com/p/chrome-os-partner/issues/detail?id=5108

chrom...@googlecode.com

unread,
Aug 13, 2011, 3:17:21 AM8/13/11
to chromium...@chromium.org
Updates:
Status: Started

Comment #7 on issue 18002 by hun...@chromium.org: fwb_tries is not set to

zero and mainfw-act remains 'B' even after running chromeos-firmwareupdate
--mode=todev
http://code.google.com/p/chromium-os/issues/detail?id=18002

Reopen because we lost this change when migrating from v2 to v3. ARM
behavior is different again and should be fixed.

chrom...@googlecode.com

unread,
Aug 13, 2011, 3:49:25 AM8/13/11
to chromium...@chromium.org
Updates:
Status: Assigned
Owner: rspa...@chromium.org

Comment #8 on issue 18002 by hun...@chromium.org: fwb_tries is not set to

zero and mainfw-act remains 'B' even after running chromeos-firmwareupdate
--mode=todev
http://code.google.com/p/chromium-os/issues/detail?id=18002

Hold on; think again, I think we should not clear flags on two-stop
firmware.

Consider the case:
- User was in developer mode. two-stop firmware allows updating in
developer mode.
- An update occurs in background and set update cookies (try_b)
- User run "chromeos-firmwareupdate --mode=todev". This clears the update
cookies
- Next boot may revert the update (if kernel is not compatible), or have
OS updated while firmware is not updated.

Another case:
- A user wants to try out a new firmware, say Version 2 (system is version
1)
- User runs chromeos-firmwareupdate --mode=autoupdate
- System was boot with B (new firmware), but not 60 seconds yet.
- User saw system firmware = Version 2, and then wants to try USB boot, so
he executed chromeos-firmware --mode=todev, (cleared flags), and reboot
immediately to test USB
- Firmware reverted to A...

These scenarios are not possible for dev-norm-separated firmware (like
Alex/ZGB) because you need to first enter developer mode and that will
apparently change the firmware.

So, in general, I think we should NOT clear the update cookies (fwb_tries
and fwupdate_tires) for two_stop firmware because --todev in two_stop
simply enables an extra feature, not changing the firmware blob.

Hi Randall, do you agree my assumption?
If not, please assign back to me and I'll make arm and x86 behavior the
same.
Otherwise let's keep this as won't fix.

chrom...@googlecode.com

unread,
Aug 22, 2011, 1:36:50 PM8/22/11
to chromium...@chromium.org
Updates:
Status: Fixed
Owner: hun...@chromium.org

Comment #9 on issue 18002 by hun...@chromium.org: fwb_tries is not set to

zero and mainfw-act remains 'B' even after running chromeos-firmwareupdate
--mode=todev
http://code.google.com/p/chromium-os/issues/detail?id=18002

Close again because updater3 (kaen/aebl) behavior is now synced again.

chromeos-firmwareupdate --mode=todev on ARM will reset the update flags
(fwb_tries, fwupdate_tries) to zero.

chrom...@googlecode.com

unread,
Aug 22, 2011, 1:40:52 PM8/22/11
to chromium...@chromium.org

Comment #10 on issue 18002 by bugdro...@chromium.org: fwb_tries is not set
to zero and mainfw-act remains 'B' even after running
chromeos-firmwareupdate --mode=todev
http://code.google.com/p/chromium-os/issues/detail?id=18002#c10

Commit: e7123a1c546f6d03dceaecf50d29da9eed2e2c95
Email: hun...@chromium.org

firmware: refine firmware updater branch layout

To make firmware updater work better with further firmware/vboot design
changes, this CL tries to make the updater branches more organized.

- updaters are now labeled with vboot/firmware protocol in numeric version.
(updater1 replaced legacy_updater.sh)
- behavior and output messages synchronization for updater v2/v3

This is part of preparation for new firmware updater.

BUG=chromium-os:19453,chromium-os:18002,chromium-os:17296
TEST=emerge-x86-zgb chromeos-firmware-zgb
emerge-tegra2_aebl chromeos-firmware-aebl

Change-Id: I9713b4616499a5c0f2773f31af4be46372ae7367
Reviewed-on: http://gerrit.chromium.org/gerrit/6397
Reviewed-by: Randall Spangler <rspa...@chromium.org>
Tested-by: Hung-Te Lin <hun...@chromium.org>

M pack_dist/updater.sh
A pack_dist/updater1.sh
A pack_dist/updater2.sh
M pack_dist/updater3.sh

Reply all
Reply to author
Forward
0 new messages