[U-Boot] cyclone5 reboot: warm or cold reset?

Tue Apr 30 21:40:51 UTC 2019

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 at lists.denx.de
> > > > > > 
> > > > > > https://lists.denx.de/listinfo/u-boot
> > > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3282 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190430/609f7faf/attachment.bin>