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.
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.
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
