[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Alexander Stein]

When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog
timeout might occur meanwhile. So pet the watchdog while operating on
the flash.

Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
 drivers/spi/fsl_qspi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index ed39114..feec3e8 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -13,6 +13,7 @@
 #include <linux/sizes.h>
 #include <dm.h>
 #include <errno.h>
+#include <watchdog.h>
 #include "fsl_qspi.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -527,6 +528,8 @@ static void qspi_op_read(struct fsl_qspi_priv *priv, u32 *rxbuf, u32 len)
 	to_or_from = priv->sf_addr + priv->cur_amba_base;
 
 	while (len > 0) {
+		WATCHDOG_RESET();
+
 		qspi_write32(priv->flags, &regs->sfar, to_or_from);
 
 		size = (len > RX_BUFFER_SIZE) ?
@@ -574,6 +577,8 @@ static void qspi_op_write(struct fsl_qspi_priv *priv, u8 *txbuf, u32 len)
 
 	status_reg = 0;
 	while ((status_reg & FLASH_STATUS_WEL) != FLASH_STATUS_WEL) {
+		WATCHDOG_RESET();
+
 		qspi_write32(priv->flags, &regs->ipcr,
 			     (SEQID_WREN << QSPI_IPCR_SEQID_SHIFT) | 0);
 		while (qspi_read32(priv->flags, &regs->sr) & QSPI_SR_BUSY_MASK)
-- 
2.4.10

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[York Sun]

On 11/04/2015 12:19 AM, Alexander Stein wrote:
> When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog
> timeout might occur meanwhile. So pet the watchdog while operating on
> the flash.

Alexander,

On which platform was this watchdog issue found?

> 
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
>  drivers/spi/fsl_qspi.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
> index ed39114..feec3e8 100644
> --- a/drivers/spi/fsl_qspi.c
> +++ b/drivers/spi/fsl_qspi.c
> @@ -13,6 +13,7 @@
>  #include <linux/sizes.h>
>  #include <dm.h>
>  #include <errno.h>
> +#include <watchdog.h>
>  #include "fsl_qspi.h"
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -527,6 +528,8 @@ static void qspi_op_read(struct fsl_qspi_priv *priv, u32 *rxbuf, u32 len)
>  	to_or_from = priv->sf_addr + priv->cur_amba_base;
>  
>  	while (len > 0) {
> +		WATCHDOG_RESET();
> +
>  		qspi_write32(priv->flags, &regs->sfar, to_or_from);
>  
>  		size = (len > RX_BUFFER_SIZE) ?
> @@ -574,6 +577,8 @@ static void qspi_op_write(struct fsl_qspi_priv *priv, u8 *txbuf, u32 len)
>  
>  	status_reg = 0;
>  	while ((status_reg & FLASH_STATUS_WEL) != FLASH_STATUS_WEL) {
> +		WATCHDOG_RESET();
> +
>  		qspi_write32(priv->flags, &regs->ipcr,
>  			     (SEQID_WREN << QSPI_IPCR_SEQID_SHIFT) | 0);
>  		while (qspi_read32(priv->flags, &regs->sr) & QSPI_SR_BUSY_MASK)
> 

York

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Alexander Stein]

On Monday 23 November 2015 10:51:49, York Sun wrote:
> On 11/04/2015 12:19 AM, Alexander Stein wrote:
> > When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog
> > timeout might occur meanwhile. So pet the watchdog while operating on
> > the flash.
> 
> Alexander,
> 
> On which platform was this watchdog issue found?

On a custom board based on LS1021A. The (GPIO based) watchdog timeout is about 1.5s

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein at systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax:    +49 (0) 3765 38600-4100
 
Managing Directors:
	Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
	Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
	Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[York Sun]

On 11/23/2015 11:19 PM, Alexander Stein wrote:
> On Monday 23 November 2015 10:51:49, York Sun wrote:
>> On 11/04/2015 12:19 AM, Alexander Stein wrote:
>>> When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog
>>> timeout might occur meanwhile. So pet the watchdog while operating on
>>> the flash.
>>
>> Alexander,
>>
>> On which platform was this watchdog issue found?
> 
> On a custom board based on LS1021A. The (GPIO based) watchdog timeout is about 1.5s
> 
>
Thanks.

Alison,

Please test on your boards to see if you suffer the same. I wonder how fast QSPI
runs and why we didn't see this issue.

York

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Huan Wang]

> On 11/23/2015 11:19 PM, Alexander Stein wrote:
> > On Monday 23 November 2015 10:51:49, York Sun wrote:
> >> On 11/04/2015 12:19 AM, Alexander Stein wrote:
> >>> When reading a large blob. e.g. a linux kernel (several MiBs) a
> >>> watchdog timeout might occur meanwhile. So pet the watchdog while
> >>> operating on the flash.
> >>
> >> Alexander,
> >>
> >> On which platform was this watchdog issue found?
> >
> > On a custom board based on LS1021A. The (GPIO based) watchdog timeout
> > is about 1.5s
> >
> >
> Thanks.
> 
> Alison,
> 
> Please test on your boards to see if you suffer the same. I wonder how
> fast QSPI runs and why we didn't see this issue.
> 
[Alison Wang] I didn't meet any issue when using sf commands to write and
read the serial flash.

Hi, Alexander,

	Could you show me the detail commands and process when you meet
such issue? Then I can try to reproduce on my board. 


Best Regards,
Alison Wang

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Alexander Stein]

On Wednesday 25 November 2015 02:20:53, Huan Wang wrote:
> [Alison Wang] I didn't meet any issue when using sf commands to write and
> read the serial flash.
> 
> Hi, Alexander,
> 
> 	Could you show me the detail commands and process when you meet
> such issue? Then I can try to reproduce on my board. 

Yep, here is the output:
> U-Boot 2015.01-00671-g78773b9 (Nov 25 2015 - 10:28:50)
> 
> CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
> 
> Clock Configuration:
>        CPU0(ARMV7):960  MHz,
>        Bus:288  MHz, DDR:800  MHz (1600 MT/s data rate),
> Reset Configuration Word (RCW):
>        00000000: 0608000a 00000000 00000000 00000000
>        00000010: 70000000 08407922 40000a00 21046000
>        00000020: 00000000 00000000 00000000 0021ef00
>        00000030: 20024800 0888f340 00000000 00000000
> QSPI
>        Watchdog enabled
> I2C:   ready
> DRAM:  Initializing DDR....
> Detected UDIMM Fixed DDR on board
> 512 MiB (DDR3, 16-bit, CL=11, ECC off)
> Using SERDES1 Protocol: 112 (0x70)
> MMC:   FSL_SDHC: 0
> SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB,
> In:    serial
> Out:   serial
> Err:   serial
> SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB,
> total 64 MiB SF: 262144 bytes @ 0x180000 Read: OK
> Firmware 'Microcode version 0.0.1 for LS1021a r1.0' for 1021 V1.0
> QE: uploading microcode 'Microcode for LS1021a r1.0' version 0.0.1
> SCSI:  Net:   eTSEC2 is in sgmii mode.
> eTSEC1 [PRIME], eTSEC2
> Hit any key to stop autoboot:  0
> => sf read 0x81040000 0x200000 0x400000
> 
> 
> U-Boot 2015.01-00671-g78773b9 (Nov 25 2015 - 10:28:50)
> 
> CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
> 
> Clock Configuration:
>        CPU0(ARMV7):960  MHz,
>        Bus:288  MHz, DDR:800  MHz (1600 MT/s data rate),
> Reset Configuration Word (RCW):
>        00000000: 0608000a 00000000 00000000 00000000
>        00000010: 70000000 08407922 40000a00 21046000
>        00000020: 00000000 00000000 00000000 0021ef00
>        00000030: 20024800 0888f340 00000000 00000000
> QSPI
>        Watchdog enabled
> I2C:   ready
> DRAM:  Initializing DDR....
> Detected UDIMM Fixed DDR on board
> [...]
and so on...

The actual command which results in a watchdog reset is 'sf read 0x81040000 0x200000 0x400000'. Please note that this uses an external watchdog which is enabled by default and resets after ~1.5s. The command itself takes about 2s (taken from my watch).

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein at systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax:    +49 (0) 3765 38600-4100
 
Managing Directors:
	Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
	Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
	Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Huan Wang]

