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

[Marek Vasut]

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.

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


-- 
Best regards,
Marek Vasut