cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
chrisjrh
Observer
Observer
3,510 Views
Registered: ‎06-05-2017

Reading Value of csu_multi_boot in U-Boot on Zynq UltraScale+ MPSoC

Hi,

 

I have two partitions in QSPI flash which hold boot binaries and I wish to know which one the board has booted from by reading the csu_multi_boot address and appending to bootargs. I have written the code to do this in U-Boot, however I get an "Synchronous Abort" handler, esr... error which I am confident is because U-Boot is running in exception level 2 and does not have the permissions to read from the CSU registers. I have thought of the following solutions:

 

Run U-Boot in EL3

I have tried setting the exception level to 3 for u-boot in the boot.bif however the boot process stops at the end of the ATF execution. From what I understand this is because the Arm Trusted Firmware BL31 is looking for something at EL2 to handoff to and I instead need a modified BL2 which will boot the EL3 payload, specified by the EL3_PAYLOAD_BASE compilation flag. It doesn't look like the zynqmp Makefile inside the ATF is setup for this - has anyone managed to get U-Boot running in EL3?

 

Read the CSU Register in the ATF

I can successfully read the csu_multi_boot register from within the ATF, how could I pass this into U-Boot?

 

Write an interface and get U-Boot or the kernel to call the function compiled within the ATF which does the read of the csu_multi_boot address? I crowbarred a read of csu_multi_boot address and printf into one of the Power State Coordination Interface functions inside the ATF which gets successfully called by linux repeatedly whilst the OS is running.

 

Read the value during the execution of the ATF and write the value to a section of RAM which U-Boot can read back out (if the RAM is setup at the point the ATF runs)?

 

Within https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/xilinx-zynqmp.md it mentions the "PMU_GLOBAL.GLOBAL_GEN_STORAGE6 register" which is free to be used by other software once the ATF is bringing up further firmware images. Can I safely write the value to this register within the ATF and then read it back out in U-Boot guaranteeing it hasn't changed?

 

Any ideas would be greatly appreciated!

 

Thanks

0 Kudos
1 Reply
chrisjrh
Observer
Observer
3,481 Views
Registered: ‎06-05-2017

From reading UG1137 (https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf) it looks like I should be able to implement an SMC call utilising the EEMI API (https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf), specifically the mmio_read function.

 

This is already in the kernel as the pm platform driver:

   include/linux/soc/xilinx/zynqmp/pm.h

   drivers/soc/xilinx/zynqmp/pm.c

and in U-Boot - https://patchwork.ozlabs.org/patch/768614/

 

 

When I execute from linux:

echo mmio_read 0xFFCA0010 > /sys/kernel/debug/zynqmp_pm/power

I get the EEMI_NO_ACCESS error code with 

-bash: echo: write error: Permission denied

 Reading another register such as BOOT_MODE_USER works fine.

 

In my boot.bif the pmufw line is as follows

[pmufw_image, exception_level=el-3, trustzone] <path/pmufw.elf>

Is this all that is needed to get the pmufw running in EL3? I guess my problem at this stage is that the pmufw isn't running in EL3 and therefore can't access the csu memory?

0 Kudos