Hi, York,

> On Wednesday 25 November 2015 02:20:53, Huan Wang wrote:
> > [Alison Wang] I didn't meet any issue when using sf commands to write
> > and read the serial flash.
> >
> > Hi, Alexander,
> >
> > 	Could you show me the detail commands and process when you meet
> such
> > issue? Then I can try to reproduce on my board.
> 
> Yep, here is the output:
> > U-Boot 2015.01-00671-g78773b9 (Nov 25 2015 - 10:28:50)
> >
> > CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
> >
> > Clock Configuration:
> >        CPU0(ARMV7):960  MHz,
> >        Bus:288  MHz, DDR:800  MHz (1600 MT/s data rate), Reset
> > Configuration Word (RCW):
> >        00000000: 0608000a 00000000 00000000 00000000
> >        00000010: 70000000 08407922 40000a00 21046000
> >        00000020: 00000000 00000000 00000000 0021ef00
> >        00000030: 20024800 0888f340 00000000 00000000 QSPI
> >        Watchdog enabled
> > I2C:   ready
> > DRAM:  Initializing DDR....
> > Detected UDIMM Fixed DDR on board
> > 512 MiB (DDR3, 16-bit, CL=11, ECC off) Using SERDES1 Protocol: 112
> > (0x70)
> > MMC:   FSL_SDHC: 0
> > SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256
> KiB,
> > In:    serial
> > Out:   serial
> > Err:   serial
> > SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256
> > KiB, total 64 MiB SF: 262144 bytes @ 0x180000 Read: OK Firmware
> > 'Microcode version 0.0.1 for LS1021a r1.0' for 1021 V1.0
> > QE: uploading microcode 'Microcode for LS1021a r1.0' version 0.0.1
> > SCSI:  Net:   eTSEC2 is in sgmii mode.
> > eTSEC1 [PRIME], eTSEC2
> > Hit any key to stop autoboot:  0
> > => sf read 0x81040000 0x200000 0x400000
> >
> >
> > U-Boot 2015.01-00671-g78773b9 (Nov 25 2015 - 10:28:50)
> >
> > CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
> >
> > Clock Configuration:
> >        CPU0(ARMV7):960  MHz,
> >        Bus:288  MHz, DDR:800  MHz (1600 MT/s data rate), Reset
> > Configuration Word (RCW):
> >        00000000: 0608000a 00000000 00000000 00000000
> >        00000010: 70000000 08407922 40000a00 21046000
> >        00000020: 00000000 00000000 00000000 0021ef00
> >        00000030: 20024800 0888f340 00000000 00000000 QSPI
> >        Watchdog enabled
> > I2C:   ready
> > DRAM:  Initializing DDR....
> > Detected UDIMM Fixed DDR on board
> > [...]
> and so on...
> 
> The actual command which results in a watchdog reset is 'sf read
> 0x81040000 0x200000 0x400000'. Please note that this uses an external
> watchdog which is enabled by default and resets after ~1.5s. The command
> itself takes about 2s (taken from my watch).
> 
[Alison Wang] I could not reproduce the issue. Maybe I don't have the
external watchdog which will reset after ~1.5s as Alexander mentioned.

