DRA821U: Having Problem Booting U-Boot Using SDK 9.02

We also tried booting U-Boot from SDK 9.02 on the devkit via UART as well, and that has also failed. It’s hanging on the u-boot.img with this one as well.

The build makes the below images for both u-boot.img and tispl.bin. We are using tiboot3-j7200-gp-evm.bin for the tiboot3.bin from the u-boot_build/r5 folder. There does not seem to be an image-gen folder anymore, so we believe that to be the right image (along with the fact that we are able to get past that binary on bootup). We have tried both the unsigned and signed versions, and both have failed to boot properly.

We are starting with the MCU UART for the first file and using the MAIN UART0 for the other two already. The failure we are seeing for the devkit is shown below. The first two images are what happens with the unsigned images. The unsigned did the transfer incomplete and went into U-Boot when it failed to boot and asked for a reset. The third image is the failure when the signed version is attempted on our devkit. The signed version hung and did not download u-boot at all.

Hi Lewis,

Couple of questions:

• Is this a regression from a previously working version of SDK? If yes which SDK version is working for you?
• Have you check the same on EVM?

- Keerthy

Is this a regression from a previously working version of SDK? If yes which SDK version is working for you?

• Yes, we are currently using SDK 8.02. We tried moving to SDK 8.04 before, but we were unable to move forward on our custom hardware.

Have you check the same on EVM?

• Yes, we did. We tried building an image for the EVM and boot it via UART and that failed. I put more information about our attempts on the EVM above.

Hi Lewis,

So on the EVM you tried with MCU_UART…or Wkup-uart?

Just wanted to check on what exact uart instance failed before i start reproducing the issue. 

Thanks, 

Keerthy 

Keerthy,

I built the EVM U-Boot images today using the instructions located here:

https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j7200/09_02_00_04/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html

