| Message ID | 1412176391-24475-5-git-send-email-sr@denx.de |
|---|---|
| State | RFC |
| Delegated to: | Jagannadha Sutradharudu Teki |
| Headers | show |
On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: > This is needed for the SoCFPGA booting from SPI NOR flash > e.g. (N25Q256A). With these changes, the SoCrates can boot and > re-boot (reset) from SPI NOR flash without any problems. Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to your board please? [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot Best regards, Marek Vasut
On 1 October 2014 20:43, Stefan Roese <sr@denx.de> wrote: > This is needed for the SoCFPGA booting from SPI NOR flash > e.g. (N25Q256A). With these changes, the SoCrates can boot and > re-boot (reset) from SPI NOR flash without any problems. > > Signed-off-by: Stefan Roese <sr@denx.de> > Cc: Chin Liang See <clsee@altera.com> > Cc: Dinh Nguyen <dinguyen@altera.com> > Cc: Vince Bridgers <vbridger@altera.com> > Cc: Marek Vasut <marex@denx.de> > Cc: Pavel Machek <pavel@denx.de> > Cc: Michael Trimarchi <michael@amarulasolutions.com> > Cc: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com> > --- > drivers/mtd/spi/sf_probe.c | 31 +++++++++++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c > index 4d148d1..85b2677 100644 > --- a/drivers/mtd/spi/sf_probe.c > +++ b/drivers/mtd/spi/sf_probe.c > @@ -355,6 +355,37 @@ static struct spi_flash *spi_flash_probe_slave(struct spi_slave *spi) > } > } > > +#ifdef CONFIG_SPI_N25Q256A_RESET > +#define CMD_RESET_ENABLE 0x66 > +#define CMD_RESET_MEMORY 0x99 > + /* > + * This is needed for the SoCFPGA booting from SPI NOR flash > + * e.g. (N25Q256A). Additionally its necessary to change > + * this line in the Linux SPI NOR flash driver: > + * > + * { "n25q256a", INFO(0x20ba19, 0, 64 * 1024, 512, > + * SECT_4K | SHUTDOWN_3BYTE) }, > + * > + * Add SHUTDOWN_3BYTE here. > + * > + * With these changes, the SoCrates can boot and re-boot > + * (reset) from SPI NOR flash without any problems. > + */ > + ret = spi_flash_cmd(spi, CMD_RESET_ENABLE, NULL, 0); > + if (ret) { > + printf("SF: Failed issue reset command\n"); > + goto err_read_id; > + } > + > + ret = spi_flash_cmd(spi, CMD_RESET_MEMORY, NULL, 0); > + if (ret) { > + printf("SF: Failed issue reset command\n"); > + goto err_read_id; > + } > + > + printf("SF: Device software reset\n"); > +#endif I have tested N25Q256A on zynq, couldn't encounter this either. This seems to be SPI flash logic more hardwired to N25Q256A. Any comments? > + > #ifdef CONFIG_OF_CONTROL > if (spi_flash_decode_fdt(gd->fdt_blob, flash)) { > debug("SF: FDT decode error\n"); > -- > 2.1.1 > thanks!
On 01.10.2014 20:25, Marek Vasut wrote: > On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: >> This is needed for the SoCFPGA booting from SPI NOR flash >> e.g. (N25Q256A). With these changes, the SoCrates can boot and >> re-boot (reset) from SPI NOR flash without any problems. > > Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to your > board please? > > [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot Yes. This seems to be that case. But I can't change it right now. So this "solution" with the soft-reset is better than nothing. Thanks, Stefan
On 2 October 2014 00:27, Stefan Roese <sr@denx.de> wrote: > On 01.10.2014 20:25, Marek Vasut wrote: >> >> On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: >>> >>> This is needed for the SoCFPGA booting from SPI NOR flash >>> e.g. (N25Q256A). With these changes, the SoCrates can boot and >>> re-boot (reset) from SPI NOR flash without any problems. >> >> >> Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to >> your >> board please? >> >> [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot > > > Yes. This seems to be that case. But I can't change it right now. So this > "solution" with the soft-reset is better than nothing. If this is some think that must require, any possibility to this resetting prior to u-boot? like preloader or in first stage boot loader or something. I feel this is mostly a kind of hardware treat, and looks like it's touching generic sf framework which is not so good. thanks!
On 01.10.2014 21:04, Jagan Teki wrote: >>>> This is needed for the SoCFPGA booting from SPI NOR flash >>>> e.g. (N25Q256A). With these changes, the SoCrates can boot and >>>> re-boot (reset) from SPI NOR flash without any problems. >>> >>> >>> Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to >>> your >>> board please? >>> >>> [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot >> >> >> Yes. This seems to be that case. But I can't change it right now. So this >> "solution" with the soft-reset is better than nothing. > > If this is some think that must require, any possibility to this > resetting prior to u-boot? > like preloader or in first stage boot loader or something. Perhaps I was not clear with the intention of this patch. Its more to show how the problem with SPI flash on this platform / board (SoCrates in this case) can be solved. So that others have a reference. Thats why I marked it as RFC. Its not really meant for inclusion into mainline. The real solution is a board rework. If not possible, the preloader should be changed. As I don't have access to the preloader code right now, this "solution" (I know, its more a hack) didn't seem too bad. > I feel this is mostly a kind of hardware treat, and looks like it's > touching generic sf framework > which is not so good. Full ack on this. So please don't pull in into mainline. Thanks, Stefan
On Wed 2014-10-01 21:25:12, Stefan Roese wrote: > On 01.10.2014 21:04, Jagan Teki wrote: > >>>>This is needed for the SoCFPGA booting from SPI NOR flash > >>>>e.g. (N25Q256A). With these changes, the SoCrates can boot and > >>>>re-boot (reset) from SPI NOR flash without any problems. > >>> > >>> > >>>Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to > >>>your > >>>board please? > >>> > >>>[1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot > >> > >> > >>Yes. This seems to be that case. But I can't change it right now. So this > >>"solution" with the soft-reset is better than nothing. > > > >If this is some think that must require, any possibility to this > >resetting prior to u-boot? > >like preloader or in first stage boot loader or something. > > Perhaps I was not clear with the intention of this patch. Its more to show > how the problem with SPI flash on this platform / board (SoCrates in this > case) can be solved. So that others have a reference. Thats why I marked it > as RFC. Its not really meant for inclusion into mainline. > > The real solution is a board rework. If not possible, the preloader should > be changed. As I don't have access to the preloader code right now, this > "solution" (I know, its more a hack) didn't seem too bad. For the record, I do not think preloader is good place for such workaround. Preloader works with SDRAM, and should load real u-boot as fast as possible. If it does not need to touch SPI (it does not, right?) it should not need to work around bugs there. Actually, if SPI driver is not compiled into the u-boot, kernel will have to do the workaround. Pavel
On Wednesday, October 01, 2014 at 09:04:48 PM, Jagan Teki wrote: > On 2 October 2014 00:27, Stefan Roese <sr@denx.de> wrote: > > On 01.10.2014 20:25, Marek Vasut wrote: > >> On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: > >>> This is needed for the SoCFPGA booting from SPI NOR flash > >>> e.g. (N25Q256A). With these changes, the SoCrates can boot and > >>> re-boot (reset) from SPI NOR flash without any problems. > >> > >> Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to > >> your > >> board please? > >> > >> [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot > > > > Yes. This seems to be that case. But I can't change it right now. So this > > "solution" with the soft-reset is better than nothing. > > If this is some think that must require, any possibility to this > resetting prior to u-boot? > like preloader or in first stage boot loader or something. You do understand, that this is a hardware bug on one particular board, right ? This can _not_ be reliably solved in software, not ever. I keep seeing people implementing one such workaround after the other in linux-mtd list, but sooner or later, they discover that their workaround is not reliable. Without proper reset logic in place, a system simply cannot reliably reboot, since it has no way to put all the hardware into defined state. Also, the N25Qxxx chips are particularly crappy in this aspect, since they tend to happily get stuck in some weird undefined state during reboot. Proper reset logic solves this issue, see the link above please. Best regards, Marek Vasut
On 02.10.2014 01:07, Pavel Machek wrote: > On Wed 2014-10-01 21:25:12, Stefan Roese wrote: >> On 01.10.2014 21:04, Jagan Teki wrote: >>>>>> This is needed for the SoCFPGA booting from SPI NOR flash >>>>>> e.g. (N25Q256A). With these changes, the SoCrates can boot and >>>>>> re-boot (reset) from SPI NOR flash without any problems. >>>>> >>>>> >>>>> Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to >>>>> your >>>>> board please? >>>>> >>>>> [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot >>>> >>>> >>>> Yes. This seems to be that case. But I can't change it right now. So this >>>> "solution" with the soft-reset is better than nothing. >>> >>> If this is some think that must require, any possibility to this >>> resetting prior to u-boot? >>> like preloader or in first stage boot loader or something. >> >> Perhaps I was not clear with the intention of this patch. Its more to show >> how the problem with SPI flash on this platform / board (SoCrates in this >> case) can be solved. So that others have a reference. Thats why I marked it >> as RFC. Its not really meant for inclusion into mainline. >> >> The real solution is a board rework. If not possible, the preloader should >> be changed. As I don't have access to the preloader code right now, this >> "solution" (I know, its more a hack) didn't seem too bad. > > For the record, I do not think preloader is good place for such > workaround. Preloader works with SDRAM, and should load real u-boot as > fast as possible. If it does not need to touch SPI (it does not, > right?) it should not need to work around bugs there. In this case, where the board boots from SPI NOR flash, the Preloader (SPL U-Boot version) does use SPI. To load the main U-Boot image from the SPI NOR flash. My current best guess is that this define in the Preloader (older SPL U-Boot version) causes these problems: #define CONFIG_SPI_FLASH_QUAD (1) Once I have full access to the Preloader source (in a few days hopefully) I can verify this. Thanks, Stefan
On Thu 2014-10-02 04:47:23, Marek Vasut wrote: > On Wednesday, October 01, 2014 at 09:04:48 PM, Jagan Teki wrote: > > On 2 October 2014 00:27, Stefan Roese <sr@denx.de> wrote: > > > On 01.10.2014 20:25, Marek Vasut wrote: > > >> On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: > > >>> This is needed for the SoCFPGA booting from SPI NOR flash > > >>> e.g. (N25Q256A). With these changes, the SoCrates can boot and > > >>> re-boot (reset) from SPI NOR flash without any problems. > > >> > > >> Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to > > >> your > > >> board please? > > >> > > >> [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot > > > > > > Yes. This seems to be that case. But I can't change it right now. So this > > > "solution" with the soft-reset is better than nothing. > > > > If this is some think that must require, any possibility to this > > resetting prior to u-boot? > > like preloader or in first stage boot loader or something. > > You do understand, that this is a hardware bug on one particular board, right ? > This can _not_ be reliably solved in software, not ever. I keep seeing people > implementing one such workaround after the other in linux-mtd list, but sooner > or later, they discover that their workaround is not reliable. Without proper > reset logic in place, a system simply cannot reliably reboot, since it has no > way to put all the hardware into defined state. Well, if you have >16M flash and if you need bootrom to work with it. AFAICT, as long as you avoid using SPI from bootrom (socrates will happily run from SD card, for example), reliable operation should be possible. And you can still use SPI from Linux and u-boot... Pavel
On Thursday, October 02, 2014 at 10:40:52 AM, Pavel Machek wrote: > On Thu 2014-10-02 04:47:23, Marek Vasut wrote: > > On Wednesday, October 01, 2014 at 09:04:48 PM, Jagan Teki wrote: > > > On 2 October 2014 00:27, Stefan Roese <sr@denx.de> wrote: > > > > On 01.10.2014 20:25, Marek Vasut wrote: > > > >> On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: > > > >>> This is needed for the SoCFPGA booting from SPI NOR flash > > > >>> e.g. (N25Q256A). With these changes, the SoCrates can boot and > > > >>> re-boot (reset) from SPI NOR flash without any problems. > > > >> > > > >> Seems like your SPI NOR reset logic is buggy. Does any of [1] apply > > > >> to your > > > >> board please? > > > >> > > > >> [1] > > > >> http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot > > > > > > > > Yes. This seems to be that case. But I can't change it right now. So > > > > this "solution" with the soft-reset is better than nothing. > > > > > > If this is some think that must require, any possibility to this > > > resetting prior to u-boot? > > > like preloader or in first stage boot loader or something. > > > > You do understand, that this is a hardware bug on one particular board, > > right ? This can _not_ be reliably solved in software, not ever. I keep > > seeing people implementing one such workaround after the other in > > linux-mtd list, but sooner or later, they discover that their workaround > > is not reliable. Without proper reset logic in place, a system simply > > cannot reliably reboot, since it has no way to put all the hardware into > > defined state. > > Well, if you have >16M flash and if you need bootrom to work with it. > > AFAICT, as long as you avoid using SPI from bootrom (socrates will happily > run from SD card, for example), reliable operation should be possible. And > you can still use SPI from Linux and u-boot... SD has the same problem if you don't have proper reset logic for it ;-) Best regards, Marek Vasut
On Wed 2014-10-01 20:25:55, Marek Vasut wrote: > On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: > > This is needed for the SoCFPGA booting from SPI NOR flash > > e.g. (N25Q256A). With these changes, the SoCrates can boot and > > re-boot (reset) from SPI NOR flash without any problems. > > Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to your > board please? Actually, this has nothing to do with SPI NOR reset logic. Yes, we need to reset NOR flash during u-boot startup, because hardware was already initialized to 4-byte addressing by u-boot-spl. No matter what reset logic does, if it passes u-boot-spl (and SPI NOR is actually used), it will be in 4-byte mode. And no, mainline u-boot-spl is not usable on socfpga, and probably will not be usable for a whill, so u-boot-spl from altera is only option here. So.. what to do? Do you want this patch? Do you want patch that know how to switch back to 3-byte addressing on this particular flash? Best regards, Pavel
On Thu 2014-10-02 00:34:48, Jagan Teki wrote: > On 2 October 2014 00:27, Stefan Roese <sr@denx.de> wrote: > > On 01.10.2014 20:25, Marek Vasut wrote: > >> > >> On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: > >>> > >>> This is needed for the SoCFPGA booting from SPI NOR flash > >>> e.g. (N25Q256A). With these changes, the SoCrates can boot and > >>> re-boot (reset) from SPI NOR flash without any problems. > >> > >> > >> Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to > >> your > >> board please? > >> > >> [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot > > > > > > Yes. This seems to be that case. But I can't change it right now. So this > > "solution" with the soft-reset is better than nothing. > > If this is some think that must require, any possibility to this > resetting prior to u-boot? > like preloader or in first stage boot loader or something. u-boot-spl 2013.01/altera set it up like this for us; and mainline u-boot-spl does not work on socfpga... that's why we need to do it here, and that's why you don't see it on your board. Best regards, Pavel
On Saturday, April 25, 2015 at 09:48:31 PM, Pavel Machek wrote: > On Thu 2014-10-02 00:34:48, Jagan Teki wrote: > > On 2 October 2014 00:27, Stefan Roese <sr@denx.de> wrote: > > > On 01.10.2014 20:25, Marek Vasut wrote: > > >> On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: > > >>> This is needed for the SoCFPGA booting from SPI NOR flash > > >>> e.g. (N25Q256A). With these changes, the SoCrates can boot and > > >>> re-boot (reset) from SPI NOR flash without any problems. > > >> > > >> Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to > > >> your > > >> board please? > > >> > > >> [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot > > > > > > Yes. This seems to be that case. But I can't change it right now. So > > > this "solution" with the soft-reset is better than nothing. > > > > If this is some think that must require, any possibility to this > > resetting prior to u-boot? > > like preloader or in first stage boot loader or something. > > u-boot-spl 2013.01/altera set it up like this for us; and mainline > u-boot-spl does not work on socfpga... that's why we need to do it > here, and that's why you don't see it on your board. As discussed in person, please rebase and repost. You're right that it's a good idea to add an option to restart the SPI NOR in software if needed be. Best regards, Marek Vasut
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c index 4d148d1..85b2677 100644 --- a/drivers/mtd/spi/sf_probe.c +++ b/drivers/mtd/spi/sf_probe.c @@ -355,6 +355,37 @@ static struct spi_flash *spi_flash_probe_slave(struct spi_slave *spi) } } +#ifdef CONFIG_SPI_N25Q256A_RESET +#define CMD_RESET_ENABLE 0x66 +#define CMD_RESET_MEMORY 0x99 + /* + * This is needed for the SoCFPGA booting from SPI NOR flash + * e.g. (N25Q256A). Additionally its necessary to change + * this line in the Linux SPI NOR flash driver: + * + * { "n25q256a", INFO(0x20ba19, 0, 64 * 1024, 512, + * SECT_4K | SHUTDOWN_3BYTE) }, + * + * Add SHUTDOWN_3BYTE here. + * + * With these changes, the SoCrates can boot and re-boot + * (reset) from SPI NOR flash without any problems. + */ + ret = spi_flash_cmd(spi, CMD_RESET_ENABLE, NULL, 0); + if (ret) { + printf("SF: Failed issue reset command\n"); + goto err_read_id; + } + + ret = spi_flash_cmd(spi, CMD_RESET_MEMORY, NULL, 0); + if (ret) { + printf("SF: Failed issue reset command\n"); + goto err_read_id; + } + + printf("SF: Device software reset\n"); +#endif + #ifdef CONFIG_OF_CONTROL if (spi_flash_decode_fdt(gd->fdt_blob, flash)) { debug("SF: FDT decode error\n");
This is needed for the SoCFPGA booting from SPI NOR flash e.g. (N25Q256A). With these changes, the SoCrates can boot and re-boot (reset) from SPI NOR flash without any problems. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Chin Liang See <clsee@altera.com> Cc: Dinh Nguyen <dinguyen@altera.com> Cc: Vince Bridgers <vbridger@altera.com> Cc: Marek Vasut <marex@denx.de> Cc: Pavel Machek <pavel@denx.de> Cc: Michael Trimarchi <michael@amarulasolutions.com> Cc: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com> --- drivers/mtd/spi/sf_probe.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)