[PATCH/RFC] ARM: dts: marzen: Add FLASH node
Tudor Ambarus
tudor.ambarus at linaro.org
Fri Apr 7 00:16:43 PDT 2023
Hi, Geert,
On 4/3/23 17:29, Geert Uytterhoeven wrote:
> On Tue, Mar 21, 2023 at 4:01 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>> On Mon, Mar 20, 2023 at 7:57 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>>> On Mon, Mar 20, 2023 at 6:04 PM Tudor Ambarus <tudor.ambarus at linaro.org> 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 at glider.be>
>>>>> ---
>>>>> 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.
>
>> 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":
>
>> 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?
>
> After actively looking for more boards with CFI FLASHes, and finding one
> more board where FLASH probing fails on SMP, I dug deeper.
> Turns out they all have in common that (a) the CFI FLASH is located at
> physical address zero, and (b) the secondary CPU bringup code relies
> on mapping (by special hardware) the region at address zero to the
> CPU boot code...
>
> Hence fixing this involves making sure that accessing FLASH and bringing
> CPU cores online do not happen concurrently...
>
Would deferring probe for CFI work?
ta
More information about the linux-arm-kernel
mailing list