[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing
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, ®s->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, ®s->ipcr, (SEQID_WREN << QSPI_IPCR_SEQID_SHIFT) | 0); while (qspi_read32(priv->flags, ®s->sr) & QSPI_SR_BUSY_MASK)
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, ®s->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, ®s->ipcr, (SEQID_WREN << QSPI_IPCR_SEQID_SHIFT) | 0); while (qspi_read32(priv->flags, ®s->sr) & QSPI_SR_BUSY_MASK)
York
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
participants (4)
-
Alexander Stein -
Fabio Estevam -
Huan Wang -
York Sun