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.
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.
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.)
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
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
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
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.
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.
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.
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