U-Boot 2015.10-00273-g7ee52af (Dec 03 2015 - 17:32:24 +0800)

CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
Clock Configuration:
       CPU0(ARMV7):1000 MHz,
       Bus:300  MHz, DDR:800  MHz (1600 MT/s data rate),
Reset Configuration Word (RCW):
       00000000: 0608000a 00000000 00000000 00000000
       00000010: 30000000 00007900 40025a00 21046000
       00000020: 00000000 00000000 00000000 20000000
       00000030: 20024800 881b7540 00000000 00000000
Model: LS1021A TWR Board
Board: LS1021ATWR
I2C:   ready
DRAM:  1 GiB
Using SERDES1 Protocol: 48 (0x30)
MMC:   FSL_SDHC: 0
SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
EEPROM: NXID v1
PCIe1: Root Complex no link, regs @ 0x3400000
PCIe2: disabled
In:    serial
Out:   serial
Err:   serial
SEC: RNG instantiated
SATA link 0 timeout.
AHCI 0001.0300 1 slots 1 ports ? Gbps 0x1 impl SATA mode
flags: 64bit ncq pm clo only pmp fbss pio slum part ccc
Found 0 device(s).
SCSI:  Net:   eTSEC1 is in sgmii mode.
eTSEC2 is in sgmii mode.
eTSEC1, eTSEC2, eTSEC3 [PRIME]
=> => sf probe
SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
=> sf read 0x81040000 0x200000 0x400000
device 0 offset 0x200000, size 0x400000
SF: 4194304 bytes @ 0x200000 Read: OK
=>


Best Regards,
Alison Wang

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Alexander Stein]

Hi,

