From zheng wei Tue Apr 5 02:15:22 2005 From: zheng wei (zheng wei) Date: Tue, 5 Apr 2005 09:15:22 +0800 Subject: [Yaffs] I want to port YAFFS2 to my S3c2410... Message-ID: I want to port YAFFS2 to my S3c2410... My ARM linux is MIZI 2.4.20 Can it run? How to get help? What version of MTD is required? Thanks... -- ---------- jeanwelly Email: jeanwelly@gmail.com China From zheng wei Tue Apr 5 02:15:22 2005 From: zheng wei (zheng wei) Date: Tue, 5 Apr 2005 09:15:22 +0800 Subject: [Yaffs] I want to port YAFFS2 to my S3c2410... Message-ID: I want to port YAFFS2 to my S3c2410... My ARM linux is MIZI 2.4.20 Can it run? How to get help? What version of MTD is required? Thanks... -- ---------- jeanwelly Email: jeanwelly@gmail.com China From manningc2@actrix.gen.nz Tue Apr 5 04:32:21 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Tue, 5 Apr 2005 15:32:21 +1200 Subject: [Yaffs] I want to port YAFFS2 to my S3c2410... In-Reply-To: References: Message-ID: <20050405033259.2D65D15C0F@desire.actrix.co.nz> On Tuesday 05 April 2005 13:15, zheng wei wrote: > I want to port YAFFS2 to my S3c2410... > My ARM linux is MIZI 2.4.20 > > Can it run? How to get help? What version of MTD is required? > Thanks... There are a few points worth noting: 1) If you are using NAND with 512 byte pages, then you do not need YAFFS2= =20 (you can use YAFFS1) though you can use YAFFS2 with the backward=20 compatability mode.=20 If your NAND has 2Kbyte pages then you need YAFFS2. 2) The mtd does not suipport older kernels any more (I think you need at=20 least 2.4.27). You could however back port the few features required. I d= id=20 this for a 2.4.18 system to do some RAM-based testing and it was quite=20 trivial. 3) I suggest you go look at the Balloon stuff:=20 http://balloonboard.org/pipermail/balloon/2004-November/000214.html http://www.aleph1.co.uk/yaffs/yaffs-rootfs-howto.html -- CHarles From chao.xie@intel.com Tue Apr 5 07:32:09 2005 From: chao.xie@intel.com (Xie, Chao) Date: Tue, 5 Apr 2005 14:32:09 +0800 Subject: [Yaffs] What should i do when i want to mount a yaffs as root file system Message-ID: <571ACEFD467F7749BC50E0A98C17CDD80659AE47@pdsmsx403> This is a multi-part message in MIME format. ------_=_NextPart_001_01C539A9.3219B0B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I use mkyaffsimage to make a yaffs image and copy the yaffs source files to the kernel. I compile the kernel with yaffs support and boot it, but the yaffs file system can not be mounted. I set CONFIG_CMDLINE=3D"root=3D/dev/mtdblock2 = rootfstype=3Dyaffs ip=3Doff console=3DttyS0,115200 mem=3D64M" The situation is same when I want to mount it in shell. I tried "mount -t yaffs /dev/mtd2 /mnt" and "mount -t yaffs /dev/mtdblock2 /mnt". Both commands report that "No such device" In fact I can mount jffs2 ad root file system. I have disabled the ECC in the NAND driver. The kernel I used is 2.6.9. =20 =20 Best Regards Chao =20 ------_=_NextPart_001_01C539A9.3219B0B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

     = ;    I use mkyaffsimage to make a yaffs image and copy the yaffs source files = to the kernel. I compile the kernel with yaffs support and boot it, but the = yaffs file system can not be mounted.

     = ;    I set CONFIG_CMDLINE=3D”root=3D/dev/mtdblock2 rootfstype=3Dyaffs = ip=3Doff console=3DttyS0,115200 mem=3D64M”

     = ;   The situation is same when I want to mount it in shell. I tried = “mount –t yaffs /dev/mtd2 /mnt” and “mount –t yaffs /dev/mtdblock2 = /mnt”. Both commands report that “No such device”

     = ;    In fact I can mount jffs2 ad root file system. I have disabled the ECC = in the NAND driver. The kernel I used is 2.6.9.

 

 

Best Regards

Chao

 

------_=_NextPart_001_01C539A9.3219B0B8-- From manningc2@actrix.gen.nz Wed Apr 6 02:13:22 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Wed, 6 Apr 2005 13:13:22 +1200 Subject: [Yaffs] Some recent CVS changes Message-ID: <20050406011357.47A324207@blood.actrix.co.nz> Hi YAFFSers I have done some recent changes: 1) linux-kernel/... :Added a rudimentary kernel patch-in script for 2.6.x= =20 kernels. My main box is still running 2.4.18 (8-O) which has limited the=20 testing a bit... must really get switched to 2.6.x. I have done **some**= =20 testing on this, but it is likely flakey at present. What it does is cre= ates=20 softlinks/symlinks from the kernel tree to a yaffs tree. It also modifies= the=20 fs/Kconfig file to include the yaffs Kconfig. I will do some more testing= ,=20 but any improvements/suggestions very welcome. 2) yaffs_guts.c: Set nErasedBlocks to zero during initialisation. This fi= xed=20 some problems with remounting a file system if the yaffs_Device structure= was=20 not reinitialised. 3) yaffs_fs.c: Added short op caching to the Linux VFS wrapper. This can=20 vastly improve performance of short reads & writes. -- Charles From zheng wei Thu Apr 7 10:45:10 2005 From: zheng wei (zheng wei) Date: Thu, 7 Apr 2005 17:45:10 +0800 Subject: [Yaffs] Error found when mounting a NANDFlash block as yaffs Message-ID: I can't figure out what caused this error? Any comments are welcome. linux command line is: "noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc console=3Dtty"MACH_TYPE =3D 193 NOW, Booting Linux...... Uncompressing Linux........................................................= . do.Linux version 2.4.18-rmk7-pxa1 (root@localhost.localdomain) (gcc version 2.95.24CPU: ARM/CIRRUS Arm920Tsid(wb) revision 0 Machine: Samsung-SMDK2410 On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc consol= e=3DttyS0 DEBUG: timer count 15626 Console: colour dummy device 80x30 Calibrating delay loop... 99.94 BogoMIPS Memory: 64MB =3D 64MB total Memory: 62540KB available (1416K code, 434K data, 76K init) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket CPU clock =3D 200.000 Mhz, HCLK =3D 100.000 Mhz, PCLK =3D 50.000 Mhz Initializing S3C2410 buffer pool for DMA workaround S3C2410 USB Controller Core Initialized eth0: cs8900 rev K(3.3 Volts) found at 0xd0000300 cs89x0 media RJ-45, IRQ 37 get_random_bytes called before random driver initialization usbctl: Opened for usb-eth usbctl: Started for usb-eth Starting kswapd devfs: v1.10 (20020120) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 ttyS%d0 at I/O 0x50000000 (irq =3D 52) is a S3C2410 ttyS%d1 at I/O 0x50004000 (irq =3D 55) is a S3C2410 ttyS%d2 at I/O 0x50008000 (irq =3D 58) is a S3C2410 Console: switching to colour frame buffer device 30x40 Installed S3C2410 frame buffer pty: 256 Unix98 ptys configured s3c2410-ts initialized S3C2410 Real Time Clock Driver v0.1 block: 128 slots per queue, batch=3D32 Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=3D= xx loop: loaded (max 8 devices) SCSI subsystem driver Revision: 1.00 scsi0 : SCSI host adapter emulation for IDE ATAPI devices UDA1341 audio driver initialized flash device information ec 76 NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V) Creating 5 MTD partitions on "NAND 64MiB 3,3V": 0x00000000-0x00020000 : "loader" 0x00020000-0x00030000 : "param" 0x00030000-0x001f0000 : "kernel" 0x00200000-0x00400000 : "root" 0x00400000-0x03ef8000 : "usr" this is the result of add_mtd_partitions 0 usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-ohci.c: USB OHCI at membase 0xe9000000, IRQ 26 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found port #1 suspened! port #0 alived! hub.c: 1 port detected usb.c: registered new driver usblp printer.c: v0.8:USB Printer Device Class driver Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com zw:Read first block, super.magic is28cd3d45 VFS: Mounted root (cramfs filesystem). Mounted devfs on /dev Freeing init memory: 76K zw: mount /etc as ramfs zw: re-create the /etc/mtab entries zw: /bin/mount -f -t cramfs -o remount,ro /dev/mtdblock/3 / zw: /sbin/insmod -f /lib/yaffs.o zw: /bin/mount -t yaffs /dev/mtdblock/4 /usr yaffs: dev is 7940 name is "1f:04" Unable to handle kernel NULL pointer dereference at virtual address 0000000= 4 pgd =3D c3eb4000 *pgd =3D 00000000, *pmd =3D 00000000 Internal error: Oops: ffffffff CPU: 0 pc : [] lr : [] Not tainted sp : c3ebbbc4 ip : c3dac65c fp : c3ebbbd0 r10: 0000c6a4 r9 : 00000004 r8 : 00000635 r7 : c3e12000 r6 : c3ebbbf4 r5 : c3dac640 r4 : c3ddc5dc r3 : 00000000 r2 : c3ddc630 r1 : c3dac640 r0 : c3ddc5dc Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user Control: C000317F Table: 33EB4000 DAC: 00000015 Process mount (pid: 18, stackpage=3Dc3ebb000) Stack: (0xc3ebbbb4 to 0xc3ebc000) bba0: c4886940 c4886b70 200000= 13 bbc0: ffffffff c3ebbe2c c3ebbbd4 c4886940 c4886b1c 00000001 00000636 c3ebbb= ec bbe0: c3e2b1a0 00000000 00000001 ffd00000 c1e4030b 00000001 00000102 6f70ff= ff bc00: 2e726577 006c6d78 00000000 00000000 00000000 00000000 00000000 000000= 00 bc20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000= 00 bc40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000= 00 bc60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000= 00 bc80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000= 00 bca0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000= 00 bcc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000= 00 bce0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffff00= 00 bd00: 000081ed 00000000 00000000 4cfa5e7d 4cfa5e7d 4cfa5e7d 00000000 ffffff= ff bd20: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff= ff bd40: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff= ff bd60: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff= ff bd80: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff= ff bda0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff= ff bdc0: 00000000 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff= ff bde0: ffffffff ffffffff ffffffff ffffffff ffffffff ffd00000 030bffff e457a9= 66 be00: c3fff3c1 00000000 000041b6 c3e12000 c0374c00 00000200 00000000 c48892= 58 be20: c3ebbe48 c3ebbe30 c48873a4 c4886350 00000000 c3e12000 00000d14 c3ebbe= 70 be40: c3ebbe4c c4881a64 c488710c c0374c00 c0374c44 c039b160 00001f04 ffffff= ea be60: 00000000 c3ebbe80 c3ebbe74 c4881bb4 c48817ec c3ebbed8 c3ebbe84 c00500= e8 be80: c4881b9c c3ebbe94 00000003 c3e13000 c4889414 c3e4ab20 c02ee360 c3e040= 00 bea0: c02ee3e0 c3e04000 00000009 00000001 00000000 c02ee3e0 c4889414 c3e130= 00 bec0: c3e04000 c3e05000 c3e04000 c3ebbefc c3ebbedc c00506f0 c004fec0 c3ebbf= 2c bee0: 00000000 c3ebbf2c 00000000 c039c000 c3ebbf20 c3ebbf00 c0062bf0 c00506= 3c bf00: 00000000 00000000 c3ebbf2c 00000000 c039c000 c3ebbf70 c3ebbf24 c0062f= 44 bf20: c0062bdc c3e04000 c3e13000 c3ebd1c0 c02ee320 c3e13000 00001000 000010= 00 bf40: 00000009 00000001 00000000 00000000 0204de50 c039c000 c0ed0000 c3eba0= 00 bf60: bfffffbe c3ebbfa4 c3ebbf74 c0062ffc c0062df0 c3e13000 c3e13000 c3e040= 00 bf80: c3e05000 0204fe88 00000000 c0ed0000 00000015 c001b7c4 00000000 c3ebbf= a8 bfa0: c001b640 c0062f70 0204fe88 c0021728 0204de50 0204fe78 bfffffbe c0ed00= 00 bfc0: 0204fe88 00000000 c0ed0000 00000000 0204fe78 00000000 bfffffbe bffffe= e8 bfe0: 4009eb90 bffff8a4 0201e178 4009eb9c 60000010 0204de50 00000000 000420= 00 Backtrace: Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] r6 =3D 00000D14 r5 =3D C3E12000 r4 =3D 00000000 Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] r8 =3D C039C000 r7 =3D 00000000 r6 =3D C3EBBF2C r5 =3D 00000000 r4 =3D C3EBBF2C Function entered at [] from [] r8 =3D C039C000 r7 =3D 00000000 r6 =3D C3EBBF2C r5 =3D 00000000 r4 =3D 00000000 Function entered at [] from [] Function entered at [] from [] r8 =3D C001B7C4 r7 =3D 00000015 r6 =3D C0ED0000 r5 =3D 00000000 r4 =3D 0204FE88 Code: e581c01c e58cc004 e5903054 e2802054 (e583c004) Segmentation fault zw: exec /sbin/init console=3D/dev/co.sole init started: BusyBox v0.60.3 (2002.05.13-08:36+0000) multi-c=E9=B5=AFl bi= nary Starting pid 21, console /dev/console: '/etc/init.d/rcS' exec: /usr/etc/rc.local: No such file or dire=E9=B9=B4ory Waiting for enter to start '/bin/sh' (pid 24, terminal /dev/console) = =20 Please press Enter to activate this console. --=20 --------- jeanwelly Email: jeanwelly@gmail.com China --=20 --------- jeanwelly Email: jeanwelly@gmail.com China From zheng wei Sat Apr 9 04:17:33 2005 From: zheng wei (zheng wei) Date: Sat, 9 Apr 2005 11:17:33 +0800 Subject: [Yaffs] I want to format nand flash . How could I do? Message-ID: -- --------- jeanwelly Email: jeanwelly@gmail.com China From wookey@aleph1.co.uk Sat Apr 9 22:57:20 2005 From: wookey@aleph1.co.uk (Wookey) Date: Sat, 9 Apr 2005 22:57:20 +0100 Subject: [Yaffs] Re: I want to format nand flash . How could I do? In-Reply-To: References: Message-ID: <20050409215720.GI30861@court.aleph1.co.uk> +++ zheng wei [05-04-09 11:17 +0800]: 'formatting' nand flash for yaffs is not really meaningful. Clearing the flash of data effectively formats it. You can use the nandutils tools for this if using linux. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From manningc2@actrix.gen.nz Sun Apr 10 08:41:30 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Sun, 10 Apr 2005 19:41:30 +1200 Subject: [Yaffs] I want to format nand flash . How could I do? In-Reply-To: References: Message-ID: <20050410074154.D3B4415760@desire.actrix.co.nz> With YAFFS, an erased flash is considered "formatted". All you need to do= is=20 erase the flash. -- Charles From zheng wei Mon Apr 11 11:45:00 2005 From: zheng wei (zheng wei) Date: Mon, 11 Apr 2005 18:45:00 +0800 Subject: [Yaffs] YAFFS ECC error Message-ID: Hi, all I'm running yaffs+nandflash on my S3C2410, and I don't use the ecc check of MTD. I open the yaffs ecc. Errors found as follows: Revise the Makefile of yaffs: # USE_NANDECC = -DCONFIG_YAFFS_USE_NANDECC #zw USE_NANDECC = -DCONFIG_YAFFS_USE_NANDECC Copy the new yaffs.o to root_china/lib/, then use the nfs mode to log in. Then... #mount -t yaffs /dev/mtdblock/4 /usr oob : 0 0 d0 ff ff ff 47 1 3f ff 3 cc c1 aa a6 57 ecc_code : 99 aa 97 c3 ff 3 ecc_calc : aa 99 97 ff c3 3 oob : 0 0 d0 ff ff ff 45 1 99 aa 97 44 c1 c3 ff 3 ecc_code : a9 aa 6b c0 ff 33 ecc_calc : aa a9 6b ff c0 33 oob : 0 0 d0 ff ff ff 44 1 a9 aa 6b c0 c1 c0 ff 33 ecc_code : c ff f3 f3 ff 3 ecc_calc : ff c f3 ff f3 3 oob : 0 0 d0 ff ff ff 43 1 c ff f3 40 c1 f3 ff 3 ecc_code : a9 aa 57 cc ff ff ecc_calc : aa a9 57 ff cc ff oob : 0 0 d0 ff ff ff 42 1 a9 aa 57 c4 c1 cc ff ff ecc_code : f ff 33 a5 a6 67 ecc_calc : ff f 33 a6 a5 67 oob : 0 0 d0 ff ff ff 41 1 f ff 33 c8 c1 a5 a6 67 ecc_code : 96 aa 97 cc ff ff ecc_calc : aa 96 97 ff cc ff oob : 0 0 d0 ff ff ff 40 1 96 aa 97 4c c1 cc ff ff ecc_code : 33 ff 33 cf ff 33 ecc_calc : ff 33 33 ff cf 33 oob : 0 0 d0 ff ff ff 3f 1 33 ff 33 cc c1 cf ff 33 ecc_code : 5a a9 6b a5 a6 57 ecc_calc : a9 5a 6b a6 a5 57 oob : 0 0 d0 ff ff ff 3e 1 5a a9 6b 48 c1 a5 a6 57 ecc_code : cf fc c3 cf ff 33 ecc_calc : fc cf c3 ff cf 33 oob : 0 0 d0 ff ff ff 3d 1 cf fc c3 44 c1 cf ff 33 ecc_code : cc fc 3f 96 a6 ab ecc_calc : fc cc 3f a6 96 ab oob : 0 0 d0 ff ff ff 3c 1 cc fc 3f c0 c1 96 a6 ab ecc_code : 55 a9 a7 f3 ff 3 ecc_calc : a9 55 a7 ff f3 3 oob : 0 0 d0 ff ff ff 3b 1 55 a9 a7 40 c1 f3 ff 3 ecc_code : c ff f fc ff 33 ecc_calc : ff c f ff fc 33 oob : 0 0 d0 ff ff ff 3a 1 c ff f c4 c1 fc ff 33 ecc_code : 33 ff cf a9 a6 97 ecc_calc : ff 33 cf a6 a9 97 oob : 0 0 d0 ff ff ff 38 1 33 ff cf 4c c1 a9 a6 97 ecc_code : 30 ff f3 a6 a6 ab ecc_calc : ff 30 f3 a6 a6 ab oob : 0 0 d0 ff ff ff 37 1 30 ff f3 5c c1 a6 a6 ab ecc_code : 33 ff cf c0 ff f3 ecc_calc : ff 33 cf ff c0 f3 oob : 0 0 d0 ff ff ff 36 1 33 ff cf d8 c1 c0 ff f3 ecc_code : 33 ff 33 96 a6 a7 ecc_calc : ff 33 33 a6 96 a7 oob : 0 0 d0 ff ff ff 35 1 33 ff 33 d4 c1 96 a6 a7 ecc_code : 66 a9 97 96 a6 ab ecc_calc : a9 66 97 a6 96 ab oob : 0 0 d0 ff ff ff 32 1 66 a9 97 54 c1 96 a6 ab ecc_code : 59 a9 57 33 f0 3 ecc_calc : a9 59 57 f0 33 3 oob : 0 0 d0 ff ff ff 31 1 59 a9 57 58 c1 33 f0 3 ecc_code : 95 a9 57 33 f0 ff ecc_calc : a9 95 57 f0 33 ff oob : 0 0 d0 ff ff ff 30 1 95 a9 57 dc c1 33 f0 ff ecc_code : a5 a9 6b 56 a9 57 ecc_calc : a9 a5 6b a9 56 57 oob : 0 0 d0 ff ff ff 2f 1 a5 a9 6b 58 c1 56 a9 57 ecc_code : c3 ff 3 56 a9 a7 ecc_calc : ff c3 3 a9 56 a7 oob : 0 0 d0 ff ff ff 2e 1 c3 ff 3 dc c1 56 a9 a7 ecc_code : 59 a9 97 96 a6 ab ecc_calc : a9 59 97 a6 96 ab oob : 0 0 d0 ff ff ff 2d 1 59 a9 97 d0 c1 96 a6 ab ecc_code : 69 a9 6b 55 a9 67 ecc_calc : a9 69 6b a9 55 67 oob : 0 0 d0 ff ff ff 28 1 69 a9 6b d8 c1 55 a9 67 ecc_code : ff fc 33 ff ff cf ecc_calc : fc ff 33 ff ff cf oob : 0 0 d0 ff ff ff 26 1 ff fc 33 4c c1 ff ff cf ecc_code : 33 ff ff 55 a9 9b ecc_calc : ff 33 ff a9 55 9b oob : 0 0 d0 ff ff ff 25 1 33 ff ff 40 c1 55 a9 9b ecc_code : 56 a9 57 56 a9 5b ecc_calc : a9 56 57 a9 56 5b oob : 0 0 d0 ff ff ff 24 1 56 a9 57 c4 c1 56 a9 5b ecc_code : a6 aa 9b 33 f0 33 ecc_calc : aa a6 9b f0 33 33 oob : 0 0 d0 ff ff ff 23 1 a6 aa 9b 44 c1 33 f0 33 ecc_code : ff fc cf 3c f0 f ecc_calc : fc ff cf f0 3c f oob : 0 0 d0 ff ff ff 22 1 ff fc cf c0 c1 3c f0 f ecc_code : 66 a9 a7 56 a9 5b ecc_calc : a9 66 a7 a9 56 5b oob : 0 0 d0 ff ff ff 21 1 66 a9 a7 cc c1 56 a9 5b ecc_code : c ff f3 33 f0 ff ecc_calc : ff c f3 f0 33 ff oob : 0 0 d0 ff ff ff 20 1 c ff f3 48 c1 33 f0 ff ecc_code : c3 fc 3 55 a9 5b ecc_calc : fc c3 3 a9 55 5b oob : 0 0 d0 ff ff ff 1f 1 c3 fc 3 54 c1 55 a9 5b ecc_code : a6 aa 9b 56 a9 5b ecc_calc : aa a6 9b a9 56 5b oob : 0 0 d0 ff ff ff 1e 1 a6 aa 9b d0 c1 56 a9 5b ecc_code : a6 aa 97 96 a6 ab ecc_calc : aa a6 97 a6 96 ab oob : 0 0 d0 ff ff ff 1c 1 a6 aa 97 58 c1 96 a6 ab ecc_code : 3f ff ff 30 f0 f ecc_calc : ff 3f ff f0 30 f oob : 0 0 d0 ff ff ff 1b 1 3f ff ff d8 c1 30 f0 f ecc_code : 3f ff ff 55 a9 ab ecc_calc : ff 3f ff a9 55 ab oob : 0 0 d0 ff ff ff 19 1 3f ff ff 50 c1 55 a9 ab ecc_code : 96 aa a7 55 a9 97 ecc_calc : aa 96 a7 a9 55 97 oob : 0 0 d0 ff ff ff 18 1 96 aa a7 d4 c1 55 a9 97 ecc_code : a9 aa ab 56 a9 97 ecc_calc : aa a9 ab a9 56 97 oob : 0 0 d0 ff ff ff 15 1 a9 aa ab 4c c1 56 a9 97 ecc_code : a6 aa ab 0 f0 ff ecc_calc : aa a6 ab f0 0 ff oob : 0 0 d0 ff ff ff 14 1 a6 aa ab c8 c1 0 f0 ff ecc_code : 66 a9 67 0 f0 3 ecc_calc : a9 66 67 f0 0 3 oob : 0 0 d0 ff ff ff 13 1 66 a9 67 48 c1 0 f0 3 ecc_code : 30 ff 33 0 f0 3f ecc_calc : ff 30 33 f0 0 3f oob : 0 0 d0 ff ff ff 12 1 30 ff 33 cc c1 0 f0 3f ecc_code : c3 fc c3 3 f0 33 ecc_calc : fc c3 c3 f0 3 33 oob : 0 0 d0 ff ff ff 11 1 c3 fc c3 c0 c1 3 f0 33 ecc_code : 55 a9 6b 65 a9 5b ecc_calc : a9 55 6b a9 65 5b oob : 0 0 d0 ff ff ff 10 1 55 a9 6b 44 c1 65 a9 5b ecc_code : 30 ff 33 66 a9 97 ecc_calc : ff 30 33 a9 66 97 oob : 0 0 d0 ff ff ff f 1 30 ff 33 c0 c1 66 a9 97 ecc_code : a6 aa 67 6a a9 9b ecc_calc : aa a6 67 a9 6a 9b oob : 0 0 d0 ff ff ff e 1 a6 aa 67 44 c1 6a a9 9b ecc_code : 95 aa 67 a6 a6 a7 ecc_calc : aa 95 67 a6 a6 a7 oob : 0 0 d0 ff ff ff d 1 95 aa 67 48 c1 a6 a6 a7 ecc_code : 33 ff 33 a6 a6 97 ecc_calc : ff 33 33 a6 a6 97 oob : 0 0 d0 ff ff ff c 1 33 ff 33 cc c1 a6 a6 97 ecc_code : 59 aa 9b 30 f0 3 ecc_calc : aa 59 9b f0 30 3 oob : 0 0 d0 ff ff ff 55 2 59 aa 9b dc c1 30 f0 3 ecc_code : a6 aa 57 30 f0 cf ecc_calc : aa a6 57 f0 30 cf oob : 0 0 d0 ff ff ff 4b 2 a6 aa 57 dc c1 30 f0 cf ecc_code : 59 a5 97 33 f0 f3 ecc_calc : a5 59 97 f0 33 f3 oob : 0 0 d0 ff ff ff 41 2 59 a5 97 c4 c1 33 f0 f3 ecc_code : c ff f 56 a9 6b ecc_calc : ff c f a9 56 6b oob : 0 0 d0 ff ff ff 37 2 c ff f 50 c1 56 a9 6b ecc_code : a9 aa 5b 56 a9 57 ecc_calc : aa a9 5b a9 56 57 oob : 0 0 d0 ff ff ff 2d 2 a9 aa 5b dc c1 56 a9 57 ecc_code : 3c ff c3 56 a9 97 ecc_calc : ff 3c c3 a9 56 97 oob : 0 0 d0 ff ff ff 23 2 3c ff c3 48 c1 56 a9 97 ecc_code : c ff 3 56 a9 9b ecc_calc : ff c 3 a9 56 9b oob : 0 0 d0 ff ff ff 19 2 c ff 3 5c c1 56 a9 9b ecc_code : 65 aa 5b 55 a9 9b ecc_calc : aa 65 5b a9 55 9b oob : 0 0 d0 ff ff ff f 2 65 aa 5b cc c1 55 a9 9b ecc_code : 6a a9 6b 33 f0 33 ecc_calc : a9 6a 6b f0 33 33 oob : 0 0 d0 ff ff ff 7 2 6a a9 6b 5c c1 33 f0 33 ecc_code : 99 aa 6b 33 f0 3f ecc_calc : aa 99 6b f0 33 3f oob : 0 0 d0 ff ff ff fb 2 99 aa 6b 70 c1 33 f0 3f ecc_code : 30 ff f3 56 a9 5b ecc_calc : ff 30 f3 a9 56 5b oob : 0 0 d0 ff ff ff f1 2 30 ff f3 68 c1 56 a9 5b ecc_code : 96 aa 67 33 f0 3f ecc_calc : aa 96 67 f0 33 3f oob : 0 0 d0 ff ff ff e7 2 96 aa 67 f8 c1 33 f0 3f ecc_code : 5a a9 ab 30 f0 33 ecc_calc : a9 5a ab f0 30 33 oob : 0 0 d0 ff ff ff dd 2 5a a9 ab ec c1 30 f0 33 ecc_code : 5a aa 67 30 f0 c3 ecc_calc : aa 5a 67 f0 30 c3 oob : 0 0 d0 ff ff ff d3 2 5a aa 67 78 c1 30 f0 c3 ecc_code : 3f fc cf 55 a9 ab ecc_calc : fc 3f cf a9 55 ab oob : 0 0 d0 ff ff ff c9 2 3f fc cf f4 c1 55 a9 ab ecc_code : a6 aa 6b 30 f0 3 ecc_calc : aa a6 6b f0 30 3 oob : 0 0 d0 ff ff ff bf 2 a6 aa 6b 60 c1 30 f0 3 ecc_code : 3c ff cf 55 a9 ab ecc_calc : ff 3c cf a9 55 ab oob : 0 0 d0 ff ff ff b5 2 3c ff cf 78 c1 55 a9 ab ecc_code : c ff 3 30 f0 f3 ecc_calc : ff c 3 f0 30 f3 oob : 0 0 d0 ff ff ff ab 2 c ff 3 78 c1 30 f0 f3 ecc_code : 3f ff f3 30 f0 ff ecc_calc : ff 3f f3 f0 30 ff oob : 0 0 d0 ff ff ff a1 2 3f ff f3 60 c1 30 f0 ff ecc_code : c3 ff ff 33 f0 3f ecc_calc : ff c3 ff f0 33 3f oob : 0 0 d0 ff ff ff 97 2 c3 ff ff 68 c1 33 f0 3f ecc_code : 56 a9 a7 30 f0 33 ecc_calc : a9 56 a7 f0 30 33 oob : 0 0 d0 ff ff ff 8d 2 56 a9 a7 e4 c1 30 f0 33 ecc_code : c ff f 30 f0 3 ecc_calc : ff c f f0 30 3 oob : 0 0 d0 ff ff ff 83 2 c ff f 70 c1 30 f0 3 ecc_code : 3f ff f 55 a9 6b ecc_calc : ff 3f f a9 55 6b oob : 0 0 d0 ff ff ff 79 2 3f ff f 58 c1 55 a9 6b ecc_code : 96 aa 97 30 f0 f ecc_calc : aa 96 97 f0 30 f oob : 0 0 d0 ff ff ff 6f 2 96 aa 97 c8 c1 30 f0 f ecc_code : 0 fc 33 55 a9 67 ecc_calc : fc 0 33 a9 55 67 oob : 0 0 d0 ff ff ff 65 2 0 fc 33 d0 c1 55 a9 67 ecc_code : 5a a5 ab 55 a9 97 ecc_calc : a5 5a ab a9 55 97 oob : 0 0 d0 ff ff ff 5b 2 5a a5 ab 48 c1 55 a9 97 ecc_code : f0 f3 ff 55 a9 97 ecc_calc : f3 f0 ff a9 55 97 oob : 0 0 d0 ff ff ff 51 2 f0 f3 ff 50 c1 55 a9 97 ecc_code : 59 a5 ab 55 a9 97 ecc_calc : a5 59 ab a9 55 97 oob : 0 0 d0 ff ff ff 47 2 59 a5 ab c0 c1 55 a9 97 ecc_code : 33 ff c3 30 f0 3 ecc_calc : ff 33 c3 f0 30 3 oob : 0 0 d0 ff ff ff 33 2 33 ff c3 dc c1 30 f0 3 ecc_code : 66 a9 97 56 a9 97 ecc_calc : a9 66 97 a9 56 97 oob : 0 0 d0 ff ff ff 29 2 66 a9 97 50 c1 56 a9 97 ecc_code : 3 ff f 33 f0 3 ecc_calc : ff 3 f f0 33 3 oob : 0 0 d0 ff ff ff 1f 2 3 ff f 58 c1 33 f0 3 # # mount -t yaffs /dev/mtdblock/4 /usr mount: Mounting /dev/mtdblock/4 on /usr failed: Device or resource busy # -- --------- jeanwelly Email: jeanwelly@gmail.com China From zheng wei Wed Apr 13 12:41:03 2005 From: zheng wei (zheng wei) Date: Wed, 13 Apr 2005 19:41:03 +0800 Subject: [Yaffs] Fwd: YAFFS ECC error In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: zheng wei Date: Apr 11, 2005 6:45 PM Subject: YAFFS ECC error To: yaffs@stoneboat.aleph1.co.uk Hi, all I'm running yaffs+nandflash on my S3C2410, and I don't use the ecc check of MTD. I open the yaffs ecc. Errors found as follows: Revise the Makefile of yaffs: # USE_NANDECC =3D -DCONFIG_YAFFS_USE_NANDECC #zw USE_NANDECC =3D -DCONFIG_YAFFS_USE_NANDECC Copy the new yaffs.o to root_china/lib/, then use the nfs mode to log in. Then... #mount -t yaffs /dev/mtdblock/4 /usr oob : 0 0 d0 ff ff ff 47 1 3f ff 3 cc c1 aa a6 57 ecc_code : 99 aa 97 c3 ff 3 ecc_calc : aa 99 97 ff c3 3 oob : 0 0 d0 ff ff ff 45 1 99 aa 97 44 c1 c3 ff 3 ecc_code : a9 aa 6b c0 ff 33 ecc_calc : aa a9 6b ff c0 33 oob : 0 0 d0 ff ff ff 44 1 a9 aa 6b c0 c1 c0 ff 33 ecc_code : c ff f3 f3 ff 3 ecc_calc : ff c f3 ff f3 3 oob : 0 0 d0 ff ff ff 43 1 c ff f3 40 c1 f3 ff 3 ecc_code : a9 aa 57 cc ff ff ecc_calc : aa a9 57 ff cc ff oob : 0 0 d0 ff ff ff 42 1 a9 aa 57 c4 c1 cc ff ff ecc_code : f ff 33 a5 a6 67 ecc_calc : ff f 33 a6 a5 67 oob : 0 0 d0 ff ff ff 41 1 f ff 33 c8 c1 a5 a6 67 ecc_code : 96 aa 97 cc ff ff ecc_calc : aa 96 97 ff cc ff oob : 0 0 d0 ff ff ff 40 1 96 aa 97 4c c1 cc ff ff ecc_code : 33 ff 33 cf ff 33 ecc_calc : ff 33 33 ff cf 33 oob : 0 0 d0 ff ff ff 3f 1 33 ff 33 cc c1 cf ff 33 ecc_code : 5a a9 6b a5 a6 57 ecc_calc : a9 5a 6b a6 a5 57 oob : 0 0 d0 ff ff ff 3e 1 5a a9 6b 48 c1 a5 a6 57 ecc_code : cf fc c3 cf ff 33 ecc_calc : fc cf c3 ff cf 33 oob : 0 0 d0 ff ff ff 3d 1 cf fc c3 44 c1 cf ff 33 ecc_code : cc fc 3f 96 a6 ab ecc_calc : fc cc 3f a6 96 ab oob : 0 0 d0 ff ff ff 3c 1 cc fc 3f c0 c1 96 a6 ab ecc_code : 55 a9 a7 f3 ff 3 ecc_calc : a9 55 a7 ff f3 3 oob : 0 0 d0 ff ff ff 3b 1 55 a9 a7 40 c1 f3 ff 3 ecc_code : c ff f fc ff 33 ecc_calc : ff c f ff fc 33 oob : 0 0 d0 ff ff ff 3a 1 c ff f c4 c1 fc ff 33 ecc_code : 33 ff cf a9 a6 97 ecc_calc : ff 33 cf a6 a9 97 oob : 0 0 d0 ff ff ff 38 1 33 ff cf 4c c1 a9 a6 97 ecc_code : 30 ff f3 a6 a6 ab ecc_calc : ff 30 f3 a6 a6 ab oob : 0 0 d0 ff ff ff 37 1 30 ff f3 5c c1 a6 a6 ab ecc_code : 33 ff cf c0 ff f3 ecc_calc : ff 33 cf ff c0 f3 oob : 0 0 d0 ff ff ff 36 1 33 ff cf d8 c1 c0 ff f3 ecc_code : 33 ff 33 96 a6 a7 ecc_calc : ff 33 33 a6 96 a7 oob : 0 0 d0 ff ff ff 35 1 33 ff 33 d4 c1 96 a6 a7 ecc_code : 66 a9 97 96 a6 ab ecc_calc : a9 66 97 a6 96 ab oob : 0 0 d0 ff ff ff 32 1 66 a9 97 54 c1 96 a6 ab ecc_code : 59 a9 57 33 f0 3 ecc_calc : a9 59 57 f0 33 3 oob : 0 0 d0 ff ff ff 31 1 59 a9 57 58 c1 33 f0 3 ecc_code : 95 a9 57 33 f0 ff ecc_calc : a9 95 57 f0 33 ff oob : 0 0 d0 ff ff ff 30 1 95 a9 57 dc c1 33 f0 ff ecc_code : a5 a9 6b 56 a9 57 ecc_calc : a9 a5 6b a9 56 57 oob : 0 0 d0 ff ff ff 2f 1 a5 a9 6b 58 c1 56 a9 57 ecc_code : c3 ff 3 56 a9 a7 ecc_calc : ff c3 3 a9 56 a7 oob : 0 0 d0 ff ff ff 2e 1 c3 ff 3 dc c1 56 a9 a7 ecc_code : 59 a9 97 96 a6 ab ecc_calc : a9 59 97 a6 96 ab oob : 0 0 d0 ff ff ff 2d 1 59 a9 97 d0 c1 96 a6 ab ecc_code : 69 a9 6b 55 a9 67 ecc_calc : a9 69 6b a9 55 67 oob : 0 0 d0 ff ff ff 28 1 69 a9 6b d8 c1 55 a9 67 ecc_code : ff fc 33 ff ff cf ecc_calc : fc ff 33 ff ff cf oob : 0 0 d0 ff ff ff 26 1 ff fc 33 4c c1 ff ff cf ecc_code : 33 ff ff 55 a9 9b ecc_calc : ff 33 ff a9 55 9b oob : 0 0 d0 ff ff ff 25 1 33 ff ff 40 c1 55 a9 9b ecc_code : 56 a9 57 56 a9 5b ecc_calc : a9 56 57 a9 56 5b oob : 0 0 d0 ff ff ff 24 1 56 a9 57 c4 c1 56 a9 5b ecc_code : a6 aa 9b 33 f0 33 ecc_calc : aa a6 9b f0 33 33 oob : 0 0 d0 ff ff ff 23 1 a6 aa 9b 44 c1 33 f0 33 ecc_code : ff fc cf 3c f0 f ecc_calc : fc ff cf f0 3c f oob : 0 0 d0 ff ff ff 22 1 ff fc cf c0 c1 3c f0 f ecc_code : 66 a9 a7 56 a9 5b ecc_calc : a9 66 a7 a9 56 5b oob : 0 0 d0 ff ff ff 21 1 66 a9 a7 cc c1 56 a9 5b ecc_code : c ff f3 33 f0 ff ecc_calc : ff c f3 f0 33 ff oob : 0 0 d0 ff ff ff 20 1 c ff f3 48 c1 33 f0 ff ecc_code : c3 fc 3 55 a9 5b ecc_calc : fc c3 3 a9 55 5b oob : 0 0 d0 ff ff ff 1f 1 c3 fc 3 54 c1 55 a9 5b ecc_code : a6 aa 9b 56 a9 5b ecc_calc : aa a6 9b a9 56 5b oob : 0 0 d0 ff ff ff 1e 1 a6 aa 9b d0 c1 56 a9 5b ecc_code : a6 aa 97 96 a6 ab ecc_calc : aa a6 97 a6 96 ab oob : 0 0 d0 ff ff ff 1c 1 a6 aa 97 58 c1 96 a6 ab ecc_code : 3f ff ff 30 f0 f ecc_calc : ff 3f ff f0 30 f oob : 0 0 d0 ff ff ff 1b 1 3f ff ff d8 c1 30 f0 f ecc_code : 3f ff ff 55 a9 ab ecc_calc : ff 3f ff a9 55 ab oob : 0 0 d0 ff ff ff 19 1 3f ff ff 50 c1 55 a9 ab ecc_code : 96 aa a7 55 a9 97 ecc_calc : aa 96 a7 a9 55 97 oob : 0 0 d0 ff ff ff 18 1 96 aa a7 d4 c1 55 a9 97 ecc_code : a9 aa ab 56 a9 97 ecc_calc : aa a9 ab a9 56 97 oob : 0 0 d0 ff ff ff 15 1 a9 aa ab 4c c1 56 a9 97 ecc_code : a6 aa ab 0 f0 ff ecc_calc : aa a6 ab f0 0 ff oob : 0 0 d0 ff ff ff 14 1 a6 aa ab c8 c1 0 f0 ff ecc_code : 66 a9 67 0 f0 3 ecc_calc : a9 66 67 f0 0 3 oob : 0 0 d0 ff ff ff 13 1 66 a9 67 48 c1 0 f0 3 ecc_code : 30 ff 33 0 f0 3f ecc_calc : ff 30 33 f0 0 3f oob : 0 0 d0 ff ff ff 12 1 30 ff 33 cc c1 0 f0 3f ecc_code : c3 fc c3 3 f0 33 ecc_calc : fc c3 c3 f0 3 33 oob : 0 0 d0 ff ff ff 11 1 c3 fc c3 c0 c1 3 f0 33 ecc_code : 55 a9 6b 65 a9 5b ecc_calc : a9 55 6b a9 65 5b oob : 0 0 d0 ff ff ff 10 1 55 a9 6b 44 c1 65 a9 5b ecc_code : 30 ff 33 66 a9 97 ecc_calc : ff 30 33 a9 66 97 oob : 0 0 d0 ff ff ff f 1 30 ff 33 c0 c1 66 a9 97 ecc_code : a6 aa 67 6a a9 9b ecc_calc : aa a6 67 a9 6a 9b oob : 0 0 d0 ff ff ff e 1 a6 aa 67 44 c1 6a a9 9b ecc_code : 95 aa 67 a6 a6 a7 ecc_calc : aa 95 67 a6 a6 a7 oob : 0 0 d0 ff ff ff d 1 95 aa 67 48 c1 a6 a6 a7 ecc_code : 33 ff 33 a6 a6 97 ecc_calc : ff 33 33 a6 a6 97 oob : 0 0 d0 ff ff ff c 1 33 ff 33 cc c1 a6 a6 97 ecc_code : 59 aa 9b 30 f0 3 ecc_calc : aa 59 9b f0 30 3 oob : 0 0 d0 ff ff ff 55 2 59 aa 9b dc c1 30 f0 3 ecc_code : a6 aa 57 30 f0 cf ecc_calc : aa a6 57 f0 30 cf oob : 0 0 d0 ff ff ff 4b 2 a6 aa 57 dc c1 30 f0 cf ecc_code : 59 a5 97 33 f0 f3 ecc_calc : a5 59 97 f0 33 f3 oob : 0 0 d0 ff ff ff 41 2 59 a5 97 c4 c1 33 f0 f3 ecc_code : c ff f 56 a9 6b ecc_calc : ff c f a9 56 6b oob : 0 0 d0 ff ff ff 37 2 c ff f 50 c1 56 a9 6b ecc_code : a9 aa 5b 56 a9 57 ecc_calc : aa a9 5b a9 56 57 oob : 0 0 d0 ff ff ff 2d 2 a9 aa 5b dc c1 56 a9 57 ecc_code : 3c ff c3 56 a9 97 ecc_calc : ff 3c c3 a9 56 97 oob : 0 0 d0 ff ff ff 23 2 3c ff c3 48 c1 56 a9 97 ecc_code : c ff 3 56 a9 9b ecc_calc : ff c 3 a9 56 9b oob : 0 0 d0 ff ff ff 19 2 c ff 3 5c c1 56 a9 9b ecc_code : 65 aa 5b 55 a9 9b ecc_calc : aa 65 5b a9 55 9b oob : 0 0 d0 ff ff ff f 2 65 aa 5b cc c1 55 a9 9b ecc_code : 6a a9 6b 33 f0 33 ecc_calc : a9 6a 6b f0 33 33 oob : 0 0 d0 ff ff ff 7 2 6a a9 6b 5c c1 33 f0 33 ecc_code : 99 aa 6b 33 f0 3f ecc_calc : aa 99 6b f0 33 3f oob : 0 0 d0 ff ff ff fb 2 99 aa 6b 70 c1 33 f0 3f ecc_code : 30 ff f3 56 a9 5b ecc_calc : ff 30 f3 a9 56 5b oob : 0 0 d0 ff ff ff f1 2 30 ff f3 68 c1 56 a9 5b ecc_code : 96 aa 67 33 f0 3f ecc_calc : aa 96 67 f0 33 3f oob : 0 0 d0 ff ff ff e7 2 96 aa 67 f8 c1 33 f0 3f ecc_code : 5a a9 ab 30 f0 33 ecc_calc : a9 5a ab f0 30 33 oob : 0 0 d0 ff ff ff dd 2 5a a9 ab ec c1 30 f0 33 ecc_code : 5a aa 67 30 f0 c3 ecc_calc : aa 5a 67 f0 30 c3 oob : 0 0 d0 ff ff ff d3 2 5a aa 67 78 c1 30 f0 c3 ecc_code : 3f fc cf 55 a9 ab ecc_calc : fc 3f cf a9 55 ab oob : 0 0 d0 ff ff ff c9 2 3f fc cf f4 c1 55 a9 ab ecc_code : a6 aa 6b 30 f0 3 ecc_calc : aa a6 6b f0 30 3 oob : 0 0 d0 ff ff ff bf 2 a6 aa 6b 60 c1 30 f0 3 ecc_code : 3c ff cf 55 a9 ab ecc_calc : ff 3c cf a9 55 ab oob : 0 0 d0 ff ff ff b5 2 3c ff cf 78 c1 55 a9 ab ecc_code : c ff 3 30 f0 f3 ecc_calc : ff c 3 f0 30 f3 oob : 0 0 d0 ff ff ff ab 2 c ff 3 78 c1 30 f0 f3 ecc_code : 3f ff f3 30 f0 ff ecc_calc : ff 3f f3 f0 30 ff oob : 0 0 d0 ff ff ff a1 2 3f ff f3 60 c1 30 f0 ff ecc_code : c3 ff ff 33 f0 3f ecc_calc : ff c3 ff f0 33 3f oob : 0 0 d0 ff ff ff 97 2 c3 ff ff 68 c1 33 f0 3f ecc_code : 56 a9 a7 30 f0 33 ecc_calc : a9 56 a7 f0 30 33 oob : 0 0 d0 ff ff ff 8d 2 56 a9 a7 e4 c1 30 f0 33 ecc_code : c ff f 30 f0 3 ecc_calc : ff c f f0 30 3 oob : 0 0 d0 ff ff ff 83 2 c ff f 70 c1 30 f0 3 ecc_code : 3f ff f 55 a9 6b ecc_calc : ff 3f f a9 55 6b oob : 0 0 d0 ff ff ff 79 2 3f ff f 58 c1 55 a9 6b ecc_code : 96 aa 97 30 f0 f ecc_calc : aa 96 97 f0 30 f oob : 0 0 d0 ff ff ff 6f 2 96 aa 97 c8 c1 30 f0 f ecc_code : 0 fc 33 55 a9 67 ecc_calc : fc 0 33 a9 55 67 oob : 0 0 d0 ff ff ff 65 2 0 fc 33 d0 c1 55 a9 67 ecc_code : 5a a5 ab 55 a9 97 ecc_calc : a5 5a ab a9 55 97 oob : 0 0 d0 ff ff ff 5b 2 5a a5 ab 48 c1 55 a9 97 ecc_code : f0 f3 ff 55 a9 97 ecc_calc : f3 f0 ff a9 55 97 oob : 0 0 d0 ff ff ff 51 2 f0 f3 ff 50 c1 55 a9 97 ecc_code : 59 a5 ab 55 a9 97 ecc_calc : a5 59 ab a9 55 97 oob : 0 0 d0 ff ff ff 47 2 59 a5 ab c0 c1 55 a9 97 ecc_code : 33 ff c3 30 f0 3 ecc_calc : ff 33 c3 f0 30 3 oob : 0 0 d0 ff ff ff 33 2 33 ff c3 dc c1 30 f0 3 ecc_code : 66 a9 97 56 a9 97 ecc_calc : a9 66 97 a9 56 97 oob : 0 0 d0 ff ff ff 29 2 66 a9 97 50 c1 56 a9 97 ecc_code : 3 ff f 33 f0 3 ecc_calc : ff 3 f f0 33 3 oob : 0 0 d0 ff ff ff 1f 2 3 ff f 58 c1 33 f0 3 # # mount -t yaffs /dev/mtdblock/4 /usr mount: Mounting /dev/mtdblock/4 on /usr failed: Device or resource busy # -- --------- jeanwelly Email: jeanwelly@gmail.com China --=20 --------- jeanwelly Email: jeanwelly@gmail.com China From laurie@aleph1.co.uk Wed Apr 13 12:50:22 2005 From: laurie@aleph1.co.uk (Laurie van Someren) Date: Wed, 13 Apr 2005 12:50:22 +0100 (BST) Subject: [Yaffs] Test message only - ignore me Message-ID: Please ignore this test message LvS -- Laurie van Someren at Aleph One Ltd Old Courthouse Bottisham CAMBRIDGE CB5 9BA UK T: +44 (0)1 223 811 679 F: +44 (0)1 223 812 713 http://www.aleph1.co..uk E:laurie@aleph1.co.uk From manningc2@actrix.gen.nz Wed Apr 13 20:59:31 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Thu, 14 Apr 2005 07:59:31 +1200 Subject: [Yaffs] Fwd: YAFFS ECC error In-Reply-To: References: Message-ID: <20050413195949.BCB4F15830@desire.actrix.co.nz> I only see mtd errors here. Since you're getting these errors during the mount it suggests that the N= AND=20 is full of garbage. Please erase the NAND and start again. Have you tried turning on more tracing in YAFFS.? Set yaffs_traceMask. -- Charles On Wednesday 13 April 2005 23:41, zheng wei wrote: > ---------- Forwarded message ---------- > From: zheng wei > Date: Apr 11, 2005 6:45 PM > Subject: YAFFS ECC error > To: yaffs@stoneboat.aleph1.co.uk > > > Hi, all > I'm running yaffs+nandflash on my S3C2410, and I don't use the ecc > check of MTD. I open the yaffs ecc. Errors found as follows: > > Revise the Makefile of yaffs: > # USE_NANDECC =3D -DCONFIG_YAFFS_USE_NANDECC #zw > USE_NANDECC =3D -DCONFIG_YAFFS_USE_NANDECC > > Copy the new yaffs.o to root_china/lib/, then use the nfs mode to log i= n. > Then... > #mount -t yaffs /dev/mtdblock/4 /usr > oob : 0 0 d0 ff ff ff 47 1 3f ff 3 cc c1 aa a6 57 > ecc_code : 99 aa 97 c3 ff 3 > ecc_calc : ff 3 f f0 33 3 > oob : 0 0 d0 ff ff ff 1f 2 3 ff f 58 c1 33 f0 3 > # > # mount -t yaffs /dev/mtdblock/4 /usr > mount: Mounting /dev/mtdblock/4 on /usr failed: Device or resource busy > # From zheng wei Sat Apr 16 07:40:17 2005 From: zheng wei (zheng wei) Date: Sat, 16 Apr 2005 14:40:17 +0800 Subject: [Yaffs] I want to use yaffs on 2.6.11. Message-ID: Hi, all I want to use yaffs on 2.6.11. The cpu is s3c2410 and the nand flash k9f1208. I am not sure about what work should be done to revise the mtd for yaffs. Additionally, I want to use yaffs as a root filesystem. Any suggestion is welcome. Thanks! --=20 --------- jeanwelly Email: jeanwelly@gmail.com China From Sergei.Sharonov@Halliburton.com Thu Apr 14 16:33:03 2005 From: Sergei.Sharonov@Halliburton.com (Sergei Sharonov) Date: Thu, 14 Apr 2005 10:33:03 -0500 Subject: [Yaffs] yaffs2 status Message-ID: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> Hi, I am working on ARM9/linux2.6.10 based system with a large (256 MByte) NAND storage. Currently the filesystem used is jffs2. Unfortunately the mount time is unacceptably long and I am looking for an alternative. Can anybody comment on status of YAFFS2? Note that version 2 is required since NAND page=20 size is 2 k. Thanks, Sergei Sharonov From wookey@aleph1.co.uk Sat Apr 16 20:53:20 2005 From: wookey@aleph1.co.uk (Wookey) Date: Sat, 16 Apr 2005 20:53:20 +0100 Subject: [Yaffs] Re: yaffs2 status In-Reply-To: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> References: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> Message-ID: <20050416195320.GD5964@xios> +++ Sergei Sharonov [05-04-14 10:33 -0500]: > Hi, > > I am working on ARM9/linux2.6.10 based system with a large > (256 MByte) NAND storage. Currently the filesystem used is jffs2. > Unfortunately the mount time is unacceptably long and I am > looking for an alternative. Can anybody comment on status > of YAFFS2? Note that version 2 is required since NAND page > size is 2 k. People are using YAFFS2 successfully. I'm not sure if any commercial products have actually shipped with it yet, but it is now tested and functional. For best mount-time splitting your flash into more than one partition is often smart so you can boot from a small partition and give user feedback whilst mounting a larger data partition. Obviously this doesn't suit all applications. We do have a plan for implementing checkpointing for much faster booting (under normal circumstances) but this work has not yet been sponsored by anyone. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From zheng wei Sun Apr 17 11:23:25 2005 From: zheng wei (zheng wei) Date: Sun, 17 Apr 2005 18:23:25 +0800 Subject: [Yaffs] Re: yaffs2 status In-Reply-To: <20050416195320.GD5964@xios> References: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> <20050416195320.GD5964@xios> Message-ID: I want to use yaffs on 2.6.11, my cpu is 2410. I am not sure whether I should update the MTD in 2.6.11. But now I found ECC in mtd can't work correctly on nandflash. Also I want to use yaffs as a root fs. How can I get started? Thanks for any idea. On 4/17/05, Wookey wrote: > +++ Sergei Sharonov [05-04-14 10:33 -0500]: > > Hi, > > > > I am working on ARM9/linux2.6.10 based system with a large > > (256 MByte) NAND storage. Currently the filesystem used is jffs2. > > Unfortunately the mount time is unacceptably long and I am > > looking for an alternative. Can anybody comment on status > > of YAFFS2? Note that version 2 is required since NAND page > > size is 2 k. >=20 > People are using YAFFS2 successfully. I'm not sure if any commercial prod= ucts > have actually shipped with it yet, but it is now tested and functional. >=20 > For best mount-time splitting your flash into more than one partition is > often smart so you can boot from a small partition and give user feedback > whilst mounting a larger data partition. Obviously this doesn't suit all > applications. >=20 > We do have a plan for implementing checkpointing for much faster booting > (under normal circumstances) but this work has not yet been sponsored by > anyone. >=20 > Wookey > -- > Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 > work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ >=20 > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs >=20 --=20 --------- jeanwelly Email: jeanwelly@gmail.com China From sergei.sharonov@halliburton.com Mon Apr 18 15:57:33 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Mon, 18 Apr 2005 14:57:33 +0000 (UTC) Subject: [Yaffs] Re: yaffs2 status References: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> <20050416195320.GD5964@xios> Message-ID: Hi, > For best mount-time splitting your flash into more than one partition is > often smart so you can boot from a small partition and give user feedback > whilst mounting a larger data partition. Obviously this doesn't suit all > applications. Can anybody post any reference numbers? For example it takes me 20+ minutes to mount 256 MByte NAND partion with a 200 MByte file on it when using jffs2. Any idea what I may gain by moving to yaffs2? Sergei Sharonov From nick@cecomputing.co.uk Mon Apr 18 17:30:15 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Mon, 18 Apr 2005 17:30:15 +0100 Subject: [Yaffs] Re: yaffs2 status In-Reply-To: Message-ID: > Hi, >=20 > > For best mount-time splitting your flash into more than one = partition is > > often smart so you can boot from a small partition and give=20 > user feedback > > whilst mounting a larger data partition. Obviously this doesn't suit = all > > applications. >=20 > Can anybody post any reference numbers? For example it takes me 20+ > minutes to mount 256 MByte NAND partion with a 200 MByte file on it > when using jffs2. > Any idea what I may gain by moving to yaffs2? >=20 These results are using yaffs1.=20 I expect the process to be faster using yaffs2 due to the faster = interface and smaller number of headers to scan. We have 128MByte nand chips fairly full and they don't take forever to = scan.=20 This is anecdotal but my impression is of the order of 10 secs. The poor boot time scaling of jffs2 and large amounts or ram used were = prime reasons why we sponsored the yaffs effort. We are very pleased with the results. I just asked one of the testers and he says that the mounting pause = during boot up is about 8 secs with 77MB used. Nick Bane --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.15 - Release Date: 16/04/2005 From wookey@aleph1.co.uk Mon Apr 18 18:35:07 2005 From: wookey@aleph1.co.uk (Wookey) Date: Mon, 18 Apr 2005 18:35:07 +0100 Subject: [Yaffs] Re: yaffs2 status In-Reply-To: References: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> <20050416195320.GD5964@xios> Message-ID: <20050418173507.GJ5964@xios> +++ Sergei Sharonov [05-04-18 14:57 +0000]: > Hi, > > > For best mount-time splitting your flash into more than one partition is > > often smart so you can boot from a small partition and give user feedback > > whilst mounting a larger data partition. Obviously this doesn't suit all > > applications. > > Can anybody post any reference numbers? For example it takes me 20+ > minutes to mount 256 MByte NAND partion with a 200 MByte file on it > when using jffs2. That does sound remarkably slow. But obviously it does depend a lot of the hardware speed - what is the platform? > Any idea what I may gain by moving to yaffs2? The main technical difference is that YAFFS doesn't need to read the body of each page (due to not having compression), only the OOB data, during initial boot scan. And the generally simpler code should be faster. Some ballpark figures reckon YAFFS(1) is 4 times as fast to boot per MB of flash, or twice as fast per meg of data (assuming the JFFS2 FS is compressed at 2:1, which is farily typical). (from http://www.aleph1.co.uk/talks/yaffs/mgp00025.html which came from collated posts to this list). YAFFS2 is up to twice as fast on read (with 2K pages and 16bit bus) - on 512byte pages and 8 bit bus it is same speed as YAFFS1. ecc checking can really slow things down if it is done in software not hardware - although that's primarily on writing, so not important for initial scan time. The best way to get some reliable numbers would of course be to try it - it should definately be at least twice as fast. We'd be interested to hear what you find. Ulitimately the solution to the problem that all log-structured filesystems have to scan the whole media on boot, and this takes time is checkpointing (storing intermediate, or shutdown, status), and smarter partitioning so you can start before scanning the whole media. The latter is available today - the former needs sponsoring. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From wookey@aleph1.co.uk Mon Apr 18 18:40:00 2005 From: wookey@aleph1.co.uk (Wookey) Date: Mon, 18 Apr 2005 18:40:00 +0100 Subject: [Yaffs] Re: yaffs2 status In-Reply-To: References: Message-ID: <20050418174000.GK5964@xios> +++ Nick Bane [05-04-18 17:30 +0100]: > > Hi, > > > > > For best mount-time splitting your flash into more than one partition is > > > often smart so you can boot from a small partition and give > > user feedback > > > whilst mounting a larger data partition. Obviously this doesn't suit all > > > applications. > > > > Can anybody post any reference numbers? For example it takes me 20+ > > minutes to mount 256 MByte NAND partion with a 200 MByte file on it > > when using jffs2. > > Any idea what I may gain by moving to yaffs2? > > > These results are using yaffs1. > I expect the process to be faster using yaffs2 due to the faster interface and smaller number of headers to scan. > We have 128MByte nand chips fairly full and they don't take forever to scan. > This is anecdotal but my impression is of the order of 10 secs. > The poor boot time scaling of jffs2 and large amounts or ram used were prime reasons why we sponsored the yaffs effort. > We are very pleased with the results. > > I just asked one of the testers and he says that the mounting pause during boot up is about 8 secs with 77MB used. That's with a 200Mhz Strongarm and software ecc, btw, for comparison. Another datapoint I have is a 400Mhz xscale and 64Mb of NAND flash using JFFS2. The root is a 56Mb partition and is completely full (2.7x compression). I reckon that takes ~30s for cold boot scan, but I haven't actually measured it. I haven't tried YAFFS on this hardware. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From sergei.sharonov@halliburton.com Mon Apr 18 18:54:14 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Mon, 18 Apr 2005 17:54:14 +0000 (UTC) Subject: [Yaffs] yaffs2 howto Message-ID: Hi, sorry if it is FAQ, but is there a howto for yaffs2? I've found only yaffs(1) Thanks, Sergei Sharonov From sergei.sharonov@halliburton.com Mon Apr 18 19:20:41 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Mon, 18 Apr 2005 18:20:41 +0000 (UTC) Subject: [Yaffs] Re: yaffs2 status References: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> <20050416195320.GD5964@xios> <20050418173507.GJ5964@xios> Message-ID: Hi, > > Can anybody post any reference numbers? For example it takes me 20+ > > minutes to mount 256 MByte NAND partion with a 200 MByte file on it > > when using jffs2. > > That does sound remarkably slow. But obviously it does depend a lot of the > hardware speed - what is the platform? at91rm9200 (arm9 @ 180 MHz) Clarification: mount returns after 1.5 minutes but then any (first) write or even ls takes 10..20 minutes. AFAIK a lot of work is left for gc thread after mount is done. I've also seen much worse numbers when the large file was saved via ftp. Node size? I have not investigated. > Some ballpark figures reckon YAFFS(1) is 4 times as fast to boot per MB of > flash, or twice as fast per meg of data (assuming the JFFS2 FS is > compressed at 2:1, which is farily typical). (from > http://www.aleph1.co.uk/talks/yaffs/mgp00025.html which came from collated > posts to this list). Hmm.. 8s/77MB seconds in yaffs case and 20m/200MB in jffs2 case is more then 4X ;-) > YAFFS2 is up to twice as fast on read (with 2K pages and 16bit bus) - > on 512byte > pages and 8 bit bus it is same speed as YAFFS1. That is good to know. I have a 100 Mb/s Ethernet and I need to be able to dump log data as fast as possible. > ecc checking can really slow things down if it is done in software not > hardware - although that's primarily on writing, so not important for > initial scan time. No hardware ECC here, but one would think 180 MIPS should mitigate that. > The best way to get some reliable numbers would of course be to try it - it > should definately be at least twice as fast. We'd be interested to hear what > you find. I definetly would like to try yaffs2 out. Where can I find howto? > Ulitimately the solution to the problem that all log-structured > filesystems have > to scan the whole media on boot, and this takes time is checkpointing > (storing intermediate, or shutdown, status), and smarter partitioning so > you > can start before scanning the whole media. The latter is available today - > the former needs sponsoring. Cannot do much with partitioning since must be able to suck the data out fast even immediatelly after reset. Sergei Sharonov From jfilling@realmsys.com Mon Apr 18 21:10:23 2005 From: jfilling@realmsys.com (Jeremy Fillingim) Date: Mon, 18 Apr 2005 14:10:23 -0600 Subject: [Yaffs] YAFFS2 Issues In-Reply-To: References: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> <20050416195320.GD5964@xios> Message-ID: <20050418201023.GA17693@realmsys.com> Hi guys, I have a custom PPC based system on which I have been running 2.6.10 + board specific changes. The flash part that we are using is a 256MB large page device (2048 page bytes + 64 spare bytes). Up to this point I have been using JFFS2 + Summary support (head of MTD CVS) with a small root partition (32MB) and a second large partition (>200MB). The JFFS2 performance is decent in most cases, but mount times can be terrible. I wanted to evaluate YAFFS2 as a possible replacement for JFFS2, so I pulled the latest YAFFS2 code out of CVS and updated my MTD to the latest CVS. A few minor changes to the Makefile and Kconfig stuff was all that was required to get YAFFS2 compiled. I am able to successfully mount an empty partition, and it "looks" like a write to that partition succeeds. However, when I attempt to unmount the YAFFS2 partition, I get a kernel oops. When I remount the partition, my files do not show up. This is the message that I receive when I unmount after touching a file on the YAFFS2 partition. VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... idr_remove called for id=4 which is not allocated. Call trace: [c00b44e0] idr_remove+0x158/0x1f0 [c004eac8] kill_anon_super+0x3c/0x6c [c004d964] deactivate_super+0xa0/0xd4 [c0065cf4] __mntput+0x30/0x44 [c0055798] path_release_on_umount+0x4c/0x60 [c00665c8] sys_umount+0x2bc/0x2d4 [c0002a00] ret_from_syscall+0x0/0x48 I did my MTD and YAFFS2 CVS checkouts on Friday April 15. Thank you in advance for any insight you may have. On Sun, Apr 17, 2005 at 06:23:25PM +0800, zheng wei (jeanwelly@gmail.com) wrote: > I want to use yaffs on 2.6.11, my cpu is 2410. > I am not sure whether I should update the MTD in 2.6.11. > But now I found ECC in mtd can't work correctly on nandflash. > Also I want to use yaffs as a root fs. How can I get started? > Thanks for any idea. > > On 4/17/05, Wookey wrote: > > +++ Sergei Sharonov [05-04-14 10:33 -0500]: > > > Hi, > > > > > > I am working on ARM9/linux2.6.10 based system with a large > > > (256 MByte) NAND storage. Currently the filesystem used is jffs2. > > > Unfortunately the mount time is unacceptably long and I am > > > looking for an alternative. Can anybody comment on status > > > of YAFFS2? Note that version 2 is required since NAND page > > > size is 2 k. > > > > People are using YAFFS2 successfully. I'm not sure if any commercial products > > have actually shipped with it yet, but it is now tested and functional. > > > > For best mount-time splitting your flash into more than one partition is > > often smart so you can boot from a small partition and give user feedback > > whilst mounting a larger data partition. Obviously this doesn't suit all > > applications. > > > > We do have a plan for implementing checkpointing for much faster booting > > (under normal circumstances) but this work has not yet been sponsored by > > anyone. > > > > Wookey > > -- > > Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 > > work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ > > > > _______________________________________________ > > yaffs mailing list > > yaffs@stoneboat.aleph1.co.uk > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > > > > -- > --------- > jeanwelly > Email: jeanwelly@gmail.com > China > > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From manningc2@actrix.gen.nz Mon Apr 18 21:39:38 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Tue, 19 Apr 2005 08:39:38 +1200 Subject: [Yaffs] yaffs2 howto In-Reply-To: References: Message-ID: <20050418203947.0FE7C1563C@desire.actrix.co.nz> On Tuesday 19 April 2005 05:54, Sergei Sharonov wrote: > Hi, > > sorry if it is FAQ, but is there a howto for yaffs2? I've found only > yaffs(1) I don't think there's an actual yaffs2 howto per se. The only real difference in using yaffs2 vs yaffs1 is the NAND interface=20 (which is in the mtd).=20 If someone using yaffs2 could roll a yaffs2 update for an existing yaffs1= =20 howto that would be great. -- Charles From manningc2@actrix.gen.nz Mon Apr 18 21:58:02 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Tue, 19 Apr 2005 08:58:02 +1200 Subject: [Yaffs] Re: yaffs2 status --> mount speed up In-Reply-To: References: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> <20050418173507.GJ5964@xios> Message-ID: <20050418205810.DBCF515885@desire.actrix.co.nz> With the interest in YAFFS speed, I thought I'd take an opportunity to=20 pre-announce some YAFFS2 speed-ups that are in the pipe. YAFFS2 is generally faster than YAFFS1 when executing for two reasons: * It does not program deletion markers. This makes things faster when chu= nks=20 are reprogrammed. * Chunk/page size is bigger therefore faster programming. YAFFS2 does not delete chunks (=3D=3D pages) like YAFFS1 does and instead= figures=20 out the system state by scanning the blocks in their allocation order. Th= is=20 means that a deleted file would get formed then deleted, all of which tak= e=20 extra (wasted) time. This means that YAFFS2 is sometimes quite a bit=20 slower than YAFFS1 for mounting, depending on the state of NAND. Someone using YAFFS2 suggested a change to the scanning policy to speed t= his=20 scanning up. Instead of scanning forwards in time the proposal was to sca= n=20 the blocks backwards (ie. most recent allocated block first). Consider t= he=20 case of the deleted file: we see the file is deleted and then just ignore= any=20 further references to that file. Simultaneously with this, I also added an optimisation to store some extr= a=20 info in the tags for object header chunks. This means that we no longer n= eed=20 to read the whole chunk to get most of the object header info needed duri= ng=20 mount scanning. Together these modifications have shown some huge speedups, typically mu= ch =20 faster than yaffs(1). They also pave the way for adding "checkpointing" e= tc. These speedups are not yet in CVS, but I intend to check them in this wee= k. -- Charles From wookey@aleph1.co.uk Mon Apr 18 22:03:34 2005 From: wookey@aleph1.co.uk (Wookey) Date: Mon, 18 Apr 2005 22:03:34 +0100 Subject: [Yaffs] Re: yaffs2 howto In-Reply-To: References: Message-ID: <20050418210334.GC6470@xios> +++ Sergei Sharonov [05-04-18 17:54 +0000]: > Hi, > > sorry if it is FAQ, but is there a howto for yaffs2? I've found only yaffs(1) Not yet :-( We are in the process of thoroughly revamping the docs (and website) for YAFFS which have got rather left behind by events. But right now it's mostly a case of asking on this list and using your skill and judgement. Not too much changes for YAFFS2. Different CVS is the main thing: module 'yaffs2'. I thought Charles had posted some updated docs but I can't find them now. There is a new script to patch YAFFS into the kernel - tested on 2.4, but not on 2.6 - this is in the yaff1 cvs. Charles - or anyone else. Do we have a 'how to do YAFFS2' or does anyone feel like writing one? Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From manningc2@actrix.gen.nz Mon Apr 18 22:03:42 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Tue, 19 Apr 2005 09:03:42 +1200 Subject: [Yaffs] YAFFS2 Issues In-Reply-To: <20050418201023.GA17693@realmsys.com> References: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> <20050418201023.GA17693@realmsys.com> Message-ID: <20050418210350.6264A4525@blood.actrix.co.nz> Hi Jeremy Could you please send me the following: * /proc/yaffs of a freshly mounted partition * /proc/yaffs of the remounted partiton * oops traceback Thanx=20 -- charles On Tuesday 19 April 2005 08:10, Jeremy Fillingim wrote: > Hi guys, > > I have a custom PPC based system on which I have been running 2.6.10 + > board specific changes. The flash part that we are using is a 256MB > large page device (2048 page bytes + 64 spare bytes). > > Up to this point I have been using JFFS2 + Summary support (head of MTD > CVS) with a small root partition (32MB) and a second large partition > (>200MB). The JFFS2 performance is decent in most cases, but mount time= s > can be terrible. > > I wanted to evaluate YAFFS2 as a possible replacement for JFFS2, so I > pulled the latest YAFFS2 code out of CVS and updated my MTD to the late= st > CVS. A few minor changes to the Makefile and Kconfig stuff was all that= was > required to get YAFFS2 compiled. > > I am able to successfully mount an empty partition, and it "looks" like > a write to that partition succeeds. However, when I attempt to unmount = the > YAFFS2 partition, I get a kernel oops. When I remount the partition, > my files do not show up. > > This is the message that I receive when I unmount after touching a file > on the YAFFS2 partition. > > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nic= e > day... idr_remove called for id=3D4 which is not allocated. > Call trace: > [c00b44e0] idr_remove+0x158/0x1f0 > [c004eac8] kill_anon_super+0x3c/0x6c > [c004d964] deactivate_super+0xa0/0xd4 > [c0065cf4] __mntput+0x30/0x44 > [c0055798] path_release_on_umount+0x4c/0x60 > [c00665c8] sys_umount+0x2bc/0x2d4 > [c0002a00] ret_from_syscall+0x0/0x48 > > I did my MTD and YAFFS2 CVS checkouts on Friday April 15. > > Thank you in advance for any insight you may have. > > On Sun, Apr 17, 2005 at 06:23:25PM +0800, zheng wei (jeanwelly@gmail.co= m)=20 wrote: > > I want to use yaffs on 2.6.11, my cpu is 2410. > > I am not sure whether I should update the MTD in 2.6.11. > > But now I found ECC in mtd can't work correctly on nandflash. > > Also I want to use yaffs as a root fs. How can I get started? > > Thanks for any idea. > > > > On 4/17/05, Wookey wrote: > > > +++ Sergei Sharonov [05-04-14 10:33 -0500]: > > > > Hi, > > > > > > > > I am working on ARM9/linux2.6.10 based system with a large > > > > (256 MByte) NAND storage. Currently the filesystem used is jffs2. > > > > Unfortunately the mount time is unacceptably long and I am > > > > looking for an alternative. Can anybody comment on status > > > > of YAFFS2? Note that version 2 is required since NAND page > > > > size is 2 k. > > > > > > People are using YAFFS2 successfully. I'm not sure if any commercia= l > > > products have actually shipped with it yet, but it is now tested an= d > > > functional. > > > > > > For best mount-time splitting your flash into more than one partiti= on > > > is often smart so you can boot from a small partition and give user > > > feedback whilst mounting a larger data partition. Obviously this > > > doesn't suit all applications. > > > > > > We do have a plan for implementing checkpointing for much faster > > > booting (under normal circumstances) but this work has not yet been > > > sponsored by anyone. > > > > > > Wookey > > > -- > > > Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 > > > 811679 work: http://www.aleph1.co.uk/ play: > > > http://www.chaos.org.uk/~wookey/ > > > > > > _______________________________________________ > > > yaffs mailing list > > > yaffs@stoneboat.aleph1.co.uk > > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > > > -- > > --------- > > jeanwelly > > Email: jeanwelly@gmail.com > > China > > > > _______________________________________________ > > yaffs mailing list > > yaffs@stoneboat.aleph1.co.uk > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From jfilling@realmsys.com Mon Apr 18 23:10:45 2005 From: jfilling@realmsys.com (Jeremy Fillingim) Date: Mon, 18 Apr 2005 16:10:45 -0600 Subject: [Yaffs] YAFFS2 Issues In-Reply-To: <20050418210350.6264A4525@blood.actrix.co.nz> References: <487B538D08487B4D8FEC138A13D4F6AC74C5F3@HOUEXCH077.corp.halliburton.com> <20050418201023.GA17693@realmsys.com> <20050418210350.6264A4525@blood.actrix.co.nz> Message-ID: <20050418221045.GA13756@realmsys.com> I misspoke about my kernel Oops, when I unmount after touching a file on my YAFFS2 partition, it erely gives me a call trace. I erased my flash partition before executing these commands: # mount -t yaffs2 /dev/mtdblock4 /mnt/mtdb4 # cat /proc/yaffs YAFFS built:Apr 18 2005 14:33:02 $Id: yaffs_fs.c,v 1.2 2005/03/16 04:00:36 charles Exp $ $Id: yaffs_guts.c,v 1.5 2005/03/16 04:00:36 charles Exp $ Device yaffs startBlock......... 1 endBlock........... 1727 chunkGroupBits..... 1 chunkGroupSize..... 2 nErasedBlocks...... 1723 nTnodesCreated..... 0 nFreeTnodes........ 0 nObjectsCreated.... 100 nFreeObjects....... 96 nFreeChunks........ 110272 nPageWrites........ 0 nPageReads......... 0 nBlockErasures..... 0 nGCCopies.......... 0 garbageCollections. 0 passiveGCs......... 0 nRetriedWrites..... 0 nRetireBlocks...... 0 eccFixed........... 0 eccUnfixed......... 0 tagsEccFixed....... 0 tagsEccUnfixed..... 0 cacheHits.......... 0 nDeletedFiles...... 0 nUnlinkedFiles..... 0 nBackgroudDeletions 0 useNANDECC......... 1 isYaffs2........... 1 I then unmounted the partition without attempting to edit any files, followed by a remount: # umount /mnt/mtdb4 # mount -t yaffs2 /dev/mtdblock4 /mnt/mtdb4 # cat /proc/yaffs YAFFS built:Apr 18 2005 14:33:02 $Id: yaffs_fs.c,v 1.2 2005/03/16 04:00:36 charles Exp $ $Id: yaffs_guts.c,v 1.5 2005/03/16 04:00:36 charles Exp $ Device yaffs startBlock......... 1 endBlock........... 1727 chunkGroupBits..... 1 chunkGroupSize..... 2 nErasedBlocks...... 1723 nTnodesCreated..... 0 nFreeTnodes........ 0 nObjectsCreated.... 100 nFreeObjects....... 96 nFreeChunks........ 110272 nPageWrites........ 0 nPageReads......... 0 nBlockErasures..... 0 nGCCopies.......... 0 garbageCollections. 0 passiveGCs......... 0 nRetriedWrites..... 0 nRetireBlocks...... 0 eccFixed........... 0 eccUnfixed......... 0 tagsEccFixed....... 0 tagsEccUnfixed..... 0 cacheHits.......... 0 nDeletedFiles...... 0 nUnlinkedFiles..... 0 nBackgroudDeletions 0 useNANDECC......... 1 isYaffs2........... 1 This is what happens when I touch a file and unmount: # touch /mnt/mtdb4/file0 # umount /mnt/mtdb4 VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... idr_remove called for id=4 which is not allocated. Call trace: [c00b44e0] idr_remove+0x158/0x1f0 [c004eac8] kill_anon_super+0x3c/0x6c [c004d964] deactivate_super+0xa0/0xd4 [c0065cf4] __mntput+0x30/0x44 [c0055798] path_release_on_umount+0x4c/0x60 [c00665c8] sys_umount+0x2bc/0x2d4 [c0002a00] ret_from_syscall+0x0/0x48 # mount -t yaffs2 /dev/mtdblock4 /mnt/mtdb4 # cat /proc/yaffs YAFFS built:Apr 18 2005 14:33:02 $Id: yaffs_fs.c,v 1.2 2005/03/16 04:00:36 charles Exp $ $Id: yaffs_guts.c,v 1.5 2005/03/16 04:00:36 charles Exp $ Device yaffs startBlock......... 1 endBlock........... 1727 chunkGroupBits..... 1 chunkGroupSize..... 2 nErasedBlocks...... 1722 nTnodesCreated..... 0 nFreeTnodes........ 0 nObjectsCreated.... 100 nFreeObjects....... 96 nFreeChunks........ 110208 nPageWrites........ 0 nPageReads......... 0 nBlockErasures..... 0 nGCCopies.......... 0 garbageCollections. 0 passiveGCs......... 0 nRetriedWrites..... 0 nRetireBlocks...... 0 eccFixed........... 0 eccUnfixed......... 0 tagsEccFixed....... 0 tagsEccUnfixed..... 0 cacheHits.......... 0 nDeletedFiles...... 0 nUnlinkedFiles..... 0 nBackgroudDeletions 0 useNANDECC......... 1 isYaffs2........... 1 On Tue, Apr 19, 2005 at 09:03:42AM +1200, Charles Manning (manningc2@actrix.gen.nz) wrote: > Hi Jeremy > > Could you please send me the following: > > * /proc/yaffs of a freshly mounted partition > * /proc/yaffs of the remounted partiton > * oops traceback > > Thanx > > -- charles > > > > On Tuesday 19 April 2005 08:10, Jeremy Fillingim wrote: > > Hi guys, > > > > I have a custom PPC based system on which I have been running 2.6.10 + > > board specific changes. The flash part that we are using is a 256MB > > large page device (2048 page bytes + 64 spare bytes). > > > > Up to this point I have been using JFFS2 + Summary support (head of MTD > > CVS) with a small root partition (32MB) and a second large partition > > (>200MB). The JFFS2 performance is decent in most cases, but mount times > > can be terrible. > > > > I wanted to evaluate YAFFS2 as a possible replacement for JFFS2, so I > > pulled the latest YAFFS2 code out of CVS and updated my MTD to the latest > > CVS. A few minor changes to the Makefile and Kconfig stuff was all that was > > required to get YAFFS2 compiled. > > > > I am able to successfully mount an empty partition, and it "looks" like > > a write to that partition succeeds. However, when I attempt to unmount the > > YAFFS2 partition, I get a kernel oops. When I remount the partition, > > my files do not show up. > > > > This is the message that I receive when I unmount after touching a file > > on the YAFFS2 partition. > > > > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice > > day... idr_remove called for id=4 which is not allocated. > > Call trace: > > [c00b44e0] idr_remove+0x158/0x1f0 > > [c004eac8] kill_anon_super+0x3c/0x6c > > [c004d964] deactivate_super+0xa0/0xd4 > > [c0065cf4] __mntput+0x30/0x44 > > [c0055798] path_release_on_umount+0x4c/0x60 > > [c00665c8] sys_umount+0x2bc/0x2d4 > > [c0002a00] ret_from_syscall+0x0/0x48 > > > > I did my MTD and YAFFS2 CVS checkouts on Friday April 15. > > > > Thank you in advance for any insight you may have. > > > > On Sun, Apr 17, 2005 at 06:23:25PM +0800, zheng wei (jeanwelly@gmail.com) > wrote: > > > I want to use yaffs on 2.6.11, my cpu is 2410. > > > I am not sure whether I should update the MTD in 2.6.11. > > > But now I found ECC in mtd can't work correctly on nandflash. > > > Also I want to use yaffs as a root fs. How can I get started? > > > Thanks for any idea. > > > > > > On 4/17/05, Wookey wrote: > > > > +++ Sergei Sharonov [05-04-14 10:33 -0500]: > > > > > Hi, > > > > > > > > > > I am working on ARM9/linux2.6.10 based system with a large > > > > > (256 MByte) NAND storage. Currently the filesystem used is jffs2. > > > > > Unfortunately the mount time is unacceptably long and I am > > > > > looking for an alternative. Can anybody comment on status > > > > > of YAFFS2? Note that version 2 is required since NAND page > > > > > size is 2 k. > > > > > > > > People are using YAFFS2 successfully. I'm not sure if any commercial > > > > products have actually shipped with it yet, but it is now tested and > > > > functional. > > > > > > > > For best mount-time splitting your flash into more than one partition > > > > is often smart so you can boot from a small partition and give user > > > > feedback whilst mounting a larger data partition. Obviously this > > > > doesn't suit all applications. > > > > > > > > We do have a plan for implementing checkpointing for much faster > > > > booting (under normal circumstances) but this work has not yet been > > > > sponsored by anyone. > > > > > > > > Wookey > > > > -- > > > > Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 > > > > 811679 work: http://www.aleph1.co.uk/ play: > > > > http://www.chaos.org.uk/~wookey/ > > > > > > > > _______________________________________________ > > > > yaffs mailing list > > > > yaffs@stoneboat.aleph1.co.uk > > > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > > > > > -- > > > --------- > > > jeanwelly > > > Email: jeanwelly@gmail.com > > > China > > > > > > _______________________________________________ > > > yaffs mailing list > > > yaffs@stoneboat.aleph1.co.uk > > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > > > _______________________________________________ > > yaffs mailing list > > yaffs@stoneboat.aleph1.co.uk > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From Shaun Jackman Tue Apr 19 17:42:41 2005 From: Shaun Jackman (Shaun Jackman) Date: Tue, 19 Apr 2005 09:42:41 -0700 Subject: [Yaffs] Static yaffs2 library Message-ID: <7f45d93905041909421981391f@mail.gmail.com> I started to compile yaffs2 for an arm-elf embedded target, but yaffs_fs.c did not find the Linux headers it was expecting. Is it possible to compile yaffs to provide a typical open/read/write/close interface in a static library, and is it possible to use yaffs with a NOR flash chip on a memory bus? Cheers, Shaun From Charles.Manning@trimble.co.nz Tue Apr 19 19:15:32 2005 From: Charles.Manning@trimble.co.nz (Charles Manning) Date: Wed, 20 Apr 2005 06:15:32 +1200 Subject: [Yaffs] Static yaffs2 library Message-ID: <8285CB7241FCFC4BB721A6F953F9B35E02E439F8@nzc-ap-xch-01.ap.trimblecorp.net> Yes, there's YAFFS Direct. This is the "RTOS flavour" of YAFFS that is easy to set up for use with or without an OS. A few people are shipping product based on YAFFS with NOR. Although YAFFS was designed for NAND, it does also work with NOR. You just need to simulate the NAND pages. If you look back in the list archives you should find some references to this. -- Charles > -----Original Message----- > From: yaffs-admin@stoneboat.aleph1.co.uk=20 > [mailto:yaffs-admin@stoneboat.aleph1.co.uk] On Behalf Of Shaun Jackman > Sent: Wednesday, 20 April 2005 4:43 a.m. > To: yaffs@stoneboat.aleph1.co.uk > Subject: [Yaffs] Static yaffs2 library >=20 >=20 > I started to compile yaffs2 for an arm-elf embedded target,=20 > but yaffs_fs.c did not find the Linux headers it was=20 > expecting. Is it possible to compile yaffs to provide a=20 > typical open/read/write/close interface in a static library,=20 > and is it possible to use yaffs with a NOR flash chip on a memory bus? >=20 > Cheers, > Shaun >=20 > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk=20 > http://stoneboat.aleph1.co.uk/cgi-> bin/mailman/listinfo/yaffs >=20 From wookey@aleph1.co.uk Tue Apr 19 19:29:26 2005 From: wookey@aleph1.co.uk (Wookey) Date: Tue, 19 Apr 2005 19:29:26 +0100 Subject: [Yaffs] Re: Static yaffs2 library In-Reply-To: <7f45d93905041909421981391f@mail.gmail.com> References: <7f45d93905041909421981391f@mail.gmail.com> Message-ID: <20050419182926.GL9422@xios> +++ Shaun Jackman [05-04-19 09:42 -0700]: > I started to compile yaffs2 for an arm-elf embedded target, but > yaffs_fs.c did not find the Linux headers it was expecting. Is it > possible to compile yaffs to provide a typical open/read/write/close > interface in a static library, Do you mean to use YAFFS without linux? If so, yes - it's called 'YAFFS direct' which does indeed provide a simplified set of calls which replace the Linux VFS layer. See the diag here for the various ways yuaffs can be fitted into OSes: http://www.aleph1.co.uk/talks/yaffs/mgp00007.html > and is it possible to use yaffs with a NOR flash chip on a memory bus? It is. It's not quite what it was designed for, but it does work fine and can make sense. You'll need to tweak things a bit. There have been a few posts to this list over the last 2 months asking the same question. Find one of those for the details. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From Sergei.Sharonov@Halliburton.com Tue Apr 19 20:00:48 2005 From: Sergei.Sharonov@Halliburton.com (Sergei Sharonov) Date: Tue, 19 Apr 2005 14:00:48 -0500 Subject: [Yaffs] yaffs2 problems Message-ID: <487B538D08487B4D8FEC138A13D4F6AC74D203@HOUEXCH077.corp.halliburton.com> Hi, sorry if it is double posted, but I don't see my original post sent=20 through gmane. ------------------------------------- SW: YAFFS2 built into linux 2.6.10 with recent mtd snapshot HW: at91rm9200 with 256 MB Samsung NAND hardware/linux/mtd are likely ok since I can run with jffs2 for weeks. Flash was erased before mounting yaffs2. Problems: 1. umount fails with message: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. =20 Have a nice day... 2. some files disappear after re-mounting 3. (a lot of) segmentation faults 4. df shows garbage People, has anybody managed to run yaffs2 under linux 2.6.x? Are there any patches required against tarball from: http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/cvs_root.tar.gz?tarball=3D1 Sergei Sharonov ------------------------------------- # mount /mnt/flash/ yaffs: dev is 32505859 name is "(unavailable)" yaffs: Attempting MTD mount on 31.3, "(unavailable)" yaffs: yaffs_GutsInitialise() yaffs: yaffs_GutsInitialise() done. # cat /proc/yaffs YAFFS built:Apr 19 2005 13:24:56 $Id: yaffs_fs.c,v 1.2 2005/03/16 04:00:36 charles Exp $ $Id: yaffs_guts.c,v 1.5 2005/03/16 04:00:36 charles Exp $ Device yaffs startBlock......... 1 endBlock........... 2047 chunkGroupBits..... 1 chunkGroupSize..... 2 nErasedBlocks...... 2047 nTnodesCreated..... 0 nFreeTnodes........ 0 nObjectsCreated.... 100 nFreeObjects....... 96 nFreeChunks........ 131008 nPageWrites........ 0 nPageReads......... 0 nBlockErasures..... 0 nGCCopies.......... 0 garbageCollections. 0 passiveGCs......... 0 nRetriedWrites..... 0 nRetireBlocks...... 0 eccFixed........... 0 eccUnfixed......... 0 tagsEccFixed....... 0 tagsEccUnfixed..... 0 cacheHits.......... 0 nDeletedFiles...... 0 nUnlinkedFiles..... 0 nBackgroudDeletions 0 useNANDECC......... 0 isYaffs2........... 1 # # df /mnt/flash/ Filesystem 1k-blocks Used Available Use% Mounted on /dev/mtdblock3 32752 -32559 65312 -98% /mnt/flash # cp /bin/busybox /mnt/flash/ # ls -l /mnt/flash/ -rwxr-xr-x 1 root root 135556 Jan 1 00:01 busybox drw-rw-rw- 1 root root 2048 Jan 1 00:00 lost+found # rm /mnt/flash/busybox # cp /bin/busybox /mnt/flash/ page 65 in gc has no object Unable to handle kernel paging request at virtual address e1a0c031 pgd =3D c03d8000 [e1a0c031] *pgd=3D00000000 Internal error: Oops: 3 [#1] Modules linked in: CPU: 0 PC is at yaffs_FindObjectByNumber+0x54/0x74 LR is at 0xc02e7bfc pc : [] lr : [] Not tainted sp : c02f3b94 ip : ffffff9b fp : c02f3ba8 r10: 00000002 r9 : c03bb800 r8 : 00000042 r7 : c02f3bbc r6 : 00000001 r5 : ffffff36 r4 : c02e8000 r3 : c02e7b44 r2 : e1a0c00d r1 : 9766569b r0 : e1a0c001 Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment user Control: C000717F Table: 203D8000 DAC: 00000015 Process cp (pid: 682, stack limit =3D 0xc02f2190) Stack: (0xc02f3b94 to 0xc02f4000) 3b80: 00000000 c02e8000 c02f3c10 3ba0: c02f3bac c00e03b0 c00def04 c00e08c8 0001ff71 00000000 00000001 aaaaaaaa 3bc0: 00000001 9766569b 6959c333 0f9b999a ffffffff 00000000 00000000 00000000 3be0: ff03ccfc 55555555 c02e8000 00000001 00000000 00000001 00000001 00000800 3c00: 00000000 c02f3c34 c02f3c14 c00e064c c00e00fc c03fe000 c03dc258 00000009 3c20: c03dc258 c02e8000 c02f3cb8 c02f3c38 c00e0d6c c00e05cc aaaaaaaa 00000001 3c40: 00000105 00000008 c02f3c68 c02f3c58 c00378c4 c00377cc 00000001 c02f3c8c 3c60: c02f3c6c c0037c8c c00378c0 c02f3d1c c02f2000 c02f3ca8 c02f3c84 c002bffc 3c80: c002b244 c0216ce4 c02f3d1c 00000000 00000800 00000008 00000009 c03dc258 3ca0: 00000800 00000800 00000000 c02f3d04 c02f3cbc c00e1838 c00e0d50 00000000 3cc0: c02e8000 00000000 00004000 00000000 00001000 00004000 c03fe000 00004000 3ce0: c03dc258 c3d11288 00001000 c02f3d38 c03fe000 00000000 c02f3d34 c02f3d08 3d00: c00dc0bc c00e1660 c02e8000 00001000 c03fe000 c022efc0 c3c16320 c01dbb28 3d20: 00000000 00000000 c02f3d60 c02f3d38 c00dbcd4 c00dc010 00004000 00000000 3d40: 00001000 00000000 c0218704 c022efc0 00004000 c02f3e00 c02f3d64 c004ad34 3d60: c00dbc54 00001000 000342d0 00001000 c3d11288 c01dbb2c c3d11320 c3c16320 3d80: 00000001 c02f3e6c 00000000 c02f3f10 00000000 08000000 00000001 00000000 3da0: c022efc0 c007d748 0000006d 1412bce5 c3d11288 00000001 c3d112d4 c02f3e04 3dc0: c02f3dcc c007d90c c0085794 0000006d 1412bce5 0000006d 00004000 00000000 3de0: 00000000 c02f3e34 c3c16320 00004000 00000000 c02f3e68 c02f3e08 c004b3c8 3e00: c004a9e4 00004000 00000000 c02f3f74 00001000 00000000 00000000 c3d11288 3e20: 00001000 c02f3f74 c02f3f10 c02f3e6c 00000001 00001000 00004000 00000000 3e40: 00000000 c02c6ce0 c02f3ecc c02f3e6c 00000000 00000000 c02f3f74 c02f3f08 3e60: c02f3e6c c004b4f4 c004af88 00000000 c02c6ce0 00000000 00000001 ffffffff 3e80: c3c16320 c03a0f04 00000000 c02f3e98 00000000 c00496c0 000342d0 c02c6ce0 3ea0: 00000000 00000000 00000000 00000001 ffffffff c3c16140 c03a0f04 00000000 3ec0: 23ca705f c02c6ce0 c00432b8 c02f3ecc c02f3ecc 00000000 00000000 c00585a4 3ee0: c0021cbc c3d112f0 c3d11320 00004000 c3d11288 c3c16320 000342d0 c02f3f3c 3f00: c02f3f0c c004b730 c004b480 c02f3fb0 000342d0 00001000 00000000 c3c16320 3f20: 00004000 00000000 00001000 c02f3f74 c02f3f70 c02f3f40 c00636b0 c004b6e4 3f40: 00000000 c02f3f78 c3c16344 fffffff7 c3c16320 c02f3f74 00004000 00000000 3f60: 40058178 c02f3fa4 c02f3f74 c00637ac c00635dc 00004000 00000000 00000000 3f80: 00001000 000342d0 00000004 00000004 c001b924 c02f2000 00000000 c02f3fa8 3fa0: c001b7a0 c006376c 00001000 c00221d4 00000004 000342d0 00001000 ffffc000 3fc0: 00001000 000342d0 00000004 00000004 00000004 00000000 40058178 00000000 3fe0: 0002ff1c befffc44 00021e18 40046ce0 20000010 00000004 00000000 00000000 Backtrace: [] (yaffs_FindObjectByNumber+0x0/0x74) from [] (yaffs_Garbag eCollectBlock+0x2c4/0x4d0) r5 =3D C02E8000 r4 =3D 00000000 [] (yaffs_GarbageCollectBlock+0x0/0x4d0) from [] (yaffs_Chec kGarbageCollection+0x90/0x114) [] (yaffs_CheckGarbageCollection+0x0/0x114) from [] (yaffs_W riteChunkDataToObject+0x2c/0xc8) r8 =3D C02E8000 r7 =3D C03DC258 r6 =3D 00000009 r5 =3D C03DC258 r4 =3D C03FE000 [] (yaffs_WriteChunkDataToObject+0x0/0xc8) from [] (yaffs_Wr iteDataToFile+0x1e8/0x278) [] (yaffs_WriteDataToFile+0x0/0x278) from [] (yaffs_file_wri te+0xbc/0x16c) [] (yaffs_file_write+0x0/0x16c) from [] (yaffs_commit_write+ 0x90/0x13c) [] (yaffs_commit_write+0x0/0x13c) from [] (generic_file_buff ered_write+0x364/0x5a8) r8 =3D 00004000 r7 =3D C022EFC0 r6 =3D C0218704 r5 =3D 00000000 r4 =3D 00001000 [] (generic_file_buffered_write+0x4/0x5a8) from [] (__generi c_file_aio_write_nolock+0x450/0x478) [] (__generic_file_aio_write_nolock+0x0/0x478) from [] (__ge neric_file_write_nolock+0x84/0xac) [] (__generic_file_write_nolock+0x0/0xac) from [] (generic_f ile_write+0x5c/0xe8) r9 =3D 000342D0 r8 =3D C3C16320 r7 =3D C3D11288 r6 =3D 00004000 r5 =3D C3D11320 r4 =3D C3D112F0 [] (generic_file_write+0x0/0xe8) from [] (vfs_write+0xe4/0x1 1c) [] (vfs_write+0x0/0x11c) from [] (sys_write+0x50/0x74) [] (sys_write+0x0/0x74) from [] (ret_fast_syscall+0x0/0x2c) r9 =3D C02F2000 r8 =3D C001B924 r7 =3D 00000004 r6 =3D 00000004 r5 =3D 000342D0 r4 =3D 00001000 Code: e3520000 e242000c e283e0b8 0a000002 (e5903030) From sergei.sharonov@halliburton.com Wed Apr 20 15:51:29 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Wed, 20 Apr 2005 14:51:29 +0000 (UTC) Subject: [Yaffs] Re: yaffs2 problems References: <487B538D08487B4D8FEC138A13D4F6AC74D203@HOUEXCH077.corp.halliburton.com> Message-ID: Hi, > Problems: > 1. umount fails with message: > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. > Have a nice day... > 2. some files disappear after re-mounting > 3. (a lot of) segmentation faults > 4. df shows garbage Ok, I managed to get rid of "self-destruct" message and possibly of segfaults by replacing kill_litter_super with kill_block_super See: http://www.aleph1.co.uk/pipermail/yaffs/2004q4/000887.html Now, 1. On remount I am getting messages like: yaffs: Allocation block 20 was not highest sequence id: block seq = 655359, devseq = 269156351 2. Some writes produce **>> yaffs chunk 686 was not erased 3. Files after remount/reboot contain all zeros or disappear. Sergei Sharonov From sergei.sharonov@halliburton.com Wed Apr 20 22:45:14 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Wed, 20 Apr 2005 21:45:14 +0000 (UTC) Subject: [Yaffs] Re: yaffs2 status References: Message-ID: Hi, > > Can anybody post any reference numbers? For example it takes me 20+ > > minutes to mount 256 MByte NAND partion with a 200 MByte file on it > > when using jffs2................... > These results are using yaffs1. > I expect the process to be faster using yaffs2 due to the faster interface > and smaller number of headers to scan. > We have 128MByte nand chips fairly full and they don't take forever to scan. > This is anecdotal but my impression is of the order of 10 secs. > The poor boot time scaling of jffs2 and large amounts or ram used were > prime reasons why we sponsored the > yaffs effort............. > I just asked one of the testers and he says that the mounting pause during > boot up is about 8 secs with 77MB used. Ok, I could not get yaffs2 to work ;-( but yaffs1 *preliminary* seems to be working fine. With 128 MByte NAND chip and 100 MByte worth of files written and fsynced (!) in 1 kB chunks mount time 18.2 s. And I can access files immediately after mount returns. Read throughput over Ethernet/samba is about 1 MByte/s, cp to /dev/null is at 1.27 MByte/s. Writes are quite slow. Overall it seems to be a huge speed improvement over jffs2. Sergei Sharonov From manningc2@actrix.gen.nz Thu Apr 21 23:15:13 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Fri, 22 Apr 2005 10:15:13 +1200 Subject: [Yaffs] Re: yaffs2 problems In-Reply-To: References: <487B538D08487B4D8FEC138A13D4F6AC74D203@HOUEXCH077.corp.halliburton.com> Message-ID: <20050421221515.B912216024@desire.actrix.co.nz> Hi Sergei Stuff below... On Thursday 21 April 2005 02:51, Sergei Sharonov wrote: > Hi, > > > Problems: > > 1. umount fails with message: > > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. > > Have a nice day... > > 2. some files disappear after re-mounting > > 3. (a lot of) segmentation faults > > 4. df shows garbage > > Ok, I managed to get rid of "self-destruct" message and possibly of > segfaults by replacing kill_litter_super with kill_block_super > See: http://www.aleph1.co.uk/pipermail/yaffs/2004q4/000887.html > Did you erase the flash before using it for YAFFS2? The stuff below looks= a=20 bit like this was not done, but more likely it is a tags corruption issue= ,=20 either in the low level stuff or in mtd. It also looks like there could be some low-level corruption of tags. This= =20 could be caused by the ECC etc. YAFFS1 tags are smaller, and I think JFF= S2=20 does not use tags so this could explain why you don't see the problem the= re. > Now, > 1. On remount I am getting messages like: > yaffs: Allocation block 20 was not highest sequence id: block seq =3D 6= 55359, > devseq =3D 269156351 The sequence Id's start at or around 4096 and increment by one every time= a=20 new block is allocated. I very much doubt that 655359 blocks (=3D=3Dappro= x 80GB=20 of data) have been written. > 2. Some writes produce > **>> yaffs chunk 686 was not erased > This indicates that the first chunk/page in a block was not written, but=20 subsequent chunks were. YAFFS does not do this, so it is maybe a tags=20 corruption. > 3. Files after remount/reboot contain all zeros or disappear. Again a tags issue would cause this. Regards -- Charles From sergei.sharonov@halliburton.com Thu Apr 21 23:54:41 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Thu, 21 Apr 2005 22:54:41 +0000 (UTC) Subject: [Yaffs] Re: yaffs2 problems References: <487B538D08487B4D8FEC138A13D4F6AC74D203@HOUEXCH077.corp.halliburton.com> <20050421221515.B912216024@desire.actrix.co.nz> Message-ID: Hi > Did you erase the flash before using it for YAFFS2? The stuff below looks a > bit like this was not done, but more likely it is a tags corruption issue, > either in the low level stuff or in mtd. Yes, I did erase flash by using flash_eraseall utility from mtd. Maybe I misconfigured something? My experience with linux is that if it does not work - check configuration first and only then dig into the source. Sergei Sharonov From manningc2@actrix.gen.nz Sat Apr 23 23:45:47 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Sun, 24 Apr 2005 10:45:47 +1200 Subject: [Yaffs] Re: yaffs2 problems In-Reply-To: References: <487B538D08487B4D8FEC138A13D4F6AC74D203@HOUEXCH077.corp.halliburton.com> <20050421221515.B912216024@desire.actrix.co.nz> Message-ID: <20050423224547.89FF815259@desire.actrix.co.nz> On Friday 22 April 2005 10:54, Sergei Sharonov wrote: > Hi > > > Did you erase the flash before using it for YAFFS2? The stuff below l= ooks > > a bit like this was not done, but more likely it is a tags corruption > > issue, either in the low level stuff or in mtd. > > Yes, I did erase flash by using flash_eraseall utility from mtd. Maybe = I > misconfigured something? My experience with linux is that if it does no= t > work - check configuration first and only then dig into the source. > > Sergei Sharonov Hi Sergei Something else worth trying is turning on a bit more tracing. Set yaffs_traceMask to 0xFFFFFFFF to turn on all tracing. From manningc2@actrix.gen.nz Sun Apr 24 12:23:46 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Sun, 24 Apr 2005 23:23:46 +1200 Subject: [Yaffs] CVS updates Message-ID: <20050424112341.ADD4149CA@blood.actrix.co.nz> Hi YAFFSers I have just done some YAFFS and YAFFS2 updates in CVS. Some of these are patching in some older stuff that I should have done a=20 while ago and include the fixes to kill_block_super and the handling of=20 special inodes in 2.6. I have been delaying these waiting to set up a ne= w=20 2.6 box, but have not done this and so checked them in anyway. If any of = this=20 breaks you, please scream. The major change has been adding the two scanning speed-ups to YAFFS2: * Backward scanning * Stuffing extra information into the tags for object headers. Some people have tried these and get **huge** speedups in mounting. -- Charles From DVukovic@hach.com Tue Apr 26 23:53:17 2005 From: DVukovic@hach.com (Vukovic, Donald) Date: Tue, 26 Apr 2005 15:53:17 -0700 Subject: [Yaffs] YAFFS with other RTOSs Message-ID: <4361F0559414924E92D4480616BD11A20587201C@dhrseasvxb01.messaging.danaherad.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C54AB2.BCE7D5E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Has anyone ported YAFFS to the Nucleus RTOS ?? I am just started to try this, and would like to know if this possible. ( or just difficult ) Thank You Donald Vukovic www.hach.com ------_=_NextPart_001_01C54AB2.BCE7D5E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YAFFS with other RTOSs

Has anyone ported YAFFS to the Nucleus = RTOS ??

I am just started to try this, and = would like to know if this possible. ( or just difficult )

Thank You

Donald Vukovic
www.hach.com

------_=_NextPart_001_01C54AB2.BCE7D5E5-- From manningc2@actrix.gen.nz Wed Apr 27 01:11:10 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Wed, 27 Apr 2005 12:11:10 +1200 Subject: [Yaffs] YAFFS with other RTOSs In-Reply-To: <4361F0559414924E92D4480616BD11A20587201C@dhrseasvxb01.messaging.danaherad.com> References: <4361F0559414924E92D4480616BD11A20587201C@dhrseasvxb01.messaging.danaherad.com> Message-ID: <20050427001059.86F7D15EFE@desire.actrix.co.nz> On Wednesday 27 April 2005 10:53, Vukovic, Donald wrote: > Has anyone ported YAFFS to the Nucleus RTOS ?? I don't know of people specifically using YAFFS with Nucleus, but YAFFS h= as=20 been used successfully with various RTOSs. The YAFFS Direct stuff was wri= tten=20 specifically for this purpose. Note that to use YAFFS in this way will likely require a licensing deal=20 (unless you're doing a GPL project). See=20 http://www.aleph1.co.uk/yaffs/licensing.html Also see=20 http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/*checkout*/yaffs/Documentatio= n/yaffs_direct.html?rev=3DHEAD&content-type=3Dtext/html YAFFS direct is pretty well tested since this is the primary method using= to=20 test yaffs_guts (ie. the internal file system algorithms). > > I am just started to try this, and would like to know if this possible. > ( or just difficult ) It should not be **that** difficult. The actual RTOS porting just involves filling out a few stub functions to= =20 provide a locking semaphore etc in direct/yaffscfg.c and of course provid= ing=20 some NAND access functions. -- CHarles From Sergei.Sharonov@Halliburton.com Thu Apr 28 17:24:31 2005 From: Sergei.Sharonov@Halliburton.com (Sergei Sharonov) Date: Thu, 28 Apr 2005 11:24:31 -0500 Subject: [Yaffs] power fail testing Message-ID: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> Charles, > You should find the power fail stuff very robust (ie. zero=20 > problems). If you=20 > don't then please shout ***loud***. the first problem found after a dozen power cycles ;-( I have a counter file that contains a number=20 that needs to be incremented. Increment is done as: 1. Read the number from the counter file (open as O_RDONLY, read, close) 2. Increment the number 3. Write the number to a temporary file 4. Rename temporary file to counter file Rename() suppose to be atomic per=20 http://www.opengroup.org/onlinepubs/007908799/xsh/rename.html: "If the link named by the new argument exists, it is removed and=20 old renamed to new. In this case, a link named new will remain=20 visible to other processes throughout the renaming operation and=20 will refer either to the file referred to by new or old before=20 the operation began." After a few power cycle tests the counter file disappeared, but=20 the temp file is still there. rename() never reported failure. =20 -------------------Code--------------------- ret =3D rename(FnameBlockTmp,FnameBlock); if(ret < 0) terminate(instance,ERR, "writer: failed to rename tmp block file %s", FnameBlockTmp); ------------------Output------------------- running external script /mnt/flash/run.sh writer 0 started instance 0 terminated with status -1 writer: failed to open block file /mnt/flash/blockno0 writing status to # cd /mnt/flash/ # ls blockno.tmp0 jffs2tester run.sh test0 write.sh init.sh lost+found status0 verify.sh # cat /proc/yaffs YAFFS built:Apr 20 2005 14:39:45 $Id: yaffs_fs.c,v 1.35 2004/10/20 20:12:43 charles Exp $ $Id: yaffs_guts.c,v 1.37 2004/10/20 20:12:43 charles Exp $ Device yaffs startBlock......... 1 endBlock........... 8191 chunkGroupBits..... 2 chunkGroupSize..... 4 nErasedBlocks...... 7 nTnodesCreated..... 33400 nFreeTnodes........ 2 nObjectsCreated.... 32800 nFreeObjects....... 83 nFreeChunks........ 187105 nPageWrites........ 6 nPageReads......... 14 nBlockErasures..... 0 nGCCopies.......... 0 garbageCollections. 0 passiveGCs......... 0 nRetriedWrites..... 0 nRetireBlocks...... 0 eccFixed........... 0 eccUnfixed......... 0 tagsEccFixed....... 0 tagsEccUnfixed..... 8 cacheHits.......... 0 nDeletedFiles...... 32706 nUnlinkedFiles..... 32706 nBackgroudDeletions 0 useNANDECC......... 1 # ------------------------------------------- Sergei From nick@cecomputing.co.uk Thu Apr 28 17:38:35 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Thu, 28 Apr 2005 17:38:35 +0100 Subject: [Yaffs] CVS updates In-Reply-To: <20050424112341.ADD4149CA@blood.actrix.co.nz> Message-ID: > Hi YAFFSers >=20 > I have just done some YAFFS and YAFFS2 updates in CVS. >=20 > Some of these are patching in some older stuff that I should have done = a=20 > while ago and include the fixes to kill_block_super and the handling = of=20 > special inodes in 2.6. I have been delaying these waiting to set=20 > up a new=20 > 2.6 box, but have not done this and so checked them in anyway. If=20 > any of this=20 > breaks you, please scream. >=20 >=20 > The major change has been adding the two scanning speed-ups to YAFFS2: > * Backward scanning > * Stuffing extra information into the tags for object headers. > Some people have tried these and get **huge** speedups in mounting. >=20 > -- Charles Charles, a rambling implementation report (sorry its taken so long)=20 that may be of help to others. I am testing yaffs2 using a standard 8-bit interface 512 bytes=20 per page nand plus an 8-bit interface 2K bytes per page nand (1GBit). Is there a missing yaffs_tagsvalidiy.h in the CVS? It looks like it. I faked one up with a couple of #defines and it now compile ok. Mounting the first chip using yaffs is unremarkable. Mounting the second gives unexpected results using df -h Size: 16M Used: 16T(!) Available: 29.2M Use% -82% I also got a load of erase failures and bad block warnings when deleting = files. Part of the problem may have been that I am not using NANDECC (for = compatability reasons) with the files on the first nand device. I note = that yaffs2 always passes a NULL in the place of the oobinfo so is = effectively always in NANDECC mode. I suspect I was therfore getting a = double ECC calculation effects. When the second nand chip was reduced to = all bad blocks, df reported that its size was 16MB, 16MB was used, 0 was = free and use% was 100%. /proc/mtd thinks its 128MB though. I fully erased the second nand and patched yaffs_fs.h so that if = yaffsVersion =3D=3D 2 , dev->useNANDECC is always asserted. Now all seems well except for the df anomaly. Nick Bane --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.10.4 - Release Date: 27/04/2005 From sergei.sharonov@halliburton.com Thu Apr 28 18:36:58 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Thu, 28 Apr 2005 17:36:58 +0000 (UTC) Subject: [Yaffs] Re: power fail testing References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> Message-ID: Hi, > Rename() suppose to be atomic per > http://www.opengroup.org/onlinepubs/007908799/xsh/rename.html: > "If the link named by the new argument exists, it is removed and > old renamed to new. In this case, a link named new will remain > visible to other processes throughout the renaming operation and > will refer either to the file referred to by new or old before > the operation began." In yaffs_fs.c : yaffs_rename(): removed = yaffs_Unlink(yaffs_InodeToObject(new_dir),new_dentry->d_name.name); retVal = yaffs_RenameObject(yaffs_InodeToObject(old_dir), old_dentry->d_name.name, yaffs_InodeToObject(new_dir), new_dentry->d_name.name); Is sequencing a problem here? Sergei From sergei.sharonov@halliburton.com Thu Apr 28 18:53:56 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Thu, 28 Apr 2005 17:53:56 +0000 (UTC) Subject: [Yaffs] Re: CVS updates References: <20050424112341.ADD4149CA@blood.actrix.co.nz> Message-ID: Hi, > Mounting the second gives unexpected results using df -h > Size: 16M Used: 16T(!) Available: 29.2M Use% -82% Same here - e.g. garbage from df. Sergei From manningc2@actrix.gen.nz Thu Apr 28 21:46:53 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Fri, 29 Apr 2005 08:46:53 +1200 Subject: [Yaffs] Re: CVS updates In-Reply-To: References: <20050424112341.ADD4149CA@blood.actrix.co.nz> Message-ID: <20050428204639.04129156A8@desire.actrix.co.nz> On Friday 29 April 2005 05:53, Sergei Sharonov wrote: > Hi, > > > Mounting the second gives unexpected results using df -h > > Size: 16M Used: 16T(!) Available: 29.2M Use% -82% > > Same here - e.g. garbage from df. > I will look at this, but perhaps someone else could too. This is going to= be=20 a one-liner I hunch. -- CHarles From manningc2@actrix.gen.nz Thu Apr 28 21:41:34 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Fri, 29 Apr 2005 08:41:34 +1200 Subject: [Yaffs] Re: power fail testing In-Reply-To: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> Message-ID: <20050428204119.250C01516E@desire.actrix.co.nz> Sergei Is this a power-fail problem or an interpretation of POSIX problem? ie. Did you force the problem by power cycling or did you observe it with= out=20 cycling power? I freely admit that my state of POSIXness is nowhere near the best in the= =20 planet. One of the things I did to conserve space was to use a single "objecthead= er"=20 structure to use for inodes and links. This was done because in most case= s=20 there is a 1:1 relationship. This makes some of the POSIX stuff like=20 hardlinks and unlinked-but-still-existing files a bit hairy. To summarise for my own benefit below: Consider=20 #touch a #touch b #mv -f a b There should always be a "b" visible to all processes, but in YAFFS there= =20 exists a (short) time during which there is no "b".=20 Is that a correct summary? -- Charles On Friday 29 April 2005 04:24, you wrote: > Charles, > > > You should find the power fail stuff very robust (ie. zero > > problems). If you > > don't then please shout ***loud***. > > the first problem found after a dozen power cycles ;-( > > I have a counter file that contains a number > that needs to be incremented. Increment is done as: > 1. Read the number from the counter file (open as O_RDONLY, read, close= ) > 2. Increment the number > 3. Write the number to a temporary file > 4. Rename temporary file to counter file > > Rename() suppose to be atomic per > http://www.opengroup.org/onlinepubs/007908799/xsh/rename.html: > "If the link named by the new argument exists, it is removed and > old renamed to new. In this case, a link named new will remain > visible to other processes throughout the renaming operation and > will refer either to the file referred to by new or old before > the operation began." > > After a few power cycle tests the counter file disappeared, but > the temp file is still there. rename() never reported failure. > > -------------------Code--------------------- > ret =3D rename(FnameBlockTmp,FnameBlock); > if(ret < 0) terminate(instance,ERR, > "writer: failed to rename tmp block file %s", > FnameBlockTmp); > > ------------------Output------------------- > running external script /mnt/flash/run.sh > writer 0 started > instance 0 terminated with status -1 > writer: failed to open block file /mnt/flash/blockno0 > writing status to > > # cd /mnt/flash/ > # ls > blockno.tmp0 jffs2tester run.sh test0 write.sh > init.sh lost+found status0 verify.sh > > # cat /proc/yaffs > YAFFS built:Apr 20 2005 14:39:45 > $Id: yaffs_fs.c,v 1.35 2004/10/20 20:12:43 charles Exp $ > $Id: yaffs_guts.c,v 1.37 2004/10/20 20:12:43 charles Exp $ > > Device yaffs > startBlock......... 1 > endBlock........... 8191 > chunkGroupBits..... 2 > chunkGroupSize..... 4 > nErasedBlocks...... 7 > nTnodesCreated..... 33400 > nFreeTnodes........ 2 > nObjectsCreated.... 32800 > nFreeObjects....... 83 > nFreeChunks........ 187105 > nPageWrites........ 6 > nPageReads......... 14 > nBlockErasures..... 0 > nGCCopies.......... 0 > garbageCollections. 0 > passiveGCs......... 0 > nRetriedWrites..... 0 > nRetireBlocks...... 0 > eccFixed........... 0 > eccUnfixed......... 0 > tagsEccFixed....... 0 > tagsEccUnfixed..... 8 > cacheHits.......... 0 > nDeletedFiles...... 32706 > nUnlinkedFiles..... 32706 > nBackgroudDeletions 0 > useNANDECC......... 1 > # > ------------------------------------------- > > Sergei From manningc2@actrix.gen.nz Fri Apr 29 08:03:57 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Fri, 29 Apr 2005 19:03:57 +1200 Subject: [Yaffs] Re: CVS updates --> df problem fixed In-Reply-To: References: <20050424112341.ADD4149CA@blood.actrix.co.nz> Message-ID: <20050429070339.23CC01585B@desire.actrix.co.nz> I have done a fix and tested it on my set-up. http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/yaffs_fs.c.diff?r1=3D1= .4&r2=3D1.5 Please try the yaffs_fs.c (1.5) just checked in. -- Charles On Friday 29 April 2005 05:53, Sergei Sharonov wrote: > Hi, > > > Mounting the second gives unexpected results using df -h > > Size: 16M Used: 16T(!) Available: 29.2M Use% -82% > > Same here - e.g. garbage from df. > > Sergei > > > > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From nick@cecomputing.co.uk Fri Apr 29 09:18:52 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Fri, 29 Apr 2005 09:18:52 +0100 Subject: [Yaffs] Re: CVS updates --> df problem fixed In-Reply-To: <20050429070339.23CC01585B@desire.actrix.co.nz> Message-ID: s@stoneboat.aleph1.co.uk > Subject: Re: [Yaffs] Re: CVS updates --> df problem fixed >=20 >=20 > I have done a fix and tested it on my set-up. >=20 > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/yaffs_fs.c.diff > ?r1=3D1.4&r2=3D1.5 >=20 > Please try the yaffs_fs.c (1.5) just checked in. >=20 Works for me. Thanks Charles. Nick --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.10.4 - Release Date: 27/04/2005 From iw3gtf@arcor.de Fri Apr 29 11:11:59 2005 From: iw3gtf@arcor.de (iw3gtf@arcor.de) Date: Fri, 29 Apr 2005 12:11:59 +0200 (CEST) Subject: [Yaffs] yaffs_InitialiseTags symbol undefined Message-ID: <24228400.1114769519132.JavaMail.ngmail@webmail-02.arcor-online.net> Hi, I'm trying to compile the yaffs2 cvs tree for a linux 2.6.9 kernel on an arm xscale proc. I'm working with a big samsunng nand flash (256 MB, 2K page size). Up to now I can compile the obj file yaffs.o using the Makefile that comes from the cvs but when I try to compile the kernel module (yaffs.ko) within the kernel source tree (make modules) I get an unresolved symbol: *** Warning: "yaffs_InitialiseTags" [fs/yaffs2/yaffs.ko] undefined! I tryed to grep the function in the yaffs2 dir. but I've only found a dectaration in yaffs_guts.h but no definition. Am I doing something wrong? thanks. Giorgio, iw3gtf@arcor.de From manningc2@actrix.gen.nz Fri Apr 29 12:13:11 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Fri, 29 Apr 2005 23:13:11 +1200 Subject: [Yaffs] yaffs_InitialiseTags symbol undefined In-Reply-To: <24228400.1114769519132.JavaMail.ngmail@webmail-02.arcor-online.net> References: <24228400.1114769519132.JavaMail.ngmail@webmail-02.arcor-online.net> Message-ID: <20050429111253.7805116395@desire.actrix.co.nz> Add yaffs_tagsvalidity to your build. I will fix the Makefile soon. Sorry I must go to bed. I have to get up in less than 4 hours. -- Charles On Friday 29 April 2005 22:11, you wrote: > Hi, > I'm trying to compile the yaffs2 cvs tree for a linux 2.6.9 kernel on a= n > arm xscale proc. I'm working with a big samsunng nand flash (256 MB, 2K > page size). Up to now I can compile the obj file yaffs.o using the Make= file > that comes from the cvs but when I try to compile the kernel module > (yaffs.ko) within the kernel source tree (make modules) I get an unreso= lved > symbol: > > *** Warning: "yaffs_InitialiseTags" [fs/yaffs2/yaffs.ko] undefined! > > I tryed to grep the function in the yaffs2 dir. but I've only found a > dectaration in yaffs_guts.h but no definition. > > Am I doing something wrong? > > thanks. > > Giorgio, iw3gtf@arcor.de > > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From nick@cecomputing.co.uk Fri Apr 29 13:07:10 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Fri, 29 Apr 2005 13:07:10 +0100 Subject: [Yaffs] yaffs_InitialiseTags symbol undefined In-Reply-To: <20050429111253.7805116395@desire.actrix.co.nz> Message-ID: > Add yaffs_tagsvalidity to your build. Charles.=20 As reported, I think its missing in the current cvs. Nick > I will fix the Makefile soon. >=20 > Sorry I must go to bed. I have to get up in less than 4 hours. > -- Charles >=20 > On Friday 29 April 2005 22:11, you wrote: > > Hi, > > I'm trying to compile the yaffs2 cvs tree for a linux 2.6.9 kernel = on an > > arm xscale proc. I'm working with a big samsunng nand flash (256 MB, = 2K > > page size). Up to now I can compile the obj file yaffs.o using=20 > the Makefile > > that comes from the cvs but when I try to compile the kernel module > > (yaffs.ko) within the kernel source tree (make modules) I get=20 > an unresolved > > symbol: > > > > *** Warning: "yaffs_InitialiseTags" [fs/yaffs2/yaffs.ko] undefined! > > > > I tryed to grep the function in the yaffs2 dir. but I've only found = a > > dectaration in yaffs_guts.h but no definition. > > > > Am I doing something wrong? > > > > thanks. > > > > Giorgio, iw3gtf@arcor.de > > > > _______________________________________________ > > yaffs mailing list > > yaffs@stoneboat.aleph1.co.uk > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs >=20 > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > --=20 > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.10.4 - Release Date: 27/04/2005 >=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.10.4 - Release Date: 27/04/2005 From ian@brightstareng.com Fri Apr 29 15:07:06 2005 From: ian@brightstareng.com (Ian McDonnell) Date: Fri, 29 Apr 2005 10:07:06 -0400 Subject: [Yaffs] Re: CVS updates (fix for bogus df stats) Message-ID: <200504291007.06484.ian@brightstareng.com> Sergei, Following patch should fix 'df' stats. -imcd diff -Naur orig-yaffs2/yaffs_fs.c yaffs2/yaffs_fs.c --- orig-yaffs2/yaffs_fs.c 2004-12-16 23:39:04.000000000 -0500 +++ yaffs2/yaffs_fs.c 2005-04-29 10:02:34.000000000 -0400 @@ -1206,6 +1206,7 @@ static int yaffs_statfs(struct super_block *sb, struct statfs *buf) #endif { + // yaffs_DeviceStruct yaffs_Device *dev = yaffs_SuperToDevice(sb); T(YAFFS_TRACE_OS,(KERN_DEBUG"yaffs_statfs\n")); @@ -1214,12 +1215,13 @@ buf->f_type = YAFFS_MAGIC; buf->f_bsize = sb->s_blocksize; buf->f_namelen = 255; - buf->f_blocks = (dev->endBlock - dev->startBlock + 1) * YAFFS_CHUNKS_PER _BLOCK/ - (sb->s_blocksize/YAFFS_BYTES_PER _CHUNK); + buf->f_blocks = ((dev->endBlock - dev->startBlock + 1) * + dev->nChunksPerBlock * dev->nBytesPerChunk) / sb->s_blocksize; buf->f_files = 0; buf->f_ffree = 0; buf->f_bfree = yaffs_GetNumberOfFreeChunks(dev)/ - (sb->s_blocksize/YAFFS_BYTES_PER _CHUNK); + (sb->s_blocksize/dev->nBytesPerChunk); + buf->f_bavail = buf->f_bfree; yaffs_GrossUnlock(dev); From manningc2@actrix.gen.nz Fri Apr 29 19:17:44 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Sat, 30 Apr 2005 06:17:44 +1200 Subject: [Yaffs] Re: CVS updates (fix for bogus df stats) In-Reply-To: <200504291007.06484.ian@brightstareng.com> References: <200504291007.06484.ian@brightstareng.com> Message-ID: <20050429181725.4B5A84694@blood.actrix.co.nz> Hi Ian Thanx for this. This is pretty much the same as the patch I put into CVS = a=20 few hours back. The patch I put in handles the cases where the chunk size > Linux block s= ize=20 or other way around, while I believe the patch you have here only handles= the=20 one case. Thanx -- Charles On Saturday 30 April 2005 02:07, Ian McDonnell wrote: > Sergei, > > Following patch should fix 'df' stats. > > -imcd > > > diff -Naur orig-yaffs2/yaffs_fs.c yaffs2/yaffs_fs.c > --- orig-yaffs2/yaffs_fs.c 2004-12-16 23:39:04.000000000 > -0500 > +++ yaffs2/yaffs_fs.c 2005-04-29 10:02:34.000000000 -0400 > @@ -1206,6 +1206,7 @@ > static int yaffs_statfs(struct super_block *sb, struct statfs > *buf) > #endif > { > + // yaffs_DeviceStruct > yaffs_Device *dev =3D yaffs_SuperToDevice(sb); > T(YAFFS_TRACE_OS,(KERN_DEBUG"yaffs_statfs\n")); > > @@ -1214,12 +1215,13 @@ > buf->f_type =3D YAFFS_MAGIC; > buf->f_bsize =3D sb->s_blocksize; > buf->f_namelen =3D 255; > - buf->f_blocks =3D (dev->endBlock - dev->startBlock + 1) * > YAFFS_CHUNKS_PER > _BLOCK/ > - (sb->s_blocksize/YAFFS_BYTES_PER > _CHUNK); > + buf->f_blocks =3D ((dev->endBlock - dev->startBlock + 1) * > + dev->nChunksPerBlock * dev->nBytesPerChunk) / > sb->s_blocksize; > buf->f_files =3D 0; > buf->f_ffree =3D 0; > buf->f_bfree =3D yaffs_GetNumberOfFreeChunks(dev)/ > - (sb->s_blocksize/YAFFS_BYTES_PER > _CHUNK); > + (sb->s_blocksize/dev->nBytesPerChunk); > + > buf->f_bavail =3D buf->f_bfree; > > yaffs_GrossUnlock(dev); > > > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From manningc2@actrix.gen.nz Fri Apr 29 19:12:16 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Sat, 30 Apr 2005 06:12:16 +1200 Subject: [Yaffs] yaffs_InitialiseTags symbol undefined In-Reply-To: References: Message-ID: <20050429181157.4B28415282@desire.actrix.co.nz> Sorry folks, missed that! yaffs_tagsvalidity.[ch] now in CVS -- CHarles On Saturday 30 April 2005 00:07, Nick Bane wrote: > > Add yaffs_tagsvalidity to your build. > > Charles. > As reported, I think its missing in the current cvs. > > Nick > > > I will fix the Makefile soon. > > > > Sorry I must go to bed. I have to get up in less than 4 hours. > > -- Charles > > > > On Friday 29 April 2005 22:11, you wrote: > > > Hi, > > > I'm trying to compile the yaffs2 cvs tree for a linux 2.6.9 kernel = on > > > an arm xscale proc. I'm working with a big samsunng nand flash (256= MB, > > > 2K page size). Up to now I can compile the obj file yaffs.o using > > > > the Makefile > > > > > that comes from the cvs but when I try to compile the kernel module > > > (yaffs.ko) within the kernel source tree (make modules) I get > > > > an unresolved > > > > > symbol: > > > > > > *** Warning: "yaffs_InitialiseTags" [fs/yaffs2/yaffs.ko] undefined! > > > > > > I tryed to grep the function in the yaffs2 dir. but I've only found= a > > > dectaration in yaffs_guts.h but no definition. > > > > > > Am I doing something wrong? > > > > > > thanks. > > > > > > Giorgio, iw3gtf@arcor.de > > > > > > _______________________________________________ > > > yaffs mailing list > > > yaffs@stoneboat.aleph1.co.uk > > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > > > _______________________________________________ > > yaffs mailing list > > yaffs@stoneboat.aleph1.co.uk > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > -- > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.308 / Virus Database: 266.10.4 - Release Date: 27/04/200= 5 From manningc2@actrix.gen.nz Sun May 1 20:46:00 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Mon, 2 May 2005 07:46:00 +1200 Subject: [Yaffs] Re: power fail testing -->rename problem In-Reply-To: References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> Message-ID: <20050501194537.9261C4408@blood.actrix.co.nz> I have investigated this and figured out a fix which I will code and test= in=20 the next few days. I considered a few approaches, but the mechanism I have settled on uses a= =20 "shadowing" field. The code went like this: if (newname exists) { unlink(newname); } rename(oldname,newname) The problem Sergei discovered was that the power could be lost between th= e=20 unlink and the rename, causing the file system to end up with no file cal= led=20 newname. We cannot just reverse the order because that could leave us with two nam= es=20 for different files -- bad! The new code will go like this if (newname exists) { rename_with_shadow(oldname,newname); // Point A unlink(newname); // Point B } rename(oldname,newname) A shadowing rename is like its non-shadowing brother except that it also=20 stores the object Id of the object that it "shadows". The semantics of=20 scanning a shadowing objectheader are different. If the shadowed object=20 exists (ie power lost at point A) then we unlink it. Essentially the shadowing gives us a way of determining priority between = two=20 like-named objects. Why do we rename without the shadow afterwards? This is done so that we=20 remove the shadow after it is no longer needed. If this was not done we w= ould=20 potentially have a shadow hanging around that would cause future files w= ith=20 the same object Id to get deleted. -- Charles On Friday 29 April 2005 05:36, Sergei Sharonov wrote: > Hi, > > > Rename() suppose to be atomic per > > http://www.opengroup.org/onlinepubs/007908799/xsh/rename.html: > > "If the link named by the new argument exists, it is removed and > > old renamed to new. In this case, a link named new will remain > > visible to other processes throughout the renaming operation and > > will refer either to the file referred to by new or old before > > the operation began." > > In yaffs_fs.c : yaffs_rename(): > removed =3D > yaffs_Unlink(yaffs_InodeToObject(new_dir),new_dentry->d_name.name); ret= Val > =3D yaffs_RenameObject(yaffs_InodeToObject(old_dir), > old_dentry->d_name.name, > yaffs_InodeToObject(new_dir), > new_dentry->d_name.name); > > > Is sequencing a problem here? > > Sergei > > > > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From sergei.sharonov@halliburton.com Tue May 3 17:03:26 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Tue, 3 May 2005 16:03:26 +0000 (UTC) Subject: [Yaffs] Re: power fail testing References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> Message-ID: Hi, > > You should find the power fail stuff very robust (ie. zero > > problems). If you > > don't then please shout ***loud***. The rename issue was worked around in application code. The second problem found after 33 power cycles. Symptoms: 1. rename/delete fails: # mv blockno.tmp0 blockno0 mv: unable to rename `blockno.tmp0': Directory not empty # rm blockno0 rm: unable to remove `blockno0': Directory not empty 2. The size of the destination file grew from 18 bytes to 512. # ls -l -rwxr-xr-x 1 root root 18 Jan 1 00:00 blockno.tmp0 -rwxr-xr-x 1 root root 512 Jan 1 00:00 blockno0 First 18 bytes are ok and the rest is filled with zeros: # hexdump blockno0 0000000 6c42 636f 206b 203d 3239 3435 3220 3234 0000010 0a36 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 * 0000200 # 3. Filesystem cannot be unmounted: # mount ....... /dev/mtdblock3 on /mnt/flash type yaffs (rw) ....... # umount /mnt/flash/ umount: /mnt/flash: Device or resource busy 4. dmesg reported: ...................... yaffs: dev is 31.3 name is "mtdblock3" yaffs: Attempting MTD mount on 31.3, "mtdblock3" block 2636 is bad block 3664 is bad nand_read_ecc: Failed ECC read, page 0x0002b1be **>>ecc error fix performed on chunk 176574:0 **>>ecc error unfixed on chunk 176574:1 **>>Block 5517 marked for retirement block 7143 is bad eth0: Link now 100-FullDuplex nfs warning: mount version older than kernel **>>ecc error fix performed on chunk 176574:0 **>>ecc error fix performed on chunk 176574:1 **>>Block 5517 marked for retirement .................................. 5. Sometime during testing device developed an extra bad block. I am inclined to believe that it is not really bad since only a few erases were executed. 6. hexdump from /dev/mtd3 produces a lot of: nand_read_ecc: Failed ECC read, page NNN *********************************************************** Additional info: linux 2.6.10 + March 28th 2005 mtd .............. SmartMedia card inserted. NAND device: Manufacturer ID: 0x98, Chip ID: 0x79 (Toshiba NAND 128MiB 3,3V 8-bi t) Scanning device for bad blocks Bad eraseblock 2636 at 0x02930000 Bad eraseblock 3664 at 0x03940000 Bad eraseblock 7143 at 0x06f9c000 Creating 1 MTD partitions on "NAND 128MiB 3,3V 8-bit": 0x00000000-0x08000000 : "Storage" mtd: Giving out device 3 to Storage ............... # cat /proc/yaffs YAFFS built:Apr 20 2005 14:39:45 $Id: yaffs_fs.c,v 1.35 2004/10/20 20:12:43 charles Exp $ $Id: yaffs_guts.c,v 1.37 2004/10/20 20:12:43 charles Exp $ Device yaffs startBlock......... 1 endBlock........... 8191 chunkGroupBits..... 2 chunkGroupSize..... 4 nErasedBlocks...... 7 nTnodesCreated..... 34100 nFreeTnodes........ 50 nObjectsCreated.... 32800 nFreeObjects....... 83 nFreeChunks........ 177913 nPageWrites........ 27 nPageReads......... 67289 nBlockErasures..... 0 nGCCopies.......... 0 garbageCollections. 0 passiveGCs......... 0 nRetriedWrites..... 0 nRetireBlocks...... 0 eccFixed........... 0 eccUnfixed......... 0 tagsEccFixed....... 0 tagsEccUnfixed..... 9 cacheHits.......... 0 nDeletedFiles...... 32702 nUnlinkedFiles..... 32702 nBackgroudDeletions 0 useNANDECC......... 1 # Sergei Sharonov From jeanwelly Sun May 8 14:39:42 2005 From: jeanwelly (jeanwelly) Date: Sun, 8 May 2005 21:39:42 +0800 Subject: [Yaffs] Yaffs on 2.6.11 Message-ID: I want to usr yaffs on 2.6.11 + s3c2410, K9F1208 nandflash. I can't access the CVS now, can you send me the yaffs.tar.gz file that can be used as root fs on 2.6.11. --=20 jeanwelly Email: jeanwelly@gmail.com China From manningc2@actrix.gen.nz Sun May 8 20:00:09 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Mon, 9 May 2005 07:00:09 +1200 Subject: [Yaffs] Yaffs on 2.6.11 In-Reply-To: References: Message-ID: <20050508185929.94B7A162B0@desire.actrix.co.nz> On Monday 09 May 2005 01:39, jeanwelly wrote: > I want to usr yaffs on 2.6.11 + s3c2410, K9F1208 nandflash. > I can't access the CVS now, can you send me the yaffs.tar.gz file that > can be used as root fs on 2.6.11. You can fetch an automatic tar file from=20 http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/cvs_root.tar.gz?tarball=3D1 -- CHarles From sergei.sharonov@halliburton.com Mon May 9 21:50:59 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Mon, 9 May 2005 20:50:59 +0000 (UTC) Subject: [Yaffs] Re: power fail testing References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> Message-ID: Hi, 1. It looks like, on occasion, a power cycle will cause FLASH to develop a bad erase block. After 549 power cycles I got 12 extra bad blocks in addition to the 2 original (manufacturer marked) bad blocks. I do not believe these blocks are actually bad because I have not erases FLASH nowhere near the maximum count. 2. Finally I got a message: nand_read_ecc: Failed ECC read, page 0x0002710e and after a power cycle verification application failed to verify data: read=0xec expected=0xe4 Looks like one bit did not program from 1 to 0, but why didn't ecc catch it? I'll take a look at the rest of the file tomorrow.. Sergei Sharonov From jeanwelly Tue May 10 09:44:49 2005 From: jeanwelly (jeanwelly) Date: Tue, 10 May 2005 16:44:49 +0800 Subject: [Yaffs] Yaffs on 2.6.11 In-Reply-To: <20050508185929.94B7A162B0@desire.actrix.co.nz> References: <20050508185929.94B7A162B0@desire.actrix.co.nz> Message-ID: Thanks. I have compiled yaffs into kernel. It can work with cramfs(root fs partition) and yaffs(usr partition). But error found when use yaffs as root fs : I use mkyaffsimage to get the rootyaffs.img. linux command line is: "noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc console=3Dtty"MACH_TYPE =3D 193 NOW, Booting Linux...... Uncompressing Linux........................................................= .....Linux version 2.6.11 (root@localhost.localdomain) (gcc version 3.4.1) #35 Tue M5CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Machine: SMDK2410 ATAG_INITRD is deprecated; please update your bootloader. Memory policy: ECC disabled, Data cache writeback CPU S3C2410 (id 0x32410000) S3C2410: core 200.000 MHz, memory 100.000 MHz, peripheral 50.000 MHz S3C2410 Clock control, (c) 2004 Simtec Electronics Built 1 zonelists Kernel command line: noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc console=3DttySAC0irq: clearing pending ext status 00000300 irq: clearing subpending status 00000003 irq: clearing subpending status 00000002 PID hash table entries: 512 (order: 9, 8192 bytes) timer tcon=3D00000000, tcnt a2c1, tcfg 00000200,00000000, usec 00001eb8 Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB =3D 64MB total Memory: 62848KB available (1573K code, 347K data, 80K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 S3C2410: Initialising architecture NetWinder Floating Point Emulator V0.97 (double precision) VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au) devfs: devfs_debug: 0x0 devfs: boot_options: 0x1 Initializing Cryptographic API Real Time Clock Driver v1.12 S3C2410 RTC, (c) 2004 Simtec Electronics S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics s3c2410_serial0 at MMIO 0x50000000 (irq =3D 70) is a S3C2410 s3c2410_serial1 at MMIO 0x50004000 (irq =3D 73) is a S3C2410 s3c2410_serial2 at MMIO 0x50008000 (irq =3D 76) is a S3C2410 io scheduler noop registered Cirrus Logic CS8900A driver for Linux (Modified for SMDK2410) eth0: CS8900A rev E at 0xe0000300 irq=3D53, no eeprom , addr: 08: 0:3E:26:0= A:5B S3C2410 NAND Driver, (c) 2004 Simtec Electronics s3c2410-nand: mapped registers at c4a00000 s3c2410-nand: timing: Tacls 10ns, Twrph0 40ns, Twrph1 10ns NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bi)NAND_ECC_NONE selected by board driver. This is not recommended !! Scanning device for bad blocks Bad eraseblock 307 at 0x004cc000 >>>>>>>>>> bad block???? !!!!!!!!!!!! Bad eraseblock 308 at 0x004d0000 Bad eraseblock 309 at 0x004d4000 Creating 5 MTD partitions on "NAND 64MiB 3,3V 8-bit": 0x00000000-0x00020000 : "vivi" mtd: Giving out device 0 to vivi 0x00020000-0x00030000 : "param" mtd: Giving out device 1 to param 0x00030000-0x00200000 : "kernel" mtd: Giving out device 2 to kernel 0x00200000-0x00500000 : "root" mtd: Giving out device 3 to root 0x00400000-0x03f00000 : "usr" mtd: Giving out device 4 to usr mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) NET: Registered protocol family 1 Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. Reading data from NAND FLASH without ECC is not recommended yaffs: dev is 32505859 name is "(unavailable)" VFS: Mounted root (yaffs filesystem). mount_devfs_fs(): unable to mount devfs, err: -2 Freeing init memory: 80K Warning: unable to open an initial console. Kernel panic - not syncing: No init found. Try passing init=3D option to k= ernel. So I want to erase the nand first. Using NFS, then, [root@localhost root_china]# file mkyaffs.arm mkyaffs.arm: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped [root@localhost root_china]# file mkyaffsimage mkyaffsimage: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped How can I successfully use yaffs as root fs. On 5/9/05, Charles Manning wrote: > On Monday 09 May 2005 01:39, jeanwelly wrote: > > I want to usr yaffs on 2.6.11 + s3c2410, K9F1208 nandflash. > > I can't access the CVS now, can you send me the yaffs.tar.gz file that > > can be used as root fs on 2.6.11. >=20 > You can fetch an automatic tar file from > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/cvs_root.tar.gz?tarball=3D1 >=20 > -- CHarles >=20 >=20 --=20 jeanwelly Email: jeanwelly@gmail.com China From jeanwelly Tue May 10 09:50:01 2005 From: jeanwelly (jeanwelly) Date: Tue, 10 May 2005 16:50:01 +0800 Subject: [Yaffs] Yaffs on 2.6.11 In-Reply-To: <20050508185929.94B7A162B0@desire.actrix.co.nz> References: <20050508185929.94B7A162B0@desire.actrix.co.nz> Message-ID: Thanks. I have compiled yaffs into kernel. It can work with cramfs(root fs partition) and yaffs(usr partition). But error found when use yaffs as root fs : I use mkyaffsimage to get the rootyaffs.img. linux command line is: "noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc console=3Dtty"MACH_TYPE =3D 193 NOW, Booting Linux...... Uncompressing Linux........................................................= .....Linux version 2.6.11 (root@localhost.localdomain) (gcc version 3.4.1) #35 Tue M5CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Machine: SMDK2410 ATAG_INITRD is deprecated; please update your bootloader. Memory policy: ECC disabled, Data cache writeback CPU S3C2410 (id 0x32410000) S3C2410: core 200.000 MHz, memory 100.000 MHz, peripheral 50.000 MHz S3C2410 Clock control, (c) 2004 Simtec Electronics Built 1 zonelists Kernel command line: noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc console=3DttySAC0irq: clearing pending ext status 00000300 irq: clearing subpending status 00000003 irq: clearing subpending status 00000002 PID hash table entries: 512 (order: 9, 8192 bytes) timer tcon=3D00000000, tcnt a2c1, tcfg 00000200,00000000, usec 00001eb8 Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB =3D 64MB total Memory: 62848KB available (1573K code, 347K data, 80K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 S3C2410: Initialising architecture NetWinder Floating Point Emulator V0.97 (double precision) VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au) devfs: devfs_debug: 0x0 devfs: boot_options: 0x1 Initializing Cryptographic API Real Time Clock Driver v1.12 S3C2410 RTC, (c) 2004 Simtec Electronics S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics s3c2410_serial0 at MMIO 0x50000000 (irq =3D 70) is a S3C2410 s3c2410_serial1 at MMIO 0x50004000 (irq =3D 73) is a S3C2410 s3c2410_serial2 at MMIO 0x50008000 (irq =3D 76) is a S3C2410 io scheduler noop registered Cirrus Logic CS8900A driver for Linux (Modified for SMDK2410) eth0: CS8900A rev E at 0xe0000300 irq=3D53, no eeprom , addr: 08: 0:3E:26:0= A:5B S3C2410 NAND Driver, (c) 2004 Simtec Electronics s3c2410-nand: mapped registers at c4a00000 s3c2410-nand: timing: Tacls 10ns, Twrph0 40ns, Twrph1 10ns NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bi)NAND_ECC_NONE selected by board driver. This is not recommended !! Scanning device for bad blocks Bad eraseblock 307 at 0x004cc000 >>>>>>>>>> bad block???? !!!!!!!!!!!! Bad eraseblock 308 at 0x004d0000 Bad eraseblock 309 at 0x004d4000 Creating 5 MTD partitions on "NAND 64MiB 3,3V 8-bit": 0x00000000-0x00020000 : "vivi" mtd: Giving out device 0 to vivi 0x00020000-0x00030000 : "param" mtd: Giving out device 1 to param 0x00030000-0x00200000 : "kernel" mtd: Giving out device 2 to kernel 0x00200000-0x00500000 : "root" mtd: Giving out device 3 to root 0x00400000-0x03f00000 : "usr" mtd: Giving out device 4 to usr mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) NET: Registered protocol family 1 Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. Reading data from NAND FLASH without ECC is not recommended yaffs: dev is 32505859 name is "(unavailable)" VFS: Mounted root (yaffs filesystem). mount_devfs_fs(): unable to mount devfs, err: -2 Freeing init memory: 80K Warning: unable to open an initial console. Kernel panic - not syncing: No init found. Try passing init=3D option to k= ernel. So I want to erase the nand first. Using NFS, then, [root@localhost root_china]# file mkyaffs.arm mkyaffs.arm: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped [root@localhost root_china]# file mkyaffsimage mkyaffsimage: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped How can I successfully use yaffs as root fs. On 5/9/05, Charles Manning wrote: > On Monday 09 May 2005 01:39, jeanwelly wrote: > > I want to usr yaffs on 2.6.11 + s3c2410, K9F1208 nandflash. > > I can't access the CVS now, can you send me the yaffs.tar.gz file that > > can be used as root fs on 2.6.11. >=20 > You can fetch an automatic tar file from > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/cvs_root.tar.gz?tarball=3D1 >=20 > -- CHarles >=20 >=20 --=20 jeanwelly Email: jeanwelly@gmail.com China From jeanwelly Tue May 10 10:00:13 2005 From: jeanwelly (jeanwelly) Date: Tue, 10 May 2005 17:00:13 +0800 Subject: [Yaffs] Yaffs on 2.6.11 In-Reply-To: <20050508185929.94B7A162B0@desire.actrix.co.nz> References: <20050508185929.94B7A162B0@desire.actrix.co.nz> Message-ID: Thanks. I have compiled yaffs into kernel. It can work with cramfs(root fs partition) and yaffs(usr partition). But error found when use yaffs as root fs : I use mkyaffsimage to get the rootyaffs.img. linux command line is: "noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc console=3Dtty"MACH_TYPE =3D 193 NOW, Booting Linux...... Uncompressing Linux........................................................= .....Linux version 2.6.11 (root@localhost.localdomain) (gcc version 3.4.1) #35 Tue M5CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Machine: SMDK2410 ATAG_INITRD is deprecated; please update your bootloader. Memory policy: ECC disabled, Data cache writeback CPU S3C2410 (id 0x32410000) S3C2410: core 200.000 MHz, memory 100.000 MHz, peripheral 50.000 MHz S3C2410 Clock control, (c) 2004 Simtec Electronics Built 1 zonelists Kernel command line: noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc console=3DttySAC0irq: clearing pending ext status 00000300 irq: clearing subpending status 00000003 irq: clearing subpending status 00000002 PID hash table entries: 512 (order: 9, 8192 bytes) timer tcon=3D00000000, tcnt a2c1, tcfg 00000200,00000000, usec 00001eb8 Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB =3D 64MB total Memory: 62848KB available (1573K code, 347K data, 80K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 S3C2410: Initialising architecture NetWinder Floating Point Emulator V0.97 (double precision) VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au) devfs: devfs_debug: 0x0 devfs: boot_options: 0x1 Initializing Cryptographic API Real Time Clock Driver v1.12 S3C2410 RTC, (c) 2004 Simtec Electronics S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics s3c2410_serial0 at MMIO 0x50000000 (irq =3D 70) is a S3C2410 s3c2410_serial1 at MMIO 0x50004000 (irq =3D 73) is a S3C2410 s3c2410_serial2 at MMIO 0x50008000 (irq =3D 76) is a S3C2410 io scheduler noop registered Cirrus Logic CS8900A driver for Linux (Modified for SMDK2410) eth0: CS8900A rev E at 0xe0000300 irq=3D53, no eeprom , addr: 08: 0:3E:26:0= A:5B S3C2410 NAND Driver, (c) 2004 Simtec Electronics s3c2410-nand: mapped registers at c4a00000 s3c2410-nand: timing: Tacls 10ns, Twrph0 40ns, Twrph1 10ns NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bi)NAND_ECC_NONE selected by board driver. This is not recommended !! Scanning device for bad blocks Bad eraseblock 307 at 0x004cc000 >>>>>>>>>> bad block???? !!!!!!!!!!!! Bad eraseblock 308 at 0x004d0000 Bad eraseblock 309 at 0x004d4000 Creating 5 MTD partitions on "NAND 64MiB 3,3V 8-bit": 0x00000000-0x00020000 : "vivi" mtd: Giving out device 0 to vivi 0x00020000-0x00030000 : "param" mtd: Giving out device 1 to param 0x00030000-0x00200000 : "kernel" mtd: Giving out device 2 to kernel 0x00200000-0x00500000 : "root" mtd: Giving out device 3 to root 0x00400000-0x03f00000 : "usr" mtd: Giving out device 4 to usr mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) NET: Registered protocol family 1 Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. Reading data from NAND FLASH without ECC is not recommended yaffs: dev is 32505859 name is "(unavailable)" VFS: Mounted root (yaffs filesystem). mount_devfs_fs(): unable to mount devfs, err: -2 Freeing init memory: 80K Warning: unable to open an initial console. Kernel panic - not syncing: No init found. Try passing init=3D option to k= ernel. So I want to erase the nand first. Using NFS, then, [root@localhost root_china]# file mkyaffs.arm mkyaffs.arm: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped [root@localhost root_china]# file mkyaffsimage mkyaffsimage: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped How can I successfully use yaffs as root fs. On 5/9/05, Charles Manning wrote: > On Monday 09 May 2005 01:39, jeanwelly wrote: > > I want to usr yaffs on 2.6.11 + s3c2410, K9F1208 nandflash. > > I can't access the CVS now, can you send me the yaffs.tar.gz file that > > can be used as root fs on 2.6.11. >=20 > You can fetch an automatic tar file from > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/cvs_root.tar.gz?tarball=3D1 >=20 > -- CHarles >=20 >=20 --=20 jeanwelly Email: jeanwelly@gmail.com China From jeanwelly Tue May 10 09:55:11 2005 From: jeanwelly (jeanwelly) Date: Tue, 10 May 2005 16:55:11 +0800 Subject: [Yaffs] Yaffs on 2.6.11 In-Reply-To: <20050508185929.94B7A162B0@desire.actrix.co.nz> References: <20050508185929.94B7A162B0@desire.actrix.co.nz> Message-ID: Thanks. I have compiled yaffs into kernel. It can work with cramfs(root fs partition) and yaffs(usr partition). But error found when use yaffs as root fs : I use mkyaffsimage to get the rootyaffs.img. linux command line is: "noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc console=3Dtty"MACH_TYPE =3D 193 NOW, Booting Linux...... Uncompressing Linux........................................................= .....Linux version 2.6.11 (root@localhost.localdomain) (gcc version 3.4.1) #35 Tue M5CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Machine: SMDK2410 ATAG_INITRD is deprecated; please update your bootloader. Memory policy: ECC disabled, Data cache writeback CPU S3C2410 (id 0x32410000) S3C2410: core 200.000 MHz, memory 100.000 MHz, peripheral 50.000 MHz S3C2410 Clock control, (c) 2004 Simtec Electronics Built 1 zonelists Kernel command line: noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc console=3DttySAC0irq: clearing pending ext status 00000300 irq: clearing subpending status 00000003 irq: clearing subpending status 00000002 PID hash table entries: 512 (order: 9, 8192 bytes) timer tcon=3D00000000, tcnt a2c1, tcfg 00000200,00000000, usec 00001eb8 Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB =3D 64MB total Memory: 62848KB available (1573K code, 347K data, 80K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 S3C2410: Initialising architecture NetWinder Floating Point Emulator V0.97 (double precision) VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au) devfs: devfs_debug: 0x0 devfs: boot_options: 0x1 Initializing Cryptographic API Real Time Clock Driver v1.12 S3C2410 RTC, (c) 2004 Simtec Electronics S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics s3c2410_serial0 at MMIO 0x50000000 (irq =3D 70) is a S3C2410 s3c2410_serial1 at MMIO 0x50004000 (irq =3D 73) is a S3C2410 s3c2410_serial2 at MMIO 0x50008000 (irq =3D 76) is a S3C2410 io scheduler noop registered Cirrus Logic CS8900A driver for Linux (Modified for SMDK2410) eth0: CS8900A rev E at 0xe0000300 irq=3D53, no eeprom , addr: 08: 0:3E:26:0= A:5B S3C2410 NAND Driver, (c) 2004 Simtec Electronics s3c2410-nand: mapped registers at c4a00000 s3c2410-nand: timing: Tacls 10ns, Twrph0 40ns, Twrph1 10ns NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bi)NAND_ECC_NONE selected by board driver. This is not recommended !! Scanning device for bad blocks Bad eraseblock 307 at 0x004cc000 >>>>>>>>>> bad block???? !!!!!!!!!!!! Bad eraseblock 308 at 0x004d0000 Bad eraseblock 309 at 0x004d4000 Creating 5 MTD partitions on "NAND 64MiB 3,3V 8-bit": 0x00000000-0x00020000 : "vivi" mtd: Giving out device 0 to vivi 0x00020000-0x00030000 : "param" mtd: Giving out device 1 to param 0x00030000-0x00200000 : "kernel" mtd: Giving out device 2 to kernel 0x00200000-0x00500000 : "root" mtd: Giving out device 3 to root 0x00400000-0x03f00000 : "usr" mtd: Giving out device 4 to usr mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) NET: Registered protocol family 1 Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. Reading data from NAND FLASH without ECC is not recommended yaffs: dev is 32505859 name is "(unavailable)" VFS: Mounted root (yaffs filesystem). mount_devfs_fs(): unable to mount devfs, err: -2 Freeing init memory: 80K Warning: unable to open an initial console. Kernel panic - not syncing: No init found. Try passing init=3D option to k= ernel. So I want to erase the nand first. Using NFS, then, [root@localhost root_china]# file mkyaffs.arm mkyaffs.arm: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped [root@localhost root_china]# file mkyaffsimage mkyaffsimage: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped How can I successfully use yaffs as root fs. On 5/9/05, Charles Manning wrote: > On Monday 09 May 2005 01:39, jeanwelly wrote: > > I want to usr yaffs on 2.6.11 + s3c2410, K9F1208 nandflash. > > I can't access the CVS now, can you send me the yaffs.tar.gz file that > > can be used as root fs on 2.6.11. >=20 > You can fetch an automatic tar file from > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/cvs_root.tar.gz?tarball=3D1 >=20 > -- CHarles >=20 >=20 --=20 jeanwelly Email: jeanwelly@gmail.com China From nick@cecomputing.co.uk Tue May 10 12:35:38 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Tue, 10 May 2005 12:35:38 +0100 Subject: [Balloon] Re: [Yaffs] Yaffs on 2.6.11 In-Reply-To: Message-ID: Some thoughts. I think the clue here might be the inability to mount devfs_fs. I recall building a boot yaffs image where the root was not read/write = and that caused trouble. Do check permissions. I note that devfs_debug is zero. Increasing that may be useful. You are not using ECC it seems. Hmm .. be very afraid. Nick Bane > -----Original Message----- > From: balloon-admin@balloonboard.org > [mailto:balloon-admin@balloonboard.org]On Behalf Of jeanwelly > Sent: 10 May 2005 09:55 > To: manningc2@actrix.gen.nz > Cc: yaffs@stoneboat.aleph1.co.uk; Balloon@balloonboard.org > Subject: [Balloon] Re: [Yaffs] Yaffs on 2.6.11 >=20 >=20 > Thanks. > I have compiled yaffs into kernel. > It can work with cramfs(root fs partition) and yaffs(usr partition). > But error found when use yaffs as root fs : > I use mkyaffsimage to get the rootyaffs.img. >=20 > linux command line is: "noinitrd root=3D/dev/mtdblock/3 = init=3D/linuxrc > console=3Dtty"MACH_TYPE =3D 193 > NOW, Booting Linux...... > Uncompressing=20 > = Linux.............................................................Linux > version 2.6.11 (root@localhost.localdomain) (gcc version 3.4.1) #35 > Tue M5CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) > CPU0: D VIVT write-back cache > CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets > CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets > Machine: SMDK2410 > ATAG_INITRD is deprecated; please update your bootloader. > Memory policy: ECC disabled, Data cache writeback > CPU S3C2410 (id 0x32410000) > S3C2410: core 200.000 MHz, memory 100.000 MHz, peripheral 50.000 MHz > S3C2410 Clock control, (c) 2004 Simtec Electronics > Built 1 zonelists > Kernel command line: noinitrd root=3D/dev/mtdblock/3 init=3D/linuxrc > console=3DttySAC0irq: clearing pending ext status 00000300 > irq: clearing subpending status 00000003 > irq: clearing subpending status 00000002 > PID hash table entries: 512 (order: 9, 8192 bytes) > timer tcon=3D00000000, tcnt a2c1, tcfg 00000200,00000000, usec = 00001eb8 > Console: colour dummy device 80x30 > Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) > Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) > Memory: 64MB =3D 64MB total > Memory: 62848KB available (1573K code, 347K data, 80K init) > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > CPU: Testing write buffer coherency: ok > NET: Registered protocol family 16 > S3C2410: Initialising architecture > NetWinder Floating Point Emulator V0.97 (double precision) > VFS: Disk quotas dquot_6.5.1 > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au) > devfs: devfs_debug: 0x0 > devfs: boot_options: 0x1 > Initializing Cryptographic API > Real Time Clock Driver v1.12 > S3C2410 RTC, (c) 2004 Simtec Electronics > S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics > s3c2410_serial0 at MMIO 0x50000000 (irq =3D 70) is a S3C2410 > s3c2410_serial1 at MMIO 0x50004000 (irq =3D 73) is a S3C2410 > s3c2410_serial2 at MMIO 0x50008000 (irq =3D 76) is a S3C2410 > io scheduler noop registered > Cirrus Logic CS8900A driver for Linux (Modified for SMDK2410) > eth0: CS8900A rev E at 0xe0000300 irq=3D53, no eeprom , addr: 08:=20 > 0:3E:26:0A:5B > S3C2410 NAND Driver, (c) 2004 Simtec Electronics > s3c2410-nand: mapped registers at c4a00000 > s3c2410-nand: timing: Tacls 10ns, Twrph0 40ns, Twrph1 10ns > NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB > 3,3V 8-bi)NAND_ECC_NONE selected by board driver. This is not > recommended !! > Scanning device for bad blocks > Bad eraseblock 307 at 0x004cc000 >>>>>>>>>> bad block???? = !!!!!!!!!!!! > Bad eraseblock 308 at 0x004d0000 > Bad eraseblock 309 at 0x004d4000 > Creating 5 MTD partitions on "NAND 64MiB 3,3V 8-bit": > 0x00000000-0x00020000 : "vivi" > mtd: Giving out device 0 to vivi > 0x00020000-0x00030000 : "param" > mtd: Giving out device 1 to param > 0x00030000-0x00200000 : "kernel" > mtd: Giving out device 2 to kernel > 0x00200000-0x00500000 : "root" > mtd: Giving out device 3 to root > 0x00400000-0x03f00000 : "usr" > mtd: Giving out device 4 to usr > mice: PS/2 mouse device common for all mice > NET: Registered protocol family 2 > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP established hash table entries: 4096 (order: 3, 32768 bytes) > TCP bind hash table entries: 4096 (order: 2, 16384 bytes) > TCP: Hash tables configured (established 4096 bind 4096) > NET: Registered protocol family 1 > Root-NFS: No NFS server available, giving up. > VFS: Unable to mount root fs via NFS, trying floppy. > Reading data from NAND FLASH without ECC is not recommended > yaffs: dev is 32505859 name is "(unavailable)" > VFS: Mounted root (yaffs filesystem). > mount_devfs_fs(): unable to mount devfs, err: -2 > Freeing init memory: 80K > Warning: unable to open an initial console. > Kernel panic - not syncing: No init found. Try passing init=3D=20 > option to kernel. >=20 > So I want to erase the nand first. > Using NFS, then, > [root@localhost root_china]# file mkyaffs.arm > mkyaffs.arm: ELF 32-bit LSB executable, ARM, version 1 (ARM), for > GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped > [root@localhost root_china]# file mkyaffsimage > mkyaffsimage: ELF 32-bit LSB executable, Intel 80386, version 1 > (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), > not stripped >=20 > How can I successfully use yaffs as root fs. >=20 >=20 >=20 > On 5/9/05, Charles Manning wrote: > > On Monday 09 May 2005 01:39, jeanwelly wrote: > > > I want to usr yaffs on 2.6.11 + s3c2410, K9F1208 nandflash. > > > I can't access the CVS now, can you send me the yaffs.tar.gz file = that > > > can be used as root fs on 2.6.11. > >=20 > > You can fetch an automatic tar file from > > = http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/cvs_root.tar.gz?tarball=3D1 > >=20 > > -- CHarles > >=20 > >=20 >=20 >=20 > --=20 > jeanwelly > Email: jeanwelly@gmail.com > China >=20 > _______________________________________________ > Balloon mailing list > Balloon@balloonboard.org > http://balloonboard.org/mailman/listinfo/balloon > --=20 > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 09/05/2005 >=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 09/05/2005 From nick@cecomputing.co.uk Tue May 10 18:56:45 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Tue, 10 May 2005 18:56:45 +0100 Subject: [Yaffs] bootldr/yaffs2/samosa Message-ID: I just updated the bootldr34 source and binaries on the husaberg site = for balloon to fix some yaffs2 problems (see below). I also updated the subversion repository with the 2.4.25 kernel that = does the same. I am somewhat new to subversion and I think I have the structure set up = unconventially. What you need to do is svn co = svn://husaberg.toby-churchill.com/linux-2.25/tags/vrs2-tcl1 You can also browse the repository on the web via a viwecvs link. Charles/Thomas: I note that the latest mtd (a recent cvs snapshot for = example) treats reads of the oob differently depending on whether one is = reading it raw with nand_read_oob or via nand_read_ecc. This results in = the auto placement shifting data around (by 16 bits for 64 byte oob nand = chips) if one uses auto placement. As yaffs does a quick raw scan of the = oob at boot, the values should not differ from the raw and ecc versions. = I was expecting to be able to pass a nand_oobinfo structure to confound = this in nand_read_ecc and nand_write_ecc but discover that either the = placement is AUTOPLACE (in which case it ignores the rest of the oobinfo = and fetches the nand-wide version instead) or is is PLACE in which case = one gets a blind copy of eccsteps*sizeof(int) data items instead of = eccsteps*3 bytes as I had expected or its a value that isn't used on = reading ecc anyway. The upshot of that previous tangle is that one must have the whole of a = nand chip set to a non standard configuration (ie yaffs2) rather than on = a per-partition basis. Alternatively I am not understanding it = correctly. Feedback requested. Nick ----------------------- Nick Bane nick@cecomputing.co.uk +44 (0)1954 719270=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 09/05/2005 From sergei.sharonov@halliburton.com Wed May 11 21:51:24 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Wed, 11 May 2005 20:51:24 +0000 (UTC) Subject: [Yaffs] Re: power fail testing References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> Message-ID: Hi, > 2. Finally I got a message: > nand_read_ecc: Failed ECC read, page 0x0002710e > and after a power cycle verification application failed to verify data: > read=0xec expected=0xe4 > Looks like one bit did not program from 1 to 0, but why didn't ecc catch it? > I'll take a look at the rest of the file tomorrow.. OK, it is reproducible: ------------------------ verifier 0 started nand_read_ecc: Failed ECC read, page 0x00004a77 nand_read_ecc: Failed ECC read, page 0x00004a77 instance 0 terminated with status -1 verifyBlock: verify failed, instance=0 block=95488 blockSize=1024 position=578, read=0xee expected=0xe6 ------------------------ All messages except nand_read_ecc are produced by test application. Application instance number = 0 (only one was run) Data was written/verified in 1 kB blocks (nothing to do with "erase block") Verify failed at position 578 of the block number 95488. I think it maps to the physical NAND address 0x0094ee42. See nand dump below. Looks like ECC fails for whatever is the reason and cannot correct bit error. Makes sense? Then the filesystem quitely returned bad data?! BTW, "Failed ECC read" message is produced when nand_correct_data() function fails. Here is a failed page dump from mtd device: # /mnt/nfs/nanddump -p -s 9760256 -l 32 /dev/mtd3 Block size 16384, nand_read_ecc: Failed ECC read, page 0x00004a77 nand_read_ecc: Failed ECC read, page 0x00004a77 page size 512, OOB size 16 Dumping data starting at 0x0094ee00 and ending at 0x0094ee20... 0x0094ee00: f3 e3 d7 cc 96 e7 3b ad 86 cf ff 50 a8 30 78 86 0x0094ee10: 76 e9 7f 11 8a bf 8d ec 0b c8 c3 99 84 be 1f 77 0x0094ee20: a2 f6 43 38 dd 7e e5 63 4d e5 b3 f6 15 2c 7c 8b 0x0094ee30: 15 fc 9c 9f bb 29 8b c6 f1 4e 5f 75 0c 7e ec ae 0x0094ee40: 74 2f ee 51 ad cc b4 fb b1 68 f1 c6 94 6d 51 a9 0x0094ee50: 69 ed 48 24 17 d3 ea 08 21 4a 7e 2d c8 6a dc 3d 0x0094ee60: 9a c2 8e 47 8e 43 42 3f ab 33 05 3f a1 56 e8 0a 0x0094ee70: 44 30 2f 5b 03 19 63 24 63 e1 51 2c 4c 2d 69 e6 0x0094ee80: f0 f7 2d 7e 3a 70 be e5 a3 c3 24 44 1a 0c 4f 5e 0x0094ee90: 3c 7e b9 3f 97 1c 63 fb fe b5 27 4a e2 90 30 d2 0x0094eea0: 87 5d 51 c2 cd 0f a7 71 d2 cc b5 ec d8 04 4a 15 0x0094eeb0: 82 03 54 1a 20 b8 15 1e 6d 3c 68 4f cc 98 22 53 0x0094eec0: f5 73 15 c3 82 bd 34 54 89 e9 41 61 ee 8b 76 70 0x0094eed0: 8f cb 8a af 83 9f cd f0 db 35 3f a7 cd 61 fb c2 0x0094eee0: d4 10 85 56 cd b9 ab 56 a3 ec b8 91 77 2e 01 06 0x0094eef0: f9 8c b5 7c 2b 82 6e 07 b7 ac ae 84 0d a9 47 e2 0x0094ef00: ba cc 38 87 86 e3 de 29 cf 96 ba 47 c4 bb 4d be 0x0094ef10: 47 03 3a f3 85 a7 7a 3d 53 28 c1 60 d2 48 42 8c 0x0094ef20: d5 7b 13 5b 5e f1 84 2e 87 3e 75 4c f9 c2 0a 41 0x0094ef30: c5 44 b4 4b eb 2e 88 3e 56 49 9f 28 52 e1 b4 27 0x0094ef40: 5c c8 82 bb b9 06 e9 41 44 5e 8d 3d 20 97 7e e6 0x0094ef50: db 32 31 e7 70 b9 05 b7 02 a4 df 54 86 94 7b e2 0x0094ef60: 5c fd dd 15 03 86 56 47 e4 e3 85 05 7a 03 eb 56 0x0094ef70: 36 1c 1d 96 d5 22 4d d7 c7 2d 2c 4d c1 a7 2f 1d 0x0094ef80: a5 cd 32 a8 53 89 f0 38 6c 75 3d e7 78 28 3d ae 0x0094ef90: 44 5a 45 19 7c 92 f0 43 bf 1c 90 80 c4 c0 9d 69 0x0094efa0: 8d d0 15 e0 59 01 18 c5 76 55 ac ef 7d e9 9d c1 0x0094efb0: 43 e2 da c0 75 cb 03 34 e7 94 b5 ab 54 52 14 e1 0x0094efc0: 22 26 c1 7b 27 da 41 9e 2f ed 8d ad d7 2b 6e 1a 0x0094efd0: 0d 49 da 82 14 de b6 fb 72 6b a7 c6 be bb a7 e0 0x0094efe0: e1 68 5c 09 42 9d a7 72 8a 34 1f 61 5e 8d 7c 6b 0x0094eff0: d6 56 ed ea 34 a4 e6 a6 0f 8d 6c cd 48 13 ae 2a OOB Data: 02 ea 12 80 ff ff 06 01 cf c3 03 94 c1 d6 55 a7 Byte by byte comparison of the good and bad files yield: FileOffset Good Bad 97780291 0xe6 0xee 97780471 0x6c 0x6e 97780500 0x73 0xf3 97780510 0x8 0x48 97780564 0xc7 0xe7 97780565 0x60 0x70 97780579 0x9d 0xdd 97780643 0x11 0x15 97780686 0x2a 0x2b Looks like some bits did not program to 0. Sergei Sharonov P.S. Any of you people tested yaffs under power fail conditions? From karl@micro-technic.com Thu May 12 16:55:09 2005 From: karl@micro-technic.com (Karl Olsen) Date: Thu, 12 May 2005 17:55:09 +0200 Subject: [Yaffs] Using the CVS version Message-ID: <002c01c5570a$fb672ea0$1f00a8c0@KARL> Hello list, I am using yaffs on Linux 2.6.11.5, based on the Frank Rowand patches from 2004-12-16. I was having some problems, so I wanted to try the current version, fetched as "Download tarball" from http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs/ . According to the CVS entries, some things have been fixed since last December. But after trying the patch-ker.sh (and adding the real yaffs files to fs/yaffs and the missing "obj-$(CONFIG_YAFFS_FS) += yaffs/" to fs/Makefile), it didn't compile at all. It looks like none of the necessary fixes that Frank Rowand made have been applied to CVS. Is there an up-to-date version somewhere, or what am I doing wrong? Kind regards, Karl Olsen From manningc2@actrix.gen.nz Fri May 13 02:43:16 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Fri, 13 May 2005 13:43:16 +1200 Subject: [Yaffs] Using the CVS version In-Reply-To: <002c01c5570a$fb672ea0$1f00a8c0@KARL> References: <002c01c5570a$fb672ea0$1f00a8c0@KARL> Message-ID: <20050513014225.160FE4340@blood.actrix.co.nz> On Friday 13 May 2005 03:55, Karl Olsen wrote: > Hello list, > > I am using yaffs on Linux 2.6.11.5, based on the Frank Rowand patches f= rom > 2004-12-16. I was having some problems, so I wanted to try the current > version, fetched as "Download tarball" from > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs/ . According to the = CVS > entries, some things have been fixed since last December. > > But after trying the patch-ker.sh (and adding the real yaffs files to > fs/yaffs and the missing "obj-$(CONFIG_YAFFS_FS) +=3D yaffs/" to > fs/Makefile), it didn't compile at all. It looks like none of the > necessary fixes that Frank Rowand made have been applied to CVS. Is th= ere > an up-to-date version somewhere, or what am I doing wrong? Some of Frank's patches were applied to what was in CVS, but not all. Som= e=20 were pretty much the same thing done a different way. The kerkel patchin script is pretty much untested work in progress. I am=20 awaiting setting up a 2.6 box to do that.=20 The files in fs/yaffs are supposed to be symbolic links back to the main=20 yaffs sources. If you have a patch for a fixed patchin script that would be most welcome= . -- CHarles From karl@micro-technic.com Fri May 13 08:21:07 2005 From: karl@micro-technic.com (Karl Olsen) Date: Fri, 13 May 2005 09:21:07 +0200 Subject: [Yaffs] Using the CVS version References: <002c01c5570a$fb672ea0$1f00a8c0@KARL> <20050513014225.160FE4340@blood.actrix.co.nz> Message-ID: <001401c5578c$816931c0$1f00a8c0@KARL> On Friday, May 13, 2005 3:43 AM [GMT+1=CET], Charles Manning wrote: > On Friday 13 May 2005 03:55, Karl Olsen wrote: > >> I am using yaffs on Linux 2.6.11.5, based on the Frank Rowand >> patches from 2004-12-16. I was having some problems, so I wanted to >> try the current version, fetched as "Download tarball" from >> http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs/ . According to >> the CVS entries, some things have been fixed since last December. >> >> But after trying the patch-ker.sh (and adding the real yaffs files to >> fs/yaffs and the missing "obj-$(CONFIG_YAFFS_FS) += yaffs/" to >> fs/Makefile), it didn't compile at all. It looks like none of the >> necessary fixes that Frank Rowand made have been applied to CVS. Is >> there an up-to-date version somewhere, or what am I doing wrong? > > Some of Frank's patches were applied to what was in CVS, but not all. > Some were pretty much the same thing done a different way. The yaffs.tar.gz I get with "Download tarball" contains a 7 month old yaffs_mtdif.c. The first line after the initial comment and the version string is a #ifdef CONFIG_YAFFS_MTD_ENABLED. So the rest of the file is never compiled (unless CONFIG_YAFFS_MTD_ENABLED is defined in the gcc command line). And I got link errors because the functions in yaffs_mtdif.c therefore weren't compiled. Frank Rowand fixed this in by adding a #include in his patch 2 of 7. So this necessary fix isn't in the "Download tarball" or the ViewCVS browser. And when looking at the revision history for this and the other files, I see a few later changes, but none related to the Frank Rowand fixes. The only sign of Frank Rowand is some "CVS Tags: pre_FrankR_changes, HEAD" lines. Are we looking at the same CVS? Kind regards, Karl Olsen From dswei@ustc.edu Fri May 13 17:45:19 2005 From: dswei@ustc.edu (dswei) Date: Sat, 14 May 2005 00:45:19 +0800 Subject: [Yaffs] yaffs on 2.6.11.8, "mkdir"==>"Cannot allocate memory" Message-ID: SGVsbG8sZXZlcnlib2R5Og0KICBJIGhhdmUgcG9ydGluZyBsaW51eDIuNi4xMS44IG9uIHRoZSBBUk0gczNjMjQxMA0KdXNpbmcgdGhlIHlhZmZzIGFzIHJvb3QgZmlsZXN5c3RlbS4gQW5kIGl0IHJ1bnMNCndlbGwgYnV0Og0KMS4gSWYgSSAibWtkaXIgZ2ciLCBpdCBzaG93cyBtZSB0aGUNCm1lc3NhZ2U6Im1rZGlyOiBDYW5ub3QgY3JlYXRlIGRpcmVjdG9yeSBgZ2cnOg0KQ2Fubm90IGFsbG9jYXRlIG1lbW9yeSIuIFdoZW4gSSBkaXNhYmxlIHRoZSBFQ0MsDQp0aGUgcXVlc3Rpb24gYWxzbyBhcHBlYXJzLg0KMi4gVGhlIHJvb3QgZGV2aWNlIHdhcyBjcmVhdGVkIHVzaW5nIGxpbnV4Mi40DQpiZWZvcmUoZG9uZSBieSBzb21lYm9keSBlbHNlKSwgYWxzbyBhcyB5YWZmcy4gSXQNCmhhcyBubyBwcm9ibGVtIHdoZW4gdXNpbmcgdGhlIGxpbnV4Mi40LiANCjMuIFdoZW4gdHJhY2luZyAibWtkaXIiLCBJIGZvdW5kIHRoYXQgdGhlIHJldHVybg0KdmFsdWUgb2YgdGhlIGZ1bmN0aW9uICJ5YWZmc19BbGxvY2F0ZUNodW5rIiBpcyA8IDAuIA0KDQogIERvZXMgc29tZWJvZHkgbWVldCB0aGVzZSBxdWVzdGlvbnM/IFBsZWFzZSBnaXZlDQptZSBzb21lIHN1Z2dlc3Rpb25zLg0KDQogIHdoYXQgaSBkbyB0byBwb3J0IHRoZSBsaW51eDIuNi4xMS44IGlzIHRoZSBzYW1lDQphcyB0aGlzIGFydGljbGUNCmRlc2NyaWJlczpodHRwOi8vc3VwZXJscC5ibG9nY2hpbmEuY29tLzEzOTEzOTMuaHRtbCAgDQotLQ0KVVNUQyBBbHVtbmkgRW1haWwgU3lzdGVtIA0KDQo= From dswei@ustc.edu Fri May 13 18:04:39 2005 From: dswei@ustc.edu (dswei) Date: Sat, 14 May 2005 01:04:39 +0800 Subject: [Yaffs] yaffs on 2.6.11.8, "mkdir"==>"Cannot allocate memory" Message-ID: <261d6c1a3a156a912be8bf51833389d0@> SGVsbG8sZXZlcnlib2R5Og0KICBJIGhhdmUgcG9ydGluZyBsaW51eDIuNi4xMS44IG9uIHRoZSBBUk0gczNjMjQxMA0KdXNpbmcgdGhlIHlhZmZzIGFzIHJvb3QgZmlsZXN5c3RlbS4gQW5kIGl0IHJ1bnMNCndlbGwgYnV0Og0KMS4gSWYgSSAibWtkaXIgZ2ciLCBpdCBzaG93cyBtZSB0aGUNCm1lc3NhZ2U6Im1rZGlyOiBDYW5ub3QgY3JlYXRlIGRpcmVjdG9yeSBgZ2cnOg0KQ2Fubm90IGFsbG9jYXRlIG1lbW9yeSIuIFdoZW4gSSBkaXNhYmxlIHRoZSBFQ0MsDQp0aGUgcXVlc3Rpb24gYWxzbyBhcHBlYXJzLg0KMi4gVGhlIHJvb3QgZGV2aWNlIHdhcyBjcmVhdGVkIHVzaW5nIGxpbnV4Mi40DQpiZWZvcmUoZG9uZSBieSBzb21lYm9keSBlbHNlKSwgYWxzbyBhcyB5YWZmcy4gSXQNCmhhcyBubyBwcm9ibGVtIHdoZW4gdXNpbmcgdGhlIGxpbnV4Mi40LiANCjMuIFdoZW4gdHJhY2luZyAibWtkaXIiLCBJIGZvdW5kIHRoYXQgdGhlIHJldHVybg0KdmFsdWUgb2YgdGhlIGZ1bmN0aW9uICJ5YWZmc19BbGxvY2F0ZUNodW5rIiBpcyA8IDAuIA0KDQogIERvZXMgc29tZWJvZHkgbWVldCB0aGVzZSBxdWVzdGlvbnM/IFBsZWFzZSBnaXZlDQptZSBzb21lIHN1Z2dlc3Rpb25zLg0KDQogIHdoYXQgaSBkbyB0byBwb3J0IHRoZSBsaW51eDIuNi4xMS44IGlzIHRoZSBzYW1lDQphcyB0aGlzIGFydGljbGUNCmRlc2NyaWJlczpodHRwOi8vc3VwZXJscC5ibG9nY2hpbmEuY29tLzEzOTEzOTMuaHRtbCAgIA0KLS0NClVTVEMgQWx1bW5pIEVtYWlsIFN5c3RlbSANCg0K From dswei@ustc.edu Fri May 13 18:28:08 2005 From: dswei@ustc.edu (dswei) Date: Sat, 14 May 2005 01:28:08 +0800 Subject: [Yaffs] yaffs on 2.6.11.8,can't mkdir, as"Cann't allocate memory' Message-ID: <2c37659b075eb0b4a397744ec57d6fbc@> U29ycnksdGhpcyBpcyBteSB0aGlyZCBlYW1pbCBmb3IgdGhpcyBzdWJqZWN0LiBJDQpob3BlIGl0IHdpbGwgbm90IGJlIGNoYW5nZWQgdG8gb3RoZXIgbGFuZ3VhZ2UgdGhhdA0Kbm9ib2R5IGNhbid0IHJlYWQuDQogICBJIGhhdmUgcG9ydGluZyBsaW51eDIuNi4xMS44IG9uIEFSTSBzM2MyNDEwLA0KdXNpbmcgdGhlIHlhZmZzIGFzIHJvb3QgZnMuIEl0IHJ1bnMgd2VsbCBidXQ6DQoxLiBJZiBJICJta2RpciBnZyIsIGl0IHNob3dzIG1lIHRoZSBtYXNzYWdlOg0KIm1rZGlyOiBDYW5uJ3QgY3JlYXRlIGRpcmVjdG9yeSBgZ2cnOiBDYW5ub3QNCmFsbG9jYXRlIG1lbW9yeSIuIFdoZW4gSSBkaXNhYmUgdGhlIEVDQywgdGhlDQpxdWVzdGlvbiBhbHNlIGFwcGVhcnMuDQoyLiBXaGVuIHRyYWNpbmcgIm1rZGlyIiwgSSBmb3VuZCB0aGF0IHRoZSByZXR1cm4NCnZhbHVlIG9mICJ5YWZmc19BbGxvY2F0ZUNodW5rIiBpcyA8IDAuDQozLiBUaGUgcm9vdCBkZXZpY2Ugd2FzIGNyZWF0ZWQgdXNpbmcgYW5vdGhlcg0Ka2VybmVsOiAyLjQsIGFsc28gYXMgeWFmZnMuIEl0IGhhcyBubyBwcm9ibGVtIHdoZW4NCnVzaW5nIGxpbnV4Mi40Lg0KDQogIENhbiB5b3UgZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rpb25zPyBUaGFuayB5b3UhDQoNCiAgV2hhdGkgSSBkbyB0byBwb3J0IHRoZSAyLjYuMTEuOCBrZXJuZWwgaXMgdGhlDQpzYW1lIGFzIHRoaXMgYXJ0aWNhbDoNCmh0dHA6Ly9zdXBlcmxwLmJsb2djaGluYS5jb20vMTM5MTM5My5odG1sDQoNCi0tDQpVU1RDIEFsdW1uaSBFbWFpbCBTeXN0ZW0gDQoNCg== From jeanwelly Tue May 17 03:46:52 2005 From: jeanwelly (jeanwelly) Date: Tue, 17 May 2005 10:46:52 +0800 Subject: [Yaffs] Real bad blocks of nand flash? Message-ID: I am running 2.6.11. 7 on S3C2410 ARM platform, using nand flash K9F1208, root fs =3Dyaffs.... Why occured so many bad blocks of nand. Are these blocks real bad? How can I take a test in another way? #./eraseall /dev/mtd/3=20 .................=20 Erasing 16 KibytMTD_ioctl=20 e @ 230000 -- 72MTD_ioctl=20 EraMTD_ioctl=20 sing 16 Kibyte @MTD_ioctl=20 234000 -- 73 % MTD_ioctl=20 ErasinMTD_ioctl=20 g 16 Kibyte @ 23MTD_ioctl=20 8000 -- 73 % comMTD_ioctl=20 Erasing 1MTD_ioctl=20 6 Kibyte @ 23c000 -- 74 % compleMTD_close=20 Erasing 16 Kibyte @ 278000 -- 82 % complete.=20 ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error=20 Erasing 16 Kibyte @ 27c000 -- 82 % complete.=20 ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error=20 Erasing 16 Kibyte @ 280000 -- 83 % complete.=20 ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error=20 Erasing 16 Kibyte @ 284000 -- 83 % complete.=20 ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error=20 Erasing 16 Kibyte @ 288000 -- 84 % complete.=20 ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error=20 Erasing 16 Kibyte @ 28c000 -- 84 % complete.=20 ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error=20 Erasing 16 Kibyte @ 290000 -- 85 % complete.=20 ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error=20 Erasing 16 Kibyte @ 2ac000 -- 89 % complete.=20 ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error=20 Erased 3072 Kibyte @ 0 -- 100% complete.=20 #=20 The following is my booting info: S3C2410 NAND Driver, (c) 2004 Simtec Electronics=20 s3c2410-nand: mapped registers at c4a00000=20 s3c2410-nand: timing: Tacls 10ns, Twrph0 40ns, Twrph1 10ns=20 NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit) NAND_ECC_NONE selected by board driver. This is not recommended !!=20 Scanning device for bad blocks=20 Bad eraseblock 129 at 0x00204000 <--- REAL BAD BLOCK ???? Bad eraseblock 130 at 0x00208000=20 Bad eraseblock 146 at 0x00248000=20 Bad eraseblock 147 at 0x0024c000=20 Bad eraseblock 148 at 0x00250000=20 Bad eraseblock 149 at 0x00254000=20 Bad eraseblock 158 at 0x00278000=20 Bad eraseblock 161 at 0x00284000=20 Bad eraseblock 174 at 0x002b8000=20 Bad eraseblock 178 at 0x002c8000=20 Bad eraseblock 286 at 0x00478000=20 Bad eraseblock 287 at 0x0047c000=20 Bad eraseblock 288 at 0x00480000=20 Bad eraseblock 289 at 0x00484000=20 Bad eraseblock 290 at 0x00488000=20 Bad eraseblock 291 at 0x0048c000=20 Bad eraseblock 292 at 0x00490000=20 Bad eraseblock 294 at 0x00498000=20 Bad eraseblock 295 at 0x0049c000=20 Bad eraseblock 296 at 0x004a0000=20 Bad eraseblock 297 at 0x004a4000=20 Bad eraseblock 298 at 0x004a8000=20 Bad eraseblock 299 at 0x004ac000=20 Bad eraseblock 300 at 0x004b0000=20 Bad eraseblock 301 at 0x004b4000=20 Bad eraseblock 305 at 0x004c4000=20 Creating 5 MTD partitions on "NAND 64MiB 3,3V 8-bit":=20 0x00000000-0x00020000 : "vivi"=20 mtd: Giving out device 0 to vivi=20 0x00020000-0x00030000 : "param"=20 mtd: Giving out device 1 to param=20 0x00030000-0x00200000 : "kernel"=20 mtd: Giving out device 2 to kernel=20 0x00200000-0x00600000 : "root"=20 mtd: Giving out device 3 to root=20 0x00600000-0x04000000 : "usr"=20 mtd: Giving out device 4 to usr=20 mice: PS/2 mouse device common for all mice=20 NET: Registered protocol family 2=20 IP: routing cache hash table of 512 buckets, 4Kbytes=20 TCP established hash table entries: 4096 (order: 3, 32768 bytes)=20 TCP bind hash table entries: 4096 (order: 2, 16384 bytes)=20 TCP: Hash tables configured (established 4096 bind 4096)=20 NET: Registered protocol family 1=20 Root-NFS: No NFS server available, giving up.=20 VFS: Unable to mount root fs via NFS, trying floppy.=20 Reading data from NAND FLASH without ECC is not recommended=20 yaffs: dev is 32505859 name is "(unavailable)"=20 VFS: Mounted root (yaffs filesystem).=20 Mounted devfs on /dev=20 Freeing init memory: 80K=20 Reading data from NAND FLASH without ECC is not recommended=20 zw: mount /etc as ramfs=20 zw: /bin/mount -t yaffs /dev/mtdblock/4 /usr=20 yaffs: dev is 32505860 name is "(unavailable)"=20 Reading data from NAND FLASH without ECC is not recommended=20 Reading data from NAND FLASH without ECC is not recommended=20 Reading data from NAND FLASH without ECC is not recommended=20 exec /sbin/init=20 console=3D/dev/console=20 init started: BusyBox v0.60.3 (2002.05.13-08:36+0000) multi-call binary=20 Starting pid 20, console /dev/console: '/etc/init.d/rcS'=20 mount: Mounting tmpfs on /dev/shm failed: No such file or directory=20 Thu Jan 1 00:00:00 UTC 2004=20 mount: Mounting ramfs on /.kde failed: No such file or directory=20 Reading data from NAND FLASH without ECC is not recommended=20 calibrate: error while loading shared libraries: liblinuetteapp.so.1: cannot load shayserver: error while loading shared libraries: liblinuettemodule.so.1: cannot load shayWaiting for enter to start '/bin/sh' (pid 38, terminal /dev/console) Please press Enter to activate this console.=20 Starting pid 38, console /dev/console: '/bin/sh'=20 BusyBox v0.60.3 (2002.05.13-08:36+0000) Built-in shell (ash)=20 Enter 'help' for a list of built-in commands.=20 # ls=20 Reading data from NAND FLASH without ECC is not recommended=20 aa.c etc linuxrc proc tmp=20 bin lib lost+found qt usr=20 dev linuette mnt sbin var=20 # ls /usr=20 Reading data from NAND FLASH without ECC is not recommended=20 bin lib lost+found sample=20 etc linuette qt sbin=20 BTW:=20 In bootloader vivi, I use # bon part , there are no bad blocks found. WHY? --=20 jeanwelly Email: jeanwelly@gmail.com China From manningc2@actrix.gen.nz Tue May 17 04:57:57 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Tue, 17 May 2005 15:57:57 +1200 Subject: [Yaffs] Real bad blocks of nand flash? In-Reply-To: References: Message-ID: <20050517035657.0D31B4824@blood.actrix.co.nz> You can expect up to approx 1% of bad blocks. These will often be close=20 together. On Tuesday 17 May 2005 14:46, jeanwelly wrote: > I am running 2.6.11. 7 on S3C2410 ARM platform, using nand flash > K9F1208, root fs =3Dyaffs.... > > Why occured so many bad blocks of nand. Are these blocks real bad? How > can I take a test in another way? > > > #./eraseall /dev/mtd/3 > ................. > Erasing 16 KibytMTD_ioctl > e @ 230000 -- 72MTD_ioctl > EraMTD_ioctl > sing 16 Kibyte @MTD_ioctl > 234000 -- 73 % MTD_ioctl > ErasinMTD_ioctl > g 16 Kibyte @ 23MTD_ioctl > 8000 -- 73 % comMTD_ioctl > Erasing 1MTD_ioctl > 6 Kibyte @ 23c000 -- 74 % compleMTD_close > Erasing 16 Kibyte @ 278000 -- 82 % complete. > ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error > Erasing 16 Kibyte @ 27c000 -- 82 % complete. > ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error > Erasing 16 Kibyte @ 280000 -- 83 % complete. > ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error > Erasing 16 Kibyte @ 284000 -- 83 % complete. > ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error > Erasing 16 Kibyte @ 288000 -- 84 % complete. > ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error > Erasing 16 Kibyte @ 28c000 -- 84 % complete. > ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error > Erasing 16 Kibyte @ 290000 -- 85 % complete. > ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error > Erasing 16 Kibyte @ 2ac000 -- 89 % complete. > ./eraseall: /dev/mtd/3: MTD Erase failure: Input/output error > Erased 3072 Kibyte @ 0 -- 100% complete. > # > > The following is my booting info: > > S3C2410 NAND Driver, (c) 2004 Simtec Electronics > s3c2410-nand: mapped registers at c4a00000 > s3c2410-nand: timing: Tacls 10ns, Twrph0 40ns, Twrph1 10ns > NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB > 3,3V 8-bit) > NAND_ECC_NONE selected by board driver. This is not recommended !! > Scanning device for bad blocks > Bad eraseblock 129 at 0x00204000 <--- REAL BAD BLOCK ???? > Bad eraseblock 130 at 0x00208000 > Bad eraseblock 146 at 0x00248000 > Bad eraseblock 147 at 0x0024c000 > Bad eraseblock 148 at 0x00250000 > Bad eraseblock 149 at 0x00254000 > Bad eraseblock 158 at 0x00278000 > Bad eraseblock 161 at 0x00284000 > Bad eraseblock 174 at 0x002b8000 > Bad eraseblock 178 at 0x002c8000 > Bad eraseblock 286 at 0x00478000 > Bad eraseblock 287 at 0x0047c000 > Bad eraseblock 288 at 0x00480000 > Bad eraseblock 289 at 0x00484000 > Bad eraseblock 290 at 0x00488000 > Bad eraseblock 291 at 0x0048c000 > Bad eraseblock 292 at 0x00490000 > Bad eraseblock 294 at 0x00498000 > Bad eraseblock 295 at 0x0049c000 > Bad eraseblock 296 at 0x004a0000 > Bad eraseblock 297 at 0x004a4000 > Bad eraseblock 298 at 0x004a8000 > Bad eraseblock 299 at 0x004ac000 > Bad eraseblock 300 at 0x004b0000 > Bad eraseblock 301 at 0x004b4000 > Bad eraseblock 305 at 0x004c4000 > Creating 5 MTD partitions on "NAND 64MiB 3,3V 8-bit": > 0x00000000-0x00020000 : "vivi" > mtd: Giving out device 0 to vivi > 0x00020000-0x00030000 : "param" > mtd: Giving out device 1 to param > 0x00030000-0x00200000 : "kernel" > mtd: Giving out device 2 to kernel > 0x00200000-0x00600000 : "root" > mtd: Giving out device 3 to root > 0x00600000-0x04000000 : "usr" > mtd: Giving out device 4 to usr > mice: PS/2 mouse device common for all mice > NET: Registered protocol family 2 > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP established hash table entries: 4096 (order: 3, 32768 bytes) > TCP bind hash table entries: 4096 (order: 2, 16384 bytes) > TCP: Hash tables configured (established 4096 bind 4096) > NET: Registered protocol family 1 > Root-NFS: No NFS server available, giving up. > VFS: Unable to mount root fs via NFS, trying floppy. > Reading data from NAND FLASH without ECC is not recommended > yaffs: dev is 32505859 name is "(unavailable)" > VFS: Mounted root (yaffs filesystem). > Mounted devfs on /dev > Freeing init memory: 80K > Reading data from NAND FLASH without ECC is not recommended > zw: mount /etc as ramfs > zw: /bin/mount -t yaffs /dev/mtdblock/4 /usr > yaffs: dev is 32505860 name is "(unavailable)" > Reading data from NAND FLASH without ECC is not recommended > Reading data from NAND FLASH without ECC is not recommended > Reading data from NAND FLASH without ECC is not recommended > exec /sbin/init > console=3D/dev/console > init started: BusyBox v0.60.3 (2002.05.13-08:36+0000) multi-call binary > Starting pid 20, console /dev/console: '/etc/init.d/rcS' > mount: Mounting tmpfs on /dev/shm failed: No such file or directory > Thu Jan 1 00:00:00 UTC 2004 > mount: Mounting ramfs on /.kde failed: No such file or directory > Reading data from NAND FLASH without ECC is not recommended > calibrate: error while loading shared libraries: liblinuetteapp.so.1: > cannot load shayserver: error while loading shared libraries: > liblinuettemodule.so.1: cannot load shayWaiting for enter to start > '/bin/sh' (pid 38, terminal /dev/console) > > Please press Enter to activate this console. > Starting pid 38, console /dev/console: '/bin/sh' > > > BusyBox v0.60.3 (2002.05.13-08:36+0000) Built-in shell (ash) > Enter 'help' for a list of built-in commands. > > # ls > Reading data from NAND FLASH without ECC is not recommended > aa.c etc linuxrc proc tmp > bin lib lost+found qt usr > dev linuette mnt sbin var > # ls /usr > Reading data from NAND FLASH without ECC is not recommended > bin lib lost+found sample > etc linuette qt sbin > > BTW: > In bootloader vivi, I use # bon part , there are no bad blocks found. = WHY? From Jarkko Lavinen Tue May 17 11:38:06 2005 From: Jarkko Lavinen (Jarkko Lavinen) Date: Tue, 17 May 2005 13:38:06 +0300 Subject: [Yaffs] Re: Real bad blocks of nand flash? In-Reply-To: References: Message-ID: <20050517103806.GA14992@angel.research.nokia.com> On Tue, May 17, 2005 at 10:46:52AM +0800, ext jeanwelly wrote: > Why occured so many bad blocks of nand. Are these blocks real bad? How > can I take a test in another way? I have seen few test boards with JFFS2 partitions and more bad blcoks than there should be. More than the manyfactures suggests the should be at maximum. When investigating one board I found something had been write garbage to OOB. I found for example word "driv" at the end of one OOB and "er" at the beginning of next. It looked just as if somebody had written kernel memory at random point to flash. This is not reproducinle but now I have garbage check in nand_base.c:write_oob() to hopefully catch this if it ever repeats. With one boatd with with lots of presumably incorrectly marked bad blocks board I broke the rules and simply disabled the bad block check from nand_base.c and from flash_eraseall.c. I ran flash_eraseall and the flash erased nicely except for few, obviously real bad blocks which refused ot be erased. I wouldn't recommed the procedure because one end up with no bad blocks at all but in my case it worked nice and test board has performed flawlessly since then. I think we would need a simple test program that would be similar to badblocks program, writing patterns of 0x00, 0x55, 0xAA etc. to flash and trying to find if some block fails when erasing, writing or in verify read. Jarkko Lavinen From sergei.sharonov@halliburton.com Tue May 17 13:41:12 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Tue, 17 May 2005 12:41:12 +0000 (UTC) Subject: [Yaffs] Re: Real bad blocks of nand flash? References: Message-ID: Hi > Why occured so many bad blocks of nand. Are these blocks real bad? How > can I take a test in another way? It may or may not relate to your situation but I found that power cycling causes additional bad blocks to appear. I don't think they are really bad because I did not erase flash that many times. Sergei From sergei.sharonov@halliburton.com Tue May 17 13:44:17 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Tue, 17 May 2005 12:44:17 +0000 (UTC) Subject: [Yaffs] power cycling Message-ID: Hi, Ok, lets try it one more time.. Has anybody done any power cycling tests with yaffs? If so, could you please post details? Thank you. Sergei From pankaj.goyal@st.com Wed May 18 10:09:56 2005 From: pankaj.goyal@st.com (Pankaj GOYAL) Date: Wed, 18 May 2005 14:39:56 +0530 Subject: [Yaffs] Yaffs support in 2.4.20 kernel Message-ID: <006001c55b89$5ca48460$0f10b40a@dlh.st.com> HI, I m using the jffs2 filesyem support on my linux kernel version 2.4.20 = and MTD subsystem version 2.6.9 with BBT and ECC management support in = MTD subsytem.Is linux kernel 2.4.20 supports the yaffs filesystem ? Also = I have a 16MB of NAND flash on my system which is ARM based.Which = filesystem(JFFS@ or YAFFS) is good in terms of the utilization of the = storage space of the NAND flash. Regards Pankaj From beat.morf@duagon.com Wed May 18 14:08:38 2005 From: beat.morf@duagon.com (Beat Morf) Date: Wed, 18 May 2005 15:08:38 +0200 Subject: [Yaffs] YAFFS and eCos Message-ID: <428B3E56.5040509@duagon.com> I am using eCos (http://sources.redhat.com/ecos) on a ARM7 microcontroller. Now I would like to add YAFFS support (direct access-mode) to eCos for using a filesystem on a 64MB NAND-flash (the JFFS2 is still not working correct with NAND-flashs under eCos). Has someone any experience concerning this topic or something similar - or exist some more implementation instructions for YAFFS? Beat From sergei.sharonov@halliburton.com Wed May 18 15:34:23 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Wed, 18 May 2005 14:34:23 +0000 (UTC) Subject: [Yaffs] Re: Yaffs support in 2.4.20 kernel References: <006001c55b89$5ca48460$0f10b40a@dlh.st.com> Message-ID: Hi, > I m using the jffs2 filesyem support on my linux kernel version 2.4.20 and MTD subsystem version 2.6.9 with > BBT and ECC management support in MTD subsytem.Is linux kernel 2.4.20 supports the yaffs filesystem ? > Also I have a 16MB of NAND flash on my system which is ARM based.Which filesystem(JFFS or YAFFS) is good in > terms of the utilization of the storage space of the NAND flash. First, in order to get stable MTD NAND support you will want recent MTD snapshot, and as you probably know recent MTD does not support 2.4 kernels. I hear I it can be backported but you are pretty much on your own. I am not sure what you mean by MTD 2.6.9 - is it pulled out of 2.6.9 kernel? You are better off using a snapshot from MTD site. Second - there some major diffrences between jffs2 and yaffs: 1. yaffs has _much_ faster boot time, but with such small (16 MB) NAND you may be OK with jffs2. Just don't do small size writes to it. 4 kB is optimal. 2. jffs2 offers compression and yaffs does not. 3. jffs2 has high RAM consumption - depends on the node size but I heard an estimate of 4 MB RAM per 128 MB NAND. 4. I believe there is much wider user base for jffs2 - just look at the trafic volume on the mailing lists. 5. I hear yaffs is robust with respect to power failures, but it does not pass my power fail test at the moment. I do not claim that it is yaffs issue - it may be a problem with my port. I asked if other people did any power cycling tests but did not get any replies. I have not tested jffs2 in this regard but I know somebody who did ~3000 power cycles without any problems. 6. I believe yaffs has seen more use on 2.4 kernels than 2.6. Sergei Sharonov From manningc2@actrix.gen.nz Wed May 18 20:26:59 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Thu, 19 May 2005 07:26:59 +1200 Subject: [Yaffs] YAFFS and eCos In-Reply-To: <428B3E56.5040509@duagon.com> References: <428B3E56.5040509@duagon.com> Message-ID: <20050518192554.A2BA64394@blood.actrix.co.nz> On Thursday 19 May 2005 01:08, Beat Morf wrote: > I am using eCos (http://sources.redhat.com/ecos) on a ARM7 > microcontroller. Now I would like to add YAFFS support (direct > access-mode) to eCos for using a filesystem on a 64MB NAND-flash (the > JFFS2 is still not working correct with NAND-flashs under eCos). > > Has someone any experience concerning this topic or something similar - > or exist some more implementation instructions for YAFFS? This could be achieved using the yaffs Direct interface which allows YAFF= S to=20 work with any RTOS. Bear in mind that YAFFS licensing is GPL and an eCos product generally is= =20 not. You would likely need to approach Aleph One about alternative licesn= ing=20 arrangements. -- Charles From nick@cecomputing.co.uk Thu May 19 10:36:15 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Thu, 19 May 2005 10:36:15 +0100 Subject: [Yaffs] Yaffs support in 2.4.20 kernel In-Reply-To: <006001c55b89$5ca48460$0f10b40a@dlh.st.com> Message-ID: See husaberg.toby-churchill.com for an example implementation of yaffs = and yaffs2 on 2.4.25 for balloon board. The latest is accessible via = subversion - see details on main page for cvs and svn access. Nick Bane > -----Original Message----- > From: yaffs-admin@stoneboat.aleph1.co.uk > [mailto:yaffs-admin@stoneboat.aleph1.co.uk]On Behalf Of Pankaj GOYAL > Sent: 18 May 2005 10:10 > To: yaffs@stoneboat.aleph1.co.uk > Subject: [Yaffs] Yaffs support in 2.4.20 kernel >=20 >=20 > HI, > I m using the jffs2 filesyem support on my linux kernel=20 > version 2.4.20 and MTD subsystem version 2.6.9 with BBT and ECC=20 > management support in MTD subsytem.Is linux kernel 2.4.20=20 > supports the yaffs filesystem ? Also I have a 16MB of NAND flash=20 > on my system which is ARM based.Which filesystem(JFFS@ or YAFFS)=20 > is good in terms of the utilization of the storage space of the=20 > NAND flash. >=20 >=20 > Regards > Pankaj >=20 >=20 > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs >=20 > --=20 > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.322 / Virus Database: 266.11.12 - Release Date: = 17/05/2005 > =20 >=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 266.11.12 - Release Date: 17/05/2005 =20 From Martin.Fouts@palmsource.com Thu May 19 22:55:26 2005 From: Martin.Fouts@palmsource.com (Martin Fouts) Date: Thu, 19 May 2005 14:55:26 -0700 Subject: [Yaffs] Can't compile Yaffs2 for 2.6.8 with gcc 3.3.4 Message-ID: =20 Hi, I'm obviously doing something dumb, but I'm not seeing what it is. Any help would be appreciated. I'm working on a Suse 9.2 platform with 2.6.8 kernel and gcc 3.3.4. I can modify and build kernels that compile, boot and operate without problems. I grab the yaffs source from the cvs archive using anonymous CVS. I modify the Makefile and set KERNELDIR to point to the proper directory. I type 'make -k'. (Gnu Make 3.80) Everything compiles excecpt yaffs_fs.c and yaffs_guts.c So I go to kernel that org and grab a bunch of kernels for 2.6.1 through 2.6.11 and stick them in a tree. I try building against various kernels. I can't get yaffs to compile against any of them. I've clearly missed a step in the instructions. Advice? Pointers to the source for working versions in 2.6.8? I should mention that this is just a step towards getting yaffs to run on arm linux on the TI Perseus 2 development system. We have a working arm linux, and I'm trying to integrate yaffs2 with it. Thanks, Marty From sergei.sharonov@halliburton.com Fri May 20 13:08:39 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Fri, 20 May 2005 12:08:39 +0000 (UTC) Subject: [Yaffs] Re: Can't compile Yaffs2 for 2.6.8 with gcc 3.3.4 References: Message-ID: Hi, > Everything compiles excecpt yaffs_fs.c and yaffs_guts.c Please post compilation errors. > I've clearly missed a step in the instructions. Advice? Pointers to > the source for working versions in 2.6.8? If we do not see the make output we cannot help you. > I should mention that this is just a step towards getting yaffs to run > on arm linux on the TI Perseus 2 development system. We have a working > arm linux, and I'm trying to integrate yaffs2 with it. I managed to compile yaffs2 for arm/2.6.10 about a month ago, but it did not work. There have been fixes since then and I believe at least one un-fixed issue. I have yaffs1 working on arm and would like to get yaffs2 going as well. Sergei Sharonov From sergei.sharonov@halliburton.com Fri May 20 15:01:22 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Fri, 20 May 2005 14:01:22 +0000 (UTC) Subject: [Yaffs] Re: power fail testing References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> Message-ID: Hi, As I reported sometimes power cycling produces files where some/few zeros are flipped to ones. I have the following hypothesis, please let me know if it makes sense or I am missing something in my understanding of yaffs_guts. 1. The error does not happen under stable power condition so it is likely that power fail causes partial programming, e.g. some ones do not program to zero. 2. Initial scan will not check crc on data and happily count a page as a valid chunk of the file. 3. Garbage collector may later copy the bad page without checking crc (!) to a new block and assign it a (new) good crc. How about that? Sergei Sharonov From Martin.Fouts@palmsource.com Fri May 20 20:39:09 2005 From: Martin.Fouts@palmsource.com (Martin Fouts) Date: Fri, 20 May 2005 12:39:09 -0700 Subject: [Yaffs] Re: Can't compile Yaffs2 for 2.6.8 with gcc 3.3.4 Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C55D73.9760AE69 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Since I wrote, I have placed the yaffs2 source into a linux 2.6.9 kernel tree as fs/yaffs2. I have modified fs/Kconfig and fs/Makefile appropriately and written fs/yaffs2/Makefile. Everything now compiles, except yaffs_guts.c I have attached the make output. From it, and email from Charles Manning, I believe that the issue is that 2.6.9 has 'old' mtd and I need 'new' mtd. This weekend, I will check that possibility out. Marty -----Original Message----- From: yaffs-admin@stoneboat.aleph1.co.uk [mailto:yaffs-admin@stoneboat.aleph1.co.uk] On Behalf Of Sergei Sharonov Sent: Friday, May 20, 2005 5:09 AM To: yaffs@stoneboat.aleph1.co.uk Subject: [Yaffs] Re: Can't compile Yaffs2 for 2.6.8 with gcc 3.3.4 Hi, > Everything compiles excecpt yaffs_fs.c and yaffs_guts.c Please post compilation errors. > I've clearly missed a step in the instructions. Advice? Pointers to=20 > the source for working versions in 2.6.8? If we do not see the make output we cannot help you. > I should mention that this is just a step towards getting yaffs to run > on arm linux on the TI Perseus 2 development system. We have a=20 > working arm linux, and I'm trying to integrate yaffs2 with it. I managed to compile yaffs2 for arm/2.6.10 about a month ago, but it did not work. There have been fixes since then and I believe at least one un-fixed issue. I have yaffs1 working on arm and would like to get yaffs2 going as well. Sergei Sharonov ------_=_NextPart_001_01C55D73.9760AE69 Content-Type: application/octet-stream; name="all.log" Content-Transfer-Encoding: base64 Content-Description: all.log Content-Disposition: attachment; filename="all.log" ICBDSEsgICAgIGluY2x1ZGUvbGludXgvdmVyc2lvbi5oCm1ha2VbMV06IGBhcmNoL2FybS9rZXJu ZWwvYXNtLW9mZnNldHMucycgaXMgdXAgdG8gZGF0ZS4KbWFrZVsxXTogYGluY2x1ZGUvYXNtLWFy bS9tYWNoLXR5cGVzLmgnIGlzIHVwIHRvIGRhdGUuCiAgQ0hLICAgICBpbmNsdWRlL2xpbnV4L2Nv bXBpbGUuaAogIENDICAgICAgZnMveWFmZnMyL3lhZmZzX2d1dHMubwpmcy95YWZmczIveWFmZnNf Z3V0cy5jOiBJbiBmdW5jdGlvbiBgeWFmZnNfUmVhZENodW5rV2l0aFRhZ3NGcm9tTkFORCc6CmZz L3lhZmZzMi95YWZmc19ndXRzLmM6MTU1OiBlcnJvcjogc3RydWN0dXJlIGhhcyBubyBtZW1iZXIg bmFtZWQgYHJlYWRDaHVua1dpdGhUYWdzRnJvbU5BTkQnCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6 MTU2OiBlcnJvcjogc3RydWN0dXJlIGhhcyBubyBtZW1iZXIgbmFtZWQgYHJlYWRDaHVua1dpdGhU YWdzRnJvbU5BTkQnCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6IEluIGZ1bmN0aW9uIGB5YWZmc19X cml0ZUNodW5rV2l0aFRhZ3NUb05BTkQnOgpmcy95YWZmczIveWFmZnNfZ3V0cy5jOjE4MDogZXJy b3I6IHN0cnVjdHVyZSBoYXMgbm8gbWVtYmVyIG5hbWVkIGB3cml0ZUNodW5rV2l0aFRhZ3NUb05B TkQnCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6MTgxOiBlcnJvcjogc3RydWN0dXJlIGhhcyBubyBt ZW1iZXIgbmFtZWQgYHdyaXRlQ2h1bmtXaXRoVGFnc1RvTkFORCcKZnMveWFmZnMyL3lhZmZzX2d1 dHMuYzogSW4gZnVuY3Rpb24gYHlhZmZzX01hcmtCbG9ja0JhZCc6CmZzL3lhZmZzMi95YWZmc19n dXRzLmM6MTg4OiBlcnJvcjogc3RydWN0dXJlIGhhcyBubyBtZW1iZXIgbmFtZWQgYG1hcmtOQU5E QmxvY2tCYWQnCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6MTg5OiBlcnJvcjogc3RydWN0dXJlIGhh cyBubyBtZW1iZXIgbmFtZWQgYG1hcmtOQU5EQmxvY2tCYWQnCmZzL3lhZmZzMi95YWZmc19ndXRz LmM6IEluIGZ1bmN0aW9uIGB5YWZmc19RdWVyeUluaXRpYWxCbG9ja1N0YXRlJzoKZnMveWFmZnMy L3lhZmZzX2d1dHMuYzoxOTU6IGVycm9yOiBzdHJ1Y3R1cmUgaGFzIG5vIG1lbWJlciBuYW1lZCBg cXVlcnlOQU5EQmxvY2snCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6MTk2OiBlcnJvcjogc3RydWN0 dXJlIGhhcyBubyBtZW1iZXIgbmFtZWQgYHF1ZXJ5TkFOREJsb2NrJwpmcy95YWZmczIveWFmZnNf Z3V0cy5jOiBJbiBmdW5jdGlvbiBgeWFmZnNfQmxvY2tOb3REaXNxdWFsaWZpZWRGcm9tR0MnOgpm cy95YWZmczIveWFmZnNfZ3V0cy5jOjIxNjQ6IGVycm9yOiBzdHJ1Y3R1cmUgaGFzIG5vIG1lbWJl ciBuYW1lZCBgaGFzU2hyaW5rSGVhZGVyJwpmcy95YWZmczIveWFmZnNfZ3V0cy5jOjIxNzg6IGVy cm9yOiBzdHJ1Y3R1cmUgaGFzIG5vIG1lbWJlciBuYW1lZCBgc2VxdWVuY2VOdW1iZXInCmZzL3lh ZmZzMi95YWZmc19ndXRzLmM6MjE4MDogZXJyb3I6IHN0cnVjdHVyZSBoYXMgbm8gbWVtYmVyIG5h bWVkIGBzZXF1ZW5jZU51bWJlcicKZnMveWFmZnMyL3lhZmZzX2d1dHMuYzoyMTg5OiBlcnJvcjog c3RydWN0dXJlIGhhcyBubyBtZW1iZXIgbmFtZWQgYHNlcXVlbmNlTnVtYmVyJwpmcy95YWZmczIv eWFmZnNfZ3V0cy5jOiBJbiBmdW5jdGlvbiBgeWFmZnNfQmxvY2tCZWNhbWVEaXJ0eSc6CmZzL3lh ZmZzMi95YWZmc19ndXRzLmM6MjMyNDogZXJyb3I6IHN0cnVjdHVyZSBoYXMgbm8gbWVtYmVyIG5h bWVkIGBoYXNTaHJpbmtIZWFkZXInCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6IEluIGZ1bmN0aW9u IGB5YWZmc19GaW5kQmxvY2tGb3JBbGxvY2F0aW9uJzoKZnMveWFmZnMyL3lhZmZzX2d1dHMuYzoy NDA1OiBlcnJvcjogc3RydWN0dXJlIGhhcyBubyBtZW1iZXIgbmFtZWQgYHNlcXVlbmNlTnVtYmVy Jwpmcy95YWZmczIveWFmZnNfZ3V0cy5jOiBJbiBmdW5jdGlvbiBgeWFmZnNfR2FyYmFnZUNvbGxl Y3RCbG9jayc6CmZzL3lhZmZzMi95YWZmc19ndXRzLmM6MjUyNTogZXJyb3I6IHN0cnVjdHVyZSBo YXMgbm8gbWVtYmVyIG5hbWVkIGBoYXNTaHJpbmtIZWFkZXInCmZzL3lhZmZzMi95YWZmc19ndXRz LmM6MjUyODogZXJyb3I6IHN0cnVjdHVyZSBoYXMgbm8gbWVtYmVyIG5hbWVkIGBoYXNTaHJpbmtI ZWFkZXInCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6IEluIGZ1bmN0aW9uIGB5YWZmc19EZWxldGVD aHVuayc6CmZzL3lhZmZzMi95YWZmc19ndXRzLmM6MzI2ODogZXJyb3I6IHN0cnVjdHVyZSBoYXMg bm8gbWVtYmVyIG5hbWVkIGBoYXNTaHJpbmtIZWFkZXInCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6 IEluIGZ1bmN0aW9uIGB5YWZmc19VcGRhdGVPYmplY3RIZWFkZXInOgpmcy95YWZmczIveWFmZnNf Z3V0cy5jOjM0ODc6IGVycm9yOiBzdHJ1Y3R1cmUgaGFzIG5vIG1lbWJlciBuYW1lZCBgaGFzU2hy aW5rSGVhZGVyJwpmcy95YWZmczIveWFmZnNfZ3V0cy5jOiBJbiBmdW5jdGlvbiBgeWFmZnNfU2Nh bic6CmZzL3lhZmZzMi95YWZmc19ndXRzLmM6NDU5NTogZXJyb3I6IHN0cnVjdHVyZSBoYXMgbm8g bWVtYmVyIG5hbWVkIGBzZXF1ZW5jZU51bWJlcicKZnMveWFmZnMyL3lhZmZzX2d1dHMuYzo0NzMy OiBlcnJvcjogc3RydWN0dXJlIGhhcyBubyBtZW1iZXIgbmFtZWQgYHNlcXVlbmNlTnVtYmVyJwpm cy95YWZmczIveWFmZnNfZ3V0cy5jOjQ3MzQ6IGVycm9yOiBzdHJ1Y3R1cmUgaGFzIG5vIG1lbWJl ciBuYW1lZCBgc2VxdWVuY2VOdW1iZXInCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6NDkxMTogZXJy b3I6IHN0cnVjdHVyZSBoYXMgbm8gbWVtYmVyIG5hbWVkIGBoYXNTaHJpbmtIZWFkZXInCmZzL3lh ZmZzMi95YWZmc19ndXRzLmM6NDkzNjogZXJyb3I6IHN0cnVjdHVyZSBoYXMgbm8gbWVtYmVyIG5h bWVkIGBoYXNTaHJpbmtIZWFkZXInCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6NDk1MzogZXJyb3I6 IHN0cnVjdHVyZSBoYXMgbm8gbWVtYmVyIG5hbWVkIGBoYXNTaHJpbmtIZWFkZXInCmZzL3lhZmZz Mi95YWZmc19ndXRzLmM6IEluIGZ1bmN0aW9uIGB5YWZmc19TY2FuQmFja3dhcmRzJzoKZnMveWFm ZnMyL3lhZmZzX2d1dHMuYzo1MDc2OiBlcnJvcjogc3RydWN0dXJlIGhhcyBubyBtZW1iZXIgbmFt ZWQgYHNlcXVlbmNlTnVtYmVyJwpmcy95YWZmczIveWFmZnNfZ3V0cy5jOjUyMjI6IGVycm9yOiBz dHJ1Y3R1cmUgaGFzIG5vIG1lbWJlciBuYW1lZCBgc2VxdWVuY2VOdW1iZXInCmZzL3lhZmZzMi95 YWZmc19ndXRzLmM6NTIyNDogZXJyb3I6IHN0cnVjdHVyZSBoYXMgbm8gbWVtYmVyIG5hbWVkIGBz ZXF1ZW5jZU51bWJlcicKZnMveWFmZnMyL3lhZmZzX2d1dHMuYzo1MzM5OiBlcnJvcjogc3RydWN0 dXJlIGhhcyBubyBtZW1iZXIgbmFtZWQgYGhhc1Nocmlua0hlYWRlcicKZnMveWFmZnMyL3lhZmZz X2d1dHMuYzo1NDMzOiBlcnJvcjogc3RydWN0dXJlIGhhcyBubyBtZW1iZXIgbmFtZWQgYGhhc1No cmlua0hlYWRlcicKZnMveWFmZnMyL3lhZmZzX2d1dHMuYzo1NTAxOiBlcnJvcjogc3RydWN0dXJl IGhhcyBubyBtZW1iZXIgbmFtZWQgYGhhc1Nocmlua0hlYWRlcicKZnMveWFmZnMyL3lhZmZzX2d1 dHMuYzogSW4gZnVuY3Rpb24gYHlhZmZzX0NoZWNrRGV2RnVuY3Rpb25zJzoKZnMveWFmZnMyL3lh ZmZzX2d1dHMuYzo1OTU3OiBlcnJvcjogc3RydWN0dXJlIGhhcyBubyBtZW1iZXIgbmFtZWQgYHdy aXRlQ2h1bmtXaXRoVGFnc1RvTkFORCcKZnMveWFmZnMyL3lhZmZzX2d1dHMuYzo1OTU4OiBlcnJv cjogc3RydWN0dXJlIGhhcyBubyBtZW1iZXIgbmFtZWQgYHJlYWRDaHVua1dpdGhUYWdzRnJvbU5B TkQnCmZzL3lhZmZzMi95YWZmc19ndXRzLmM6NTk2MTogZXJyb3I6IHN0cnVjdHVyZSBoYXMgbm8g bWVtYmVyIG5hbWVkIGBtYXJrTkFOREJsb2NrQmFkJwpmcy95YWZmczIveWFmZnNfZ3V0cy5jOjU5 NjI6IGVycm9yOiBzdHJ1Y3R1cmUgaGFzIG5vIG1lbWJlciBuYW1lZCBgcXVlcnlOQU5EQmxvY2sn CmZzL3lhZmZzMi95YWZmc19ndXRzLmM6IEluIGZ1bmN0aW9uIGB5YWZmc19HdXRzSW5pdGlhbGlz ZSc6CmZzL3lhZmZzMi95YWZmc19ndXRzLmM6NjEzNjogZXJyb3I6IGluY29tcGF0aWJsZSB0eXBl cyBpbiBhc3NpZ25tZW50Cm1ha2VbMl06ICoqKiBbZnMveWFmZnMyL3lhZmZzX2d1dHMub10gRXJy b3IgMQptYWtlWzFdOiAqKiogW2ZzL3lhZmZzMl0gRXJyb3IgMgptYWtlOiAqKiogW2ZzXSBFcnJv ciAyCg== ------_=_NextPart_001_01C55D73.9760AE69-- From sergei.sharonov@halliburton.com Fri May 20 21:56:41 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Fri, 20 May 2005 20:56:41 +0000 (UTC) Subject: [Yaffs] Re: Can't compile Yaffs2 for 2.6.8 with gcc 3.3.4 References: Message-ID: Martin, Looks like CONFIG_YAFFS_YAFFS2 is not defined. See yaffs_guts.h for struct definition. Probably need to add/set a switch in Kconfig. Sergei From manningc2@actrix.gen.nz Sat May 21 23:14:00 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Sun, 22 May 2005 10:14:00 +1200 Subject: [Yaffs] Re: power fail testing In-Reply-To: References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> Message-ID: <20050521221247.F04A215F07@desire.actrix.co.nz> Sergei I know I have been silent on this a while, but that is mainly because I h= ave=20 been thinking... For now I will put aside the rename problem which has a fix that I need t= o=20 complete and will instead focus on the actual power fial issues. > As I reported sometimes power cycling produces files where some/few zer= os > are flipped to ones. I have the following hypothesis, please let me kno= w if > it makes sense or I am missing something in my understanding of yaffs_g= uts. > > 1. The error does not happen under stable power condition so it is like= ly > that power fail causes partial programming, e.g. some ones do not progr= am > to zero. 2. Initial scan will not check crc on data and happily count a > page as a valid chunk of the file. YAFFS currently assumes that a power failure will not destroy a write. Fo= r=20 the most par that should be an OK assumption since once a flash programmi= ng=20 cycle has been set up it should execute in 200uS. THere should be enough=20 residual power in the system to complete that. Two things that can be done to improve the situation at the low level: 1) Ensure that the whole page write is being done as a single write at th= e=20 mtd level (ie. writing the data and oob as seperate operations is not goo= d). 2) Add a power check step just before the write in the mtd (assuming you = have=20 a power fail warning flag) ie=20 nand_write(..) { set up write while(!power_good){spin} complete write } There is also something that can be done in YAFFS: Better handling of pow= er=20 fail by checking the condition of the last write beforepower failed. If i= t=20 was bad we can just discard it. > 3. Garbage collector may later copy the bad page without checking crc (= !) > to a new block and assign it a (new) good crc. There is no crc, but there is ecc. YAFFS should be applying ECC during gc= too=20 as it is part of the standard read. THis will fix single bit errors, but = not=20 partially written pages. -- Charles From Martin.Fouts@palmsource.com Sat May 21 23:43:48 2005 From: Martin.Fouts@palmsource.com (Martin Fouts) Date: Sat, 21 May 2005 15:43:48 -0700 Subject: [Yaffs] Re: Can't compile Yaffs2 for 2.6.8 with gcc 3.3.4 Message-ID: That was the problem. Thanks.=20 -----Original Message----- From: yaffs-admin@stoneboat.aleph1.co.uk [mailto:yaffs-admin@stoneboat.aleph1.co.uk] On Behalf Of Sergei Sharonov Sent: Friday, May 20, 2005 1:57 PM To: yaffs@stoneboat.aleph1.co.uk Subject: [Yaffs] Re: Can't compile Yaffs2 for 2.6.8 with gcc 3.3.4 Martin, Looks like CONFIG_YAFFS_YAFFS2 is not defined. See yaffs_guts.h for struct definition. Probably need to add/set a switch in Kconfig. Sergei _______________________________________________ yaffs mailing list yaffs@stoneboat.aleph1.co.uk http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From tglx@linutronix.de Sun May 22 22:53:05 2005 From: tglx@linutronix.de (Thomas Gleixner) Date: Sun, 22 May 2005 23:53:05 +0200 Subject: [Yaffs] Re: power fail testing In-Reply-To: <20050521221247.F04A215F07@desire.actrix.co.nz> References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> <20050521221247.F04A215F07@desire.actrix.co.nz> Message-ID: <1116798785.6736.6.camel@tglx.tec.linutronix.de> On Sun, 2005-05-22 at 10:14 +1200, Charles Manning wrote: > YAFFS currently assumes that a power failure will not destroy a write. For > the most par that should be an OK assumption since once a flash programming > cycle has been set up it should execute in 200uS. THere should be enough > residual power in the system to complete that. Hmm, thats a dangerous assumption. Assume that the WP pin is switched to write protect mode by a reset controller which supervises the power supply. You have to handle interrupted writes. There is no guarantee for "atomic" programming operations. And all hacks you put into the mtd/nand layer or YAFFS will not improve the situation. Keep this stuff as simple as possible and handle the rare case of interrupted page programming in the mount stage. tglx From manningc2@actrix.gen.nz Mon May 23 01:06:58 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Mon, 23 May 2005 12:06:58 +1200 Subject: [Yaffs] Re: power fail testing In-Reply-To: <1116798785.6736.6.camel@tglx.tec.linutronix.de> References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> <20050521221247.F04A215F07@desire.actrix.co.nz> <1116798785.6736.6.camel@tglx.tec.linutronix.de> Message-ID: <20050523000542.E4E10415F@blood.actrix.co.nz> On Monday 23 May 2005 09:53, Thomas Gleixner wrote: > On Sun, 2005-05-22 at 10:14 +1200, Charles Manning wrote: > > YAFFS currently assumes that a power failure will not destroy a write= . > > For the most par that should be an OK assumption since once a flash > > programming cycle has been set up it should execute in 200uS. THere > > should be enough residual power in the system to complete that. > > Hmm, thats a dangerous assumption. Assume that the WP pin is switched t= o > write protect mode by a reset controller which supervises the power > supply. Thanx Thomas I had not considered this condition. The WP directly controls the internal high voltage charge pump that drive= s=20 the programming. If WP goes low, the hv will droop and the programming w= ill=20 not complete reliably. In most circuits I am familar with, the WP is strapped to Vcc which would= =20 allow in-progress writes to complete. > > You have to handle interrupted writes. There is no guarantee for > "atomic" programming operations. And all hacks you put into the mtd/nan= d > layer or YAFFS will not improve the situation. Keep this stuff as simpl= e > as possible and handle the rare case of interrupted page programming in > the mount stage. There are really two things that should be done in YAFFS to improve the=20 situation: 1) Currently YAFFS uses chunks that fail ECC. It would probably be better= to=20 ignore them (delete them) and consider them to be aborted writes (needs m= ore=20 thought). 2) If an ECC failure is detected on a block, then the block is retired.=20 Perhaps instead a block should only be retired if a write fails. This wou= ld=20 be more in tune with Toshiba's recommendations. The argument against this= has=20 been that I'd rather retire blocks earlier (ie before they start to go ba= d),=20 but this should be reviewed in the light of recent evidence. -- CHarles From tglx@linutronix.de Mon May 23 09:10:49 2005 From: tglx@linutronix.de (Thomas Gleixner) Date: Mon, 23 May 2005 10:10:49 +0200 Subject: [Yaffs] Re: power fail testing In-Reply-To: <20050523000542.E4E10415F@blood.actrix.co.nz> References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> <20050521221247.F04A215F07@desire.actrix.co.nz> <1116798785.6736.6.camel@tglx.tec.linutronix.de> <20050523000542.E4E10415F@blood.actrix.co.nz> Message-ID: <1116835849.6736.33.camel@tglx.tec.linutronix.de> On Mon, 2005-05-23 at 12:06 +1200, Charles Manning wrote: > There are really two things that should be done in YAFFS to improve the > situation: > 1) Currently YAFFS uses chunks that fail ECC. It would probably be better to > ignore them (delete them) and consider them to be aborted writes (needs more > thought). Yes. > 2) If an ECC failure is detected on a block, then the block is retired. > Perhaps instead a block should only be retired if a write fails. This would > be more in tune with Toshiba's recommendations. The argument against this has > been that I'd rather retire blocks earlier (ie before they start to go bad), > but this should be reviewed in the light of recent evidence. >From our experience with long time stress tests: 1. Its normal that bit flips happens over time 2. The block goes bad scenario is definitely more than a single bit flip. Either the block can not be erased to all FF anymore or you have consecutive programming errors. In case 1.) its not necessary to retire the block. Of course you should copy the ECC corrected data to another block and erase the block. If it is really going bad 2.) will catch that. tglx From tglx@linutronix.de Mon May 23 10:45:49 2005 From: tglx@linutronix.de (Thomas Gleixner) Date: Mon, 23 May 2005 11:45:49 +0200 Subject: [Yaffs] Re: power fail testing In-Reply-To: <20050523000542.E4E10415F@blood.actrix.co.nz> References: <487B538D08487B4D8FEC138A13D4F6AC826C69@HOUEXCH077.corp.halliburton.com> <20050521221247.F04A215F07@desire.actrix.co.nz> <1116798785.6736.6.camel@tglx.tec.linutronix.de> <20050523000542.E4E10415F@blood.actrix.co.nz> Message-ID: <1116841549.6736.36.camel@tglx.tec.linutronix.de> On Mon, 2005-05-23 at 12:06 +1200, Charles Manning wrote: > The WP directly controls the internal high voltage charge pump that drives > the programming. If WP goes low, the hv will droop and the programming will > not complete reliably. > > In most circuits I am familar with, the WP is strapped to Vcc which would > allow in-progress writes to complete. There is another problematic scenario: Removable media e.g. SmartMedia. You have no control over users :) tglx From Sergei.Sharonov@Halliburton.com Mon May 23 13:06:09 2005 From: Sergei.Sharonov@Halliburton.com (Sergei Sharonov) Date: Mon, 23 May 2005 07:06:09 -0500 Subject: [Yaffs] Re: power fail testing Message-ID: <487B538D08487B4D8FEC138A13D4F6AC9BF0C0@HOUEXCH077.corp.halliburton.com> Charles, > > 3. Garbage collector may later copy the bad page without=20 > > checking crc (!) > > to a new block and assign it a (new) good crc. >=20 > There is no crc, but there is ecc. YAFFS should be applying=20 > ECC during gc too=20 > as it is part of the standard read. THis will fix single bit=20 > errors, but not=20 > partially written pages. Sorry, I misused crc in place of ecc. I am worried that gc may copy out a bad page and assign it a new=20 good ecc. Then the read will not be able to see a problem with this page. Maybe there should be a check in gc for a good ecc before copy. Sergei ---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and pri= vileged information for the sole use of the intended recipient. Any review= , use, distribution, or disclosure by others is strictly prohibited. If yo= u are not the intended recipient (or authorized to receive information for = the intended recipient), please contact the sender by reply e-mail and dele= te all copies of this message. From Sergei.Sharonov@Halliburton.com Mon May 23 13:21:45 2005 From: Sergei.Sharonov@Halliburton.com (Sergei Sharonov) Date: Mon, 23 May 2005 07:21:45 -0500 Subject: [Yaffs] Re: power fail testing Message-ID: <487B538D08487B4D8FEC138A13D4F6AC9BF0C7@HOUEXCH077.corp.halliburton.com> Charles, > 2) If an ECC failure is detected on a block, then the block=20 > is retired.=20 > Perhaps instead a block should only be retired if a write=20 > fails. This would=20 > be more in tune with Toshiba's recommendations. The argument=20 > against this has=20 > been that I'd rather retire blocks earlier (ie before they=20 > start to go bad),=20 > but this should be reviewed in the light of recent evidence. I see block leakage during power cycling test. I think it is=20 caused by read failures on partially programmed pages. Blocks should not go bad after few hundred erases. On a positive side the leakage is moderate - a dozen lost blocks after ~500 cycles. Now, I got a question about erasing during power fail. AFAIK this is what was killing original jffs - incompletely erased blocks had bits that after programming sometimes read 0 and sometimes 1, e.g. write verify may be successful but a later read may fail. That was the reason for introduction of the "clean marker" in jffs2. YAFFS does not use clean markers at the moment. The problem is harder to catch because of much faster erase of the NAND, but it is probably still there. Thomas, is that correct recollection of=20 the jffs/jffs2 and clean marker situation? Sergei ---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and pri= vileged information for the sole use of the intended recipient. Any review= , use, distribution, or disclosure by others is strictly prohibited. If yo= u are not the intended recipient (or authorized to receive information for = the intended recipient), please contact the sender by reply e-mail and dele= te all copies of this message. From Sergei.Sharonov@HALLIBURTON.com Mon May 23 15:37:43 2005 From: Sergei.Sharonov@HALLIBURTON.com (Sergei Sharonov) Date: Mon, 23 May 2005 09:37:43 -0500 Subject: [Yaffs] Re: power fail testing Message-ID: <487B538D08487B4D8FEC138A13D4F6AC9BF132@HOUEXCH077.corp.halliburton.com> Hi, > > Hmm, thats a dangerous assumption. Assume that the WP pin=20 > > is switched to > > write protect mode by a reset controller which supervises the power > > supply. >=20 > Thanx Thomas I had not considered this condition. >=20 > The WP directly controls the internal high voltage charge=20 > pump that drives=20 > the programming. If WP goes low, the hv will droop and the=20 > programming will not complete reliably. >=20 > In most circuits I am familar with, the WP is strapped to Vcc=20 > which would allow in-progress writes to complete. Well, I just checked schematic and I did hook WP to global reset signal, the one that comes from reset generator. Always thought it=20 was a good idea ;-) Sergei ---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and pri= vileged information for the sole use of the intended recipient. Any review= , use, distribution, or disclosure by others is strictly prohibited. If yo= u are not the intended recipient (or authorized to receive information for = the intended recipient), please contact the sender by reply e-mail and dele= te all copies of this message. From Sergei.Sharonov@Halliburton.com Mon May 23 15:17:46 2005 From: Sergei.Sharonov@Halliburton.com (Sergei Sharonov) Date: Mon, 23 May 2005 09:17:46 -0500 Subject: [Yaffs] Re: power fail testing Message-ID: <487B538D08487B4D8FEC138A13D4F6AC9BF127@HOUEXCH077.corp.halliburton.com> > Two things that can be done to improve the situation at the low level: > 1) Ensure that the whole page write is being done as a single=20 > write at the mtd level (ie. writing the data and oob as separate=20 > operations is not good). Hmm... I would think separate writes would be a good idea - then we have a guarantee that data write has completed. That is if crc on tags=20 is good then no power failure has occurred during data write. On the other hand if we do a write in one gulp then valid crc on tags does not prove that data is ok. So: 1. In case of separate writes: - no need to check ecc on data at scan time - must check erase status before write (we do that anyway) since data may=20 be written and oob not. Come to think of it we have to do it only on first allocation. 2. In case of a single write: - good crc on tags does not guarantee good ecc on data since it may be=20 a partial write. So what is the problem with two separate writes (data and oob)? Sergei ---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and pri= vileged information for the sole use of the intended recipient. Any review= , use, distribution, or disclosure by others is strictly prohibited. If yo= u are not the intended recipient (or authorized to receive information for = the intended recipient), please contact the sender by reply e-mail and dele= te all copies of this message. From tglx@linutronix.de Mon May 23 16:38:04 2005 From: tglx@linutronix.de (Thomas Gleixner) Date: Mon, 23 May 2005 17:38:04 +0200 Subject: [Yaffs] Re: power fail testing In-Reply-To: <487B538D08487B4D8FEC138A13D4F6AC9BF132@HOUEXCH077.corp.halliburton.com> References: <487B538D08487B4D8FEC138A13D4F6AC9BF132@HOUEXCH077.corp.halliburton.com> Message-ID: <1116862684.6736.82.camel@tglx.tec.linutronix.de> On Mon, 2005-05-23 at 09:37 -0500, Sergei Sharonov wrote: > > The WP directly controls the internal high voltage charge > > pump that drives > > the programming. If WP goes low, the hv will droop and the > > programming will not complete reliably. > > > > In most circuits I am familar with, the WP is strapped to Vcc > > which would allow in-progress writes to complete. > > Well, I just checked schematic and I did hook WP to global reset > signal, the one that comes from reset generator. Always thought it > was a good idea ;-) Even if you cut this line you will have a rare chance of corruption and the filesystem has to handle it. tglx From sergei.sharonov@halliburton.com Mon May 23 17:03:28 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Mon, 23 May 2005 16:03:28 +0000 (UTC) Subject: [Yaffs] Re: power fail testing References: <487B538D08487B4D8FEC138A13D4F6AC9BF132@HOUEXCH077.corp.halliburton.com> Message-ID: > This e-mail, including any attached files, may contain confidential and privileged information for the > sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly > prohibited. If you are not the intended recipient (or authorized to receive information for the intended > recipient), please contact the sender by reply e-mail and delete all copies of this message. > Ouups.. Sorry, used outlook to send email and it automatically attaches the footnote. I usually use gmane. Sergei From manningc2@actrix.gen.nz Mon May 23 20:27:31 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Tue, 24 May 2005 07:27:31 +1200 Subject: [Yaffs] Re: power fail testing --> seperate writes In-Reply-To: <487B538D08487B4D8FEC138A13D4F6AC9BF127@HOUEXCH077.corp.halliburton.com> References: <487B538D08487B4D8FEC138A13D4F6AC9BF127@HOUEXCH077.corp.halliburton.com> Message-ID: <20050523192617.9D7D715135@desire.actrix.co.nz> On Tuesday 24 May 2005 02:17, Sergei Sharonov wrote: > > Two things that can be done to improve the situation at the low level= : > > 1) Ensure that the whole page write is being done as a single > > write at the mtd level (ie. writing the data and oob as separate > > operations is not good). > > Hmm... I would think separate writes would be a good idea - then we > have a guarantee that data write has completed. That is if crc on tags > is good then no power failure has occurred during data write. On the > other > hand if we do a write in one gulp then valid crc on tags does not prove > that data is ok. So: > 1. In case of separate writes: > - no need to check ecc on data at scan time > - must check erase status before write (we do that anyway) since data > may > be written and oob not. Come to think of it we have to do it only on > first allocation. > 2. In case of a single write: > - good crc on tags does not guarantee good ecc on data since it may be > a partial write. > > So what is the problem with two separate writes (data and oob)? Seperate write are a bad idea because it is much slower. Two writes inst= ead=20 of one =3D=3D 400uS instead of 200uS. It still would not fix the problem since you could still get any corrupti= ons. -- Charles From arshad@commlinkllc.com Wed May 25 12:42:12 2005 From: arshad@commlinkllc.com (Muhammad Arshad Ul Abedin) Date: Wed, 25 May 2005 17:42:12 +0600 Subject: [Yaffs] How to extract .yaffs file Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C56151.19603D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, I am new to the YAFFS, and I have small question. I have a yaffs image for a SmartMedia card, which I want to expand and work on in my RedHat machine. Is there a way to extract the contents of the image so that I can modify the contents, make the image again through mkyaffsimage and write to the card through mkyaffs? Thanks in advance, Muhammad Arshad Ul Abedin. ------=_NextPart_000_0000_01C56151.19603D70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

I am new to the YAFFS, and I have small question. I = have a yaffs image for a SmartMedia card, which I want to expand and work on in = my RedHat machine. Is there a way to extract the contents of the image so that I = can modify the contents, make the image again through mkyaffsimage and write = to the card through mkyaffs?

 

Thanks in advance,

 

Muhammad Arshad Ul = Abedin.

 

------=_NextPart_000_0000_01C56151.19603D70-- From karl@micro-technic.com Wed May 25 21:14:13 2005 From: karl@micro-technic.com (Karl Olsen) Date: Wed, 25 May 2005 22:14:13 +0200 Subject: [Yaffs] Using the CVS version References: <002c01c5570a$fb672ea0$1f00a8c0@KARL> <20050513014225.160FE4340@blood.actrix.co.nz> Message-ID: <005801c56166$520d50d0$1f00a8c0@KARL> On Friday, May 13, 2005 3:43 AM [GMT+1=CET], Charles Manning wrote: > On Friday 13 May 2005 03:55, Karl Olsen wrote: >> I am using yaffs on Linux 2.6.11.5, based on the Frank Rowand >> patches from 2004-12-16. I was having some problems, so I wanted to >> try the current version, fetched as "Download tarball" from >> http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs/ . According to >> the CVS entries, some things have been fixed since last December. >> >> But after trying the patch-ker.sh (and adding the real yaffs files to >> fs/yaffs and the missing "obj-$(CONFIG_YAFFS_FS) += yaffs/" to >> fs/Makefile), it didn't compile at all. It looks like none of the >> necessary fixes that Frank Rowand made have been applied to CVS. Is >> there an up-to-date version somewhere, or what am I doing wrong? > > Some of Frank's patches were applied to what was in CVS, but not all. > Some were pretty much the same thing done a different way. I am sorry but I can only find one change related to Frank Rowand, the kill_block_super vs. kill_litter_super in yaffs_fs.c. He made many changes that were necessary to make the code compile under Linux 2.6. For example, he added "#include " at the top of many files, and without this in yaffs_mtdif.c, the functions in that file would never be compiled at all. yaffs_mtdif.c is described as version 1.10, 8 months old (from Sep 19 2004). The files under yaffs2/ look similar. I am looking at the "access the repository over the web" (http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/ ). Are there updated yaffs files available elsewhere? Kind regards, Karl Olsen From wookey@aleph1.co.uk Wed May 25 21:59:40 2005 From: wookey@aleph1.co.uk (Wookey) Date: Wed, 25 May 2005 21:59:40 +0100 Subject: [Yaffs] Re: Using the CVS version In-Reply-To: <005801c56166$520d50d0$1f00a8c0@KARL> References: <002c01c5570a$fb672ea0$1f00a8c0@KARL> <20050513014225.160FE4340@blood.actrix.co.nz> <005801c56166$520d50d0$1f00a8c0@KARL> Message-ID: <20050525205940.GB3991@xios> +++ Karl Olsen [05-05-25 22:14 +0200]: > On Friday, May 13, 2005 3:43 AM [GMT+1=CET], > Charles Manning wrote: > > >On Friday 13 May 2005 03:55, Karl Olsen wrote: > > >>I am using yaffs on Linux 2.6.11.5, based on the Frank Rowand > >>patches from 2004-12-16. I was having some problems, so I wanted to > >>try the current version, fetched as "Download tarball" from > >>http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs/ . According to > >>the CVS entries, some things have been fixed since last December. > >> > >>But after trying the patch-ker.sh (and adding the real yaffs files to > >>fs/yaffs and the missing "obj-$(CONFIG_YAFFS_FS) += yaffs/" to > >>fs/Makefile), it didn't compile at all. It looks like none of the > >>necessary fixes that Frank Rowand made have been applied to CVS. Is > >>there an up-to-date version somewhere, or what am I doing wrong? > > > >Some of Frank's patches were applied to what was in CVS, but not all. > >Some were pretty much the same thing done a different way. > > I am sorry but I can only find one change related to Frank Rowand, the > kill_block_super vs. kill_litter_super in yaffs_fs.c. He made many changes > that were necessary to make the code compile under Linux 2.6. For example, > he added "#include " at the top of many files, and without > this in yaffs_mtdif.c, the functions in that file would never be compiled at > all. yaffs_mtdif.c is described as version 1.10, 8 months old (from Sep 19 > 2004). The files under yaffs2/ look similar. > > I am looking at the "access the repository over the web" > (http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/ ). Are there updated yaffs > files available elsewhere? Nope - those are the right version. Looks like Charles has forgotten to check something in. There are yaffs and yaffs2 modules - it's possible some changes are in one and not the other? Thanx for checking up - we should make sure Franks patches don't get lost. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From wonwoo.chae@samsung.com Fri May 27 04:58:00 2005 From: wonwoo.chae@samsung.com (wonwoo.chae) Date: Fri, 27 May 2005 12:58:00 +0900 Subject: [Yaffs] Re: Message-ID: <0IH400JNSR31E8@mmp2.samsung.com> This is a multi-part message in MIME format. --Boundary_(ID_AwQySU2WTtc/jBGSCLrqgg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT confirm 544176 --Boundary_(ID_AwQySU2WTtc/jBGSCLrqgg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

confirm 544176

--Boundary_(ID_AwQySU2WTtc/jBGSCLrqgg)-- From Peter.B@LogicPD.com Tue May 31 16:43:50 2005 From: Peter.B@LogicPD.com (Peter Barada) Date: Tue, 31 May 2005 11:43:50 -0400 Subject: [Yaffs] Can YAFFS run on NOR flash? Message-ID: <1117554230.5224.88.camel@thunk> Are there patches anyone has to run YAFFS on NOR based flash? TIA. -- Peter Barada From wookey@aleph1.co.uk Tue May 31 17:38:52 2005 From: wookey@aleph1.co.uk (Wookey) Date: Tue, 31 May 2005 17:38:52 +0100 Subject: [Yaffs] Re: Can YAFFS run on NOR flash? In-Reply-To: <1117554230.5224.88.camel@thunk> References: <1117554230.5224.88.camel@thunk> Message-ID: <20050531163852.GX11014@xios> +++ Peter Barada [05-05-31 11:43 -0400]: > Are there patches anyone has to run YAFFS on NOR based flash? I think we need to put this up as a FAQ :-) People have asked about this a few times and been given general instructions on how to do it (maybe seing those on the list caused you to ask this question?), but I am not aware of any posted patches. Does anyone have any to post as they would make a useful starting point for anyone else doing the same thing. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From dy_wang@yahoo.com Thu Jun 2 18:09:02 2005 From: dy_wang@yahoo.com (wang dengyi) Date: Thu, 2 Jun 2005 10:09:02 -0700 (PDT) Subject: [Yaffs] Undefined reference Message-ID: <20050602170902.26972.qmail@web51908.mail.yahoo.com> Hello, I have arm board with a Toshiba 128MB NAND flash which is 528bytes/page. I downloaded the newest yaffs code and patch it to linux kernel 2.6.11.10. I select yafss and mtd support from muneconfig. After make, I got the error messages at the end: CHK include/linux/version.h make[1]: `arch/arm/kernel/asm-offsets.s' is up to date. make[1]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/compile.h CHK usr/initramfs_list CC fs/yaffs/yaffs_fs.o fs/yaffs/yaffs_fs.c:167: warning: initialization from incompatible pointer type fs/yaffs/yaffs_fs.c: In function `yaffs_internal_read_super': fs/yaffs/yaffs_fs.c:1279: warning: `dev' might be used uninitialized in this function fs/yaffs/yaffs_fs.c: At top level: fs/yaffs/yaffs_fs.c:689: warning: `yaffs_file_read' defined but not used fs/yaffs/yaffs_fs.c:1491: warning: `yaffs_internal_read_super_ram' defined but not used fs/yaffs/yaffs_fs.c:1561: warning: `my_proc_ram_write_entry' defined but not used fs/yaffs/yaffs_fs.c:1635: warning: `yaffs_proc_ram_write' defined but not used CC fs/yaffs/yaffs_mtdif.o LD fs/yaffs/yaffs.o LD fs/yaffs/built-in.o LD fs/built-in.o GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 fs/built-in.o(.text+0x7dac0): In function `yaffs_internal_read_super': : undefined reference to `nandmtd_WriteChunkToNAND' fs/built-in.o(.text+0x7dac4): In function `yaffs_internal_read_super': : undefined reference to `nandmtd_ReadChunkFromNAND' fs/built-in.o(.text+0x7dac8): In function `yaffs_internal_read_super': : undefined reference to `nandmtd_EraseBlockInNAND' fs/built-in.o(.text+0x7dacc): In function `yaffs_internal_read_super': : undefined reference to `nandmtd_InitialiseNAND' make: *** [.tmp_vmlinux1] Error 1 yaffs_mtdif does compile which include the 4 undefined functions. But why does it complain about the 4 functions. __________________________________ Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html From sergei.sharonov@halliburton.com Thu Jun 2 20:38:23 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Thu, 2 Jun 2005 19:38:23 +0000 (UTC) Subject: [Yaffs] Re: Undefined reference References: <20050602170902.26972.qmail@web51908.mail.yahoo.com> Message-ID: Wang, Check if CONFIG_YAFFS_MTD_ENABLED is really set. I would stick #error statement into one of the "missing" functions, compile and see if it blows up. Sergei From karl@micro-technic.com Fri Jun 3 07:28:34 2005 From: karl@micro-technic.com (Karl Olsen) Date: Fri, 3 Jun 2005 08:28:34 +0200 Subject: [Yaffs] Undefined reference References: <20050602170902.26972.qmail@web51908.mail.yahoo.com> Message-ID: <002a01c56805$77bff080$1f00a8c0@KARL> On Thursday, June 02, 2005 7:09 PM [GMT+1=CET], wang dengyi wrote: > I have arm board with a Toshiba 128MB NAND flash which > is 528bytes/page. > I downloaded the newest yaffs code and patch it to > linux kernel 2.6.11.10. I select yafss and mtd support > from muneconfig. After make, I got the error messages > at the end: > > CHK include/linux/version.h > make[1]: `arch/arm/kernel/asm-offsets.s' is up to > date. > make[1]: `include/asm-arm/mach-types.h' is up to date. > CHK include/linux/compile.h > CHK usr/initramfs_list > CC fs/yaffs/yaffs_fs.o > fs/yaffs/yaffs_fs.c:167: warning: initialization from > incompatible pointer type > fs/yaffs/yaffs_fs.c: In function > `yaffs_internal_read_super': > fs/yaffs/yaffs_fs.c:1279: warning: `dev' might be used > uninitialized in this function > fs/yaffs/yaffs_fs.c: At top level: > fs/yaffs/yaffs_fs.c:689: warning: `yaffs_file_read' > defined but not used > fs/yaffs/yaffs_fs.c:1491: warning: > `yaffs_internal_read_super_ram' defined but not used > fs/yaffs/yaffs_fs.c:1561: warning: > `my_proc_ram_write_entry' defined but not used > fs/yaffs/yaffs_fs.c:1635: warning: > `yaffs_proc_ram_write' defined but not used > CC fs/yaffs/yaffs_mtdif.o > LD fs/yaffs/yaffs.o > LD fs/yaffs/built-in.o > LD fs/built-in.o > GEN .version > CHK include/linux/compile.h > UPD include/linux/compile.h > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > fs/built-in.o(.text+0x7dac0): In function > `yaffs_internal_read_super': >> undefined reference to `nandmtd_WriteChunkToNAND' > fs/built-in.o(.text+0x7dac4): In function > `yaffs_internal_read_super': >> undefined reference to `nandmtd_ReadChunkFromNAND' > fs/built-in.o(.text+0x7dac8): In function > `yaffs_internal_read_super': >> undefined reference to `nandmtd_EraseBlockInNAND' > fs/built-in.o(.text+0x7dacc): In function > `yaffs_internal_read_super': >> undefined reference to `nandmtd_InitialiseNAND' > make: *** [.tmp_vmlinux1] Error 1 > > > yaffs_mtdif does compile which include the 4 undefined > functions. But why does it complain about the 4 > functions. See http://www.aleph1.co.uk/pipermail/yaffs/2005q2/001131.html Better to start with the Frank Rowand patches, and then manually apply later patches from CVS if necessary. See archives around 2004-12-16. Kind regards, Karl Olsen From Martin.Fouts@palmsource.com Fri Jun 3 09:11:37 2005 From: Martin.Fouts@palmsource.com (Martin Fouts) Date: Fri, 3 Jun 2005 01:11:37 -0700 Subject: [Yaffs] New dumb error: can't mount Message-ID: I thought I'd try yaffs2ram file system on a suse 9.2 distro runing the 2.6.8 kernel. I installed the source in linux/fs and modified linux/fs/Kconfig and linux/fs/Makefile appropriately. My new kernel definitely knows about yaffs: # cat /proc/yaffs YAFFS built:Jun 3 2005 00:31:47 $Id: yaffs_fs.c,v 1.5 2005/04/29 07:01:18 charles Exp $ $Id: yaffs_guts.c,v 1.6 2005/04/24 09:57:06 charles Exp $ And I definitely have yaffs2ram support in my kernel config file: CONFIG_YAFFS2_FS=3Dy CONFIG_YAFFS_YAFFS2=3Dy CONFIG_YAFFS2_MTD_ENABLED=3Dy CONFIG_YAFFS2_RAM_ENABLED=3Dy CONFIG_YAFFS2_USE_NANDECC=3Dy # CONFIG_YAFFS2_ECC_WRONG_ORDER is not set CONFIG_YAFFS2_USE_GENERIC_RW=3Dy # CONFIG_YAFFS2_USE_HEADER_FILE_SIZE is not set CONFIG_YAFFS2_DISABLE_CHUNK_ERASED_CHECK=3Dy CONFIG_YAFFS2_SHORT_NAMES_IN_RAM=3Dy But when I try to mount a yaffs2ram file system, I get an error: # mount -v -t yaffs2ram yaffs2 /mnt/yaffs2ram mount: special device yaffs2 does not exist # uname -a Linux marty 2.6.8-24-marty-yaffs2 #4 Fri Jun 3 00:51:33 PDT 2005 i686 i686 i386 GNU/Linux # ls -ld /mnt/yaffs2ram drwxr-xr-x 2 root root 4096 2005-06-02 09:56 /mnt/yaffs2ram So I'm off to debug this, but any pointers as to what to look for would be greatly appreciated. Marty From sergei.sharonov@halliburton.com Fri Jun 3 15:01:45 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Fri, 3 Jun 2005 14:01:45 +0000 (UTC) Subject: [Yaffs] Re: New dumb error: can't mount References: Message-ID: Martin, > # mount -v -t yaffs2ram yaffs2 /mnt/yaffs2ram > mount: special device yaffs2 does not exist you need something like /dev/mtdN or /dev/mtd/N for device. yaffs2 is not a valid device name. Make sure you have properly created this device before you use it. N=0,1,2.. Sergei From Martin.Fouts@palmsource.com Fri Jun 3 18:34:11 2005 From: Martin.Fouts@palmsource.com (Martin Fouts) Date: Fri, 3 Jun 2005 10:34:11 -0700 Subject: [Yaffs] Re: New dumb error: can't mount Message-ID: I'm confused. I thought yaffs2mem is a NODEV file system, like proc, and didn't need a device. It certainly registers itself as one. I understand that yaffs2 would need 'yaffs2' replaced by the dev name of the mtd block device that the mount was for, but shouldn't 'yaffs2' just be a placeholder for yaffs2mem? Marty -----Original Message----- From: yaffs-admin@stoneboat.aleph1.co.uk [mailto:yaffs-admin@stoneboat.aleph1.co.uk] On Behalf Of Sergei Sharonov Sent: Friday, June 03, 2005 7:02 AM To: yaffs@stoneboat.aleph1.co.uk Subject: [Yaffs] Re: New dumb error: can't mount Martin, > # mount -v -t yaffs2ram yaffs2 /mnt/yaffs2ram > mount: special device yaffs2 does not exist you need something like /dev/mtdN or /dev/mtd/N for device. yaffs2 is not a valid device name. Make sure you have properly created this device before you use it. N=3D0,1,2.. Sergei _______________________________________________ yaffs mailing list yaffs@stoneboat.aleph1.co.uk http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From dy_wang@yahoo.com Mon Jun 6 18:58:20 2005 From: dy_wang@yahoo.com (wang dengyi) Date: Mon, 6 Jun 2005 10:58:20 -0700 (PDT) Subject: [Yaffs] Bad eraseblock Message-ID: <20050606175820.23020.qmail@web51901.mail.yahoo.com> Hello, My embedded system is AT91RM9200(arm9) with linux 2.6.11.10. My NAND flash is Toshiba TC58DVG02A1FT00. The flash has 8192 blocks. When linux boots, it reports that the first 2105 blocks are "Bad eraseblock". What does it mean? I check the code. It's in the function create_bbt(). Seems it reads the flash and compares with some pattern then shows the error message. Does it affect anything at all? __________________________________ Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html From dy_wang@yahoo.com Mon Jun 6 19:06:24 2005 From: dy_wang@yahoo.com (wang dengyi) Date: Mon, 6 Jun 2005 11:06:24 -0700 (PDT) Subject: [Yaffs] Cannot allocate memory Message-ID: <20050606180624.85264.qmail@web51905.mail.yahoo.com> Hello, After "mount -t yaffs /dev/mtdblock/2 /mnt/f", I cannot create any file on the flash. I always get the error message: "... Cannot allocate memory". Afte I use "df /mnt/f", it shows 100% for use%. But I already deleted everything in that directory except the "lost+found" which I cannot delete. Could anyone give me some hint on it? Someone already asked this kind of quesiton. But I didn't find the answer. The solution I can think, is to erase the flash. But how. Yaffs does not provide the util to do that. __________________________________ Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html From blair@circumnavnetworks.com Mon Jun 6 23:14:23 2005 From: blair@circumnavnetworks.com (Blair Barnett) Date: Mon, 06 Jun 2005 15:14:23 -0700 Subject: [Yaffs] Cannot allocate memory In-Reply-To: <20050606180624.85264.qmail@web51905.mail.yahoo.com> References: <20050606180624.85264.qmail@web51905.mail.yahoo.com> Message-ID: <1118096063.23367.7.camel@blairs-desktop> Hi, The mtd utilities might prove to be useful here. Unmount the questionable filesystem and try 'flash_eraseall /dev/mtdX' where X is the partition number you'd like to erase. You'll have to reinstall the YAFFS image, I believe. You'll have to do this with the partition unmounted. You could also mount the newly erased partition and start writing files into this new partition. -blair On Mon, 2005-06-06 at 11:06, wang dengyi wrote: > Hello, > > After "mount -t yaffs /dev/mtdblock/2 /mnt/f", I > cannot create any file on the flash. I always get the > error message: "... Cannot allocate memory". Afte I > use "df /mnt/f", it shows 100% for use%. But I already > deleted everything in that directory except the > "lost+found" which I cannot delete. Could anyone give > me some hint on it? Someone already asked this kind of > quesiton. But I didn't find the answer. > > The solution I can think, is to erase the flash. But > how. Yaffs does not provide the util to do that. > From chao.xie@intel.com Tue Jun 7 02:28:34 2005 From: chao.xie@intel.com (Xie, Chao) Date: Tue, 7 Jun 2005 09:28:34 +0800 Subject: [Yaffs] Bad eraseblock Message-ID: <571ACEFD467F7749BC50E0A98C17CDD806EEF6E7@pdsmsx403> Hi First, you should make clear which byte in OOB of your nand flash = indicates the bad block. I think the spec has described it. If you have erased the nand flash with the bad blocks, the bad block = information may be lost, and you may get wrong bad block warnings. Best Regards Chao -----Original Message----- From: yaffs-admin@stoneboat.aleph1.co.uk = [mailto:yaffs-admin@stoneboat.aleph1.co.uk] On Behalf Of wang dengyi Sent: 2005=C4=EA6=D4=C27=C8=D5 1:58 To: yaffs@stoneboat.aleph1.co.uk Subject: [Yaffs] Bad eraseblock Hello, My embedded system is AT91RM9200(arm9) with linux 2.6.11.10. My NAND flash is Toshiba TC58DVG02A1FT00.=20 The flash has 8192 blocks. When linux boots, it reports that the first 2105 blocks are "Bad eraseblock". What does it mean? I check the code. It's in the function create_bbt(). Seems it reads the flash and compares with some pattern then shows the error message. Does it affect anything at all? =09 __________________________________=20 Discover Yahoo!=20 Get on-the-go sports scores, stock quotes, news and more. Check it out!=20 http://discover.yahoo.com/mobile.html _______________________________________________ yaffs mailing list yaffs@stoneboat.aleph1.co.uk http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From coywolf@lovecn.org Tue Jun 7 03:43:18 2005 From: coywolf@lovecn.org (Coywolf Qi Hunt) Date: Tue, 7 Jun 2005 10:43:18 +0800 Subject: [Yaffs] Bad eraseblock In-Reply-To: <571ACEFD467F7749BC50E0A98C17CDD806EEF6E7@pdsmsx403> References: <571ACEFD467F7749BC50E0A98C17CDD806EEF6E7@pdsmsx403> Message-ID: <2cd57c90050606194371634cac@mail.gmail.com> T24gNi83LzA1LCBYaWUsIENoYW8gPGNoYW8ueGllQGludGVsLmNvbT4gd3JvdGU6Cj4gSGkKPiAg ICAgICAgIEZpcnN0LCB5b3Ugc2hvdWxkIG1ha2UgY2xlYXIgd2hpY2ggYnl0ZSBpbiBPT0Igb2Yg eW91ciBuYW5kIGZsYXNoIGluZGljYXRlcyB0aGUgYmFkIGJsb2NrLiBJIHRoaW5rIHRoZSBzcGVj IGhhcyBkZXNjcmliZWQgaXQuCgpJdCBpcyB0aGUgc3RhbmRhcmQgbG9jYXRpb24sIGJ5dGUgNTE3 LgoKPiAgICAgICAgIElmIHlvdSBoYXZlIGVyYXNlZCB0aGUgbmFuZCBmbGFzaCB3aXRoIHRoZSBi YWQgYmxvY2tzLCB0aGUgYmFkIGJsb2NrIGluZm9ybWF0aW9uIG1heSBiZSBsb3N0LCBhbmQgeW91 IG1heSBnZXQgd3JvbmcgYmFkIGJsb2NrIHdhcm5pbmdzLgoKSSBkb24ndCB0aGluayB0aGVyZSBl eGlzdCBhbnkgYmFkIGJsb2NrIHVuYXdhcmUgZXJhc3VyZSB0b29scy4KCj4gCj4gQmVzdCBSZWdh cmRzCj4gQ2hhbwo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogeWFmZnMtYWRt aW5Ac3RvbmVib2F0LmFsZXBoMS5jby51ayBbbWFpbHRvOnlhZmZzLWFkbWluQHN0b25lYm9hdC5h bGVwaDEuY28udWtdIE9uIEJlaGFsZiBPZiB3YW5nIGRlbmd5aQo+IFNlbnQ6IDIwMDXE6jbUwjfI 1SAxOjU4Cj4gVG86IHlhZmZzQHN0b25lYm9hdC5hbGVwaDEuY28udWsKPiBTdWJqZWN0OiBbWWFm ZnNdIEJhZCBlcmFzZWJsb2NrCj4gCj4gSGVsbG8sCj4gCj4gTXkgZW1iZWRkZWQgc3lzdGVtIGlz IEFUOTFSTTkyMDAoYXJtOSkgd2l0aCBsaW51eAo+IDIuNi4xMS4xMC4gTXkgTkFORCBmbGFzaCBp cyBUb3NoaWJhIFRDNThEVkcwMkExRlQwMC4KPiAKPiBUaGUgZmxhc2ggaGFzIDgxOTIgYmxvY2tz LiBXaGVuIGxpbnV4IGJvb3RzLCBpdAo+IHJlcG9ydHMgdGhhdCB0aGUgZmlyc3QgMjEwNSBibG9j a3MgYXJlICJCYWQKPiBlcmFzZWJsb2NrIi4gV2hhdCBkb2VzIGl0IG1lYW4/IEkgY2hlY2sgdGhl IGNvZGUuIEl0J3MKPiBpbiB0aGUgZnVuY3Rpb24gY3JlYXRlX2JidCgpLiBTZWVtcyBpdCByZWFk cyB0aGUgZmxhc2gKPiBhbmQgY29tcGFyZXMgd2l0aCBzb21lIHBhdHRlcm4gdGhlbiBzaG93cyB0 aGUgZXJyb3IKPiBtZXNzYWdlLiBEb2VzIGl0IGFmZmVjdCBhbnl0aGluZyBhdCBhbGw/Cj4gCgoK Ci0tIApDb3l3b2xmIFFpIEh1bnQKaHR0cDovL2FoYmwub3JnL35jb3l3b2xmLwo= From Coywolf Qi Hunt Tue Jun 7 04:47:52 2005 From: Coywolf Qi Hunt (Coywolf Qi Hunt) Date: Tue, 7 Jun 2005 11:47:52 +0800 Subject: [Yaffs] Bad eraseblock In-Reply-To: <571ACEFD467F7749BC50E0A98C17CDD806EEF6E7@pdsmsx403> References: <571ACEFD467F7749BC50E0A98C17CDD806EEF6E7@pdsmsx403> Message-ID: <2cd57c90050606204730fe9ccc@mail.gmail.com> On 6/7/05, Xie, Chao wrote: > Hi > First, you should make clear which byte in OOB of your nand flash= indicates the bad block. I think the spec has described it. It is the standard location, byte 517. > If you have erased the nand flash with the bad blocks, the bad bl= ock information may be lost, and you may get wrong bad block warnings. I don't think there exist any bad block unaware erasure tools. --=20 Coywolf Qi Hunt http://ahbl.org/~coywolf/ From wookey@aleph1.co.uk Tue Jun 7 09:53:02 2005 From: wookey@aleph1.co.uk (Wookey) Date: Tue, 7 Jun 2005 09:53:02 +0100 Subject: [Yaffs] Re: Bad eraseblock In-Reply-To: <20050606175820.23020.qmail@web51901.mail.yahoo.com> References: <20050606175820.23020.qmail@web51901.mail.yahoo.com> Message-ID: <20050607085301.GW1652@xios> +++ wang dengyi [05-06-06 10:58 -0700]: > Hello, > > My embedded system is AT91RM9200(arm9) with linux > 2.6.11.10. My NAND flash is Toshiba TC58DVG02A1FT00. > > The flash has 8192 blocks. When linux boots, it > reports that the first 2105 blocks are "Bad > eraseblock". What does it mean? It probably means something has gone wrong :-) In simple terms it means this block appears to be marked bad in the OOB. Assuming that these blocks aren't _really_ bad (there should be no more than 5% bad to start with) the problem is likely to be a confusion between different bit of software over which mapping is used for ECC bytes. There are various arrangements that can be used for these bytes. If one bit of software (or hardware) is writing one arrangement, and another is expecting another arrangement, then every changed block can come out 'apparently bad'. e.g if the bootloader is writing images with a different layout to yaffs in the filesystem, or hardware ecc is present but yaffs has been compiled for soft ecc (with a different layout) or jffs2 and yaffs are both being used but with different layouts. All of these will screw up your flash. It may have been that whilst getting used to yaffs you booted with some other scheme once before getting the settings how they are now - same effect is possible, under some circumstances. To fix it you just have to completely erase the flash, including the bad-block markers. This normally gives you all your flash back, although there is a small risk that it will screw it up if the factory-marked bad blocks take offense at being re-used - I don't think anyone has seen this problem in practice. The MTDutils will help you with the erasing. I'm not sure if anyone has actually hacked a tool foris job yet or if you have to mess with nandwrite so that it will let you nobble the bad blocks. Of course it could be some other problem, but mismatched ECC is the most usual cause of this sort of thing. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From sergei.sharonov@halliburton.com Tue Jun 7 13:03:06 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Tue, 7 Jun 2005 12:03:06 +0000 (UTC) Subject: [Yaffs] Re: Bad eraseblock References: <20050606175820.23020.qmail@web51901.mail.yahoo.com> <20050607085301.GW1652@xios> Message-ID: Hi, > The MTDutils will help you with the erasing. I'm not sure if anyone has > actually hacked a tool foris job yet or if you have to mess with nandwrite > so that it will let you nobble the bad blocks. You need to hack both flash_eraseall and mtd (nand_base.c : nand_erase_nand()) to bypass bad block checking. I've done that and others did as well. You supposedly may kill the chip by doing that but I have not seen this happen. > Of course it could be some other problem, but mismatched ECC is the most > usual cause of this sort of thing. YAFFS may wrongly create bad blocks under power cycling but not as many you see. Sergei From tglx@linutronix.de Tue Jun 7 13:59:05 2005 From: tglx@linutronix.de (Thomas Gleixner) Date: Tue, 07 Jun 2005 14:59:05 +0200 Subject: [Yaffs] Re: Bad eraseblock In-Reply-To: References: <20050606175820.23020.qmail@web51901.mail.yahoo.com> <20050607085301.GW1652@xios> Message-ID: <1118149145.20785.497.camel@tglx.tec.linutronix.de> On Tue, 2005-06-07 at 12:03 +0000, Sergei Sharonov wrote: > Hi, > > > The MTDutils will help you with the erasing. I'm not sure if anyone has > > actually hacked a tool foris job yet or if you have to mess with nandwrite > > so that it will let you nobble the bad blocks. > > You need to hack both flash_eraseall and mtd (nand_base.c : nand_erase_nand()) > to bypass bad block checking. Its sufficient to tweak the nand_block_checkbad() function to return 0. tglx From Ramesh Chaurasiya Mon Jun 13 16:13:26 2005 From: Ramesh Chaurasiya (Ramesh Chaurasiya) Date: Mon, 13 Jun 2005 20:43:26 +0530 Subject: [Yaffs] YAFFS on kernel 2.4 Message-ID: <5585a0780506130813f743ded@mail.gmail.com> Hi, I am trying to get NAND flash work on kernel 2.4 can anyone please tell me from where can I get yaffs source appropriate for kernel 2.4 The source available today at http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/ seems to be meant for kernel 2.6 --=20 Thanks, Ramesh From nick@cecomputing.co.uk Mon Jun 13 16:58:56 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Mon, 13 Jun 2005 16:58:56 +0100 Subject: [Yaffs] YAFFS on kernel 2.4 In-Reply-To: <5585a0780506130813f743ded@mail.gmail.com> Message-ID: Look at husaberg.toby-churchill.com/balloon/ and wget the = 2.4.25-vrs2-tcl1 tree. Nick Bane > -----Original Message----- > From: yaffs-admin@stoneboat.aleph1.co.uk > [mailto:yaffs-admin@stoneboat.aleph1.co.uk]On Behalf Of Ramesh > Chaurasiya > Sent: 13 June 2005 16:13 > To: yaffs@stoneboat.aleph1.co.uk > Subject: [Yaffs] YAFFS on kernel 2.4 >=20 >=20 > Hi, > I am trying to get NAND flash work on kernel 2.4 > can anyone please tell me from where can I get yaffs source > appropriate for kernel 2.4 >=20 > The source available today at = http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/ > seems to be meant for kernel 2.6 >=20 > --=20 > Thanks, > Ramesh >=20 > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > --=20 > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: 11/06/2005 >=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: 11/06/2005 From Coywolf Qi Hunt Tue Jun 14 01:54:59 2005 From: Coywolf Qi Hunt (Coywolf Qi Hunt) Date: Tue, 14 Jun 2005 08:54:59 +0800 Subject: [Yaffs] YAFFS on kernel 2.4 In-Reply-To: <5585a0780506130813f743ded@mail.gmail.com> References: <5585a0780506130813f743ded@mail.gmail.com> Message-ID: <2cd57c9005061317543d7d37d2@mail.gmail.com> On 6/13/05, Ramesh Chaurasiya wrote: > Hi, > I am trying to get NAND flash work on kernel 2.4 > can anyone please tell me from where can I get yaffs source > appropriate for kernel 2.4 >=20 > The source available today at http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi= / > seems to be meant for kernel 2.6 The code seems support 2.4 too. --=20 Coywolf Qi Hunt http://ahbl.org/~coywolf/ From vvillatora@seltatel.it Tue Jun 14 09:51:24 2005 From: vvillatora@seltatel.it (Villatora Virgilio) Date: Tue, 14 Jun 2005 10:51:24 +0200 Subject: [Yaffs] yaffs filesystem check utility Message-ID: <0919CB1D9CD143409F2C7CC840B1DED6034285@slttex001.selta-tel.selta-spa.local> This is a multi-part message in MIME format. ------_=_NextPart_001_01C570BE.3E3E92B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpEZWFyIGFsbCwNCkkgaGF2ZSBhIHByb2JsZW0gcmVnYXJkaW5nIHRoZSB5YWZmcyBmcyBj aGVja2luZyB1dGlsaXR5Lg0KDQpNeSBlbWJlZGRlZCBtYWNoaW5lIHJ1bnMgdW5kZXIgTGlu dXggKERlYmlhbiBkaXN0cmlidXRpb24pIDIuNC4xOS1ybWs0KHYyXzExKS4NCg0KV2UgdXNl IGEgTkFORCBmbGFzaCBkZXZpY2UgKDUxMmsgYnl0ZSBwZXIgcGFnZSkgZGl2aWRlZCBpbiA0 IHBhcnRpdGlvbnMuDQpUaGUgZmlyc3QgdHdvICgyTUIgZWFjaCkgY29udGFpbnMgYSBzcGVj aWFsIEZXIGFuZCB6SW1hZ2Ugb2YgdGhlIGtlcm5lbDsNClRoZSB0aGlyZCBvbmUgY29udGFp bnMgYSB5YWZmcyBmaWxlIHN5c3RlbSBpbWFnZS4NCg0KVGhlIHN5c3RlbSB3b3JrcyBjb3Jy ZWN0bHkgZm9yIHNldmVyYWwgZGF5cy4NCkFmdGVyIHRoaXMgcGVyaW9kIHRoZSBrZXJuZWwg YmVnaW5zIHRvIGdpdmUgc3RyYW5nZSBtZXNzYWdlcyBhbmQgYXQgdGhlIHJlYm9vdA0KdGhl IGZvdXJ0aCBwYXJ0aXRpb24gY2Fubm90IGJlIG1vdW50ZWQuDQoNCldlIHRoaW5rIHRoYXQg aXQgY291bGQgZGVwZW5kIGZyb20gYmFkIHRyYWNrcyBtYW5hZ2VtZW50Lg0KDQpBdCBzeXN0 ZW0gYm9vdCBJIGNhbiByZWFkIGFuIGVycm9yIG1lc3NhZ2Ugb24gdGhlIGNvbnNvbGU6DQoi Li4uDQpmc2NrIHYxLjI3IC4uLi4NCmZzY2sgZXJyb3I6IGZzY2sueWFmZnMgbm90IGZvdW5k DQplcnJvciAyIHdoaWxlIGV4ZWN1dGluZyBmc2NrDQouLi4NCiINCmFuZCBpZiB5b3UgY2hl Y2sgdW5kZXIgL3NiaW4gZGlyIGZzY2sueWFmZnMgZmlsZSBkb2VzIG5vdCBleGlzdC4uLig/ KQ0KSSBoYXZlIGxvb2tlZCBmb3IgdGhlIHBhY2thZ2UgdW5kZXIgRGViaWFuIHdlYiBzaXRl IHdpdGggbm8gc3VjY2Vzcy4NCkNhbiB5b3UgaGVscCBtZSBpbiBmaW5kaW5nIC5kZWIgcGFj a2FnZSBvZiB0aGlzIHV0aWxpdHkgT1IgYW5vdGhlciANCnV0aWxpdHkgdGhhdCBtYWtlcyB0 aGUgc2FtZSBjaGVjayBvbiB0aGUgZmlsZSBteSB5YWZmcyBmaWxlc3lzdGVtID8NCg0KVGhh bmsgeW91IGluIGFkdmFuY2UuLi4NCg0KVmlyZ2lsaW8gVmlsbGF0b3JhIEVuZy4NClNFTFRB IFRlbGVtYXRpY2EgUy5wLkEuDQpUT1JUT1JFVE8gKFRFKQ0KSVRBTFkNCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNClRoZSBpbmZvcm1hdGlvbiBpbiB0aGlzIG1lc3NhZ2UgaXMgY29uZmlkZW50aWFs IGFuZCBtYXkgYmUgbGVnYWxseQ0KcHJpdmlsZWdlZC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgYWRkcmVzc2VlLiBBY2Nlc3MgdG8gdGhpcyBtZXNzYWdlDQpieSBhbnlvbmUg ZWxzZSBpcyB1bmF1dGhvcml6ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIGFueQ0KZGlzY2xvc3VyZSwgY29weWluZywgb3IgZGlzdHJpYnV0aW9uIG9mIHRo ZSBtZXNzYWdlLCBvciBhbnkgYWN0aW9uIG9yDQpvbWlzc2lvbiB0YWtlbiBieSB5b3UgaW4g cmVsaWFuY2Ugb24gaXQsIGlzIHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NClBs ZWFzZSBpbW1lZGlhdGVseSBjb250YWN0IHRoZSBzZW5kZXIgaWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBtZXNzYWdlIGluDQplcnJvci4NCg0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg== ------_=_NextPart_001_01C570BE.3E3E92B4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhU TUw+DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0i dGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9y IiBDT05URU5UPSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA2LjUuNzIyNi4wIj4NCjxU SVRMRT55YWZmcyBmaWxlc3lzdGVtIGNoZWNrIHV0aWxpdHk8L1RJVExFPg0KPC9IRUFEPg0K PEJPRFk+DQo8IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPg0KPEJS Pg0KDQo8UD48Rk9OVCBTSVpFPTI+RGVhciBhbGwsPEJSPg0KSSBoYXZlIGEgcHJvYmxlbSBy ZWdhcmRpbmcgdGhlIHlhZmZzIGZzIGNoZWNraW5nIHV0aWxpdHkuPEJSPg0KPEJSPg0KTXkg ZW1iZWRkZWQgbWFjaGluZSBydW5zIHVuZGVyIExpbnV4IChEZWJpYW4gZGlzdHJpYnV0aW9u KSAyLjQuMTktcm1rNCh2Ml8xMSkuPEJSPg0KPEJSPg0KV2UgdXNlIGEgTkFORCBmbGFzaCBk ZXZpY2UgKDUxMmsgYnl0ZSBwZXIgcGFnZSkgZGl2aWRlZCBpbiA0IHBhcnRpdGlvbnMuPEJS Pg0KVGhlIGZpcnN0IHR3byAoMk1CIGVhY2gpIGNvbnRhaW5zIGEgc3BlY2lhbCBGVyBhbmQg ekltYWdlIG9mIHRoZSBrZXJuZWw7PEJSPg0KVGhlIHRoaXJkIG9uZSBjb250YWlucyBhIHlh ZmZzIGZpbGUgc3lzdGVtIGltYWdlLjxCUj4NCjxCUj4NClRoZSBzeXN0ZW0gd29ya3MgY29y cmVjdGx5IGZvciBzZXZlcmFsIGRheXMuPEJSPg0KQWZ0ZXIgdGhpcyBwZXJpb2QgdGhlIGtl cm5lbCBiZWdpbnMgdG8gZ2l2ZSBzdHJhbmdlIG1lc3NhZ2VzIGFuZCBhdCB0aGUgcmVib290 PEJSPg0KdGhlIGZvdXJ0aCBwYXJ0aXRpb24gY2Fubm90IGJlIG1vdW50ZWQuPEJSPg0KPEJS Pg0KV2UgdGhpbmsgdGhhdCBpdCBjb3VsZCBkZXBlbmQgZnJvbSBiYWQgdHJhY2tzIG1hbmFn ZW1lbnQuPEJSPg0KPEJSPg0KQXQgc3lzdGVtIGJvb3QgSSBjYW4gcmVhZCBhbiBlcnJvciBt ZXNzYWdlIG9uIHRoZSBjb25zb2xlOjxCUj4NCiZxdW90Oy4uLjxCUj4NCmZzY2sgdjEuMjcg Li4uLjxCUj4NCmZzY2sgZXJyb3I6IGZzY2sueWFmZnMgbm90IGZvdW5kPEJSPg0KZXJyb3Ig MiB3aGlsZSBleGVjdXRpbmcgZnNjazxCUj4NCi4uLjxCUj4NCiZxdW90OzxCUj4NCmFuZCBp ZiB5b3UgY2hlY2sgdW5kZXIgL3NiaW4gZGlyIGZzY2sueWFmZnMgZmlsZSBkb2VzIG5vdCBl eGlzdC4uLig/KTxCUj4NCkkgaGF2ZSBsb29rZWQgZm9yIHRoZSBwYWNrYWdlIHVuZGVyIERl YmlhbiB3ZWIgc2l0ZSB3aXRoIG5vIHN1Y2Nlc3MuPEJSPg0KQ2FuIHlvdSBoZWxwIG1lIGlu IGZpbmRpbmcgLmRlYiBwYWNrYWdlIG9mIHRoaXMgdXRpbGl0eSBPUiBhbm90aGVyPEJSPg0K dXRpbGl0eSB0aGF0IG1ha2VzIHRoZSBzYW1lIGNoZWNrIG9uIHRoZSBmaWxlIG15IHlhZmZz IGZpbGVzeXN0ZW0gPzxCUj4NCjxCUj4NClRoYW5rIHlvdSBpbiBhZHZhbmNlLi4uPEJSPg0K PEJSPg0KVmlyZ2lsaW8gVmlsbGF0b3JhIEVuZy48QlI+DQpTRUxUQSBUZWxlbWF0aWNhIFMu cC5BLjxCUj4NClRPUlRPUkVUTyAoVEUpPEJSPg0KSVRBTFk8QlI+DQo8L0ZPTlQ+DQo8L1A+ DQoNCjwvQk9EWT4NCjwvSFRNTD48cHJlPioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoZSBpbmZvcm1h dGlvbiBpbiB0aGlzIG1lc3NhZ2UgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgYmUgbGVnYWxs eQ0KcHJpdmlsZWdlZC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vl LiBBY2Nlc3MgdG8gdGhpcyBtZXNzYWdlDQpieSBhbnlvbmUgZWxzZSBpcyB1bmF1dGhvcml6 ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueQ0KZGlzY2xv c3VyZSwgY29weWluZywgb3IgZGlzdHJpYnV0aW9uIG9mIHRoZSBtZXNzYWdlLCBvciBhbnkg YWN0aW9uIG9yDQpvbWlzc2lvbiB0YWtlbiBieSB5b3UgaW4gcmVsaWFuY2Ugb24gaXQsIGlz IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NClBsZWFzZSBpbW1lZGlhdGVseSBj b250YWN0IHRoZSBzZW5kZXIgaWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGlu DQplcnJvci4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvcHJlPg== ------_=_NextPart_001_01C570BE.3E3E92B4-- From nick@cecomputing.co.uk Tue Jun 14 10:48:11 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Tue, 14 Jun 2005 10:48:11 +0100 Subject: [Yaffs] OneNAND Message-ID: Charles/Thomas and other What are the implications of Samsungs OneNAND chips on yaffs/mtd? It = looks like they are yaffs1 block style internally on a 16-bit address = and data bus with densities up to 4Gbit in mass production now. Access = is fairly dissimilar to generic nand though. They are essentially a buffered NAND with hardware ecc built in giving = very fast access times as well as a 1K boot cache xip area. It looks like the oob is accessible but in a slightly restriced way. = Hopefully this can all be hidden from yaffs per se via the mtd layer. = Are there plans to support OneNAND Thomas? I note the mtd thread in Feb started by samsung (starting from = http://lists.infradead.org/pipermail/linux-mtd/2005-February/011860.html)= . The mood seemed to be to split off OneNAND from generic nand as the = access is so different. I was unclear whether this presents OneNAND as = non generic NAND mtd technology possibly requiring changes to yaffs eg = the test for the device being an "mtd-nand" at mount time. See = http://www.samsung.com/Products/Semiconductor/Flash/OneNAND_TM/1Gbit/KFG1= G16U2M/KFG1G16U2M.htm for example info. Nick ----------------------- Nick Bane nick@cecomputing.co.uk +44 (0)1954 719270=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.1 - Release Date: 13/06/2005 From tglx@linutronix.de Tue Jun 14 11:09:43 2005 From: tglx@linutronix.de (Thomas Gleixner) Date: Tue, 14 Jun 2005 12:09:43 +0200 Subject: [Yaffs] OneNAND In-Reply-To: References: Message-ID: <1118743783.2989.8.camel@tglx.tec.linutronix.de> On Tue, 2005-06-14 at 10:48 +0100, Nick Bane wrote: > It looks like the oob is accessible but in a slightly restriced way. > Hopefully this can all be hidden from yaffs per se via the mtd layer. > Are there plans to support OneNAND Thomas? > In principle yes, but I still wait for the Samsung driver to show up or a contract to do it myself :) > I note the mtd thread in Feb started by samsung (starting from > http://lists.infradead.org/pipermail/linux-mtd/2005-February/011860.html). The mood seemed to be to split off OneNAND from generic nand as the access is so different. I was unclear whether this presents OneNAND as non generic NAND mtd technology possibly requiring changes to yaffs eg the test for the device being an "mtd-nand" at mount time. I'm not sure either. I have just skimmed the datasheet, but it might be possible to setup a NAND compatible API tglx From nick@cecomputing.co.uk Tue Jun 14 13:39:57 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Tue, 14 Jun 2005 13:39:57 +0100 Subject: [Yaffs] OneNAND In-Reply-To: <1118743783.2989.8.camel@tglx.tec.linutronix.de> Message-ID: > > It looks like the oob is accessible but in a slightly restriced way. > > Hopefully this can all be hidden from yaffs per se via the mtd = layer. > > Are there plans to support OneNAND Thomas? > >=20 > In principle yes, but I still wait for the Samsung driver to show up = or > a contract to do it myself :) >=20 Ok. > > I note the mtd thread in Feb started by samsung (starting from > >=20 > http://lists.infradead.org/pipermail/linux-mtd/2005-February/01186 > 0.html). The mood seemed to be to split off OneNAND from generic=20 > nand as the access is so different. I was unclear whether this=20 > presents OneNAND as non generic NAND mtd technology possibly=20 > requiring changes to yaffs eg the test for the device being an=20 > "mtd-nand" at mount time. >=20 > I'm not sure either. I have just skimmed the datasheet, but it might = be > possible to setup a NAND compatible API=20 >=20 It looks like there are only 2 bytes of user usable data in the "spare" = area. Although yaffs won't need to do so much ecc it looks like yaffs = will have a problem with that little spare space unless one can use = bigger virtual blocks. Charles? Nick > tglx >=20 >=20 >=20 > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > --=20 > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.7.1 - Release Date: 13/06/2005 >=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.1 - Release Date: 13/06/2005 From rick@efn.org Tue Jun 14 23:29:00 2005 From: rick@efn.org (Rick Bronson) Date: Tue, 14 Jun 2005 15:29:00 -0700 Subject: [Yaffs] Anyone using yaffs in u-boot? Message-ID: Hi, It looks like someone in Korea is using yaffs on uboot. If you google: "nand read" yaffs uboot site:kr but the code doesn't seem to be available. Just wondered if anyone here knows how to get yaffs support in uboot? Thanks very much for any help. Rick Bronson _ | | / /__ .----------------------------------------------------------._____/ (___) | Rick Bronson rick@efn.org Tel 541-485-7264 | (___) | Amazonia Computing http://www.efn.org/~rick __ o |_____ (___) | 5050 Donald Street "Onde esta dinheiro?" _`\<, | \_(___) | Eugene, OR 97405 -- Gal Costa __( )/( )__ | `----------------------------------------------------------' From andre@bluewatersys.com Tue Jun 14 23:56:20 2005 From: andre@bluewatersys.com (Andre Renaud) Date: Wed, 15 Jun 2005 10:56:20 +1200 Subject: [Yaffs] Anyone using yaffs in u-boot? In-Reply-To: References: Message-ID: <1118789780.1122.5.camel@benmore> --=-igUJOn9zNenbG/+ICmDX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-06-14 at 15:29 -0700, Rick Bronson wrote: > Hi, >=20 > It looks like someone in Korea is using yaffs on uboot. If you > google: >=20 > "nand read" yaffs uboot site:kr >=20 > but the code doesn't seem to be available. Just wondered if anyone > here knows how to get yaffs support in uboot? =46rom the looks of the site, they haven't implemented YAFFS filesystem support, just the ability to write a yaffs image directly into NAND and have it cope with bad blocks correctly. You still couldn't copy a linux kernel out of the yaffs filesystem and into memory for booting from for instance. The code does appear to be available at: http://kelp.or.kr/korweblog/stories.php?story=3D04/06/30/7742286 You just have to cut and paste it out of the html. Probably not particularly useful though. --=20 Bluewater Systems Ltd - ARM Technology Solutions Centre Andre Renaud Bluewater Systems Ltd Phone: +64 3 3779127 (Aus 1 800 148 751) Level 17, 119 Armagh St Fax: +64 3 3779135 PO Box 13889 Email: arenaud@bluewatersys.com Christchurch Web: http://www.bluewatersys.com New Zealand --=-igUJOn9zNenbG/+ICmDX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCr2CU8TW+L7DOlmkRAs2DAJ9PEesGlWpEId0WIC3Kt2sS20goowCfT1/u 7YRIUnRSQr9GyNziOOjbAN4= =x/HM -----END PGP SIGNATURE----- --=-igUJOn9zNenbG/+ICmDX-- From manningc2@actrix.gen.nz Wed Jun 15 00:10:30 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Wed, 15 Jun 2005 11:10:30 +1200 Subject: [Yaffs] OneNAND In-Reply-To: References: Message-ID: <20050614230817.E247F152A1@desire.actrix.co.nz> I have not read the whole OneNAND spec yet. On Wednesday 15 June 2005 00:39, Nick Bane wrote: > > > I note the mtd thread in Feb started by samsung (starting from > > > > http://lists.infradead.org/pipermail/linux-mtd/2005-February/01186 > > 0.html). The mood seemed to be to split off OneNAND from generic > > nand as the access is so different. I was unclear whether this > > presents OneNAND as non generic NAND mtd technology possibly > > requiring changes to yaffs eg the test for the device being an > > "mtd-nand" at mount time. > > > > I'm not sure either. I have just skimmed the datasheet, but it might = be > > possible to setup a NAND compatible API You could even set up a NAND interface to NOR if you were really keen :-)= . For OneNAND, the sector management might break "NAND-ness".=20 > > It looks like there are only 2 bytes of user usable data in the "spare" > area. Although yaffs won't need to do so much ecc it looks like yaffs w= ill > have a problem with that little spare space unless one can use bigger > virtual blocks. Charles? It might be possbile to subvert some of the other bytes (eg. sector numbe= r). I'd be tempted to run this stuff as 2k pages with YAFFS2. That would give= =20 more bytes/chunk. Still might not be enough though. Samsung: If you're reading this, what would ne nice, IMHO, would be the=20 ability to bypass the OneNAND interface and use part of the device as a r= aw=20 NAND (perhaps with HWECC) for file system purposes and some as NOR equiva= lent=20 for use as boot sectors etc. Perhaps this is possible. -- Charles From manningc2@actrix.gen.nz Wed Jun 15 00:39:16 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Wed, 15 Jun 2005 11:39:16 +1200 Subject: [Yaffs] Anyone using yaffs in u-boot? In-Reply-To: References: Message-ID: <20050614233704.6CB79157C6@desire.actrix.co.nz> On Wednesday 15 June 2005 10:29, Rick Bronson wrote: > Hi, > > It looks like someone in Korea is using yaffs on uboot. If you > google: > > "nand read" yaffs uboot site:kr > > but the code doesn't seem to be available. Just wondered if anyone > here knows how to get yaffs support in uboot? > > Thanks very much for any help. > > Rick Bronson I'm notr sure what Uboot does, but it depends what you're trying to achie= ve,=20 reading or writing. If you're wanting to read an image during booting (ie. boot from YAFFS) t= hen=20 have a look at the bootloader in YAFFS direct. If you want to use Uboot to write an image into a YAFFS partition then lo= ok=20 at mkyaffs for inspiration. -- CHarles From coywolf@lovecn.org Wed Jun 15 04:07:45 2005 From: coywolf@lovecn.org (Coywolf Qi Hunt) Date: Wed, 15 Jun 2005 11:07:45 +0800 Subject: [Yaffs] yaffs filesystem check utility In-Reply-To: <0919CB1D9CD143409F2C7CC840B1DED6034285@slttex001.selta-tel.selta-spa.local> References: <0919CB1D9CD143409F2C7CC840B1DED6034285@slttex001.selta-tel.selta-spa.local> Message-ID: <2cd57c900506142007677ece75@mail.gmail.com> On 6/14/05, Villatora Virgilio wrote: > =20 > =20 >=20 > Dear all, > I have a problem regarding the yaffs fs checking utility. > =20 > My embedded machine runs under Linux (Debian distribution) > 2.4.19-rmk4(v2_11). > =20 > We use a NAND flash device (512k byte per page) divided in 4 partitions. > The first two (2MB each) contains a special FW and zImage of the kernel; > The third one contains a yaffs file system image. > =20 > The system works correctly for several days. > After this period the kernel begins to give strange messages and at the > reboot > the fourth partition cannot be mounted. > =20 > We think that it could depend from bad tracks management. > =20 > At system boot I can read an error message on the console: > "... > fsck v1.27 .... > fsck error: fsck.yaffs not found > error 2 while executing fsck > ... > " > and if you check under /sbin dir fsck.yaffs file does not exist...(?) > I have looked for the package under Debian web site with no success. > Can you help me in finding .deb package of this utility OR another > utility that makes the same check on the file my yaffs filesystem ? Debian never has that package. You could build it yourself. --=20 Coywolf Qi Hunt http://ahbl.org/~coywolf/ From rick@efn.org Wed Jun 15 18:09:49 2005 From: rick@efn.org (Rick Bronson) Date: Wed, 15 Jun 2005 10:09:49 -0700 Subject: [Yaffs] Anyone using yaffs in u-boot? In-Reply-To: <20050614233704.6CB79157C6@desire.actrix.co.nz> (message from Charles Manning on Wed, 15 Jun 2005 11:39:16 +1200) References: <20050614233704.6CB79157C6@desire.actrix.co.nz> Message-ID: Charles, Thanks much for the reply. > I'm notr sure what Uboot does, but it depends what you're trying to achieve, > reading or writing. > > If you're wanting to read an image during booting (ie. boot from YAFFS) then > have a look at the bootloader in YAFFS direct. Yes, this is what I want to do. Can the "YAFFS direct" take a pointer to the actual NAND device (ie. the 8 bit port) and extract a file from a partition into ram that was previously written via YAFFS on Linux? Unfortunately I'm stuck at a 2.4.19 kernel for now, is this a problem for the latest and greatest YAFFS? Thanks for all the help. Rick From manningc2@actrix.gen.nz Wed Jun 15 21:05:43 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Thu, 16 Jun 2005 08:05:43 +1200 Subject: [Yaffs] Anyone using yaffs in u-boot? In-Reply-To: References: <20050614233704.6CB79157C6@desire.actrix.co.nz> Message-ID: <20050615200330.71B8D15661@desire.actrix.co.nz> On Thursday 16 June 2005 05:09, Rick Bronson wrote: > Charles, > > Thanks much for the reply. > > > I'm notr sure what Uboot does, but it depends what you're trying to > > achieve, reading or writing. > > > > If you're wanting to read an image during booting (ie. boot from YAFF= S) > > then have a look at the bootloader in YAFFS direct. > > Yes, this is what I want to do. > > Can the "YAFFS direct" take a pointer to the actual NAND device > (ie. the 8 bit port) and extract a file from a partition into ram that > was previously written via YAFFS on Linux? The bootloader is really not part of Yaffs Direct, but just lurks in that= =20 directory. You still need to provide NAND read functions, but they don't have to be=20 Linux ones. yboot is LGPL to make it easier to integrate with various=20 bootloaders. I recommend too wandering over to the stuff Nick did to hook= =20 this up with the Balloon project. In essence, the bootloader (see direct/yboot.c) is a stripped version of= the=20 yaffs mount scanner, but instead of searching for, and building up, all t= he=20 files it just looks for the file you want. As it is at present it has som= e=20 limitations (eg. can only boot from an image in the root). > > Unfortunately I'm stuck at a 2.4.19 kernel for now, is this a > problem for the latest and greatest YAFFS? All such problems should be in mtd land. YAFFS is pretty version agnostic= . It=20 you have a working mtd then you should be good to go. -- Charles From ladis@linux-mips.org Thu Jun 16 17:06:06 2005 From: ladis@linux-mips.org (Ladislav Michl) Date: Thu, 16 Jun 2005 18:06:06 +0200 Subject: [Yaffs] YAFFS2 failure Message-ID: <20050616160606.GA24009@orphique> Hi, I tried to use current yaffs2 CVS code with linux-2.6.12-rc6 OMAP git kernel (http://www.muru.com/linux/omap/), plus some board specific patches. Flash is Samsung K9F1G08U0M, 128MB, 2k pages. Writing, reading and erasing files works, until I umount and mount filesystem. df still states correct filesystem usage, however only directory visible is lost+found. All files are gone. # df -h Filesystem Size Used Available Use% Mounted on /dev/mtdblock0 127.9M 57.0M 70.8M 45% /mnt Listing lost+found gives: # ls /mnt/lost\+found/ ls: /mnt/lost+found/obj17170432: Value too large for defined data type ls: /mnt/lost+found/obj17235968: Value too large for defined data type ls: /mnt/lost+found/obj17301504: Value too large for defined data type [etc...] Any hint where to start debugging appreciated, ladis From sergei.sharonov@halliburton.com Thu Jun 16 17:42:57 2005 From: sergei.sharonov@halliburton.com (Sergei Sharonov) Date: Thu, 16 Jun 2005 16:42:57 +0000 (UTC) Subject: [Yaffs] Re: YAFFS2 failure References: <20050616160606.GA24009@orphique> Message-ID: Hi, > Writing, reading and erasing files works, until I umount and mount > filesystem. df still states correct filesystem usage, however only > directory visible is lost+found. All files are gone. Same story here. AFAIK yaffs2 has problems with newer mtd oob autoplacement. See Nick's post. I see the same 16 bit shift in oob data. There was mtd fix (autoplace_user flag) and it was supposed to correct that but I could not seem to make it work either. Let me know if you manage to get it working.. Nick, did you manage to get it going with user autoplace? Sergei Sharonov From nick@cecomputing.co.uk Thu Jun 16 18:53:12 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Thu, 16 Jun 2005 18:53:12 +0100 Subject: [Yaffs] Re: YAFFS2 failure In-Reply-To: Message-ID: > Hi, >=20 > > Writing, reading and erasing files works, until I umount and mount > > filesystem. df still states correct filesystem usage, however only > > directory visible is lost+found. All files are gone. >=20 > Same story here. AFAIK yaffs2 has problems with newer mtd oob=20 > autoplacement.=20 > See Nick's post. I see the same 16 bit shift in oob data. There=20 > was mtd fix=20 > (autoplace_user flag) and it was supposed to correct that but I=20 > could not seem=20 > to make it work either. >=20 > Let me know if you manage to get it working.. >=20 > Nick, did you manage to get it going with user autoplace? >=20 Yes, all works fine for me. Nick > Sergei Sharonov >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > --=20 > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: = 15/06/2005 >=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: 15/06/2005 From ladis@linux-mips.org Thu Jun 16 19:51:13 2005 From: ladis@linux-mips.org (Ladislav Michl) Date: Thu, 16 Jun 2005 20:51:13 +0200 Subject: [Yaffs] Re: YAFFS2 failure In-Reply-To: References: Message-ID: <20050616185113.GA1536@orphique> On Thu, Jun 16, 2005 at 06:53:12PM +0100, Nick Bane wrote: > > Same story here. AFAIK yaffs2 has problems with newer mtd oob Has problems or have problems? > > autoplacement. See Nick's post. I see the same 16 bit shift in oob > > data. There was mtd fix (autoplace_user flag) and it was supposed to > > correct that but I could not seem to make it work either. I searches archives and have no clue which post are you talking about. > > Let me know if you manage to get it working.. > > > > Nick, did you manage to get it going with user autoplace? > > > Yes, all works fine for me. Umm, well. Are there any patches available? Regards, ladis From Martin.Fouts@palmsource.com Thu Jun 16 22:18:17 2005 From: Martin.Fouts@palmsource.com (Martin Fouts) Date: Thu, 16 Jun 2005 14:18:17 -0700 Subject: [Yaffs] Re: YAFFS2 failure Message-ID: Which OMAP board are you using? I'm working with OMAP 730 on the Perseus2 board an am currently debugging problems with the NAND. Marty=20 -----Original Message----- From: yaffs-admin@stoneboat.aleph1.co.uk [mailto:yaffs-admin@stoneboat.aleph1.co.uk] On Behalf Of Ladislav Michl Sent: Thursday, June 16, 2005 11:51 AM To: Nick Bane Cc: Sergei Sharonov; yaffs@stoneboat.aleph1.co.uk Subject: Re: [Yaffs] Re: YAFFS2 failure On Thu, Jun 16, 2005 at 06:53:12PM +0100, Nick Bane wrote: > > Same story here. AFAIK yaffs2 has problems with newer mtd oob Has problems or have problems? > > autoplacement. See Nick's post. I see the same 16 bit shift in oob=20 > > data. There was mtd fix (autoplace_user flag) and it was supposed to > > correct that but I could not seem to make it work either. I searches archives and have no clue which post are you talking about. > > Let me know if you manage to get it working.. > >=20 > > Nick, did you manage to get it going with user autoplace? > >=20 > Yes, all works fine for me. Umm, well. Are there any patches available? Regards, ladis _______________________________________________ yaffs mailing list yaffs@stoneboat.aleph1.co.uk http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs From manningc2@actrix.gen.nz Fri Jun 17 01:22:17 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Fri, 17 Jun 2005 12:22:17 +1200 Subject: [Yaffs] YAFFS2 failure In-Reply-To: <20050616160606.GA24009@orphique> References: <20050616160606.GA24009@orphique> Message-ID: <20050617002000.7508F1599C@desire.actrix.co.nz> Some points to mention... > Listing lost+found gives: > # ls /mnt/lost\+found/ > ls: /mnt/lost+found/obj17170432: Value too large for defined data type > ls: /mnt/lost+found/obj17235968: Value too large for defined data type > ls: /mnt/lost+found/obj17301504: Value too large for defined data type > [etc...] > Stuff turns up in lost+found when the directory structure can't handle it= . Stuff in lost+found shows up in two ways: 1) If the name looks sane (eg. .../lost+found/myfile.txt) then it means t= hat=20 YAFFS scanning could find the directory that myfile belongs to and it got= =20 dumped there instead. Well actually it will be dumped in=20 .../lost+found/objxxx/myfile.txt). 2) If the file name is something like objnnnn then it means that YAFFS fo= und=20 some data chunks, but could not find a file name to associate with them. We're observing 2 above. It is also worth noting that the nnn in obj nnn is made up by YAFFS at ls= =20 time from the objectId of the chunk. Thus, obj17170432 tells us that a ch= unk=20 turned up marked with objectId 1717042. Now objectIds are created=20 sequentiually starting at 4096, and I don't believe that 1717000-odd file= s=20 have been created on this system, which says to me that the objectId in t= he=20 tags got corrupted. All this is very consistent with the mtd problems discussed by others her= e. I=20 believe this has been fixed in mtd CVS. As a side issue: I have finally got around to purchasing a new coimputer = to=20 be loaded with Linux 2.6. It has 1GB of RAM which means I should be able = to=20 do proper mtd emulations of up to, say, 512MB of NAND. I hope this will b= e=20 able to help me do a better job of improving mtd and 2.6 integration. -- Charles From ladis@linux-mips.org Fri Jun 17 11:15:25 2005 From: ladis@linux-mips.org (Ladislav Michl) Date: Fri, 17 Jun 2005 12:15:25 +0200 Subject: [Yaffs] YAFFS2 failure In-Reply-To: <20050617002000.7508F1599C@desire.actrix.co.nz> References: <20050616160606.GA24009@orphique> <20050617002000.7508F1599C@desire.actrix.co.nz> Message-ID: <20050617101525.GA25510@orphique> On Fri, Jun 17, 2005 at 12:22:17PM +1200, Charles Manning wrote: > All this is very consistent with the mtd problems discussed by others here. I > believe this has been fixed in mtd CVS. Yes, Thomas kindly bounced me mail with patch. However I do not see where is MTD_NANDECC_AUTOPL_USR set in YAFFS2 code... Regards, ladis From nick@cecomputing.co.uk Fri Jun 17 11:11:21 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Fri, 17 Jun 2005 11:11:21 +0100 Subject: [Yaffs] Re: YAFFS2 failure In-Reply-To: <487B538D08487B4D8FEC138A13D4F6ACB4256C@HOUEXCH077.corp.halliburton.com> Message-ID: >=20 > if it is not too much trouble, could you post/email a patch? I am > probably=20 > doing something wrong. > Thanks, Actually I am lying terribly about yaffs2 working in a new mtd kernel. The linux kernel that I am testing yaffs2 in is 2.4.25-vrs2 which uses = the older mtd where all is well. See http://husaberg.toby-churchill.com/cgi-bin/viewcvs.cgi/linux-2.4.25/ = for details. It is in bootldr that I am using the new mtd suitably changed for = embedded usage. What I needed to do was override the default autoob policy in the nand = chip structure. This meant that it defaulted to my autoplacement policy = and not the mtd default for all reads of data+oob together. Look in = husaberg.toby-churchill.co.uk/balloon/development/bootldr35/nand/nandif.c= in the setup_nand function where nand->autoob is set to yaffs2_oob. = That should fix it for you though it means that all partitions (yaffs2 = or not) will be forced to use that policy. The use of MTD_NANECC_AULTOPL_USR is almost tested but not quite ready = for showtime. Look in yaffs/yaffs_mtdif2.c for the way to test it by changing the = comments. I have been just too busy to do it myself in the kernel as it needs a = fair bit of work to port 2.6 to balloon though that is scheduled when = balloon3 hardware becomes available (July/Sept?). Nick >=20 > Sergei --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: 15/06/2005 From ladis@linux-mips.org Fri Jun 17 11:19:05 2005 From: ladis@linux-mips.org (Ladislav Michl) Date: Fri, 17 Jun 2005 12:19:05 +0200 Subject: [Yaffs] Re: YAFFS2 failure In-Reply-To: References: Message-ID: <20050617101905.GB25510@orphique> On Thu, Jun 16, 2005 at 02:18:17PM -0700, Martin Fouts wrote: > Which OMAP board are you using? > > I'm working with OMAP 730 on the Perseus2 board an am currently > debugging problems with the NAND. It is custom OMAP5910 based board (NetStar). Some basic support is already in OMAP tree, I'll send the rest after more testing. I have no problems with NAND itself, only with yaffs2 on top of it. ladis From ladis@linux-mips.org Fri Jun 17 12:02:31 2005 From: ladis@linux-mips.org (Ladislav Michl) Date: Fri, 17 Jun 2005 13:02:31 +0200 Subject: [Yaffs] Re: YAFFS2 failure In-Reply-To: References: <487B538D08487B4D8FEC138A13D4F6ACB4256C@HOUEXCH077.corp.halliburton.com> Message-ID: <20050617110231.GA26883@orphique> On Fri, Jun 17, 2005 at 11:11:21AM +0100, Nick Bane wrote: > It is in bootldr that I am using the new mtd suitably changed for > embedded usage. What I needed to do was override the default autoob > policy in the nand chip structure. This meant that it defaulted to my > autoplacement policy and not the mtd default for all reads of data+oob > together. Nice, I'm just working on integrating new NAND MTD into U-Boot (based on patch by Pantelis Antoniou), so perhaps we could join our effort. > Look in > husaberg.toby-churchill.co.uk/balloon/development/bootldr35/nand/nandif.c > in the setup_nand function where nand->autoob is set to yaffs2_oob. > That should fix it for you though it means that all partitions (yaffs2 > or not) will be forced to use that policy. Unfortunately I cannot access toby-churchill.co.uk site. $ traceroute husaberg.toby-churchill.co.uk traceroute: unknown host husaberg.toby-churchill.co.uk It was working yesterday for short while, but now it's unaccessible again. > The use of MTD_NANECC_AULTOPL_USR is almost tested but not quite ready > for showtime. Look in yaffs/yaffs_mtdif2.c for the way to test it by > changing the comments. I have been just too busy to do it myself in > the kernel as it needs a fair bit of work to port 2.6 to balloon > though that is scheduled when balloon3 hardware becomes available > (July/Sept?). Are you talking about yaffs/yaffs_mtdif2.c source file from yaffs2 CVS module as found in :pserver:anonymous@cvs.aleph1.co.uk:/home/aleph1/cvs ? If so I must be doing something wrong, because I do see any comment looking close your description. ladis From nick@cecomputing.co.uk Fri Jun 17 12:15:33 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Fri, 17 Jun 2005 12:15:33 +0100 Subject: [Yaffs] Re: YAFFS2 failure In-Reply-To: <20050617110231.GA26883@orphique> Message-ID: uboot collaboration might be useful. > = husaberg.toby-churchill.co.uk/balloon/development/bootldr35/nand/nandif.c= > > in the setup_nand function where nand->autoob is set to yaffs2_oob. > > That should fix it for you though it means that all partitions = (yaffs2 > > or not) will be forced to use that policy. >=20 > Unfortunately I cannot access toby-churchill.co.uk site. sorry, my bad. husaberg.toby-churchill.com >=20 > Are you talking about yaffs/yaffs_mtdif2.c source file from yaffs2 CVS > module as found in = :pserver:anonymous@cvs.aleph1.co.uk:/home/aleph1/cvs ? > If so I must be doing something wrong, because I do see any comment > looking close your description. No its my addition. Nick >=20 > ladis > --=20 > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: = 15/06/2005 >=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: 15/06/2005 From Ramesh Chaurasiya Fri Jun 17 13:50:05 2005 From: Ramesh Chaurasiya (Ramesh Chaurasiya) Date: Fri, 17 Jun 2005 18:20:05 +0530 Subject: [Yaffs] YAFFS on kernel 2.4 In-Reply-To: References: <5585a0780506130813f743ded@mail.gmail.com> Message-ID: <5585a07805061705504b002e97@mail.gmail.com> Hi, Source for kernel 2.4.19 is also there at husaberg.toby-churchill.com, I am working on PXA 255 board with kernel 2.4.19 as no patches are available for kernel 2.4.25 for XScale. I got the NAND flash worked on 2.6 kernel (tried jffs2) but for some reasons, I have to stick with the 2.4 kernel. I used 2.4.19 from the above site, I got YAFFS mounted successfully=20 command "df" shows entire partition is empty but if I copy any data on to the NAND partition it takes too much time and finally gives error message "cp: cannot create regular file `abc': Cannot allocate memory" Now "df" shows that there is no space on the device Can any one help me out to fix it up. The source that I got doing wget from husaberg.toby-churchill.com, has few files missing and is not getting compiled therefore from that source I used ... 1. fs/yaffs 2. mtd/mtdpart.c 3. drivers/mtd/nand and 4. required header files only (can this be the reason for?) Is anywhere tar compressed archive available for same source? Thanks, Ramesh On 6/13/05, Nick Bane wrote: > Look at husaberg.toby-churchill.com/balloon/ and wget the 2.4.25-vrs2-tcl= 1 tree. >=20 > Nick Bane >=20 > > -----Original Message----- > > From: yaffs-admin@stoneboat.aleph1.co.uk > > [mailto:yaffs-admin@stoneboat.aleph1.co.uk]On Behalf Of Ramesh > > Chaurasiya > > Sent: 13 June 2005 16:13 > > To: yaffs@stoneboat.aleph1.co.uk > > Subject: [Yaffs] YAFFS on kernel 2.4 > > > > > > Hi, > > I am trying to get NAND flash work on kernel 2.4 > > can anyone please tell me from where can I get yaffs source > > appropriate for kernel 2.4 > > > > The source available today at http://www.aleph1.co.uk/cgi-bin/viewcvs.c= gi/ > > seems to be meant for kernel 2.6 > > > > -- > > Thanks, > > Ramesh > > > > _______________________________________________ > > yaffs mailing list > > yaffs@stoneboat.aleph1.co.uk > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > -- > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: 11/06/2005 > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: 11/06/2005 >=20 > From nick@cecomputing.co.uk Fri Jun 17 15:17:03 2005 From: nick@cecomputing.co.uk (Nick Bane) Date: Fri, 17 Jun 2005 15:17:03 +0100 Subject: [Yaffs] YAFFS on kernel 2.4 In-Reply-To: <5585a07805061705504b002e97@mail.gmail.com> Message-ID: > Hi, > Source for kernel 2.4.19 is also there at husaberg.toby-churchill.com, > I am working on PXA 255 board with kernel 2.4.19 as no patches are > available for kernel 2.4.25 for XScale. > I got the NAND flash worked on 2.6 kernel (tried jffs2) but for some > reasons, I have to stick with the 2.4 kernel. >=20 I haven't maitained 2.4.29 for a long while now. I consider ot obsolete. = However, I believe it to have worked fine with the mtd/yaffs at that = time. > I used 2.4.19 from the above site, I got YAFFS mounted successfully=20 > command "df" shows entire partition is empty but if I copy any data on > to the NAND partition it takes too much time and finally gives error > message > "cp: cannot create regular file `abc': Cannot allocate memory" > Now "df" shows that there is no space on the device > Can any one help me out to fix it up. >=20 Hmm. I remember that one. I am pretty sure it was fixed in later = versions of the kernel+yaffs. > The source that I got doing wget from husaberg.toby-churchill.com, has > few files missing and is not getting compiled therefore from that > source I used ... > 1. fs/yaffs > 2. mtd/mtdpart.c > 3. drivers/mtd/nand and > 4. required header files only (can this be the reason for?) > Is anywhere tar compressed archive available for same source? >=20 I suggest trying a wget of the 2.4.25 series. The latest can be = downloaded via viewcvs and/or subversion. Nick > Thanks, > Ramesh >=20 > On 6/13/05, Nick Bane wrote: > > Look at husaberg.toby-churchill.com/balloon/ and wget the=20 > 2.4.25-vrs2-tcl1 tree. > >=20 > > Nick Bane > >=20 > > > -----Original Message----- > > > From: yaffs-admin@stoneboat.aleph1.co.uk > > > [mailto:yaffs-admin@stoneboat.aleph1.co.uk]On Behalf Of Ramesh > > > Chaurasiya > > > Sent: 13 June 2005 16:13 > > > To: yaffs@stoneboat.aleph1.co.uk > > > Subject: [Yaffs] YAFFS on kernel 2.4 > > > > > > > > > Hi, > > > I am trying to get NAND flash work on kernel 2.4 > > > can anyone please tell me from where can I get yaffs source > > > appropriate for kernel 2.4 > > > > > > The source available today at=20 > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/ > > > seems to be meant for kernel 2.6 > > > > > > -- > > > Thanks, > > > Ramesh > > > > > > _______________________________________________ > > > yaffs mailing list > > > yaffs@stoneboat.aleph1.co.uk > > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Anti-Virus. > > > Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: = 11/06/2005 > > > > > -- > > No virus found in this outgoing message. > > Checked by AVG Anti-Virus. > > Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: = 11/06/2005 > >=20 > > > --=20 > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: = 15/06/2005 >=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: 15/06/2005 From mail@lehmann-frank.net Sat Jun 18 15:54:00 2005 From: mail@lehmann-frank.net (Frank Lehmann) Date: Sat, 18 Jun 2005 16:54:00 +0200 Subject: [Yaffs] Problem with file attributes Message-ID: <20050618145401.50DC2608074@mail.gellar.net> Hello Everyone, just now I changed from 'jffs2' to 'yaffs'. Up to now no problems occurred during compiling and setting up my embedded system with 'yaffs' NAND flash partitions in combination with kernel 2.4.25. The MTD driver is working fine. Installing and mounting 'yaffs' partitions performed very well. No errors when reading from or writing to 'yaffs' partitions. As far as good! Unfortunately at the end of the day one problem came up. All files or directories I create as user (not 'root') are assigned to 'root'. For example if I am user 'abc' and I create a file or if I transfer a file via FTP to the 'yaffs' partition to any directory which doesn't belong to group or user 'root', I always get assigned user and group 'root' to that file. After that I can change permissions, user and group. Even if I use the setgid and setuid flags (6755) of a directory which belongs to user 'abc' and group 'xyz' and where I create or transfer a file, the result is always the same. The new file belongs to 'root'. It seems that after remounting everything is fine. My expectation was that 'yaffs' handles the file/directory attributes in same way like other file systems. Maybe I am wrong? Any idea what's going wrong? Hints in this regard are appreciated. Thanks, Frank From NGFrankW@gmx.net Sat Jun 18 19:32:41 2005 From: NGFrankW@gmx.net (Frank) Date: Sat, 18 Jun 2005 20:32:41 +0200 Subject: [Yaffs] Windows CE .NET 4.2- YAFFS2 adaption ? Message-ID: <098c01c57434$1ca0aa60$6502a8c0@darkstar2> Has anyone tried to adapt YAFFS2 to Windows CE .NET 4.2 ? I'm wondering if this works with 1GByte (4x256k, 2048bytes/page, 8Bit) and which performance I will get in comparison with the Microsoft FMD/FAL/FAT combination. From manningc2@actrix.gen.nz Tue Jun 21 04:16:33 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Tue, 21 Jun 2005 15:16:33 +1200 Subject: [Yaffs] Problem with file attributes In-Reply-To: <20050618145401.50DC2608074@mail.gellar.net> References: <20050618145401.50DC2608074@mail.gellar.net> Message-ID: <20050621031406.D65E615632@desire.actrix.co.nz> On Sunday 19 June 2005 02:54, Frank Lehmann wrote: > Hello Everyone, > > just now I changed from 'jffs2' to 'yaffs'. Up to now no problems occur= red > during compiling and setting up my embedded system with 'yaffs' NAND fl= ash > partitions in combination with kernel 2.4.25. The MTD driver is working > fine. Installing and mounting 'yaffs' partitions performed very well. > No errors when reading from or writing to 'yaffs' partitions. As far as > good! > > Unfortunately at the end of the day one problem came up. All files or > directories I create as user (not 'root') are assigned to 'root'. > For example if I am user 'abc' and I create a file or if I transfer a f= ile > via FTP to the 'yaffs' partition to any directory which doesn't belong = to > group or user 'root', I always get assigned user and group 'root' to th= at > file. After that I can change permissions, user and group. > > Even if I use the setgid and setuid flags (6755) of a directory which > belongs to user 'abc' and group 'xyz' and where I create or transfer a > file, the result is always the same. The new file belongs to 'root'. > > It seems that after remounting everything is fine. > > My expectation was that 'yaffs' handles the file/directory attributes i= n > same way like other file systems. Maybe I am wrong? The intention is to have YAFFS doing attribute handling just the same as = any=20 other fs. Any wierdo behaviour like you report here is a bug. YAFFS does jump through a few hoops because it does not use inodes and=20 dentries internally, but that is supposed to be sorted out by the YAFFS f= s=20 layer. Can anyone confirm these problems on the same or other Linux versions? -- CHarles From Peter.B@LogicPD.com Tue Jun 21 20:25:41 2005 From: Peter.B@LogicPD.com (Peter Barada) Date: Tue, 21 Jun 2005 15:25:41 -0400 Subject: [Yaffs] Why does YAFFS skip the first block? Message-ID: <1119381941.5580.205.camel@thunk> I have a NOR implementation of YAFFS, and I've been pounding my head with mkyaffsimage.c trying to get an image that can be built on a linux box and used on a ColdFire mcf5475 based embedded Linux board using kernel 2.4.26. To do this, I've set up the MTD access such that the spare abuts its corresponding data chunk which all seems to work(this is that I make sure that a data chunk and spare are in the same block). What I stumbled across is that YAFFS refuses to use the first flash block(which in my case is 64K in size) by setting dev->startBlock = 1 in yaffs_internal_read_super. This causes it to behave bizarrely when I first burned the image created by mkyaffsimage into the flash starting at block zero. If I change dev->startBlock to zero, then yaffs_GutsInitialize() fails due to checks for a non-zero startBlock. If I change those checks to allow a zero startBlock, things look like they work fine, including the image that mkyaffsimage created(after I modified write_chunk to place the data and spares in the appropriate offsets). Am I setting myself up for a bunch of problems by changing the startBlock to zero? -- Peter Barada From manningc2@actrix.gen.nz Tue Jun 21 23:47:37 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Wed, 22 Jun 2005 10:47:37 +1200 Subject: [Yaffs] Why does YAFFS skip the first block? In-Reply-To: <1119381941.5580.205.camel@thunk> References: <1119381941.5580.205.camel@thunk> Message-ID: <20050621224514.33402417A@blood.actrix.co.nz> On Wednesday 22 June 2005 07:25, Peter Barada wrote: > I have a NOR implementation of YAFFS, and I've been pounding my head > with mkyaffsimage.c trying to get an image that can be built on a linux > box and used on a ColdFire mcf5475 based embedded Linux board using > kernel 2.4.26. > > To do this, I've set up the MTD access such that the spare abuts its > corresponding data chunk which all seems to work(this is that I make > sure that a data chunk and spare are in the same block). What I > stumbled across is that YAFFS refuses to use the first flash block(whic= h > in my case is 64K in size) by setting dev->startBlock =3D 1 in > yaffs_internal_read_super. This causes it to behave bizarrely when I > first burned the image created by mkyaffsimage into the flash starting > at block zero. > > If I change dev->startBlock to zero, then yaffs_GutsInitialize() fails > due to checks for a non-zero startBlock. If I change those checks to > allow a zero startBlock, things look like they work fine, including the > image that mkyaffsimage created(after I modified write_chunk to place > the data and spares in the appropriate offsets). > > Am I setting myself up for a bunch of problems by changing the > startBlock to zero? Not using chunk zero is a historical accident, of sorts. On NAND, chunk z= ero=20 is guaranteed good while others might not. On many systems, the first n=20 chunks hold boot image etc. Sometimes chunk zero is used to store bad bl= ock=20 tables etc. I needed a value for "invalid chunk" and "invalid block" and, because of = the=20 above, and because zero is easy to use, I chose zero. In hindsight, it m= ight=20 have been better to use -1/0xffffffffff. Most NAND folk don't hurt to much if a single block has to be lost (since= =20 NAND typically has many blocks), but it can be nasty for NOR folk with f= ew=20 blocks. All is not lost though, there is a way to use that block zero, and it is= =20 pretty straight forward. You just need to tell YAFFS some lies! All yaffs flash calls go through a few access functions.=20 All you need to do is to do a mapping in these functions so that yaffs bl= ock=20 1 =3D physical block 0. eg. int (*writeChunkToNAND)(struct yaffs_DeviceStruct *dev,int chunkInNAND, c= onst=20 __u8 *data, yaffs_Spare *spare) { chunkInNAND -=3D dev->nChunksPerBlock;=20 ..... // rest of stuff } int (*eraseBlockInNAND)(struct yaffs_DeviceStruct *dev,int blockInNAND) { blockInNAND--; ...// rest of stuff } Now you must need to keep the illusion going by setting up the device sta= rt=20 and end blocks accordingly. If you have, say, 32 physical blocks numbered= =20 from 0 to 31, then just set up startBlock=3D1 and endBlock =3D32; There is no chunk or block info imprinted in the actual YAFFS data, so no= =20 changes are needed to mkyaffsimage etc to make this work. -- Charles =20 From Peter.B@LogicPD.com Wed Jun 22 01:13:03 2005 From: Peter.B@LogicPD.com (Peter Barada) Date: Tue, 21 Jun 2005 20:13:03 -0400 Subject: [Yaffs] Why does YAFFS skip the first block? In-Reply-To: <20050621224514.33402417A@blood.actrix.co.nz> References: <1119381941.5580.205.camel@thunk> <20050621224514.33402417A@blood.actrix.co.nz> Message-ID: <1119399183.5580.212.camel@thunk> On Wed, 2005-06-22 at 10:47 +1200, Charles Manning wrote: > On Wednesday 22 June 2005 07:25, Peter Barada wrote: > > I have a NOR implementation of YAFFS, and I've been pounding my head > > with mkyaffsimage.c trying to get an image that can be built on a linux > > box and used on a ColdFire mcf5475 based embedded Linux board using > > kernel 2.4.26. > > > > To do this, I've set up the MTD access such that the spare abuts its > > corresponding data chunk which all seems to work(this is that I make > > sure that a data chunk and spare are in the same block). What I > > stumbled across is that YAFFS refuses to use the first flash block(which > > in my case is 64K in size) by setting dev->startBlock = 1 in > > yaffs_internal_read_super. This causes it to behave bizarrely when I > > first burned the image created by mkyaffsimage into the flash starting > > at block zero. > > > > If I change dev->startBlock to zero, then yaffs_GutsInitialize() fails > > due to checks for a non-zero startBlock. If I change those checks to > > allow a zero startBlock, things look like they work fine, including the > > image that mkyaffsimage created(after I modified write_chunk to place > > the data and spares in the appropriate offsets). > > > > Am I setting myself up for a bunch of problems by changing the > > startBlock to zero? > > Not using chunk zero is a historical accident, of sorts. On NAND, chunk zero > is guaranteed good while others might not. On many systems, the first n > chunks hold boot image etc. Sometimes chunk zero is used to store bad block > tables etc. > > I needed a value for "invalid chunk" and "invalid block" and, because of the > above, and because zero is easy to use, I chose zero. In hindsight, it might > have been better to use -1/0xffffffffff. > > Most NAND folk don't hurt to much if a single block has to be lost (since > NAND typically has many blocks), but it can be nasty for NOR folk with few > blocks. Yeah, that's my problem. It wastes a serious percentage of space... > All is not lost though, there is a way to use that block zero, and it is > pretty straight forward. You just need to tell YAFFS some lies! > > All yaffs flash calls go through a few access functions. > All you need to do is to do a mapping in these functions so that yaffs block > 1 = physical block 0. > > eg. > int (*writeChunkToNAND)(struct yaffs_DeviceStruct *dev,int chunkInNAND, const > __u8 *data, yaffs_Spare *spare) > { > chunkInNAND -= dev->nChunksPerBlock; > > ..... // rest of stuff > } > > int (*eraseBlockInNAND)(struct yaffs_DeviceStruct *dev,int blockInNAND) > { > blockInNAND--; > ...// rest of stuff > } > > Now you must need to keep the illusion going by setting up the device start > and end blocks accordingly. If you have, say, 32 physical blocks numbered > from 0 to 31, then just set up startBlock=1 and endBlock =32; > > There is no chunk or block info imprinted in the actual YAFFS data, so no > changes are needed to mkyaffsimage etc to make this work. Ugh, that sounds like a *total* hack. Is there anything wrong with allowing dev->startBlock to be zero instead of 1? I *could* do the remap in the access functions, but it *assumes some magical offset that requires a comment of: /* This is a total hack since YAFFS refuses to use block zero */ Is there anything *actually* wrong with using block zero? If what you say is true for NAND, then you don't even bother using the one guaranteed good block in the device... > -- Charles > > > > -- Peter Barada From manningc2@actrix.gen.nz Wed Jun 22 02:06:51 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Wed, 22 Jun 2005 13:06:51 +1200 Subject: [Yaffs] Why does YAFFS skip the first block? In-Reply-To: <1119399183.5580.212.camel@thunk> References: <1119381941.5580.205.camel@thunk> <20050621224514.33402417A@blood.actrix.co.nz> <1119399183.5580.212.camel@thunk> Message-ID: <20050622010421.43C9A15576@desire.actrix.co.nz> On Wednesday 22 June 2005 12:13, Peter Barada wrote: > > All is not lost though, there is a way to use that block zero, and i= t is > > pretty straight forward. You just need to tell YAFFS some lies! > > > > All yaffs flash calls go through a few access functions. > > All you need to do is to do a mapping in these functions so that yaff= s > > block 1 =3D physical block 0. > > > > eg. > > int (*writeChunkToNAND)(struct yaffs_DeviceStruct *dev,int chunkInNAN= D, > > const __u8 *data, yaffs_Spare *spare) > > { > > chunkInNAND -=3D dev->nChunksPerBlock; > > > > ..... // rest of stuff > > } > > > > int (*eraseBlockInNAND)(struct yaffs_DeviceStruct *dev,int blockInNAN= D) > > { > > blockInNAND--; > > ...// rest of stuff > > } > > > > Now you must need to keep the illusion going by setting up the device > > start and end blocks accordingly. If you have, say, 32 physical block= s > > numbered from 0 to 31, then just set up startBlock=3D1 and endBlock =3D= 32; > > > > There is no chunk or block info imprinted in the actual YAFFS data, s= o no > > changes are needed to mkyaffsimage etc to make this work. > > Ugh, that sounds like a *total* hack. =20 So what? It is very simple, works fine, is efficient and does not disrupt= =20 stable code. As it is, you're already pulling nastier hacks to emulate spare regions e= tc=20 to make NOR look like NAND. >Is there anything wrong with > allowing dev->startBlock to be zero instead of 1? This would not work for various things.=20 For example when YAFFS goes to look for the chunkId of the chunk in chunk= =20 zero, the search code would report "it is in chunk zero" which the rest = of=20 yaffs interprets as "it does not exist". So anything you write to chunk z= ero=20 is written into a black hole. > > I *could* do the remap in the access functions, but it *assumes some > magical offset that requires a comment of: > > /* This is a total hack since YAFFS refuses to use block zero */ Hack, maybe. Total hack, I think, is stating it a bit strongly. Any offset is fine so long as there is no logical (ie from YAFFS's point = of=20 view) chunk zero any more. Just using a one block offset is the simplest=20 case. Counting from one instead of zero is hardly going to make most=20 programmers spill their cup of tea. You can just use fixed constants in your mapping: Offset by one block. Si= nce=20 dev->nChunksPerBlock holds the number of chunks per block that is all you= =20 need to offset by for the reading/writing of a block. This means, all up, you need to add three lines of code:=20 blockId--; // add to the erase function chunkId -=3D dev->nChunksPerBlock; // add to read/write functions And change two lines where you set the start and end blocks. Changing five lines of code is hardly a large effort. Much less than, say= ,=20 writing an email. > > Is there anything *actually* wrong with using block zero? If what you > say is true for NAND, then you don't even bother using the one > guaranteed good block in the device... There is nothing technically wrong with using block zero from a memory/NA= ND=20 perspective. At the end of the day, file system integrity is governed by= the=20 performance of the worst block and not the best block. Block zero is only= =20 guaranteed good at the time of shipping and can go bad with time. Also,=20 many/most systems use block zero for some other purpose (eg. boot data or= bad=20 block marker). Thus, relying on chunk zero being good is pointless.=20 Yaffs needs some chunk/block Id for "does not exist". As I mentioned befo= re,=20 this could have been 0xFFFFFFFF/-1, but there are places (eg. Tnodes) whe= re=20 YAFFS uses 16 bit values. Using 0xFFFFFFFF as an invalid marker gets to b= e a=20 headache when using 16 and 32 bits because we'd have to look at special=20 cases. Zero is way easier. Now this mapping stuff could be done in YAFFS so that YAFFS would be able= to=20 start at block zero, but this has not yet risen to the top of the importa= nt=20 things to do pile, mainly because the workaround is trivial (which implie= s,=20 of course that fixing it in YAFFS is trivial too :-)). -- CHarles From coywolf@lovecn.org Wed Jun 22 04:09:57 2005 From: coywolf@lovecn.org (Coywolf Qi Hunt) Date: Wed, 22 Jun 2005 11:09:57 +0800 Subject: [Yaffs] Why does YAFFS skip the first block? In-Reply-To: <20050622010421.43C9A15576@desire.actrix.co.nz> References: <1119381941.5580.205.camel@thunk> <20050621224514.33402417A@blood.actrix.co.nz> <1119399183.5580.212.camel@thunk> <20050622010421.43C9A15576@desire.actrix.co.nz> Message-ID: <2cd57c90050621200958aa338@mail.gmail.com> On 6/22/05, Charles Manning wrote: > There is nothing technically wrong with using block zero from a memory/NA= ND > perspective. At the end of the day, file system integrity is governed by= the > performance of the worst block and not the best block. Block zero is only > guaranteed good at the time of shipping and can go bad with time. Also, > many/most systems use block zero for some other purpose (eg. boot data or= bad > block marker). Thus, relying on chunk zero being good is pointless. Is it that the code in the block 0 can be executed in place for booting? We may consider supporting partitions. As to bad block marker issue, using a fixed block for that purpose is against wear leveling and not reliable. Bad block information always can be gathered through oob area. --=20 Coywolf Qi Hunt http://ahbl.org/~coywolf/ From manningc2@actrix.gen.nz Wed Jun 22 04:33:06 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Wed, 22 Jun 2005 15:33:06 +1200 Subject: [Yaffs] Why does YAFFS skip the first block? In-Reply-To: <2cd57c90050621200958aa338@mail.gmail.com> References: <1119381941.5580.205.camel@thunk> <20050622010421.43C9A15576@desire.actrix.co.nz> <2cd57c90050621200958aa338@mail.gmail.com> Message-ID: <20050622033036.2D1B249F6@blood.actrix.co.nz> On Wednesday 22 June 2005 15:09, Coywolf Qi Hunt wrote: > On 6/22/05, Charles Manning wrote: > > > > There is nothing technically wrong with using block zero from a > > memory/NAND perspective. At the end of the day, file system integrit= y is > > governed by the performance of the worst block and not the best block= . > > Block zero is only guaranteed good at the time of shipping and can go= bad > > with time. Also, many/most systems use block zero for some other pur= pose > > (eg. boot data or bad block marker). Thus, relying on chunk zero bein= g > > good is pointless. > > Is it that the code in the block 0 can be executed in place for > booting? We may consider supporting partitions. Some device (eg. Samsung) support loading from block zero. > > As to bad block marker issue, using a fixed block for that purpose is > against wear leveling and not reliable. Bad block information always > can be gathered through oob area. This is not always true. Some devices have fixed bytes in the OOB area f= or=20 marking the bad blocks. This is what YAFFS1 expects. Some devices, particularly some of the newer 2k page devices, have differ= ent=20 bad block marking strategies. In some of these, any non-FF blocks should = be=20 considered bad. For these you need to build some sort of bad block table = and=20 keep that somewhere. Some people choose to use block zero for this purpo= se,=20 because it is guaranteed good and therefore an easy place to store the ta= ble. In general, it would be better for YAFFS to allow block zero to be usable= by=20 YAFFS. At the time the YAFFS code was written, I made the decision not t= o=20 use block zero and these points were merely what I considered as part of = the=20 rationale behind skipping block zero. To work around this is not very=20 difficult outside of YAFFS. I will likely, at some time, integrate the=20 workaround into YAFFS so that this all happens transparently inside YAFFS= and=20 thus make everybody happy. -- CHarles From Peter.B@LogicPD.com Wed Jun 22 05:09:51 2005 From: Peter.B@LogicPD.com (Peter Barada) Date: Wed, 22 Jun 2005 00:09:51 -0400 Subject: [Yaffs] Why does YAFFS skip the first block? In-Reply-To: <20050622010421.43C9A15576@desire.actrix.co.nz> References: <1119381941.5580.205.camel@thunk> <20050621224514.33402417A@blood.actrix.co.nz> <1119399183.5580.212.camel@thunk> <20050622010421.43C9A15576@desire.actrix.co.nz> Message-ID: <1119413391.5580.253.camel@thunk> On Wed, 2005-06-22 at 13:06 +1200, Charles Manning wrote: > On Wednesday 22 June 2005 12:13, Peter Barada wrote: > > > > All is not lost though, there is a way to use that block zero, and it is > > > pretty straight forward. You just need to tell YAFFS some lies! > > > > > > All yaffs flash calls go through a few access functions. > > > All you need to do is to do a mapping in these functions so that yaffs > > > block 1 = physical block 0. > > > > > > eg. > > > int (*writeChunkToNAND)(struct yaffs_DeviceStruct *dev,int chunkInNAND, > > > const __u8 *data, yaffs_Spare *spare) > > > { > > > chunkInNAND -= dev->nChunksPerBlock; > > > > > > ..... // rest of stuff > > > } > > > > > > int (*eraseBlockInNAND)(struct yaffs_DeviceStruct *dev,int blockInNAND) > > > { > > > blockInNAND--; > > > ...// rest of stuff > > > } > > > > > > Now you must need to keep the illusion going by setting up the device > > > start and end blocks accordingly. If you have, say, 32 physical blocks > > > numbered from 0 to 31, then just set up startBlock=1 and endBlock =32; > > > > > > There is no chunk or block info imprinted in the actual YAFFS data, so no > > > changes are needed to mkyaffsimage etc to make this work. > > > > Ugh, that sounds like a *total* hack. > > So what? It is very simple, works fine, is efficient and does not disrupt > stable code. Yes it is a *simple* hack, but it builds on other "lies"(your words) in the definition of YAFFS, i.e. that it *never* uses any data below the first 'block' of flash. For NAND devices where block sizes are small compared to the number of blocks, then this is no problem. In the case where there are 4 8-bit flash parts, each with a 64k block size on a 32- bit bus, you're talking about a 256K block size in 16M of memory which is pretty darn large. > As it is, you're already pulling nastier hacks to emulate spare regions etc > to make NOR look like NAND. That is because I want to use YAFFS on a NOR device because my hardware has NOR devices. Of course I have to pull a hack. At least its a *very* clean hack and hides itself from any layers above it. > >Is there anything wrong with > > allowing dev->startBlock to be zero instead of 1? > > This would not work for various things. > For example when YAFFS goes to look for the chunkId of the chunk in chunk > zero, the search code would report "it is in chunk zero" which the rest of > yaffs interprets as "it does not exist". So anything you write to chunk zero > is written into a black hole. Can you give me a pointer to function/line where this test is? Perhaps fixing YAFFS to handle block zero is better than forcing a 'hack' at a lower layer. > > > > I *could* do the remap in the access functions, but it *assumes some > > magical offset that requires a comment of: > > > > /* This is a total hack since YAFFS refuses to use block zero */ > > Hack, maybe. Total hack, I think, is stating it a bit strongly. Yes, "total" hack was a bit strong, but after using mkyaffsimage to create a image that I put into flash, and finding that I couldn't find some partial bits of it(and a bunch of objects end up in lost+found that can't even be opened), I may have expressed my frustration a bit strong. You can see where that comes from when 85% of the flash image is visible and usable... > Any offset is fine so long as there is no logical (ie from YAFFS's point of > view) chunk zero any more. Just using a one block offset is the simplest > case. Counting from one instead of zero is hardly going to make most > programmers spill their cup of tea. No, they won't spill their tea, but if you have 16MB of flash hooked up that the minimum erase size is 256K, then that one lost block is *really* aggrevating, especially since yaffs_mtdif.c doesn't mention that block zero is ignored(and an offset should be applied). > You can just use fixed constants in your mapping: Offset by one block. Since > dev->nChunksPerBlock holds the number of chunks per block that is all you > need to offset by for the reading/writing of a block. > > This means, all up, you need to add three lines of code: > > blockId--; // add to the erase function > > chunkId -= dev->nChunksPerBlock; // add to read/write functions > > And change two lines where you set the start and end blocks. > > Changing five lines of code is hardly a large effort. Much less than, say, > writing an email. Only after its taken a long day of yanking your hair out to understand the problem. No offense, but yaffs_fs.c, yaffs_mdtif.c and mkyaffsimage.c don't match as they exist now, and the documentation doesn't mention that the image created by mkyaffsimage.c should be offset by a flash block so that it all works. Anyone who's marched down this path should be able to tell you that. > > > > Is there anything *actually* wrong with using block zero? If what you > > say is true for NAND, then you don't even bother using the one > > guaranteed good block in the device... > > There is nothing technically wrong with using block zero from a memory/NAND > perspective. At the end of the day, file system integrity is governed by the > performance of the worst block and not the best block. Block zero is only > guaranteed good at the time of shipping and can go bad with time. Also, > many/most systems use block zero for some other purpose (eg. boot data or bad > block marker). Thus, relying on chunk zero being good is pointless. I'm already trying to use MTD underneath YAFFS, so this should be *completely* hidden from YAFFS point of view. I.E. the start of flash has a boot-loader in it and I'm using the following 15MB of a 16MB flash space, so I've partitioned the flash with 1MB for the base, and 15MB for YAFFS which YAFFS "conveniently" skips the first 256K space or 1.7% of the usable space(before you remove from use the reserved blocks). > Yaffs needs some chunk/block Id for "does not exist". As I mentioned before, > this could have been 0xFFFFFFFF/-1, but there are places (eg. Tnodes) where > YAFFS uses 16 bit values. Using 0xFFFFFFFF as an invalid marker gets to be a > headache when using 16 and 32 bits because we'd have to look at special > cases. Zero is way easier. > > Now this mapping stuff could be done in YAFFS so that YAFFS would be able to > start at block zero, but this has not yet risen to the top of the important > things to do pile, mainly because the workaround is trivial (which implies, > of course that fixing it in YAFFS is trivial too :-)). Tell me where the code is that assumes block zero is "does not exist", and I'll be glad to create/test(using LTP fs tests) a patch so the lower layer is clean with regard to the usable start of flash... -- Peter Barada From manningc2@actrix.gen.nz Wed Jun 22 05:55:23 2005 From: manningc2@actrix.gen.nz (Charles Manning) Date: Wed, 22 Jun 2005 16:55:23 +1200 Subject: [Yaffs] Why does YAFFS skip the first block? In-Reply-To: <1119413391.5580.253.camel@thunk> References: <1119381941.5580.205.camel@thunk> <20050622010421.43C9A15576@desire.actrix.co.nz> <1119413391.5580.253.camel@thunk> Message-ID: <20050622045253.69B5049E5@blood.actrix.co.nz> I have thought of a very simple way to add the mapping stuff so that it i= s=20 done completely internally to YAFFS, in a very non-obtrusive way (ie. I d= on't=20 want to do something that potentially hurts what is already there). YAFFS= =20 would then be able to accept and use block zero, but would work completel= y=20 transparently if a non-zero starting block was used. I think Frank's main point is that doing the work around (for YAFFS) requ= ires=20 hacking the mtd access stuff. ie., It seems nuts to go hack somewhere els= e to=20 fdo a YAFFS workaround. For the most part, people using YAFFS on NOR hav= e=20 done this with RTOSs, and had to write their own flash access functions s= o it=20 was not a big deal. While the loss of a single block is not significant for NAND systems it i= s=20 significant for many NOR systems. YAFFS is a NAND system, but there have=20 already been some hacks done to make YAFFS NOR friendlier. I consider my arm twisted and will do/test this in the next couple of day= s. -- Charles On Wednesday 22 June 2005 16:09, you wrote: > On Wed, 2005-06-22 at 13:06 +1200, Charles Manning wrote: > > On Wednesday 22 June 2005 12:13, Peter Barada wrote: > > > > > > > > All is not lost though, there is a way to use that block zero, a= nd > > > > it is pretty straight forward. You just need to tell YAFFS some l= ies! > > > > > > > > All yaffs flash calls go through a few access functions. > > > > All you need to do is to do a mapping in these functions so that > > > > yaffs block 1 =3D physical block 0. > > > > > > > > eg. > > > > int (*writeChunkToNAND)(struct yaffs_DeviceStruct *dev,int > > > > chunkInNAND, const __u8 *data, yaffs_Spare *spare) > > > > { > > > > chunkInNAND -=3D dev->nChunksPerBlock; > > > > > > > > ..... // rest of stuff > > > > } > > > > > > > > int (*eraseBlockInNAND)(struct yaffs_DeviceStruct *dev,int > > > > blockInNAND) { > > > > blockInNAND--; > > > > ...// rest of stuff > > > > } > > > > > > > > Now you must need to keep the illusion going by setting up the de= vice > > > > start and end blocks accordingly. If you have, say, 32 physical > > > > blocks numbered from 0 to 31, then just set up startBlock=3D1 and > > > > endBlock =3D32; > > > > > > > > There is no chunk or block info imprinted in the actual YAFFS dat= a, > > > > so no changes are needed to mkyaffsimage etc to make this work. > > > > > > Ugh, that sounds like a *total* hack. > > > > So what? It is very simple, works fine, is efficient and does not dis= rupt > > stable code. > > Yes it is a *simple* hack, but it builds on other "lies"(your words) in > the definition of YAFFS, i.e. that it *never* uses any data below the > first 'block' of flash. For NAND devices where block sizes are small > compared to the number of blocks, then this is no problem. In the case > where there are 4 8-bit flash parts, each with a 64k block size on a 32= - > bit bus, you're talking about a 256K block size in 16M of memory which > is pretty darn large. > > > As it is, you're already pulling nastier hacks to emulate spare regio= ns > > etc to make NOR look like NAND. > > That is because I want to use YAFFS on a NOR device because my hardware > has NOR devices. Of course I have to pull a hack. At least its a > *very* clean hack and hides itself from any layers above it. > > > >Is there anything wrong with > > > allowing dev->startBlock to be zero instead of 1? > > > > This would not work for various things. > > For example when YAFFS goes to look for the chunkId of the chunk in c= hunk > > zero, the search code would report "it is in chunk zero" which the r= est > > of yaffs interprets as "it does not exist". So anything you write to > > chunk zero is written into a black hole. > > Can you give me a pointer to function/line where this test is? Perhaps > fixing YAFFS to handle block zero is better than forcing a 'hack' at a > lower layer. The main offendiung function is yaffs_FindChunkInGroup() that looks at=20 theChunk. If theChunk was passed in as zero, then it means "chunk does no= t=20 exist". > > > > I *could* do the remap in the access functions, but it *assumes som= e > > > magical offset that requires a comment of: > > > > > > /* This is a total hack since YAFFS refuses to use block zero */ > > > > Hack, maybe. Total hack, I think, is stating it a bit strongly. > > Yes, "total" hack was a bit strong, but after using mkyaffsimage to > create a image that I put into flash, and finding that I couldn't find > some partial bits of it(and a bunch of objects end up in lost+found tha= t > can't even be opened), I may have expressed my frustration a bit strong= . > You can see where that comes from when 85% of the flash image is visibl= e > and usable... > > > Any offset is fine so long as there is no logical (ie from YAFFS's po= int > > of view) chunk zero any more. Just using a one block offset is the > > simplest case. Counting from one instead of zero is hardly going to m= ake > > most programmers spill their cup of tea. > > No, they won't spill their tea, but if you have 16MB of flash hooked up > that the minimum erase size is 256K, then that one lost block is > *really* aggrevating, especially since yaffs_mtdif.c doesn't mention > that block zero is ignored(and an offset should be applied). This is mentioned in yaffs_fs.c. The mkyaffsimage output is fine, so long as you write it into flash start= ing=20 at startBlock. > > > You can just use fixed constants in your mapping: Offset by one block= . > > Since dev->nChunksPerBlock holds the number of chunks per block that = is > > all you need to offset by for the reading/writing of a block. > > > > This means, all up, you need to add three lines of code: > > > > blockId--; // add to the erase function > > > > chunkId -=3D dev->nChunksPerBlock; // add to read/write functions > > > > And change two lines where you set the start and end blocks. > > > > Changing five lines of code is hardly a large effort. Much less than, > > say, writing an email. > > Only after its taken a long day of yanking your hair out to understand > the problem. No offense, but yaffs_fs.c, yaffs_mdtif.c and > mkyaffsimage.c don't match as they exist now, and the documentation > doesn't mention that the image created by mkyaffsimage.c should be > offset by a flash block so that it all works. Anyone who's marched dow= n > this path should be able to tell you that. The mkyaffsimage output is completely location independent, but it is=20 expected to be used with mkyaffs (which loads starting at block one). If = you=20 take the image and load it into flash at block 1 you'll be OK. In what way don't they match?=20 AFAIK, 1) yaffs_fs.c uses startBlock of 1 2) mkyaffs loads from block 1 3) yaffs_guts says block zero is not permitted. > Tell me where the code is that assumes block zero is "does not exist", > and I'll be glad to create/test(using LTP fs tests) a patch so the lowe= r > layer is clean with regard to the usable start of flash... The main offender is how the tnodes work and FindChunkInFile which assume= s=20 that the chunk does not exist if the chunkId is zero. From Peter.B@LogicPD.com Wed Jun 22 07:27:19 2005 From: Peter.B@LogicPD.com (Peter Barada) Date: Wed, 22 Jun 2005 02:27:19 -0400 Subject: [Yaffs] Why does YAFFS skip the first block? In-Reply-To: <20050622045253.69B5049E5@blood.actrix.co.nz> References: <1119381941.5580.205.camel@thunk> <20050622010421.43C9A15576@desire.actrix.co.nz> <1119413391.5580.253.camel@thunk> <20050622045253.69B5049E5@blood.actrix.co.nz> Message-ID: <1119421639.5580.273.camel@thunk> On Wed, 2005-06-22 at 16:55 +1200, Charles Manning wrote: > > I have thought of a very simple way to add the mapping stuff so that it is > done completely internally to YAFFS, in a very non-obtrusive way (ie. I don't > want to do something that potentially hurts what is already there). YAFFS > would then be able to accept and use block zero, but would work completely > transparently if a non-zero starting block was used. > > I think Frank's main point is that doing the work around (for YAFFS) requires > hacking the mtd access stuff. ie., It seems nuts to go hack somewhere else to > fdo a YAFFS workaround. For the most part, people using YAFFS on NOR have > done this with RTOSs, and had to write their own flash access functions so it > was not a big deal. > > While the loss of a single block is not significant for NAND systems it is > significant for many NOR systems. YAFFS is a NAND system, but there have > already been some hacks done to make YAFFS NOR friendlier. > > I consider my arm twisted and will do/test this in the next couple of days. I'd like to help, if I can. > On Wednesday 22 June 2005 16:09, you wrote: > > On Wed, 2005-06-22 at 13:06 +1200, Charles Manning wrote: > > > On Wednesday 22 June 2005 12:13, Peter Barada wrote: > > > > > > > > > > > All is not lost though, there is a way to use that block zero, and > > > > > it is pretty straight forward. You just need to tell YAFFS some lies! > > > > > > > > > > All yaffs flash calls go through a few access functions. > > > > > All you need to do is to do a mapping in these functions so that > > > > > yaffs block 1 = physical block 0. > > > > > > > > > > eg. > > > > > int (*writeChunkToNAND)(struct yaffs_DeviceStruct *dev,int > > > > > chunkInNAND, const __u8 *data, yaffs_Spare *spare) > > > > > { > > > > > chunkInNAND -= dev->nChunksPerBlock; > > > > > > > > > > ..... // rest of stuff > > > > > } > > > > > > > > > > int (*eraseBlockInNAND)(struct yaffs_DeviceStruct *dev,int > > > > > blockInNAND) { > > > > > blockInNAND--; > > > > > ...// rest of stuff > > > > > } > > > > > > > > > > Now you must need to keep the illusion going by setting up the device > > > > > start and end blocks accordingly. If you have, say, 32 physical > > > > > blocks numbered from 0 to 31, then just set up startBlock=1 and > > > > > endBlock =32; > > > > > > > > > > There is no chunk or block info imprinted in the actual YAFFS data, > > > > > so no changes are needed to mkyaffsimage etc to make this work. > > > > > > > > Ugh, that sounds like a *total* hack. > > > > > > So what? It is very simple, works fine, is efficient and does not disrupt > > > stable code. > > > > Yes it is a *simple* hack, but it builds on other "lies"(your words) in > > the definition of YAFFS, i.e. that it *never* uses any data below the > > first 'block' of flash. For NAND devices where block sizes are small > > compared to the number of blocks, then this is no problem. In the case > > where there are 4 8-bit flash parts, each with a 64k block size on a 32- > > bit bus, you're talking about a 256K block size in 16M of memory which > > is pretty darn large. > > > > > As it is, you're already pulling nastier hacks to emulate spare regions > > > etc to make NOR look like NAND. > > > > That is because I want to use YAFFS on a NOR device because my hardware > > has NOR devices. Of course I have to pull a hack. At least its a > > *very* clean hack and hides itself from any layers above it. > > > > > >Is there anything wrong with > > > > allowing dev->startBlock to be zero instead of 1? > > > > > > This would not work for various things. > > > For example when YAFFS goes to look for the chunkId of the chunk in chunk > > > zero, the search code would report "it is in chunk zero" which the rest > > > of yaffs interprets as "it does not exist". So anything you write to > > > chunk zero is written into a black hole. > > > > Can you give me a pointer to function/line where this test is? Perhaps > > fixing YAFFS to handle block zero is better than forcing a 'hack' at a > > lower layer. > > > The main offendiung function is yaffs_FindChunkInGroup() that looks at > theChunk. If theChunk was passed in as zero, then it means "chunk does not > exist". Hmm, I don't see yaffs_FindChunkInGroup in yaffs_guts.c, is that a YAFFS2 function? I see yaffs_FindChunkInFile() in yaffs_guts.c; is that what you're referring to? > > > > > > I *could* do the remap in the access functions, but it *assumes some > > > > magical offset that requires a comment of: > > > > > > > > /* This is a total hack since YAFFS refuses to use block zero */ > > > > > > Hack, maybe. Total hack, I think, is stating it a bit strongly. > > > > Yes, "total" hack was a bit strong, but after using mkyaffsimage to > > create a image that I put into flash, and finding that I couldn't find > > some partial bits of it(and a bunch of objects end up in lost+found that > > can't even be opened), I may have expressed my frustration a bit strong. > > You can see where that comes from when 85% of the flash image is visible > > and usable... > > > > > Any offset is fine so long as there is no logical (ie from YAFFS's point > > > of view) chunk zero any more. Just using a one block offset is the > > > simplest case. Counting from one instead of zero is hardly going to make > > > most programmers spill their cup of tea. > > > > No, they won't spill their tea, but if you have 16MB of flash hooked up > > that the minimum erase size is 256K, then that one lost block is > > *really* aggrevating, especially since yaffs_mtdif.c doesn't mention > > that block zero is ignored(and an offset should be applied). > > This is mentioned in yaffs_fs.c. Where? a search of 'zero' over yaffs_fs.c yeilds a comment before yaffs_delete_inode, referring to the link count, and 'block 0' only refers to the places where dev->startBlock is set. There's no comment as to *why* it can't be zero.... > The mkyaffsimage output is fine, so long as you write it into flash starting > at startBlock. Yeah, I figured that out, finally. You can imagine if you loaded the YAFFS image at block zero, and ignored the first 256K of data from the image, some *really* wierd stuff happens including root directory objects that never show up, and a lost+found that contains objects that have no contents(due to missing objects located in the first 256K). > > > > > You can just use fixed constants in your mapping: Offset by one block. > > > Since dev->nChunksPerBlock holds the number of chunks per block that is > > > all you need to offset by for the reading/writing of a block. > > > > > > This means, all up, you need to add three lines of code: > > > > > > blockId--; // add to the erase function > > > > > > chunkId -= dev->nChunksPerBlock; // add to read/write functions > > > > > > And change two lines where you set the start and end blocks. > > > > > > Changing five lines of code is hardly a large effort. Much less than, > > > say, writing an email. > > > > Only after its taken a long day of yanking your hair out to understand > > the problem. No offense, but yaffs_fs.c, yaffs_mdtif.c and > > mkyaffsimage.c don't match as they exist now, and the documentation > > doesn't mention that the image created by mkyaffsimage.c should be > > offset by a flash block so that it all works. Anyone who's marched down > > this path should be able to tell you that. > > > The mkyaffsimage output is completely location independent, but it is > expected to be used with mkyaffs (which loads starting at block one). If you > take the image and load it into flash at block 1 you'll be OK. I understand that mkyaffsimage produces a location independent image, but it *does* matter where it it is placed such that YAFFS actually accesses all of it. > In what way don't they match? > > AFAIK, > 1) yaffs_fs.c uses startBlock of 1 > 2) mkyaffs loads from block 1 > 3) yaffs_guts says block zero is not permitted. I have a separate bootloader that knows how to erase/burn flash. I'm trying to use YAFFS as a *root* filesystem, so it has to be burned from a boot-loader, and not from Linux, so mkyaffs doesn't help me here. I'd figure if mkyaffsimage is like mkfs.jffs2, it produces an image that can be burned *directly* into flash without the need for a support program (such as mkyaffs). And if YAFFS is my root FS, then I have a catch-22 here if I require mkyaffs... Documentation/yaffs-rootfs-howto.html has:

Creating a bootable yaffs partition:

You can

1) Create the partition by mounting it from a running linux os and copying the data there. The mkyaffs utility in the yaffs source simply erases a NAND mtdblock device without removing bad block data.

2) Make and download a filesystem image. The mkyaffsimage utility that came with the sources will create a YAFFS block list in a file from a root tree. This is a list of 512+16 byte blocks that need to be placed (in any order) on a NAND device.

You will need to write code to copy these data blocks and add in the block numbers in the oob areas.

Nowhere does that mention that mkyaffs is *required* to load the image created by mkyaffsimage into the NAND device so that it 'shuffles' the image past the first block. It describes mkyaffs as 'simply erases a NAND mtdblock device'. That can be accomplished by most boot-loaders. > > > > Tell me where the code is that assumes block zero is "does not exist", > > and I'll be glad to create/test(using LTP fs tests) a patch so the lower > > layer is clean with regard to the usable start of flash... > > The main offender is how the tnodes work and FindChunkInFile which assumes > that the chunk does not exist if the chunkId is zero. I'll start looking there to see how to handle a block being zero. I'm assuming that an objectId of zero is really bad... -- Peter Barada From wookey@aleph1.co.uk Wed Jun 22 11:59:05 2005 From: wookey@aleph1.co.uk (Wookey) Date: Wed, 22 Jun 2005 11:59:05 +0100 Subject: [Yaffs] Re: Why does YAFFS skip the first block? In-Reply-To: <1119421639.5580.273.camel@thunk> References: <1119381941.5580.205.camel@thunk> <20050622010421.43C9A15576@desire.actrix.co.nz> <1119413391.5580.253.camel@thunk> <20050622045253.69B5049E5@blood.actrix.co.nz> <1119421639.5580.273.camel@thunk> Message-ID: <20050622105905.GD24743@court.aleph1.co.uk> +++ Peter Barada [05-06-22 02:27 -0400]: > > The mkyaffsimage output is fine, so long as you write it into flash starting > > at startBlock. > > Yeah, I figured that out, finally. You can imagine if you loaded the > YAFFS image at block zero, and ignored the first 256K of data from the > image, some *really* wierd stuff happens including root directory > objects that never show up, and a lost+found that contains objects that > have no contents(due to missing objects located in the first 256K). > > > Only after its taken a long day of yanking your hair out to understand > > > the problem. No offense, but yaffs_fs.c, yaffs_mdtif.c and > > > mkyaffsimage.c don't match as they exist now, and the documentation > > > doesn't mention that the image created by mkyaffsimage.c should be > > > offset by a flash block so that it all works. Anyone who's marched down > > > this path should be able to tell you that. > > > > > > The mkyaffsimage output is completely location independent, but it is > > expected to be used with mkyaffs (which loads starting at block one). If you > > take the image and load it into flash at block 1 you'll be OK. > > I understand that mkyaffsimage produces a location independent image, > but it *does* matter where it it is placed such that YAFFS actually > accesses all of it. > > > In what way don't they match? > > > > AFAIK, > > 1) yaffs_fs.c uses startBlock of 1 > > 2) mkyaffs loads from block 1 > > 3) yaffs_guts says block zero is not permitted. > > I have a separate bootloader that knows how to erase/burn flash. I'm > trying to use YAFFS as a *root* filesystem, so it has to be burned from > a boot-loader, and not from Linux, so mkyaffs doesn't help me here. I'd > figure if mkyaffsimage is like mkfs.jffs2, it produces an image that can > be burned *directly* into flash without the need for a support program > (such as mkyaffs). And if YAFFS is my root FS, then I have a catch-22 > here if I require mkyaffs... > > Documentation/yaffs-rootfs-howto.html has: > >

Creating a bootable yaffs partition:

>

You can

>

1) Create the partition by mounting it from a running linux os and > copying the data there. The mkyaffs utility in the yaffs source > simply erases a NAND mtdblock device without removing bad block > data.

>

2) Make and download a filesystem image. The mkyaffsimage utility > that came with the sources will create a YAFFS block list in a file > from a root tree. This is a list of 512+16 byte blocks that need to > be placed (in any order) on a NAND device.

>

You will need to write code to copy these data blocks and add in > the block numbers in the oob areas.

> > Nowhere does that mention that mkyaffs is *required* to load the image > created by mkyaffsimage into the NAND device so that it 'shuffles' the > image past the first block. It describes mkyaffs as 'simply erases a > NAND mtdblock device'. That can be accomplished by most boot-loaders. Point taken. Thanx for pointing out that this isn't clear. We are working on better/newer docs now so this should get fixed fairly soon. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From Peter.B@LogicPD.com Wed Jun 22 15:08:18 2005 From: Peter.B@LogicPD.com (Peter Barada) Date: Wed, 22 Jun 2005 10:08:18 -0400 Subject: [Yaffs] Re: Why does YAFFS skip the first block? In-Reply-To: <20050622105905.GD24743@court.aleph1.co.uk> References: <1119381941.5580.205.camel@thunk> <20050622010421.43C9A15576@desire.actrix.co.nz> <1119413391.5580.253.camel@thunk> <20050622045253.69B5049E5@blood.actrix.co.nz> <1119421639.5580.273.camel@thunk> <20050622105905.GD24743@court.aleph1.co.uk> Message-ID: <1119449299.5580.277.camel@thunk> On Wed, 2005-06-22 at 11:59 +0100, Wookey wrote: > > Nowhere does that mention that mkyaffs is *required* to load the image > > created by mkyaffsimage into the NAND device so that it 'shuffles' the > > image past the first block. It describes mkyaffs as 'simply erases a > > NAND mtdblock device'. That can be accomplished by most boot-loaders. > > Point taken. Thanx for pointing out that this isn't clear. We are working on > better/newer docs now so this should get fixed fairly soon. After staring at yaffs_FindChunkInFile(), I think I've convinced myself that its not that the block can't be zero, but the chunkInNAND can't be zero. So instead of skipping the entire first block, we'd only have to skip the first chunk which is *much* more palatable. Of course I'd like to use as much of the flash as possible, so I'm digging some more. -- Peter Barada From Martin.Fouts at palmsource.com Thu Jun 23 00:21:46 2005 From: Martin.Fouts at palmsource.com (Martin Fouts) Date: Thu Jun 23 00:25:10 2005 Subject: [Yaffs] One more dumb question Message-ID: I've finally sifted through my config issues and now have a working P2 NAND driver. I'm trying to get yaffs to work 2.6.11 kernel. When I try to mount a file system I get / # mount -t yaffs2 /dev/mtdblock/4 /tmp/p4 yaffs: dev is 32505860 name is "(unavailable)" yaffs_read_super: Using yaffs2 yaffs_read_super: MTD block size 4096 yaffs: yaffs_GutsInitialise() yaffs: NAND geometry problems: chunk size 1, type is yaffs yaffs_read_super: guts initialised FAILED mount: permission denied. (are you root?) I am able to mount jffs2 file systems on the same partition. Before I dive into this, is there something obvious I'm doing wrong? Thanks, Marty From andre at bluewatersys.com Thu Jun 23 06:06:35 2005 From: andre at bluewatersys.com (Andre Renaud) Date: Thu Jun 23 06:09:15 2005 Subject: [Yaffs] Yaffs2 vs. Yaffs1 Message-ID: <1119503195.11493.79.camel@benmore> Can someone give me a quick overview of how Yaffs2 differs from Yaffs1 if you're using it on a 512 byte chunk/16 oob device? I've had a look at the source, and from what I could see it appears as if yaffs2 only works on 1024/32 devices, and the code for the 512/16 'appeared' to be the same as yaffs1 (that is probably where I'm wrong). For instance if I try to mount a 512/16 device using mount -t yaffs2 /dev/mtdblock/1 /mnt It complains that the geometry is incorrect (since yaffs2 doesn't do that), but if I specify -t yaffs, what benefit am I getting over the previous release? Thanks, -- Bluewater Systems Ltd - ARM Technology Solutions Centre Andre Renaud Bluewater Systems Ltd Phone: +64 3 3779127 (Aus 1 800 148 751) Level 17, 119 Armagh St Fax: +64 3 3779135 PO Box 13889 Email: arenaud@bluewatersys.com Christchurch Web: http://www.bluewatersys.com New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://stoneboat.aleph1.co.uk/pipermail/yaffs/attachments/20050623/a74071ba/attachment.pgp From beat.morf at duagon.com Thu Jun 23 15:15:36 2005 From: beat.morf at duagon.com (Beat Morf) Date: Thu Jun 23 15:18:56 2005 Subject: [Yaffs] Problem with deleted files after unmount/mount Message-ID: <42BAC408.1000800@duagon.com> Hi I am testing YAFFS with the direct implementation on my hardware. All work well until I tried following code. for (j=0; j<2; j++) { h = yaffs_open("/flash/yaffs1", O_CREAT | O_RDWR | O_TRUNC, S_IREAD | S_IWRITE); if (0 <= h) { if (200 == yaffs_write(h, buffer, 200)) { if (0 == yaffs_close(h)) { yaffs_unmount("/flash"); yaffs_mount("/flash"); if (0 == yaffs_rename("/flash/yaffs1", "/flash/yaffs2")) { if (0 == yaffs_unlink("/flash/yaffs2")) { /* OK */ diag_printf("round %d is OK\n", j); } else { diag_printf("unlink error\n"); } } else { diag_printf("rename error\n"); } } else { diag_printf("close error\n"); } } else { diag_printf("write error\n"); } } else { diag_printf("open error\n"); } } For (j==0) the loop works well and no file called /flash/yaffs1 or /flash/yaffs2 is available at the end. For (j==1) the procedure fails at the function yaffs_rename("/flash/yaffs1", "/flash/yaffs2") with the return value '-1'. If I list the directory "/flash", I see two files called "/flash/yaffs1" and "/flash/yaffs2" !!! Disabling the procedures 'yaffs_unmount("/flash")' and 'yaffs_mount("/flash")' will fix the problem! Does anybody know such a file-problem of unmounting and remounting a YAFFS partition during normal operation? (of course in normal operation a YAFFS partition is mounting at the beginning and unmounting at the end of an application). Thanks in advance, Beat Morf From Peter.B at LogicPD.com Fri Jun 24 20:34:28 2005 From: Peter.B at LogicPD.com (Peter Barada) Date: Fri Jun 24 20:48:44 2005 Subject: [Yaffs] Why does YAFFS skip the first block? In-Reply-To: <1119381941.5580.205.camel@thunk> References: <1119381941.5580.205.camel@thunk> Message-ID: <1119641669.5282.151.camel@thunk> On Tue, 2005-06-21 at 15:25 -0400, Peter Barada wrote: > I have a NOR implementation of YAFFS, and I've been pounding my head > with mkyaffsimage.c trying to get an image that can be built on a linux > box and used on a ColdFire mcf5475 based embedded Linux board using > kernel 2.4.26. I'm trying to figure out the *minimum* number of flash blocks required for YAFFS to run. In yaffs_GutsInitialize(), there are tests agains hard coded constants for the number of chunks in a flash block, number of reserved blocks, and number of blocks that YAFFS has to work with. 1) What is the minimum number of reserved blocks that YAFFS needs to run? I think its one(assuming that the NOR flash doesn't have as nearly the number of write errors that NAND does). 2) What is the minimum number of flash blocks (besides the reserved) that YAFFS needs to run? I think its two (one to collect, one to copy into, one to update). The reason I'm asking is that I'm trying to use YAFFS on a 1MB flash partition that has 256K flash blocks, leaving only 4 blocks total of which one is reserved. Any help is appreciated! Thanks! -- Peter Barada From manningc2 at actrix.gen.nz Sat Jun 25 04:29:43 2005 From: manningc2 at actrix.gen.nz (Charles Manning) Date: Sat Jun 25 04:33:45 2005 Subject: [Yaffs] Re: Why does YAFFS skip the first block? In-Reply-To: <1119565674.5282.91.camel@thunk> References: <8285CB7241FCFC4BB721A6F953F9B35E02E43AF9@xch.ap.trimblecorp.net> <20050623220924.1D63F4221@blood.actrix.co.nz> <1119565674.5282.91.camel@thunk> Message-ID: <20050625032706.348F3483A@blood.actrix.co.nz> YAFFS now allows use of block zero. Latest changes to cvs should do this. Not yet applied to YAFFS2 or to mkyaffs. -- Charles From rameshc at gmail.com Mon Jun 27 08:43:29 2005 From: rameshc at gmail.com (Ramesh Chaurasiya) Date: Mon Jun 27 08:54:14 2005 Subject: [Yaffs] YAFFS on kernel 2.4 In-Reply-To: References: <5585a07805061705504b002e97@mail.gmail.com> Message-ID: <5585a0780506270043160ea65f@mail.gmail.com> Hi, In 2.4 series there is no patch available for kernel 2.4.25 for XScale. You suggested to get 2.4.25, this time I took the following from 2.4.25 1. entire "fs" directory 2. entire "driver/mtd/nand" directory 3. whatever files that were required to get kernel compiled that includes various header files, many files from "drivers/mtd" source files from directory "lib" etc etc. Here also (after mounting yaffs partition) I am getting the same error "cp: cannot create regular file `abc': Cannot allocate memory" and finally "df" shows that there is no space on the NAND partition. >From NAND flash point of view I am using the code from kernel 2.4.25, which worked for you, so why its giving that error OR is there anything which I am doing wrong? Please help me to fix it up. Regards, Ramesh On 6/17/05, Nick Bane wrote: > > Hi, > > Source for kernel 2.4.19 is also there at husaberg.toby-churchill.com, > > I am working on PXA 255 board with kernel 2.4.19 as no patches are > > available for kernel 2.4.25 for XScale. > > I got the NAND flash worked on 2.6 kernel (tried jffs2) but for some > > reasons, I have to stick with the 2.4 kernel. > > > I haven't maitained 2.4.29 for a long while now. I consider ot obsolete. However, I believe it to have worked fine with the mtd/yaffs at that time. > > > I used 2.4.19 from the above site, I got YAFFS mounted successfully > > command "df" shows entire partition is empty but if I copy any data on > > to the NAND partition it takes too much time and finally gives error > > message > > "cp: cannot create regular file `abc': Cannot allocate memory" > > Now "df" shows that there is no space on the device > > Can any one help me out to fix it up. > > > Hmm. I remember that one. I am pretty sure it was fixed in later versions of the kernel+yaffs. > > > > The source that I got doing wget from husaberg.toby-churchill.com, has > > few files missing and is not getting compiled therefore from that > > source I used ... > > 1. fs/yaffs > > 2. mtd/mtdpart.c > > 3. drivers/mtd/nand and > > 4. required header files only (can this be the reason for?) > > Is anywhere tar compressed archive available for same source? > > > I suggest trying a wget of the 2.4.25 series. The latest can be downloaded via viewcvs and/or subversion. > > > > Nick > > > Thanks, > > Ramesh > > > > On 6/13/05, Nick Bane wrote: > > > Look at husaberg.toby-churchill.com/balloon/ and wget the > > 2.4.25-vrs2-tcl1 tree. > > > > > > Nick Bane > > > > > > > -----Original Message----- > > > > From: yaffs-admin@stoneboat.aleph1.co.uk > > > > [mailto:yaffs-admin@stoneboat.aleph1.co.uk]On Behalf Of Ramesh > > > > Chaurasiya > > > > Sent: 13 June 2005 16:13 > > > > To: yaffs@stoneboat.aleph1.co.uk > > > > Subject: [Yaffs] YAFFS on kernel 2.4 > > > > > > > > > > > > Hi, > > > > I am trying to get NAND flash work on kernel 2.4 > > > > can anyone please tell me from where can I get yaffs source > > > > appropriate for kernel 2.4 > > > > > > > > The source available today at > > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/ > > > > seems to be meant for kernel 2.6 > > > > > > > > -- > > > > Thanks, > > > > Ramesh > > > > > > > > _______________________________________________ > > > > yaffs mailing list > > > > yaffs@stoneboat.aleph1.co.uk > > > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > > > -- > > > > No virus found in this incoming message. > > > > Checked by AVG Anti-Virus. > > > > Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: 11/06/2005 > > > > > > > -- > > > No virus found in this outgoing message. > > > Checked by AVG Anti-Virus. > > > Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: 11/06/2005 > > > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: 15/06/2005 > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: 15/06/2005 > > -- Regards, Ramesh From nick at cecomputing.co.uk Mon Jun 27 10:06:54 2005 From: nick at cecomputing.co.uk (Nick Bane) Date: Mon Jun 27 10:09:24 2005 Subject: [Yaffs] YAFFS on kernel 2.4 In-Reply-To: <5585a0780506270043160ea65f@mail.gmail.com> Message-ID: > Hi, > In 2.4 series there is no patch available for kernel 2.4.25 for XScale. > You suggested to get 2.4.25, this time I took the following from 2.4.25 > 1. entire "fs" directory Only fs/yaffs is needed there plus a config/makefile patch to use it. > 2. entire "driver/mtd/nand" directory It might be that more than the nand bit of mtd is required. To be honest I have forgotten how patched the mtd tree is. A diff against a stock kernel would help. I hope you aren't mixing mtd distros. They tend to go as a single unit. Onto what are you grafting it? > 3. whatever files that were required to get kernel compiled that > includes various header files, many files from "drivers/mtd" source > files from directory "lib" etc etc. > lib is slightly surprising. > Here also (after mounting yaffs partition) I am getting the same error > "cp: cannot create regular file `abc': Cannot allocate memory" > and finally "df" shows that there is no space on the NAND partition. > This must be an oob spare area problem. There may be "bad stuff" in the oob spare area that needs erasing. If you erase the nand completely and mount it (I hope its not your rootfs) there should be only lost+found and free space. If df shows lots spare then the problem is very probably a mismatch between ecc versions. > >From NAND flash point of view I am using the code from kernel 2.4.25, > which worked for you, so why its giving that error OR is there > anything which I am doing wrong? Please help me to fix it up. > This is indeed perplexing and should have nothing to do with pxa. Charles? > > Regards, > Ramesh > > > On 6/17/05, Nick Bane wrote: > > > Hi, > > > Source for kernel 2.4.19 is also there at husaberg.toby-churchill.com, > > > I am working on PXA 255 board with kernel 2.4.19 as no patches are > > > available for kernel 2.4.25 for XScale. > > > I got the NAND flash worked on 2.6 kernel (tried jffs2) but for some > > > reasons, I have to stick with the 2.4 kernel. > > > > > I haven't maitained 2.4.29 for a long while now. I consider ot > obsolete. However, I believe it to have worked fine with the > mtd/yaffs at that time. > > > > > I used 2.4.19 from the above site, I got YAFFS mounted successfully > > > command "df" shows entire partition is empty but if I copy any data on > > > to the NAND partition it takes too much time and finally gives error > > > message > > > "cp: cannot create regular file `abc': Cannot allocate memory" > > > Now "df" shows that there is no space on the device > > > Can any one help me out to fix it up. > > > > > Hmm. I remember that one. I am pretty sure it was fixed in > later versions of the kernel+yaffs. > > > > > > > The source that I got doing wget from husaberg.toby-churchill.com, has > > > few files missing and is not getting compiled therefore from that > > > source I used ... > > > 1. fs/yaffs > > > 2. mtd/mtdpart.c > > > 3. drivers/mtd/nand and > > > 4. required header files only (can this be the reason for?) > > > Is anywhere tar compressed archive available for same source? > > > > > I suggest trying a wget of the 2.4.25 series. The latest can be > downloaded via viewcvs and/or subversion. > > > > > > > > Nick > > > > > Thanks, > > > Ramesh > > > > > > On 6/13/05, Nick Bane wrote: > > > > Look at husaberg.toby-churchill.com/balloon/ and wget the > > > 2.4.25-vrs2-tcl1 tree. > > > > > > > > Nick Bane > > > > > > > > > -----Original Message----- > > > > > From: yaffs-admin@stoneboat.aleph1.co.uk > > > > > [mailto:yaffs-admin@stoneboat.aleph1.co.uk]On Behalf Of Ramesh > > > > > Chaurasiya > > > > > Sent: 13 June 2005 16:13 > > > > > To: yaffs@stoneboat.aleph1.co.uk > > > > > Subject: [Yaffs] YAFFS on kernel 2.4 > > > > > > > > > > > > > > > Hi, > > > > > I am trying to get NAND flash work on kernel 2.4 > > > > > can anyone please tell me from where can I get yaffs source > > > > > appropriate for kernel 2.4 > > > > > > > > > > The source available today at > > > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/ > > > > > seems to be meant for kernel 2.6 > > > > > > > > > > -- > > > > > Thanks, > > > > > Ramesh > > > > > > > > > > _______________________________________________ > > > > > yaffs mailing list > > > > > yaffs@stoneboat.aleph1.co.uk > > > > > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > > > > -- > > > > > No virus found in this incoming message. > > > > > Checked by AVG Anti-Virus. > > > > > Version: 7.0.323 / Virus Database: 267.6.9 - Release > Date: 11/06/2005 > > > > > > > > > -- > > > > No virus found in this outgoing message. > > > > Checked by AVG Anti-Virus. > > > > Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: > 11/06/2005 > > > > > > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Anti-Virus. > > > Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: > 15/06/2005 > > > > > -- > > No virus found in this outgoing message. > > Checked by AVG Anti-Virus. > > Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: 15/06/2005 > > > > > > > -- > Regards, > Ramesh > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.8.2/29 - Release Date: 27/06/2005 > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.2/29 - Release Date: 27/06/2005 From rameshc at gmail.com Mon Jun 27 16:51:03 2005 From: rameshc at gmail.com (Ramesh Chaurasiya) Date: Mon Jun 27 16:54:07 2005 Subject: [Yaffs] YAFFS on kernel 2.4 In-Reply-To: References: <5585a0780506270043160ea65f@mail.gmail.com> Message-ID: <5585a0780506270851ea305d9@mail.gmail.com> >> Hi, >> In 2.4 series there is no patch available for kernel 2.4.25 for XScale. >> You suggested to get 2.4.25, this time I took the following from 2.4.25 >> 1. entire "fs" directory >Only fs/yaffs is needed there plus a config/makefile patch to use it. > > 2. entire "driver/mtd/nand" directory > It might be that more than the nand bit of mtd is required. To be honest I have forgotten how patched the mtd tree is. A diff against a stock kernel would help. I hope you aren't mixing mtd distros. They tend to go as a single unit. Onto what are you grafting it? Oh for mtd I mixed up the things from 2.4.19 and 2.4.25, I'll try taking entire mtd from 2.4.25 > > 3. whatever files that were required to get kernel compiled that > > includes various header files, many files from "drivers/mtd" source > > files from directory "lib" etc etc. > > > lib is slightly surprising. That was required by crc related stuff. > > Here also (after mounting yaffs partition) I am getting the same error > > "cp: cannot create regular file `abc': Cannot allocate memory" > > and finally "df" shows that there is no space on the NAND partition. > > > This must be an oob spare area problem. There may be "bad stuff" in the oob spare area that needs erasing. If you erase the nand completely and mount it (I hope its not your rootfs) there should be only lost+found and free space. If df shows lots spare then the problem is very probably a mismatch between ecc versions. Yes this happens if I erase the entire partition and then mount - df shows that entire partion is free (with lost+found directory) and then - if I copy any data on to NAND partion it takes too much time and eventually gives the error "cp: cannot create regular file `abc': Cannot allocate memory" and then - df shows entire partition is filled. But here I am trying to get it without ecc support first! I couldnt find the source for utils (mkyaffs) on husaberg.toby-churchill.com and therefore I am using the one that I downloaded from CVS some time back and made a change (initialization of eccpos member as done in drivers/mtd/nand/nand.c) in two files - utils/mkyaffs.c and - fs/yaffs_mtdif.c as shown below struct nand_oobinfo yaffs_oobinfo = { useecc: 1, //eccpos: {8, 9, 10, 13, 14, 15} eccpos: {0, 1, 2, 3, 6, 7} //As initialized in drivers/mtd/nand/nand.c }; Can mkyaffs be the problem here? Could you please tell me from where I can get utils and hence mkyaffs that is compatible with the 2.4.25 kernel source for balloon? > > >From NAND flash point of view I am using the code from kernel 2.4.25, > > which worked for you, so why its giving that error OR is there > > anything which I am doing wrong? Please help me to fix it up. > > > This is indeed perplexing and should have nothing to do with pxa. Charles? Thanks, Ramesh > > On 6/17/05, Nick Bane wrote: > > > > Hi, > > > > Source for kernel 2.4.19 is also there at husaberg.toby-churchill.com, > > > > I am working on PXA 255 board with kernel 2.4.19 as no patches are > > > > available for kernel 2.4.25 for XScale. > > > > I got the NAND flash worked on 2.6 kernel (tried jffs2) but for some > > > > reasons, I have to stick with the 2.4 kernel. > > > > > > > I haven't maitained 2.4.29 for a long while now. I consider ot > > obsolete. However, I believe it to have worked fine with the > > mtd/yaffs at that time. > > > > > > > I used 2.4.19 from the above site, I got YAFFS mounted successfully > > > > command "df" shows entire partition is empty but if I copy any data on > > > > to the NAND partition it takes too much time and finally gives error > > > > message > > > > "cp: cannot create regular file `abc': Cannot allocate memory" > > > > Now "df" shows that there is no space on the device > > > > Can any one help me out to fix it up. > > > > > > > Hmm. I remember that one. I am pretty sure it was fixed in > > later versions of the kernel+yaffs. > > > > > > > > > > The source that I got doing wget from husaberg.toby-churchill.com, has > > > > few files missing and is not getting compiled therefore from that > > > > source I used ... > > > > 1. fs/yaffs > > > > 2. mtd/mtdpart.c > > > > 3. drivers/mtd/nand and > > > > 4. required header files only (can this be the reason for?) > > > > Is anywhere tar compressed archive available for same source? > > > > > > > I suggest trying a wget of the 2.4.25 series. The latest can be > > downloaded via viewcvs and/or subversion. > > > > > > > > > > > > Nick From Martin.Fouts at palmsource.com Tue Jun 28 06:43:14 2005 From: Martin.Fouts at palmsource.com (Martin Fouts) Date: Tue Jun 28 06:54:07 2005 Subject: [Yaffs] ok, so i'm slow. but at least i have number numbers. Message-ID: I've finally straightened out all the configuration issues and now have yaffs2 in the kernel tree so that it will configure and build properly. meanwhile, i've also gotten the p2 NAND driver stabilized. I'm seeing some interesting bugs in yaffs2 on a Samsung NAND part, but it is stable enough to run some benchmarks. Is anyone interested in patches that allow yaffs2 to compile properly in-tree in 2.6.11.12? marty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://stoneboat.aleph1.co.uk/pipermail/yaffs/attachments/20050627/ad976035/attachment.html From beat.morf at duagon.com Wed Jun 29 07:59:16 2005 From: beat.morf at duagon.com (Beat Morf) Date: Wed Jun 29 08:09:00 2005 Subject: [Yaffs] Slow yaffs_readdir(..) Message-ID: <42C246C4.4050009@duagon.com> Hi I am using YAFFS direct implementation and actually testing some basically requirements. When I write hundreds of files into the root of my YAFFS-FS (let's say 600) and dump them afterwards ('yaffs_opendir()', 'yaffs_readdir()'), I saw, that the 'yaffs_readdir(...)' functions needs much more time for the last files than for the first one. Each call to the 'yaffs_readdir(...)' function will start at the first object within the 'yaffs_DIR'. For knowing which object was allready returned, a separate list of allready showed objects is applied (the objects are identifiable with the ObjectID); Means long times for a lot of files! What is exactly the reason for such a method if I don't need to give them out in an ordered way? And should they now be ordered? Actually I am using following 'yaffs_xxxxdir(...)' functions with a good performance ('dsc->list' is used for pointing to the next yaffsfs_ObjectListEntry entry): Beat yaffs_DIR *yaffs_opendir(const char *dirname) { yaffs_DIR *dir = NULL; struct list_head *i; yaffs_Object *obj = NULL; yaffsfs_DirectorySearchContext *dsc = NULL; yaffsfs_Lock(); obj = yaffsfs_FindObject(NULL,dirname,0); i = obj->variant.directoryVariant.children.next; if(obj && obj->variantType == YAFFS_OBJECT_TYPE_DIRECTORY) { dsc = YMALLOC(sizeof(yaffsfs_DirectorySearchContext)); dir = (yaffs_DIR *)dsc; if(dsc) { dsc->magic = YAFFS_MAGIC; dsc->list = NULL; memset(dsc->name,0,NAME_MAX+1); strncpy(dsc->name,dirname,NAME_MAX); dsc->list = (struct yaffsfs_ObjectListEntry*)i; } } yaffsfs_Unlock(); return dir; } struct yaffs_dirent *yaffs_readdir(yaffs_DIR *dirp) { yaffsfs_DirectorySearchContext *dsc = (yaffsfs_DirectorySearchContext *)dirp; struct yaffs_dirent *retVal = NULL; yaffs_Object *entry = NULL; int offset; struct list_head *i; yaffs_Object *obj = NULL; yaffsfs_Lock(); offset = -1; if(dsc && dsc->magic == YAFFS_MAGIC) { yaffsfs_SetError(0); obj = yaffsfs_FindObject(NULL,dsc->name,0); if ( ((i = (struct list_head*) dsc->list) != NULL) && (obj && obj->variantType == YAFFS_OBJECT_TYPE_DIRECTORY) && (i != &obj->variant.directoryVariant.children) ) { entry = (i) ? list_entry(i, yaffs_Object,siblings) : NULL; i = i->next; dsc->list = (struct yaffsfs_ObjectListEntry*)i; dsc->de.d_ino = yaffs_GetEquivalentObject(entry)->objectId; dsc->de.d_off = offset; yaffs_GetObjectName(entry,dsc->de.d_name,NAME_MAX+1); dsc->de.d_reclen = sizeof(struct yaffs_dirent); retVal = &dsc->de; } } else { yaffsfs_SetError(-EBADF); } yaffsfs_Unlock(); return retVal; } void yaffs_rewinddir(yaffs_DIR *dirp) { yaffsfs_DirectorySearchContext *dsc = (yaffsfs_DirectorySearchContext *)dirp; yaffs_Object *obj = NULL; struct list_head *i; yaffsfs_Lock(); obj = yaffsfs_FindObject(NULL,dsc->name,0); i = obj->variant.directoryVariant.children.next; dsc->list = (struct yaffsfs_ObjectListEntry*)i; yaffsfs_Unlock(); } int yaffs_closedir(yaffs_DIR *dirp) { yaffsfs_DirectorySearchContext *dsc = (yaffsfs_DirectorySearchContext *)dirp; yaffsfs_Lock(); dsc->list = NULL; dsc->magic = 0; YFREE(dsc); yaffsfs_Unlock(); return 0; } From wookey at aleph1.co.uk Wed Jun 29 21:36:02 2005 From: wookey at aleph1.co.uk (Wookey) Date: Wed Jun 29 21:47:07 2005 Subject: [Yaffs] Mailing list breakage now fixed Message-ID: <20050629203601.GH7868@xios> We had a server upgrade involving changing mailman from v1 to v2, which changes the way mailman works (especially the bounce-detection features). This interected badly with our slightly exotic mail configuration and anti-spam features, so messages sent between approx 16:55 on June 22nd (wed) and 14:48 on June 29th (wed) appeared to come from unverifiable email addresses and got binned as spam. Apologies for this (I knew the upgrade would break something). I beleive everything is now in order again so anyone who sent anything to these lists during the above broken period should try again. There will be some rationalisation of list domain names at some point which might potentially break things some more. Hassle me if there are further problems. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ From beat.morf at duagon.com Thu Jun 30 06:43:30 2005 From: beat.morf at duagon.com (Beat Morf) Date: Thu Jun 30 06:47:13 2005 Subject: [Yaffs] Slow yaffs_readdir(..) Message-ID: <42C38682.80500@duagon.com> Hi I am using YAFFS direct implementation and actually testing some basically requirements. When I write hundreds of files into the root of my YAFFS-FS (let's say 600) and dump them afterwards ('yaffs_opendir()', 'yaffs_readdir()'), I saw, that the 'yaffs_readdir(...)' functions needs much more time for the last files than for the first one. Each call to the 'yaffs_readdir(...)' function will start at the first object within the 'yaffs_DIR'. For knowing which object was allready returned, a separate list of allready showed objects is applied (the objects are identifiable with the ObjectID); Means long times for a lot of files! What is exactly the reason for such a method if I don't need to give them out in an special ordered way? Actually I am using following 'yaffs_xxxxdir(...)' functions with a good performance ('dsc->list' is used for pointing to the next yaffsfs_ObjectListEntry entry): Beat yaffs_DIR *yaffs_opendir(const char *dirname) { yaffs_DIR *dir = NULL; struct list_head *i; yaffs_Object *obj = NULL; yaffsfs_DirectorySearchContext *dsc = NULL; yaffsfs_Lock(); obj = yaffsfs_FindObject(NULL,dirname,0); i = obj->variant.directoryVariant.children.next; if(obj && obj->variantType == YAFFS_OBJECT_TYPE_DIRECTORY) { dsc = YMALLOC(sizeof(yaffsfs_DirectorySearchContext)); dir = (yaffs_DIR *)dsc; if(dsc) { dsc->magic = YAFFS_MAGIC; dsc->list = NULL; memset(dsc->name,0,NAME_MAX+1); strncpy(dsc->name,dirname,NAME_MAX); dsc->list = (struct yaffsfs_ObjectListEntry*)i; } } yaffsfs_Unlock(); return dir; } struct yaffs_dirent *yaffs_readdir(yaffs_DIR *dirp) { yaffsfs_DirectorySearchContext *dsc = (yaffsfs_DirectorySearchContext *)dirp; struct yaffs_dirent *retVal = NULL; yaffs_Object *entry = NULL; int offset; struct list_head *i; yaffs_Object *obj = NULL; yaffsfs_Lock(); offset = -1; if(dsc && dsc->magic == YAFFS_MAGIC) { yaffsfs_SetError(0); obj = yaffsfs_FindObject(NULL,dsc->name,0); if ( ((i = (struct list_head*) dsc->list) != NULL) && (obj && obj->variantType == YAFFS_OBJECT_TYPE_DIRECTORY) && (i != &obj->variant.directoryVariant.children) ) { entry = (i) ? list_entry(i, yaffs_Object,siblings) : NULL; i = i->next; dsc->list = (struct yaffsfs_ObjectListEntry*)i; dsc->de.d_ino = yaffs_GetEquivalentObject(entry)->objectId; dsc->de.d_off = offset; yaffs_GetObjectName(entry,dsc->de.d_name,NAME_MAX+1); dsc->de.d_reclen = sizeof(struct yaffs_dirent); retVal = &dsc->de; } } else { yaffsfs_SetError(-EBADF); } yaffsfs_Unlock(); return retVal; } void yaffs_rewinddir(yaffs_DIR *dirp) { yaffsfs_DirectorySearchContext *dsc = (yaffsfs_DirectorySearchContext *)dirp; yaffs_Object *obj = NULL; struct list_head *i; yaffsfs_Lock(); obj = yaffsfs_FindObject(NULL,dsc->name,0); i = obj->variant.directoryVariant.children.next; dsc->list = (struct yaffsfs_ObjectListEntry*)i; yaffsfs_Unlock(); } int yaffs_closedir(yaffs_DIR *dirp) { yaffsfs_DirectorySearchContext *dsc = (yaffsfs_DirectorySearchContext *)dirp; yaffsfs_Lock(); dsc->list = NULL; dsc->magic = 0; YFREE(dsc); yaffsfs_Unlock(); return 0; } From andre at bluewatersys.com Thu Jun 30 21:56:44 2005 From: andre at bluewatersys.com (Andre Renaud) Date: Thu Jun 30 22:02:26 2005 Subject: [Yaffs] Yaffs2 vs. Yaffs1 Message-ID: <1120165004.13664.101.camel@benmore> Can someone give me a quick overview of how Yaffs2 differs from Yaffs1 if you're using it on a 512 byte chunk/16 oob device? I've had a look at the source, and from what I could see it appears as if yaffs2 only works on 1024/32 devices, and the code for the 512/16 'appeared' to be the same as yaffs1 (that is probably where I'm wrong). For instance if I try to mount a 512/16 device using mount -t yaffs2 /dev/mtdblock/1 /mnt It complains that the geometry is incorrect (since yaffs2 doesn't do that), but if I specify -t yaffs, what benefit am I getting over the previous release? Thanks, -- Bluewater Systems Ltd - ARM Technology Solutions Centre Andre Renaud Bluewater Systems Ltd Phone: +64 3 3779127 (Aus 1 800 148 751) Level 17, 119 Armagh St Fax: +64 3 3779135 PO Box 13889 Email: arenaud@bluewatersys.com Christchurch Web: http://www.bluewatersys.com New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://stoneboat.aleph1.co.uk/pipermail/yaffs/attachments/20050701/e6369760/attachment.pgp From manningc2 at actrix.gen.nz Thu Jun 30 22:59:47 2005 From: manningc2 at actrix.gen.nz (Charles Manning) Date: Thu Jun 30 23:02:00 2005 Subject: [Yaffs] Yaffs2 vs. Yaffs1 In-Reply-To: <1120165004.13664.101.camel@benmore> References: <1120165004.13664.101.camel@benmore> Message-ID: <20050630215703.CBB3D1537B@desire.actrix.co.nz> On Friday 01 July 2005 08:56, Andre Renaud wrote: > Can someone give me a quick overview of how Yaffs2 differs from Yaffs1 > if you're using it on a 512 byte chunk/16 oob device? I've had a look at > the source, and from what I could see it appears as if yaffs2 only works > on 1024/32 devices, and the code for the 512/16 'appeared' to be the > same as yaffs1 (that is probably where I'm wrong). For instance if I try > to mount a 512/16 device using > mount -t yaffs2 /dev/mtdblock/1 /mnt > It complains that the geometry is incorrect (since yaffs2 doesn't do > that), but if I specify -t yaffs, what benefit am I getting over the > previous release? Hi Andre There are really two parts to this answer: YAFFS1 vs YAFFS2 NAND layout: In YAFFS1, the NAND layout has been set up for 512-byte pages. The YAFFS2 layout requires more spare (oob) area in flash to store the yaffs_PackedTags2 structure. Some people have suggested that by sqeezing bitbields, the same could be achieved on 512-byte pages, but the structure as it is requires 16 bytes (+ ECC bytes etc) - ie at least what is provided by a 1k page. YAFFS1 vs YAFFS2 code base: The YAFFS1 code base has some hard coded 512-byte constants etc. These have been stripped out of YAFFS2. YAFFS2 does some things differently, eg. YAFFS1 uses the stack for buffers, but YAFFS2 does not because in many situations (eg. Linux), the buffers get too big to put on the stack and they need compile-time knowledge of the size. The YAFFS2 code base supports both the YAFFS2 layout as well as the YAFFS1 layout through a backward compatability layer. If you are just using 512-byte devices, then you will not notice much difference between YAFFS1 and 2. YAFFS2 has some slight differences to garbage collection and file deletion. With time, there will probably be more changes. At present, there is no real benefit in running YAFFS2 in backward compatability mode (versus running YAFFS1), but it does mean that one chunk of code can be used for both. -- CHarles From manningc2 at actrix.gen.nz Thu Jun 30 23:19:49 2005 From: manningc2 at actrix.gen.nz (Charles Manning) Date: Thu Jun 30 23:31:56 2005 Subject: [Yaffs] Re: Why does YAFFS skip the first block? References: <8285CB7241FCFC4BB721A6F953F9B35E02E43AF9@xch.ap.trimblecorp.net> <1119565674.5282.91.camel@thunk> Message-ID: <20050630221657.31B6815915@desire.actrix.co.nz> Resend because the list went silly... On Saturday 25 June 2005 15:29, Charles Manning wrote: > YAFFS now allows use of block zero. > > Latest changes to cvs should do this. > > Not yet applied to YAFFS2 or to mkyaffs. > > -- Charles From manningc2 at actrix.gen.nz Thu Jun 30 23:41:52 2005 From: manningc2 at actrix.gen.nz (Charles Manning) Date: Thu Jun 30 23:46:54 2005 Subject: [Yaffs] Slow yaffs_readdir(..) In-Reply-To: <42C38682.80500@duagon.com> References: <42C38682.80500@duagon.com> Message-ID: <20050630223900.3800315BFE@desire.actrix.co.nz> On Thursday 30 June 2005 17:43, Beat Morf wrote: > Hi > > I am using YAFFS direct implementation and actually testing some > basically requirements. > > When I write hundreds of files into the root of my YAFFS-FS (let's say > 600) and dump them afterwards ('yaffs_opendir()', 'yaffs_readdir()'), I > saw, that the 'yaffs_readdir(...)' functions needs much more time for > the last files than for the first one. > > Each call to the 'yaffs_readdir(...)' function will start at the first > object within the 'yaffs_DIR'. For knowing which object was allready > returned, a separate list of allready showed objects is applied (the > objects are identifiable with the ObjectID); Means long times for a lot > of files! > > What is exactly the reason for such a method if I don't need to give > them out in an special ordered way? > > Actually I am using following 'yaffs_xxxxdir(...)' functions with a good > performance ('dsc->list' is used for pointing to the next > yaffsfs_ObjectListEntry entry): > Thanx Beat I have had this comment once before from someone using huge directories. I believe they got around the problem by caching names in their application. There are some interesting issues associated with directory reading. For example, what happens if another thread is writing new files to the directory or deleting files from the directory? The easiest way to do a directory traversal is to keep a pointer to the next sibling in the list as we search, but that can go wrong if that object gets deleted before you read it: eg. 1. Directory has files xx,yy zz. 2. Read dir, get xx. Pointer points to yy 3. Delete yy 4. Now pointer points to a non-existant object! Another way that does not work is to try remember the number where you are: eg. 1. Directory has files xx,yy zz. 2. Read dir, get xx. Remember we're pointing to item 1 (starting at zero) 3. Delete xx 4. Now item 1 is zz and we skipped past yy. The code, as is, covers for cuveballs like this but it isn't very efficient. This is something that I should look at improving. I have not looked at your code suggestion in detail yet, but I shall. -- Charles