Implement host side support for open box RMA process. |
||||||||||
Issue descriptionSee go/verify-ro-firmware, "Cr50 console commands for option 1" In brief: - A command to enable verification commands. This requires physical presence. Enable times out after no verification commands have been sent for some period (15 sec? 60 sec?) - A command to read a block of AP SPI flash and print the SHA-256 hash - A command to read a block of EC SPI flash and print the SHA-256 hash Commands must fail if the device is not turned off (because if the device is on, the AP and/or EC are driving SPI and Cr50 can't.) Reading EC SPI requires forcing the EC into reset and then gang programmer mode, then back out on return. Which is why enable verification needs physical presence.
,
Feb 15 2018
here is the plan:
open box RMA verification process is driven by a descriptor file which has the following format:
<target>:<hash or dump>:{{expected value 1}, {expected value 2},...}
where 'target' is one of 'a' (AP), 'e' (EC), 'g' (EC in gang mode)
'hash or dump' is 'h' for hash, 'd' for dump
there are multiple sets of {expected value} blocks for each target area, once the first area matches to a set at a certain index, all other sets much match at the same index.
for added flexibility some expected values could be set to "don't care"
in case of 'dump' option, the expected value field can be set to 'ask operator' and depending on the operators input the check either passes or fails.
gsctool would be modified to parse this file and generate the pass/fail response, using operator's input to confirm certain fields if required.
gsctool is modified to allow retrieving hashes or dumps from the slave, say with the following command line options:
-R {a|e|g}:{d|h}:base_addr:region_size
first parameter indicates which device's memory is targeted: a - AP, e - EC, g - EC in gang mode.
second parameter tells what's required, hash or dump.
,
Feb 16 2018
Doesn't the descriptor file need to specify offset:size too? So <a|e|g>:<h|d>:<offs>:<size>:<expected result as hex> We should also compare against boardid. Otherwise, swapping binaries between boards would not be detected (and in some cases might still run but expose a vulnerability). And while HWID may move around in the flash, boardid is always directly readable. This cuts down on the number of reads needed. I suggest something like a series of: START <boardid> <a|e|g>:<h|d>:<offs>:<size>:<expected result as hex> <a|e|g>:<h|d>:<offs>:<size>:<expected result as hex> <a|e|g>:<h|d>:<offs>:<size>:<expected result as hex> <a|e|g>:<h|d>:<offs>:<size>:<expected result as hex> END Lines starting with # should be treated as comments and ignored. With white-box systems and build variants, it's possible that there might be multiple groups with the same board ID. It is recommended that the first line of each group be the HWID (or the entire GBB), so it is easy to distinguish multiple HWIDs for the same boardid.
,
Feb 16 2018
The test passes if all lines in a group succeed. It fails if that's not true. Ideally, gsctool should remember the results for lines it's tried, so that if there are 20 variants of a board with different HWID, it only reads the GBB once.
,
Feb 16 2018
re# 3, sure, board ID would allow to create a file for different boards, we still might have to have multiple result groups, as the same board ID could have different versions of firmware running on it. BTW, this means that each time new AP/EC firmware is released, this description file has to be altered to accommodate new board, and verifying the board needs to be part of the board firmware release test suite.
,
Feb 16 2018
Re#5: Yes, though we only really need to update the list-o-hashes file for a MP RO firmware change. We don't verify RW this way, since the recovery image can fix that. We can decide if we want to verify PreMP RO firmware or not. Almost certainly don't care about proto/EVT/DVT.
,
Feb 21 2018
let's move further discussion to b/73668125, it's easier to keep track of different Cr50 issues this way.
,
Feb 21 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/53ca6cfbdf3a54d574f140a3eaf926eb80a53697 commit 53ca6cfbdf3a54d574f140a3eaf926eb80a53697 Author: Vadim Bendebury <vbendeb@chromium.org> Date: Wed Feb 21 06:50:10 2018 cr50: Allow spihash extension command over USB Execution of this command requires physical presence on the DUT, this is why it is save to allow it over USB. BRANCH=cr50, cr50-mp BUG= chromium:812880 TEST=using modified gsctool verified that the command goes through and physical presence indication is requested Change-Id: I0aa371d8aaa5a480cc12d5d16edad8497142f4b4 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/927796 Reviewed-by: Mary Ruthven <mruthven@chromium.org> [modify] https://crrev.com/53ca6cfbdf3a54d574f140a3eaf926eb80a53697/common/extension.c
,
Feb 21 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/77fe675d7566d9999a4de3485e20b52e4628e972 commit 77fe675d7566d9999a4de3485e20b52e4628e972 Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Feb 21 22:19:49 2018 gsctool: allow multiple source files With the upcoming extensions it would be beneficial to be able to keep gsctool functionality spread among multiple source files. The current Makefile is also not generating proper dependencies, which was fine when gsctool utility was first introduced, but is not adequate any more, and would be even more noticeable when more source files are added. In preparation let's just convert the build scheme into separately compiling .c files, generating .d files while at it, and then linking the .o files together in a separate link operation. BRANCH=none BUG= chromium:812880 TEST=verified that gsctool still builds fine and allows to update Cr50 image. Change-Id: I537bbe6bf76ac71e8d30040b276b78513d390bbf Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923418 Reviewed-by: Randall Spangler <rspangler@chromium.org> [modify] https://crrev.com/77fe675d7566d9999a4de3485e20b52e4628e972/extra/usb_updater/.gitignore [modify] https://crrev.com/77fe675d7566d9999a4de3485e20b52e4628e972/extra/usb_updater/Makefile
,
Feb 21 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/cd76cde2173e7e18d54865d97beece25fa2cb14e commit cd76cde2173e7e18d54865d97beece25fa2cb14e Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Feb 21 22:19:50 2018 gsctool: fix Board ID retrieval function The function used to read or write Board ID value, when invoked for reading, reports the value on the console, but does not save the read value in the passed in structure. Let's always save it in the structure so that the caller of this function has access to the retrieved value. BRANCH=none BUG= chromium:812880 TEST=verified that 'gsctool -i' still operates as expected. Change-Id: I9bc713386758ca6701e6b853e042652e2f392871 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/925692 Reviewed-by: Randall Spangler <rspangler@chromium.org> [modify] https://crrev.com/cd76cde2173e7e18d54865d97beece25fa2cb14e/extra/usb_updater/gsctool.c
,
Feb 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/9a6de75ebf220effe1e428f4e253178f36360ec1 commit 9a6de75ebf220effe1e428f4e253178f36360ec1 Author: Vadim Bendebury <vbendeb@google.com> Date: Sat Feb 24 07:12:56 2018 gsctool: add RO descriptor parser This patch adds code which would parse the RO hash/dump descriptor file including a database listing expected values of hashes for various ranges of target SPI flash devices, or areas which need to be printed out (hex dumped) for operator inspection. Lines starting with '#' are completely ignored. The rest of the logical lines could actually split into multiple text lines in the file, so to separate one logical line from another at least one empty line is required. Hash descriptor database file consists of sections for various Chrome OS boards. Each board description section starts with a logical line of 4 characters which is the board ID (the same as the board's RLZ code). Each board description section includes variable number of range descriptor entries, each entry being a logical line, potentially split into multiple text lines. Each entry consists of semicolon separated fields: {a|e|g}:{h|d}:base_addr:size[:value[:value[:value...]]]] Where - the first sindgle character field defines the way the range is accessed: a - AP flash e - EC flash g - EC flash requiring gang programming mode - the second single character field defines the range type h - Cr50 returns the hash of the range d - Cr50 returns actual contents of the range (hex dump) - the third and and forth fields are base address and size of the range - ranges of type 'h' include one or more values for the hash of the range, each hash is a 64 byte hex string. Ranges of type 'd' do not include any data. All values are expressed in hex. The parser API provides functions to open the passed in hash descriptor file and find there the section for a particular board, a function to advance to the next entry in the board's section, and a function to close the file when board entries scanning is completed. When scanning the entries, the parser verifies their sanity, i.e. conformance with the above described format, that all hashes are of the right size, that there are no hashes attached to 'dump' entries and there is at least one hash attached to the 'hash' entries, and that there are no invalid characters in the hashes and address range definitions. The parser is not yet used by the gsctool, but when the new module is compiled stand alone with -DTEST_PARSER passed to the compiler, it becomes an executable which can be given the test hash database (the new file, sample_descriptor) to interpret and report success or failure. BRANCH=none BUG= chromium:812880 TEST=ran the following commands: $ gcc -DTEST_PARSER desc_parser.c -o dp $ ./dp sample_descriptor Section 1, rv 0 Section 2, rv 0 Section 3, rv 0 Unexpected data in section 4 Section 4, rv -22 Invalid hash 1 size 0 in section 5 Section 5, rv -22 Invalid hash 1 size 0 in section 6 Section 6, rv -22 Invalid hash 1 size 63 in section 7 Section 7, rv -22 Invalid hash 1 size 65 in section 8 Section 8, rv -22 Invalid hash 1 value in section 9 Section 9, rv -22 Unexpected number of variants in section 10 Section 10, rv -22 Invalid hex value 10x in section 11 Section 11, rv -22 Section 12, rv -61 $ Change-Id: I14b2754a5f6ba26b3c56ddc26d45cb4574514b69 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923419 Reviewed-by: Andrey Pronin <apronin@chromium.org> [add] https://crrev.com/9a6de75ebf220effe1e428f4e253178f36360ec1/extra/usb_updater/desc_parser.h [modify] https://crrev.com/9a6de75ebf220effe1e428f4e253178f36360ec1/extra/usb_updater/.gitignore [add] https://crrev.com/9a6de75ebf220effe1e428f4e253178f36360ec1/extra/usb_updater/sample_descriptor [modify] https://crrev.com/9a6de75ebf220effe1e428f4e253178f36360ec1/extra/usb_updater/Makefile [add] https://crrev.com/9a6de75ebf220effe1e428f4e253178f36360ec1/extra/usb_updater/desc_parser.c
,
Mar 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/84a21b4425b1f91d6c2a4887af8b3cd75782bc04 commit 84a21b4425b1f91d6c2a4887af8b3cd75782bc04 Author: Vadim Bendebury <vbendeb@chromium.org> Date: Thu Mar 01 02:06:13 2018 cr50: Allow spihash extension command over USB Execution of this command requires physical presence on the DUT, this is why it is save to allow it over USB. BRANCH=cr50, cr50-mp BUG= chromium:812880 TEST=using modified gsctool verified that the command goes through and physical presence indication is requested Change-Id: I0aa371d8aaa5a480cc12d5d16edad8497142f4b4 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/927796 Reviewed-by: Mary Ruthven <mruthven@chromium.org> (cherry picked from commit 53ca6cfbdf3a54d574f140a3eaf926eb80a53697) Reviewed-on: https://chromium-review.googlesource.com/942115 [modify] https://crrev.com/84a21b4425b1f91d6c2a4887af8b3cd75782bc04/common/extension.c
,
Mar 3 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/aec4a5dc2008d7c0ee9d0eb276e3fa7a56f46c75 commit aec4a5dc2008d7c0ee9d0eb276e3fa7a56f46c75 Author: Vadim Bendebury <vbendeb@google.com> Date: Sat Mar 03 00:29:35 2018 gsctool: add RO descriptor parser This patch adds code which would parse the RO hash/dump descriptor file including a database listing expected values of hashes for various ranges of target SPI flash devices, or areas which need to be printed out (hex dumped) for operator inspection. Lines starting with '#' are completely ignored. The rest of the logical lines could actually split into multiple text lines in the file, so to separate one logical line from another at least one empty line is required. Hash descriptor database file consists of sections for various Chrome OS boards. Each board description section starts with a logical line of 4 characters which is the board ID (the same as the board's RLZ code). Each board description section includes variable number of range descriptor entries, each entry being a logical line, potentially split into multiple text lines. Each entry consists of semicolon separated fields: {a|e|g}:{h|d}:base_addr:size[:value[:value[:value...]]]] Where - the first sindgle character field defines the way the range is accessed: a - AP flash e - EC flash g - EC flash requiring gang programming mode - the second single character field defines the range type h - Cr50 returns the hash of the range d - Cr50 returns actual contents of the range (hex dump) - the third and and forth fields are base address and size of the range - ranges of type 'h' include one or more values for the hash of the range, each hash is a 64 byte hex string. Ranges of type 'd' do not include any data. All values are expressed in hex. The parser API provides functions to open the passed in hash descriptor file and find there the section for a particular board, a function to advance to the next entry in the board's section, and a function to close the file when board entries scanning is completed. When scanning the entries, the parser verifies their sanity, i.e. conformance with the above described format, that all hashes are of the right size, that there are no hashes attached to 'dump' entries and there is at least one hash attached to the 'hash' entries, and that there are no invalid characters in the hashes and address range definitions. The parser is not yet used by the gsctool, but when the new module is compiled stand alone with -DTEST_PARSER passed to the compiler, it becomes an executable which can be given the test hash database (the new file, sample_descriptor) to interpret and report success or failure. BRANCH=none BUG= chromium:812880 TEST=ran the following commands: $ gcc -DTEST_PARSER desc_parser.c -o dp $ ./dp sample_descriptor Section 1, rv 0 Section 2, rv 0 Section 3, rv 0 Unexpected data in section 4 Section 4, rv -22 Invalid hash 1 size 0 in section 5 Section 5, rv -22 Invalid hash 1 size 0 in section 6 Section 6, rv -22 Invalid hash 1 size 63 in section 7 Section 7, rv -22 Invalid hash 1 size 65 in section 8 Section 8, rv -22 Invalid hash 1 value in section 9 Section 9, rv -22 Unexpected number of variants in section 10 Section 10, rv -22 Invalid hex value 10x in section 11 Section 11, rv -22 Section 12, rv -61 $ Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923419 Reviewed-by: Andrey Pronin <apronin@chromium.org> (cherry picked from commit 9a6de75ebf220effe1e428f4e253178f36360ec1) Change-Id: I37fcf22306ee9d085bfceb3fbad267b4d3de6535 Reviewed-on: https://chromium-review.googlesource.com/947426 Reviewed-by: Furquan Shaikh <furquan@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Trybot-Ready: Furquan Shaikh <furquan@chromium.org> [add] https://crrev.com/aec4a5dc2008d7c0ee9d0eb276e3fa7a56f46c75/extra/usb_updater/desc_parser.h [modify] https://crrev.com/aec4a5dc2008d7c0ee9d0eb276e3fa7a56f46c75/extra/usb_updater/.gitignore [add] https://crrev.com/aec4a5dc2008d7c0ee9d0eb276e3fa7a56f46c75/extra/usb_updater/sample_descriptor [modify] https://crrev.com/aec4a5dc2008d7c0ee9d0eb276e3fa7a56f46c75/extra/usb_updater/Makefile [add] https://crrev.com/aec4a5dc2008d7c0ee9d0eb276e3fa7a56f46c75/extra/usb_updater/desc_parser.c
,
Mar 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/f58c3776bc5bb66b907d2eb2a6b8aea06e4beedb commit f58c3776bc5bb66b907d2eb2a6b8aea06e4beedb Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Mar 14 01:19:42 2018 gsctool: allow multiple source files With the upcoming extensions it would be beneficial to be able to keep gsctool functionality spread among multiple source files. The current Makefile is also not generating proper dependencies, which was fine when gsctool utility was first introduced, but is not adequate any more, and would be even more noticeable when more source files are added. In preparation let's just convert the build scheme into separately compiling .c files, generating .d files while at it, and then linking the .o files together in a separate link operation. BRANCH=none BUG= chromium:812880 TEST=verified that gsctool still builds fine and allows to update Cr50 image. Change-Id: I537bbe6bf76ac71e8d30040b276b78513d390bbf Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923418 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 77fe675d7566d9999a4de3485e20b52e4628e972) Reviewed-on: https://chromium-review.googlesource.com/961608 [modify] https://crrev.com/f58c3776bc5bb66b907d2eb2a6b8aea06e4beedb/extra/usb_updater/.gitignore [modify] https://crrev.com/f58c3776bc5bb66b907d2eb2a6b8aea06e4beedb/extra/usb_updater/Makefile
,
Mar 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/434f73992164dffff02bddb783dce9b19b3941dd commit 434f73992164dffff02bddb783dce9b19b3941dd Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Mar 14 01:19:43 2018 gsctool: fix Board ID retrieval function The function used to read or write Board ID value, when invoked for reading, reports the value on the console, but does not save the read value in the passed in structure. Let's always save it in the structure so that the caller of this function has access to the retrieved value. BRANCH=none BUG= chromium:812880 TEST=verified that 'gsctool -i' still operates as expected. Change-Id: I9bc713386758ca6701e6b853e042652e2f392871 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/925692 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit cd76cde2173e7e18d54865d97beece25fa2cb14e) Reviewed-on: https://chromium-review.googlesource.com/961609 [modify] https://crrev.com/434f73992164dffff02bddb783dce9b19b3941dd/extra/usb_updater/gsctool.c
,
Mar 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/421e55e6fd6af248f3937159bf8a0c5762cbcf00 commit 421e55e6fd6af248f3937159bf8a0c5762cbcf00 Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Mar 14 01:19:47 2018 gsctool: add RO descriptor parser This patch adds code which would parse the RO hash/dump descriptor file including a database listing expected values of hashes for various ranges of target SPI flash devices, or areas which need to be printed out (hex dumped) for operator inspection. Lines starting with '#' are completely ignored. The rest of the logical lines could actually split into multiple text lines in the file, so to separate one logical line from another at least one empty line is required. Hash descriptor database file consists of sections for various Chrome OS boards. Each board description section starts with a logical line of 4 characters which is the board ID (the same as the board's RLZ code). Each board description section includes variable number of range descriptor entries, each entry being a logical line, potentially split into multiple text lines. Each entry consists of semicolon separated fields: {a|e|g}:{h|d}:base_addr:size[:value[:value[:value...]]]] Where - the first sindgle character field defines the way the range is accessed: a - AP flash e - EC flash g - EC flash requiring gang programming mode - the second single character field defines the range type h - Cr50 returns the hash of the range d - Cr50 returns actual contents of the range (hex dump) - the third and and forth fields are base address and size of the range - ranges of type 'h' include one or more values for the hash of the range, each hash is a 64 byte hex string. Ranges of type 'd' do not include any data. All values are expressed in hex. The parser API provides functions to open the passed in hash descriptor file and find there the section for a particular board, a function to advance to the next entry in the board's section, and a function to close the file when board entries scanning is completed. When scanning the entries, the parser verifies their sanity, i.e. conformance with the above described format, that all hashes are of the right size, that there are no hashes attached to 'dump' entries and there is at least one hash attached to the 'hash' entries, and that there are no invalid characters in the hashes and address range definitions. The parser is not yet used by the gsctool, but when the new module is compiled stand alone with -DTEST_PARSER passed to the compiler, it becomes an executable which can be given the test hash database (the new file, sample_descriptor) to interpret and report success or failure. BRANCH=none BUG= chromium:812880 TEST=ran the following commands: $ gcc -DTEST_PARSER desc_parser.c -o dp $ ./dp sample_descriptor Section 1, rv 0 Section 2, rv 0 Section 3, rv 0 Unexpected data in section 4 Section 4, rv -22 Invalid hash 1 size 0 in section 5 Section 5, rv -22 Invalid hash 1 size 0 in section 6 Section 6, rv -22 Invalid hash 1 size 63 in section 7 Section 7, rv -22 Invalid hash 1 size 65 in section 8 Section 8, rv -22 Invalid hash 1 value in section 9 Section 9, rv -22 Unexpected number of variants in section 10 Section 10, rv -22 Invalid hex value 10x in section 11 Section 11, rv -22 Section 12, rv -61 $ Change-Id: I14b2754a5f6ba26b3c56ddc26d45cb4574514b69 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923419 Reviewed-by: Andrey Pronin <apronin@chromium.org> (cherry picked from commit 9a6de75ebf220effe1e428f4e253178f36360ec1) Reviewed-on: https://chromium-review.googlesource.com/961611 [add] https://crrev.com/421e55e6fd6af248f3937159bf8a0c5762cbcf00/extra/usb_updater/desc_parser.h [modify] https://crrev.com/421e55e6fd6af248f3937159bf8a0c5762cbcf00/extra/usb_updater/.gitignore [add] https://crrev.com/421e55e6fd6af248f3937159bf8a0c5762cbcf00/extra/usb_updater/sample_descriptor [modify] https://crrev.com/421e55e6fd6af248f3937159bf8a0c5762cbcf00/extra/usb_updater/Makefile [add] https://crrev.com/421e55e6fd6af248f3937159bf8a0c5762cbcf00/extra/usb_updater/desc_parser.c
,
Mar 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/6bef9568603dbe2c7df6a1f8877d7a5caaccb476 commit 6bef9568603dbe2c7df6a1f8877d7a5caaccb476 Author: Vadim Bendebury <vbendeb@chromium.org> Date: Fri Mar 23 15:55:47 2018 cr50: Allow spihash extension command over USB Execution of this command requires physical presence on the DUT, this is why it is save to allow it over USB. BRANCH=cr50, cr50-mp BUG= chromium:812880 TEST=using modified gsctool verified that the command goes through and physical presence indication is requested Change-Id: I0aa371d8aaa5a480cc12d5d16edad8497142f4b4 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/927796 Reviewed-by: Mary Ruthven <mruthven@chromium.org> (cherry picked from commit 53ca6cfbdf3a54d574f140a3eaf926eb80a53697) Reviewed-on: https://chromium-review.googlesource.com/942115 (cherry picked from commit 84a21b4425b1f91d6c2a4887af8b3cd75782bc04) Reviewed-on: https://chromium-review.googlesource.com/949070 [modify] https://crrev.com/6bef9568603dbe2c7df6a1f8877d7a5caaccb476/common/extension.c
,
Jun 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/15f5fa9b2e1f44a0c594d6543f31f39a44fdd809 commit 15f5fa9b2e1f44a0c594d6543f31f39a44fdd809 Author: Vadim Bendebury <vbendeb@google.com> Date: Fri Jun 01 05:13:55 2018 gsctool: fix Board ID retrieval function The function used to read or write Board ID value, when invoked for reading, reports the value on the console, but does not save the read value in the passed in structure. Let's always save it in the structure so that the caller of this function has access to the retrieved value. BRANCH=none BUG= chromium:812880 TEST=verified that 'gsctool -i' still operates as expected. Change-Id: I9bc713386758ca6701e6b853e042652e2f392871 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/925692 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit cd76cde2173e7e18d54865d97beece25fa2cb14e) Reviewed-on: https://chromium-review.googlesource.com/1082071 Reviewed-by: Marco Chen <marcochen@chromium.org> Commit-Queue: Marco Chen <marcochen@chromium.org> Tested-by: Marco Chen <marcochen@chromium.org> [modify] https://crrev.com/15f5fa9b2e1f44a0c594d6543f31f39a44fdd809/extra/usb_updater/gsctool.c
,
Jun 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/184feab4e7cbfc45047ede318b347f1f510a6ad6 commit 184feab4e7cbfc45047ede318b347f1f510a6ad6 Author: Vadim Bendebury <vbendeb@google.com> Date: Fri Jun 01 05:41:43 2018 gsctool: allow multiple source files With the upcoming extensions it would be beneficial to be able to keep gsctool functionality spread among multiple source files. The current Makefile is also not generating proper dependencies, which was fine when gsctool utility was first introduced, but is not adequate any more, and would be even more noticeable when more source files are added. In preparation let's just convert the build scheme into separately compiling .c files, generating .d files while at it, and then linking the .o files together in a separate link operation. BRANCH=none BUG= chromium:812880 TEST=verified that gsctool still builds fine and allows to update Cr50 image. Change-Id: I537bbe6bf76ac71e8d30040b276b78513d390bbf Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923418 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 77fe675d7566d9999a4de3485e20b52e4628e972) Reviewed-on: https://chromium-review.googlesource.com/1082092 Reviewed-by: Marco Chen <marcochen@chromium.org> Commit-Queue: Marco Chen <marcochen@chromium.org> Tested-by: Marco Chen <marcochen@chromium.org> [modify] https://crrev.com/184feab4e7cbfc45047ede318b347f1f510a6ad6/extra/usb_updater/.gitignore [modify] https://crrev.com/184feab4e7cbfc45047ede318b347f1f510a6ad6/extra/usb_updater/Makefile
,
Jun 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/3ee5cbbbe39651c793e607c540229d8f846dbf79 commit 3ee5cbbbe39651c793e607c540229d8f846dbf79 Author: Vadim Bendebury <vbendeb@google.com> Date: Fri Jun 01 05:45:48 2018 gsctool: add RO descriptor parser This patch adds code which would parse the RO hash/dump descriptor file including a database listing expected values of hashes for various ranges of target SPI flash devices, or areas which need to be printed out (hex dumped) for operator inspection. Lines starting with '#' are completely ignored. The rest of the logical lines could actually split into multiple text lines in the file, so to separate one logical line from another at least one empty line is required. Hash descriptor database file consists of sections for various Chrome OS boards. Each board description section starts with a logical line of 4 characters which is the board ID (the same as the board's RLZ code). Each board description section includes variable number of range descriptor entries, each entry being a logical line, potentially split into multiple text lines. Each entry consists of semicolon separated fields: {a|e|g}:{h|d}:base_addr:size[:value[:value[:value...]]]] Where - the first sindgle character field defines the way the range is accessed: a - AP flash e - EC flash g - EC flash requiring gang programming mode - the second single character field defines the range type h - Cr50 returns the hash of the range d - Cr50 returns actual contents of the range (hex dump) - the third and and forth fields are base address and size of the range - ranges of type 'h' include one or more values for the hash of the range, each hash is a 64 byte hex string. Ranges of type 'd' do not include any data. All values are expressed in hex. The parser API provides functions to open the passed in hash descriptor file and find there the section for a particular board, a function to advance to the next entry in the board's section, and a function to close the file when board entries scanning is completed. When scanning the entries, the parser verifies their sanity, i.e. conformance with the above described format, that all hashes are of the right size, that there are no hashes attached to 'dump' entries and there is at least one hash attached to the 'hash' entries, and that there are no invalid characters in the hashes and address range definitions. The parser is not yet used by the gsctool, but when the new module is compiled stand alone with -DTEST_PARSER passed to the compiler, it becomes an executable which can be given the test hash database (the new file, sample_descriptor) to interpret and report success or failure. BRANCH=none BUG= chromium:812880 TEST=ran the following commands: $ gcc -DTEST_PARSER desc_parser.c -o dp $ ./dp sample_descriptor Section 1, rv 0 Section 2, rv 0 Section 3, rv 0 Unexpected data in section 4 Section 4, rv -22 Invalid hash 1 size 0 in section 5 Section 5, rv -22 Invalid hash 1 size 0 in section 6 Section 6, rv -22 Invalid hash 1 size 63 in section 7 Section 7, rv -22 Invalid hash 1 size 65 in section 8 Section 8, rv -22 Invalid hash 1 value in section 9 Section 9, rv -22 Unexpected number of variants in section 10 Section 10, rv -22 Invalid hex value 10x in section 11 Section 11, rv -22 Section 12, rv -61 $ Change-Id: I14b2754a5f6ba26b3c56ddc26d45cb4574514b69 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923419 Reviewed-by: Andrey Pronin <apronin@chromium.org> (cherry picked from commit 9a6de75ebf220effe1e428f4e253178f36360ec1) Reviewed-on: https://chromium-review.googlesource.com/1082093 Reviewed-by: Marco Chen <marcochen@chromium.org> Commit-Queue: Marco Chen <marcochen@chromium.org> Tested-by: Marco Chen <marcochen@chromium.org> [add] https://crrev.com/3ee5cbbbe39651c793e607c540229d8f846dbf79/extra/usb_updater/desc_parser.h [modify] https://crrev.com/3ee5cbbbe39651c793e607c540229d8f846dbf79/extra/usb_updater/.gitignore [add] https://crrev.com/3ee5cbbbe39651c793e607c540229d8f846dbf79/extra/usb_updater/sample_descriptor [modify] https://crrev.com/3ee5cbbbe39651c793e607c540229d8f846dbf79/extra/usb_updater/Makefile [add] https://crrev.com/3ee5cbbbe39651c793e607c540229d8f846dbf79/extra/usb_updater/desc_parser.c
,
Jul 18
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/f7c8c331a306285b61cfe14a9a78f14a75d4a8e4 commit f7c8c331a306285b61cfe14a9a78f14a75d4a8e4 Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Jul 18 05:19:21 2018 gsctool: allow multiple source files With the upcoming extensions it would be beneficial to be able to keep gsctool functionality spread among multiple source files. The current Makefile is also not generating proper dependencies, which was fine when gsctool utility was first introduced, but is not adequate any more, and would be even more noticeable when more source files are added. In preparation let's just convert the build scheme into separately compiling .c files, generating .d files while at it, and then linking the .o files together in a separate link operation. BRANCH=none BUG= chromium:812880 TEST=verified that gsctool still builds fine and allows to update Cr50 image. Change-Id: I537bbe6bf76ac71e8d30040b276b78513d390bbf Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923418 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 77fe675d7566d9999a4de3485e20b52e4628e972) Reviewed-on: https://chromium-review.googlesource.com/1141527 Reviewed-by: Nick Sanders <nsanders@chromium.org> Commit-Queue: Nick Sanders <nsanders@chromium.org> Tested-by: Nick Sanders <nsanders@chromium.org> [modify] https://crrev.com/f7c8c331a306285b61cfe14a9a78f14a75d4a8e4/extra/usb_updater/.gitignore [modify] https://crrev.com/f7c8c331a306285b61cfe14a9a78f14a75d4a8e4/extra/usb_updater/Makefile
,
Jul 18
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/41234da76c8f3a797ca665c66a30302cda8803be commit 41234da76c8f3a797ca665c66a30302cda8803be Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Jul 18 05:19:22 2018 gsctool: fix Board ID retrieval function The function used to read or write Board ID value, when invoked for reading, reports the value on the console, but does not save the read value in the passed in structure. Let's always save it in the structure so that the caller of this function has access to the retrieved value. BRANCH=none BUG= chromium:812880 TEST=verified that 'gsctool -i' still operates as expected. Change-Id: I9bc713386758ca6701e6b853e042652e2f392871 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/925692 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit cd76cde2173e7e18d54865d97beece25fa2cb14e) Reviewed-on: https://chromium-review.googlesource.com/1141524 Reviewed-by: Nick Sanders <nsanders@chromium.org> Commit-Queue: Nick Sanders <nsanders@chromium.org> Tested-by: Nick Sanders <nsanders@chromium.org> [modify] https://crrev.com/41234da76c8f3a797ca665c66a30302cda8803be/extra/usb_updater/gsctool.c
,
Jul 18
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/e93805cb49a887877ac89fe3af86611af437a902 commit e93805cb49a887877ac89fe3af86611af437a902 Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Jul 18 05:25:30 2018 gsctool: add RO descriptor parser This patch adds code which would parse the RO hash/dump descriptor file including a database listing expected values of hashes for various ranges of target SPI flash devices, or areas which need to be printed out (hex dumped) for operator inspection. Lines starting with '#' are completely ignored. The rest of the logical lines could actually split into multiple text lines in the file, so to separate one logical line from another at least one empty line is required. Hash descriptor database file consists of sections for various Chrome OS boards. Each board description section starts with a logical line of 4 characters which is the board ID (the same as the board's RLZ code). Each board description section includes variable number of range descriptor entries, each entry being a logical line, potentially split into multiple text lines. Each entry consists of semicolon separated fields: {a|e|g}:{h|d}:base_addr:size[:value[:value[:value...]]]] Where - the first sindgle character field defines the way the range is accessed: a - AP flash e - EC flash g - EC flash requiring gang programming mode - the second single character field defines the range type h - Cr50 returns the hash of the range d - Cr50 returns actual contents of the range (hex dump) - the third and and forth fields are base address and size of the range - ranges of type 'h' include one or more values for the hash of the range, each hash is a 64 byte hex string. Ranges of type 'd' do not include any data. All values are expressed in hex. The parser API provides functions to open the passed in hash descriptor file and find there the section for a particular board, a function to advance to the next entry in the board's section, and a function to close the file when board entries scanning is completed. When scanning the entries, the parser verifies their sanity, i.e. conformance with the above described format, that all hashes are of the right size, that there are no hashes attached to 'dump' entries and there is at least one hash attached to the 'hash' entries, and that there are no invalid characters in the hashes and address range definitions. The parser is not yet used by the gsctool, but when the new module is compiled stand alone with -DTEST_PARSER passed to the compiler, it becomes an executable which can be given the test hash database (the new file, sample_descriptor) to interpret and report success or failure. BRANCH=none BUG= chromium:812880 TEST=ran the following commands: $ gcc -DTEST_PARSER desc_parser.c -o dp $ ./dp sample_descriptor Section 1, rv 0 Section 2, rv 0 Section 3, rv 0 Unexpected data in section 4 Section 4, rv -22 Invalid hash 1 size 0 in section 5 Section 5, rv -22 Invalid hash 1 size 0 in section 6 Section 6, rv -22 Invalid hash 1 size 63 in section 7 Section 7, rv -22 Invalid hash 1 size 65 in section 8 Section 8, rv -22 Invalid hash 1 value in section 9 Section 9, rv -22 Unexpected number of variants in section 10 Section 10, rv -22 Invalid hex value 10x in section 11 Section 11, rv -22 Section 12, rv -61 $ Change-Id: I14b2754a5f6ba26b3c56ddc26d45cb4574514b69 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923419 Reviewed-by: Andrey Pronin <apronin@chromium.org> (cherry picked from commit 9a6de75ebf220effe1e428f4e253178f36360ec1) Reviewed-on: https://chromium-review.googlesource.com/1141529 Reviewed-by: Nick Sanders <nsanders@chromium.org> Commit-Queue: Nick Sanders <nsanders@chromium.org> Tested-by: Nick Sanders <nsanders@chromium.org> [add] https://crrev.com/e93805cb49a887877ac89fe3af86611af437a902/extra/usb_updater/desc_parser.h [modify] https://crrev.com/e93805cb49a887877ac89fe3af86611af437a902/extra/usb_updater/.gitignore [add] https://crrev.com/e93805cb49a887877ac89fe3af86611af437a902/extra/usb_updater/sample_descriptor [modify] https://crrev.com/e93805cb49a887877ac89fe3af86611af437a902/extra/usb_updater/Makefile [add] https://crrev.com/e93805cb49a887877ac89fe3af86611af437a902/extra/usb_updater/desc_parser.c
,
Nov 13
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/b349b8550710bf7527680b4097450330fcee2d86 commit b349b8550710bf7527680b4097450330fcee2d86 Author: Vadim Bendebury <vbendeb@google.com> Date: Tue Nov 13 00:19:02 2018 gsctool: fix Board ID retrieval function The function used to read or write Board ID value, when invoked for reading, reports the value on the console, but does not save the read value in the passed in structure. Let's always save it in the structure so that the caller of this function has access to the retrieved value. BRANCH=none BUG= chromium:812880 TEST=verified that 'gsctool -i' still operates as expected. Change-Id: I9bc713386758ca6701e6b853e042652e2f392871 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/925692 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit cd76cde2173e7e18d54865d97beece25fa2cb14e) Reviewed-on: https://chromium-review.googlesource.com/1141524 Reviewed-by: Nick Sanders <nsanders@chromium.org> Commit-Queue: Nick Sanders <nsanders@chromium.org> Tested-by: Nick Sanders <nsanders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1221371 Reviewed-by: Marco Chen <marcochen@chromium.org> Commit-Queue: Marco Chen <marcochen@chromium.org> Tested-by: Marco Chen <marcochen@chromium.org> [modify] https://crrev.com/b349b8550710bf7527680b4097450330fcee2d86/extra/usb_updater/gsctool.c
,
Nov 13
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/166c023e9954ef35ba4f0d1d89104f14f358e3a1 commit 166c023e9954ef35ba4f0d1d89104f14f358e3a1 Author: Vadim Bendebury <vbendeb@google.com> Date: Tue Nov 13 00:19:05 2018 gsctool: allow multiple source files With the upcoming extensions it would be beneficial to be able to keep gsctool functionality spread among multiple source files. The current Makefile is also not generating proper dependencies, which was fine when gsctool utility was first introduced, but is not adequate any more, and would be even more noticeable when more source files are added. In preparation let's just convert the build scheme into separately compiling .c files, generating .d files while at it, and then linking the .o files together in a separate link operation. BRANCH=none BUG= chromium:812880 TEST=verified that gsctool still builds fine and allows to update Cr50 image. Change-Id: I537bbe6bf76ac71e8d30040b276b78513d390bbf Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923418 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 77fe675d7566d9999a4de3485e20b52e4628e972) Reviewed-on: https://chromium-review.googlesource.com/1141527 Reviewed-by: Nick Sanders <nsanders@chromium.org> Commit-Queue: Nick Sanders <nsanders@chromium.org> Tested-by: Nick Sanders <nsanders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1221375 Reviewed-by: Marco Chen <marcochen@chromium.org> Commit-Queue: Marco Chen <marcochen@chromium.org> Tested-by: Marco Chen <marcochen@chromium.org> [modify] https://crrev.com/166c023e9954ef35ba4f0d1d89104f14f358e3a1/extra/usb_updater/.gitignore [modify] https://crrev.com/166c023e9954ef35ba4f0d1d89104f14f358e3a1/extra/usb_updater/Makefile
,
Nov 13
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/9dde6d63da92cbacdd3b67e94b2bd61eb2c1faf5 commit 9dde6d63da92cbacdd3b67e94b2bd61eb2c1faf5 Author: Vadim Bendebury <vbendeb@google.com> Date: Tue Nov 13 00:19:06 2018 gsctool: add RO descriptor parser This patch adds code which would parse the RO hash/dump descriptor file including a database listing expected values of hashes for various ranges of target SPI flash devices, or areas which need to be printed out (hex dumped) for operator inspection. Lines starting with '#' are completely ignored. The rest of the logical lines could actually split into multiple text lines in the file, so to separate one logical line from another at least one empty line is required. Hash descriptor database file consists of sections for various Chrome OS boards. Each board description section starts with a logical line of 4 characters which is the board ID (the same as the board's RLZ code). Each board description section includes variable number of range descriptor entries, each entry being a logical line, potentially split into multiple text lines. Each entry consists of semicolon separated fields: {a|e|g}:{h|d}:base_addr:size[:value[:value[:value...]]]] Where - the first sindgle character field defines the way the range is accessed: a - AP flash e - EC flash g - EC flash requiring gang programming mode - the second single character field defines the range type h - Cr50 returns the hash of the range d - Cr50 returns actual contents of the range (hex dump) - the third and and forth fields are base address and size of the range - ranges of type 'h' include one or more values for the hash of the range, each hash is a 64 byte hex string. Ranges of type 'd' do not include any data. All values are expressed in hex. The parser API provides functions to open the passed in hash descriptor file and find there the section for a particular board, a function to advance to the next entry in the board's section, and a function to close the file when board entries scanning is completed. When scanning the entries, the parser verifies their sanity, i.e. conformance with the above described format, that all hashes are of the right size, that there are no hashes attached to 'dump' entries and there is at least one hash attached to the 'hash' entries, and that there are no invalid characters in the hashes and address range definitions. The parser is not yet used by the gsctool, but when the new module is compiled stand alone with -DTEST_PARSER passed to the compiler, it becomes an executable which can be given the test hash database (the new file, sample_descriptor) to interpret and report success or failure. BRANCH=none BUG= chromium:812880 TEST=ran the following commands: $ gcc -DTEST_PARSER desc_parser.c -o dp $ ./dp sample_descriptor Section 1, rv 0 Section 2, rv 0 Section 3, rv 0 Unexpected data in section 4 Section 4, rv -22 Invalid hash 1 size 0 in section 5 Section 5, rv -22 Invalid hash 1 size 0 in section 6 Section 6, rv -22 Invalid hash 1 size 63 in section 7 Section 7, rv -22 Invalid hash 1 size 65 in section 8 Section 8, rv -22 Invalid hash 1 value in section 9 Section 9, rv -22 Unexpected number of variants in section 10 Section 10, rv -22 Invalid hex value 10x in section 11 Section 11, rv -22 Section 12, rv -61 $ Change-Id: I14b2754a5f6ba26b3c56ddc26d45cb4574514b69 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923419 Reviewed-by: Andrey Pronin <apronin@chromium.org> (cherry picked from commit 9a6de75ebf220effe1e428f4e253178f36360ec1) Reviewed-on: https://chromium-review.googlesource.com/1141529 Reviewed-by: Nick Sanders <nsanders@chromium.org> Commit-Queue: Nick Sanders <nsanders@chromium.org> Tested-by: Nick Sanders <nsanders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1221376 Reviewed-by: Marco Chen <marcochen@chromium.org> Commit-Queue: Marco Chen <marcochen@chromium.org> Tested-by: Marco Chen <marcochen@chromium.org> [add] https://crrev.com/9dde6d63da92cbacdd3b67e94b2bd61eb2c1faf5/extra/usb_updater/desc_parser.h [modify] https://crrev.com/9dde6d63da92cbacdd3b67e94b2bd61eb2c1faf5/extra/usb_updater/.gitignore [add] https://crrev.com/9dde6d63da92cbacdd3b67e94b2bd61eb2c1faf5/extra/usb_updater/sample_descriptor [modify] https://crrev.com/9dde6d63da92cbacdd3b67e94b2bd61eb2c1faf5/extra/usb_updater/Makefile [add] https://crrev.com/9dde6d63da92cbacdd3b67e94b2bd61eb2c1faf5/extra/usb_updater/desc_parser.c
,
Dec 5
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/564ec123b44a42ec09a983111a414fa67f3f62f3 commit 564ec123b44a42ec09a983111a414fa67f3f62f3 Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Dec 05 00:35:39 2018 gsctool: fix Board ID retrieval function The function used to read or write Board ID value, when invoked for reading, reports the value on the console, but does not save the read value in the passed in structure. Let's always save it in the structure so that the caller of this function has access to the retrieved value. BRANCH=none BUG= chromium:812880 TEST=verified that 'gsctool -i' still operates as expected. Change-Id: I9bc713386758ca6701e6b853e042652e2f392871 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/925692 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1358184 Reviewed-by: Chia-Hsiu Chang <chia-hsiu.chang@quanta.corp-partner.google.com> Reviewed-by: Marco Chen <marcochen@chromium.org> Commit-Queue: Chia-Hsiu Chang <chia-hsiu.chang@quanta.corp-partner.google.com> Tested-by: Chia-Hsiu Chang <chia-hsiu.chang@quanta.corp-partner.google.com> [modify] https://crrev.com/564ec123b44a42ec09a983111a414fa67f3f62f3/extra/usb_updater/gsctool.c
,
Dec 5
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/27987233acb1b3029992cf46a0895288355db739 commit 27987233acb1b3029992cf46a0895288355db739 Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Dec 05 00:35:43 2018 gsctool: allow multiple source files With the upcoming extensions it would be beneficial to be able to keep gsctool functionality spread among multiple source files. The current Makefile is also not generating proper dependencies, which was fine when gsctool utility was first introduced, but is not adequate any more, and would be even more noticeable when more source files are added. In preparation let's just convert the build scheme into separately compiling .c files, generating .d files while at it, and then linking the .o files together in a separate link operation. BRANCH=none BUG= chromium:812880 TEST=verified that gsctool still builds fine and allows to update Cr50 image. Change-Id: I537bbe6bf76ac71e8d30040b276b78513d390bbf Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923418 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1358188 Reviewed-by: Chia-Hsiu Chang <chia-hsiu.chang@quanta.corp-partner.google.com> Reviewed-by: Marco Chen <marcochen@chromium.org> Commit-Queue: Chia-Hsiu Chang <chia-hsiu.chang@quanta.corp-partner.google.com> Tested-by: Chia-Hsiu Chang <chia-hsiu.chang@quanta.corp-partner.google.com> [modify] https://crrev.com/27987233acb1b3029992cf46a0895288355db739/extra/usb_updater/.gitignore [modify] https://crrev.com/27987233acb1b3029992cf46a0895288355db739/extra/usb_updater/Makefile
,
Dec 5
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/ec/+/71254fbdef3f2fd70834575fa5ebce276e1a79b5 commit 71254fbdef3f2fd70834575fa5ebce276e1a79b5 Author: Vadim Bendebury <vbendeb@google.com> Date: Wed Dec 05 00:35:44 2018 gsctool: add RO descriptor parser This patch adds code which would parse the RO hash/dump descriptor file including a database listing expected values of hashes for various ranges of target SPI flash devices, or areas which need to be printed out (hex dumped) for operator inspection. Lines starting with '#' are completely ignored. The rest of the logical lines could actually split into multiple text lines in the file, so to separate one logical line from another at least one empty line is required. Hash descriptor database file consists of sections for various Chrome OS boards. Each board description section starts with a logical line of 4 characters which is the board ID (the same as the board's RLZ code). Each board description section includes variable number of range descriptor entries, each entry being a logical line, potentially split into multiple text lines. Each entry consists of semicolon separated fields: {a|e|g}:{h|d}:base_addr:size[:value[:value[:value...]]]] Where - the first sindgle character field defines the way the range is accessed: a - AP flash e - EC flash g - EC flash requiring gang programming mode - the second single character field defines the range type h - Cr50 returns the hash of the range d - Cr50 returns actual contents of the range (hex dump) - the third and and forth fields are base address and size of the range - ranges of type 'h' include one or more values for the hash of the range, each hash is a 64 byte hex string. Ranges of type 'd' do not include any data. All values are expressed in hex. The parser API provides functions to open the passed in hash descriptor file and find there the section for a particular board, a function to advance to the next entry in the board's section, and a function to close the file when board entries scanning is completed. When scanning the entries, the parser verifies their sanity, i.e. conformance with the above described format, that all hashes are of the right size, that there are no hashes attached to 'dump' entries and there is at least one hash attached to the 'hash' entries, and that there are no invalid characters in the hashes and address range definitions. The parser is not yet used by the gsctool, but when the new module is compiled stand alone with -DTEST_PARSER passed to the compiler, it becomes an executable which can be given the test hash database (the new file, sample_descriptor) to interpret and report success or failure. BRANCH=none BUG= chromium:812880 TEST=ran the following commands: $ gcc -DTEST_PARSER desc_parser.c -o dp $ ./dp sample_descriptor Section 1, rv 0 Section 2, rv 0 Section 3, rv 0 Unexpected data in section 4 Section 4, rv -22 Invalid hash 1 size 0 in section 5 Section 5, rv -22 Invalid hash 1 size 0 in section 6 Section 6, rv -22 Invalid hash 1 size 63 in section 7 Section 7, rv -22 Invalid hash 1 size 65 in section 8 Section 8, rv -22 Invalid hash 1 value in section 9 Section 9, rv -22 Unexpected number of variants in section 10 Section 10, rv -22 Invalid hex value 10x in section 11 Section 11, rv -22 Section 12, rv -61 $ Change-Id: I14b2754a5f6ba26b3c56ddc26d45cb4574514b69 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/923419 Reviewed-by: Andrey Pronin <apronin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1358189 Reviewed-by: Chia-Hsiu Chang <chia-hsiu.chang@quanta.corp-partner.google.com> Reviewed-by: Marco Chen <marcochen@chromium.org> Commit-Queue: Chia-Hsiu Chang <chia-hsiu.chang@quanta.corp-partner.google.com> Tested-by: Chia-Hsiu Chang <chia-hsiu.chang@quanta.corp-partner.google.com> [add] https://crrev.com/71254fbdef3f2fd70834575fa5ebce276e1a79b5/extra/usb_updater/desc_parser.h [modify] https://crrev.com/71254fbdef3f2fd70834575fa5ebce276e1a79b5/extra/usb_updater/.gitignore [add] https://crrev.com/71254fbdef3f2fd70834575fa5ebce276e1a79b5/extra/usb_updater/sample_descriptor [modify] https://crrev.com/71254fbdef3f2fd70834575fa5ebce276e1a79b5/extra/usb_updater/Makefile [add] https://crrev.com/71254fbdef3f2fd70834575fa5ebce276e1a79b5/extra/usb_updater/desc_parser.c |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by vbendeb@chromium.org
, Feb 15 2018