The images I built loaded and ran successfully (WKUP_UART for the R5, MAIN_UART0 for A53). Lewis would like to load both the R5 and A53 images through WKUP_UART on his custom board (he doesn't have access to MAIN_UART0). But I would like to confirm that he can at least do the out of box experience on WKUP_UART and MAIN_UART0 with the EVM first.

Once this is working, I think the next step is to try and boot with WKUP_UART only on the EVM. Only once this is verified to work should we move on to the custom board. I don't want to be debugging multiple potential issues at once, best to divide and conquer.

Thanks,

Stuart

Stuart,

Thanks for the detailed summary. 

Stuart Baker said:

images I built loaded and ran successfully (WKUP_UART for the R5, MAIN_UART0 for A53

If I understood this correctly then I'm evm side there is no issue? 

Stuart Baker said:

this is working, I think the next step is to try and boot with WKUP_UART only on the EVM.

Agreed. Let's get the confirmation on this. 

Best Regards,

Keerthy 

Keerthy,

We were able to build an image for the EVM and successfully boot the image onto the EVM. We used both WKUP_UART and MAIN_UART to boot on the EVM. We used the same build environment we are using for our custom hardware, so our build environment is not the problem. Like Stuart said, our next steps will be trying to boot with WKUP_UART only on the EVM.

Keerthy,

I'm providing an update on our progress

We tried two builds on the EVM today. The first build we tried was an image using our built ATF and OPTEE images for our custom hardware (no changes to the device tree, ATF, or OPTEE). This first build is still using both WKUP_UART and MAIN_UART. The build fails at u-boot.img. We get the following printout below:

Do you know what could be causing this?

ATF cross compiler: gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu

optee cross compilers: gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf, gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu

For the second build, we tried to boot the EVM using WKUP_UART only. This build fails at tispl.bin. This issue is also a timeout on pathname error.

Do you have any insight on what might be causing this timeout error when using WKUP_UART only?

Adding an update: we made a build without using our built OPTEE for the EVM. We used the default OPTEE build for the EVM with a rebuilt ATF. This build is still using both WKUP_UART and MAIN_UART for UART. We can boot this build of u-boot onto the EVM. It seems we are having a problem building OPTEE. Do you know what could be causing failures in OPTEE?

We did try this same build (rebuilt ATF and default OPTEE) with only WKUP_UART. This build failed at tispl.bin again.

Hi Lewis,

Can you bypass OPTEE and check with Judy ATF?

You can build ATF without opteed parameter and bypass OPTEE altogether.

- Keerthy 

Hi Keerthy,

We can try bypassing OPTEE for now since our current design of our custom hardware contains a pre-released DRA821. But for Rev 2 of our custom hardware boards, it will contain HS part DRA821U4T5BALMRQ1. We will still need support in building OPTEE for SDK 9.02.

Hi Lewis,

The default OPTEE Image assumes the console MAIN_UART0. Since you are using WKUP_UART It can crash!

https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j7200/09_02_00_04/exports/docs/linux/Foundational_Components_OPTEE.html

You need to download the repo for OPTEE and compile the OPTEE Image aka bl32.bin.

Keerthy,

We did that change already for OPTEE. We also changed the speed like we needed to do with ATF.

We tried a couple more builds today on the EVM with WKUP_UART only. These builds today have WKUP_UART only with the 48000000Hz clock defined. One is nooptee, where we are not rebuilding optee and excluding the optee option in the ATF. The second one builds and uses both ATF and OPTEE. Both of our builds are getting a timeout error at tispl_unsigned.bin. It looks like it's not even trying to transfer tispl.bin. Do you have any ideas on why it’s crashing at tispl.bin?

Lewis,

Share the changes in as a patch and atach here. I will review and get back.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1109996/faq-tda4vm-how-to-boot-using-wkup-uart

I believe you have followed the above FAQ.

Best Regards,

Keerthy 

Keerthy,

Looking at the link you shared, we do not have the PDK_install_Path directory in our build. We are using the J7200 Linux SDK 9.02.

Attached is a zip file of all the files we modified in the SDK to try and get WKUP_UART boot to work. Let me know if you see anything that we might be doing wrong. Thanks for your help.

edits.zip

Hi Lewis,

I should have been more specific. In the link that i shared above please look at the section for SPL:

Modifications needed for SPL based boot flow:

e2e.ti.com/.../wkup_5F00_uart0_5F00_console

On 8.2 SDK the below patch enables booting with WKUP_UART as console.

Regards,

Keerthy 

Keerthy,
We have tried this patch already. Our problem seems to be with the differences in 8.02 and 9.02. We were able to boot using wkup only on 8.02 with no problems. Two of the files in that patch are irrelevent in 9.02 since one (boot.h) doesn't exist in 9.02 and the other (j721e_evm.h) has no references to the uart at all. The assistance we need is in 9.02 and making this version run on the dev kit.

We also cannot use the rebuilt ATF and OPTEE with the base build (mcu and main0 uarts), so that may be part of our issue. When we rebuild it, we get stuck transferring the u-boot.img file. We are going to need to be able to rebuild both for the newest revision on our custom board to use the HS-FS part. Even just rebuilding the ATF without the opteed option does not get past tispl.bin.

Troubleshooting these issues is taking longer than we had anticipated in our schedule. We are counting on your and the TI team's support to resolve these issues as soon as possible.

Regards,

Lewis

Keerthy,

We have a request on our end. Can you try to boot U-Boot from SDK9.02 onto the EVM using rebuild images of ATF and OPTEE? This will tell us if we are doing something wrong when building or if we have an issue on the backend of SDK9.02. Thanks!

Regards,

Lewis

Lewis,

I am currently out of office & not having access to the DRA821 board. However we ported the patch to use WKUP_UART on a different SOC.
The changes should be similar on j7200 as below:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1348834/processor-sdk-j784s4-main-uart-receiving-rx-not-working/5224657#5224657

Please try and let me know if that helps.

- Keerthy

Hello Keerthy,

We tried the patch to use WKUP_UART on DRA821 Eval board (based on above E2E post). We still were not able to get past tispl.bin.

Do you know when you will be back in the office to help test the DRA821 Eval board with SDK 9.02 rebuild images including ATF and OPTEE?

We really are counting on TI team support as this issue need resolution soon. We need to help the customers with the SDK 9.02 builds on custom DRA821 boards. We are unable to do much on software tasks until we have this resolved. And our project schedule is getting impacted.

Hi Syed,

Keerthy will be back in office middle of next week.

Can you share the full set of changes you made on the TI DRA821 EVM following the above thread? Where are you getting stuck at? Are you past the ATF and OPTEE and stuck in A72 SPL?

regards

Suman

Hi Suman,

Seeing if you have an update on your end? We are still trying to see if you were able to build ATF and OPTEE and boot U-Boot successfully on the EVM? Do you still need a full set of changes we made on our side? I provided all the files we changes in the zip folder above in the thread. Thanks.

Regards,

Lewis

Hi Lewis,

Can you make send the edits in the form of path files for me? That way I can see what edits you made more easily.

Best,
Jared

Hey Jared,

We are currently asking for TI's help to build an u-boot image for the EVM using SDK9.02 with rebuilding OPTEE and ATF and booting it via UART. We want to see if someone from y'all side can successfully build and boot u-boot while rebuilding OPTEE and ATF. On our side, we are getting to the u-boot.img and failing to boot from there whenever we make a u-boot image rebuilding OPTEE and ATF. We didn't change any files for the EVM so I have nothing to share on that end.

Regards,

Lewis

Hi Lewis,

I'm sorry, I made a typo. I meant patch files, not path files. If I have the patches, I'll be able to easily see the what work has been done and what else may need to be edited.

Best,
Jared

Jared,

For this first step, there are no patches to provide. Customer cannot get the 9.02 SDK on the EVM to successfully boot using WKUP_UART + MAIN_UART0 when the rebuild ATF and OPTEE from source. No changes to the source code whatsoever. Customer is asking if TI can reproduce these results to know if they are doing something wrong, because if this step doesn't work, none of the necessary board porting steps that follow are going to work either.

Thanks,

Stuart

Jared,

To follow-up, I have just tried to boot using ATF and OPTEE built from source using the instructions found here:

• https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j7200/09_02_00_04/exports/docs/linux/Foundational_Components_ATF.html#foundational-components-atf
• https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j7200/09_02_00_04/exports/docs/linux/Foundational_Components_OPTEE.html#foundational-components-optee

This is not successful for me. Once loadiing tispl.bin_unsigned is complete, I get:

Loaded 1018991 bytes
Loading Environment from nowhere... OK
init_env from device 7 not supported!
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b8
NOTICE:  BL31: Built : 13:56:34, Jun 11 2024
I/TC:
I/TC: OP-TEE version: 4.1.0-51-g012cdca49 (gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1)) #1 Tue Jun 11 20:42:59 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
E/TC:0 0 k3_sec_proxy_verify_thread:108 Queue is busy
E/TC:0 0 k3_sec_proxy_send:134 Thread SEC_PROXY_LOW_PRIORITY_THREAD verification failed. ret = -65523
E/TC:0 0 ti_sci_do_xfer:142 Message sending failed (-65523)
E/TC:0 0 ti_sci_init:486 Unable to communicate with control firmware (-65523)
E/TC:0 0 call_initcalls:43 Initcall __text_start + 0x0006ff40 failed
E/TC:0 0 k3_sec_proxy_verify_thread:108 Queue is busy
E/TC:0 0 k3_sec_proxy_send:134 Thread SEC_PROXY_LOW_PRIORITY_THREAD verification failed. ret = -65523
E/TC:0 0 ti_sci_do_xfer:142 Message sending failed (-65523)
E/TC:0 0 k3_sec_proxy_verify_thread:108 Queue is busy
E/TC:0 0 k3_sec_proxy_send:134 Thread SEC_PROXY_LOW_PRIORITY_THREAD verification failed. ret = -65523
E/TC:0 0 ti_sci_do_xfer:142 Message sending failed (-65523)
E/TC:0 0 k3_sec_proxy_verify_thread:108 Queue is busy
E/TC:0 0 k3_sec_proxy_send:134 Thread SEC_PROXY_LOW_PRIORITY_THREAD verification failed. ret = -65523
E/TC:0 0 ti_sci_do_xfer:142 Message sending failed (-65523)
E/TC:0 0 tee_otp_get_hw_unique_key:97 Could not get HUK
E/TC:0 0 call_initcalls:43 Initcall __text_start + 0x0006ff68 failed
I/TC: Primary CPU switching to normal world boot
PANIC in EL3.
x30            = 0x0000000070008424
x0             = 0x00000000be000000
x1             = 0x000000009e8018e4
x2             = 0x0000000000000002
x3             = 0x0000000000000700
x4             = 0x000000009e873d80
x5             = 0x000000009e873d80
x6             = 0x000000000000000f
x7             = 0x000000009e88e1c0
x8             = 0x0000000000000020
x9             = 0x000000009e8a9190
x10            = 0x0000000000000000
x11            = 0x0000000000000000
x12            = 0x0000000000000000
x13            = 0x000000009e869a14
x14            = 0x0000000000000000
x15            = 0x0000000000000000
x16            = 0x000000009e84d94c
x17            = 0x0000000000000000
x18            = 0x0000000000000000
x19            = 0x0000000000000000
x20            = 0x0000000000000000
x21            = 0x0000000000000000
x22            = 0x0000000000000000
x23            = 0x000000009e8abcb0
x24            = 0x000000009e873db0
x25            = 0x0000000000000000
x26            = 0x0000000000000000
x27            = 0x0000000000000000
x28            = 0x000000009e8001d4
x29            = 0x0000000000000064
scr_el3        = 0x0000000000000e30
sctlr_el3      = 0x0000000030cd183f
cptr_el3       = 0x0000000000000000
tcr_el3        = 0x0000000080803520
daif           = 0x00000000000003c0
mair_el3       = 0x00000000004404ff
spsr_el3       = 0x00000000600003c4
elr_el3        = 0x000000009e8001d4
ttbr0_el3      = 0x0000000070013080
esr_el3        = 0x000000005e000000
far_el3        = 0x0000000000000000
spsr_el1       = 0x0000000000000000
elr_el1        = 0x0000000000000000
spsr_abt       = 0x0000000000000000
spsr_und       = 0x0000000000000000
spsr_irq       = 0x0000000000000000
spsr_fiq       = 0x0000000000000000
sctlr_el1      = 0x0000000000c8180d
actlr_el1      = 0x0000000000000000
cpacr_el1      = 0x0000000000000000
csselr_el1     = 0x0000000000000000
sp_el1         = 0x000000009e873db0
esr_el1        = 0x0000000000000000
ttbr0_el1      = 0x000000009e8a1000
ttbr1_el1      = 0x0000000000000000
mair_el1       = 0x00000000ff00ff04
amair_el1      = 0x0000000000000000
tcr_el1        = 0x0000000180803fa0
tpidr_el1      = 0x0000000000000000
tpidr_el0      = 0x0000000000000000
tpidrro_el0    = 0x0000000000000000
par_el1        = 0xff0000009fc00b80
mpidr_el1      = 0x0000000080000000
afsr0_el1      = 0x0000000000000000
afsr1_el1      = 0x0000000000000000
contextidr_el1 = 0x0000000000000000
vbar_el1       = 0x000000009e803000
cntp_ctl_el0   = 0x0000000000000000
cntp_cval_el0  = 0x0000000000000000
cntv_ctl_el0   = 0x0000000000000000
cntv_cval_el0  = 0x0000000000000000
cntkctl_el1    = 0x0000000000000000
sp_el0         = 0x000000009e8abcb0
isr_el1        = 0x0000000000000100
dacr32_el2     = 0x0000000000000000
ifsr32_el2     = 0x0000000000000000
cpuectlr_el1   = 0x0000001b00000040
cpumerrsr_el1  = 0x0000000000000000
l2merrsr_el1   = 0x0000000000000000

Thanks,

Stuart

Hi Stuart,

I see the same log as you when rebuilding OPTEE and loading tispl.bin and tispl.bin_unsigned.

I did not see the issue when I only rebuilt ATF, so the issue is isolated to OPTEE. Additionally, I was unable to build OPTEE using the oe toolchain and had to use the ARM toolchains.

The only difference I see between the OPTEE versions is the toolchain used to compile them.

Working OPTEE version: 4.1.0-51-g012cdca49 (gcc version 11.4.0 (GCC)) #1 Tue Jan 30 10:48:03 UTC 2024 aarch64
Broken OPTEE version: 4.1.0-51-g012cdca49 (gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1)) #1 Thu Jun 13 04:43:56 UTC 2024 aarch64

