Other Parts Discussed in Thread: SYSCONFIG
Hello,
I am trying to fix warm reset issue of our custom board. We need to have a possibility to restart the target system from a SW application and re-run our preloader located in the parallel NOR flash memory (NOR).
The preloader successfully runs after Power On Reset (POR), the GPMC is properly configured, contents of the NOR flash can be seen at the expected memory area (0x3003E000).
The first method was trigger the warm reset (RST) by setting zero value to the 'SWRST' bit of the 'RSCTRL' register, either Hard reset as call sequence:
volatile DWORD* rsctrl = (DWORD*)RSCTRL;
*rsctrl = RSCTRL_KEY;
*rsctrl = RSCTRL_RESET;
or Soft reset:
volatile DWORD* rsctrl = (DWORD*)RSCTRL;
*rsctrl = RSCTRL_KEY;
((DWORD)RSCFG) |= 0x00003000UL;
*rsctrl = RSCTRL_KEY;
*rsctrl = RSCTRL_RESET;
where:
#define RSCTRL_OFFSET 0x000000E8UL
#define RSCTRL (PLLC_CFG_REGS + RSCTRL_OFFSET)
#define RSCTRL_KEY 0x00005A69UL
#define RSCTRL_RESET 0UL
#define RSCFG (PLLC_CFG_REGS + 0x000000ECUL)
For both Soft and Hard resets the result is the same. After the RST, the same memory area is filled by zeroes and 'GPMC_ERR_' registers are nonzero:
GPMC_ERR_ADDRESS = 0x34000000
GPMC_ERR_TYPE = 0x00000211
The 'BOOTCFG_' registers contain expected values, especially the 'BOOTCFG_DEVSTAT' corresponds to the strap pins, setting the boot mode and its parameters:
BOOTCFG_DEVSTAT = 0x00060395
It seems the processor is reset (the emulator probe was disconnected), I also verified the RESET pin of the NOR device is pulsed. When in such unstable state of the NOR access, I connected to the SoC the emulator back and invoked Board Setup (PLL setup, etc.) function in GEL from CCS, the Memory Browser momentarily shown valid data at the given address space, but then all was filled with the '0xFFFFFFFF' pattern.
According to errata 66AK2G12 'KeyStoneII.BTS_errata_advisory.46 BOOT, GPMC: GPMC XIP Boot Failure' the strap pins select 100 MHz PLL reference clock, so the GPMC uses less aggressive timing when accessing the NOR device during boot process, then it is up to the higher boot stages to reconfigure to the right timing when BootROM succeeded reading Preloader. I added a code setting the timing back similarly as selected by strap pins before the RST is triggered, but it causes also NOR access loss. I tried to modify 'BOOTCFG_DEVSTAT' register to set 25 MHz PLL reference for normal timing instead of the errata workaround, but the strap pins are latched back into the 'BOOTCFG_DEVSTAT' after RST, even though it is written in the 66AK2G12 TRM that it should occur after the POR only.
The second method was modify the Boot Parameter Table to play with the GPMC configuration, then jump onto the BootROM re-entry function at address 0x00001004, to mimic the two-stage boot, but the CPU is trapped in the infinite loop at address 0x00000B88: 'E12FFF1E bx lr'.
I tried to set zero value at the ARMSS BOOT_MAGIC_ADDRESS, before the jump to re-entry, but the result is the same:
static volatile xipBootParams_t* bootParams = reinterpret_cast<xipBootParams_t*>(0x0C0F4100);
bootParams->options = 1;
bootParams->gpmcConfig1_msw = 0x0000;
bootParams->gpmcConfig1_lsw = 0x1002;
bootParams->gpmcConfig2_msw = 0x0010;
bootParams->gpmcConfig2_lsw = 0x1001;
bootParams->gpmcConfig3_msw = 0x2206;
bootParams->gpmcConfig3_lsw = 0x0514;
bootParams->gpmcConfig4_msw = 0x1005;
bootParams->gpmcConfig4_lsw = 0x7016;
bootParams->gpmcConfig5_msw = 0x010F;
bootParams->gpmcConfig5_lsw = 0x1111;
bootParams->gpmcConfig6_msw = 0x8F07;
bootParams->gpmcConfig6_lsw = 0x0000;
bootParams->gpmcConfig7_msw = 0x0000;
bootParams->gpmcConfig7_lsw = 0x0C70;
bootParams->gpmcConfig_msw = 0x0000;
bootParams->gpmcConfig_lsw = 0x0A00;
//*((DWORD*)0x0C0F0000) = 0UL; // ARMSS BOOT_MAGIC_ADDRESS
((void(*)(void))0x00001004)();
Unfortunatelly, I do not see under the hood of SoC's BootROM what is happenning there, so I cannot troubleshoot it. I am not sure what all is required before jump to the BootROM re-entry, to avoid any such infinite loop trap, also what is the purpose of the 'ARMSS BOOT_MAGIC_ADDRESS'. I tried to call '_romtDeviceFreqMHz()' at address 0x00001020 and got expected value without any crash, just to be sure I call BootROM functions properly.
How can I reset from our application without cold/hardware reset?
Thank you for your support,
Jiri
