On Mon, Mar 20, 2023 at 7:57 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> On Mon, Mar 20, 2023 at 6:04 PM Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> wrote:
> > Vignesh used to review CFI code, maybe he can intervene. I've never
> > worked with CFI, but I can try to help. I'll need more debug data though.
> >
> > On 3/20/23 16:43, Geert Uytterhoeven wrote:
> > > Add a device node for the Spansion S29GL512N NOR FLASH on the Marzen
> > > development board.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> > > ---
> > > Although the S29GL512N is a CFI FLASH, using "cfi-flash" instead of
> > > "mtd-rom" does not work:
> > > 1. Probing fails with "physmap-flash 0.flash: map_probe failed",
> >
> > I would first try to understand why the probe fails.
>
> With debug code added, I saw that cfi_probe_chip() fails because
> cfi_qry_mode_on() returns zero. Printing actual vs. expected values
> in map_word_equal() showed that nothing was read (all 0xff, IIRC).
I misremembered:
physmap-flash 0.flash: physmap platform flash device: [mem
0x00000000-0x03ffffff]
cfi_qry_present:238: 0x5151 vs. 0xe0
cfi_qry_present:238: 0x5151 vs. 0xe0
cfi_qry_present:238: 0x5151 vs. 0xe0
cfi_qry_present:238: 0x5151 vs. 0xe0
cfi_qry_present:238: 0x5151 vs. 0xe0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x51 vs. 0xe0
cfi_qry_present:238: 0x51 vs. 0xe0
cfi_qry_present:238: 0x51 vs. 0xe0
cfi_qry_present:238: 0x51 vs. 0xe0
cfi_qry_present:238: 0x51 vs. 0xe0
cfi_qry_present:238: 0x51 vs. 0x0
cfi_qry_present:238: 0x51 vs. 0x0
cfi_qry_present:238: 0x51 vs. 0x0
cfi_qry_present:238: 0x51 vs. 0x0
cfi_qry_present:238: 0x51 vs. 0x0
physmap-flash 0.flash: map_probe failed
I suddenly remembered I have a different board (APE6-EVM), where
the CFI-FLASH stopped working after adding support for secondary
CPUs. I always thought that was a hardware quirk...
Turns out the CFI-FLASH on Marzen (quad Cortex-A9) is detected when
booting with "nosmp":
physmap-flash 0.flash: physmap platform flash device: [mem
0x00000000-0x03ffffff]
cfi_qry_present:238: 0x5151 vs. 0x51
cfi_qry_present:238: 0x5151 vs. 0x51
cfi_qry_present:238: 0x5151 vs. 0x51
cfi_qry_present:238: 0x5151 vs. 0x1c0
cfi_qry_present:238: 0x5151 vs. 0x1c0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x0
cfi_qry_present:238: 0x5151 vs. 0x6002
cfi_qry_present:238: 0x5151 vs. 0x6002
cfi_qry_present:238: 0x5151 vs. 0x6002
cfi_qry_present:238: 0x5151 vs. 0x6002
cfi_qry_present:238: 0x5151 vs. 0x6002
0.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer
ID 0x000001 Chip ID 0x002301
Amd/Fujitsu Extended Query Table at 0x0040
Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
3 fixed-partitions partitions found on MTD device 0.flash
Creating 3 MTD partitions on "0.flash":
0x000000000000-0x000000040000 : "uboot"
0x000000040000-0x000000080000 : "uboot-env"
0x000000080000-0x000004000000 : "flash"
My first guess was that the probing process is migrated to a different
CPU core during probing, but printing smp_processor_id() didn't
confirm that; it's just running on a different CPU core than CPU0.
Wrapping the body of cfi_qry_mode_on() inside a get_cpu()/put_cpu()
pair to prevent migration also didn't fix it.
Is CFI-FLASH known-broken on SMP?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
