* AXI ID 0x5c8 on STM32MP13
@ 2024-12-05 13:40 Ahmad Fatoum
2024-12-06 10:41 ` [Linux-stm32] " Yann Gautier
0 siblings, 1 reply; 2+ messages in thread
From: Ahmad Fatoum @ 2024-12-05 13:40 UTC (permalink / raw)
To: linux-stm32, Alexandre Torgue
Cc: Pengutronix Kernel Team, Oleksij Rempel, barebox
Hello,
After a kernel update to v6.13-rc1, we have been increasingly seeing
following occasional OP-TEE (v4.2.0) panic:
E/TC:0 dump_fail_filter:425 Violation @0xce01b000, non-secure privileged read, AXI ID 5c8
E/TC:0 Panic at core/arch/arm/plat-stm32mp1/plat_tzc400.c:30 <tzc_it_handler>
E/TC:0 TEE load address @ 0xce000000
This happens at kernel boot time, when loaded by barebox. The probability that
this happens, seems to be inversely proportional to how long the system
was powered off prior to Power-on reset...
The kernel /reserved-memory entry has a no-map entry for OP-TEE, so this
looks correct.
barebox maps the OP-TEE range as uncached and with eXecute Never set.
Indeed, if we jump to the OP-TEE memory directly, we get a prefetch error
from within barebox without hitting the firewall as expected.
If the barebox MMU is disabled and we try to execute from 0xce000000, we
get an expected panic from OP-TEE:
E/TC:0 tzc_it_handler:26 TZC permission failure
E/TC:0 dump_fail_filter:420 Permission violation on filter 0
E/TC:0 dump_fail_filter:425 Violation @0xce000000, non-secure privileged read, AXI ID 4c0
E/TC:0 Panic at core/arch/arm/plat-stm32mp1/plat_tzc400.c:30 <tzc_it_handler>
E/TC:0 TEE load address @ 0xce000000
Note that this is a different AXI ID (0x4c0) than the one we see related
to the spurious read (0x5c8).
In order to further debug this, it would be useful to know which AXI master
has ID 0x5c8. The reference manual (RM0475) has Table 20. "NSAID and AXI_ID
mapping" in RM0475 but it contains no 0x5c8. 0x4c0 is expectedly the CA7
itself.
Can someone from ST please chime in with the information what AXI master
ID 0x5c8 maps to?
Thanks,
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Linux-stm32] AXI ID 0x5c8 on STM32MP13
2024-12-05 13:40 AXI ID 0x5c8 on STM32MP13 Ahmad Fatoum
@ 2024-12-06 10:41 ` Yann Gautier
0 siblings, 0 replies; 2+ messages in thread
From: Yann Gautier @ 2024-12-06 10:41 UTC (permalink / raw)
To: Ahmad Fatoum, linux-stm32, Alexandre Torgue
Cc: barebox, Oleksij Rempel, Pengutronix Kernel Team
On 12/5/24 14:40, Ahmad Fatoum wrote:
> Hello,
>
> After a kernel update to v6.13-rc1, we have been increasingly seeing
> following occasional OP-TEE (v4.2.0) panic:
>
> E/TC:0 dump_fail_filter:425 Violation @0xce01b000, non-secure privileged read, AXI ID 5c8
> E/TC:0 Panic at core/arch/arm/plat-stm32mp1/plat_tzc400.c:30 <tzc_it_handler>
> E/TC:0 TEE load address @ 0xce000000
>
> This happens at kernel boot time, when loaded by barebox. The probability that
> this happens, seems to be inversely proportional to how long the system
> was powered off prior to Power-on reset...
>
> The kernel /reserved-memory entry has a no-map entry for OP-TEE, so this
> looks correct.
>
> barebox maps the OP-TEE range as uncached and with eXecute Never set.
> Indeed, if we jump to the OP-TEE memory directly, we get a prefetch error
> from within barebox without hitting the firewall as expected.
>
> If the barebox MMU is disabled and we try to execute from 0xce000000, we
> get an expected panic from OP-TEE:
>
> E/TC:0 tzc_it_handler:26 TZC permission failure
> E/TC:0 dump_fail_filter:420 Permission violation on filter 0
> E/TC:0 dump_fail_filter:425 Violation @0xce000000, non-secure privileged read, AXI ID 4c0
> E/TC:0 Panic at core/arch/arm/plat-stm32mp1/plat_tzc400.c:30 <tzc_it_handler>
> E/TC:0 TEE load address @ 0xce000000
>
> Note that this is a different AXI ID (0x4c0) than the one we see related
> to the spurious read (0x5c8).
>
> In order to further debug this, it would be useful to know which AXI master
> has ID 0x5c8. The reference manual (RM0475) has Table 20. "NSAID and AXI_ID
> mapping" in RM0475 but it contains no 0x5c8. 0x4c0 is expectedly the CA7
> itself.
>
> Can someone from ST please chime in with the information what AXI master
> ID 0x5c8 maps to?
>
Hi Ahmad,
The table you mention gives most of the explanation but I agree this is
not completely clear.
From the table:
Master | NSAID[3:0] | ID_WIDTH | AXI_ID[10:0]
CA7 | 0b0000 | AR:6/AW:5 | 11’b10XXXXXX000
The BIT[10] (0x400) is set in 0x5c8, so it is the Cortex-A7.
Then the 0x1c8 is the ARID or AWID, that you can find in Cortex-A7 TRM.
See tables 7.4 or 7.5.
As the TZC error mentions a read error, then it will be an ARIDM.
And 0x1c8 >> 3 correspond to:
0b111mmm[b] L2 Line-Fill Buffer
b. Where mmm is L2 encoding of the Line-Fill Buffer.
And 0x4c0 is then the Cortex-A7 Processor 0 Instruction.
Best regards,
Yann
> Thanks,
> Ahmad
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-12-06 10:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-12-05 13:40 AXI ID 0x5c8 on STM32MP13 Ahmad Fatoum
2024-12-06 10:41 ` [Linux-stm32] " Yann Gautier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox