Device tree binary missing from mbl-console-image-test-imx7s-warp-mbl image artifact
davisga opened this issue · 8 comments
Description
The imx7s-warp.dtb device tree binary is missing from the mbl-console-image-test-imx7s-warp-mbl image artifact (mbl-console-image-test-imx7s-warp-mbl.tar.xz) when building for WaRP7 platform.
Building with mbl-os-0.5 branch (6e167a5) of mbl-tools.
./mbl-tools/build-mbl/run-me.sh --builddir /home/davisg/dev/mbed/build-warp7 --inject-mcc /home/davisg/dev/mbed/mbed_cloud_dev_credentials.c --inject-mcc /home/davisg/dev/mbed/update-resources/update_default_resources.c --outputdir /home/davisg/dev/mbed/artifacts-warp7/ --downloaddir /home/davisg/dev/mbed/downloads -- --branch mbl-os-0.5 --machine imx7s-warp-mbl
Manually added imx7s-warp.dtb to /boot/ directory of rootfs1 partition to get MBL to boot.
This also causes a problem when trying to do a Pelion update (i.e., manifest-tool update device).
Issue request type
[ ] Question
[ ] Enhancement
[x ] Bug
Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-611
The tar file (mbl-console-image-test-imx7s-warp-mbl-tar.xz) only contains the root file system, and is only used as part of the update sequence via the Pelion cloud. To provision a new WaRP7 board, you will need to flash a full disk image (mbl-console-image-test-imx7s-warp-mbl.wic.gz). Please follow the documentation that tells you how to use the bmap tool to flash this image - https://os.mbed.com/docs/mbed-linux-os/v0.5/getting-started/writing-and-booting-the-disk-image.html
There are DTBs that live in the boot partition (inside FITs or FIPs), but the DTB doesn't live on the root file system partition. You can find out more information about our partitions and secure boot methodology by reviewing the documentation in https://github.com/ARMmbed/meta-mbl/tree/mbl-os-0.5/docs.
Yes, I followed the "writing-and-booting-the-disk-image" steps and ran the bmap command as described:
bmaptool copy --bmap artifacts-warp7/machine/imx7s-warp-mbl/images/mbl-console-image-test/images/mbl-console-image-test-imx7s-warp-mbl.wic.bmap artifacts-warp7/machine/imx7s-warp-mbl/images/mbl-console-image-test/images/mbl-console-image-test-imx7s-warp-mbl.wic.gz /dev/disk/by-id/usb-Linux_UMS_disk_0-0\:0>
I am suspecting that this may be a u-boot environment variables issue. The MBL image update does not touch the u-boot environment variables. Correct? I assume the u-boot environment variables for the WaRP7 are being stored in one of the eMMC boot blocks. Correct? (I did not dig into u-boot to verify this.) The environment variables were left over from the stock android boot. Are the u-boot environment variables required to boot MBL documented anywhere?
Thanks for confirming.
It does sound like there maybe some leftovers from the Android boot sequence. To help us investigate further, can you please supply the following:
- a full boot log;
- the u-boot environment by using "printenv";
- the OS partition table by using the "lsblk" command after boot
Thank you for the logs. The logs confirm that the u-boot environment is incorrect, and hasn't been overwritten in flashing and so is not booting from the correct partition. It shows mmcpart=3 when it should be 1.
In case there are any other possible issues, we suggest you reflash the entire image using dd.
First unpack the wic.gz image:
gzip -dk mbl-console-image-test-imx7s-warp-mbl.wic.gz
Then follow the board flashing instructions, but replace the sudo bmap-tool copy command with:
sudo dd if=mbl-console-image-test-imx7s-warp-mbl.wic of=/dev/disk/by-id/<device-file-name> bs=1M oflag=sync conv=fsync
Just changing to mmcpart=1 in u-boot seems to have fixed things. Able to do rootfs update also now.
I will try re-flashing steps above a report back.
Documentation has been updated (step 7) to indicate a full disk image must be flashed to start with. This has been done for the 0.5 release and will be continued for future releases.