What is the booloader like on the DragonBoard? I’ve been porting FreeBSD to AArch64, and have started getting it to boot on the HiKey I have access to. At the moment we rely on UEFI as the boot environment so this would be preferred, however we may be able to handle other boot code depending on what it provides, and how it expects to load the next stage, be it Linux of FreeBSD.
the boot process involves several pieces, some of them being proprietary and released as firmware/binary blob only.
From a very high level view, the boot process is:
- A53 ROM code (Primary Boot Loader) starts execution, and loads Secondary Boot Loader (SBL) from eMMC sbl1 partition
- A53 runs SBL, which initializes a bunch of ‘things’, DDR
- A53 loads the Application Bootloader (APPSBL) from the ‘aboot’ partition on the eMMC
- A53 starts execution of APPSBL
- A53 runs APPSBL whose job is to load the kernel image, and starts kernel.
Currently, the APPSBL included in both Linux and Android release is Little Kernel (https://developer.qualcomm.com/download/little-kernel-boot-loader-overview.pdf). It is open source. and it is the first open source component in the boot chain. We haven’t provided the complete instructions on how to rebuild it, but I am planning to have that documented soon.
Please note that APPSBL currently runs in 32-bit mode, and the switch to 64 bit is done when/if the kernel image to be loaded is built for aarch64.
APPSBL could be replaced by u-boot, assuming someone adds supports for it in u-boot, which isn’t the case today.
The current APPSBL expects a specific ‘boot’ image in the ‘boot’ partition on the eMMC. You can create your own boot image using https://github.com/96boards/documentation/wiki/Dragonboard-410c-Boot-Image.
There is no support for UEFI at the moment, unfortunetaly.
If you want to add distro support with the current APPSBL, it’s possible, but you have to teach the distro about the custom boot image format… it’s possible to generate the boot.img from the target and write it to the ‘boot’ partition…
Hi ndec, thanks for the good info. Does the boot image receive control at EL2?
(unfortunately) no. the SBL image obviously runs at EL3, but the APPSBL runs at EL1.
Thanks for those information about the whole boot process.
Do you know where I can access/download the source code of SBL?
I made some google works but failed to find one though. (only some SBL intros in qualcomm platform)
I doubt you’ll get SBL sources (and binaries have to be signed anyway).
You can boot your kernel either with Little Kernel (appsbl), or with U-Boot (that I work on) chain-loaded from Little Kernel.
Little Kernel is probably first open source component on Dragonboard.
the last reply from Mateusz is correct. SBL is proprietary , and sources are not available. LK is indeed the first component in the boot chain which is open source.
Thanks for the replies.
Sounds a bad new for me
Actually, what I want to do is to try to play with db410c’s trustzone/hypervisor mode features.
Since APPSBL starts at EL1, does it mean that I have no way to access EL2 and EL3?
indeed, this is correct… it has been mentioned a few times on this forum… nothing we can do about that, without proper firmware from qcom.
Use hikey for that - at least old ones have EL2/3 unlocked
Or look for exploits for Qualcomm trusted firmware (as long as it’s legal in your country),
perhaps someone already cracked it.
Something like this (this is for older SoCs): https://www.blackhat.com/docs/us-14/materials/us-14-Rosenberg-Reflections-on-Trusting-TrustZone.pdf
But IMO it’s not worth an effort and risk if there is hikey available.
I flashed win10 IoT on my dragonboard 410c, and found that it used UEFI as the bootloader.
I can use fastboot from UEFI, but fastboot always failed and menton that all partition not fund.
I want to fallback my board to Android/Linux but now I stuck here, can you give me some help?
I have never tried the Windows image, so I cannot comment/help on that. As far as I know, nobody was able to boot Linux using the Win10 IoT UEFI bootloaders, yet. And since many bootloader components are closed source, we can’t really know for sure ourselves neither.
You should be able to re-install the board with Linux or Android by following the SD card installation (or SD card rescue) method from the documentation. If that doesn’t work, please provide details about what you have done, and where it failed.
Thank you for your great information. Does “l-loader” and “ARM Trusted Firmware” SBL belong to SBL or APPSBL?
the ARM trusted firmware would be ‘equivalent’ to the tz.mbn binary blob (e.g. the secure world firmware), not SBL.
the l-loader is a hikey specific bootloader. i am not very familiar with that, but I believe that the SoC on Hikey will initially boot in 32-bit mode, and l-loader will switch from 32 to 64 bit. then the actual bootloader (uboot, uefi, …) will come into play. So it is not equivalent to SBL.
SBL is the first bootloader that runs on the QCOM SoC after the ROM code. when it runs the DDR is not initialized yet. and SBL will take care of it. Once the DDR is ready, the SBL will load the next bootloader (APPSBL/LK) into DDR and start its execution.
SBL will also load the various other proprietary firmware (RPM for power management companion, and TZ for the secure world).
Without source code of SBL, is it possible to replace DDR with different parameters? can a CDT partition be separate from SBL1.mbn on dragaon board 410c so that we only modify and compile a cdt.xml?
i don’t know much about the DDR replacement… however please note that since the last few releases, the CDT is in its own partition. At least that should answer your second question…
We have a custom board based on the 410c DragonBoard and are planning to change the eMMC/LPDDR3 memory chip. I have the some questions about the CDT partition.
Is there a CDT partition for Android?
dragonboard410c_bootloader_emmc_linux-88.zip contains the file sbc_1.0_8016.bin and is listed in the flashall script.
dragonboard410c_bootloader_emmc_android-88.zip does not have the file sbc_1.0_8016.bin.
What would it take to have a CDT partition for Android?
Where can we find the *.xml source file that will create the sdc_1.0_8016.bin using the python cdt_generator.py script file.
It looks like the file dragonboard410c_bootloader_emmc_aosp-88.zip has the file sbc_1.0_8016.bin already and this is part of the eMMC partitions. So my questions #1 and #2 are already answered.
I am still looking for the *.xml source file that will generate the sbc_1.0_8016.bin file.
trying to answers all questions:
in the early builds for DB410c, the CDT was ‘embedded’ into the SBL. That’s why there was no CDT partition. Sometimes last year QCOM released a new SBL where CDT is not embedded, and can be flashed into separate partition. But there was no new QCOM Android release since that. So as far as i know, there is no android release with ‘external’ cdt partition yet.
a new SBL release that reads CDT from partition. I believe. but bare in minds that this is just guess , since we don’t have SBL source code!
I don’t know. we got CDT in binary form from QCOM firmware release.
the AOSP bootloader package is identical to the Linux bootloader package (e.g. same SBL, cdt, …) the only difference is the GPT which has all the needed partition to run AOSP. But this bootloader package was not tested with the Qualcomm Android builds.