Also make the script able to run at other directory.
BUG=chromium-os:11384
TEST=as follow:
$ cd /tmp
$ ~/$CHROMEOS/src/platform/vboot_reference/scripts/bitmaps/make_bmp_images.sh 'x86 HWID 1234' '1366x768' true
processing BlankBmp ...
processing DeveloperBmp ...
processing RecoveryBmp ...
processing RecoveryMissingOSBmp ...
processing RecoveryNoOSBmp ...
$ file out_x86_HWID_1234/DeveloperBmp/DeveloperBmp.bmp
out_x86_HWID_1234/DeveloperBmp/DeveloperBmp.bmp: PC bitmap, Windows 3.x format, 800 x 600 x 24
$ ~/$CHROMEOS/src/platform/vboot_reference/scripts/bitmaps/make_bmp_images.sh 'arm HWID 1234' '1366x768' false
processing BlankBmp ...
processing DeveloperBmp ...
processing RecoveryBmp ...
processing RecoveryMissingOSBmp ...
processing RecoveryNoOSBmp ...
$ file out_arm_HWID_1234/DeveloperBmp/DeveloperBmp.bmp out_arm_HWID_1234/DeveloperBmp/DeveloperBmp.bmp: PC bitmap, Windows 3.x format, 1366 x 768 x 8
Change-Id: Ia96a4e64f34350f8bd5fec51657d3cec85c4ab1c
Review URL: http://codereview.chromium.org/6273012
This CL modifies the bitmap generation script as follows:
- allow to specify required geometry of the images and to
generate a single set per FWID instead of generating all
geometries for all FWIDs
- store the images and the zip archive in a directory with
the name derived from FWID.
The CL also adds a wrapper, which given the path to the tree
containing already released GBB firmware volumes would find
all valid (as verified by the CRC in the file name) FWIDs
and generate new images for all detected FWIDs.
The geometry of the generated images is based on the FWID
contents, Marios get 1280x800 and ZGAs - 1366x768.
Once this script stops running, the scripts/bitmaps
directory contains a set of subdirectories, one per
generated set of images.
Another script ran by cygwin on a windows machine was used
to pick up all image sets and regenerate GBB firmware
volumes, will be published under a separate CL.
BUG=chrome-os-partner:792
TEST=see below:
Ran the following command:
./process_all_targets.sh ../../../chromeos-internal/third_party/autotest/files/client/site_tests/
After command completed, the following out_* directories showed up:
(bitmaps 144) ls -1d out*
out_ACER_ASPIREONE_001_8012/
out_ACER_ASPIREONE_001_DEV_0393/
out_ACER_ASPIREONE_002_0710/
out_ACER_ASPIREONE_002_DEV_1017/
out_IEC_MARIO_FISH_2330/
out_IEC_MARIO_PONY_6101/
out_IEC_MARIO_PONY_DEV_3342/
out_IEC_MARIO_PONY_DVT_8784/
out_IEC_MARIO_PONY_EVT_3495/
out_IEC_MARIO_PONY_PREDVT_6766/
with typical directory contents as follows:
(bitmaps 145) tree out_ACER_ASPIREONE_001_8012/
out_ACER_ASPIREONE_001_8012/
|-- 1366x768.zip
|-- BlankBmp
| `-- BlankBmp.bmp
|-- DeveloperBmp
| `-- DeveloperBmp.bmp
|-- RecoveryBmp
| `-- RecoveryBmp.bmp
|-- RecoveryMissingOSBmp
| `-- RecoveryMissingOSBmp.bmp
`-- RecoveryNoOSBmp
`-- RecoveryNoOSBmp.bmp
5 directories, 6 files
Review URL: http://codereview.chromium.org/4147008
Change-Id: I4620966554ca26ea91b01e65fd441c9c09db2a83
BUG=chrome-os-parter:792
TEST=none
As with every previous change to the BIOS bitmaps, you'll have to
1) get a new factory-install shim with the bitmaps embedded
2) run the factory-install shim to change the screens on the device
3) boot in developer and/or recovery mode to see the screens
There is no direct test for this particular bug alone.
Review URL: http://codereview.chromium.org/4158003
