Unable to generate sdrescue with board support package v1032.1

Products Support DragonBoard410c
#1

Hi folks,

I tried to generate a SD rescue image using db-boot-tools, but it seems that I can’t get it working with Board Support Package version higher than v1.4.

So that works:

sudo ./mksdcard -p ./dragonboard410c/linux/sdrescue.txt -i ~/src/bootloaders-linux/v1.4/ -i ~/src/lk/build-msm8916/ -o sdrescue_v1.4_unsigned.img

But these two images don’t:

sudo ./mksdcard -p ./dragonboard410c/linux/sdrescue.txt -i ~/src/bootloaders-linux/v1032.1/ -i ~/src/lk/build-msm8916/ -o sdrescue_v1032.1_unsigned.img
mv ~/src/lk/build-msm8916/emmc_appsboot.mbn ~/src/lk/build-msm8916/emmc_appsboot_unsigned.mbn
mv ~/src/lk/build-msm8916/emmc_appsboot_signed.mbn ~/src/lk/build-msm8916/emmc_appsboot.mbn
sudo ./mksdcard -p ./dragonboard410c/linux/sdrescue.txt -i ~/src/bootloaders-linux/v1032.1/ -i ~/src/lk/build-msm8916/ -o sdrescue_v1032.1_signed.img

I get the following error with both the signed and unsigned images:

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.0-00286
S - IMAGE_VARIANT_STRING=HAAAANAZA
S - OEM_IMAGE_VERSION_STRING=CRM
S - Boot Config, 0x000002e3
S - Core 0 Frequency, 0 MHz
B - 1545 - PBL, Start
B - 3490 - bootable_media_detect_entry, Start
B - 156912 - bootable_media_detect_success, Start
B - 156916 - elf_loader_entry, Start
B - 159671 - auth_hash_seg_entry, Start
B - 159882 - auth_hash_seg_exit, Start
B - 188959 - elf_segs_hash_verify_entry, Start
B - 249554 - PBL, End
B - 204990 - SBL1, Start
B - 255224 - pm_device_init, Start
D - 14243 - pm_device_init, Delta
B - 269803 - boot_flash_init, Start
D - 0 - boot_flash_init, Delta
B - 273829 - boot_config_data_table_init, Start
D - 163022 - boot_config_data_table_init, Delta - (0 Bytes)
B - 441396 - CDT version:3,Platform ID:8,Major ID:1,Minor ID:0,Subtype:0
B - 447221 - sbl1_ddr_set_params, Start
B - 451186 - cpr_init, Start
D - 0 - cpr_init, Delta
B - 456798 - Pre_DDR_clock_init, Start
D - 183 - Pre_DDR_clock_init, Delta
D - 0 - sbl1_ddr_set_params, Delta
B - 469364 - pm_driver_init, Start
D - 3721 - pm_driver_init, Delta
B - 481717 - clock_init, Start
D - 30 - clock_init, Delta
B - 491843 - Image Load, Start
B - 491904 - Error code 300d at boot_elf_loader.c Line 1306

I noticed that the signed bootloader is quite smaller than the unsigned one, but couldn’t really tell it that made sense or not.

$ ls -lh build-msm8916/emmc_appsboot*
-rwxr-xr-x 1 user user 755K Jun 14 12:21 build-msm8916/emmc_appsboot_unsigned.mbn
-rw-r–r-- 1 user user 533K Jun 14 12:21 build-msm8916/emmc_appsboot_signed.mbn
$ git describe
dragonboard410c-LA.BR.1.2.7-03810-8x16.0-linaro1

Thanks for your help,
Damien

#2

hi @damienr,

in the v1032.1 release a few changes were done to the firmware files, and your problem is very likely because of sbl1.mbn vs sbl1.sd.mbn. For SD boot you need to use sbl1.sd.mbn , sbl1.mbn won’t work.
The new sbl1.mbn which has a couple of new features (like checking LK signature and support for external CDT partition) does not work (yet) with SD boot, so we put a copy of the previous sbl1.mbn (e.g. from v1.4…) into the firmware release just for SD boot. Hopefully this will be resolved in the next firmware release from QCOM.

You might be aware that we have a build job that creates the SD rescue image that we publish, this is the commit where we transitioned from v1.4 to v1032.1, from this commit you can clearly see what we had to change to adapt to the new firmware release:

https://git.linaro.org/ci/job/configs.git/commit?id=bac369c7dc63477933f16936718915bcbdc022ff

Also, note that instead of using the firmware release from QCOM, you can use our own release, for example: dragonboard410c_bootloader_sd_linux-79.zip. We create a ‘bootloader’ package for each main use case (Linux vs Android MMC boot or SD boot). In our release the right files from the QC release are included, e.g. sbl1.mbn in the sd_linux bootloader will allow booting from SD card…

#3

Thanks @anon91830841, that’s very helpful.

To give you a bit more context, I have a SoM which requires a recent (>v1.4) Board Support Package to initialize the RAM properly, but the issue is that I flashed the sbl1.mbn from v1.4 (I wasn’t aware of the issue at that time…), that means I can’t boot from the eMMC anymore. But as you said that the new sbl1.mbn doesn’t work (yet) with SD boot, I think this SoM is bricked for now.

#4

But you said that the following worked:

Which means that you can boot from SD using the v1.4 at least, no? If so, you should have the board into fastboot mode, and you could reflash the eMMC? Am I missing anything here?

The reason why the second command fails is because you need to copy sbl1.sd.mbn to sbl1.bm before running the mksdcard tool.

#5

Sorry, I forgot to mention that I have two different SoMs, one which can be initialized with the v1.4, not the other.

When I first bricked the “new” SoM (with extended memory), I figured that using the rescue image provided here failed to initialize the RAM properly, and that I needed a newer version of sbl1.mbn. But then I faced this error with version 1032.1

Error code 300d at boot_elf_loader.c Line 1306

So I tried version 1032.1 of sbl1.mbn on the “old” SoM, and faced the same error 300d. On this one I don’t have RAM initialization issue if I use version 1.4 of sbl1.mbn, and it can also load from the SD card, so this one is not bricked.

But as the “new” SoM’s RAM can only be initiliazed properly with version > 1.4, versions which cannot load other blobs from the SD card, it ends up being bricked. Sorry for the confusion. First post was about the “old” SoM, second one about the “new” one.

#6

ok, thanks for the follow up… unfortunately our releases, especially the low level bootloader components are meant to be used with DB410c, and are not tested on any of the various clones/variants.

however in general, everything we do for DB410c in terms of tooling and builds, is open for anyone, so we really hope/expect that the other board vendors can simply use what we’ve done as reference work…

it is possible to recover with a USB based flashing tool, and we have implemented a tool that we will soon release as open source… hopefully this will be another tool that can be leveraged by the snapdragon/dragonboard community at large.