Best,
Jared

Hey Jared,

We are seeing the same thing with the oe toolchain. Is there a fix for the built in oe toolchain? We are unable to get the version of GCC that was suggested in our setup. We did try the older versions of SDK9 and still got the same error on the oe toolchain. Since the SRM toolchain does not boot the oe toolchain is necessary to work and be linked correctly. 

Regards,

Lewis

Lewis,

Can we get the OPTEE out of our way for now? Build ATF using below command:

make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=generic

Build ATF using the above command & it will directly load A72 SPL directly after ATF.

Let us get to U-Boot without OPTEE. Then we can figure out the delta in OPTEE.

Is that okay?

- Keerthy

Hey Keerthy,

We are able to build images with SDK9.02 with OPTEE disabled and boot U-Boot successfully on both the EVM and our custom hardware. However, OPTEE does not link correctly when enabled with ATF. Our custom hardware is moving to the HS-FS DRA821, where from our understanding, we need OPTEE enable to boot. We still need TI’s support on getting a U-Boot image on SDK9.02 with OPTEE and ATF enabled.

Regards,

Lewis

Hi Lewis,

What toolchain were you using to build OPTEE on 8.02?

Best,
Jared

Hey Jared,

For SDK 8.02, we weren’t rebuilding OPTEE at all, only ATF. For Rev2 of our custom hardware, we are using an HS-FS DRA821U.

Regards,

Lewis

Hi Lewis,

Lewis Holley said:

Our custom hardware is moving to the HS-FS DRA821, where from our understanding, we need OPTEE enable to boot.

The OPTEE-OS is the component running in the Secure Layer of the A72 core providing support for Secure Applications. This is agnostic of the SoC device type - GP or HS-FS or HS-SE. You don't need OPTEE unless you have usecases exercising this.

QNX for example is a HLOS but does not use OPTEE at all.

regards

Suman