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

[Simon Goldschmidt]

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?

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

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