On Thursday 03 December 2015 09:49:40, Huan Wang wrote:
> [Alison Wang] I could not reproduce the issue. Maybe I don't have the
> external watchdog which will reset after ~1.5s as Alexander mentioned.

Could you try to set the internal watchdog to 1s timeout? This should be more or less the same scenario.

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein at systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax:    +49 (0) 3765 38600-4100
 
Managing Directors:
	Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
	Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
	Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Huan Wang]

> On Thursday 03 December 2015 09:49:40, Huan Wang wrote:
> > [Alison Wang] I could not reproduce the issue. Maybe I don't have the
> > external watchdog which will reset after ~1.5s as Alexander mentioned.
> 
> Could you try to set the internal watchdog to 1s timeout? This should be
> more or less the same scenario.
> 
[Alison Wang] Yes, I could do that and I think the system will reset as we
set the watchdog to 1s timeout. But if we don't set the watchdog to 1s
timeout, "sf read" will work correctly. Right?

If so, I think there is no problem about the driver itself.

Best Regards,
Alison Wang

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[York Sun]

On 12/03/2015 01:49 AM, Wang Huan-B18965 wrote:

<snip>

>>
>> The actual command which results in a watchdog reset is 'sf read
>> 0x81040000 0x200000 0x400000'. Please note that this uses an external
>> watchdog which is enabled by default and resets after ~1.5s. The command
>> itself takes about 2s (taken from my watch).
>>
> [Alison Wang] I could not reproduce the issue. Maybe I don't have the
> external watchdog which will reset after ~1.5s as Alexander mentioned.
> 
> U-Boot 2015.10-00273-g7ee52af (Dec 03 2015 - 17:32:24 +0800)
> 
> CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
> Clock Configuration:
>        CPU0(ARMV7):1000 MHz,
>        Bus:300  MHz, DDR:800  MHz (1600 MT/s data rate),
> Reset Configuration Word (RCW):
>        00000000: 0608000a 00000000 00000000 00000000
>        00000010: 30000000 00007900 40025a00 21046000
>        00000020: 00000000 00000000 00000000 20000000
>        00000030: 20024800 881b7540 00000000 00000000
> Model: LS1021A TWR Board
> Board: LS1021ATWR
> I2C:   ready
> DRAM:  1 GiB
> Using SERDES1 Protocol: 48 (0x30)
> MMC:   FSL_SDHC: 0
> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> EEPROM: NXID v1
> PCIe1: Root Complex no link, regs @ 0x3400000
> PCIe2: disabled
> In:    serial
> Out:   serial
> Err:   serial
> SEC: RNG instantiated
> SATA link 0 timeout.
> AHCI 0001.0300 1 slots 1 ports ? Gbps 0x1 impl SATA mode
> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc
> Found 0 device(s).
> SCSI:  Net:   eTSEC1 is in sgmii mode.
> eTSEC2 is in sgmii mode.
> eTSEC1, eTSEC2, eTSEC3 [PRIME]
> => => sf probe
> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> => sf read 0x81040000 0x200000 0x400000
> device 0 offset 0x200000, size 0x400000
> SF: 4194304 bytes @ 0x200000 Read: OK
> =>

Alison and Alexander,

My concerns are

Is the watchdog triggered reasonably?
How long does it take to load the file?
Is SPI running at reasonable speed?
Is there other similar situations such as loading large file off NOR flash?


York

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Huan Wang]

