From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Egholm Nielsen Date: Mon, 10 Jan 2005 21:15:40 +0100 Subject: [U-Boot-Users] Re: JFFS2 images written from U-Boot unusable in Linux? (Round 2) In-Reply-To: References: <69A56150-6260-11D9-BA9B-000A95A5473A@gumstix.com> <29B9DA05-6264-11D9-AB91-000A95B312BA@onz.com> 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 Hi again, 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? BR, Martin Egholm >>>> # 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 ==== 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 >>> I think it's not u-boot's fault -- u-boot is actually being better >>> than the kernel about reading a damaged JFFS2 fs, where the kernel >>> refuses to. > Sounds resonable to assume yes - I just wondered whether U-Boot had some > sophisticated way of writing the image to the nand, that required some > specific kernel configuration.