U-Boot doesn't run when T2080 secure boot enabled

[VNF]

We are using the T2080 with secure boot bit enabled in the RCW. We’ve been successful in running uni_sign to sign U-Boot and other ESBCs to generate the CSF header file and boot the T2080. We have been customizing U-Boot for some time and have not had any problems with booting until now.

I recently made a small change to our U-Boot code, added two parameters to a function which is near the end of U-Boot execution. Now U-Boot appears not to start or it hangs (no output text gets displayed). I checked the security monitor state using a Lauterbach JTAG debugger (our CodeWarrior license expired). The SSM_ST value was 0xd and the SCRATCHRW2 register value is 0x0 so it appears the T2080 ISBC is booting into the Trusted state and U-Boot should have started, but there is no output. The interesting thing is that U-Boot executes fine when secure boot bit is disabled.

When I load the debug symbols in the Lauterbach debugger, reset the CPU, then hit Go, the execution gets stuck in a data TLB error handler. I compared the LAWs and TLBs between the good and bad U-Boot early in the execution and they look the same.

Another interesting thing, if I put several breakpoints in the code where it is executing out of NOR flash then execution gets to the relocation to RAM. Then I can hit Go and U-Boot continues to run.

Also, when I single step the Lauterbach it seems to execute some instructions at addresses that are not even part of the code.  I wonder if Lauterbach cannot debug properly when in secure boot mode.

Any help is appreciated.

Thanks,

VNF

[ufedor]

This is an update to your question/request:

Secure Boot does not affect normal process, except PAMU cannot be in bypass mode.

From the Trust Architecture User Guide 2.0,

#####

3.1.2.1 PAMUs

The core's MMU settings determine which memory ranges are accessible by each

domain, and the hypervisor prevents these settings from being altered by operating

system or application software.

In order to prevent system masters other than the cores from reading or writing sensitive

memory regions, the chip implements a number of I/O MMUs, known as peripheral

access management units or PAMUs. The PAMUs prevent internal and external DMAs

(non-CPU masters) from accessing memory for which they have not been granted explicit

access permission.

#####

Which exactly modification was done? Is it possible that transaction for the target peripheral is blocked by PAMU?

Please check whether there is PAMU error. You can configure the PAMU interrupt to list out the PAMU status registers in case of access violation.

Make sure that there are enough entries for both primary and secondary tables. In U-Boot, primary and secondary tables are defined with static sizes which are defined in fsl_pamu.h file as:

#define NUM_PPAACT_ENTRIES              512

#define NUM_SPAACT_ENTRIES              256

[VNF · Accepted solution]

Thanks for the information.  It turns out we did not have this patch in our code.

https://lists.denx.de/pipermail/u-boot/2017-March/282887.html

powerpc: e6500: Lock/unlock 1 cache instead of L1 as init_ram

For E6500 cores, L2 cache has been used as init_ram. L1 cache is a write through cache on E6500.If lines are not locked in both L1 and L2 caches, crashes are observed during secure boot. This patch locks/unlocks both L1 and L2 cache to prevent the crash.