> On 12/03/2015 01:49 AM, Wang Huan-B18965 wrote:
> 
> <snip>
> 
> >>
> >> The actual command which results in a watchdog reset is 'sf read
> >> 0x81040000 0x200000 0x400000'. Please note that this uses an external
> >> watchdog which is enabled by default and resets after ~1.5s. The
> >> command itself takes about 2s (taken from my watch).
> >>
> > [Alison Wang] I could not reproduce the issue. Maybe I don't have the
> > external watchdog which will reset after ~1.5s as Alexander mentioned.
> >
> > U-Boot 2015.10-00273-g7ee52af (Dec 03 2015 - 17:32:24 +0800)
> >
> > CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
> > Clock Configuration:
> >        CPU0(ARMV7):1000 MHz,
> >        Bus:300  MHz, DDR:800  MHz (1600 MT/s data rate), Reset
> > Configuration Word (RCW):
> >        00000000: 0608000a 00000000 00000000 00000000
> >        00000010: 30000000 00007900 40025a00 21046000
> >        00000020: 00000000 00000000 00000000 20000000
> >        00000030: 20024800 881b7540 00000000 00000000
> > Model: LS1021A TWR Board
> > Board: LS1021ATWR
> > I2C:   ready
> > DRAM:  1 GiB
> > Using SERDES1 Protocol: 48 (0x30)
> > MMC:   FSL_SDHC: 0
> > SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB,
> > total 16 MiB
> > EEPROM: NXID v1
> > PCIe1: Root Complex no link, regs @ 0x3400000
> > PCIe2: disabled
> > In:    serial
> > Out:   serial
> > Err:   serial
> > SEC: RNG instantiated
> > SATA link 0 timeout.
> > AHCI 0001.0300 1 slots 1 ports ? Gbps 0x1 impl SATA mode
> > flags: 64bit ncq pm clo only pmp fbss pio slum part ccc Found 0
> > device(s).
> > SCSI:  Net:   eTSEC1 is in sgmii mode.
> > eTSEC2 is in sgmii mode.
> > eTSEC1, eTSEC2, eTSEC3 [PRIME]
> > => => sf probe
> > SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB,
> > total 16 MiB => sf read 0x81040000 0x200000 0x400000 device 0 offset
> > 0x200000, size 0x400000
> > SF: 4194304 bytes @ 0x200000 Read: OK
> > =>
> 
> Alison and Alexander,
> 
> My concerns are
> 
> Is the watchdog triggered reasonably?
[Alison Wang] I think as Alexander set the watchdog to 1s timeout, so the
trigger occurs at that time.
> How long does it take to load the file?
[Alison Wang] About 2s.
> Is SPI running at reasonable speed?
[Alison Wang] Yes.
> Is there other similar situations such as loading large file off NOR
> flash?
[Alison Wang] If we don't set the watchdog to 1s timeout, both loading
Large file to serial flash or NOR flash, there is not such situation.
If we set the watchdog to 1s timeout, I think there are both such
situation.

Alexander, do you agree with my answer? Please give your comments too. :)

Best Regards,
Alison Wang

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[York Sun]

On 12/03/2015 05:56 PM, Wang Huan-B18965 wrote:
>> On 12/03/2015 01:49 AM, Wang Huan-B18965 wrote:
>>
>> <snip>
>>
>>>>
>>>> The actual command which results in a watchdog reset is 'sf read
>>>> 0x81040000 0x200000 0x400000'. Please note that this uses an external
>>>> watchdog which is enabled by default and resets after ~1.5s. The
>>>> command itself takes about 2s (taken from my watch).
>>>>
>>> [Alison Wang] I could not reproduce the issue. Maybe I don't have the
>>> external watchdog which will reset after ~1.5s as Alexander mentioned.
>>>
>>> U-Boot 2015.10-00273-g7ee52af (Dec 03 2015 - 17:32:24 +0800)
>>>
>>> CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
>>> Clock Configuration:
>>>        CPU0(ARMV7):1000 MHz,
>>>        Bus:300  MHz, DDR:800  MHz (1600 MT/s data rate), Reset
>>> Configuration Word (RCW):
>>>        00000000: 0608000a 00000000 00000000 00000000
>>>        00000010: 30000000 00007900 40025a00 21046000
>>>        00000020: 00000000 00000000 00000000 20000000
>>>        00000030: 20024800 881b7540 00000000 00000000
>>> Model: LS1021A TWR Board
>>> Board: LS1021ATWR
>>> I2C:   ready
>>> DRAM:  1 GiB
>>> Using SERDES1 Protocol: 48 (0x30)
>>> MMC:   FSL_SDHC: 0
>>> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB,
>>> total 16 MiB
>>> EEPROM: NXID v1
>>> PCIe1: Root Complex no link, regs @ 0x3400000
>>> PCIe2: disabled
>>> In:    serial
>>> Out:   serial
>>> Err:   serial
>>> SEC: RNG instantiated
>>> SATA link 0 timeout.
>>> AHCI 0001.0300 1 slots 1 ports ? Gbps 0x1 impl SATA mode
>>> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc Found 0
>>> device(s).
>>> SCSI:  Net:   eTSEC1 is in sgmii mode.
>>> eTSEC2 is in sgmii mode.
>>> eTSEC1, eTSEC2, eTSEC3 [PRIME]
>>> => => sf probe
>>> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB,
>>> total 16 MiB => sf read 0x81040000 0x200000 0x400000 device 0 offset
>>> 0x200000, size 0x400000
>>> SF: 4194304 bytes @ 0x200000 Read: OK
>>> =>
>>
>> Alison and Alexander,
>>
>> My concerns are
>>
>> Is the watchdog triggered reasonably?
> [Alison Wang] I think as Alexander set the watchdog to 1s timeout, so the
> trigger occurs at that time.
>> How long does it take to load the file?
> [Alison Wang] About 2s.
>> Is SPI running at reasonable speed?
> [Alison Wang] Yes.
>> Is there other similar situations such as loading large file off NOR
>> flash?
> [Alison Wang] If we don't set the watchdog to 1s timeout, both loading
> Large file to serial flash or NOR flash, there is not such situation.
> If we set the watchdog to 1s timeout, I think there are both such
> situation.
> 
> Alexander, do you agree with my answer? Please give your comments too. :)
> 

