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

[Simon Goldschmidt]

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 at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
> 
>