DB820c Bootloader - LK or EDK2?

I downloaded Official Linux BSP from QTI, it seems that DB820c uses UEFI/EDK2 as bootloader (pretty similar to QCOM Windows platform and 835+ devices). Meanwhile there’s a branch for 8996 in LK’s repository too.

So which of these two will be the final open-sourced version bootloader? It will be nice to see if there’s an official EDK2 variant bootloader for additional flexibility (I made myself one for DB410c, integrated with LK for SEC phase).

hey,

the Linaro releases are using the LK bootloader. Can you please point us to where you have seen references to UEFI/EDK2, I would be curious to investigate.

thanks

https://developer.qualcomm.com/download/db820c/linux-board-support-package-r01700.1.zip

“XBL.elf” and “XBL.sd.elf” are actually UEFI/EDK2 images (First goes QCOM SEC Phase code, then LZMA-compressed FD, viewable via UEFITool or other tools). DXE modules and configuration files are pretty similar to QCOM Windows Platform devices.

you seem to be right… and I didn’t know about that… to be honest, that even looks interesting :wink:

we will have to dig a bit into it…

from the time being, i stick to what I said earlier… the only boot chain we support is ROM code → XBL → LK.

nico

Yup. Received my board today, performed some experiments. XBL have three segments, in current boot workflow only first two are utilized (identical to SBL1 on DB410c). The third part is UEFI itself, but if “aboot” partition (aka. LK) presents, XBL segment 1 loads and jumps to it.

I removed “aboot” on purpose to see what happened:

....
D -     14091 - RPM Image Loaded, Delta - (223900 Bytes)
B -    695613 - Image Load, Start
D -      3202 - STI Image Loaded, Delta - (0 Bytes)
B -    701774 - Image Load, Start
D -     55327 - APPSBL Image Loaded, Delta - (983040 Bytes)
B -    757193 - SBL1, End
D -    674477 - SBL1, Delta
S - Flash Throughput, 74000 KB/s  (3193332 Bytes,  42630 us)
S - DDR Frequency, 1017 MHz


UEFI Start : 910 mS
PROD Mode  : Off
DEBUG Mode : On
Invalid memory configuration, check memory partition table
ASSERT /local/mnt/workspace/CRMBuilds/BOOT.XF.1.0-00301-M8996LZB-1_20160715_044814/b/boot_images/QcomPkg/XBLCore/Sec.c(598): Status == 0

Not really usable yet, it hangs at SEC phase (likely what I expected to see, because the platform configuration in the UEFI image looks like a modified variant from Windows Phone). The conclusion is SD820’s XBL recognizes either AArch32 and AArch64 APPSBL images (not like SD410). It’s interesting, and I can start my experiment porting a EDK2/UEFI to DB820c :slight_smile:

btw, perhaps this is interesting:

https://source.codeaurora.org/quic/la/abl/tianocore/edk2/

there are 8x96 related tags (I’m just trying to figure out which branch to use atm)

This is literally the EDK2 Qualcomm uses though “QcomPkg” is missing.

QcomModulePkg contains a Linux loader application used on recent Android phones (AFAIK, Pixel 2, etc.)

ok… maybe QcomPkg exists on one of the other branches in that tree? idk, I’m not really an expert about edk2 (although I have done some work on u-boot’s minimal UEFI implementation to get GOP+grub working on db410c… but a proper UEFI implementation would be much nicer ;-))

I saw your blog posts about edk2 on db410c. How were you doing that? chainloading? I guess it would be nice if we could replace xbl on the db820c, but I’m not sure if it needs to be signed.

Yes. Chainloading. XBL/SBL1 cannot be completely replaced, but we can have a stub APPSBL that simply loads UEFI and jumps (performs a SCM call). In my implementation, LK still runs low-level initialization (e.g. display, etc) and then move to UEFI. It is possible to bundle them together in one binary.

I have some other branches of “QcomPkg”, due to license requirements I cannot disclosure them. The DB410c implementation will be open once I finished code cleanup.

fwiw, I have a lk branch with hdmi supported (basically linaro’s lk with adv75xx patches ported from other branches)… with the u-boot + efi setup, lk would enable the display, and use simple-framebuffer dt bindings to pass the scanout address / resolution to u-boot (which would implement EFI GOP).

it is a bit limited since the adv75xx code doesn’t probe EDID to figure out what resolution to use.

btw, what is implemented by QcomPkg?

QcomPkg contains two parts, one is target-independent library and drivers (for example, Qualcomm utilities, high-level device drivers like GPIO/I2C/SPI/SPMI, MDP display drivers, PMIC abstraction), the other is target-dependent library and drivers like buttons, PMIC chipset drivers and SoC-specific feature drivers.

Dragonboard 410c uses ADV7533, while Dragonboard 820c has HDMI natively. (Yes, I used your LK variant for bootstrapping, though I changed pixel packing format in mdp5.c to comfort UEFI BGRA FB requirement), and it boots Windows. So for Dragonboard 820c, I simply enabled these switches in build:

DEFINES += ENABLE_DISPLAY=1
DEFINES += DISPLAY_SPLASH_SCREEN=1
DEFINES += DISPLAY_HDMI_PRIMARY=1
DEFINES += DISPLAY_TYPE_MIPI=1
DEFINES += DISPLAY_TYPE_DSI6G=1

And the HDMI works natively (information retrieved from EDID). I manually changed BPP information to 32bit and added BGRA pixel format definition (as you did in LK) manually. (See https://github.com/imbushuo/lk, branch UEFI.BootStrapper.1.0.0.8996.0)

I decided not to use aboot to bootstrap anymore because I want to keep FV bootstrapping simple. So I am going to add an app/fvbootstrapper that builds HOBs UEFI requires and loads UEFI FD in a few more days.