If an external watchdog is used, any long operation may trigger it.

Jagan,

If you are OK with it, I can bring this patch in.

York

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Alexander Stein]

On Friday 04 December 2015 12:10:47, York Sun wrote:
> 
> On 12/03/2015 05:56 PM, Wang Huan-B18965 wrote:
> >> On 12/03/2015 01:49 AM, Wang Huan-B18965 wrote:
> >>
> >> <snip>
> >>
> >>>>
> >>>> The actual command which results in a watchdog reset is 'sf read
> >>>> 0x81040000 0x200000 0x400000'. Please note that this uses an external
> >>>> watchdog which is enabled by default and resets after ~1.5s. The
> >>>> command itself takes about 2s (taken from my watch).
> >>>>
> >>> [Alison Wang] I could not reproduce the issue. Maybe I don't have the
> >>> external watchdog which will reset after ~1.5s as Alexander mentioned.
> >>>
> >>> U-Boot 2015.10-00273-g7ee52af (Dec 03 2015 - 17:32:24 +0800)
> >>>
> >>> CPU:   Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
> >>> Clock Configuration:
> >>>        CPU0(ARMV7):1000 MHz,
> >>>        Bus:300  MHz, DDR:800  MHz (1600 MT/s data rate), Reset
> >>> Configuration Word (RCW):
> >>>        00000000: 0608000a 00000000 00000000 00000000
> >>>        00000010: 30000000 00007900 40025a00 21046000
> >>>        00000020: 00000000 00000000 00000000 20000000
> >>>        00000030: 20024800 881b7540 00000000 00000000
> >>> Model: LS1021A TWR Board
> >>> Board: LS1021ATWR
> >>> I2C:   ready
> >>> DRAM:  1 GiB
> >>> Using SERDES1 Protocol: 48 (0x30)
> >>> MMC:   FSL_SDHC: 0
> >>> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB,
> >>> total 16 MiB
> >>> EEPROM: NXID v1
> >>> PCIe1: Root Complex no link, regs @ 0x3400000
> >>> PCIe2: disabled
> >>> In:    serial
> >>> Out:   serial
> >>> Err:   serial
> >>> SEC: RNG instantiated
> >>> SATA link 0 timeout.
> >>> AHCI 0001.0300 1 slots 1 ports ? Gbps 0x1 impl SATA mode
> >>> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc Found 0
> >>> device(s).
> >>> SCSI:  Net:   eTSEC1 is in sgmii mode.
> >>> eTSEC2 is in sgmii mode.
> >>> eTSEC1, eTSEC2, eTSEC3 [PRIME]
> >>> => => sf probe
> >>> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB,
> >>> total 16 MiB => sf read 0x81040000 0x200000 0x400000 device 0 offset
> >>> 0x200000, size 0x400000
> >>> SF: 4194304 bytes @ 0x200000 Read: OK
> >>> =>
> >>
> >> Alison and Alexander,
> >>
> >> My concerns are
> >>
> >> Is the watchdog triggered reasonably?
> > [Alison Wang] I think as Alexander set the watchdog to 1s timeout, so the
> > trigger occurs at that time.

Well, 'set' is not exactly correct. It is 'set' by hardware (power sequencer), thus fixed in hardware. No way to change it.

> >> How long does it take to load the file?
> > [Alison Wang] About 2s.
> >> Is SPI running at reasonable speed?
> > [Alison Wang] Yes.
> >> Is there other similar situations such as loading large file off NOR
> >> flash?
> > [Alison Wang] If we don't set the watchdog to 1s timeout, both loading
> > Large file to serial flash or NOR flash, there is not such situation.
> > If we set the watchdog to 1s timeout, I think there are both such
> > situation.
> > 
> > Alexander, do you agree with my answer? Please give your comments too. :)

