On 4/30/19 8:56 PM, Simon Goldschmidt wrote:
Hi all,
Hi,
I added some of those I think worth discussing this.
I was chasing a reboot problem on one of our cyclone5 boards today. That board boots from a "n25q256a" qspi flash. Up to now, U-Boot configures the boot ROM to just jump to OCRAM when rebooting and hope that the SPL is still there and fully working (nothing's overwritten).
For a long running production board, this is of course crap, as a pointer running wild could always overwrite the SRAM. But there was not much we could do about it as long as U-Boot and/or Linux were putting out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot ROM unless in 3-byte mode. And while Linux "reboot" could reset the chip into 3-byte mode, "reboot -f" and U-Boot "reset" can't.
Now with U-Boot and Linux having everything in place to leave the spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte opcodes, I thought rebooting from Linux would now work with loading the SPL from qspi (by disabling the magic that tells the Boot ROM to jump to OCRAM).
Well, if the chip is in the middle of some operation (erase or page program) and you reset the CPU just at the right moment, leaving the chip in 3byte addressing mode won't help you anyway.
The only reliable solution is to connect reset to the SPI NOR chip and trigger the reset. Of course, some SPI NORs have a reset line, but it is not connected internally, which is a fantastic design. I think the N25Q256 had exactly such a problem, but only on some revisions, to make it even more messed up.
However, I found the Boot ROM still cannot load the SPL because it tries to load at 100 MHz (while on cold boot, it loads with 6.25 MHz).
Look at https://patchwork.ozlabs.org/patch/729738/
However, when triggering cold reset instead of warm reset in rstmgr ctrl register [1], it works fine (and qspi clock is 6.25 MHz).
Now the question is: why do we trigger warm reset instead of cold reset?
I'd like to know that too. But it's likely because of various AMP setups, where the second CPU or the FPGA do something and you don't want to interrupt that operation by the primary CPU's reset. I haven't seen such deployments much myself though.
Isn't cold reset more stable, e.g. when rebooting watchdog-like? Linux also uses warm reset by default, but I'm tempted to send a patch for both U-Boot and Linux to use cold reset by default.
Any insight on the consequences of using cold reset instead of warm reset would be really appreciated!
Regards, Simon
[1] https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#...
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot