ls1043ardb without optee?

[steven_vanden_b]

Hello,

i would like to know if it is possible to boot ls1043ardb (from sd card for now) without using optee and eufi.

I managed to compile atf without optee support.

I get this far in the booting process:

INFO: Loading image id=5 at address 0x82000000
INFO: sd-mmc read done.
INFO: Image id=5 loaded: 0x82000000 - 0x820afbc3
NOTICE: BL2: Booting BL31
INFO: Entry point address = 0xbbe00000
NOTICE: BL31: v1.5(release):devtool-patched-dirty
NOTICE: BL31: Built : 08:19:07, May 13 2020
NOTICE: Welcome to ls1043ardb BL31 Phase
INFO: ARM GICv2 driver initialized
INFO: BL31: Initializing runtime services
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x82000000
INFO: SPSR = 0x3c9

-> it seems to work untill it wants to jump to uboot, i do not see any output from the serial console after this.

What config changes do i need in uboot to boot without eufi and without optee?

i tried:

CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=n   --> i had to patch 1 file according to

[U-Boot,2/6] armv8: fsl-layerscape: fix compile error with sec fw disabled - Patchwork 
CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y

[JRRandall]

I have this exact same issue on our LS1046A-based board.  Rather than start another new thread, I was wondering if any of you remember what the solution was to this problem?  Is it an endian issued once the BL33 u-boot image is reached?  

Justin

@steven_vanden_b

@yipingwang 

@StephenLiu

@david_wachira 

[StephenLiu]

Hi,

Any update on this issue? I have exact the same problem,  can share your solution?

BR

[maxime_guillot]

Hello,

It seems I have the same problem. Did you find the reason of this issue? Can you share please?

Thank you

[david_wachira]

Did you resolve this (inability to switch to u-boot). If so, please share. I am having similar issues

[yipingwang]

Please refer to the following TF-A boot flow.

1. Boot ROM (BL1)
a. When the CPU is released from reset, hardware executes PBL commands that copy the BL2 binary (bl2.bin) for
platform initialization to OCRAM. The PBI commands also populate the BOOTLOC ptr to the location where
bl2.bin is copied.
b. Upon successful execution of the PBI commands, Boot ROM passes control to the BL2 image at EL3.
2. BL2
a. BL2 initializes the DRAM, configures TZASC
b. BL2 validates BL31, BL32, and BL33 images to the DDR memory after validating these images. BL31, BL32, and
BL33 images form FIP image, fip.bin.
c. Post validation of all the components of the FIP image, BL2 passes execution control to the EL3 runtime firmware
image named as “BL31”,
3. BL31
a. Sets up exception vector table at EL3
b. Configures security related settings (TZPC)
c. Provides services to both bootloader and operating system, such as controlling core power state and bringing
additional cores out of reset
d. [Optional] Passes execution control to Trusted OS (OP-TEE) image, BL32, if BL32 image is present.
4. BL32
a. [Optional] After initialization, BL32 returns control to BL31.
5. BL31
a. Passes execution control to bootloader U-Boot/UEFI, BL33 at EL2
6. BL33
a. Loads and starts the kernel and other firmware (if any) images.

Thanks,

Yiping

[steven_vanden_b]

I also noted that the x /100x 0x82000000 has uboot loaded but in reverse endianess of hexdump uboot-tfa.bin. I suspect this is correct, could you provide me with a hexdump -c of the uboot-tfa.bin file that is working without tfa (on the reference platform) ?

[steven_vanden_b]

in policy.h -> #define POLICY_SMMU_PAGESZ_64K 0x1

-> how do i know i have to change this?

[steven_vanden_b]

I see now that the on the moment we jump back to normal world, the debugger hangs with

[Inferior 1 (Remote target) exited with code 01]
[New Thread 1]
Remote failure reply: E01

this is the serial trace,

NOTICE:  BL2: Booting BL31
INFO:    Entry point address = 0xfbe00000
NOTICE:  BL31: v1.5(debug):devtool-patched-2-g2e512006c
NOTICE:  BL31: Built : 09:56:47, May 29 2020
NOTICE:  Welcome to otn_xtd2100 BL31 Phase
INFO:    ARM GICv2 driver initialized
INFO:    BL31: Initializing runtime services
WARNING: BL31: cortex_a53: CPU workaround for 835769 was missing!
WARNING: BL31: cortex_a53: CPU workaround for 843419 was missing!
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x82000000
INFO:    SPSR = 0x3c9

I suspect then that something in setting up the memory regions might be wrong in BL31code.

What is done for ls1043ardb in BL31 code?

[yipingwang]

Hello Steven Vanden Branden,

Which version LSDK do you use?

Please refer to the following OPTEE is not open in configs/build_lsdk.cfg in LSDK 20.04.

CONFIG_APP_OPTEE=n

Thanks,

Yiping

[steven_vanden_b]

We use the latest version.

We already put this config to n.

Is there a way to debug this issue?

[yipingwang]

Please generate SD firmware image with the following command, then deploy it at offset 0x8.

$ flex-builder -i mkfw -m ls1043ardb -b sd

[steven_vanden_b]

I am not using the ls1043ardb reference board, so i have changed the sdk with my own rcw as needed and my own ddr init in the fta bootloader. The codewarrior ddr validation works fine. I also am able to run a debug application on the platform.

Where can i find instructions on how to debug the fta boot further to find where it hangs on the switch to uboot?

[yipingwang]

Please refer to the following procedure

ATF is a simple bareboard application, so you should be able to debug it accordingly. There’s no special guide needed. Given the fact that ATF resides in flash and then copied to OCRAM, you’ll need an “attach” launch configuration. As far as I know, there are two elf files required for debugging, one for BL2 and one for BL31. Also, depending on the MMU configuration, you might need to mark some areas as read-only, in order to force HW BPs to be used from GDB. See ‘mem’ command for more details.

I brought in discussion the MMU configuration in a more general sense – so not strictly related to ATF. It’s important to know that debugger (GDB) defaults to software breakpoints by default and they will not work on read-only MMU ranges. So you can either set hardware breakpoints using GDB’s ‘hbreak’ command, either add read-only/write-only memory ranges in GDB (see ‘mem’ command) and force GDB this way to always set HW breakpoints inside those ranges.

Regarding the MMU configuration performed by ATF, I’m pretty sure it configures MMU. Moreover, I think I’ve accidentally noticed at some point the ATF marking some memory ranges as read-only – but not sure. So, please discuss this subject with someone working on ATF or inspect the ATF sources yourself. There’s also a GDB command implemented in CW-ARMv8 that allows users inspect current MMU configuration – see ‘mmu’ command and its description (use ‘help’ in Debugger Console or read ch. 6.5.6 from ARMv8 Targeting Manual).

[steven_vanden_b]

Hello i am trying to import my BL2 binary into codewarrior but he seems to fail to detect the type:

/home/test/bl2_sd.pbl

unknown executable format.

Is there a way to just connect to a gdb shell after the board has booted via the sd card? (codewarrior should not do board initialization)?

[steven_vanden_b]

i used the wrong file, i found the elf file and now i can debug, thanks.