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

[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.

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


-- 
Best regards,
Marek Vasut