linux-kernel - Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface

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:   Wed, 2 Jan 2019 09:33:38 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Romain Perier <romain.perier@...il.com>
Cc:     Naga Sureshkumar Relli <naga.sureshkumar.relli@...inx.com>,
        Boris Brezillon <bbrezillon@...nel.org>,
        linux-mtd@...ts.infradead.org, peterpandong@...ron.com,
        linux-kernel@...r.kernel.org
Subject: Re: [LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm
 pl353 smc nand interface

Hi Romain,

Switching Boris address.

Romain Perier <romain.perier@...il.com> wrote on Fri, 21 Dec 2018
10:17:50 +0100:

> Hello,
> 
> I have rebased this patch onto 4.19.11. I use it on a Zynq7000-based
> board with a NAND chip Micron MT29F4G08ABADAH4, since ~2 weeks now.
> The only problem I have to report is that when I boot with an unchanged
> driver on my board, I get the following logs:
> 
> [    1.988797] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
> [    1.995184] nand: Micron MT29F4G08ABADAH4
> [    1.999187] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> [    2.402661] nand: timeout while waiting for chip to become ready
> [    2.408665] nand: timing mode 5 not acknowledged by the NAND chip
> [    2.416251] Bad block table not found for chip 0
> [    2.422278] Bad block table not found for chip 0
> [    2.426903] Scanning device for bad blocks
> [    2.431024] Bad eraseblock 0 at 0x000000000000
> [    2.435509] Bad eraseblock 1 at 0x000000020000
> [    2.439978] Bad eraseblock 2 at 0x000000040000
> [    2.444465] Bad eraseblock 3 at 0x000000060000
> [    2.448936] Bad eraseblock 4 at 0x000000080000
> [    2.453423] Bad eraseblock 5 at 0x0000000a0000
> [    2.457893] Bad eraseblock 6 at 0x0000000c0000
> [    2.462354] Bad eraseblock 7 at 0x0000000e0000
> [    2.466841] Bad eraseblock 8 at 0x000000100000
> [    2.471304] Bad eraseblock 9 at 0x000000120000
> [    2.475793] Bad eraseblock 10 at 0x000000140000
> [    2.480349] Bad eraseblock 11 at 0x000000160000
> 
> [...]
> 
> 
> After investigation, it seems that during the nand_scan phase, the NAND
> subsystem tests different timing modes on the NAND chip (mode 0 seems to be
> apply during reset, and then it tries to detect the best mode supported by the
> NAND chip). Only the mode 0 works here, trying the use the mode 5 resuls in an
> error (as you can see in the log) and a bad BBT detection. Both modes are
> supported by the NAND chip. In order to fix this, I had to put the nfc timing
> into the device node of the nfc, inside the DT (that's not a real fix, ihmo).

Thanks for testing! Indeed, the ->setup_data_interface() callback should be fixed.

> Except this, everything is working as expected. Everything is stable with correct
> performances.
> 
> If I can provide more informations, feel free to ask.

[...]

> > +static int pl353_setup_data_interface(struct mtd_info *mtd, int csline,
> > +				       const struct nand_data_interface *conf)
> > +{
> > +	struct nand_chip *chip = mtd_to_nand(mtd);
> > +	struct pl353_nand_controller *xnfc =
> > +		container_of(chip, struct pl353_nand_controller, chip);
> > +	const struct nand_sdr_timings *sdr;
> > +	u32 timings[7], mckperiodps;
> > +
> > +	if (csline == NAND_DATA_IFACE_CHECK_ONLY)
> > +		return 0;
> > +
> > +	sdr = nand_get_sdr_timings(conf);
> > +	if (IS_ERR(sdr))
> > +		return PTR_ERR(sdr);
> > +
> > +	/*
> > +	 * SDR timings are given in pico-seconds while NFC timings must be
> > +	 * expressed in NAND controller clock cycles.
> > +	 */
> > +	mckperiodps = NSEC_PER_SEC / clk_get_rate(xnfc->mclk);
> > +	mckperiodps *= 1000;
> > +	if (sdr->tRC_min <= 20000)
> > +		/*
> > +		 * PL353 SMC needs one extra read cycle in SDR Mode 5
> > +		 * This is not written anywhere in the datasheet but
> > +		 * the results observed during testing.
> > +		 */
> > +		timings[0] = DIV_ROUND_UP(sdr->tRC_min, mckperiodps) + 1;
> > +	else
> > +		timings[0] = DIV_ROUND_UP(sdr->tRC_min, mckperiodps);
> > +
> > +	timings[1] = DIV_ROUND_UP(sdr->tWC_min, mckperiodps);
> > +	/*
> > +	 * For all SDR modes, PL353 SMC needs tREA max value as 1,
> > +	 * Results observed during testing.
> > +	 */
> > +	timings[2] = PL353_TREA_MAX_VALUE;
> > +	timings[3] = DIV_ROUND_UP(sdr->tWP_min, mckperiodps);
> > +	timings[4] = DIV_ROUND_UP(sdr->tCLR_min, mckperiodps);
> > +	timings[5] = DIV_ROUND_UP(sdr->tAR_min, mckperiodps);
> > +	timings[6] = DIV_ROUND_UP(sdr->tRR_min, mckperiodps);
> > +	pl353_smc_set_cycles(timings);
> > +
> > +	return 0;
> > +}  
> 
> If I hack this function in order to limit the timings only to mode 0,
> everything works. Otherwise it hangs when it tries to apply mode 5.
> 

Maybe Naga is not using a chip compatible with mode 5 and did not ran
into this issue?


Thanks,
Miquèl