From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Egholm Nielsen Date: Wed, 12 Jan 2005 14:46:44 +0100 Subject: [U-Boot-Users] Re: JFFS2 images written from U-Boot unusable in Linux? (Round 2) In-Reply-To: <41E5183D.1020604@intracom.gr> References: <69A56150-6260-11D9-BA9B-000A95A5473A@gumstix.com> <29B9DA05-6264-11D9-AB91-000A95B312BA@onz.com> <41E5183D.1020604@intracom.gr> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de >>>>>> # mount -t jffs2 /dev/mtdblock0 /mnt >>>>>> jffs2: Erase block size too small (16KiB). Using virtual blocks >>>>>> size (32KiB) instead >>>>>> Cowardly refusing to erase blocks on filesystem with no valid >>>>>> JFFS2 nodes >>>>>> empty_blocks 0, bad_blocks 5, c->nr_blocks 2048 >>>>>> mount: Mounting /dev/mtdblock0 on /mnt failed: Invalid argument >> New information entered the scene: I tried another (identical) board >> today having none of the "Bad eraseblock" messages from my Linux >> kernel. And then everything worked! >> Hence, my boardsupplier suggested that U-Boot "ignored" these "Bad >> eraseblock" that the NAND presumable was born with... What do you think? >> ==== 8< 8< 8< ==== >> >>> But I'm getting some info from the Kernel at startup: >>> Scanning device for bad blocks >>> Bad eraseblock 1 at 0x00004000 >>> Bad eraseblock 2 at 0x00008000 >>> Bad eraseblock 3 at 0x0000c000 >>> Bad eraseblock 4 at 0x00010000 >>> Bad eraseblock 5 at 0x00014000 >>> Bad eraseblock 6 at 0x00018000 >>> Bad eraseblock 7 at 0x0001c000 >>> Bad eraseblock 1600 at 0x01900000 > NAND support is currently broken when bad blocks are present. > Will sent patches shortly dealing with the problems... Aahaaa! That explains a bit (alot)! :-) Is this also broken in U-Boot 1.1.2 or just CVS? Any estimates on when - months? ;-) Thanks for the super info! Martin