On 4/30/19 9:19 PM, Simon Goldschmidt wrote: > Am 30.04.2019 um 21:08 schrieb Marek Vasut: >> 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. > > Right, but unfortunately, that's not an issue for us :-) > >> >> 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. > > Yeah, well, let's just assume there *are* boards that either use spi-nor > chips without a working reset line and there *are* boards with spi-nor > chips having a reset line that is just not connected... > >> >>> 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/ > > Interesting, I didn't know that one. I doesn't seem to have made it into > the tree, but it's a different thing slightly: it prevents the Boot ROM > jumping to OCRAM, but that's what I did and it still fails as the Boot > ROM uses a constant divider "4" resulting in loading SPL with 100 MHz > from the qspi chip. And that somehow fails.
It makes the bootrom jump "somewhere else" in OCRAM upon warm reset, to a code which resets the PLLs and then triggers another warm reset, this time with a jump address pointing to the SPL. > If I change the handoff files so that the qspi core runs at 200 MHz > instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold > reset would still be better... > >> >>> 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. > > Ok, from reading the above thread, I guess there might be use cases for > the warm reset but not for us. So I can make Linux using cold reset via > a Kernel command line parameter but I can't do it for U-Boot. > > Looks like we need a method to control this for U-Boot. Unless someone > comes up with a better explanation, that is. Update the "reset" command to take a parameter -- type of reset. It's been on my list of things to do for a while, but didn't get around to it. > Regards, > Simon > >> >>> 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#topic/sfo1410067764332.html >>> >>> >>> _______________________________________________ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> https://lists.denx.de/listinfo/u-boot >> >> > -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot