[meta-xilinx] zynqmp support in warrior branch

[Mike Looijmans]

In 'warrior', the ATF loading was changed in u-boot and now uses a FIT image 
for uboot+atf. The hack that loads ATF as 'kernel' and u-boot as its 
devicetree is no longer working properly there.

I got this working for the miami MPSoC module using this recipe:
https://github.com/topic-embedded-products/meta-topic/blob/warrior-next/recipes-bsp/u-boot/u-boot-xlnx_2019.1.bbappend

It's the "mkimage" command that's key here.


As for the PMU, I just build a 'patched' version once using a separate build 
environment so I don't have to mess around with multiconfig. The binary it 
produces is the same for all boards and configurations anyway (there's one 
Xilinx evaluation board that's an exception to that though), so just 
considering it a firmware 'blob' works well enough. So unless you have a board 
where the PMU needs to so something, you can just use the meta-topic pre-built 
binary pmu firmware for any zynqmp board, since it contains a sort of "yes to 
all" patch that allows all peripherals (including second SD and both SPI 
ports) to work.



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
Postbus 440, 5680 AK Best
The Netherlands

T: +31 (0) 499 33 69 69
E: {E-mail
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 23-10-19 13:32, Adrian Fiergolski wrote:
> Hi,
> 
> I am experiencing issue booting a custom board based on ZynqMP+ device. The 
> boot process stops at ATF:
> 
> U-Boot SPL 2019.01 (Oct 23 2019 - 10:34:53 +0000)
> EL Level:       EL3
> Trying to boot from MMC2
> NOTICE:  ATF running on XCZU6EG/silicon v4/RTL5.1 at 0xfffea000
> NOTICE:  BL31: Secure code at 0x0
> NOTICE:  BL31: Non secure code at 0x8000000
> NOTICE:  BL31: v2.0(release):xilinx-v2019.1
> NOTICE:  BL31: Built : 15:12:20, Oct 22 2019
> 
> I checked with debugger and apparently, ATF fails to launch u-boot image.
> 
> As mu setup, what is reflected properly in the device-tree, uses 2 SD 
> controllers, just as a precaution, I applied two patches on PMU (link 
> <https://github.com/topic-embedded-products/meta-topic/tree/master/recipes-bsp/pmu-firmware/pmu-firmware>), 
> including the one enabling NODE_SD0 for the cores.
> 
> Has anybody experienced a similar issue? Can somebody confirm a successful run 
> of ZynqMP+ based platform with warrior branch?