On Mon, Feb 06, 2023 at 12:50:20AM +0100, Safae Ouajih wrote:
test_abootimg is extended to include the testing of boot images version 4. For this, boot.img and vendor_boot.img have been generated using mkbootimg tool with setting the header version to 4.
This tests:
- Getting the header version using abootimg
- Extracting the load address of the dtb
- Extracting the dtb start address in RAM
Running test: $ ./test/py/test.py --bd sandbox --build -k test_abootimg
Signed-off-by: Safae Ouajih souajih@baylibre.com Reviewed-by: Simon Glass sjg@chromium.org
test/py/tests/test_android/test_abootimg.py | 136 ++++++++++++++++++-- 1 file changed, 123 insertions(+), 13 deletions(-)
Alright, so I don't know where the failure starts, exactly. And to make testing this easier, there's currently the trini/u-boot-gitlab-ci-runner:jammy-20230126-07Feb2023 container you can use to replicate my problem. The problem is that while this test passes in CI, with GCC, with Clang it fails, consistently: https://source.denx.de/u-boot/u-boot/-/jobs/572239#L284 and I'm not quite sure why. I hope that building sandbox with clang and also just trying these features out interactively will fail too, and so debugging this will be less of a problem.