S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash access Environment: S32N55, FSS FW 1.19.0 (D2604), GrayVIP 1.0.25, HSE2, Secure Boot enabled. Goal: Implement A/B swap OTA. Active bank A at AHB 0x10000000, passive bank B at 0x14000000 (flash offset 0x04000000). I am trying to have the running FSS (active bank A) install the passive bank’s PaCo/Codef/SMR, then swap the IVT and reboot into bank B. What I found: The running FSS cannot read the passive bank at 0x14000000. With T32 (XSPI configured for a 4-byte read, cmd 0x13) the data at 0x14000000 reads correctly, but at runtime the FSS/QSPI uses an OPI read that appears to be 3-byte addressing (~16MB reach), so any access to 0x14xxxxxx bus-faults. Bank A works because all of its used data is within the low 16MB. Forcing a runtime asset re-install hard-faults/resets the board. When I bypass the “SYS-IMAGE already loaded” gate in the FSS asset-install functions (InstallPaCo / InstallSMRs / InstallCodefs / AuthenProcess) to re-run the install at runtime, the board resets — even when I target the active (readable) bank. This suggests asset install is not intended to run while the cohorts (CRS/RTU) are already executing. Questions: Is FSS asset install (PaCo/Codef/SMR via HSE) supported only during the boot/provisioning phase (before cohorts are released), and not at runtime while CRS/RTU are running? For A/B swap OTA, what is the intended activation sequence? After writing the passive bank and swapping the IVT, when and how are the passive bank’s Codef (whose image source addresses are bank-dependent), SMRs, and PaCo installed/verified? Is the running FSS expected to access the passive bank (0x14000000) at runtime (i.e., should the runtime read path use 4-byte addressing), or is the passive bank accessed only by the boot ROM at the next boot? Across an A/B swap, does the PaCo differ between banks? The PaCo contains flash-range addresses (0x10xxxxxx / 0x11xxxxxx), so does the passive bank’s PaCo require relocation like the Codef, or is it bank-independent? S32N5 Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc Hi Chenyin, thanks for the quick reply. To clarify my question: I am not relying on a built-in SCMI service. I have already implemented my own runtime PaCo/CoDef install as part of an A/B bank-swap OTA. The design is bank-agnostic: the running (active) FSS installs the passive bank’s assets at runtime, then swaps the IVT primary pointer (0x10000000 ↔ 0x14000000) and reboots into the other bank. I reuse the existing FSS install state machine directly for this. So my real question is whether this approach is feasible on the current FSS, because in testing it fails at a specific point. What works: With the install targeted at the active bank, the full path completes (PaCo/Owner/Keys, SMR install returns OK, FSS FW SMR0/AuthenProcess OK; Codef-install and ValidateBootConfig return NOT_ALLOWED under the published SYS-IMG, so I defer those to the next boot’s BootCfgVerify). BTM then proceeds to PublishSysImage + EnableGlobalSecureBoot. What fails: When the install targets the passive bank, it bus-faults in IndexSourcesStep the first time the FSS dereferences the passive-bank PaCo at AHB 0x14013000. Active-bank addresses (0x10xxxxxx) read fine. Root cause I traced: It is not the AHB window or addressing. MemAcc_Init() (which initializes Mem_43_EXFLS, MemPerformDeviceConfiguration=TRUE) runs before Fss_Firmware_InstallPacoCodefs(), so at install time SFA1D is already 0x18000000 (128 MB), AHB read is enabled, and the read LUT is 4-byte OPI-DDR. Even after I manually confirmed SFA1D = 0x18000000 via T32, 0x14013000 still returns a hard bus error (not the SFP error payload). This points to XSPI Secure Flash Protection (SFP): the FRAD covering the passive region did not grant the accessing master’s domain RW. When I extended the FRAD coverage to the full flash and set Md4Acp = RW, the access behavior changed. My questions: Is runtime install of PaCo/CoDef into the passive bank architecturally supported on the current FSS (Secure Boot enabled) by reusing the install functions as above, or are there hard blockers I should be aware of before the reference OTA is available? Any caveats for this interim approach — e.g., installing FSS FW SMR0 (AuthenProcess) for the target bank, and deferring the CoDef/boot-config check to the next boot’s BootCfgVerify? Thanks, Eddie Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc Hello, @EddiePark
Thanks for the post and glad to support again.
The current FSS does not provide an SCMI service for installing PaCo and CoDef at runtime.
Currently, the reference OTA implementation of S32N is still under development, if possible, I suggest referencing it directly to implement your own OTA process once it is available.
BR
Chenyin Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc Hi, following up with much more detail after systematic debugging. Setup: S32N55, FSS FW 1.19.0, Secure Boot. A/B bank-swap OTA. The running FSS (M7) installs the passive bank’s PaCo/CoDef at runtime (our own implementation, reusing the FSS install state machine). Passive bank base = 0x14000000. Fault: In Fss_Firmware_IndexSourcesStep, the FSS-M7 does a direct AHB memory-mapped read (CPU dereference) of the passive-bank PaCo at 0x14013000 and takes a precise BusFault: CFSR = 0x00008200 → BFSR: PRECISERR=1, BFARVALID=1, MMFSR=0 BFAR = 0x14013000 What we ruled out (with evidence): MPU: not the cause. MMFSR=0. MPU region 2 = External Flash 0x10000000–0x1FFFFFFF, Normal cacheable WB, Read-Only → covers 0x14013000, read permitted. SFP: not the cause. Setting MemXspiSfpEnable = FALSE and rebuilding → same fault. (FRADs grant the region to the relevant domains anyway.) AHB window: SFA1D = 0x18000000 (128 MB) → bank B is inside the window. Key observation — it’s not bank-specific, it’s “fresh vs cached”: The read/fault boundary is exactly 0x13780000 (0x1377FFFF reads, 0x13780000 faults). That is the end of the firmware image region (FSS/CRS/HSE/RTU/Sys_Img) / start of the data region (IDS…). It is 56 MB from base — not a power of two, so it is not a hardware size boundary; it is exactly the extent the FSS read and cached during boot (External Flash region is cacheable). → Everything the FSS read during boot (now in D-cache) reads back fine. Any address requiring a FRESH (uncached) direct AHB read faults — including addresses below 0x14000000 (e.g. 0x13780000 is in the active 64 MB and also faults). So the real issue is: fresh, uncached, direct AHB memory-mapped reads of external flash fail at runtime. MemPerformDeviceConfiguration test: MemPerformDeviceConfiguration = TRUE (device init runs → octal-DDR): flash writes work (indirect/IP-command via MemAcc INDIRECT_STATIC), cached reads work, fresh AHB reads FAULT. MemPerformDeviceConfiguration = FALSE (skip device init): reads return all 0x00 (device not left in octal-DDR mode). So with the device correctly in octal-DDR, writes succeed but fresh memory-mapped READS fault. Since octal-DDR external-DQS reads are sampled using the device DQS strobe and writes are not, this points to a read-path (DQS/DLL/dummy/timing) problem. Config context: Only the FSS configures the XSPI controller (Xspi_Ip_paXspiUnitCfg, MemPerformDeviceConfiguration = TRUE, octal-DDR, external DQS, DLL bypassed). CRS and RTU skip controller configuration (XspiUnit = NULL, DeviceConfiguration = FALSE) and inherit the boot config. The qspi param (xspi_S28H_octal_ddr_200Mhz_dll_bypass_ext_dqs.bin) is included in the generated VIP/IVT blob. Questions: On the current FSS, is the FSS-M7 expected to be able to perform direct AHB memory-mapped reads of external XSPI flash at runtime (after MemAcc_Init) at arbitrary/uncached addresses? Or must runtime flash reads go through the indirect (IP-command) Mem/MemAcc path? Why would a direct AHB read return a precise BusFault for uncached addresses while writes (indirect) and cached reads succeed, given SFA1D=128 MB, SFP disabled, and MPU RO covering the region? Does the FSS’s MemAcc_Init controller re-configuration conflict with the boot qspi-param XSPI read setup such that memory-mapped reads break? Should the FSS skip controller reconfiguration (like CRS/RTU) and inherit the boot qspi-param config — and if so, how do we retain flash write support? For octal-DDR / external-DQS / DLL-bypass at 200 MHz on S28HS01GT, what DLL / DQS / dummy-cycle settings are required for reliable memory-mapped reads? (We suspect our FSS read config differs from the working boot qspi-param config.) Thanks, Eddie Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc Hello, @EddiePark
Sorry for the late response due on leave.
May I know if you had the following settings modified? Access Control Policy for TG0 → change all instances to XSPI_IP_SFP_ACP_RW, then test if the issue still persist when accessing the flash address via FSS.
BR
Chenyin Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc Hi Chenyin, No problem at all — thanks for getting back to me. Yes, we have implemented the related functionality, and the passive-bank access via FSS is working. The PaCo and SMR installs for the passive bank (bank B) complete successfully at runtime: PaCo: HSE returns HSE_SRV_RSP_ALREADY_DONE (0xDADAEAEA) and we treat it as success. SMR: installs correctly with the bank-B source address (0x14280000), ret=0. Our remaining question is specifically about Codef installation at runtime: When Secure Boot is enabled and the SYS-IMAGE has been published, a runtime Sherpa_Cdd_InstallCodef call (issued from FSS, triggered via RTU3 SCMI during normal operation) returns HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21C) for every cohort. We confirmed this with logging (instRet=1 on all cohorts). Our understanding is that, under Secure Boot ON, the published SYS-IMAGE seals the Codef, so a runtime Codef install is not permitted — and the Codef CHECK-IN must instead be deferred to the next boot’s hseBootCfgVerifySrv_t stage (after the IVT swap). SMRs, by contrast, are allowed at runtime. Could you please confirm whether this is the expected/by-design behavior? That is: Is runtime Codef install (via FSS/SCMI) expected to return NOT_ALLOWED once Secure Boot is enabled and SYS-IMAGE is published? Is deferring the Codef CHECK-IN to the next boot verify (hseBootCfgVerifySrv_t) the correct/intended approach for the A/B swap passive-bank update? Regarding the Access Control Policy setting (TG0 → XSPI_IP_SFP_ACP_RW): we will check our current configuration and test the flash access as you suggested, and report back. Thank you, Eddie Park
記事全体を表示
