Issue 242757 in chromium: Enable cros_write_firmware with an option to preserve vpd

[chro...@googlecode.com]

Status: Untriaged
Owner: bhthomp...@chromium.org
CC: s...@chromium.org, vpala...@chromium.org, vben...@chromium.org,
dpa...@chromium.org
Labels: Type-Bug Pri-2 Cr-OS-Firmware-BIOS OS-Chrome

New issue 242757 by bhthomp...@chromium.org: Enable cros_write_firmware
with an option to preserve vpd
http://code.google.com/p/chromium/issues/detail?id=242757

In some cases we may want to be able to rewrite a system's firmware using
the direct cros_write_firmware script, but leave the VPD (HWID, serial,
codes, etc.) intact. This would allow you to rewrite your firmware from a
development host machine, while keeping the target system's ability to do
things like auto update (which depends on a valid HWID).

It looks like we can do this by adding to _GetFlashScript() in
write_firmware.py. After staring at the function for a while, I believe we
can do this by using a bit of space after address + length to store the
original VPD, and adding in additional U-Boot commands to manage the
reading and writing back to SPI. I am not sure if we need to add user
facing options for VPD offset and size, or if we can get away with hard
coding those, or if we can read them easily somewhere.

Does this sound feasible?

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #1 on issue 242757 by bhthomp...@chromium.org: Enable

cros_write_firmware with an option to preserve vpd
http://code.google.com/p/chromium/issues/detail?id=242757

I have a prototype up at https://gerrit.chromium.org/gerrit/#/c/56511/
which works on an ARM Chromebook however this currently has hard coded
addresses and offsets.

I am afraid that decoding the FMAP using a U-boot script appears a bit
daunting at the moment (maybe we could add a U-Boot fmap command?), so my
current thought is we can specify a preset offset and size since we know
the device is exynos and the image size is 4MB, which based on the DTS
files in U-Boot seems to specify a particular flashmap, though this does
give us a cross dependency if someone were to change the flashmap and makes
scaling to other platforms more painful :(.

Another alternative is to add additional arguments to provide specific
offsets and lengths for RO/RW vpd on the command line, though those could
be long.

[chro...@googlecode.com]

Comment #2 on issue 242757 by bugdro...@chromium.org: Enable

cros_write_firmware with an option to preserve vpd

http://code.google.com/p/chromium/issues/detail?id=242757#c2

Project: chromiumos/third_party/u-boot
Branch : chromeos-v2011.12
Author : Bernie Thompson <bhtho...@chromium.org>
Commit : 5b5e5271284821cb78fa9cc87da216672756d7cb

Code Review +2: Simon Glass
Verified +1: Bernie Thompson
Change-Id : I33158e7588d2c1e98a5bfc2cd8d074e0a751eae8
Reviewed-at : https://gerrit.chromium.org/gerrit/56609

exynos: config: enable setexpr command for smdk5250 based boards

This adds the setexpr command which allows basic evaluations in hex, which
is useful for some U-boot command scripts involving addresses.

BUG=chromium:242757
TEST=Manual, boot up U-Boot image, verify setexpr command is in help and
functions.
BRANCH=none

Signed-off-by: Bernie Thompson <bhtho...@chromium.org>

M include/configs/smdk5250.h