OPTEE Core data-abort problem.

[Macdog]

We recently udated from OpenSTLinux v2.1 to v4.1. The boot chain is solid, but occasionally we are getting TEE aborts (trace listed below). I am not sure exactly how to debug this, any help would be appreciated.

E/TC:1

E/TC:1  Core data-abort at address 0x2fff8805 (translation fault)

E/TC:1   fsr 0x00000207 ttbr0 0x2ffd8020 ttbr1 0x00000000 cidr 0x0

E/TC:1   cpu #1         cpsr 0x000001f3

E/TC:1   r0 0x2fff8805     r4 0x2ffda889   r8 0x2ffda889  r12 0xffffffe0

E/TC:1   r1 0x2ffcda91     r5 0x000000f7   r9 0x00000000   sp 0x2ffda788

E/TC:1   r2 0x2fff8805     r6 0x00000000  r10 0x2fff8805   lr 0x2ffcb297

E/TC:1   r3 0x2fff8806     r7 0x2ffda870  r11 0xffffffff   pc 0x2ffcac80

E/TC:1  TEE load address @ 0x2ffc0000

E/TC:1  Panic 'abort outside thread context' at ?:0

[Kevin HUBER]

Hello @Community member​ ,

please can you share the complete boot log?

Best Regards,

Kevin

[Macdog]

Thanks, Kevin, for responding!

Some more context: we are building our own distribution using buildroot. On top of that we are running Nerves (Erlang BEAM / Elixir main application). The exception reliable presents when we do a firmware update through our web interface (Phoenix/Cowboy server). The firmware file uploads successfully (written to a read/write partition formatted as F2FS), and aborts when attempting to overwrite the GPT partition table. The partition table overwrite is how Nerves manages firmware A/B with fallback.

Attached is the boot log up to and including the abort.

[Macdog · Accepted solution]

Just in case anyone is interested, our problem was a simple device tree oversight. We had neglected to inlude the reserved memory for optee in our kernel device tree when updating from TF-A boot chain to OP-TEE boot chain:

```

        optee@de000000 {

            reg = <0xde000000 0x2000000>;

            no-map;

        };

```