On Tue, 2019-04-30 at 22:09 +0200, Marek Vasut wrote: > On 4/30/19 10:05 PM, Simon Goldschmidt wrote: > > Am 30.04.2019 um 22:01 schrieb Marek Vasut: > > > 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. > > > > Well, what I read from hat patch is that it only writes the magic to > > make Boot ROM jump to OCRAM if csel != 0. So it would try to load SPL > > from QSPI for csel == 0 in my case (and I do have csel ==0 0). > > > > I fail to see the "somewhere else" in the link you sent. Maybe that was > > in an older version? > > That's quite possible , there were a few iterations.
In some ES silicon for C5, which happens to be what is used on the DE0 board, there was an issue that required CSEL=0. As noted in the comments, for CSEL=0 the bootrom does not reset the PLL/clock configurations and as a result the QSPI clock in your case is not being modified to a useable clock for the bootrom. The patch just forced a cold reset when csel=0. personally, i would like a default to cold resets, with an option to use warm resets should a use case exist (such as preserving DDR contents). What changed with 4-byte access in the QSPI? --dalon > > > > > 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. > > > > Right, something like that. Probably the same enum Linux uses (enum > > reboot_mode), to make things clearer. > > Right > > > Regards, > > Simon > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot