From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail02.prevas.se ([62.95.78.10]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1eQhET-0004Vf-CK for linux-mtd@lists.infradead.org; Sun, 17 Dec 2017 22:16:31 +0000 Subject: [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb Date: Sun, 17 Dec 2017 23:15:42 +0100 In-Reply-To: <20171217230032.30853780@bbrezillon> References: <7df7abb5-e666-c999-e449-75762b551ea5@prevas.dk> <20171212095119.475de032@xps13> <727489cf-d1f6-8777-c6f4-981127657c9d@prevas.dk> <20171212111227.4946cc15@xps13> <20171212120806.7c31463f@xps13> <20171212123523.48185f21@xps13> <75bd6b87-12ed-4003-262a-b1bd03a62cbd@prevas.dk> <20171212134706.49f3c57e@xps13> <2f16ce90-6e00-c95f-7a81-5603d9acf574@prevas.dk> <20171212143512.3b62d3f5@xps13> <48EEEC1C-954B-42E5-92BE-A00AD97A5789@prevas.dk> <20171212192327.57b1fa80@xps13> <9f578b28-ef3b-8e84-0a8c-b70c494efff0@prevas.dk> <20171213094105.73646658@xps13> <20171215182512.2449af9e@xps13> <45D7D798-BA86-41CD-AB56-156C1BD7FCC4@prevas.dk> <20171215201955.2431195c@xps13> <7892957c-273b-ea58-1d50-b35e70c69e02@prevas.dk> <20171217141916.04e377ab@bbrezillon> <461b45a8-de1f-0b54-567f-001ea30ee927@prevas.dk> <20171217230032.30853780@bbrezillon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Boris Brezillon CC: Miquel RAYNAL , ezequiel.garcia@free-electrons.com, linux-mtd@lists.infradead.org, "Kasper Revsbech (KREV)" From: =?ISO-8859-1?Q?Sean_Nyekj=E6r?= Message-ID: List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 17 December 2017 23:00:32 CET, Boris Brezillon wrote: >On Sun, 17 Dec 2017 22:47:26 +0100 >Sean Nyekjaer wrote: > >> Hi Boris and Miquel >> >>> =20 >> >>>> I also tried booting with ECC enabled and with that enabled the >> >>>> driver is unable to read the bbt and marked all blocks bad=2E =20 >> >>> And if I understand correctly, if you remove nand-ecc-mode =3D >"none" (or >> >>> set it to "hw"), the kernel fails to find the BBT, that is right? >=20 >> >> Yes=2E =20 >> >>> As I was not expecting such a quick answer, I did push another >patch >> >>> after sending my email that fixes an issue in mtdcore=2Ec, please >check >> >>> you have it (there are a few "fixup!" patches, and on top of them >you >> >>> must find one which is a well-formatted patch about >> >>> mtd_check_oob_ops())=2E =20 >> >> I have rebased on top of 9aee88a618f8 mtd: Fix mtd_check_oob_ops() >=20 >> >>> I learned that today: to get a prompt while all blocks are bad, >you can >> >>> add: >> >>> >> >>> chip->options |=3D NAND_SKIP_BBTSCAN; >> >>> >> >>> Before nand_scan_tail()=2E >> >>> >> >>> If you can reach a prompt with the failing configuration and when >you >> >>> will have the time, I will welcome a dump of the same area as >before >> >>> so we will try to understand what is wrong now ! :) =20 >> >> Nice one, a lot easier to read whats happens >> >> >> >> nanddump of BBT without ECC enabled: >> >> https://gist=2Egithub=2Ecom/anonymous/627e5be058ed93c106d61641f6aa5d= a0 >> >> >> >> nanddump of BBT with ECC enabled: >> >> https://gist=2Egithub=2Ecom/anonymous/76b3240f156c6547cf76d59f2aae49= fe >> >> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled=2E >> >> https://gist=2Egithub=2Ecom/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc= 85 >> >> >> >> Please let me know what traces you need to fix the ECC :-) =20 >> > The dumps look good (at least, the BBT pattern is correct, we have >the >> > number of ECC bytes we expect and they are where we expect them)=2E >> > >> > My gut feeling is that something is wrong with ECC (or something >related >> > to ECC) in u-boot=2E >> > >> > Can you try to let Linux create the BBT on its own and dump the >last >> > block as you did previously? >> > >> > So, to sum-up >> > >> > 1/ put the following in your DT >> > >> > nand-ecc-mode =3D "hw"; >> > nand-on-flash-bbt; >> > >> > 2/ scrub the NAND from u-boot and make sure you don't reboot after >that, >> > so that u-boot can't recreate its own BBT=2E >> > >> > 3/ Let Linux boot and dump the pages (in raw mode) where BBTs >created by >> > Linux are supposed to be (should be the same addresses as before) =20 >> Trace with nand scrub in uboot and ecc enabled: >> https://gist=2Egithub=2Ecom/anonymous/3ce389b9276fddbd46f59c89b99ee4ff >>=20 >> Same as above with "chip->options |=3D NAND_SKIP_BBTSCAN;" in the >marvell=20 >> nand driver >> https://gist=2Egithub=2Ecom/anonymous/3aed159b5a5ee22f27403fe79ba97400 >>=20 >> If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt pages)=20 >> they contain >> only 0xFF's as the kernel does not write to the blocks=2E >>=20 >> To me it seem a little bit difficult to say why the new marvell nand >driver >> (with ecc enabled) thinks all the freshly scrubbed blocks are bad=2E > >Ok, now I really need the dump without the -n option=2E It seems that >dumping in non-raw mode does not return the expected value=2E > How can I get the driver to write a bbt when it have marked all the blocks= bad? So I do a trace, without the -n option, with ecc enabled and NAND_SKIP_BBT= SCAN set? Is that what you need? /Sean