I can't test NOR, there is just none. But loading from TFTP works fine (about 3s download time), so it seems rather a QSPI driver problem.
Other answers are same for me.

> If an external watchdog is used, any long operation may trigger it.

Yep, especially there is no way to avoid that, despite petting it at reasonable intervals.

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein at systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax:    +49 (0) 3765 38600-4100
 
Managing Directors:
	Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
	Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
	Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[York Sun]

On 11/24/2015 06:20 PM, Wang Huan-B18965 wrote:
>> On 11/23/2015 11:19 PM, Alexander Stein wrote:
>>> On Monday 23 November 2015 10:51:49, York Sun wrote:
>>>> On 11/04/2015 12:19 AM, Alexander Stein wrote:
>>>>> When reading a large blob. e.g. a linux kernel (several MiBs) a
>>>>> watchdog timeout might occur meanwhile. So pet the watchdog while
>>>>> operating on the flash.
>>>>
>>>> Alexander,
>>>>
>>>> On which platform was this watchdog issue found?
>>>
>>> On a custom board based on LS1021A. The (GPIO based) watchdog timeout
>>> is about 1.5s
>>>
>>>
>> Thanks.
>>
>> Alison,
>>
>> Please test on your boards to see if you suffer the same. I wonder how
>> fast QSPI runs and why we didn't see this issue.
>>
> [Alison Wang] I didn't meet any issue when using sf commands to write and
> read the serial flash.
> 
> Hi, Alexander,
> 
> 	Could you show me the detail commands and process when you meet
> such issue? Then I can try to reproduce on my board. 
> 

Alison,

Were you able to reproduce it?

York

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Fabio Estevam]

On Wed, Nov 4, 2015 at 6:19 AM, Alexander Stein
<alexander.stein@systec-electronic.com> wrote:
> When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog
> timeout might occur meanwhile. So pet the watchdog while operating on
> the flash.

I guess the same problem would occur when you do long file transfers
via TFTP, via USB, via eMMC, right?

Shouldn't you fix the watchdog timeout value instead? If I read this
thread correctly you set the watchdog timeout to be 1.5 s, which seems
to be too low.

Regards,

Fabio Estevam

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[York Sun]

On 12/04/2015 12:54 PM, Fabio Estevam wrote:
> On Wed, Nov 4, 2015 at 6:19 AM, Alexander Stein
> <alexander.stein@systec-electronic.com> wrote:
>> When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog
>> timeout might occur meanwhile. So pet the watchdog while operating on
>> the flash.
> 
> I guess the same problem would occur when you do long file transfers
> via TFTP, via USB, via eMMC, right?
> 
> Shouldn't you fix the watchdog timeout value instead? If I read this
> thread correctly you set the watchdog timeout to be 1.5 s, which seems
> to be too low.
> 

Exactly what I thought. So we either discourage using short period for watchdog,
or feed the dog in all long calls, not only SPI driver.

York

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[Alexander Stein]

Hi Fabio,

On Friday 04 December 2015 18:54:15, Fabio Estevam wrote:
> On Wed, Nov 4, 2015 at 6:19 AM, Alexander Stein
> <alexander.stein@systec-electronic.com> wrote:
> > When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog
> > timeout might occur meanwhile. So pet the watchdog while operating on
> > the flash.
> 
> I guess the same problem would occur when you do long file transfers
> via TFTP, via USB, via eMMC, right?

I didn't notice this problem with TFTP which takes ~3s. I don't have the opportunity to use USB oder eMMC on this hardware.

> Shouldn't you fix the watchdog timeout value instead? If I read this
> thread correctly you set the watchdog timeout to be 1.5 s, which seems
> to be too low.

You might be right, but there absolutely no way to change that timeout. It's _fixed_ in hardware. If you can't serve it, you got reset. It's that simple, no matter what.

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein at systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax:    +49 (0) 3765 38600-4100
 
Managing Directors:
	Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
	Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
	Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing

[York Sun]

On 11/04/2015 04:19 PM, Alexander Stein wrote:
> When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog
> timeout might occur meanwhile. So pet the watchdog while operating on
> the flash.
> 
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---

Applied to fsl-qoriq master. Awaiting upstream.

York