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