linux-kernel - Re: Marvell NFC timings on CN9130

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 16 May 2023 19:25:38 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc:     Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Marvell NFC timings on CN9130

Hi Chris!

Chris.Packham@...iedtelesis.co.nz wrote on Tue, 16 May 2023 04:46:38
+0000:

> Hi Miquel, Thomas,
> 
> A hardware colleague reported a concern to me about a new design we have 
> using the Marvell CN9130 SoC (which I think was called Armada-8K before 
> they rebranded).
> 
> Basically their concern is that the tWC timing they observe is faster 
> (~18ns) than the documented minimum in the hardware datasheet for the 
> CN9130 (25ns). Aside from not meeting the datasheet spec we've not 
> observed any other issue (yet).

I would have expected the controller to support almost any kind of
timings, including SDR EDO mode 5. tWC is 25ns with mode 4, but 20 on
mode 5 (ONFI). So I believe you're running a system with a chip that is
not compatible with the fastest mode. If that is the case, it may
explain why you don't see errors with this chip: it may support
slightly faster timings than it advertises.

Anyway, if your findings are true, it means the current implementation
is slightly out of spec and the timing calculation might require to be
tweaked a little bit to reduce tWC.

> I notice in the marvell_nand.c driver that marvell_nfc_init() sets the 
> NAND Clock Frequency Select bit (0xF2440700:0) to 1 which runs according 
> to the datasheet the NAND flash at 400MHz . But the calculations in 
> marvell_nfc_setup_interface() use the value from 
> clk_get_rate(nfc->core_clk) which is still 250MHz so I'm wondering if 
> maybe the fact that the NAND flash is being run faster is having an 
> impact on timings that are calculated around the core_clk frequency.

What if you reset this bit? Do you observe different timings? I hope
you do, otherwise this is a dead-end.

The timings are derived from this clock but I remember seeing different
rates than the ones I expected with no obvious explanation (see the "*
2" in the calculation of period_ns and the comment right below). So
maybe this is due to the 400MHz vs. 250MHz issue you are reporting, or
there is an undocumented pre-scaler in-between (this is my original
guess).

> Do you think that the timings calculations should take the NAND Clock 
> Frequency Select setting into account?

There is not much about this clock in the manual, so if the clock is
feeding the logic of the controller generating the signals on the bus,
then yes. You can verify this with the test mentioned above.

Could you check the values set to tWP and tWH with and without the bit
and probe the signals in both cases? Maybe the "* 2" in the
period_ns calculation will vanish if we use 400MHz as input clock rather
than clk_get_rate() (or better, expose the bit as a mux-clock and use
it to tell the CCF the right frequency) and you'll get a sharper tWC in
the end, which hopefully should match the spec this time.

Thanks,
Miquèl