On 2/23/22 23:18, Dinh Nguyen wrote:
On 2/23/22 11:16, Marek Vasut wrote:
On 2/23/22 17:46, Dinh Nguyen wrote:
On 2/23/22 10:43, Marek Vasut wrote:
On 2/23/22 17:28, Dinh Nguyen wrote:
On 2/22/22 18:54, Marek Vasut wrote:
On 2/22/22 22:32, Dinh Nguyen wrote:
On 2/22/22 12:30, Marek Vasut wrote:
On 2/22/22 16:49, Dinh Nguyen wrote:
On 2/21/22 11:05, Marek Vasut wrote:
On 2/21/22 17:38, Dinh Nguyen wrote:
On 2/20/22 22:32, Marek Vasut wrote:
On SoCFPGA Gen5, DAC memcpy_fromio() in
cqspi_direct_read_execute()
leads to data abort, disable DAC to avoid triggering it:
Unhandled fault: imprecise external abort (0x1406) at
0x0400d3e9
[0400d3e9] *pgd=00000000
Signed-off-by: Marek Vasut <marex@xxxxxxx>
Cc: Dinh Nguyen <dinguyen@xxxxxxxxxx>
Cc: Pratyush Yadav <p.yadav@xxxxxx>
---
drivers/spi/spi-cadence-quadspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index b808c94641fa6..65f2c2449be09 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1870,7 +1870,7 @@ static const struct
cqspi_driver_platdata intel_lgm_qspi = {
};
static const struct cqspi_driver_platdata socfpga_qspi = {
- .quirks = CQSPI_NO_SUPPORT_WR_COMPLETION,
+ .quirks = CQSPI_DISABLE_DAC_MODE |
CQSPI_NO_SUPPORT_WR_COMPLETION,
};
static const struct cqspi_driver_platdata versal_ospi = {
Acked-by: Dinh Nguyen <dinguyen@xxxxxxxxxx>
Is this DAC really not working on socfpga gen5 or is there
some other issue ?
I don't know the answer to this question. What is the DAC in
the QSPI module and how do I go about testing it?
DAC = direct access.
How do you go about testing this -- compile kernel with/without
this patch, boot on SoCFPGA Gen5 with QSPI NOR attached, the
kernel crashes without this patch on imprecise external abort.
Hmm...I just tested v5.17-rc3 on a C5 board and QSPI looks to be
working fine:
[ 1.744489] spi-nor spi1.0: found n25q512ax3, expected mt25qu02g
[ 1.750534] dma-pl330 ffe01000.pdma: Reset Channel-0 CS-f
FTC-40000
[ 1.756941] spi-nor spi1.0: n25q512ax3 (65536 Kbytes)
[ 1.762369] 2 fixed-partitions partitions found on MTD device
ff705000.spi.0
[ 1.769425] Creating 2 MTD partitions on "ff705000.spi.0":
[ 1.774925] 0x000000000000-0x000000800000 : "Flash 0 Raw Data"
[ 1.781942] 0x000000800000-0x000008000000 : "Flash 0 jffs2
Filesystem"
[ 1.788468] mtd: partition "Flash 0 jffs2 Filesystem" extends
beyond the end of device "ff705000.spi.0" -- size truncated to
0x3800000
I wonder if we might be missing some clock enable somewhere.
Can you mail me the whole boot log ? (I'm using u-boot 2022.01 btw.)
I tested with U-Boot 2022.01 as well:
=> run nfsboot_dinh
Kernel image @ 0x1000000 [ 0x000000 - 0x54edd0 ]
## Flattened Device Tree blob at 02000000
Booting using the fdt blob at 0x2000000
Loading Device Tree to 09ff8000, end 09fffeb1 ... OK
Starting kernel ...
Deasserting all peripheral resets
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.17.0-rc3 (dinguyen@linux-builds1)
(arm-linux-gnue abihf-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04)
7.5.0, GNU ld (GNU Binutils for U buntu) 2.30) #1 SMP Wed Feb 23
08:51:18 CST 2022
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7),
cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT
aliasing instructio n cache
[ 0.000000] OF: fdt: Machine model: Altera SOCFPGA Cyclone V SoC
Development Kit
[ 0.000000] Memory policy: Data cache writealloc
This is weird.
One more thing, I have two SPI NORs on this CQSPI, one on each chip
select, do you think that can make any difference ?
Besides that, I used latest next for my tests, not latest linus tree.
Let me test on latest next.
Thank you
If you cannot reproduce it there, drop this patch and I'll revisit
this on my side.
Hmm...it doesn't look like the same error, but I'm getting this on the
-next. I disable QSPI and the error still shows up. I'll dig more into it.
[ 1.685301] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.17.0-rc5-next-20220222 #3
[ 1.692771] Hardware name: Altera SOCFPGA
[ 1.696771] Backtrace:
[ 1.699217] dump_backtrace from show_stack+0x20/0x24
[ 1.704277] r7:c0d03cc8 r6:c05fb6dc r5:c0b1d644 r4:60000093
[ 1.709919] show_stack from dump_stack_lvl+0x48/0x54
This looks like something else and it doesn't even come from the CQSPI,
maybe it is some temporary issue that's already fixed in the upcoming next.
