[U-Boot] cyclone5 reboot: warm or cold reset?
Hi all,
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).
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).
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? 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#...
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.
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.
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/
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.
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#...
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
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).
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#...
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
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).
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#...
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
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).
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#...
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
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).
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#...
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Tue, 2019-04-30 at 22:09 +0200, Marek Vasut wrote:
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).
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.
In some ES silicon for C5, which happens to be what is used on the DE0 board, there was an issue that required CSEL=0. As noted in the comments, for CSEL=0 the bootrom does not reset the PLL/clock configurations and as a result the QSPI clock in your case is not being modified to a useable clock for the bootrom. The patch just forced a cold reset when csel=0. personally, i would like a default to cold resets, with an option to use warm resets should a use case exist (such as preserving DDR contents).
What changed with 4-byte access in the QSPI?
--dalon
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#...
U-Boot mailing list U-Boot@lists.denx.de
On 30.04.19 23:40, Westergreen, Dalon wrote:
On Tue, 2019-04-30 at 22:09 +0200, Marek Vasut wrote:
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).
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.
In some ES silicon for C5, which happens to be what is used on the DE0 board, there was an issue that required CSEL=0. As noted in the comments, for CSEL=0 the bootrom does not reset the PLL/clock configurations and as a result the QSPI clock in your case is not being modified to a useable clock for the bootrom. The patch just forced a cold reset when csel=0. personally, i would like a default to cold resets, with an option to use warm resets should a use case exist (such as preserving DDR contents).
Right, QSPI periph clock stays at 400 MHz, so the external clock is 100 MHz. And it doesn't seem to work reliably at 100 MHz, although the chip should work up to 108 MHz.
Defaulting to cold reset with optional warm reset sounds like a good idea.
What changed with 4-byte access in the QSPI?
Since Vignesh ported the Linux MTD layer, U-Boot supports 4-byte opcodes, so it doesn't need to set BAR in the chip or 4-byte mode. Both of those are stateful, so the Boot ROM might not be able to load SPL.
With using 4-byte opcodes, this problem is now gone.
Regards, Simon
--dalon
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#... > > > > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot >
participants (4)
-
Marek Vasut -
Marek Vasut -
Simon Goldschmidt -
Westergreen, Dalon