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