summaryrefslogtreecommitdiffstats
path: root/tests/unit/bootloader_message_test.cpp (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Consolidate the vendor space misc usage for PixelsTianjie Xu2019-11-121-34/+0
| | | | | | | | | | | | | | | | The layout of the vendor space /misc partition was pretty confusing and lead to some usage conflicts. To formalize the layout, we create a pixel specific library with the definition & offset of various flags. The new library also handles the R/W. As a result, we will leave system domain /misc definitions in the libbootloader_message. We also switch the misc_writer binary to use more specific options instead of writing an arbitrary hex string. So we can avoid redefining the string & offset in both init script and recovery ui. Bug: 131775112 Test: unit tests pass, run misc_writer and check contents of /misc Change-Id: I00f8842a81d1929e31a1de4d5eb09575ffad47c0
* Add misc_writer.Tao Bao2019-05-211-0/+38
| | | | | | | | | | | | | | | | | | | | | bootloader_message.h currently divides /misc into four segments. The space between 2K and 16K is reserved for vendor use (e.g. bootloader persists flags). This CL adds a vendor tool "misc_writer", to allow writing data to the vendor space in /misc, before getting a dedicated HAL for accessing /misc partition (b/131775112). Targets need to explicitly include the module, then invoke the executable to write data. For example, the following command will write 3-byte data ("0xABCDEF") to offset 4 in vendor space (i.e. 2048 + 4 in /misc). $ /vendor/bin/misc_writer --vendor-space-offset 4 --hex-string 0xABCDEF Bug: 132906936 Test: Run recovery_unit_test on crosshatch. Test: Call the command via init.hardware.rc on crosshatch. Check that the call finishes successfully. Then check the contents written to /misc (`dd bs=1 skip=2048 if=/dev/block/sda2 count=32 | xxd`). Change-Id: I79548fc63fc79b705a0320868690569c3106949f
* tests: Merge recovery_component_test into recovery_unit_test.Tao Bao2019-04-301-0/+116
Most of the tests in component/ are in fact unit tests. And it doesn't look practically beneficial to distinguish between the two: - They have the same test setup; - We always run both (recovery_unit_test and recovery_component_test) at the same time; - Breaking any of them would be equally bad. This CL merges the tests in recovery_component_test into recovery_unit_test to save the effort to maintain both. Test: Run recovery_unit_test on marlin (via `adb sync data`). Test: `atest recovery_unit_test` Change-Id: I93ff32e7219cd83425a4bcfe5613978a8dd48d75