iuliana-prodan
commented
2 months ago From the crash and after analyzing the disassembly I've realized the error is here:
acc = AE_SLAI64S(acc, 1); /* Convert to Q17.47 */
92455be4: 297582ac4402b11345f23f { ae_s32.l.i aed3, a2, -4; l32i a4, a5, 12; nop; ae_slai64s aed1, aed1, 1 }
By comparing the two disassembles from RI2023 (which is ok) and RJ2024 (which is NOK):
we can see that for RJ2024, we have a load instruction on slot1, from the four operations in parallel.
By looking in the HiFi4 User guide:
this seems to be correct.
Also, another difference is the
addi and l32i instructions - these are in both cases but in different sets of 4 operations.
At first, I checked that all the variables are aligned based on the instructions restrictions and they seem to be (if we look at the VADDR or A2, A3, etc from crash dump).
I also wrote a simple function that does a store and load (trying to reproduce the order of instructions from where the crash happens), with the exact addresses:
diff --git a/src/math/iir_df1_hifi3.c b/src/math/iir_df1_hifi3.c
index d1aa05f55..40edcbee7 100644
--- a/src/math/iir_df1_hifi3.c
+++ b/src/math/iir_df1_hifi3.c
@@ -46,6 +46,22 @@
/* 32 bit data, 32 bit coefficients and 32 bit state variables */
+uint32_t first_iteration(void)
+{
+ uint32_t *addr_r = (uint32_t *)0x92c0c220;
+ uint32_t value;
+
+ ae_int32 *addr_w = (ae_int32 *)0x92c0c200;
+ ae_int32x2 tmp = AE_ZERO32();
+
+ AE_S32_L_I (tmp, addr_w, -4);
+
+ value = *addr_r;
+
+ return value;
+}
+int cnt = 0x1;
+
int32_t iir_df1(struct iir_state_df1 *iir, int32_t x)
{
ae_int64 acc;
@@ -67,6 +83,11 @@ int32_t iir_df1(struct iir_state_df1 *iir, int32_t x)
int j;
int nseries = iir->biquads_in_series;
+ if (cnt == 0x1) {
+ first_iteration();
+ }
+ cnt++;
+
/* Bypass is set with number of biquads set to zero. */
if (!iir->biquads)
return x;With this, the disassembly looks similar to the crash - meaning is doing a store (ae_s32.l.i), next a load (l32i.n), but it passes:
92446e24 <first_iteration>:
first_iteration():
/opt/samba/nxa06898/xcc/sof/src/math/iir_df1_hifi3.c:50
{
92446e24: 004136 entry a1, 32
/opt/samba/nxa06898/xcc/sof/src/math/iir_df1_hifi3.c:55
ae_int32x2 tmp = AE_ZERO32();
92446e27: fc48c400672e { l32r a2, 92429fc4 (92c0c200 <heapmem+0x7200>); ae_movi aed0, 0 }
/opt/samba/nxa06898/xcc/sof/src/math/iir_df1_hifi3.c:57
AE_S32_L_I (tmp, addr_w, -4);
92446e2d: e002f4 ae_s32.l.i aed0, a2, -4
/opt/samba/nxa06898/xcc/sof/src/math/iir_df1_hifi3.c:59
value = *addr_r;
92446e30: 8228 l32i.n a2, a2, 32
/opt/samba/nxa06898/xcc/sof/src/math/iir_df1_hifi3.c:61
return value;
92446e32: f01d retw.n
lgirdwood
singalsu
Describe the bug Compiled SOF successfully with XCC toolchain RJ2024.3 from Cadence. When trying to run an IIR test I get a
load/store erroron DSP:In Linux I get an
Input/output error:To Reproduce Use an IIR topology and run the following commands:
Reproduction Rate With latest SOF - main branch, with XCC RJ2024.3, the error is met 100%. This was reproduced on all i.MX platforms: i.MX8MP, i.MX8QM, i.MX8QXP.
With XCC RI2023.11 everything works fine.
Expected behavior No error should appear.
Impact Not working as expected. Showstopper for IIR, if updating to latest XCC toolchain.
Environment 1) Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
Screenshots or console output
I've attached here the disassembly for OK XCC 2023 SOF and NOT OK XCC 2024 SOF. zephyr_2023_OK.dst.txt zephyr_2024_NOK.dst.txt