From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Egholm Nielsen Date: Mon, 10 Jan 2005 09:50:19 +0100 Subject: [U-Boot-Users] Re: JFFS2 images written from U-Boot unusable in Linux? (Round 2) In-Reply-To: <29B9DA05-6264-11D9-AB91-000A95B312BA@onz.com> 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 > Did you try upgrading to the latest MTD tools? I'm running with mkfs.jffs2 from ELDK 3.1 and tried a similar version on target - namely revision 1.42. === 8< 8< 8< === >>> # 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 >> Martin, I noticed something similar recently when I upgraded kernels >> to a more recent one (not sure the exact version change), and it >> looked like actually the problem was that mtd-utils mkjffs2 tool was >> not agreeing with the kernel about how what the FS should look like, >> when dealing with entries which are both in the filetree being turned >> into the image, and also in a device_table.txt file (for example if >> you're specifying permission changes or ownership changes that way). >> The mtdutils tool seemed to be creating 2 physical copies of the file >> in the root_fs (which massively increased its size), and marking one >> of the copies as "erased" or something but not actually removing it. >> When the new kernel saw that, it borked. I fixed the problem >> temporarily by just chmod'ing the files I wanted to change perms on >> before running mkjffs2 -- but a better fix would be to resolve the bug >> in the tool instead. I haven't had a chance to do this yet. Anyway, But I have no such file. I'm just creating this simple root-filesystem... 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 Though I'm not sure what it means, or if has anything to do with this at all... >> 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. BR, Martin