From sharma.amit at samsung.com Tue Aug 1 01:49:04 2006 From: sharma.amit at samsung.com (Amit Kumar Sharma) Date: Tue, 01 Aug 2006 14:49:04 +0900 Subject: Bad block message from JFFS2 In-Reply-To: <6AD9F6A5F6E096408F0B703773355A070129D945@CHN-SNR-MBX01.wipro.com> Message-ID: <007b01c6b52e$335f6250$3d92340c@dsn.sec.samsung.com> Hi Thanks for reply. I am getting Node CRC read error too or some time data CRC or head CRC.I think some alignment problem because I am using utility tools developed for 2.6 kernel. I think for they may have some problem for 2.4 that why these messages are coming. Any way what is ur idea about tools like flasheraseall, nandwrite and mkfs.jffs2. Do these tools need to be investigating for using with 2.4 kernels. Can u tell me why this message is coming? Newly-erased block contained word 0x1313000 at offset 0x0b4e0000 Newly-erased block contained word 0x1b076 at offset 0x05540000 Thanks Amit -----Original Message----- From: srideep.devireddy at wipro.com [mailto:srideep.devireddy at wipro.com] Sent: Tuesday, August 01, 2006 2:33 PM To: sharma.amit at samsung.com Subject: RE: Bad block message from JFFS2 Hi , Normally the logic for jffs2 making a block as bad is Any block where the 1st and 6th bytes in the spare area of the 1st page doesn't contain ffh is a bad block , yes the clean marker is not updated ( -j option should update the clean marker in spare area , try this out correctly . When writing data to nand on a page it write it and reads it back to check the crc , if the crc is found correctly it continues to write data to next block or page . while the crc is read wrongly then it adds that block to the bad block list . later jffs2 tries to make it good , if not it frees it from the node list . In your case I see data is written even to the bad blocks , this is because . while writing data clean marker is not updated properly . So it write there and next time when it boots after scaning , it finds bad block . If your using a u-boot loader , then try to perform a nand erase from there , if you are mounting the device after linux comes up . eraseall -j /dev/mtblock/0 or 1 and try to copy the file system? Hw are you writing the filesystem on the nand ? Good luck ... Regards Srideep -----Original Message----- From: Amit Kumar Sharma [mailto:sharma.amit at samsung.com] Sent: Tuesday, August 01, 2006 10:45 AM To: Srideep DeviReddy (WT01 - Broadband Networks) Subject: RE: Bad block message from JFFS2 Hi Srideep This problem is coming from bad blocks as flasheraseall -j will not update Bad blocks with erase marker so I wonder why Jffs2 try to write in these block. Thanks Amit -----Original Message----- From: srideep.devireddy at wipro.com [mailto:srideep.devireddy at wipro.com] Sent: Tuesday, August 01, 2006 2:06 PM To: sharma.amit at samsung.com Subject: RE: Bad block message from JFFS2 Hi Amit , I think the problem below is clean marker from jffs2 is not written properly after the block is been erased .. check the clean marker implementation in jffs2 code of your's , Regards Srideep -----Original Message----- From: linux-mtd-bounces at lists.infradead.org [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of Amit Kumar Sharma Sent: Tuesday, August 01, 2006 5:34 AM To: linux-mtd at lists.infradead.org Subject: Bad block message from JFFS2 Hi I am testing JFFS2 with OneNAND mtd on Linux kernel mvl 2.4.20 I have two partition of JFFS2 on my device of following size 20Mb and 200Mb. During iozone testing on flash partition of size 200Mb, JFFS2 try to erase device and it create Bad blocks on device .when I try to check with some different software, I did not find so many bad blocks on my device .How I Can verify bad block marker in JFFS2 and in which condition JFFS2 will mark a block as bad block? During IOZONE running on 200Mb partition for 20Mb file read and write operation.I am getting following debugging messages on console KB reclen write rewrite read reread 20480 4jffs2_scan_eraseblock(): Node at 0x003cdff8 {0x1985, 0x) jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003cdffc: 0x0046 id jffs2_check_nand_cleanmarker(): Bad block at 05560000 block state bad block /* ==========" block state bad block print is coming from here=============== int ret = jffs2_check_nand_cleanmarker(c, jeb); D2(printk(KERN_NOTICE "jffs_check_nand_cleanmarker returned %d\n",ret)); /* Even if it's not found, we still scan to see if the block is empty. We use this information to decide whether to erase it or not. */ switch (ret) { case 0: cleanmarkerfound = 1; break; case 1: break; case 2: printk("block state bad block\n"); return BLK_STATE_BADBLOCK; case 3: ========================================================*/ jffs2_check_nand_cleanmarker(): Bad block at 05580000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 055a0000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 0b9e0000 block state bad block Newly-erased block contained word 0xe0021985 at offset 0x05540000 Newly-erased block contained word 0x44c17860 at offset 0x00220000 Newly-erased block contained word 0x20f000 at offset 0x00200000 jffs2_scan_eraseblock(): Node at 0x003cdff8 {0x1985, 0xe002, 0x00000046) has in) jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003cdffc: 0x0046 id jffs2_check_nand_cleanmarker(): Bad block at 05560000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 05580000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 055a0000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 0b9e0000 block state bad block Newly-erased block contained word 0x3 at offset 0x0bb60000 Newly-erased block contained word 0x34 at offset 0x05540000 Newly-erased block contained word 0x1141 at offset 0x06860000 3318 1875jffs2_scan_eraseblock(): Node at 0x003cdff8 {0x1985, 0xe002, 0x) jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003cdffc: 0x0046 id jffs2_check_nand_cleanmarker(): Bad block at 05560000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 05580000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 055a0000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 0b9e0000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 0bb60000 block state bad block Newly-erased block contained word 0x1313000 at offset 0x0b4e0000 Newly-erased block contained word 0x1b076 at offset 0x05540000 Newly-erased block contained word 0x1400000 at offset 0x0bb40000 jffs2_scan_eraseblock(): Node at 0x003cdff8 {0x1985, 0xe002, 0x00000046) has in) jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003cdffc: 0x0046 id jffs2_check_nand_cleanmarker(): Bad block at 05560000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 05580000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 055a0000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 0b9e0000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 0bb40000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 0bb60000 block state bad block Newly-erased block contained word 0xe0021985 at offset 0x09220000 Newly-erased block contained word 0x0 at offset 0x05540000 5362 4459 Newly-erased block contained word 0x1141 at offset 0x06800000 Newly-erased block contained word 0x2fc93c1e at offset 0x04d60000 20480 8jffs2_scan_eraseblock(): Node at 0x003cdff8 {0x1985, 0x) jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003cdffc: 0x0046 id jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x04d42800: 0x4994 id jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x04d42804: 0xd309 id jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x04d42808: 0xac25 id jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x04d4280c: 0xa49c id jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x04d42810: 0x96f8 id jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x04d42814: 0x5b8f id jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x04d42818: 0x0c02 id jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x04d4281c: 0x203a id jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x04d42820: 0x803e id jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x04d42824: 0x4764 id Further such events for this erase block will not be printed jffs2_check_nand_cleanmarker(): Bad block at 04d60000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 05560000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 05580000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 055a0000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 09220000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 0b9e0000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 0bb40000 block state bad block jffs2_check_nand_cleanmarker(): Bad block at 0bb60000 block state bad block I am getting following message from device after boot up complete. " Newly-erased block contained word 0x1a2c3ecf at offset 0x054e000 root at apollon:~# Newly-erased block contained word 0x37fc4828 at offset 0x0bb4000... " ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From dedekind at infradead.org Tue Aug 1 09:46:41 2006 From: dedekind at infradead.org (Artem B. Bityutskiy) Date: Tue, 01 Aug 2006 17:46:41 +0400 Subject: [PATCH] JFFS2 superblock support Message-ID: <1154440001.30995.7.camel@sauron.oktetlabs.ru> David, here is the patch which adds superblock node support to JFFS2 (we talked about this). The superblock node has no useful data so far - this patch just adds general support. The next steps are: 1. useful data to SB and probably corresponding ioctl() interfaces which change these data. 3. update mtdutils correspondingly; I'm only planning to add reserved size to the SB. Comments? -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. -------------- next part -------------- A non-text attachment was scrubbed... Name: add-superblock.diff Type: text/x-patch Size: 16048 bytes Desc: not available Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20060801/ddf38eff/attachment.bin From jwboyer at gmail.com Tue Aug 1 10:14:30 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 1 Aug 2006 09:14:30 -0500 Subject: [PATCH] JFFS2 superblock support In-Reply-To: <1154440001.30995.7.camel@sauron.oktetlabs.ru> References: <1154440001.30995.7.camel@sauron.oktetlabs.ru> Message-ID: <625fc13d0608010714u48a7e582qea5a719b4b0aab55@mail.gmail.com> On 8/1/06, Artem B. Bityutskiy wrote: > David, > > here is the patch which adds superblock node support to JFFS2 (we talked > about this). The superblock node has no useful data so far - this patch > just adds general support. I forget exactly why a super block should be added. Could you refresh my memory? josh From dedekind at yandex.ru Tue Aug 1 10:36:45 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Tue, 01 Aug 2006 18:36:45 +0400 Subject: [PATCH] JFFS2 superblock support In-Reply-To: <625fc13d0608010714u48a7e582qea5a719b4b0aab55@mail.gmail.com> References: <1154440001.30995.7.camel@sauron.oktetlabs.ru> <625fc13d0608010714u48a7e582qea5a719b4b0aab55@mail.gmail.com> Message-ID: <44CF66FD.1090106@yandex.ru> Josh Boyer wrote: > I forget exactly why a super block should be added. Could you refresh > my memory? Just a normal node with no fixed place contaning all the per-FS data. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From dbyron at hheld.com Tue Aug 1 15:25:19 2006 From: dbyron at hheld.com (David Byron) Date: Tue, 1 Aug 2006 12:25:19 -0700 Subject: autoconf for mtd-utils In-Reply-To: AAAAAJOKoN+ryO5OkOyypB2eX+7EESIA Message-ID: <000001c6b5a0$3a0a5bb0$c834800a@RudiDell> On Mon, 2006-07-31 at 5:50p, Josh Boyer wrote: > Better. But it only defines BUILDDIR during a cross compile. Is that > what you wanted? Or did you want a general purpose way to separate > the object and binary files from the source during build time? I do define BUILDDIR for native builds too, but to the current directory. The important thing for me is that native objects live in a different place than cross-compiled objects. Where they are relative to the source isn't important to me at the moment. -DB From edwinfong001 at yahoo.com.hk Tue Aug 1 10:03:19 2006 From: edwinfong001 at yahoo.com.hk (Maybank Hong Kong.) Date: Tue, 1 Aug 2006 22:03:19 +0800 (CST) Subject: Project From Hong Kong. Message-ID: <53383.213.185.118.200.1154440999.squirrel@nurrti.email.starband.net> Mr. Fong Edwin. Maybank Hong Kong, 21/F, Man Yee Building, 68 Des Voeux Road Central, Hong Kong. edwinfong001 at yahoo.com.hk Greetings. I am Mr. Fong Edwin of Trade Finance Department, Maybank Hong Kong. On July 6, 2004, our client Dr. Ravia Pumin, a businessman, made a numbered fixed deposit for 6 (six) calendar months, with a value of US$16.5m only in my branch. Upon maturity several notice was sent to him and no response came from him. Another notification was sent early August 2005 and still no response came from him. The Bank officially sent two-man delegate to his residence in Indonesia were he reside only to find out that the business mogul and his family perished in the Tsunami Disaster on 26th december 2004. After further investigations, it was also discovered that Dr. Ravia Pumin did not declare any next of kin in his official papers, including the paper work of his bank deposit. And he also confided in me the last time he visited my office that no one except me knew of his deposit in my bank. So, Sixteen million, Five Hundred Thousand United State Dollars is still lying in my bank and no one will ever come forward to claim it. According to the laws in Hong Kong, at the expiration of two year (2 years) the funds will revert to the ownership of Hong Kong Government if nobody applies to claim the funds. I will like you as a foreigner to stand as the next of kin to Dr. Ravia Pumin to enable you receive the funds. Lets put heads together to see how we can transfer these funds out of Hong Kong and use it judiciously.I have contacted my Attorney that will prepare the necessary document that will back you up as the next of kin to Dr. Ravia Pumin, all that is require from you at this stage is for you to provide me with your full names and Address including your direct phone and fax numbers for my Attorney to commence his job. It can be sent through my personal email below.My Attorney will also file in for claims on your behalf and secure the necessary approval and letter of probate in your favor for the funds to be move to an account that will be provided by you. We are going to adopt a legalized method and the Attorney will prepare all the necessary documents and no risk involve. Note that sharing percentage is negotiable by the two parties. Contact me via my personal email address with your full names, address, fax and telephone number if you are interested and more details will be provided to you about the Project. Sincerely, Mr. Fong Edwin. edwinfong001 at yahoo.com.hk From dbyron at hheld.com Tue Aug 1 16:59:57 2006 From: dbyron at hheld.com (David Byron) Date: Tue, 1 Aug 2006 13:59:57 -0700 Subject: nandwrite in FAQ Message-ID: <001001c6b5ad$727d9400$c834800a@RudiDell> Related to http://lists.infradead.org/pipermail/linux-mtd/2006-July/016184.html, what do you think of removing the -j argument to nandwrite in the NAND FAQ? Definitely would have saved me a bunch of time. -DB -------------- next part -------------- A non-text attachment was scrubbed... Name: nand.xml.patch Type: application/octet-stream Size: 611 bytes Desc: not available Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20060801/94744f51/attachment.obj From Jan.Korger at uni-konstanz.de Tue Aug 1 14:04:51 2006 From: Jan.Korger at uni-konstanz.de (Jan Korger) Date: Tue, 1 Aug 2006 20:04:51 +0200 Subject: "Bad eraseblock" - NAND memory gone bad? (Zaurus, mtdblock) Message-ID: <20060801200451.26e54e4e@urania.exp.univie.ac.at> Hi everyone, I'm not a kernel developer, but I couldn't find user documentation for my problem, so I hope someone on this list will kindly provide some hints. I have asked this question in a Zaurus Forum without getting a reply. I own 2.5years old Sharp Zaurus C860, which suddenly stopped working properly. These devices have a built-in 128MiB NAND. I'm using the OpenZaurus distribution (OZ version 3.5.4, Linux kernel version 2.6.14), which uses three partitions, two of them are (read/write) jffs2 mounted via /dev/mtdblock?. I can find out more details about the system if it should matter. Not working "properly" means the device does boot but the GUI (GPE 2.7, X) is not usable (various minor issues, could be due to lost configuration data). I can however manage to get a text console with bash and friends. I saved the output from 'dmesg' after a reboot: http://www.oesf.org/forums/index.php?act=Attach&type=post&id=2744 The interesting part, which makes me think I may have a NAND problem, is this: NAND device: Manufacturer ID: 0xec, Chip ID: 0x79 (Samsung NAND 128MiB 3,3V 8-bit) Scanning device for bad blocks Bad eraseblock 32 at 0x00080000 Bad eraseblock 3095 at 0x0305c000 Bad eraseblock 3099 at 0x0306c000 Creating 3 MTD partitions on "sharpsl-nand": 0x00000000-0x00700000 : "System Area" 0x00700000-0x03c00000 : "Root Filesystem" 0x03c00000-0x08000000 : "Home Filesystem" I never inspected the boot messages while the Zaurus worked. ;-( Thus, I cannot tell whether this messages have always been there or not. I understand that NAND chips usually have a few badblocks from the very beginning, i.e. when they leave the manufacturer, and that NAND wears out after c. 100'000 write/erase cycles. How can I tell the difference? Are these worn out NAND blocks and -- if yes -- does this mean I have already reached the end of the NAND's lifetime? The only test I did was running md5sum on /dev/mtdblock? (where ? is 0 to 3). For mtdblock1 and mtdblock2 I saw "IO errors", these are the first two partions on the NAND chip in question, i.e. the kernel ("System area") and the "Root Filesystem". This is exactly where the badblocks as seen above are. (JFTR, I think mtdblock0 refers to another ROM.) If possible, I want to get the Zaurus back to a usable state. I have backed up my data but I don't want to experiment too much for not to make things worse. There are three options to operate on the built-in NAND: (I don't want to disassamble it. I don't have suitable tools anyways.) 1. While Linux is running through /dev/*. This seems difficult because the partition in question will be mounted (readonly maybe). 2. By using the Zaurus upgrade procedure, my preferred method. This involves booting from a SD or CF card and executing a shell script. OpenZaurus' version of this script is hard to read but it involves 'eraseall', 'nandlogical', 'nandcp' (IIRC 'nandlogical' is something Sharp invented, used mainly for historic reasons.): http://www.spacezone.de/zaurus/articles/update.sh.txt 3. By using Zaurus' "Full NAND Restore" feature. This will overwrite the whole NAND from a binary image file. I don't know how (and if) this method deals with badblocks. It is designed as a last resort when method 2 fails. The Zaurus stuff is off-topic here, of course, but I hope I provided enough information for you to understand my problem. Thanks for taking your time to read it. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20060801/78602e4d/attachment.bin From dedekind at yandex.ru Wed Aug 2 00:47:27 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Wed, 02 Aug 2006 08:47:27 +0400 Subject: nandwrite in FAQ In-Reply-To: <001001c6b5ad$727d9400$c834800a@RudiDell> References: <001001c6b5ad$727d9400$c834800a@RudiDell> Message-ID: <44D02E5F.20707@yandex.ru> David Byron wrote: > Related to > http://lists.infradead.org/pipermail/linux-mtd/2006-July/016184.html, what > do you think of removing the -j argument to nandwrite in the NAND FAQ? > Definitely would have saved me a bunch of time. MTD/JFFS2 FAQs are updated not very often. Feel free to send a patch - MTD's web contents are at git://git.infradead.org/mtd-www.git, GIT howto is at http://www.linux-mtd.infradead.org/doc/git.html. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From jwboyer at gmail.com Wed Aug 2 07:00:57 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 2 Aug 2006 06:00:57 -0500 Subject: autoconf for mtd-utils In-Reply-To: <000001c6b5a0$3a0a5bb0$c834800a@RudiDell> References: <000001c6b5a0$3a0a5bb0$c834800a@RudiDell> Message-ID: <625fc13d0608020400w307e5e77s40f4aa604c0e4395@mail.gmail.com> On 8/1/06, David Byron wrote: > On Mon, 2006-07-31 at 5:50p, Josh Boyer wrote: > > > Better. But it only defines BUILDDIR during a cross compile. Is that > > what you wanted? Or did you want a general purpose way to separate > > the object and binary files from the source during build time? > > I do define BUILDDIR for native builds too, but to the current directory. > The important thing for me is that native objects live in a different place > than cross-compiled objects. Where they are relative to the source isn't > important to me at the moment. This looks OK to me. dwmw2, do you have any issues with this? josh From r&d2 at dave-tech.it Wed Aug 2 10:14:18 2006 From: r&d2 at dave-tech.it (llandre) Date: Wed, 02 Aug 2006 16:14:18 +0200 Subject: How to generate a patch limited to MTD subsystem Message-ID: <44D0B33A.2080702@dave-tech.it> I'm facing the following problem. I'm working on custom hardware with kernel 2.6.15. I suspect I need to update the MTD subsystem with latest sources. How to do that without migrating to latest kernel? In other words I need to generate a patch from latest MTD code against MTD code included in v2.6.15 kernel. Is it possible? How? TIA, llandre DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2 at dave-tech.it From dedekind at yandex.ru Wed Aug 2 10:38:55 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Wed, 02 Aug 2006 18:38:55 +0400 Subject: How to generate a patch limited to MTD subsystem In-Reply-To: <44D0B33A.2080702@dave-tech.it> References: <44D0B33A.2080702@dave-tech.it> Message-ID: <44D0B8FF.6090601@yandex.ru> llandre wrote: > I'm facing the following problem. > I'm working on custom hardware with kernel 2.6.15. I suspect I need to > update the MTD subsystem with latest sources. How to do that without > migrating to latest kernel? In other words I need to generate a patch > from latest MTD code against MTD code included in v2.6.15 kernel. Is it > possible? How? I'd do like this: rm -rf linux-2.6.15/drivers/mtd cp -r linux-latest/drivers/mtd linux-2.6.15/drivers/ rm linux-2.6.15/include/mtd cp -r linux-latest/include/mtd linux-2.6.15/include/mtd rm linux-2.6.15/include/linux/mtd cp -r linux-latest/include/linux/mtd linux-2.6.15/include/linux/mtd Then try to compile & run and resolve all problems. I suspect there are not going to be many of them. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From dbyron at hheld.com Wed Aug 2 10:42:42 2006 From: dbyron at hheld.com (David Byron) Date: Wed, 2 Aug 2006 07:42:42 -0700 Subject: nandwrite in FAQ In-Reply-To: AAAAAJOKoN+ryO5OkOyypB2eX+6kJyIA Message-ID: <004801c6b641$e97c1330$c834800a@RudiDell> On Tuesday August 1, 2006, Artem B. Bityutskiy wrote: > MTD/JFFS2 FAQs are updated not very often. Feel free to > send a patch - MTD's web contents are at > git://git.infradead.org/mtd-www.git, GIT howto is at > http://www.linux-mtd.infradead.org/doc/git.html. I attached a patch to my original message. Is that enough? Getting an account at infradead, making my own tree, etc. seems like overkill for a three character change. -DB From dedekind at yandex.ru Wed Aug 2 10:44:39 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Wed, 02 Aug 2006 18:44:39 +0400 Subject: nandwrite in FAQ In-Reply-To: <004801c6b641$e97c1330$c834800a@RudiDell> References: <004801c6b641$e97c1330$c834800a@RudiDell> Message-ID: <44D0BA57.9040200@yandex.ru> David Byron wrote: > I attached a patch to my original message. Is that enough? Getting an > account at infradead, making my own tree, etc. seems like overkill for a > three character change. Sorry, missed the attached patch. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From dedekind at yandex.ru Wed Aug 2 10:52:44 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Wed, 02 Aug 2006 18:52:44 +0400 Subject: nandwrite in FAQ In-Reply-To: <004801c6b641$e97c1330$c834800a@RudiDell> References: <004801c6b641$e97c1330$c834800a@RudiDell> Message-ID: <44D0BC3C.8080700@yandex.ru> David Byron wrote: > I attached a patch to my original message. Is that enough? Getting an > account at infradead, making my own tree, etc. seems like overkill for a > three character change. > Committed to my tree so far. Will importune dwmw2 to pull from it. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From dbyron at hheld.com Wed Aug 2 10:59:14 2006 From: dbyron at hheld.com (David Byron) Date: Wed, 2 Aug 2006 07:59:14 -0700 Subject: nandwrite in FAQ In-Reply-To: AAAAAJOKoN+ryO5OkOyypB2eX+4ELSIA Message-ID: <004901c6b644$38f305c0$c834800a@RudiDell> On Wednesday August 2, 2006, Artem B. Bityutskiy wrote: > Committed to my tree so far. Will importune dwmw2 to pull from it. Thank you. -DB From r&d2 at dave-tech.it Wed Aug 2 11:18:40 2006 From: r&d2 at dave-tech.it (llandre) Date: Wed, 02 Aug 2006 17:18:40 +0200 Subject: How to generate a patch limited to MTD subsystem In-Reply-To: <44D0B8FF.6090601@yandex.ru> References: <44D0B33A.2080702@dave-tech.it> <44D0B8FF.6090601@yandex.ru> Message-ID: <44D0C250.2030601@dave-tech.it> > I'd do like this: > > rm -rf linux-2.6.15/drivers/mtd > cp -r linux-latest/drivers/mtd linux-2.6.15/drivers/ > > rm linux-2.6.15/include/mtd > cp -r linux-latest/include/mtd linux-2.6.15/include/mtd > > rm linux-2.6.15/include/linux/mtd > cp -r linux-latest/include/linux/mtd linux-2.6.15/include/linux/mtd > > Then try to compile & run and resolve all problems. I suspect there are > not going to be many of them. > Hmm ... if I recall correctly MTD provides more stuff (JFFS2 for example), doesn't it? -- llandre DAVE Electronics System House - R&D Department web: http://www.dave-tech.it email: r&d2 at dave-tech.it From dedekind at infradead.org Wed Aug 2 11:22:10 2006 From: dedekind at infradead.org (Artem B. Bityutskiy) Date: Wed, 02 Aug 2006 19:22:10 +0400 Subject: How to generate a patch limited to MTD subsystem In-Reply-To: <44D0C250.2030601@dave-tech.it> References: <44D0B33A.2080702@dave-tech.it> <44D0B8FF.6090601@yandex.ru> <44D0C250.2030601@dave-tech.it> Message-ID: <1154532130.11061.3.camel@sauron.oktetlabs.ru> On Wed, 2006-08-02 at 17:18 +0200, llandre wrote: > Hmm ... if I recall correctly MTD provides more stuff (JFFS2 for > example), doesn't it? If you need JFFS2 as well, do similar for fs/jffs2, include/linux/jffs2*. I don't know another way ... In JFFS2 you'll probably meet more merging problems. There was an RB-tree rework (special macros were introduced), and you may have troubles compiling JFFS2 because of this. But this is solvable. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From Martin.Krause at tqs.de Thu Aug 3 06:32:10 2006 From: Martin.Krause at tqs.de (Martin Krause) Date: Thu, 3 Aug 2006 12:32:10 +0200 Subject: MPC8xxx UPM NAND Flash In-Reply-To: Message-ID: <47F3F98010FF784EBEE6526EAAB078D1024F81D8@tq-mailsrv.tq-net.de> Hi Harsha, Harsha Padmanabha wrote on Thursday, August 03, 2006 10:19 AM: > Hey Martin, > > I saw your post on the web-board for MTD support. Do you have any > clues or luck using the freescale whitepaper to interface with the > NAND Flash?. We are able to generate the required timing waveforms > but are unable to write to flash or read it back using UPM. Currently we are working on this on a MPC8548 board (TQM8548). Unfortunately I'm not involved in this project, so I don't know much details, but the guys working on this told me, that some basic flash accesses are running already (at a bus clock of 50 MHz). The boot software we use is not U-boot, but our own bootloader "MON85xx", so I couldn't send patches or code snippets. But I hope that U-Boot will be ported for this board too, once everything is running well. Regards, Martin From diva at kondor.imp.bg.ac.yu Thu Aug 3 06:51:37 2006 From: diva at kondor.imp.bg.ac.yu (Iva Salom) Date: Thu, 3 Aug 2006 12:51:37 +0200 Subject: Problem with mounting JFFS2 Message-ID: <001601c6b6ea$cb60f790$c6345b93@VLADIMIR> Hi! I am a beginner in all these embedded linux - mtd - jffs stuff. I am using Intel FLASH 28F320 (2 interleaved 16b chips of 8MB, so we have 32bit buswidth) (CFI) with TMS320C5471 platform. I turnd on MTD support, so I have 5 partitions: bootloader (/dev/mtd0), bootloader parameters (/dev/mtd1), kernel image (/dev/mtd2), ROMFS SDRAM image (/dev/mtd5), primary file system, which is romfs (/dev/mtd3) and I want the second to be jffs2 (/dev/mtd4): c5471_init: CFI FLASH device size: 16384K Creating 5 MTD partitions on "C5471 CFI": 0x00000000-0x000a0000 : "C5471 Bootloader" 0x000a0000-0x000c0000 : "C5471 Bootloader Parameters" 0x000c0000-0x001c0000 : "C5471 Kernel Image" 0x001c0000-0x00800000 : "C5471 Primary File System" 0x00800000-0x01000000 : "C5471 Secondary File System" Creating 1 MTD partitions on "SDRAM": 0x00000000-0x006bffe0 : "SDRAM File System" I have made jffs2 image: arm-uclinux-mkjffs2 -d ./jffsfolder -l -e 0x00020000 -o jffs2.img >/dev/null and I loaded it at addresses from 0x00800000, which correspond to fs2, i.e. /dev/mtd4. When I try to mount jffs2: # mount -t jffs2 /dev/mtd4 /mnt/ramdisk/tmp it sends me messages: jffs2: read_super for device 1f:04 jffs2_scan_eraseblock(): Scanning block at 0x0 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0xface instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004: 0x0020 instead Empty bitmask at 0x00000008 jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c: 0x5188 instead jffs2_scan_dirent_node(): Node at 0x00000010 jffs2_get_ino_cache(): ino 1 jffs2_get_ino_cache found 00000000 for ino 1 Allocated inocache at 106dd2c0 jffs2_add_ino_cache: Add 106dd2c0 (ino #1) jffs2_add_fd_to_list( 1023f6a0, 10219e60 (->00000000)) Dirent "config.last" (hash 0xca144fa2, ino #2 jffs2_scan_inode_node(): Node at 0x00000044 jffs2_get_ino_cache(): ino 2 jffs2_get_ino_cache found 00000000 for ino 2 Allocated inocache at 106dd2d4 jffs2_add_ino_cache: Add 106dd2d4 (ino #2) Node is ino #2, version 1. Range 0x0-0x1000 jffs2_scan_inode_node(): Node at 0x00001088 jffs2_get_ino_cache(): ino 2 jffs2_get_ino_cache found 106dd2d4 for ino 2 Node is ino #2, version 2. Range 0x1000-0x2000 jffs2_scan_inode_node(): Node at 0x000020cc jffs2_get_ino_cache(): ino 2 jffs2_get_ino_cache found 106dd2d4 for ino 2 Node is ino #2, version 3. Range 0x2000-0x27c4 jffs2_scan_dirent_node(): Node at 0x000028d4 jffs2_get_ino_cache(): ino 1 jffs2_get_ino_cache found 106dd2c0 for ino 1 jffs2_add_fd_to_list( 1023f6e0, 10219e60 (->1023f6a0)) Dirent "config.last~" (hash 0xaedfc2e3, ino #3 Dirent "config.last" (hash 0xca144fa2, ino #2 jffs2_scan_inode_node(): Node at 0x00002908 jffs2_get_ino_cache(): ino 3 jffs2_get_ino_cache found 00000000 for ino 3 Allocated inocache at 106dd2e8 jffs2_add_ino_cache: Add 106dd2e8 (ino #3) Node is ino #3, version 1. Range 0x0-0x1000 jffs2_scan_inode_node(): Node at 0x0000394c jffs2_get_ino_cache(): ino 3 jffs2_get_ino_cache found 106dd2e8 for ino 3 Node is ino #3, version 2. Range 0x1000-0x2000 jffs2_scan_inode_node(): Node at 0x00004990 jffs2_get_ino_cache(): ino 3 jffs2_get_ino_cache found 106dd2e8 for ino 3 Node is ino #3, version 3. Range 0x2000-0x27c4 Found empty flash at 0x5198 Empty flash detected from 0x00005198 to 0x00020000 Block at 0x00000000: free 0x0001ae68, dirty 0x00000010, used 0x00005188 jffs2_scan_eraseblock(): Scanning block at 0x20000 Empty flash detected from 0x00020000 to 0x00040000 Block at 0x00020000 is empty (erased) jffs2_scan_eraseblock(): Scanning block at 0x40000 Empty flash detected from 0x00040000 to 0x00060000 Block at 0x00040000 is empty (erased) jffs2_scan_eraseblock(): Scanning block at 0x60000 Empty flash detected from 0x00060000 to 0x00080000 Block at 0x00060000 is empty (erased) etc., and finally: Pass 3 complete jffs2_read_super(): Getting root inode jffs2_read_inode(): inode->i_ino == 1 getting inocache jffs2_get_ino_cache(): ino 1 jffs2_get_ino_cache found 106dd2c0 for ino 1 jffs2_read_inode(): Got inocache at 106dd2c0 jffs2_read_inode(): ino #1 nlink is 1 jffs2_get_inode_nodes(): ino #1 Node at 000028d4 is a dirent node Adding fd "config.last~", ino #3 jffs2_add_fd_to_list( 1023f6a0, 10707d14 (->00000000)) Dirent "config.last~" (hash 0xaedfc2e3, ino #3 Node at 00000010 is a dirent node Adding fd "config.last", ino #2 jffs2_add_fd_to_list( 1023f6e0, 10707d14 (->1023f6a0)) Dirent "config.last~" (hash 0xaedfc2e3, ino #3 Dirent "config.last" (hash 0xca144fa2, ino #2 jffs2_read_inode() returning jffs2_read_super(): d_alloc_root() thread_should_wake(): nr_free_blocks 0, nr_erasing_blocks 63, dirty_size 0x10 thread_should_wake(): return 0 jffs2_garbage_collect_thread(): posle !thread_should_wake jffs2_garbage_collect_thread sleeping... JFFS2: Garbage collect thread is pid 37 jffs2_read_super(): pre return sb thread_should_wake(): nr_free_blocks 0, nr_erasing_blocks 63, dirty_size 0x10 thread_should_wake(): return 0 Starting erase of pending block 0x00620000 Freeing all node refs for eraseblock offset 0x00620000 erase.c: jffs2_free_all_node_refs(): end jffs2_erase_pending_blocks(): TEST1 jffs2_erase_pending_blocks(): TEST2 jffs2_erase_block(): TEST1 jffs2_erase_block(): TEST2 jffs2_erase_block(): TEST3 do_erase_oneblock(): status_OK = CMD(0x80) = 0x800080 do_erase_oneblock(): chip->state1 = 0 do_erase_oneblock(): chip->state2 = 1 do_erase_o and there it stops every time, with a few characters more or less. The situation was similar when I erased my flash before mounting the jffs2 (except it found completely empty flash). Have enyone an idea what I did wrong or what I missed to do? Could a problem be with that thread thing - thread_should_wake()? Thank you in advance! Iva -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.infradead.org/pipermail/linux-mtd/attachments/20060803/04f49881/attachment.html From jwboyer at gmail.com Thu Aug 3 07:53:07 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 3 Aug 2006 06:53:07 -0500 Subject: Problem with mounting JFFS2 In-Reply-To: <001601c6b6ea$cb60f790$c6345b93@VLADIMIR> References: <001601c6b6ea$cb60f790$c6345b93@VLADIMIR> Message-ID: <625fc13d0608030453u54cc12b2nf9aca1609148d07e@mail.gmail.com> On 8/3/06, Iva Salom wrote: > > > Hi! > > I am a beginner in all these embedded linux - mtd - jffs stuff. I am using > Intel FLASH 28F320 (2 interleaved 16b chips of 8MB, so we have 32bit > buswidth) (CFI) with TMS320C5471 platform. I turnd on MTD support, so I have > 5 partitions: bootloader (/dev/mtd0), bootloader parameters (/dev/mtd1), > kernel image (/dev/mtd2), ROMFS SDRAM image (/dev/mtd5), primary file > system, which is romfs (/dev/mtd3) and I want the second to be jffs2 > (/dev/mtd4): Which kernel are you using? > I have made jffs2 image: > > arm-uclinux-mkjffs2 -d ./jffsfolder -l -e 0x00020000 -o jffs2.img >/dev/null > > and I loaded it at addresses from 0x00800000, which correspond to fs2, i.e. > /dev/mtd4. Loaded it how? josh From jwboyer at gmail.com Thu Aug 3 08:22:39 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 3 Aug 2006 07:22:39 -0500 Subject: autoconf for mtd-utils In-Reply-To: <625fc13d0608020400w307e5e77s40f4aa604c0e4395@mail.gmail.com> References: <000001c6b5a0$3a0a5bb0$c834800a@RudiDell> <625fc13d0608020400w307e5e77s40f4aa604c0e4395@mail.gmail.com> Message-ID: <625fc13d0608030522g1495c843q3ae23e4db7252c2f@mail.gmail.com> On 8/2/06, Josh Boyer wrote: > On 8/1/06, David Byron wrote: > > I do define BUILDDIR for native builds too, but to the current directory. > > The important thing for me is that native objects live in a different place > > than cross-compiled objects. Where they are relative to the source isn't > > important to me at the moment. > > This looks OK to me. dwmw2, do you have any issues with this? I've committed this patch. Thanks again David. josh From takasi-y at ops.dti.ne.jp Thu Aug 3 09:28:18 2006 From: takasi-y at ops.dti.ne.jp (takasi-y at ops.dti.ne.jp) Date: Thu, 3 Aug 2006 22:28:18 +0900 Subject: [PATCH] PHYSMAP depens on CFI or JEDECPROBE or ROM Message-ID: <20060803222818.7f8f0286.takasi-y@ops.dti.ne.jp> Hi, map/physmap.c tries to probe "cfi_probe", "jedec_probe" and "map_rom", but map/Kconfig says it depends on MTD_CFI only. Here is the fix. # I think description should be rewritten by someone who speak real english, though. /yoshii Index: drivers/mtd/maps/Kconfig =================================================================== RCS file: /home/cvs/mtd/drivers/mtd/maps/Kconfig,v retrieving revision 1.69 diff -u -p -r1.69 Kconfig --- drivers/mtd/maps/Kconfig 28 Mar 2006 16:15:53 -0000 1.69 +++ drivers/mtd/maps/Kconfig 3 Aug 2006 13:22:08 -0000 @@ -13,13 +13,13 @@ config MTD_COMPLEX_MAPPINGS config MTD_PHYSMAP tristate "CFI Flash device in physical memory map" - depends on MTD_CFI + depends on MTD_CFI || MTD_JEDECPROBE || MTD_ROM help - This provides a 'mapping' driver which allows the CFI probe and - command set driver code to communicate with flash chips which - are mapped physically into the CPU's memory. You will need to - configure the physical address and size of the flash chips on - your particular board as well as the bus width, either statically + This provides a 'mapping' driver which allows the NOR Flash and + ROM driver code to communicate with chips which are mapped + physically into the CPU's memory. You will need to configure + the physical address and size of the flash chips on your + particular board as well as the bus width, either statically with config options or at run-time. config MTD_PHYSMAP_START From takasi-y at ops.dti.ne.jp Thu Aug 3 09:39:36 2006 From: takasi-y at ops.dti.ne.jp (takasi-y at ops.dti.ne.jp) Date: Thu, 3 Aug 2006 22:39:36 +0900 Subject: [PATCH] Mcronix MX29F040 support. Message-ID: <20060803223936.87040059.takasi-y@ops.dti.ne.jp> Hi, I've got new board which has MX29F040, Macroix's NOR Flash on it. I'm now struggling to put kernel and userland into it. Could you(who? Mr. dwmw2?) add this one, please? /yoshii Index: drivers/mtd/chips/jedec_probe.c =================================================================== RCS file: /home/cvs/mtd/drivers/mtd/chips/jedec_probe.c,v retrieving revision 1.68 diff -u -p -r1.68 jedec_probe.c --- drivers/mtd/chips/jedec_probe.c 29 Mar 2006 08:42:49 -0000 1.68 +++ drivers/mtd/chips/jedec_probe.c 3 Aug 2006 13:31:52 -0000 @@ -112,6 +112,7 @@ #define MX29LV040C 0x004F #define MX29LV160T 0x22C4 #define MX29LV160B 0x2249 +#define MX29F040 0x00A4 #define MX29F016 0x00AD #define MX29F002T 0x00B0 #define MX29F004T 0x0045 @@ -1173,6 +1174,19 @@ static const struct amd_flash_info jedec } }, { .mfr_id = MANUFACTURER_MACRONIX, + .dev_id = MX29F040, + .name = "Macronix MX29F040", + .uaddr = { + [0] = MTD_UADDR_0x0555_0x02AA /* x8 */ + }, + .DevSize = SIZE_512KiB, + .CmdSet = P_ID_AMD_STD, + .NumEraseRegions= 1, + .regions = { + ERASEINFO(0x10000,8), + } + }, { + .mfr_id = MANUFACTURER_MACRONIX, .dev_id = MX29F016, .name = "Macronix MX29F016", .uaddr = { From jwboyer at gmail.com Thu Aug 3 10:13:29 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 3 Aug 2006 09:13:29 -0500 Subject: [PATCH] Mcronix MX29F040 support. In-Reply-To: <20060803223936.87040059.takasi-y@ops.dti.ne.jp> References: <20060803223936.87040059.takasi-y@ops.dti.ne.jp> Message-ID: <625fc13d0608030713u299085f4l60dbc9169e61b968@mail.gmail.com> On 8/3/06, takasi-y at ops.dti.ne.jp wrote: > Hi, > I've got new board which has MX29F040, Macroix's NOR Flash on it. > I'm now struggling to put kernel and userland into it. > Could you(who? Mr. dwmw2?) add this one, please? This patch (and your other one) need a Signed-off-by: before they can really be included. josh From dedekind at infradead.org Thu Aug 3 10:44:15 2006 From: dedekind at infradead.org (Artem B. Bityutskiy) Date: Thu, 03 Aug 2006 18:44:15 +0400 Subject: Problem with mounting JFFS2 In-Reply-To: <001601c6b6ea$cb60f790$c6345b93@VLADIMIR> References: <001601c6b6ea$cb60f790$c6345b93@VLADIMIR> Message-ID: <1154616255.9457.3.camel@sauron.oktetlabs.ru> Hello Iva, On Thu, 2006-08-03 at 12:51 +0200, Iva Salom wrote: > I am a beginner in all these embedded linux - mtd - jffs stuff. I am > using Intel FLASH 28F320 (2 interleaved 16b chips of 8MB, so we have > 32bit buswidth) (CFI) with TMS320C5471 platform. I turnd on MTD > support, so I have 5 partitions: bootloader (/dev/mtd0), bootloader > parameters (/dev/mtd1), kernel image (/dev/mtd2), ROMFS SDRAM image > (/dev/mtd5), primary file system, which is romfs (/dev/mtd3) and I > want the second to be jffs2 (/dev/mtd4): Sorry, I didn't get it what's the question/problem. The output you provided looks OK. If you don't want all this output - just disable JFFS2 debugging. Or you deliberately enabled it? BTW, your original message included HTML and was not rejected by a mistake. Please, don't send HTML messages. Regards, Artem. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From dedekind at infradead.org Thu Aug 3 11:00:43 2006 From: dedekind at infradead.org (Artem B. Bityutskiy) Date: Thu, 03 Aug 2006 19:00:43 +0400 Subject: "Bad eraseblock" - NAND memory gone bad? (Zaurus, mtdblock) In-Reply-To: <20060801200451.26e54e4e@urania.exp.univie.ac.at> References: <20060801200451.26e54e4e@urania.exp.univie.ac.at> Message-ID: <1154617243.9457.16.camel@sauron.oktetlabs.ru> Hello Jan, On Tue, 2006-08-01 at 20:04 +0200, Jan Korger wrote: > Not working "properly" means the device does boot but the GUI (GPE 2.7, > X) is not usable (various minor issues, could be due to lost > configuration data). I can however manage to get a text console with > bash and friends. I saved the output from 'dmesg' after a reboot: > http://www.oesf.org/forums/index.php?act=Attach&type=post&id=2744 Hmm, I don't see any MTD/JFFS2-related message there. > The interesting part, which makes me think I may have a NAND problem, is > this: > > NAND device: Manufacturer ID: 0xec, Chip ID: 0x79 (Samsung NAND 128MiB > 3,3V 8-bit) > Scanning device for bad blocks > Bad eraseblock 32 at 0x00080000 > Bad eraseblock 3095 at 0x0305c000 > Bad eraseblock 3099 at 0x0306c000 Well, few bad eraseblocks is normal for NANDs. And the message looks OK. > I understand that NAND chips usually have a few badblocks from the very > beginning, i.e. when they leave the manufacturer, and that NAND wears > out after c. 100'000 write/erase cycles. How can I tell the difference? > Are these worn out NAND blocks and -- if yes -- does this mean I have > already reached the end of the NAND's lifetime? Yeah, and more bad eraseblocks may appear with time. Unfortunately, with MTD/JFFS2 you cannot say how worn-out are your eraseblock. And it'll hardly help if I say that UBI - a new system - does provide this information as it stores erase-counters. But this is more for UBI advertising/promotion. > The only test I did was running md5sum on /dev/mtdblock? (where ? is 0 > to 3). For mtdblock1 and mtdblock2 I saw "IO errors", these are the > first two partions on the NAND chip in question, i.e. the kernel > ("System area") and the "Root Filesystem". This is exactly where the > badblocks as seen above are. (JFTR, I think mtdblock0 refers to another > ROM.) AFAIR mtdblock was not bad-block aware, so it may try accessing bad eraseblocks. So it's all-right. > If possible, I want to get the Zaurus back to a usable state. I have > backed up my data but I don't want to experiment too much for not to > make things worse. There are three options to operate on the > built-in NAND: (I don't want to disassamble it. I don't have suitable > tools anyways.) One theory what could happen is that a new bad eraseblock appeared and you lost you data. JFFS2 is bad-block aware (in theory) and one of those 3 bad eraseblocks could be marked bad by JFFS2. Probably, if you re-flash your gizmo, it'll be fine - but this is just my guess. Ideally, it would be nice to run a flash I/O test which would examine your flash, find&mark new bad eraseblock before. But I don't know such a tool. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From mitsy12 at gmail.com Thu Aug 3 15:05:05 2006 From: mitsy12 at gmail.com (mitsy) Date: Thu, 3 Aug 2006 15:05:05 -0400 Subject: NAND flash writeb fails Message-ID: I have a AMD au1550 based board with NAND flash. When I try to write a command to the flash, it just hangs on writeb(). I can't figure out why it hangs there. Any suggestions? Mitsy From sshtylyov at ru.mvista.com Thu Aug 3 15:10:36 2006 From: sshtylyov at ru.mvista.com (Sergei Shtylyov) Date: Thu, 03 Aug 2006 23:10:36 +0400 Subject: NAND flash writeb fails In-Reply-To: References: Message-ID: <44D24A2C.2070002@ru.mvista.com> Hello, you wrote: > I have a AMD au1550 based board with NAND flash. When I try to write a > command to the flash, it just hangs on writeb(). I can't figure out > why it hangs there. Any suggestions? First off, what driver and kernel verison you're using? > Mitsy WBR, Sergei From takasi-y at ops.dti.ne.jp Thu Aug 3 18:25:00 2006 From: takasi-y at ops.dti.ne.jp (takasi-y at ops.dti.ne.jp) Date: Fri, 4 Aug 2006 07:25:00 +0900 Subject: [PATCH] Mcronix MX29F040 support. In-Reply-To: <625fc13d0608030713u299085f4l60dbc9169e61b968@mail.gmail.com> References: <20060803223936.87040059.takasi-y@ops.dti.ne.jp> <625fc13d0608030713u299085f4l60dbc9169e61b968@mail.gmail.com> Message-ID: <20060804072500.a0ad58a6.takasi-y@ops.dti.ne.jp> Thank you, josh. I'd missunderstood thet the line is added certified(?) people. /yoshii Signed-off-by: Takashi YOSHII Index: drivers/mtd/chips/jedec_probe.c =================================================================== RCS file: /home/cvs/mtd/drivers/mtd/chips/jedec_probe.c,v retrieving revision 1.68 diff -u -p -r1.68 jedec_probe.c --- drivers/mtd/chips/jedec_probe.c 29 Mar 2006 08:42:49 -0000 1.68 +++ drivers/mtd/chips/jedec_probe.c 3 Aug 2006 13:31:52 -0000 @@ -112,6 +112,7 @@ #define MX29LV040C 0x004F #define MX29LV160T 0x22C4 #define MX29LV160B 0x2249 +#define MX29F040 0x00A4 #define MX29F016 0x00AD #define MX29F002T 0x00B0 #define MX29F004T 0x0045 @@ -1173,6 +1174,19 @@ static const struct amd_flash_info jedec } }, { .mfr_id = MANUFACTURER_MACRONIX, + .dev_id = MX29F040, + .name = "Macronix MX29F040", + .uaddr = { + [0] = MTD_UADDR_0x0555_0x02AA /* x8 */ + }, + .DevSize = SIZE_512KiB, + .CmdSet = P_ID_AMD_STD, + .NumEraseRegions= 1, + .regions = { + ERASEINFO(0x10000,8), + } + }, { + .mfr_id = MANUFACTURER_MACRONIX, .dev_id = MX29F016, .name = "Macronix MX29F016", .uaddr = { From diva at kondor.imp.bg.ac.yu Fri Aug 4 03:52:07 2006 From: diva at kondor.imp.bg.ac.yu (Iva Salom) Date: Fri, 4 Aug 2006 09:52:07 +0200 Subject: Problem with mounting JFFS2 References: <001601c6b6ea$cb60f790$c6345b93@VLADIMIR> <625fc13d0608030453u54cc12b2nf9aca1609148d07e@mail.gmail.com> Message-ID: <002901c6b79a$e23af8c0$c6345b93@VLADIMIR> ----- Original Message ----- From: "Josh Boyer" To: "Iva Salom" Cc: Sent: Thursday, August 03, 2006 1:53 PM Subject: Re: Problem with mounting JFFS2 > On 8/3/06, Iva Salom wrote: >> >> >> Hi! >> >> I am a beginner in all these embedded linux - mtd - jffs stuff. I am >> using >> Intel FLASH 28F320 (2 interleaved 16b chips of 8MB, so we have 32bit >> buswidth) (CFI) with TMS320C5471 platform. I turnd on MTD support, so I >> have >> 5 partitions: bootloader (/dev/mtd0), bootloader parameters (/dev/mtd1), >> kernel image (/dev/mtd2), ROMFS SDRAM image (/dev/mtd5), primary file >> system, which is romfs (/dev/mtd3) and I want the second to be jffs2 >> (/dev/mtd4): > > Which kernel are you using? It's uClinux 2.4. >> I have made jffs2 image: >> >> arm-uclinux-mkjffs2 -d ./jffsfolder -l -e 0x00020000 -o jffs2.img >> >/dev/null >> >> and I loaded it at addresses from 0x00800000, which correspond to fs2, >> i.e. >> /dev/mtd4. > > Loaded it how? I used rrload "Load" and "Store" options, and when I checked the flash everything looked ok, it also had those jffs2 magic 0x1985 words at some places, so I thought that I did that part right. > josh Thanks! Iva From diva at kondor.imp.bg.ac.yu Fri Aug 4 04:20:18 2006 From: diva at kondor.imp.bg.ac.yu (Iva Salom) Date: Fri, 4 Aug 2006 10:20:18 +0200 Subject: Fw: Problem with mounting JFFS2 Message-ID: <004101c6b79e$d241a0f0$c6345b93@VLADIMIR> ----- Original Message ----- From: "Artem B. Bityutskiy" To: "Iva Salom" Cc: Sent: Thursday, August 03, 2006 4:44 PM Subject: Re: Problem with mounting JFFS2 Hi Artem! > Hello Iva, > > On Thu, 2006-08-03 at 12:51 +0200, Iva Salom wrote: >> I am a beginner in all these embedded linux - mtd - jffs stuff. I am >> using Intel FLASH 28F320 (2 interleaved 16b chips of 8MB, so we have >> 32bit buswidth) (CFI) with TMS320C5471 platform. I turnd on MTD >> support, so I have 5 partitions: bootloader (/dev/mtd0), bootloader >> parameters (/dev/mtd1), kernel image (/dev/mtd2), ROMFS SDRAM image >> (/dev/mtd5), primary file system, which is romfs (/dev/mtd3) and I >> want the second to be jffs2 (/dev/mtd4): > > Sorry, I didn't get it what's the question/problem. The output you > provided looks OK. If you don't want all this output - just disable > JFFS2 debugging. Or you deliberately enabled it? Yes, I enabled it because the first time I tried to mount jffs2 it just stoped without any message. I hopped that I will get some warning or something but it just stops each time at the same point and all those messages didn't help me a lot. As I understood, there are several threads running, so using my TEST outputs I found 3 functions where it stops but, I would say, with no reason. So I expect that something else is the problem, maybe something I haven't enabled? > BTW, your original message included HTML and was not rejected by a > mistake. Please, don't send HTML messages. Sorry, it was my first time, now I think I know what was the mistaque. > Regards, > Artem. Thanks! Iva From komal_shah802003 at yahoo.com Fri Aug 4 07:33:26 2006 From: komal_shah802003 at yahoo.com (Komal Shah) Date: Fri, 04 Aug 2006 17:03:26 +0530 Subject: [PATCH] OMAP: Add TI OMAP242x H4 EVM NOR flash support. Message-ID: <1154691206.14227.267630051@webmail.messagingengine.com> Attached patch adds support for TI OMAP242x based H4 EVM board NOR flash support. Please review it and give the ack if it is OK. PS: Trying lkml this time, as my e-mail id is not considered "good" for linux-mtd :( ---Komal Shah http://komalshah.blogspot.com -- http://www.fastmail.fm - The way an email service should be -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-OMAP-Add-TI-OMAP242x-NOR-Flash.patch Type: application/octet-stream Size: 1158 bytes Desc: not available Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20060804/57df5e95/attachment.obj From takasi-y at ops.dti.ne.jp Fri Aug 4 10:08:02 2006 From: takasi-y at ops.dti.ne.jp (takasi-y at ops.dti.ne.jp) Date: Fri, 4 Aug 2006 23:08:02 +0900 Subject: [PATCH] PHYSMAP depens on CFI or JEDECPROBE or ROM In-Reply-To: <20060803222818.7f8f0286.takasi-y@ops.dti.ne.jp> References: <20060803222818.7f8f0286.takasi-y@ops.dti.ne.jp> Message-ID: <20060804230802.80dc086b.takasi-y@ops.dti.ne.jp> # posting it agein. map/physmap.c tries to probe "cfi_probe", "jedec_probe" and "map_rom", but map/Kconfig says it depends on MTD_CFI only. This patch adds MTD_JEDECPROBE and MTD_ROM to the dependency condition. Signed-off-by: Takashi YOSHII --- Index: drivers/mtd/maps/Kconfig =================================================================== RCS file: /home/cvs/mtd/drivers/mtd/maps/Kconfig,v retrieving revision 1.69 diff -u -p -r1.69 Kconfig --- drivers/mtd/maps/Kconfig 28 Mar 2006 16:15:53 -0000 1.69 +++ drivers/mtd/maps/Kconfig 4 Aug 2006 14:00:58 -0000 @@ -13,13 +13,13 @@ config MTD_COMPLEX_MAPPINGS config MTD_PHYSMAP tristate "CFI Flash device in physical memory map" - depends on MTD_CFI + depends on MTD_CFI || MTD_JEDECPROBE || MTD_ROM help - This provides a 'mapping' driver which allows the CFI probe and - command set driver code to communicate with flash chips which - are mapped physically into the CPU's memory. You will need to - configure the physical address and size of the flash chips on - your particular board as well as the bus width, either statically + This provides a 'mapping' driver which allows the NOR Flash and + ROM driver code to communicate with chips which are mapped + physically into the CPU's memory. You will need to configure + the physical address and size of the flash chips on your + particular board as well as the bus width, either statically with config options or at run-time. config MTD_PHYSMAP_START From mitsy12 at gmail.com Fri Aug 4 13:13:42 2006 From: mitsy12 at gmail.com (mitsy) Date: Fri, 4 Aug 2006 13:13:42 -0400 Subject: NAND flash writeb fails In-Reply-To: <44D24A2C.2070002@ru.mvista.com> References: <44D24A2C.2070002@ru.mvista.com> Message-ID: Sergei, Thank you for replying. Now I looked at for a while, I believe my problem was that I didn't set up TLB in the bootloader correctly. That's why the nand flash works with kernel (2.4.26) but not from my bootloader. I just need to figure out what is wrong with my TLB setup. Mitsy On 8/3/06, Sergei Shtylyov wrote: > Hello, you wrote: > > > I have a AMD au1550 based board with NAND flash. When I try to write a > > command to the flash, it just hangs on writeb(). I can't figure out > > why it hangs there. Any suggestions? > > First off, what driver and kernel verison you're using? > > > Mitsy > > WBR, Sergei > From Kevin.Bradway at i-o.com Fri Aug 4 13:57:32 2006 From: Kevin.Bradway at i-o.com (Kevin Bradway) Date: Fri, 4 Aug 2006 12:57:32 -0500 Subject: 8gig multiCell nand parts Message-ID: <20CD42856DE21B48BC209EC1CBA00FB902B41976@STAFEXVS03.ioinc.ioroot.tld> I need help trying to get 8/16 gig multicell (mlc) Micron/Samsung parts working properly. I am using JFFS2. Both cells are always getting written?? They are duplicated. I have 4 partitions Starting at offset 0 and then using the MTDPART_OFS_APPEND with size 0x10000000. The mlc parts require 2 CE#'s. One for each cell. I have used the "number of chips" in the option of the nand driver. This shows that the proper chip select is being selected but both cells still get written too. I have verified that the right chip select is set when the page address rolls past the page mask. I have verified the PLD addressing. Any ideas would be helpful. This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original. From jwboyer at gmail.com Fri Aug 4 14:18:18 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 4 Aug 2006 13:18:18 -0500 Subject: 8gig multiCell nand parts In-Reply-To: <20CD42856DE21B48BC209EC1CBA00FB902B41976@STAFEXVS03.ioinc.ioroot.tld> References: <20CD42856DE21B48BC209EC1CBA00FB902B41976@STAFEXVS03.ioinc.ioroot.tld> Message-ID: <625fc13d0608041118q9a71de3ud82f908dab6c0b04@mail.gmail.com> On 8/4/06, Kevin Bradway wrote: > Any ideas would be helpful. > > This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original. This disclaimer will not win you any points. It should not be used on a mailing list such as this. I therefore assume that I have received this email in error and am notifying you and have deleted the original. josh From dufkaf at seznam.cz Sun Aug 6 04:52:14 2006 From: dufkaf at seznam.cz (Frantisek Dufka) Date: Sun, 06 Aug 2006 10:52:14 +0200 Subject: nandwrite -j -f made all flashed blocks bad (twice) Message-ID: <44D5ADBE.7090704@seznam.cz> Hello, I played few times with nandwrite and two times with flash_eraseall on mtd3 partition on my device and later found my mtd3 partition grew from 2MB to 5MB (and overflowed into mtd4 partition and made it shorter) having now 3MB of bad blocks. Hardware is Nokia 770 (http://www.nokia.com/770 http://www.maemo.org) - OMAP1710 based device with omap-hw-nand: OMAP NAND Controller rev. 1.1 and NAND device: Manufacturer ID: 0xec, Chip ID: 0xa1 (Samsung NAND 128MiB 1,8V 8-bit) This device has binary only flasher executable which can flash mtd partitions from PC over USB. I tried to find another way and flash device directly from itself by using nandwrite and flash_erasall compiled from mtd utils 1.0 source. I did read the documentation and FAQ at www.linux-mtd.infradead.org but looks like I still screwed something. I tried to flash 1574084 bytes long jffs2 image made by 'mkfs.jffs2 -r initfs -o initfs.bootmenu.jffs2 -e 128 -l -n' command to 2MB big partition /dev/mtd3. First I tried 'nandwrite /dev/mtd3 initfs.bootmenu.jffs2' without any error but the result did not boot. So I flashed it over USB with proprietary flasher and it worked. Then I tried nandwrite -j -f since it is jffs2 image and previous attempt failed. I had to use -f with -j otherwise it didn't work. This did not boot too so I again flashed it over USB to make it working. Then I found in mailing list that I should use flash_eraseall before using nandwrite http://lists.infradead.org/pipermail/linux-mtd/2005-February/012040.html So I tried 'flash_eraseall -j /dev/mtd3' and saw Nokia770-26:~# ./flash_eraseall -j /dev/mtd3 Skipping bad block at 0x00000000 Erasing 128 Kibyte @ 20000 -- 3 % complete. Cleanmarker written at 20000. Skipping bad block at 0x00040000 Skipping bad block at 0x00060000 Skipping bad block at 0x00080000 Skipping bad block at 0x000a0000 Skipping bad block at 0x000c0000 Skipping bad block at 0x000e0000 Skipping bad block at 0x00100000 Skipping bad block at 0x00120000 Skipping bad block at 0x00140000 Skipping bad block at 0x00160000 Skipping bad block at 0x00180000 Erasing 128 Kibyte @ 360000 -- 96 % complete. Cleanmarker written at 360000. This is the first time I found there is something seriously wrong but don't know when those (1.5MB of) bad blocks were made. Either by using nandwrite before without erasing it or by recovering device with nokia flasher or by using flash_eraseall now. Also dmesg output is interesting [ 14.708068] omap-hw-nand: OMAP NAND Controller rev. 1.1 [ 14.708251] NAND device: Manufacturer ID: 0xec, Chip ID: 0xa1 (Samsung NAND 128MiB 1,8V 8-bit) [ 14.708465] omap-hw-nand: using PSC values 2, 2, 3 [ 14.708557] Scanning device for bad blocks [ 14.709472] Bad eraseblock 20 at 0x00280000 [ 14.709625] Bad eraseblock 22 at 0x002c0000 [ 14.709747] Bad eraseblock 23 at 0x002e0000 [ 14.709838] Bad eraseblock 24 at 0x00300000 [ 14.709960] Bad eraseblock 25 at 0x00320000 [ 14.710083] Bad eraseblock 26 at 0x00340000 [ 14.710205] Bad eraseblock 27 at 0x00360000 [ 14.710327] Bad eraseblock 28 at 0x00380000 [ 14.710449] Bad eraseblock 29 at 0x003a0000 [ 14.710571] Bad eraseblock 30 at 0x003c0000 [ 14.710693] Bad eraseblock 31 at 0x003e0000 [ 14.710815] Bad eraseblock 32 at 0x00400000 [ 14.744750] 5 cmdlinepart partitions found on MTD device omap-nand [ 14.744873] Creating 5 MTD partitions on "omap-nand": [ 14.745025] 0x00000000-0x00020000 : "bootloader" [ 14.746643] 0x00020000-0x00080000 : "config" [ 14.748138] 0x00080000-0x00280000 : "kernel" [ 14.749633] 0x00280000-0x00600000 : "initfs" [ 14.751098] 0x00600000-0x08000000 : "root" I believe before I started to mess with device initfs location was 0x00280000-0x00480000 : "initfs" I tried similar thing again (nandwrite -j,usb flash,flash_eraseall) and ended with exactly same flash_eraseall output now having 3MBytes of bad blocks. Incomplete dmesg output after 2nd attempt: Nokia770-26:~# dmesg 0x00360000 [ 1.985870] Bad eraseblock 28 at 0x00380000 [ 1.985992] Bad eraseblock 29 at 0x003a0000 [ 1.986114] Bad eraseblock 30 at 0x003c0000 [ 1.986236] Bad eraseblock 31 at 0x003e0000 [ 1.986358] Bad eraseblock 32 at 0x00400000 [ 1.986511] Bad eraseblock 34 at 0x00440000 [ 1.986633] Bad eraseblock 35 at 0x00460000 [ 1.986755] Bad eraseblock 36 at 0x00480000 [ 1.986846] Bad eraseblock 37 at 0x004a0000 [ 1.986968] Bad eraseblock 38 at 0x004c0000 [ 1.987091] Bad eraseblock 39 at 0x004e0000 [ 1.987213] Bad eraseblock 40 at 0x00500000 [ 1.987335] Bad eraseblock 41 at 0x00520000 [ 1.987457] Bad eraseblock 42 at 0x00540000 [ 1.987579] Bad eraseblock 43 at 0x00560000 [ 1.987701] Bad eraseblock 44 at 0x00580000 [ 2.021270] 5 cmdlinepart partitions found on MTD device omap-nand [ 2.021423] Creating 5 MTD partitions on "omap-nand": [ 2.021514] 0x00000000-0x00020000 : "bootloader" [ 2.023132] 0x00020000-0x00080000 : "config" [ 2.024627] 0x00080000-0x00280000 : "kernel" [ 2.026153] 0x00280000-0x00780000 : "initfs" [ 2.027587] 0x00780000-0x08000000 : "root" So now the device still works when booting rootfs from MMC card, root mtd4 partition is not booting (the beginning is moved from 0x00480000 to 0x00780000), I have made lot of bad blocks and still don't know how to flash device from itself or what exactly I did wrong. Any ideas? Also is it possible that it didn't work because mtdblock3 is mounted read only and one process is running from it? Since jffs2 is compressed and it is small executable I suppose it is completely in RAM. It cannot be stopped easily and device unmounted. It is some proprietary Nokia stuff that controls hardware (charging,backlight) and also controlls watchdog that reboots device if this or any other vital process dies. What is also puzzling it that eraseblocks 21 and 33 (i.e. block at 0x00020000 when using flash_eraseall both times) are OK. Why? I suppose nandwrite -j -f was the bad thing that made those bad blocks, correct? Any way how can I get those 'bad' blocks back? I suppose they are good but have some wrong data pattern in oob area which makes them bad when scanning. Or are they really bad? Erasing bad block is not possible in current kernel, could commenting out this check in nand_erase_nand kernel source help to reset those block to usable state? Since I screwed it many times I'd like to have some insight from someone more skilled before going any further. Thanks for any helpful tips or ideas. Frantisek From kaigai at kaigai.gr.jp Sat Aug 5 20:54:06 2006 From: kaigai at kaigai.gr.jp (KaiGai Kohei) Date: Sun, 06 Aug 2006 09:54:06 +0900 Subject: [PATCH] Add the latest xattr support on mtd-utils Message-ID: <44D53DAE.5020803@kaigai.gr.jp> Hi, This patch enables to pack xattr informations for _recent_ xattr implementation. When I posted a patch which enables to operate xattr on NAND flash by using delete marker at Jun, the format of xref node was a bit changed. As 'xseqno' was added into struct jffs2_raw_xref, I ought to post a patch to modify it. But I left for posting. Please apply it, Thanks. -- KaiGai Kohei -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jffs2-xattr-v6.2-04-add-xseqno-on-mtdutils.patch Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20060806/0e452b53/attachment.pl From kmnet1 at gmail.com Mon Aug 7 03:56:25 2006 From: kmnet1 at gmail.com (KimM) Date: Mon, 07 Aug 2006 09:56:25 +0200 Subject: JFFS2 Garbage collector on 2.6.16 Message-ID: Hi all I have a question regarding the JFFS2 garbage collector. On my AT91RM9200 system I have a 22 MB JFFS2 RW partition. The mount time is OK, but the problem is that the garbage collector starts to run and locks down the system for additional 60-120 seconds! What happens is: The System boots busybox init rcS runs / is remounted RW I get a login prompt The garbage collector starts/continues to runs I type in login and password The system stalls until the garbage collector finishes. Now, I traced the problem and found that the long runtime of the garbage collector is causes by a few large files on my system (~6MB). While the GC process the inodes of any single file, the FS is locked, which is why my user apps stalls. More specifically, JFFS2 spends it's time in: jffs2_do_read_inode_internal() which is called from: jjffs2_garbage_collect_pass() -> ffs2_do_crccheck_inode() -> jffs2_do_read_inode_internal() Reading the README.Locking explains the GC locking, but I was wondering if this is really desired behaviour, and if there is anything I can do to speed up things. I am not brave enough to just change the locking mechanism...;-) I should mention that I get the same behaviour on 2.6.17.6... BTW: what is the correct mail list for strictly JFFS2 related topics? I tried jffs-dev at axis.com & linux.file-systems.jffs at gmane.org without success... BR Kim From zjiaxue at hotmail.com Mon Aug 7 05:46:27 2006 From: zjiaxue at hotmail.com (dannel) Date: Mon, 7 Aug 2006 17:46:27 +0800 Subject: how to visit nand flash through usb? Message-ID: Hi all I have some questions about through usb visit nand flash,who can have some advice? Now my board run 2.4.24 kernel and had success mount nand flash with yaffs2 filsystems. Best regards dannel From samuel at Update.UU.SE Mon Aug 7 06:42:32 2006 From: samuel at Update.UU.SE (Samuel ]slund) Date: Mon, 7 Aug 2006 12:42:32 +0200 Subject: Bad typecast in flash_eraseall ? Message-ID: <20060807104232.GA27930@Update.UU.SE> Hi, I recently dovnloaded the mtd-utils-1.0.0.tar.gz from www.infradead.org. When running "flash_eraseall" on a Micrel ks8695p I get some wierd output: / # flash_eraseall /dev/mtd1 Erasing 64 Kibyte @ 30000 -- 4294901765 % complete. When I moved the typecast (unsigned long long) at line 155 from before "erase.start" to before "100" : ("\rErasing %d Kibyte @ %x -- %2llu %% complete.", meminfo.erasesize / 1024, erase.start, erase.start * (unsigned long long) 100 / meminfo.size); the output became correct: / # flash_eraseall /dev/mtd1 Erasing 64 Kibyte @ 100000 -- 26 % complete. Seems like a bug, thought you might want to know. //Samuel PS. Sorry if this has been mentioned before, I did google a bit on the list archives but the search interface is not very friendly. DS. From jwboyer at gmail.com Mon Aug 7 07:19:42 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 7 Aug 2006 06:19:42 -0500 Subject: [PATCH] Add the latest xattr support on mtd-utils In-Reply-To: <44D53DAE.5020803@kaigai.gr.jp> References: <44D53DAE.5020803@kaigai.gr.jp> Message-ID: <625fc13d0608070419x556292dek44db8bdc53459886@mail.gmail.com> On 8/5/06, KaiGai Kohei wrote: > Hi, > > This patch enables to pack xattr informations for _recent_ xattr > implementation. > > When I posted a patch which enables to operate xattr on NAND > flash by using delete marker at Jun, the format of xref node > was a bit changed. > As 'xseqno' was added into struct jffs2_raw_xref, I ought to > post a patch to modify it. But I left for posting. > > Please apply it, Thanks. KaiGai-san, The patch looks good, however could you please resend it with a Signed-of-by: line? thx, josh From jwboyer at gmail.com Mon Aug 7 10:17:21 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 7 Aug 2006 09:17:21 -0500 Subject: [PATCH] Add the latest xattr support on mtd-utils In-Reply-To: <44D748E3.2070708@kaigai.gr.jp> References: <44D53DAE.5020803@kaigai.gr.jp> <625fc13d0608070419x556292dek44db8bdc53459886@mail.gmail.com> <44D748E3.2070708@kaigai.gr.jp> Message-ID: <625fc13d0608070717v9a63f68j142d52a994c5d96f@mail.gmail.com> On 8/7/06, KaiGai Kohei wrote: > > KaiGai-san, > > > > The patch looks good, however could you please resend it with a > > Signed-of-by: line? > > OK, I'll resend it with Signed-off-by: line again. Thank you. This has been committed. josh From kaigai at kaigai.gr.jp Mon Aug 7 10:06:27 2006 From: kaigai at kaigai.gr.jp (KaiGai Kohei) Date: Mon, 07 Aug 2006 23:06:27 +0900 Subject: [PATCH] Add the latest xattr support on mtd-utils In-Reply-To: <625fc13d0608070419x556292dek44db8bdc53459886@mail.gmail.com> References: <44D53DAE.5020803@kaigai.gr.jp> <625fc13d0608070419x556292dek44db8bdc53459886@mail.gmail.com> Message-ID: <44D748E3.2070708@kaigai.gr.jp> > KaiGai-san, > > The patch looks good, however could you please resend it with a > Signed-of-by: line? OK, I'll resend it with Signed-off-by: line again. Thanks, [PAATH] Add 'xseqno' into jffs2_raw_xref on mkfs.jffs2 Signed-off-by: KaiGai Kohei -- KaiGai Kohei ^^^^^^^^^^^^^^^^^^^ <- Don't mind. I'm working in my house today. :D -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jffs2-xattr-v6.2-04-add-xseqno-on-mtdutils.patch Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20060807/a2b8612e/attachment.pl From rpurdie at rpsys.net Mon Aug 7 14:41:50 2006 From: rpurdie at rpsys.net (Richard Purdie) Date: Mon, 07 Aug 2006 19:41:50 +0100 Subject: 2.6.18-rc4 jffs2 problems Message-ID: <1154976111.17725.8.camel@localhost.localdomain> I previous reported problems with jffs2 on the Zaurus. I tested 2.6.18-rc4 and nothing has changed - I see the following when booting, both with filesystems that work with 2.6.17 and freshly reflashed systems: Linux version 2.6.18-rc4-.dev-snapshot-20060807 (richard at tim) (gcc version 3.4.3) #1 PREEMPT Mon Aug 7 17:47:07 BST 2006 CPU: XScale-PXA250 [69052904] revision 4 (ARMv5TE), cr=0000397f Machine: SHARP Poodle [...] Sharp SL series flash device: 800000 at 0 Using static partision definition Creating 1 MTD partitions on "sharpsl-flash": 0x00120000-0x007f0000 : "Boot PROM Filesystem" NAND device: Manufacturer ID: 0x98, Chip ID: 0x76 (Toshiba NAND 64MiB 3,3V 8-bit) Scanning device for bad blocks Creating 3 MTD partitions on "sharpsl-nand": 0x00000000-0x00700000 : "System Area" 0x00700000-0x01d00000 : "Root Filesystem" 0x01d00000-0x04000000 : "Home Filesystem" [...] Empty flash at 0x0054bc5c ends at 0x0054be00 VFS: Mounted root (jffs2 filesystem) readonly. Freeing init memory: 100K JFFS2 error: (472) jffs2_get_inode_nodes: short read at 0x074e84: 68 instead of 380. JFFS2 error: (472) jffs2_do_read_inode_internal: cannot read nodes for ino 153, returned error is -5 The empty flash warning is probably due to a slightly corrupted image due to a reboot. The last two messages appear on freshly flashed images on both this and other Zaurus devices (all using nand/sharpsl.c). Experience shows I can lock the device up with filesystem corruption if I use the device :-(. Does anyone know what the problem is or have an idea of where I should start debugging this? Regards, Richard From akpm at osdl.org Tue Aug 8 02:40:10 2006 From: akpm at osdl.org (Andrew Morton) Date: Mon, 7 Aug 2006 23:40:10 -0700 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <1154976111.17725.8.camel@localhost.localdomain> References: <1154976111.17725.8.camel@localhost.localdomain> Message-ID: <20060807234010.f9a281ed.akpm@osdl.org> On Mon, 07 Aug 2006 19:41:50 +0100 Richard Purdie wrote: > I previous reported problems with jffs2 on the Zaurus. I tested > 2.6.18-rc4 and nothing has changed - I see the following when booting, > both with filesystems that work with 2.6.17 and freshly reflashed > systems: > > Linux version 2.6.18-rc4-.dev-snapshot-20060807 (richard at tim) (gcc version 3.4.3) #1 PREEMPT Mon Aug 7 17:47:07 BST 2006 > CPU: XScale-PXA250 [69052904] revision 4 (ARMv5TE), cr=0000397f > Machine: SHARP Poodle > [...] > Sharp SL series flash device: 800000 at 0 > Using static partision definition > Creating 1 MTD partitions on "sharpsl-flash": > 0x00120000-0x007f0000 : "Boot PROM Filesystem" > NAND device: Manufacturer ID: 0x98, Chip ID: 0x76 (Toshiba NAND 64MiB 3,3V 8-bit) > Scanning device for bad blocks > Creating 3 MTD partitions on "sharpsl-nand": > 0x00000000-0x00700000 : "System Area" > 0x00700000-0x01d00000 : "Root Filesystem" > 0x01d00000-0x04000000 : "Home Filesystem" > [...] > Empty flash at 0x0054bc5c ends at 0x0054be00 > VFS: Mounted root (jffs2 filesystem) readonly. > Freeing init memory: 100K > JFFS2 error: (472) jffs2_get_inode_nodes: short read at 0x074e84: 68 instead of 380. > JFFS2 error: (472) jffs2_do_read_inode_internal: cannot read nodes for ino 153, returned error is -5 > > The empty flash warning is probably due to a slightly corrupted image > due to a reboot. The last two messages appear on freshly flashed images > on both this and other Zaurus devices (all using nand/sharpsl.c). > > Experience shows I can lock the device up with filesystem corruption if > I use the device :-(. > > Does anyone know what the problem is or have an idea of where I should > start debugging this? > Nope, but please be sure to take a block-level copy of the filesystem so that you and others can reproduce the problem. From dedekind at yandex.ru Tue Aug 8 03:15:21 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Tue, 08 Aug 2006 11:15:21 +0400 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <1154976111.17725.8.camel@localhost.localdomain> References: <1154976111.17725.8.camel@localhost.localdomain> Message-ID: <44D83A09.6020200@yandex.ru> Richard Purdie wrote: > JFFS2 error: (472) jffs2_get_inode_nodes: short read at 0x074e84: 68 instead of 380. > JFFS2 error: (472) jffs2_do_read_inode_internal: cannot read nodes for ino 153, returned error is -5 > This looks like an MTD problem, not JFFS2. Try to reproduce this on the mtdram flash emulator. Also, please, check if mtd->writesize is correct at your setup (I suppose your flash is NOR and it has to be 1). -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From sharma.amit at samsung.com Tue Aug 8 06:08:18 2006 From: sharma.amit at samsung.com (Amit Kumar Sharma) Date: Tue, 08 Aug 2006 19:08:18 +0900 Subject: JFFS2 file address space operation Message-ID: <001d01c6bad2$928c8920$3d92340c@dsn.sec.samsung.com> Hi I find mmap operation for file failed in JFFS2, I find Jffs2 does not support writepage in JFFS2 file address operation .I would like to know reason for not supporting writepage operation for file address operation. , struct address_space_operations jffs2_file_address_operations = { .readpage = jffs2_readpage, .prepare_write =jffs2_prepare_write, .commit_write = jffs2_commit_write }; Thanks Amit From noodles at earth.li Tue Aug 8 11:39:44 2006 From: noodles at earth.li (Jonathan McDowell) Date: Tue, 8 Aug 2006 16:39:44 +0100 Subject: [MTD] NAND: Fix ams-delta after core conversion Message-ID: <20060808153944.GA8126@earth.li> The recent hwctrl core conversion for MTD NAND devices broke the Amstrad Delta driver. This fixes it up and uses the existing control line defines rather than unclear magic numbers. Signed-Off-By: Jonathan McDowell ----- diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c index d7897dc..a0ba07c 100644 --- a/drivers/mtd/nand/ams-delta.c +++ b/drivers/mtd/nand/ams-delta.c @@ -130,11 +130,13 @@ static void ams_delta_hwcontrol(struct m if (ctrl & NAND_CTRL_CHANGE) { unsigned long bits; - bits = (~ctrl & NAND_NCE) << 2; - bits |= (ctrl & NAND_CLE) << 7; - bits |= (ctrl & NAND_ALE) << 6; + bits = (~ctrl & NAND_NCE) ? AMS_DELTA_LATCH2_NAND_NCE : 0; + bits |= (ctrl & NAND_CLE) ? AMS_DELTA_LATCH2_NAND_CLE : 0; + bits |= (ctrl & NAND_ALE) ? AMS_DELTA_LATCH2_NAND_ALE : 0; - ams_delta_latch2_write(0xC2, bits); + ams_delta_latch2_write(AMS_DELTA_LATCH2_NAND_CLE | + AMS_DELTA_LATCH2_NAND_ALE | + AMS_DELTA_LATCH2_NAND_NCE, bits); } if (cmd != NAND_CMD_NONE) ----- J. -- ] http://www.earth.li/~noodles/ [] "Hand me that solar-powered [ ] PGP/GPG Key @ the.earth.li [] flashlight..." [ ] via keyserver, web or email. [] [ ] RSA: 4DC4E7FD / DSA: 5B430367 [] [ From rpurdie at rpsys.net Tue Aug 8 12:38:28 2006 From: rpurdie at rpsys.net (Richard Purdie) Date: Tue, 08 Aug 2006 17:38:28 +0100 Subject: JFFS2 file address space operation In-Reply-To: <001d01c6bad2$928c8920$3d92340c@dsn.sec.samsung.com> References: <001d01c6bad2$928c8920$3d92340c@dsn.sec.samsung.com> Message-ID: <1155055108.5541.16.camel@localhost.localdomain> On Tue, 2006-08-08 at 19:08 +0900, Amit Kumar Sharma wrote: > I find mmap operation for file failed in JFFS2, I find Jffs2 does not > support writepage in JFFS2 file address operation .I would like to know > reason for not supporting writepage operation for file address operation. JFFS2 supports compression so there often isn't anything you can mmap directly. Richard From sshtylyov at ru.mvista.com Tue Aug 8 12:50:40 2006 From: sshtylyov at ru.mvista.com (Sergei Shtylyov) Date: Tue, 08 Aug 2006 20:50:40 +0400 Subject: [MTD] NAND: Fix ams-delta after core conversion In-Reply-To: <20060808153944.GA8126@earth.li> References: <20060808153944.GA8126@earth.li> Message-ID: <44D8C0E0.9070800@ru.mvista.com> Hello. Jonathan McDowell wrote: > The recent hwctrl core conversion for MTD NAND devices broke the Amstrad > Delta driver. This fixes it up and uses the existing control line > defines rather than unclear magic numbers. Ugh, au1550nd.c also looks broken by this change. No time to fix now though... WBR, Sergei From sshtylyov at ru.mvista.com Tue Aug 8 13:00:33 2006 From: sshtylyov at ru.mvista.com (Sergei Shtylyov) Date: Tue, 08 Aug 2006 21:00:33 +0400 Subject: [MTD] NAND: Fix ams-delta after core conversion In-Reply-To: <44D8C0E0.9070800@ru.mvista.com> References: <20060808153944.GA8126@earth.li> <44D8C0E0.9070800@ru.mvista.com> Message-ID: <44D8C331.8080800@ru.mvista.com> Hello. Sergei Shtylyov wrote: >>The recent hwctrl core conversion for MTD NAND devices broke the Amstrad >>Delta driver. This fixes it up and uses the existing control line >>defines rather than unclear magic numbers. > Ugh, au1550nd.c also looks broken by this change. No time to fix now though... OTOH, it was too hasty conclusion. This driver overrides both select_chip and cmdfunc, so probably not. I'll try it somewhat later for real... WBR, Sergei From sky.9367548 at nctu.edu.tw Wed Aug 9 02:16:27 2006 From: sky.9367548 at nctu.edu.tw (Clare Huang) Date: Wed, 9 Aug 2006 14:16:27 +0800 Subject: JFFS2 support LZO/LZMA compression ??? Message-ID: <031701c6bb7b$5a7d2400$c9010165@ClareHuang> Dear all, I am a newbie of this community~ According to the http://www.inf.u-szeged.hu/jffs2/compression.php, I know BBC could let jffs2 support LZO compression. But the kernel version I used is 2.6.14..... How could I patch the kernel or update the mtd driver to support LZO or LZMA compression ? I try to use CVS or git to get the latest mtd driver..... But I still don't know where to enable the LZO/LZMA support of jffs2 ??? Could anyone help about this ? or which website I could get more information about this question ? Thanks and Best Regards, Clare From noodles at earth.li Wed Aug 9 05:34:19 2006 From: noodles at earth.li (Jonathan McDowell) Date: Wed, 9 Aug 2006 10:34:19 +0100 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <1154976111.17725.8.camel@localhost.localdomain> References: <1154976111.17725.8.camel@localhost.localdomain> Message-ID: <20060809093419.GA14187@earth.li> On Mon, Aug 07, 2006 at 07:41:50PM +0100, Richard Purdie wrote: > I previous reported problems with jffs2 on the Zaurus. I tested > 2.6.18-rc4 and nothing has changed - I see the following when booting, > both with filesystems that work with 2.6.17 and freshly reflashed > systems: > > Linux version 2.6.18-rc4-.dev-snapshot-20060807 (richard at tim) (gcc version 3.4.3) #1 PREEMPT Mon Aug 7 17:47:07 BST 2006 > CPU: XScale-PXA250 [69052904] revision 4 (ARMv5TE), cr=0000397f > Machine: SHARP Poodle > [...] > Sharp SL series flash device: 800000 at 0 > Using static partision definition > Creating 1 MTD partitions on "sharpsl-flash": > 0x00120000-0x007f0000 : "Boot PROM Filesystem" > NAND device: Manufacturer ID: 0x98, Chip ID: 0x76 (Toshiba NAND 64MiB 3,3V 8-bit) > Scanning device for bad blocks > Creating 3 MTD partitions on "sharpsl-nand": > 0x00000000-0x00700000 : "System Area" > 0x00700000-0x01d00000 : "Root Filesystem" > 0x01d00000-0x04000000 : "Home Filesystem" > [...] > Empty flash at 0x0054bc5c ends at 0x0054be00 > VFS: Mounted root (jffs2 filesystem) readonly. > Freeing init memory: 100K > JFFS2 error: (472) jffs2_get_inode_nodes: short read at 0x074e84: 68 instead of 380. > JFFS2 error: (472) jffs2_do_read_inode_internal: cannot read nodes for ino 153, returned error is -5 I'm seeing similar problems on the Amstrad Delta, both with a filesystem that works fine under 2.6.16 and a completely clean fs. Like the Zaurus this is a NAND device. dmesg output (the jffs2 partition is / and never gets fully mounted) is: JFFS2 error: (1) check_node_data: short read at 0x1a14200: 17 instead of 849. JFFS2 error: (1) check_node: check_node_data() returned error: -5. kernel BUG at fs/jffs2/readinode.c:700! Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 817 [#1] Modules linked in: CPU: 0 PC is at __bug+0x40/0x54 LR is at 0x1 pc : [] lr : [<00000001>] Not tainted sp : c0373ab8 ip : 60000093 fp : c0373ac4 r10: c1d16320 r9 : c1d091f4 r8 : c1d1ecd8 r7 : c1d16340 r6 : c1d16340 r5 : fffffffb r4 : 00000000 r3 : 00000000 r2 : 00000000 r1 : 60000013 r0 : 00000001 Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: 317F Table: 10018000 DAC: 00000017 Process swapper (pid: 1, stack limit = 0xc0372250) Stack: (0xc0373ab8 to 0xc0374000) 3aa0: c0373b50 c0373ac8 3ac0: c0103c20 c0025c60 c0020800 c0020800 c1cae0b4 c0373b08 0000050d c0020800 3ae0: 00000000 c0017cd8 c1d1ed58 c0373be0 c0017cc8 c1cd3a00 00000000 c1d16340 3b00: 00000200 c0176354 00000000 00000200 00000000 c0373b30 00000000 c1d16340 3b20: c012f348 c0373b80 c0372000 c0017cc8 c0373b5c c1d11475 000002ab c1cd3ae8 3b40: c1cd3a00 c0373bac c0373b54 c0104520 c0102ee0 00000000 c0373be0 00000000 3b60: c0373b80 c0373b70 c01005dc c00382d4 00000000 c0373c0c c0373b84 c0104258 3b80: c01005b4 c0017cf4 c1cd3800 d8acb8a2 c1d11475 c1cd6914 c0017cf4 c0017cc8 3ba0: c0373c4c c0373bb0 c010abf4 c010432c c1cd3a00 00000013 c1d16340 00000148 3bc0: c00219f8 00000000 00000148 00000000 c02fc40c 00000000 c1cd3a00 c1d115a0 3be0: c0373bfc c0373bf0 c010b8ec c0079958 c0373c1c c0373c00 c009940c c010b8e0 3c00: c1d115a0 c0017cf4 c0372000 000002ab c0373c4c c0373c20 c0099fb4 c0099dc8 3c20: 00000000 c0017cf4 c1cd3800 d8acb8a2 c1d11475 c1cd6914 000002ab c1d11460 3c40: c0373c80 c0373c50 c00fdf6c c010ab84 00000000 c1d14b74 fffffff4 c1cd6914 3c60: c1d14b74 c1d14be4 c0373e94 c0373cc8 c0373cc0 c0373cb0 c0373c84 c008cf6c 3c80: c00fde2c c0364220 00000000 c0373e94 c1d14b74 c0373d00 c1d0cc80 c0373cc0 3ca0: c1d0cc93 c0373cfc c0373cb4 c008dc64 c008cec0 00000000 00000013 00000001 3cc0: c0364220 c1cd6c78 d8acb8a2 0000000d c1d0cc86 00000000 c0373e94 c1d0cc80 3ce0: c0373d00 c1d0cc80 c0373d7c 00000000 c0373d6c c0373d00 c008e2c0 c008d1dc 3d00: c1c1f570 c0364220 c1d14754 c0364220 c1cd6dec 00000101 00000001 00000001 3d20: c007c5ec c1d0cc80 c03a64e0 c0373f00 00000000 ffffff9c 00000001 c0383000 3d40: c0373ef8 00000011 00000000 c03a63a0 00000000 c0373e94 c0372000 c1cd6990 3d60: c0373db8 c0373d70 c008dfb4 c008e240 00000000 c0022738 00000101 c0364220 3d80: c1cd6990 019ff37b 00000004 c025505e c0372000 c0373e94 c0255058 c0373dbc 3da0: 00000001 00000000 c0255058 c0373e28 c0373dbc c008e2c0 c008d1dc c1c1f570 3dc0: c0364220 c1d14754 c0364220 c1cd6dec 00000101 00000001 00000000 c007c5ec 3de0: c0066d68 c03a64e0 c0373f00 00000000 ffffff9c 00000001 c0383000 c0373ef8 3e00: 00000011 00000000 c03a63a0 c0372000 c0255058 c0373e94 00000000 c0373e54 3e20: c0373e2c c008e6bc c008e240 c0373e38 ffffff9c c0255058 00000001 c0373e94 3e40: c029959c c0373f2c c0373e74 c0373e58 c008e820 c008e3a0 c1d26c00 c0255058 3e60: c0299510 c0373e94 c0373e8c c0373e78 c008e884 c008e7dc 00000011 00000000 3e80: c0373f00 c0373e90 c0089814 c008e870 00000011 c1cd6c78 c0364220 c1d14754 3ea0: c0364220 c1cd6dec 00000101 00000001 00000001 c007c5ec c1d0cc80 c03a64e0 3ec0: c0373f00 00000000 ffffff9c 00000001 c0383000 c0373ef8 00000011 00000000 3ee0: c03a63a0 c1d26c00 c0255058 c0299510 fffffff4 c0373f28 c0373f04 c008a8e0 3f00: c00897f4 c0255058 c029959c c0299510 c0373f2c 00000001 c001e598 c0373f90 3f20: c0373f2c c00257d8 c008a8b0 00000000 00000000 00000000 00000000 00000000 3f40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3f60: 00000000 00000000 00000000 00000000 00000000 c02f28c8 c001e598 c0372000 3f80: c001ead4 c0373fa0 c0373f94 c0021070 c00257a8 c0373ff4 c0373fa4 c0021268 3fa0: c0021060 00000001 c0021ec4 c00380b0 00000000 00000000 c002107c c003ef74 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 c0373ff8 c003ef74 c002108c 0a000008 e591300c Backtrace: [] (__bug+0x0/0x54) from [] (jffs2_do_read_inode_internal+0xd50/0x1394) [] (jffs2_do_read_inode_internal+0x0/0x1394) from [] (jffs2_do_read_inode+0x204/0x228) [] (jffs2_do_read_inode+0x0/0x228) from [] (jffs2_read_inode+0x80/0x3b4) [] (jffs2_read_inode+0x0/0x3b4) from [] (jffs2_lookup+0x150/0x19c) [] (jffs2_lookup+0x0/0x19c) from [] (do_lookup+0xbc/0x170) [] (do_lookup+0x0/0x170) from [] (__link_path_walk+0xa98/0x1064) [] (__link_path_walk+0x0/0x1064) from [] (link_path_walk+0x90/0x160) [] (link_path_walk+0x0/0x160) from [] (__link_path_walk+0xde8/0x1064) r7 = C1CD6990 r6 = C0372000 r5 = C0373E94 r4 = 00000000 [] (__link_path_walk+0x0/0x1064) from [] (link_path_walk+0x90/0x160) [] (link_path_walk+0x0/0x160) from [] (do_path_lookup+0x32c/0x354) r7 = 00000000 r6 = C0373E94 r5 = C0255058 r4 = C0372000 [] (do_path_lookup+0x0/0x354) from [] (__path_lookup_intent_open+0x54/0x94) [] (__path_lookup_intent_open+0x0/0x94) from [] (path_lookup_open+0x24/0x2c) r7 = C0373E94 r6 = C0299510 r5 = C0255058 r4 = C1D26C00 [] (path_lookup_open+0x0/0x2c) from [] (open_exec+0x30/0xe0) [] (open_exec+0x0/0xe0) from [] (do_execve+0x40/0x1c4) r7 = FFFFFFF4 r6 = C0299510 r5 = C0255058 r4 = C1D26C00 [] (do_execve+0x0/0x1c4) from [] (execve+0x40/0x88) [] (execve+0x0/0x88) from [] (run_init_process+0x20/0x2c) r7 = C001EAD4 r6 = C0372000 r5 = C001E598 r4 = C02F28C8 [] (run_init_process+0x0/0x2c) from [] (init+0x1ec/0x270) [] (init+0x0/0x270) from [] (do_exit+0x0/0x958) Code: 1b005e2a e59f0014 eb005e28 e3a03000 (e5833000) <0>Kernel panic - not syncing: Attempted to kill init! J. -- ] http://www.earth.li/~noodles/ [] I don't know. I'm a dog. [ ] PGP/GPG Key @ the.earth.li [] [ ] via keyserver, web or email. [] [ ] RSA: 4DC4E7FD / DSA: 5B430367 [] [ From noodles at earth.li Thu Aug 10 02:04:09 2006 From: noodles at earth.li (Jonathan McDowell) Date: Thu, 10 Aug 2006 07:04:09 +0100 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <20060809093419.GA14187@earth.li> References: <1154976111.17725.8.camel@localhost.localdomain> <20060809093419.GA14187@earth.li> Message-ID: <20060810060409.GH27094@earth.li> On Wed, Aug 09, 2006 at 10:34:19AM +0100, Jonathan McDowell wrote: > On Mon, Aug 07, 2006 at 07:41:50PM +0100, Richard Purdie wrote: > > I previous reported problems with jffs2 on the Zaurus. I tested > > 2.6.18-rc4 and nothing has changed - I see the following when booting, > > both with filesystems that work with 2.6.17 and freshly reflashed > > systems: > > > > Linux version 2.6.18-rc4-.dev-snapshot-20060807 (richard at tim) (gcc version 3.4.3) #1 PREEMPT Mon Aug 7 17:47:07 BST 2006 > > CPU: XScale-PXA250 [69052904] revision 4 (ARMv5TE), cr=0000397f > > Machine: SHARP Poodle > > [...] > > Sharp SL series flash device: 800000 at 0 > > Using static partision definition > > Creating 1 MTD partitions on "sharpsl-flash": > > 0x00120000-0x007f0000 : "Boot PROM Filesystem" > > NAND device: Manufacturer ID: 0x98, Chip ID: 0x76 (Toshiba NAND 64MiB 3,3V 8-bit) > > Scanning device for bad blocks > > Creating 3 MTD partitions on "sharpsl-nand": > > 0x00000000-0x00700000 : "System Area" > > 0x00700000-0x01d00000 : "Root Filesystem" > > 0x01d00000-0x04000000 : "Home Filesystem" > > [...] > > Empty flash at 0x0054bc5c ends at 0x0054be00 > > VFS: Mounted root (jffs2 filesystem) readonly. > > Freeing init memory: 100K > > JFFS2 error: (472) jffs2_get_inode_nodes: short read at 0x074e84: 68 instead of 380. > > JFFS2 error: (472) jffs2_do_read_inode_internal: cannot read nodes for ino 153, returned error is -5 > > I'm seeing similar problems on the Amstrad Delta, both with a filesystem > that works fine under 2.6.16 and a completely clean fs. Like the Zaurus > this is a NAND device. A "git bisect" is flagging up 8593fbc68b0df1168995de76d1af38eb62fd6b62 as the problem commit: commit 8593fbc68b0df1168995de76d1af38eb62fd6b62 Author: Thomas Gleixner Date: Mon May 29 03:26:58 2006 +0200 [MTD] Rework the out of band handling completely J. -- jid: noodles at jabber.earth.li 101 things you can't have too much of : 25 - email. From sharma.amit at samsung.com Thu Aug 10 04:29:57 2006 From: sharma.amit at samsung.com (Amit Kumar Sharma) Date: Thu, 10 Aug 2006 17:29:57 +0900 Subject: JFFS2 problem Message-ID: <003d01c6bc57$29ba2700$3d92340c@dsn.sec.samsung.com> Hi I am looking for JFFS2 stable version for kernel 2.4, Can u help me because I am facing strange problem. My device size is 187M and JFFS2 creating 2G file on my device. But when I checked same device partition on 2.6 kernel it also show file size 2G "it can not be possible because MTD partition is 187M " SO I run same test program on 2.6 kernel. it stops after creating 187M file size. SO I wonder may it is a problem of JFFS2 version I am using with mvl 2.4.20 kernel. Rgs Amit From kmnet1 at gmail.com Thu Aug 10 04:12:55 2006 From: kmnet1 at gmail.com (KimM) Date: Thu, 10 Aug 2006 10:12:55 +0200 Subject: Dynamic MTD partition tables in Linux Message-ID: Hi all I need support for dynamic MTD partition tables in Linux. Currently there's four ways of doing this: cmdlineparsing, Redboot, ARM way or my own way. For various reasons I won't use the cmdline, so it's either Redboot or ARM, in which case my preference is Redboot since I assume that it's more likely to be maintained in the future. Unfortunately I do not use Redboot, but u-boot, so I have to develop my own tool for writing the partition tables. Of course, there are several ways to go about this, but I prefer a generic Linux tool which can create/modify the partition table. This way I can run the tool on both my host and target and create partitions as images or at runtime. But before I go ahead, I want to get some opinions whether to use the Redboot or ARM tables. And of course, I would very must like to know if a tool already exists...:) Thanks KimM From dedekind at yandex.ru Thu Aug 10 05:25:47 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Thu, 10 Aug 2006 13:25:47 +0400 Subject: Dynamic MTD partition tables in Linux In-Reply-To: References: Message-ID: <44DAFB9B.1040902@yandex.ru> Hello KimM, KimM wrote: > I need support for dynamic MTD partition tables in Linux. Currently there's four > ways of doing this: cmdlineparsing, Redboot, ARM way or my own way. > Please, pay your attention to UBI: http://www.linux-mtd.infradead.org/doc/ubi.html http://www.linux-mtd.infradead.org/faq/ubi.html This is a new technology, so no barand boot-loaders support it yet. But it is completely "dynamic". -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From dedekind at yandex.ru Thu Aug 10 05:27:33 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Thu, 10 Aug 2006 13:27:33 +0400 Subject: Fw: Problem with mounting JFFS2 In-Reply-To: <004101c6b79e$d241a0f0$c6345b93@VLADIMIR> References: <004101c6b79e$d241a0f0$c6345b93@VLADIMIR> Message-ID: <44DAFC05.8020506@yandex.ru> Hello Iva, Iva Salom wrote: > Yes, I enabled it because the first time I tried to mount jffs2 it just > stoped without any message. I hopped that I will get some warning or > something but it just stops each time at the same point and all those > messages didn't help me a lot. As I understood, there are several threads > running, so using my TEST outputs I found 3 functions where it stops but, I > would say, with no reason. So I expect that something else is the problem, > maybe something I haven't enabled? > Well, I really have no idea what is this, sorry. I'd suggest you to debug this yourself or to try a newer kernel/MTD. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From dedekind at yandex.ru Thu Aug 10 05:29:51 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Thu, 10 Aug 2006 13:29:51 +0400 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <20060810060409.GH27094@earth.li> References: <1154976111.17725.8.camel@localhost.localdomain> <20060809093419.GA14187@earth.li> <20060810060409.GH27094@earth.li> Message-ID: <44DAFC8F.1020708@yandex.ru> Hello Jonathan, Jonathan McDowell wrote: > commit 8593fbc68b0df1168995de76d1af38eb62fd6b62 > Author: Thomas Gleixner > Date: Mon May 29 03:26:58 2006 +0200 > > [MTD] Rework the out of band handling completely > Oh, there was a major re-work in NAND subsystem. I'd suggest you to dig this yourself or to wait when Thomas has come back and look at this. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From dedekind at yandex.ru Thu Aug 10 05:32:35 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Thu, 10 Aug 2006 13:32:35 +0400 Subject: JFFS2 problem In-Reply-To: <003d01c6bc57$29ba2700$3d92340c@dsn.sec.samsung.com> References: <003d01c6bc57$29ba2700$3d92340c@dsn.sec.samsung.com> Message-ID: <44DAFD33.4060104@yandex.ru> Hello Amit, Amit Kumar Sharma wrote: > I am looking for JFFS2 stable version for kernel 2.4, Can u help me because > I am facing strange problem. My device size is 187M and JFFS2 creating 2G > file on my device. But when I checked same device partition on 2.6 kernel it > also show file size 2G "it can not be possible because MTD partition is 187M > " SO I run same test program on 2.6 kernel. it stops after creating 187M > file size. SO I wonder may it is a problem of JFFS2 version I am using with > mvl 2.4.20 kernel. I'd suggest you to contact MV instead. MTD community is mostly not interested in 2.4, so you probably won't get any help here. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From sshtylyov at ru.mvista.com Fri Aug 11 11:31:11 2006 From: sshtylyov at ru.mvista.com (Sergei Shtylyov) Date: Fri, 11 Aug 2006 19:31:11 +0400 Subject: [RFC] Adding MTD to device tree In-Reply-To: <20060709001435.7a94294e@localhost.localdomain> References: <20060614213643.137680b8@vitb.ru.mvista.com> <44A83AE1.4020707@ru.mvista.com> <20060705153118.6ffbe97d@localhost.localdomain> <44ABC0D1.1020407@ru.mvista.com> <20060705191007.54e8b4b6@localhost.localdomain> <44B00C03.5010409@ru.mvista.com> <20060709001435.7a94294e@localhost.localdomain> Message-ID: <44DCA2BF.1030002@ru.mvista.com> Hello. Here's the proposal for the representation of the MTD (optionally having some partitions) in the device tree, along with the sample code that parses the MTD node and hands the necessary information to the 'physmap' driver using the 'platform_device' method. The representation was fitted to the current Linux MTD driver model, so it doesn't bear any information on the chip models or the flash interflace, letting the MTD probing code figure all that out (this part might need some changes I suspect). To me, however, this method seems too limiting: we have to look thru the device tree for each particular kind MTDs (assuming that there could be different ones that 'physmap' can't drive) and register each of them its own way. If we teach 'physmap' to register on the 'of_platform_device' bus, we may look up the device tree for *any* MTD nodes somewhere in arch/powerpc/ tree, register them all, and leave it up to the particular driver to claim them and get the information the driver needs from their node's properties. That would require introducing another MTD partition pasrsing module (so the code that parses the partitions in this patch will move into the separate module under drivers/mtd/). Opinions on what way should be taken and what needs to be added from both PowerPC and MTD communities are very welcome. WBR, Sergei Signed-off-by: Sergei Shtylyov -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: OF-physmap-device.patch Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20060811/ebf70715/attachment.pl From arnd at arndb.de Fri Aug 11 17:10:40 2006 From: arnd at arndb.de (Arnd Bergmann) Date: Fri, 11 Aug 2006 23:10:40 +0200 Subject: [RFC] Adding MTD to device tree In-Reply-To: <44DCA2BF.1030002@ru.mvista.com> References: <20060614213643.137680b8@vitb.ru.mvista.com> <20060709001435.7a94294e@localhost.localdomain> <44DCA2BF.1030002@ru.mvista.com> Message-ID: <200608112310.41110.arnd@arndb.de> On Friday 11 August 2006 17:31, Sergei Shtylyov wrote: > + ? h) MTD nodes > + > + ? Memory Technology Devices are flash, ROM, and similar chips, often used > + ? for solid state file systems on embedded devices. > + > + ? Required properties: > + > + ? ?- device_type : has to be "mtd" > + ? ?- compatible : Should be the name of the MTD driver. Currently, this is > + ? ? ?most likely to be "physmap". > + ? ?- reg : Offset and length of the register set for the device. I would prefer to call them something different in the device tree. The name 'mtd' is very specific to Linux, but the device tree is a more generic concept. I understand that the booting-without-of.txt file is by definition Linux specific as well, but we should be prepared for making parts of it a OS independent binding at the point where we put the same device nodes into actual OF implementations that able to boot different operating systems. I would prefer a naming that has Required properties: - device_type : one of "nand-flash", "nor-flash", or "rom". - model : an identifier for the actual controller chip used. - compatible : Should be the name of the MTD driver. For type "rom", this is most likely "physmap". Arnd <>< From segher at kernel.crashing.org Sat Aug 12 05:58:01 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sat, 12 Aug 2006 11:58:01 +0200 Subject: [RFC] Adding MTD to device tree In-Reply-To: <1155347601.3108.7.camel@vader.jdub.homelinux.org> References: <20060614213643.137680b8@vitb.ru.mvista.com> <20060709001435.7a94294e@localhost.localdomain> <44DCA2BF.1030002@ru.mvista.com> <200608112310.41110.arnd@arndb.de> <1155347601.3108.7.camel@vader.jdub.homelinux.org> Message-ID: <001C3287-87E7-4DF9-AB4E-E1448EC20518@kernel.crashing.org> >> Required properties: >> - device_type : one of "nand-flash", "nor-flash", or "rom". > > There are more than just those kinds of MTDs. There's dataflash, > AG-AND, NVRAM, ioremappable DRAM, etc. I'd prefer it to just be > called > "flash". See more below. Existing firmwares call it "rom", "nvram", "flash". All of those are easy; and I have really no opinion how all the weirdo nand-flash etc. interfaces should be handled. device_type communicates to the device-tree consumer what other properties to expect in this node -- it does not indicate the exact programming model of the device itself. I suspect for most nand-flash you can get away with a device_type of "nand-flash"; for some you might have to specify something more detailed. >> - model : an identifier for the actual controller chip used. > > Meaning what exactly? Lots of NOR flash doesn't have a "controller". Lots of those chips from different vendors are pin-compatible as well, so you cannot really hardcode one specific model number. I don't see this information being very useful anyway. Instead, in most cases, the information you're really after is the programming interface for the device. And that goes... >> - compatible : Should be the name of the MTD driver. For >> type "rom", this is most likely "physmap". > > This I agree with, but Sergei already had this. And since you're > specifying the name of the MTD driver, that typically already knows > what > type of chip it's talking to. "compatible" contains a list, most specific first. So for example for a NOR-flash it could be "jedec-flash,nor-flash,flash" or whatnot. (Btw: no comma's, but 0-chars in the actual properties!) Segher From sshtylyov at ru.mvista.com Sat Aug 12 12:19:32 2006 From: sshtylyov at ru.mvista.com (Sergei Shtylyov) Date: Sat, 12 Aug 2006 20:19:32 +0400 Subject: [RFC] Adding MTD to device tree In-Reply-To: <001C3287-87E7-4DF9-AB4E-E1448EC20518@kernel.crashing.org> References: <20060614213643.137680b8@vitb.ru.mvista.com> <20060709001435.7a94294e@localhost.localdomain> <44DCA2BF.1030002@ru.mvista.com> <200608112310.41110.arnd@arndb.de> <1155347601.3108.7.camel@vader.jdub.homelinux.org> <001C3287-87E7-4DF9-AB4E-E1448EC20518@kernel.crashing.org> Message-ID: <44DDFF94.3090402@ru.mvista.com> Hello. Segher Boessenkool wrote: >>> Required properties: >>> - device_type : one of "nand-flash", "nor-flash", or "rom". I thought about having the separate device types initially, then I decided that all the differences can be handled on the driver level... >>There are more than just those kinds of MTDs. There's dataflash, >>AG-AND, NVRAM, ioremappable DRAM, etc. I'd prefer it to just be >>called "flash". See more below. > Existing firmwares call it "rom", "nvram", "flash". All of those > are easy; and I have really no opinion how all the weirdo nand-flash > etc. interfaces should be handled. > device_type communicates to the device-tree consumer what other > properties to expect in this node -- it does not indicate the exact > programming model of the device itself. Erm, IIUC the exact set of properties is defined by the node name (or the "compatible" property). The device type defines some mandatory set of properties/methods but there may be some specific... > I suspect for most nand-flash you can get away with a device_type > of "nand-flash"; for some you might have to specify something more > detailed. Hm, not sure that you need to be so much detailed with the device type. The original OF spec. had device type "block" signifying any kind of blocked storage device. >>> - model : an identifier for the actual controller chip used. >>Meaning what exactly? Lots of NOR flash doesn't have a "controller". > Lots of those chips from different vendors are pin-compatible as well, > so you cannot really hardcode one specific model number. I don't see > this information being very useful anyway. Instead, in most cases, the > information you're really after is the programming interface for the > device. And that goes... This property might be marked optional still. >>> - compatible : Should be the name of the MTD driver. For >>> type "rom", this is most likely "physmap". >>This I agree with, but Sergei already had this. And since you're >>specifying the name of the MTD driver, that typically already knows >>what >>type of chip it's talking to. > "compatible" contains a list, most specific first. So for example > for a NOR-flash it could be "jedec-flash,nor-flash,flash" or whatnot. > (Btw: no comma's, but 0-chars in the actual properties!) The "compatible" prop (as well as "name") should define which driver to select according to spec. (the Generic Names spec. delegates this role solely to the "compatible" prop). While specifying the flash interface (JEDEC in this case) is indeed useful (however, the current 'platform_device' based 'physmap' implementation doesn't allow to pass the probe type to the driver), the prop in the form suggested doesn't really help with selecting the MTD map driver (without which you can't support a NOR flash). A reference to 'physmap' should still be present in the node in one or another form... WBR, Sergei From sshtylyov at ru.mvista.com Sat Aug 12 13:43:51 2006 From: sshtylyov at ru.mvista.com (Sergei Shtylyov) Date: Sat, 12 Aug 2006 21:43:51 +0400 Subject: [RFC] Adding MTD to device tree In-Reply-To: <311553550076b8b45674.846930886.miltonm@bga.com> References: <311553550076b8b45674.846930886.miltonm@bga.com> Message-ID: <44DE1357.5010703@ru.mvista.com> Hello. Milton Miller wrote: >>>+ h) MTD nodes >>>+ >>>+ Memory Technology Devices are flash, ROM, and similar chips, often used >>>+ for solid state file systems on embedded devices. >>>+ >>>+ Required properties: >>>+ >>>+ - device_type : has to be "mtd" >>>+ - compatible : Should be the name of the MTD driver. Currently, this is >>>+ most likely to be "physmap". >>>+ - reg : Offset and length of the register set for the device. >>I would prefer to call them something different in the device tree. >>The name 'mtd' is very specific to Linux, but the device tree >>is a more generic concept. "Memory type devices" are specific to Linux? Doubt it. :-) In fact, device type "flash" sounds too restrictive. >>I understand that the booting-without-of.txt file is by definition >>Linux specific as well, but we should be prepared for making parts >>of it a OS independent binding at the point where we put the same >>device nodes into actual OF implementations that able to boot >>different operating systems. >>I would prefer a naming that has >> Required properties: >> - device_type : one of "nand-flash", "nor-flash", or "rom". >> - model : an identifier for the actual controller chip used. >> - compatible : Should be the name of the MTD driver. For >> type "rom", this is most likely "physmap". > I'm with your suggestion for device_type and model, but not > compatable. "physmap"? What kind of device is that? A Directly mapped NOR flash or ROM I think. > command set name, maybe with a width, would be That'd be pretty useless if you don't let Linux know which MTD *map* driver to use. And I have specified the "bank-width" prop. > appropriate. Physmap is the name of another linux driver. And the role of the "compatible" prop is exactly to help OS in selecting the driver. > Something like direct or linear might be appropriate for a rom, > where just address and length appear. I agree that "linear" or "direct" may be better variants. > Even rom would be better than physmap. Doubt it since the ROM is the only one thing (and even the least probable) that we're going to support. > milton WBR, Sergei From segher at kernel.crashing.org Sat Aug 12 14:44:55 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sat, 12 Aug 2006 20:44:55 +0200 Subject: [RFC] Adding MTD to device tree In-Reply-To: <44DDFF94.3090402@ru.mvista.com> References: <20060614213643.137680b8@vitb.ru.mvista.com> <20060709001435.7a94294e@localhost.localdomain> <44DCA2BF.1030002@ru.mvista.com> <200608112310.41110.arnd@arndb.de> <1155347601.3108.7.camel@vader.jdub.homelinux.org> <001C3287-87E7-4DF9-AB4E-E1448EC20518@kernel.crashing.org> <44DDFF94.3090402@ru.mvista.com> Message-ID: >>>> - device_type : one of "nand-flash", "nor-flash", or "rom". > > I thought about having the separate device types initially, then > I decided that all the differences can be handled on the driver > level... Not necessarily on all OSes. >>> There are more than just those kinds of MTDs. There's dataflash, >>> AG-AND, NVRAM, ioremappable DRAM, etc. I'd prefer it to just be >>> called "flash". See more below. > >> Existing firmwares call it "rom", "nvram", "flash". All of those >> are easy; and I have really no opinion how all the weirdo nand-flash >> etc. interfaces should be handled. > >> device_type communicates to the device-tree consumer what other >> properties to expect in this node -- it does not indicate the exact >> programming model of the device itself. > > Erm, IIUC the exact set of properties is defined by the node > name (or the "compatible" property). The device type defines some > mandatory set of properties/methods but there may be some specific... Exact set of properties isn't defined anywhere. "device_type" defines a pretty generic interface, mostly saying what methods will be there (but you don't care for that for a flattened tree); "compatible" communicates to the OS what this device is exactly (so it can select a device driver to use, for example). "name" should not be used by anything but humans normally. >> I suspect for most nand-flash you can get away with a device_type >> of "nand-flash"; for some you might have to specify something more >> detailed. > > Hm, not sure that you need to be so much detailed with the > device type. > The original OF spec. had device type "block" signifying any kind > of blocked storage device. But memory devices aren't really block devices, for example, NOR-flash is random access for everything but erase operations. >>>> - model : an identifier for the actual controller chip used. > This property might be marked optional still. Then there's no reason to include it in the binding; "model" is already defined in the base spec. >> "compatible" contains a list, most specific first. So for example >> for a NOR-flash it could be "jedec-flash,nor-flash,flash" or whatnot. >> (Btw: no comma's, but 0-chars in the actual properties!) > > The "compatible" prop (as well as "name") should define which > driver to select according to spec. (the Generic Names spec. > delegates this role solely to the "compatible" prop). While > specifying the flash interface (JEDEC in this case) is indeed > useful (however, the current 'platform_device' based 'physmap' > implementation doesn't allow to pass the probe type to the driver), > the prop in the form suggested doesn't really help with selecting > the MTD map driver (without which you can't support a NOR flash). A > reference to 'physmap' should still be present in the node in one > or another form... "compatible" denotes the device's specific programming interface, _not_ the name of the device's driver in some random OS. If you don't care for the detailed interface (because your driver will probe for it itself for example, as you said), you can take the next-less-specific entry from "compatible" and use that instead. Although it would be better to just probe for the few specific interfaces defined (jedec-flash, cfi-flash, and a few more perhaps). Segher From segher at kernel.crashing.org Sat Aug 12 14:48:20 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sat, 12 Aug 2006 20:48:20 +0200 Subject: [RFC] Adding MTD to device tree In-Reply-To: <44DE1357.5010703@ru.mvista.com> References: <311553550076b8b45674.846930886.miltonm@bga.com> <44DE1357.5010703@ru.mvista.com> Message-ID: <9FC79123-7439-4800-B5B5-752AB81A6E4F@kernel.crashing.org> >>> I would prefer to call them something different in the device tree. >>> The name 'mtd' is very specific to Linux, but the device tree >>> is a more generic concept. > > "Memory type devices" are specific to Linux? Doubt it. :-) The name "mtd" is. > In fact, device type "flash" sounds too restrictive. But we can't call it "memory", that one is taken already. >> 'm with your suggestion for device_type and model, but not >> compatable. "physmap"? What kind of device is that? A > > Directly mapped NOR flash or ROM I think. So use "flash" and "rom" as device_type (and as name, heh). >> appropriate. Physmap is the name of another linux driver. > > And the role of the "compatible" prop is exactly to help OS in > selecting > the driver. But it *cannot* do that by just naming the driver. Not every OS calls this driver "physmap", you know. Segher From miltonm at bga.com Sat Aug 12 17:15:56 2006 From: miltonm at bga.com (Milton Miller) Date: Sat, 12 Aug 2006 16:15:56 -0500 Subject: [RFC] Adding MTD to device tree In-Reply-To: <44DE1357.5010703@ru.mvista.com> References: <311553550076b8b45674.846930886.miltonm@bga.com> <44DE1357.5010703@ru.mvista.com> Message-ID: <91f1d0619c8ff22cf70404059d514857@bga.com> On Aug 12, 2006, at 12:43 PM, Sergei Shtylyov wrote: > Hello. > > Milton Miller wrote: > >>>> + h) MTD nodes >>>> + >>>> + Memory Technology Devices are flash, ROM, and similar chips, >>>> often used >>>> + for solid state file systems on embedded devices. >>>> + >>>> + Required properties: >>>> + >>>> + - device_type : has to be "mtd" >>>> + - compatible : Should be the name of the MTD driver. >>>> Currently, this is >>>> + most likely to be "physmap". >>>> + - reg : Offset and length of the register set for the device. > >>> I would prefer to call them something different in the device tree. >>> The name 'mtd' is very specific to Linux, but the device tree >>> is a more generic concept. > > "Memory type devices" are specific to Linux? Doubt it. :-) > In fact, device type "flash" sounds too restrictive. First of all, I was only quoting that. Second, no, memory type devices are not specific to Linux. But the term MTD probably is[1]. If you don't want to call it flash, then call it rom. The fact that its programable rom is a detail. >>> I understand that the booting-without-of.txt file is by definition >>> Linux specific as well, but we should be prepared for making parts >>> of it a OS independent binding at the point where we put the same >>> device nodes into actual OF implementations that able to boot >>> different operating systems. > >>> I would prefer a naming that has > >>> Required properties: >>> - device_type : one of "nand-flash", "nor-flash", or "rom". >>> - model : an identifier for the actual controller chip used. >>> - compatible : Should be the name of the MTD driver. For >>> type "rom", this is most likely "physmap". > >> I'm with your suggestion for device_type and model, but not >> compatable. >> "physmap"? What kind of device is that? A > > Directly mapped NOR flash or ROM I think. I don't know how you got there, without your linux implementation knowledge. >> command set name, maybe with a width, would be > > That'd be pretty useless if you don't let Linux know which MTD > *map* driver > to use. And I have specified the "bank-width" prop. The fact that its directly mapped should be evident from its location in the device tree and its properties such as reg. I think you are getting caught up the layering of the linux mtd subsystem, and not thinking about describing the hardware. >> appropriate. Physmap is the name of another linux driver. > > And the role of the "compatible" prop is exactly to help OS in > selecting the driver. Yes, help select. But not say "here is the name of the driver to use." Its to specify the programing interface. We don't say "use the ohci driver" but "this device has pci class 0C0310" and the ohci-pci driver says "I handle devices that are pci class serial subclass usb and programming interface ohci". Putting "cfi-xxx", "cfi", "rom" would show that it should be probed by cfi instead of by jedec for example. Are we still talking about doing a driver that calls physmap with the appropriate address gathered from of_device? It would be the one to select the nodes compatable nodes, finds the relevant parms, and calls the mtd layer. >> Something like direct or linear might be appropriate for a rom, where >> just address >> and length appear. > > I agree that "linear" or "direct" may be better variants. Yea. >> Even rom would be better than physmap. > > Doubt it since the ROM is the only one thing (and even the least > probable) that we're > going to support. But it would make sense to be a later compatible entry ... we can treat the flash as a true read-only memory and it will work, we just will not have the feature of writing to it. As segher pointed out, compatible is a (specific to generic) list of hints to the programming interface. I'll admit I'm not that familiar with the mtd subsystem. But I did go and browse the redboot, ebony, and ocetea map drivers, along with physmap. With the addresses filled out, they would appear to collapse into one driver, with multiple device nodes for each one. Except for the partitioning information. Ok that brings up partitions: if you need partitions, and don't have a table system like redboot, then we need some way to convey that in the device tree. My first instinct is that would be via device nodes under the map device in the tree. The nodes would get a reg with relative address and size, and the name would be the name of the partition. We could also do it in properties on the mtd node, but then would not not have a good place to put the name. (Well, we could do a list of strings and a parallel list of partition sizes. I would prefer we not encode both in one property). Yes, we can rely on cmdline partitioning ... but that means a long argument in your device tree you don't want edited. milton [1] Google seems to confirm this: the first several hits are for a power equipment manufacturer, and then linux-mtd site by itself, without other os's "mtd" projects in the first 4 pages of hits. From sshtylyov at ru.mvista.com Sat Aug 12 18:00:36 2006 From: sshtylyov at ru.mvista.com (Sergei Shtylyov) Date: Sun, 13 Aug 2006 02:00:36 +0400 Subject: [RFC] Adding MTD to device tree In-Reply-To: <91f1d0619c8ff22cf70404059d514857@bga.com> References: <311553550076b8b45674.846930886.miltonm@bga.com> <44DE1357.5010703@ru.mvista.com> <91f1d0619c8ff22cf70404059d514857@bga.com> Message-ID: <44DE4F84.9030802@ru.mvista.com> Hello. Milton Miller wrote: >>>>> + h) MTD nodes >>>>> + >>>>> + Memory Technology Devices are flash, ROM, and similar chips, >>>>> often used >>>>> + for solid state file systems on embedded devices. >>>>> + >>>>> + Required properties: >>>>> + >>>>> + - device_type : has to be "mtd" >>>>> + - compatible : Should be the name of the MTD driver. >>>>> Currently, this is >>>>> + most likely to be "physmap". >>>>> + - reg : Offset and length of the register set for the device. >>>> I would prefer to call them something different in the device tree. >>>> The name 'mtd' is very specific to Linux, but the device tree >>>> is a more generic concept. >> "Memory type devices" are specific to Linux? Doubt it. :-) >> In fact, device type "flash" sounds too restrictive. > First of all, I was only quoting that. I'm not ascribing them to you. :-) > Second, no, memory type devices are not specific to Linux. But the term > MTD > probably is[1]. I doubt Google based conslusions qualify here. > If you don't want to call it flash, then call it rom. The > fact that its programable rom is a detail. Important detail, I'd say. >>>> I understand that the booting-without-of.txt file is by definition >>>> Linux specific as well, but we should be prepared for making parts >>>> of it a OS independent binding at the point where we put the same >>>> device nodes into actual OF implementations that able to boot >>>> different operating systems. >>>> I would prefer a naming that has >>>> Required properties: >>>> - device_type : one of "nand-flash", "nor-flash", or "rom". >>>> - model : an identifier for the actual controller chip used. >>>> - compatible : Should be the name of the MTD driver. For >>>> type "rom", this is most likely "physmap". >>> I'm with your suggestion for device_type and model, but not compatable. >>> "physmap"? What kind of device is that? A >> Directly mapped NOR flash or ROM I think. > I don't know how you got there, without your linux implementation > knowledge. Indeed, this was compeletely Linux specific name. >>> command set name, maybe with a width, would be >> That'd be pretty useless if you don't let Linux know which MTD >> *map* driver >> to use. And I have specified the "bank-width" prop. > The fact that its directly mapped should be evident from its location in > the device tree and its properties such as reg. Nohow. The flash could be be indirectly accessible and still have the reg prop in the device node. It also may need nasty byte swapping tricks (in which case it's not physmap compatible). > I think you are getting caught up the layering of the linux mtd > subsystem, and not > thinking about describing the hardware. If we end up with the node spec that is correct from the point of description the hardware but absolutely useless when it comes to selectiong the proper driver, what use it would be? >>> appropriate. Physmap is the name of another linux driver. >> And the role of the "compatible" prop is exactly to help OS in >> selecting the driver. > Yes, help select. But not say "here is the name of the driver to use." > Its to specify the programing interface. Well, you may be wrong here. See below. :-) > Putting "cfi-xxx", "cfi", "rom" would show that it should be probed by cfi > instead of by jedec for example. Yes. But that's just no use with the current platform_device base implementation of physmap. So we'd either need to extend this implementation or make physmap parse all that from the device tree by itself. > Are we still talking about doing a driver that calls physmap with the > appropriate > address gathered from of_device? Well, this would not exactly be a driver then. > It would be the one to select the nodes compatable > nodes, finds the relevant parms, and calls the mtd layer. In fact, I indended to probe the MTD/PPC people which way they like best: sticking with platform_device still, or making physmap of_device aware by itself (although we'd still need to register the flash device somewhere in arch/powerpc/, since there's not code anywhere that register *all* devices found in the device tree)... >>> Even rom would be better than physmap. >> Doubt it since the ROM is the only one thing (and even the least >> probable) that we're >> going to support. > But it would make sense to be a later compatible entry ... we can treat > the flash as a > true read-only memory and it will work, we just will not have the > feature of writing > to it. Indeed, if "compatible" incorporated the chip interfaces (probe types for MTD/physmap drivers), that'd have made sense. Alas, with platform_device based approach, we have no way of passing this info to MTD subsys currently. > As segher pointed out, compatible is a (specific to generic) list of > hints to the > programming interface. If you look into the OF specs, "compatible" and "name" are treated as the *driver* names here. There are whole passages there warning about not selecting too generic driver names like "network". > I'll admit I'm not that familiar with the mtd subsystem. But I did go > and browse the > redboot, ebony, and ocetea map drivers, along with physmap. With the > addresses filled > out, they would appear to collapse into one driver, with multiple device > nodes for each > one. Except for the partitioning information. Then they should have indeed collapsed into it. The thing is physmap driver might be actually newer than those ones, so they're kept for historical reasons (and for the partition info which actually should move into the platform setup code). > Ok that brings up partitions: if you need partitions, and don't have a > table system > like redboot, then we need some way to convey that in the device tree. My > first instinct is that would be via device nodes under the map device in > the tree. Erm, what map device? > The nodes would get a reg with relative address and size, and the name > would be > the name of the partition. MTD partitions are *not* devices, so I guess the first instinct is wrong (I had to struggle with it too :-). > We could also do it in properties on the > mtd node, but > then would not not have a good place to put the name. (Well, we could > do a list of > strings and a parallel list of partition sizes. I would prefer we not > encode both > in one property). 'dtc' wouldn't able to chew it anyway although the OF spec. promised multi-type properties. Sorry, have you bothered looking into my node spec? :-) > Yes, we can rely on cmdline partitioning ... but that > means a long > argument in your device tree you don't want edited. I finally decided that if we have the ability to store it in the device tree, this is better than have user to type and store the bootargs (or worse yet, rebuild U-Boot changing the default value of this env. var.). > milton > [1] Google seems to confirm this: the first several hits are for a power > equipment > manufacturer, and then linux-mtd site by itself, without other os's > "mtd" projects > in the first 4 pages of hits. Hm, MTD is a short for "memory type device", what Linux has to do with it at all? However, let the MTD experts correct me... WBR, Sergei From wd at denx.de Sat Aug 12 20:20:40 2006 From: wd at denx.de (Wolfgang Denk) Date: Sun, 13 Aug 2006 02:20:40 +0200 Subject: [RFC] Adding MTD to device tree In-Reply-To: Your message of "Sun, 13 Aug 2006 02:00:36 +0400." <44DE4F84.9030802@ru.mvista.com> Message-ID: <20060813002040.DFA8D352660@atlas.denx.de> In message <44DE4F84.9030802 at ru.mvista.com> you wrote: > > Hm, MTD is a short for "memory type device", what Linux has to do with it Memory Technology Device. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated. From wd at denx.de Sat Aug 12 20:20:51 2006 From: wd at denx.de (Wolfgang Denk) Date: Sun, 13 Aug 2006 02:20:51 +0200 Subject: [RFC] Adding MTD to device tree In-Reply-To: Your message of "Sat, 12 Aug 2006 16:15:56 CDT." <91f1d0619c8ff22cf70404059d514857@bga.com> Message-ID: <20060813002051.3237E352660@atlas.denx.de> In message <91f1d0619c8ff22cf70404059d514857 at bga.com> you wrote: > > Second, no, memory type devices are not specific to Linux. But the > term MTD > probably is[1]. If you don't want to call it flash, then call it rom. No, it is not. It has been used by other RTOS as well, and probably before Linux. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de A conservative is a man who believes that nothing should be done for the first time. - Alfred E. Wiggam From john at arrows.demon.co.uk Sun Aug 13 06:24:35 2006 From: john at arrows.demon.co.uk (John) Date: Sun, 13 Aug 2006 11:24:35 +0100 (BST) Subject: OneNAND - Cannot mount jffs2 partition Message-ID: I am trying to use a OneNAND device fitted to a MIPS board. I am the first person to use this device on this board. And I am fairly new to the MTD world. My problems may be generic to MTD rather than being OneNAND specific. My Kernel is based on Linux 2.6.12 patched with the OneNAND code from Linux 2.6.16. I am running little endian. My mtd-utils are from October 2005. Questions: Is this a suitable pair of commands? $ flash_eraseall -j /dev/mtd5 $ mount -t jffs2 /dev/mtdblock5 /mnt/onenand Would they work on an ordinary NAND device? Should I be using the NFTL code is some way? What is the likely underlying cause of the error message "Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes" I'd be very grateful for any guidance, John (John Smith) Here is some log stuff from the Kernel showing what happens: (The board has both a NOR flash device, and a oneNAND flash device) At boot time the kernel reports: Flash device: 1000000 at 1f000000 Mapped flash: Found 1 x16 devices at 0x0 in 16-bit bank Amd/Fujitsu Extended Query Table at 0x0040 Mapped flash: CFI does not contain boot bank location. Assuming top. number of CFI chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. Creating 5 MTD partitions on "NOR flash": 0x00000000-0x00c00000 : "rootfs" 0x00c00000-0x00c80000 : "loader" 0x00c80000-0x00fff800 : "vmlinux" mtd: partition "vmlinux" doesn't end on an erase block -- force read-only 0x00fff800-0x00fff890 : "config" mtd: partition "config" doesn't start on an erase block boundary -- force read-only 0x00fff890-0x01000000 : "nvram" mtd: partition "nvram" doesn't start on an erase block boundary -- force read-only MTD: pace_onenand_init OneNAND 16MB 2.65/3.3V 16-bit (0x05) Lock scheme is Continues Lock Scanning device for bad blocks Creating 2 MTD partitions on "Onenand": 0x00000000-0x00800000 : "part_one" 0x00800000-0x01000000 : "part_two" ## ## Looking at /proc/mtd, the partitions seem to exist ## ~ # cat /proc/mtd dev: size erasesize name mtd0: 00c00000 00020000 "rootfs" mtd1: 00080000 00020000 "loader" mtd2: 0037f800 00020000 "vmlinux" mtd3: 00000090 00020000 "config" mtd4: 00000770 00020000 "nvram" mtd5: 00800000 00010000 "part_one" mtd6: 00800000 00010000 "part_two" ## ## I can build a jffs2 partition on the NOR device ## (with a worring error message) ~ # flash_eraseall -j /dev/mtd0 Erasing 128 Kibyte @ be0000 -- 98 % complete. Cleanmarker written at be0000. ~ # mount -t jffs2 /dev/mtdblock0 /mnt/nor Eep. No valid nodes for ino #1 ~ #~ # cp /my-registers.txt /mnt/nor ~ # ls -l /my-registers.txt /mnt/nor/my-registers.txt -rw-r--r-- 1 0 0 2087754 Jan 1 00:02 /mnt/nor/my-registers.txt -rw-r--r-- 1 0 0 2087754 Aug 13 2006 /my-registers.txt ~ # md5sum /mnt/nor/my-registers.txt /my-registers.txt 3b8b150e7067d2a7b251cfcd0200e530 /mnt/nor/my-registers.txt 3b8b150e7067d2a7b251cfcd0200e530 /my-registers.txt (after rebooting and mounting, the file was still there) ## ## Equivalent commands on the OneNAND flash fail ## ~ # flash_eraseall -j /dev/mtd5 Erasing 64 Kibyte @ 7f0000 -- 99 % complete. Cleanmarker written at 7f0000. ~ # mount -t jffs2 /dev/mtdblock5 /mnt/onenand/ Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes empty_blocks 0, bad_blocks 0, c->nr_blocks 128 mount: Mounting /dev/mtdblock5 on /mnt/onenand failed: Input/output error ## ## And afterwards only the NOR device is mounted: ## ~ # df Filesystem 1k-blocks Used Available Use% Mounted on /dev/root 76255996 64592052 7790272 89% / tmpfs 256 12 244 5% /var /dev/mtdblock0 12288 852 11436 7% /mnt/nor ## ## mtd_debug reports the right sizes. ## (oneNAND has internal ECC logic. It has 16 bytes of OOB space ## for every 512 byte sector, several of which are reserved for use by the ## ECC logic) ~ # mtd_debug info /dev/mtd5 mtd.type = MTD_NANDFLASH mtd.flags = MTD_CLEAR_BITS | MTD_ERASEABLE | MTD_OOB | MTD_ECC mtd.size = 8388608 (8M) mtd.erasesize = 65536 (64K) mtd.oobblock = 1024 (1K) mtd.oobsize = 32 mtd.ecctype = MTD_ECC_NONE regions = 0 From dedekind at yandex.ru Sun Aug 13 08:10:52 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Sun, 13 Aug 2006 16:10:52 +0400 Subject: OneNAND - Cannot mount jffs2 partition In-Reply-To: References: Message-ID: <44DF16CC.3070708@yandex.ru> Hello John, John wrote: > Questions: > Is this a suitable pair of commands? > $ flash_eraseall -j /dev/mtd5 > $ mount -t jffs2 /dev/mtdblock5 /mnt/onenand Yeah, I believe this is the right commands and should work. > Would they work on an ordinary NAND device? Yeah, and even on NOR. > Should I be using the NFTL code is some way? Nope. > What is the likely underlying cause of the error message > "Cowardly refusing to erase blocks on filesystem with > no valid JFFS2 nodes" Hmm, JFFS2 is complaining that you feed it with a flash which is neither empty nor contains a valid JFFS2 FS image. Try to avoid using -j ans see what happens. You also may try to enable JFFS2's debugging prints. I personally have never used OneNAND, and AFAIK it is rather new in MTD. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From catherine at arrows.demon.co.uk Sun Aug 13 13:45:12 2006 From: catherine at arrows.demon.co.uk (Catherine Smith) Date: Sun, 13 Aug 2006 18:45:12 +0100 Subject: OneNAND - Cannot mount jffs2 partition References: <44DF16CC.3070708@yandex.ru> Message-ID: <000e01c6bf00$3acdd130$c9fea8c0@Catherine> Thanks Artem. > John wrote: >> Questions: >> Is this a suitable pair of commands? >> $ flash_eraseall -j /dev/mtd5 >> $ mount -t jffs2 /dev/mtdblock5 /mnt/onenand > Yeah, I believe this is the right commands and should work. > > >> What is the likely underlying cause of the error message >> "Cowardly refusing to erase blocks on filesystem with >> no valid JFFS2 nodes" > Hmm, JFFS2 is complaining that you feed it with a flash which is neither > empty nor contains a valid JFFS2 FS image. > > Try to avoid using -j and see what happens. You also may try to enable > JFFS2's debugging prints. > If I don't use the -j, it seems to work, though with a few warnings. For example: $ flash_eraseall /dev/mtd5 Eraseing 64 Kibyte @ 7f0000 -- 99 % complete $ mount -t jffs2 /dev/mtdblock5 /mnt/onenand Eep. no valid nodes for ino #1 Then I can create files in /mnt/onenand, and copy them around or calculate a few signatures. All is well. Once, when I tried to mount after a power cycle, it said: jffs2_get_inode_nodes(): CRC failed on node at 0x002dd7c8: Read 0xffffffff, calculated 0x20f0e445 Are these warnings, the Eep and the CRC failure, typical and harmless, or should I take a keen interest? > > -- > Best Regards, > Artem B. Bityutskiy, > St.-Petersburg, Russia. > Regards, John Smith Lancashire, England From ynezz at true.cz Mon Aug 14 04:38:45 2006 From: ynezz at true.cz (Petr Stetiar) Date: Mon, 14 Aug 2006 10:38:45 +0200 Subject: Obsolete ioctl MEMSETOOBSEL in nandwrite Message-ID: <20060814083845.GA18948@ibawizard.net> Hi, I think, that nandwrite is using already obsolete MEMSETOOBSEL ioctl. I've fixed it for myself just by removing these ioctl calls and it seems to work. Sorry, that I'm not sending a patch, but I don't feel familiar enough with mtd to do so. Just for info, I'm using 2.6.18-rc4 kernel with latest mtd-utils.git in buildroot on ep93xx ARM platform, 32MB Samsung NAND flash. -- ynezz From dwmw2 at infradead.org Mon Aug 14 08:39:26 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 14 Aug 2006 13:39:26 +0100 Subject: [RFC] Adding MTD to device tree In-Reply-To: <9FC79123-7439-4800-B5B5-752AB81A6E4F@kernel.crashing.org> References: <311553550076b8b45674.846930886.miltonm@bga.com> <44DE1357.5010703@ru.mvista.com> <9FC79123-7439-4800-B5B5-752AB81A6E4F@kernel.crashing.org> Message-ID: <1155559166.3321.138.camel@pmac.infradead.org> On Sat, 2006-08-12 at 20:48 +0200, Segher Boessenkool wrote: > > "Memory type devices" are specific to Linux? Doubt it. :-) > > The name "mtd" is. Actually it came from PCMCIA. -- dwmw2 From sharma.amit at samsung.com Sun Aug 13 20:58:15 2006 From: sharma.amit at samsung.com (Amit Kumar Sharma) Date: Mon, 14 Aug 2006 09:58:15 +0900 Subject: linux-mtd Digest, Vol 41, Issue 17 In-Reply-To: Message-ID: <001a01c6bf3c$b9fa9d30$3d92340c@dsn.sec.samsung.com> -----Original Message----- From: linux-mtd-bounces at lists.infradead.org [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf Of linux-mtd-request at lists.infradead.org Sent: Monday, August 14, 2006 1:00 AM To: linux-mtd at lists.infradead.org Subject: linux-mtd Digest, Vol 41, Issue 17 Send linux-mtd mailing list submissions to linux-mtd at lists.infradead.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.infradead.org/mailman/listinfo/linux-mtd or, via email, send a message with subject or body 'help' to linux-mtd-request at lists.infradead.org You can reach the person managing the list at linux-mtd-owner at lists.infradead.org When replying, please edit your Subject line so it is more specific than "Re: Contents of linux-mtd digest..." Today's Topics: 1. Re: [RFC] Adding MTD to device tree (Wolfgang Denk) 2. Re: [RFC] Adding MTD to device tree (Wolfgang Denk) 3. OneNAND - Cannot mount jffs2 partition (John) 4. Re: OneNAND - Cannot mount jffs2 partition (Artem B. Bityutskiy) ---------------------------------------------------------------------- Message: 1 Date: Sun, 13 Aug 2006 02:20:40 +0200 From: Wolfgang Denk Subject: Re: [RFC] Adding MTD to device tree To: Sergei Shtylyov Cc: Segher Boessenkool , Arnd Bergmann , Milton Miller , linuxppc-dev at ozlabs.org, linux-mtd at lists.infradead.org, linuxppc-embedded at ozlabs.org Message-ID: <20060813002040.DFA8D352660 at atlas.denx.de> Content-Type: text/plain; charset=ISO-8859-1 In message <44DE4F84.9030802 at ru.mvista.com> you wrote: > > Hm, MTD is a short for "memory type device", what Linux has to do with it Memory Technology Device. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated. ------------------------------ Message: 2 Date: Sun, 13 Aug 2006 02:20:51 +0200 From: Wolfgang Denk Subject: Re: [RFC] Adding MTD to device tree To: Milton Miller Cc: Sergei Shtylyov , linuxppc-dev at ozlabs.org, linux-mtd at lists.infradead.org, Arnd Bergmann , linuxppc-embedded at ozlabs.org Message-ID: <20060813002051.3237E352660 at atlas.denx.de> Content-Type: text/plain; charset=ISO-8859-1 In message <91f1d0619c8ff22cf70404059d514857 at bga.com> you wrote: > > Second, no, memory type devices are not specific to Linux. But the > term MTD > probably is[1]. If you don't want to call it flash, then call it rom. No, it is not. It has been used by other RTOS as well, and probably before Linux. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de A conservative is a man who believes that nothing should be done for the first time. - Alfred E. Wiggam ------------------------------ Message: 3 Date: Sun, 13 Aug 2006 11:24:35 +0100 (BST) From: John Subject: OneNAND - Cannot mount jffs2 partition To: Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII I am trying to use a OneNAND device fitted to a MIPS board. I am the first person to use this device on this board. And I am fairly new to the MTD world. My problems may be generic to MTD rather than being OneNAND specific. My Kernel is based on Linux 2.6.12 patched with the OneNAND code from Linux 2.6.16. I am running little endian. My mtd-utils are from October 2005. Questions: Is this a suitable pair of commands? $ flash_eraseall -j /dev/mtd5 $ mount -t jffs2 /dev/mtdblock5 /mnt/onenand Would they work on an ordinary NAND device? Should I be using the NFTL code is some way? What is the likely underlying cause of the error message "Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes" I'd be very grateful for any guidance, John (John Smith) Hi John Can u tell how u are creating JFFS2 image for ONENAND partition. ./mkfs.jffs2 --pad=0x3e80000(size of ur partition) -s 2KiB -m none -e 128KiB --root=empty/ -o jffs2.image .Please try these options for ur image. Rgs Amit Here is some log stuff from the Kernel showing what happens: (The board has both a NOR flash device, and a oneNAND flash device) At boot time the kernel reports: Flash device: 1000000 at 1f000000 Mapped flash: Found 1 x16 devices at 0x0 in 16-bit bank Amd/Fujitsu Extended Query Table at 0x0040 Mapped flash: CFI does not contain boot bank location. Assuming top. number of CFI chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. Creating 5 MTD partitions on "NOR flash": 0x00000000-0x00c00000 : "rootfs" 0x00c00000-0x00c80000 : "loader" 0x00c80000-0x00fff800 : "vmlinux" mtd: partition "vmlinux" doesn't end on an erase block -- force read-only 0x00fff800-0x00fff890 : "config" mtd: partition "config" doesn't start on an erase block boundary -- force read-only 0x00fff890-0x01000000 : "nvram" mtd: partition "nvram" doesn't start on an erase block boundary -- force read-only MTD: pace_onenand_init OneNAND 16MB 2.65/3.3V 16-bit (0x05) Lock scheme is Continues Lock Scanning device for bad blocks Creating 2 MTD partitions on "Onenand": 0x00000000-0x00800000 : "part_one" 0x00800000-0x01000000 : "part_two" ## ## Looking at /proc/mtd, the partitions seem to exist ## ~ # cat /proc/mtd dev: size erasesize name mtd0: 00c00000 00020000 "rootfs" mtd1: 00080000 00020000 "loader" mtd2: 0037f800 00020000 "vmlinux" mtd3: 00000090 00020000 "config" mtd4: 00000770 00020000 "nvram" mtd5: 00800000 00010000 "part_one" mtd6: 00800000 00010000 "part_two" ## ## I can build a jffs2 partition on the NOR device ## (with a worring error message) ~ # flash_eraseall -j /dev/mtd0 Erasing 128 Kibyte @ be0000 -- 98 % complete. Cleanmarker written at be0000. ~ # mount -t jffs2 /dev/mtdblock0 /mnt/nor Eep. No valid nodes for ino #1 ~ #~ # cp /my-registers.txt /mnt/nor ~ # ls -l /my-registers.txt /mnt/nor/my-registers.txt -rw-r--r-- 1 0 0 2087754 Jan 1 00:02 /mnt/nor/my-registers.txt -rw-r--r-- 1 0 0 2087754 Aug 13 2006 /my-registers.txt ~ # md5sum /mnt/nor/my-registers.txt /my-registers.txt 3b8b150e7067d2a7b251cfcd0200e530 /mnt/nor/my-registers.txt 3b8b150e7067d2a7b251cfcd0200e530 /my-registers.txt (after rebooting and mounting, the file was still there) ## ## Equivalent commands on the OneNAND flash fail ## ~ # flash_eraseall -j /dev/mtd5 Erasing 64 Kibyte @ 7f0000 -- 99 % complete. Cleanmarker written at 7f0000. ~ # mount -t jffs2 /dev/mtdblock5 /mnt/onenand/ Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes empty_blocks 0, bad_blocks 0, c->nr_blocks 128 mount: Mounting /dev/mtdblock5 on /mnt/onenand failed: Input/output error ## ## And afterwards only the NOR device is mounted: ## ~ # df Filesystem 1k-blocks Used Available Use% Mounted on /dev/root 76255996 64592052 7790272 89% / tmpfs 256 12 244 5% /var /dev/mtdblock0 12288 852 11436 7% /mnt/nor ## ## mtd_debug reports the right sizes. ## (oneNAND has internal ECC logic. It has 16 bytes of OOB space ## for every 512 byte sector, several of which are reserved for use by the ## ECC logic) ~ # mtd_debug info /dev/mtd5 mtd.type = MTD_NANDFLASH mtd.flags = MTD_CLEAR_BITS | MTD_ERASEABLE | MTD_OOB | MTD_ECC mtd.size = 8388608 (8M) mtd.erasesize = 65536 (64K) mtd.oobblock = 1024 (1K) mtd.oobsize = 32 mtd.ecctype = MTD_ECC_NONE regions = 0 ------------------------------ Message: 4 Date: Sun, 13 Aug 2006 16:10:52 +0400 From: "Artem B. Bityutskiy" Subject: Re: OneNAND - Cannot mount jffs2 partition To: John Cc: linux-mtd at lists.infradead.org Message-ID: <44DF16CC.3070708 at yandex.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Hello John, John wrote: > Questions: > Is this a suitable pair of commands? > $ flash_eraseall -j /dev/mtd5 > $ mount -t jffs2 /dev/mtdblock5 /mnt/onenand Yeah, I believe this is the right commands and should work. > Would they work on an ordinary NAND device? Yeah, and even on NOR. > Should I be using the NFTL code is some way? Nope. > What is the likely underlying cause of the error message > "Cowardly refusing to erase blocks on filesystem with > no valid JFFS2 nodes" Hmm, JFFS2 is complaining that you feed it with a flash which is neither empty nor contains a valid JFFS2 FS image. Try to avoid using -j ans see what happens. You also may try to enable JFFS2's debugging prints. I personally have never used OneNAND, and AFAIK it is rather new in MTD. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. ------------------------------ ______________________________________________________ Linux MTD discussion mailing list digest http://lists.infradead.org/mailman/listinfo/linux-mtd/ End of linux-mtd Digest, Vol 41, Issue 17 ***************************************** From sharma.amit at samsung.com Sun Aug 13 21:06:58 2006 From: sharma.amit at samsung.com (Amit Kumar Sharma) Date: Mon, 14 Aug 2006 10:06:58 +0900 Subject: OneNAND - Cannot mount jffs2 partition (Amit kumar Sharma) Message-ID: <001b01c6bf3d$f12b39d0$3d92340c@dsn.sec.samsung.com> Hi John For creating JFFS2 on One nand image use these options ./flasheraseall -j /dev/mtd partition ./mkfs.jffs2 --pad=0x3e80000 (ur mtd onenand partition size) -s 2KiB -m none -e 128KiB(block size) --root=empty/(source directory for image ) -o jffs2.image(output file) Use nandwrite from mtd utils for image writing Thanks Amit From dedekind at yandex.ru Mon Aug 14 11:03:36 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Mon, 14 Aug 2006 19:03:36 +0400 Subject: OneNAND - Cannot mount jffs2 partition In-Reply-To: <000e01c6bf00$3acdd130$c9fea8c0@Catherine> References: <44DF16CC.3070708@yandex.ru> <000e01c6bf00$3acdd130$c9fea8c0@Catherine> Message-ID: <44E090C8.9040400@yandex.ru> Hi Catherine, Catherine Smith wrote: > If I don't use the -j, it seems to work, though with a few warnings. > For example: > $ flash_eraseall /dev/mtd5 > Eraseing 64 Kibyte @ 7f0000 -- 99 % complete > $ mount -t jffs2 /dev/mtdblock5 /mnt/onenand > Eep. no valid nodes for ino #1 That's harmless. -j option means to put so-called clean marker at each etaseblock. The cleanmarker just means that the eraseblock is clean ant it is safe to write data at it. This is needed to guaranty data consistency - it is not enough to just check that the eraseblock contains only 0xFF bytes. For example, due to unclean reboots which may interrupt an erase operation, some bits may become unstable and be read sometimes as 1, and sometimes as 0. If you don't use -j option, JFFS2 will re-erase empty eraseblocks itself, and put the clean marker. It may also complain about absence of the root inode (which isn't a brilliant idea), but it creates the root node automatically. > Then I can create files in /mnt/onenand, and copy them around or calculate a > few signatures. All is well. > Once, when I tried to mount after a power cycle, it said: > jffs2_get_inode_nodes(): CRC failed on node at 0x002dd7c8: Read > 0xffffffff, calculated 0x20f0e445 Did you unmount it cleanly? Or just pushed reset? If you didn't unmount - it may be harmless. > Are these warnings, the Eep and the CRC failure, typical and harmless, > or should I take a keen interest? If you didn't cleanly unmount, you could have been interrupted a delayed wbuf flush and just lost some last-written data. This could cause CRC failure. And as JFFS2 cannot distinguish between real corruption and corruptions due to unclean reboots - it issued a warning. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From jwboyer at gmail.com Mon Aug 14 20:49:14 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 14 Aug 2006 19:49:14 -0500 Subject: [PATCH] Mcronix MX29F040 support. In-Reply-To: <20060804072500.a0ad58a6.takasi-y@ops.dti.ne.jp> References: <20060803223936.87040059.takasi-y@ops.dti.ne.jp> <625fc13d0608030713u299085f4l60dbc9169e61b968@mail.gmail.com> <20060804072500.a0ad58a6.takasi-y@ops.dti.ne.jp> Message-ID: <625fc13d0608141749h1ffd3147m419bd3eab51f1950@mail.gmail.com> On 8/3/06, takasi-y at ops.dti.ne.jp wrote: > Thank you, josh. > I'd missunderstood thet the line is added certified(?) people. > /yoshii > > Signed-off-by: Takashi YOSHII This has been applied to my tree. I'll push to the master MTD tree soon. thx, josh From jwboyer at gmail.com Tue Aug 15 08:29:03 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 15 Aug 2006 07:29:03 -0500 Subject: [PATCH] PHYSMAP depens on CFI or JEDECPROBE or ROM In-Reply-To: <20060804230802.80dc086b.takasi-y@ops.dti.ne.jp> References: <20060803222818.7f8f0286.takasi-y@ops.dti.ne.jp> <20060804230802.80dc086b.takasi-y@ops.dti.ne.jp> Message-ID: <625fc13d0608150529j68b8a4e1r739a251375a6f028@mail.gmail.com> On 8/4/06, takasi-y at ops.dti.ne.jp wrote: > # posting it agein. > map/physmap.c tries to probe "cfi_probe", "jedec_probe" and "map_rom", but > map/Kconfig says it depends on MTD_CFI only. > This patch adds MTD_JEDECPROBE and MTD_ROM to the dependency condition. I've committed this one to my tree as well. In the future, it would be better to generate patches with a strip level of 1 and based on the MTD git tree instead of CVS. The MTD CVS tree is dead now. thx, josh From wayendavis1tt at yahoo.com.hk Tue Aug 15 09:01:52 2006 From: wayendavis1tt at yahoo.com.hk (Dr. Wayne Davis) Date: Tue, 15 Aug 2006 13:01:52 -0000 (GMT) Subject: Job Representative Offer Message-ID: <37261.165.228.131.12.1155646912.squirrel@65.98.16.106> Dr. Wayne Davis Agricultural Research Institute of Northern Ireland Hillsborough, Ireland BT26 6DR Tel: +447011121587 Dear Sir/Madam, How are you doing. I came across your email address and your brief profile through an email listing affiliated with the Australian Chamber of Commerce. I would be very interested in offering you a part-time paying job in which you could earn alot. My names are Dr. Wayne Davis and I am 58 years of age. I just resigned my job as a research scientist for ARINI(Agricultural Research Institute of Northern Ireland and I now work as a freelance consultant for the instistute which gives me very much time to do my own work which is basically being a freelance researcher who could be employed by research institutes to do research projects anywhere in the world. Presently, I have just been granted a funding to head a research project in the tropical regions of Asia regarding rare and vulnerable plant species and this would be commencing very soon. This research program will be funded and sponsored by some of my Australian counterparts and Associates. But the only set back is that my Australian counterparts want to make payments for the research in form of bank transfer only to any of the Australian banks. Getting an accountant in Australian or opening an account would have been my best choice but I have a deadline to meet and taking any of those choices would cost me time and a whole lot of other requirements which I am not ready to deal with. This is where I need to employ your assistance and service. WHAT I NEED YOU FOR? At this point, I will be glad if you could work with me as my representative in Australia. You will be working as my payment assistant incharge of collecting the payments from my Associates. Since they will be making the payment in bank transfers made payable only to you in Australia, you will be collecting this payments and cashing them on my behalf. On agreement to been my representative, you will receive a commission of 10% of whatever amount of payment you receive from my associates. JOB DESCRIPTION? 1. Recieve payments from My Clients/Associates through bank transfers into your bank account. 2. Cash the Payments at your Bank. 3. Deduct 10% which will be your commission/percentage on Payment processed. 4. You are to remit the balance via Money Gram or Western Union Money Transfer according to my instruction. HOW MUCH WILL YOU EARN? 10% from each transaction! For instance: On receiving 6000 Dollars on my behalf, you will cash the payment and keep 10% to yourself before remitting the balance! At the beginning your commission will equal 10%, though later it will increase up to 12%! For the research, I am expecting about the sum of $95,000 in total from the clients(though the money will be sent in installmentally due to the progress of my research). You could make over $9,500 for the little time we will be working together. ADVANTAGES? You dont have to go out of your present daily activity inorder to engage in this Job(i.e. you can do this Work easily without leaving or affecting your present Job).You will work as an independent contractor right from your home /office. Your job is absolutely legal. You do not need any capital to start(non of your personal funds is needed). REQUIREMENTS? i) 18 years or older. ii) Legally capable. iii) Responsible, Reliable and Trustworthy. iv) Ready to work 3-4 hours per week. v) Able to check and respond to emails often. vi) Easy telephone access. IS THIS LEGAL? Yes it is.As a matter of fact,my lawyer checked all legal provisions to know if there is any dosmestic or international law against businesses or deals in this manner.And he said its allowed by all LAWS.So know that doing this work is safe and legitimate. I hope all is well understood. I would be glad if you accept my proposal and I intend to commence as soon as you are ready. Please, to facilitate the conclusion of this transaction if accepted, do send promptly by email the following details below, to indicate your interest. NAME: ADDRESS: PHONE NUMBER: AGE: SEX: NAME OF BANK: ACCOUNT NAME: ACCOUNT NUMBER: B.S.B NUMBER: Once these information has been received from you, it would be forwarded to my Australian associates so they could commence the bank transfer to you. ALL REPLIES TO BE SENT TO : wayendavis1s at yahoo.ie From katey.Yu at ositech.com Mon Aug 14 16:44:01 2006 From: katey.Yu at ositech.com (Katey Yu) Date: Mon, 14 Aug 2006 16:44:01 -0400 Subject: write-protected Message-ID: <007020085773234AAACE3B66E13C18E8D71CB3@MAILSRVR.ositech.com> Hello, When I mount /dev/mtdblock3 in flash I get block " block device /dev/mtdblock3 is write-protected, mounting read-only". I should get mtdblock_open? Could somebody tell me what's wrong? mount -t jffs2 /dev/mtdblock3 /var/tmp mount: block device /dev/mtdblock3 is write-protected, mounting read-only Katey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.infradead.org/pipermail/linux-mtd/attachments/20060814/447ae464/attachment.html From samuel at Update.UU.SE Tue Aug 15 11:36:49 2006 From: samuel at Update.UU.SE (Samuel ]slund) Date: Tue, 15 Aug 2006 17:36:49 +0200 Subject: write-protected In-Reply-To: <007020085773234AAACE3B66E13C18E8D71CB3@MAILSRVR.ositech.com> References: <007020085773234AAACE3B66E13C18E8D71CB3@MAILSRVR.ositech.com> Message-ID: <20060815153649.GF3622@Update.UU.SE> On Mon, Aug 14, 2006 at 04:44:01PM -0400, Katey Yu wrote: > Hello, > > When I mount /dev/mtdblock3 in flash I get block " block device > /dev/mtdblock3 is write-protected, mounting read-only". I should get > mtdblock_open? > > Could somebody tell me what's wrong? > > > > > > mount -t jffs2 /dev/mtdblock3 /var/tmp > > mount: block device /dev/mtdblock3 is write-protected, mounting > read-only You do not give very much information about your system... Ok, assuming you have set up the block device correctly. I had a similar problem that boiled down to that the driver from the manufacturer hardcoded the partition to be read-only. in my case the apropriate file was: linux/arch/arm/mach-ks8695/ks8695_mm.c The partition had been set read-only by adding: .mask_flags = MTD_WRITABLE to the partition struct. HTH //Samuel From rpurdie at rpsys.net Thu Aug 17 18:09:47 2006 From: rpurdie at rpsys.net (Richard Purdie) Date: Thu, 17 Aug 2006 23:09:47 +0100 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <1154976111.17725.8.camel@localhost.localdomain> References: <1154976111.17725.8.camel@localhost.localdomain> Message-ID: <1155852587.5530.30.camel@localhost.localdomain> Read the return value before we release the nand device otherwise the value can become corrupted by another user of chip->ops, ultimately resulting in filesystem corruption. Signed-off-by: Richard Purdie --- This fixes the jffs2 errors and filesystem corruption I reported. It should be applied for 2.6.18. drivers/mtd/nand/nand_base.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) Index: git/drivers/mtd/nand/nand_base.c =================================================================== --- git.orig/drivers/mtd/nand/nand_base.c 2006-08-17 22:46:19.000000000 +0100 +++ git/drivers/mtd/nand/nand_base.c 2006-08-17 22:47:27.000000000 +0100 @@ -1093,9 +1093,10 @@ static int nand_read(struct mtd_info *mt ret = nand_do_read_ops(mtd, from, &chip->ops); + *retlen = chip->ops.retlen; + nand_release_device(mtd); - *retlen = chip->ops.retlen; return ret; } @@ -1691,9 +1692,10 @@ static int nand_write(struct mtd_info *m ret = nand_do_write_ops(mtd, to, &chip->ops); + *retlen = chip->ops.retlen; + nand_release_device(mtd); - *retlen = chip->ops.retlen; return ret; } From katey.Yu at ositech.com Thu Aug 17 14:52:30 2006 From: katey.Yu at ositech.com (Katey Yu) Date: Thu, 17 Aug 2006 14:52:30 -0400 Subject: jffs2 Message-ID: <007020085773234AAACE3B66E13C18E8D71D96@MAILSRVR.ositech.com> Hello, What's wrong? Creating 5 MTD partitions on " Intel flash memory": 0x00000000-0x00010000 : "bootloader" 0x00010000-0x000b0000 : "kernel" 0x000b0000-0x00200000 : "filesystem" 0x00004000-0x00008000 : "config" 0x00000000-0x00200000 : "complete flash" # mount -t jffs2 /dev/mtdblock3 /var/tmp jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004: 0x000d instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008: 0x300c instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c: 0x0008 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x000a instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000014: 0x300d instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000018: 0x0006 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c: 0x0007 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020: 0x0004 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024: 0x1006 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000028: 0x2004 instead Further such events for this erase block will not be printed JFFS2: Erase block at 0x00000000 is not formatted. It will be erased jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002000: 0xc00d instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002004: 0xd870 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002008: 0x6000 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000200c: 0x300c instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002010: 0xb004 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002014: 0x5003 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002018: 0x0002 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000201c: 0x001c instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002020: 0x3038 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00002024: 0x20b4 instead Further such events for this erase block will not be printed JFFS2: Erase block at 0x00002000 is not formatted. It will be erased Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes mount: wrong fs type, bad option, bad superblock on /dev/mtdblock3, or too many mounted file systems From dedekind at yandex.ru Wed Aug 16 04:33:31 2006 From: dedekind at yandex.ru (Artem B. Bityutskiy) Date: Wed, 16 Aug 2006 12:33:31 +0400 Subject: JFFS2 problem(amit Kumar sharma) In-Reply-To: <003101c6c0ea$80b147e0$3d92340c@dsn.sec.samsung.com> References: <003101c6c0ea$80b147e0$3d92340c@dsn.sec.samsung.com> Message-ID: <44E2D85B.6030303@yandex.ru> Amit Kumar Sharma wrote: > I have one problem related to JFFS2 partition ,My partition size is 20MB > but I am able to copy more then 20 MB in this partition and strange is after > rebooting file exist with out any problem ,Can u tell me ,how JFFS2 maintain > partition size information during copy or file write command.In which area I > must check in JFFS2 or mtd. JFFS2 compresses the data so ir is possible that you fit more then 20MiB. Try to copy mp3 files - you'll you fit less then 20MiB. WRT to your question, I'm not sure what to answer - it's too general. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From samuel at Update.UU.SE Tue Aug 15 17:34:49 2006 From: samuel at Update.UU.SE (Samuel ]slund) Date: Tue, 15 Aug 2006 23:34:49 +0200 Subject: write-protected In-Reply-To: <007020085773234AAACE3B66E13C18E8D71D08@MAILSRVR.ositech.com> References: <007020085773234AAACE3B66E13C18E8D71D08@MAILSRVR.ositech.com> Message-ID: <20060815213449.GG3622@Update.UU.SE> Hi Katey, If I read that right you should be able to write to all partitions _except_ the fourth (mtd3 / mtdblock3) . HTH //Samuel On Tue, Aug 15, 2006 at 04:08:47PM -0400, Katey Yu wrote: > Hi Samuel, > > This is mtd partition. > static struct mtd_partition partition_info[]= { > > { > name: "bootloader", > ///dev/mtdblock0 > size: 64 * 1024, > offset: 0, > // mask_flags: MTD_WRITEABLE > mask_flags: 0 > }, > { > name: "kernel", ///dev/mtdblock1 > > size: 640 * 1024, > offset: MTDPART_OFS_APPEND, > // mask_flags: MTD_WRITEABLE > mask_flags: 0 > }, > { > name: "filesystem", ///dev/mtdblock2 > size: 1300 * 1024, > offset: MTDPART_OFS_APPEND, > // mask_flags: MTD_WRITEABLE > mask_flags: 0 > }, > { > name: "config", > ////dev/mtdblock3 > size: 16 * 1024, > offset: MTDPART_OFS_APPEND, > // offset: 0x4000, > mask_flags: MTD_WRITEABLE > // mask_flags: 0 > } > { > name: "complete flash", > ///dev/mtdblock4 > size: 2048 * 1024, > offset: 0, > mask_flags: 0 > // mask_flags: MTD_WRITEABLE > } > }; > > Katey > -----Original Message----- > From: Samuel ]slund [mailto:samuel at Update.UU.SE] > Sent: Tuesday, August 15, 2006 11:37 AM > To: Katey Yu > Cc: linux-mtd at lists.infradead.org > Subject: Re: write-protected > > On Mon, Aug 14, 2006 at 04:44:01PM -0400, Katey Yu wrote: > > Hello, > > > > When I mount /dev/mtdblock3 in flash I get block " block device > > /dev/mtdblock3 is write-protected, mounting read-only". I should get > > mtdblock_open? > > > > Could somebody tell me what's wrong? > > > > > > > > > > > > mount -t jffs2 /dev/mtdblock3 /var/tmp > > > > mount: block device /dev/mtdblock3 is write-protected, mounting > > read-only > > You do not give very much information about your system... > Ok, assuming you have set up the block device correctly. > > I had a similar problem that boiled down to that the driver > from the manufacturer hardcoded the partition to be read-only. > > in my case the apropriate file was: > linux/arch/arm/mach-ks8695/ks8695_mm.c > > The partition had been set read-only by adding: > .mask_flags = MTD_WRITABLE > > to the partition struct. > > HTH > //Samuel > > > From sharma.amit at samsung.com Thu Aug 17 22:27:27 2006 From: sharma.amit at samsung.com (Amit Kumar Sharma) Date: Fri, 18 Aug 2006 11:27:27 +0900 Subject: JFFS2 problem(amit Kumar sharma) In-Reply-To: <44E2D85B.6030303@yandex.ru> Message-ID: <007e01c6c26d$d9629c20$3d92340c@dsn.sec.samsung.com> Hi Artem I am able to solve this problem .I have one more. I lost data after reboot but without reboot, I try mount, umount and then mount so I did not lost any data. I find JFFS2 erase my all blocks, as it did not find any valid clean marker in OOB area. I am getting these debug messages. Unknown but compatible feature node (0x2005) found at offset 0x00380000 jffs2_check_nand_cleanmarker(): Clean marker node not detected in block at 003a00 OOB at 003a0000 was ff ff 85 19 05 ff ff ff a6 9a a9 3f ff ff ff ff ff ff ff ff jffs_check_nand_cleanmarker returned 1 Unknown but compatible feature node (0x2005) found at offset 0x003a0000 jffs2_check_nand_cleanmarker(): Cleanmarker node not detected in block at 003c00 OOB at 003c0000 was ff ff 85 19 05 ff ff ff aa 95 55 3f ff ff ff ff ff ff ff ff jffs_check_nand_cleanmarker returned 1 Unknown but compatible feature node (0x2005) found at offset 0x003c0000 jffs_check_nand_cleanmarker returned 0 jffs2_check_oob_empty returned 1 JFFS2: Erase block at 0x003e0000 is not formatted. It will be erased jffs_check_nand_cleanmarker returned 0 jffs2_check_oob_empty returned 1 JFFS2: Erase block at 0x00400000 is not formatted. It will be erased jffs_check_nand_cleanmarker returned 0 jffs2_check_oob_empty returned 1 JFFS2: Erase block at 0x00420000 is not formatted. It will be erased jffs_check_nand_cleanmarker returned 0 Thanks Amit -----Original Message----- From: Artem B. Bityutskiy [mailto:dedekind at yandex.ru] Sent: Wednesday, August 16, 2006 5:34 PM To: Amit Kumar Sharma Cc: linux-mtd at lists.infradead.org Subject: Re: JFFS2 problem(amit Kumar sharma) Amit Kumar Sharma wrote: > I have one problem related to JFFS2 partition ,My partition size is 20MB > but I am able to copy more then 20 MB in this partition and strange is after > rebooting file exist with out any problem ,Can u tell me ,how JFFS2 maintain > partition size information during copy or file write command.In which area I > must check in JFFS2 or mtd. JFFS2 compresses the data so ir is possible that you fit more then 20MiB. Try to copy mp3 files - you'll you fit less then 20MiB. WRT to your question, I'm not sure what to answer - it's too general. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From rpurdie at rpsys.net Tue Aug 15 18:29:11 2006 From: rpurdie at rpsys.net (Richard Purdie) Date: Tue, 15 Aug 2006 23:29:11 +0100 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <20060810060409.GH27094@earth.li> References: <1154976111.17725.8.camel@localhost.localdomain> <20060809093419.GA14187@earth.li> <20060810060409.GH27094@earth.li> Message-ID: <1155680951.5542.19.camel@localhost.localdomain> On Thu, 2006-08-10 at 07:04 +0100, Jonathan McDowell wrote: > A "git bisect" is flagging up 8593fbc68b0df1168995de76d1af38eb62fd6b62 > as the problem commit: > > commit 8593fbc68b0df1168995de76d1af38eb62fd6b62 > Author: Thomas Gleixner > Date: Mon May 29 03:26:58 2006 +0200 > > [MTD] Rework the out of band handling completely I found time to do some testing myself and can confirm this is the problem patch for sharpsl as well. I don't see the problem with recent git kernels if I apply: http://www.rpsys.net/openzaurus/patches/mtd_revert_oob-r0.patch which is a hack reverting the above change (only on the bits of the kernel which sharpsl needs). I'll see if I can trim the diff down and find the problem... Richard From sharma.amit at samsung.com Wed Aug 16 00:14:43 2006 From: sharma.amit at samsung.com (Amit Kumar Sharma) Date: Wed, 16 Aug 2006 13:14:43 +0900 Subject: JFFS2 problem(amit Kumar sharma) In-Reply-To: <44DAFD33.4060104@yandex.ru> Message-ID: <003101c6c0ea$80b147e0$3d92340c@dsn.sec.samsung.com> Hi Artem I have one problem related to JFFS2 partition ,My partition size is 20MB but I am able to copy more then 20 MB in this partition and strange is after rebooting file exist with out any problem ,Can u tell me ,how JFFS2 maintain partition size information during copy or file write command.In which area I must check in JFFS2 or mtd. Thanks Amit -----Original Message----- From: Artem B. Bityutskiy [mailto:dedekind at yandex.ru] Sent: Thursday, August 10, 2006 6:33 PM To: Amit Kumar Sharma Cc: linux-mtd at lists.infradead.org Subject: Re: JFFS2 problem Hello Amit, Amit Kumar Sharma wrote: > I am looking for JFFS2 stable version for kernel 2.4, Can u help me because > I am facing strange problem. My device size is 187M and JFFS2 creating 2G > file on my device. But when I checked same device partition on 2.6 kernel it > also show file size 2G "it can not be possible because MTD partition is 187M > " SO I run same test program on 2.6 kernel. it stops after creating 187M > file size. SO I wonder may it is a problem of JFFS2 version I am using with > mvl 2.4.20 kernel. I'd suggest you to contact MV instead. MTD community is mostly not interested in 2.4, so you probably won't get any help here. -- Best Regards, Artem B. Bityutskiy, St.-Petersburg, Russia. From jwboyer at gmail.com Sat Aug 19 21:34:46 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 19 Aug 2006 20:34:46 -0500 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <1155852587.5530.30.camel@localhost.localdomain> References: <1154976111.17725.8.camel@localhost.localdomain> <1155852587.5530.30.camel@localhost.localdomain> Message-ID: <625fc13d0608191834r19ce12e5raccbae011d67c25e@mail.gmail.com> On 8/17/06, Richard Purdie wrote: > Read the return value before we release the nand device otherwise the > value can become corrupted by another user of chip->ops, ultimately > resulting in filesystem corruption. > We have multiple confirmations that this patch fixes the issue reported. I agree it should go in 2.6.18. Greg, can you add this to your tree? > Signed-off-by: Richard Purdie Acked-by: Josh Boyer josh From kbb64 at hotmail.com Tue Aug 15 15:33:41 2006 From: kbb64 at hotmail.com (k bb) Date: Tue, 15 Aug 2006 14:33:41 -0500 Subject: JFFS2 speedup CS vs EBS Message-ID: Linux version 2.6.17uc0 Which of these speed up options options are standard in the 2.6.17 kernel? Are they all put in ./fs/jffs2/summary.c? Kevin B. From jaredeh at gmail.com Fri Aug 18 05:23:51 2006 From: jaredeh at gmail.com (Jared Hulbert) Date: Fri, 18 Aug 2006 02:23:51 -0700 Subject: [PATCH] CORE: Allow kernel access to struct mtd_part and PART() for axfs Message-ID: <6934efce0608180223g4591c1beja5be00f57d5173f4@mail.gmail.com> In order to mount to mtd partitions axfs (axfs.sf.net) needs the physical address found by using the mtd_part structure. This patch simply moves the definition of struct mtd_part and PART() from drivers/mtd/mtdpart.c to include/linux/mtd/partitions.h where other parts of the kernel, such as axfs, can use it. This is actually in my brand new shiny users/jehulber/mtd-intel.git all ready to be pulled. If everyone is okay with it that is. This is best way we could figure out to get access to the physical address of a given partition. We _need_ the physical address to use remap_pfn_range(). part = PART(mtd); map = part->master->priv; fsi->virtaddr = (void *)virtaddr; fsi->clean_up_callback = axfs_mtd_cleanup; fsi->callback_data = (u32) mtdnr; fsi->physaddr = (void *)(map->phys + part->offset); --- a/drivers/mtd/mtdpart.c +++ b/drivers/mtd/mtdpart.c @@ -24,23 +24,6 @@ /* Our partition linked list */ static LIST_HEAD(mtd_partitions); -/* Our partition node structure */ -struct mtd_part { - struct mtd_info mtd; - struct mtd_info *master; - u_int32_t offset; - int index; - struct list_head list; - int registered; -}; - -/* - * Given a pointer to the MTD object in the mtd_part structure, we can retrieve - * the pointer to that structure with this macro. - */ -#define PART(x) ((struct mtd_part *)(x)) - - /* * MTD methods which simply translate the effective address and pass through * to the _real_ device. --- a/include/linux/mtd/partitions.h +++ b/include/linux/mtd/partitions.h @@ -45,6 +45,22 @@ struct mtd_partition { struct mtd_info **mtdp; /* pointer to store the MTD object */ }; +/* Our partition node structure */ +struct mtd_part { + struct mtd_info mtd; + struct mtd_info *master; + u_int32_t offset; + int index; + struct list_head list; + int registered; +}; + +/* + * Given a pointer to the MTD object in the mtd_part structure, we can retrieve + * the pointer to that structure with this macro. + */ +#define PART(x) ((struct mtd_part *)(x)) + #define MTDPART_OFS_NXTBLK (-2) #define MTDPART_OFS_APPEND (-1) #define MTDPART_SIZ_FULL (0) From jwboyer at gmail.com Sat Aug 19 22:21:07 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 19 Aug 2006 21:21:07 -0500 Subject: JFFS2 speedup CS vs EBS In-Reply-To: References: Message-ID: <625fc13d0608191921j2d544b04ye48f9e1fa806e0f9@mail.gmail.com> On 8/15/06, k bb wrote: > Linux version 2.6.17uc0 > > Which of these speed up options options are standard in the 2.6.17 kernel? > Are they all put in ./fs/jffs2/summary.c? Eraseblock Summary is in 2.6.17. Centralized Summary has not yet been merged in either the upstream kernel or the MTD tree. josh From dwmw2 at infradead.org Sun Aug 20 04:17:31 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 20 Aug 2006 09:17:31 +0100 Subject: [PATCH] CORE: Allow kernel access to struct mtd_part and PART() for axfs In-Reply-To: <6934efce0608180223g4591c1beja5be00f57d5173f4@mail.gmail.com> References: <6934efce0608180223g4591c1beja5be00f57d5173f4@mail.gmail.com> Message-ID: <1156061852.22871.239.camel@pmac.infradead.org> On Fri, 2006-08-18 at 02:23 -0700, Jared Hulbert wrote: > This is best way we could figure out to get access to the physical > address of a given partition. We _need_ the physical address to use > remap_pfn_range(). If it's going to be public information I'd prefer to just add it to the struct mtd_info rather than exposing more private structures just because they happen to contain it at the moment. But really, you need to be able to coordinate with the flash driver so that you can read from it _only_ when it's in read mode. This kind of thing is what point() is for. The whole point()/unpoint() thing is probably misdesigned, so feel free to make suggestions for changing it, if it doesn't do what you want. How do you handle tearing down a mapping when the data moves from one place on the flash to another? Or does that not happen? -- dwmw2 From rhjeng at csie.nctu.edu.tw Sun Aug 20 07:40:41 2006 From: rhjeng at csie.nctu.edu.tw (Rey Cheng) Date: Sun, 20 Aug 2006 11:40:41 -0000 Subject: ALLFF blocks seems to be added to erase pending list at booting-time Message-ID: <44C0AC2D.9090408@csie.nctu.edu.tw> Hi all, I have two machine. In machine #1, I use mkfs.jffs2 to create its flash file system image. # mkfs.jffs2 -r /mnt/flash -o jffs2.img To burn the image on machine #2, I erase machine #2's flash file system. And write the image on machine #2. I use mtd_debug to erase the flash, the flash is 1MB and the image is about 700K. # mtd_debug erase /dev/mtd1 0 0x100000 # mtd_debug write /dev/mtd1 0 705136 ./jffs2.img Then I reboot the system. Because I erased the entire flash memory, and only 700K bytes were written. The "ALLFF" blocks are added to erase pending list, and jffs2 tries to mark the blocks clean at boot time. But I put the system init scripts in the flash file system. Therefore the "erasing" and "reading" occurs in the same time. Looks like a race condition. I solve the problem by umount and mount the flash file system after witting image on machine #2. Then the "ALLFF" blocks will be erased before rebooting the system. Is there any other solution? Thank you. Rey. From greg at kroah.com Sun Aug 20 21:35:45 2006 From: greg at kroah.com (Greg KH) Date: Sun, 20 Aug 2006 18:35:45 -0700 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <625fc13d0608191834r19ce12e5raccbae011d67c25e@mail.gmail.com> References: <1154976111.17725.8.camel@localhost.localdomain> <1155852587.5530.30.camel@localhost.localdomain> <625fc13d0608191834r19ce12e5raccbae011d67c25e@mail.gmail.com> Message-ID: <20060821013545.GA21012@kroah.com> On Sat, Aug 19, 2006 at 08:34:46PM -0500, Josh Boyer wrote: > On 8/17/06, Richard Purdie wrote: > >Read the return value before we release the nand device otherwise the > >value can become corrupted by another user of chip->ops, ultimately > >resulting in filesystem corruption. > > > > We have multiple confirmations that this patch fixes the issue > reported. I agree it should go in 2.6.18. > > Greg, can you add this to your tree? Add what to what tree? I need things to be a bit more specific here :) thanks, greg k-h From rpurdie at rpsys.net Mon Aug 21 05:05:10 2006 From: rpurdie at rpsys.net (Richard Purdie) Date: Mon, 21 Aug 2006 10:05:10 +0100 Subject: [PATCH] [MTD] Protect chip->ops with correct locking - fix jffs2 corruption Message-ID: <1156151110.5557.33.camel@localhost.localdomain> Read the return value before we release the nand device otherwise the value can become corrupted by another user of chip->ops, ultimately resulting in filesystem corruption. Signed-off-by: Richard Purdie Acked-by: Josh Boyer --- This fixes the jffs2 errors and filesystem corruption I reported. It should be applied for 2.6.18. On Sun, 2006-08-20 at 18:35 -0700, Greg KH wrote: > On Sat, Aug 19, 2006 at 08:34:46PM -0500, Josh Boyer wrote: > > We have multiple confirmations that this patch fixes the issue > > reported. I agree it should go in 2.6.18. > > > > Greg, can you add this to your tree? > > Add what to what tree? I need things to be a bit more specific > here :) drivers/mtd/nand/nand_base.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) Index: git/drivers/mtd/nand/nand_base.c =================================================================== --- git.orig/drivers/mtd/nand/nand_base.c 2006-08-17 22:46:19.000000000 +0100 +++ git/drivers/mtd/nand/nand_base.c 2006-08-17 22:47:27.000000000 +0100 @@ -1093,9 +1093,10 @@ static int nand_read(struct mtd_info *mt ret = nand_do_read_ops(mtd, from, &chip->ops); + *retlen = chip->ops.retlen; + nand_release_device(mtd); - *retlen = chip->ops.retlen; return ret; } @@ -1691,9 +1692,10 @@ static int nand_write(struct mtd_info *m ret = nand_do_write_ops(mtd, to, &chip->ops); + *retlen = chip->ops.retlen; + nand_release_device(mtd); - *retlen = chip->ops.retlen; return ret; } From dwmw2 at infradead.org Tue Aug 22 10:12:16 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 22 Aug 2006 15:12:16 +0100 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <20060821013545.GA21012@kroah.com> References: <1154976111.17725.8.camel@localhost.localdomain> <1155852587.5530.30.camel@localhost.localdomain> <625fc13d0608191834r19ce12e5raccbae011d67c25e@mail.gmail.com> <20060821013545.GA21012@kroah.com> Message-ID: <1156255936.29825.15.camel@pmac.infradead.org> On Sun, 2006-08-20 at 18:35 -0700, Greg KH wrote: > Add what to what tree? I need things to be a bit more specific > here :) I think he means the tree you were keeping while Linus was away. I'll sort out this and one or two more to send to Linus shortly. -- dwmw2 From jwboyer at gmail.com Tue Aug 22 10:39:10 2006 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 22 Aug 2006 09:39:10 -0500 Subject: 2.6.18-rc4 jffs2 problems In-Reply-To: <1156255936.29825.15.camel@pmac.infradead.org> References: <1154976111.17725.8.camel@localhost.localdomain> <1155852587.5530.30.camel@localhost.localdomain> <625fc13d0608191834r19ce12e5raccbae011d67c25e@mail.gmail.com> <20060821013545.GA21012@kroah.com> <1156255936.29825.15.camel@pmac.infradead.org> Message-ID: <625fc13d0608220739n18cd971s4a236b55724c0a85@mail.gmail.com> On 8/22/06, David Woodhouse wrote: > On Sun, 2006-08-20 at 18:35 -0700, Greg KH wrote: > > Add what to what tree? I need things to be a bit more specific > > here :) > > I think he means the tree you were keeping while Linus was away. I'll > sort out this and one or two more to send to Linus shortly. Yeah, I did. Sorry, I can see how that was confusing. Richard was kind enough to follow up by sending the patch directly to Greg. josh From jaredeh at gmail.com Wed Aug 23 05:22:29 2006 From: jaredeh at gmail.com (Jared Hulbert) Date: Wed, 23 Aug 2006 02:22:29 -0700 Subject: [PATCH] CORE: Allow kernel access to struct mtd_part and PART() for axfs In-Reply-To: <1156061852.22871.239.camel@pmac.infradead.org> References: <6934efce0608180223g4591c1beja5be00f57d5173f4@mail.gmail.com> <1156061852.22871.239.camel@pmac.infradead.org> Message-ID: <6934efce0608230222o68716ad5t6cdd2c69a2aafb1e@mail.gmail.com> > If it's going to be public information I'd prefer to just add it to the > struct mtd_info rather than exposing more private structures just > because they happen to contain it at the moment. You're right, but I don't like putting .phys into mtd_info as it's already in map_info. Seems like redundant duplication. And besides axfs is the only customer for this data. How about we add a new function, something like unsigned long partition_physaddr(mtd_info) in mtdpart.c to do the dirty work? > But really, you need to be able to coordinate with the flash driver so > that you can read from it _only_ when it's in read mode. This kind of > thing is what point() is for. The whole point()/unpoint() thing is > probably misdesigned, so feel free to make suggestions for changing it, > if it doesn't do what you want. As soon as I mount I point() the whole partition and unpoint() it at unmount. Works for me. Maybe someday we will include this page by page XIP into a writeable filesystem and then we'll take a more serious look at point(). But I really don't see anything wrong with point(). There is no read mode really. I assume any userspace process will have the raw flash mmap()ed directly into it's memory. So I just keep it point()ed. If the flash needs to be written to then use CONFIG_MTD_XIP or be clever with flash hardware partitions. > How do you handle tearing down a mapping when the data moves from one > place on the flash to another? Or does that not happen? Doesn't happen, its a static read only filesystem. Design is very simple. The mounting routines are I think twice the lines as the actual meat of the filesystem. From ganganwen at gmail.com Wed Aug 23 05:45:45 2006 From: ganganwen at gmail.com (wenjia) Date: Wed, 23 Aug 2006 17:45:45 +0800 Subject: I have a 1MB nor flash chip, Is it big enough for JFFS2? Message-ID: <200608231745406401974@gmail.com> hi,all I have a 1MB nor flash chip(39vf160), Is it big enough for JFFS2? if I choose JFFS2 and how much flash space should left for JFFS2? thanks for any response -------------- wenjia 2006-08-23 From steven.scholz at imc-berlin.de Wed Aug 23 11:07:27 2006 From: steven.scholz at imc-berlin.de (Steven Scholz) Date: Wed, 23 Aug 2006 17:07:27 +0200 Subject: PM for physmap.c ? Message-ID: <44EC6F2F.7070508@imc-berlin.de> Hi all, for quite some time physmap.c uses platform_{device,driver}. I wonder why it does not contain any (generic) code for power management yet, i.e. .suspend/.resume functions. Is it correct that all I would need to survive a suspend/resume cycle is something like int physmap_flash_suspend(struct platform_device *dev, pm_message_t state) { struct sa_info *info = platform_get_drvdata(dev); int ret = 0; if (info) ret = info->mtd->suspend(info->mtd); return ret; } int physmap_flash_resume(struct platform_device *dev) { struct sa_info *info = platform_get_drvdata(dev); if (info) info->mtd->resume(info->mtd); return 0; } as stolen from sa1100-flash.c? Or is PM done at some other/higher layer of the MTD stuff? Cheers, -- Steven From posaune at hotmail.com Wed Aug 23 14:12:31 2006 From: posaune at hotmail.com (Han Chang) Date: Wed, 23 Aug 2006 11:12:31 -0700 Subject: Issue with h/w ecc based NAND driver. Message-ID: Hi there, I'm using a NAND with h/w ecc. When a block is erased, both main data and oob are set to 0xff, and if the driver read the main data in the page with hardware enabled ecc, the 0xff in the oob is not the right ecc code, so the ecc mechanism in the h/w try to recover the error and trash the content in the main data area. I tried to set the right ecc code in the oob for every page whenever a block is erased. But then the problem is with page programming. When write a page, the h/w ecc controller generates the ecc code and write it to the oob, since the oob is already written once during erase, the 2nd write to the oob is not taken well. So when read back the same page, it causes ecc error again. I would appreciate very much if someone can shed some light on this kind of delimma. Thanks, Han From joern at wohnheim.fh-wedel.de Thu Aug 24 09:44:30 2006 From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel) Date: Thu, 24 Aug 2006 15:44:30 +0200 Subject: [RFC] LogFS Message-ID: <20060824134430.GB17132@wohnheim.fh-wedel.de> For the last 16 month, I've been hacking on a small filesystem. It has progress far enough that it shouldn't be a total embarrassment to show the code, but still needs quite a bit of work. Anyhow, in case people are interested to have a look... comments are very welcome. J?rn -- ...one more straw can't possibly matter... -- Kirby Bakken fs/Kconfig | 13 fs/Makefile | 1 fs/logfs/CREDITS | 18 fs/logfs/Makefile | 9 fs/logfs/NAMES | 32 + fs/logfs/dir.c | 464 +++++++++++++++++++++++ fs/logfs/file.c | 82 ++++ fs/logfs/gc.c | 517 ++++++++++++++++++++++++++ fs/logfs/inode.c | 385 +++++++++++++++++++ fs/logfs/journal.c | 216 +++++++++++ fs/logfs/logfs.h | 431 ++++++++++++++++++++++ fs/logfs/readwrite.c | 992 +++++++++++++++++++++++++++++++++++++++++++++++++++ fs/logfs/super.c | 435 ++++++++++++++++++++++ 13 files changed, 3595 insertions(+) --- logfs3/fs/Kconfig~logfs 2006-08-24 15:35:33.000000000 +0200 +++ logfs3/fs/Kconfig 2006-08-24 15:39:42.000000000 +0200 @@ -1230,6 +1230,19 @@ config JFFS2_CMODE_SIZE endchoice +config LOGFS + tristate "Log Filesystem (EXPERIMENTAL)" + depends on EXPERIMENTAL + help + Successor of JFFS2, using explicit filesystem hierarchy. + Continuing with the long tradition of calling the filesystem + exactly what it is not, LogFS is a journaled filesystem, + while JFFS and JFFS2 were true log-structured filesystems. + The hybrid structure of journaled filesystems promise to + scale better to larger sized. + + If unsure, say N. + config CRAMFS tristate "Compressed ROM file system support (cramfs)" select ZLIB_INFLATE --- logfs3/fs/Makefile~logfs 2006-08-24 15:35:33.000000000 +0200 +++ logfs3/fs/Makefile 2006-08-24 15:39:42.000000000 +0200 @@ -84,6 +84,7 @@ obj-$(CONFIG_UFS_FS) += ufs/ obj-$(CONFIG_EFS_FS) += efs/ obj-$(CONFIG_JFFS_FS) += jffs/ obj-$(CONFIG_JFFS2_FS) += jffs2/ +obj-$(CONFIG_LOGFS) += logfs/ obj-$(CONFIG_AFFS_FS) += affs/ obj-$(CONFIG_ROMFS_FS) += romfs/ obj-$(CONFIG_QNX4FS_FS) += qnx4/ --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/CREDITS 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,18 @@ +Testing +2005-2006 Joern Engel +2006 Arnd Bergmann + +Design (in rough chronological order - and some may be unaware of the fact): +1991 Mendel Rosenblum +1991 John K. Ousterhout +2005-2006 Joern Engel +2005-2006 Arnd Bergmann +2005 David Woodhouse +2005-2006 Dirk Bolte +2005 Carsten Otte +2006 Martin Schwidefski +2006 Ferenc Havasi +2006 Hubertus Franke + +Implementation: +2005-2006 Joern Engel --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/NAMES 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,32 @@ +This filesystem started with the codename "Logfs", which was actually +a joke at the time. Logfs was to replace JFFS2, the journaling flash +filesystem (version 2). JFFS2 was actually a log structured +filesystem in its purest form, so the name described just what it was +not. Logfs was planned as a journaling filesystem, so its name would +be in the same tradition of non-description. + +Apart from the joke, "Logfs" was only intended as a codename, later to +be replaced by something better. Some ideas from various people were: +logfs +jffs3 +jefs +engelfs +poofs +crapfs +sweetfs +cutefs +dynamic journaling fs - djofs +tfsfkal - the file system formerly known as logfs + +Later it turned out that while having a journal, Logfs has borrowed so +many concepts from log structured filesystems that the name actually +made some sense. + +Yet later, Arnd noticed that Logfs was to scale logarithmically with +increasing flash sizes, where JFFS2 scales linearly. What a nice +coincidence. Even better, its successor can be called Log2fs, +emphasizing this point. + +So to this day, I still like "Logfs" and cannot come up with a better +name. And unless someone has the stroke of a genius or there is +massive opposition against this name, I'd like to just keep it. --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/Makefile 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,9 @@ +obj-$(CONFIG_LOGFS) += logfs.o + +logfs-y += dir.o +logfs-y += file.o +logfs-y += gc.o +logfs-y += inode.o +logfs-y += journal.o +logfs-y += readwrite.o +logfs-y += super.o --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/logfs.h 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,431 @@ +#ifndef logfs_h +#define logfs_h + +#include +#include + +/** + * Throughout the logfs code, we're constantly dealing with blocks at + * various positions or offsets. To remove confusion, we stricly + * distinguish between a "position" - the logical position within a + * file and an "offset" - the physical location within the device. + * + * Any usage of the term offset for a logical location or position for + * a physical one is a bug and should get fixed. + */ + +/** + * Block are allocated in one of several segments depending on their + * level. The following levels are used: + * 0-1 - reserved + * 2 - gc recycled blocks + * 3 - new data blocks + * 4 - replacement blocks + * 5 - i1 indirect blocks + * 6 - i2 indirect blocks + * 7 - i3 indirect blocks + * 8 - i4 indirect blocks + * 9 - i5 indirect blocks + * 10 - ifile data blocks + * 11 - ifile i1 indirect blocks + * 12 - ifile i2 indirect blocks + * 13 - ifile i3 indirect blocks + * 14 - ifile i4 indirect blocks + * 15 - ifile i5 indirect blocks + * + * Levels 5-15 are necessary for robust gc operations and help seperate + * short-lived metadata from longer-lived file data. Further, file data + * is seperated into several segments based on simple heuristics. Old + * data recycled during gc operation is expected to be long-lived. New + * data is of uncertain life expectancy. New data used to replace older + * blocks in existing files is expected to be short-lived. + */ + + +typedef __be16 be16; +typedef __be32 be32; +typedef __be64 be64; + +typedef u64 pos_t; + +static inline pos_t be64_to_pos(const be64 p) +{ + return (__force pos_t) be64_to_cpu(p); +} + +static inline be64 pos_to_be64(const pos_t p) +{ + return cpu_to_be64((__force u64) p); +} + +#define packed __attribute__((__packed__)) + + +#undef TRACE +#if 0 +#define TRACE() _TRACE() +#else +#define TRACE() +#endif + +#define _TRACE() do { \ + printk("trace: %s:%d: ", __FILE__, __LINE__); \ + print_symbol("%s", (long)__builtin_return_address(0)); \ + printk("->%s\n", __func__); \ +} while(0) + + +#define LOGFS_MAGIC 0xb21f205ac97e8168ull +#define LOGFS_MAGIC_U32 0xc97e8168ull + + +#define LOGFS_BLOCK_SECTORS (8) +#define LOGFS_BLOCK_BITS (9) /* 512 pointers, used for shifts */ +#define LOGFS_BLOCKSIZE (4096ull) +#define LOGFS_BLOCK_FACTOR (LOGFS_BLOCKSIZE / sizeof(u64)) +#define LOGFS_BLOCK_MASK (LOGFS_BLOCK_FACTOR-1) + +#define I0_BLOCKS (4+16) +#define I1_BLOCKS LOGFS_BLOCK_FACTOR +#define I2_BLOCKS (LOGFS_BLOCK_FACTOR * I1_BLOCKS) +#define I3_BLOCKS (LOGFS_BLOCK_FACTOR * I2_BLOCKS) +#define I4_BLOCKS (LOGFS_BLOCK_FACTOR * I3_BLOCKS) +#define I5_BLOCKS (LOGFS_BLOCK_FACTOR * I4_BLOCKS) + +#define I1_INDEX (4+16) +#define I2_INDEX (5+16) +#define I3_INDEX (6+16) +#define I4_INDEX (7+16) +#define I5_INDEX (8+16) + +#define LOGFS_EMBEDDED_FIELDS (9+16) + +#define LOGFS_EMBEDDED_SIZE (LOGFS_EMBEDDED_FIELDS * sizeof(u64)) +#define LOGFS_I0_SIZE (I0_BLOCKS * LOGFS_BLOCKSIZE) +#define LOGFS_I1_SIZE (I1_BLOCKS * LOGFS_BLOCKSIZE) +#define LOGFS_I2_SIZE (I2_BLOCKS * LOGFS_BLOCKSIZE) +#define LOGFS_I3_SIZE (I3_BLOCKS * LOGFS_BLOCKSIZE) +#define LOGFS_I4_SIZE (I4_BLOCKS * LOGFS_BLOCKSIZE) +#define LOGFS_I5_SIZE (I5_BLOCKS * LOGFS_BLOCKSIZE) + +#define LOGFS_MAX_INDIRECT (5) +#define LOGFS_MAX_LEVELS (3) +//#define LOGFS_MAX_LEVELS (LOGFS_MAX_INDIRECT + 1) +#define LOGFS_SEGMENTS (2 * LOGFS_MAX_LEVELS) + + +struct logfs_disk_super { + be64 ds_magic; + be32 ds_segment_size; + be32 ds_block_size; + + be64 ds_journal_ofs; + be64 ds_journal_len; + + u8 reserved; + u8 ds_ifile_levels; /* max level of ifile */ + u8 ds_iblock_levels; /* max level of regular files */ + u8 ds_data_levels; /* number of segments to leaf blocks */ + be64 ds_root_reserve; + + be64 ds_filesystem_size; + be64 ds_feature_incompat; + + be64 ds_feature_ro_compat; + be64 ds_feature_compat; + + be32 ds_anchor_size; + be32 ds_sum_start; +}packed; + + +#define LOGFS_IF_VALID 0x00000001 /* inode exists */ +#define LOGFS_IF_EMBEDDED 0x00000002 /* data embedded in block pointers */ +#define LOGFS_IF_INVALID 0x80000000 /* inode does not exist */ +struct logfs_disk_inode { + be16 di_mode; + be16 di_pad; + be32 di_flags; + be32 di_uid; + be32 di_gid; + + be64 di_ctime; + be64 di_mtime; + + be32 di_refcount; + be32 di_generation; /* for nfs file handles */ + be64 di_blocks; + + be64 di_size; + be64 di_data[LOGFS_EMBEDDED_FIELDS]; +}packed; + + +#define LOGFS_MAX_NAMELEN 245 +struct logfs_disk_dentry { + be64 ino; /* inode pointer */ + be16 namelen; + u8 type; + u8 name[LOGFS_MAX_NAMELEN]; +}packed; + + +struct logfs_disk_block { + be64 ino; + be64 pos; +}packed; + + +struct logfs_disk_sum { + /* footer */ + be32 erase_count; + u8 level; + u8 pad[3]; + union { + be64 ofs; + be64 gec; + }; + struct logfs_disk_block blocks[0]; +}packed; + + +struct logfs_anchor { + be64 da_maxec; /* maximal erase count */ + be64 da_gec; /* global erase count */ + + be64 da_sweeper; /* current position of gc "sweeper" */ + be64 da_last_ino; + + be64 da_size; + be64 da_data[LOGFS_EMBEDDED_FIELDS]; +}packed; + + +enum { + JE_ANCHOR = 1, + JE_SPILLOUT = 2, +}; + + +struct logfs_journal_entry { + be16 je_type; + be16 pad0; + be32 pad1; + be64 je_version; + union { + struct logfs_anchor da; + }; +}packed; + + +//////////////////////////////////////////////////////////////////////////////// +//////////////////////////////////////////////////////////////////////////////// + + +#define LOGFS_SUPER(sb) ((struct logfs_super*)(sb->s_fs_info)) +#define LOGFS_INODE(inode) container_of(inode, struct logfs_inode, vfs_inode) + + + /* 0 reserved for gc markers */ +#define LOGFS_INO_MASTER 1 /* inode file */ +#define LOGFS_INO_ROOT 2 /* root directory */ +#define LOGFS_INO_JOURNAL 3 /* journal */ +#define LOGFS_INO_ATIME 4 /* atime for all inodes */ +#define LOGFS_INO_BAD_BLOCKS 5 /* bad blocks */ +#define LOGFS_INO_OBSOLETE 6 /* obsolete block count */ +#define LOGFS_INO_ERASE_COUNT 7 /* erase count */ +#define LOGFS_RESERVED_INOS 16 + + +struct logfs_block { + u64 ino; + pos_t pos; +}; + + +struct logfs_super; +struct logfs_segment { + struct logfs_super *super; + int active; + u64 ofs; + u16 cur_block; + /* footer */ + u32 erase_count; + u8 level; + struct logfs_block blocks[0]; +}; + + +struct logfs_super { + struct super_block *s_sb; /* should get removed... */ + struct mtd_info *s_mtd; /* underlying device */ + struct inode *s_master_inode; /* ifile */ + /* gc.c fields */ + long s_segsize; /* size of a segment */ + long s_no_segs; /* segments on device */ + long s_blocksize; /* size of a block */ + long s_no_blocks; /* blocks per segment */ + u64 s_last; /* position of last used seg */ + u64 s_size; /* filesystem size */ + void *s_gc_buf; /* copy buf for cleansing */ + struct logfs_segment *s_segs[LOGFS_SEGMENTS]; /* segment array */ + u8 *s_valid_count; /* # of valid block per seg */ + long s_no_free_segs; /* # of free segments */ + u64 s_maxec; /* max erase count */ + u64 s_gec; /* global erase count */ + u64 s_sweeper; /* current sweeper pos */ + u8 s_ifile_levels; /* max level of ifile */ + u8 s_iblock_levels; /* max level of regular files */ + u8 s_data_levels; /* # of segments to leaf block*/ + u8 s_total_levels; /* sum of above three */ + /* inode.c fields */ + spinlock_t s_ino_lock; /* lock s_last_ino on 32bit */ + u64 s_last_ino; /* highest ino used */ + struct inode *s_write_inode; /* inode currently written */ + struct mutex s_write_inode_mutex; /* only one deletion at once */ + /* journal.c fields */ + struct mutex s_log_sem; + struct logfs_journal_entry *s_je; /* new journal entry */ + u64 s_log_ofs; + u64 s_log_len; + u64 s_last_version; + u64 s_anchor_ofs; + u32 s_anchor_size; /* size of anchor */ + u32 s_sum_start; /* start of summary in anchor */ + /* readwrite.c fields */ + struct mutex s_r_sem; + struct mutex s_w_sem; + be64 *s_rblock; + be64 *s_wblock[LOGFS_MAX_INDIRECT+1]; + u64 s_free; /* number of free blocks */ + u64 s_gc_reserve; + u64 s_root_reserve; +}; + + +struct logfs_inode { + struct inode vfs_inode; + u64 li_data[LOGFS_EMBEDDED_FIELDS]; + u32 li_flags; + u64 li_blocks; +}; + + +static inline size_t logfs_summary_size(struct logfs_super *super) +{ + return super->s_no_blocks * sizeof(struct logfs_block); +} +static inline size_t logfs_segstruct_size(struct logfs_super *super) +{ + return sizeof(struct logfs_segment) + logfs_summary_size(super); +} + + +static inline pgoff_t logfs_index(u64 pos) +{ + return pos / LOGFS_BLOCKSIZE; +} + + +static inline struct inode *logfs_iget(struct super_block *sb, ino_t ino) +{ + struct logfs_super *super = LOGFS_SUPER(sb); + if (ino == LOGFS_INO_MASTER) /* never iget this "inode"! */ + return super->s_master_inode; + return iget(sb, ino); +} +static inline void logfs_iput(struct inode *inode) +{ + if (inode->i_ino == LOGFS_INO_MASTER) /* never iput it either! */ + return; + iput(inode); +} + + +static inline struct logfs_disk_sum *alloc_disk_sum(struct logfs_super *super) +{ + return kmalloc(logfs_summary_size(super), GFP_ATOMIC); +} +static inline void free_disk_sum(struct logfs_disk_sum *sum) +{ + kfree(sum); +} + + +/* dir.c */ +extern struct inode_operations logfs_dir_iops; +extern struct file_operations logfs_dir_fops; + + +/* file.c */ +extern struct inode_operations logfs_reg_iops; +extern struct file_operations logfs_reg_fops; +extern struct address_space_operations logfs_reg_aops; + +int logfs_setattr(struct dentry *dentry, struct iattr *iattr); + + +/* gc.c */ +void logfs_gc_pass(struct logfs_super *super); +s64 logfs_get_free_block(struct logfs_super*super, int level, u64 ino, pos_t pos); +int logfs_init_gc(struct logfs_super *super); +void logfs_cleanup_gc(struct logfs_super *super); +/* still gc.c, but should get moved to segment.c */ +int logfs_erase_segment(struct logfs_super *super, u64 ofs); + +void logfs_disk_to_sum(struct logfs_super *super, struct logfs_segment *seg, + struct logfs_disk_sum *sum); +void logfs_sum_to_disk(struct logfs_super *super, struct logfs_segment *seg, + struct logfs_disk_sum *sum); +int logfs_init_segments(struct logfs_super *super); +void logfs_cleanup_segments(struct logfs_super *super); + + +/* inode.c */ +extern struct super_operations logfs_super_operations; + +struct inode *logfs_new_inode(struct inode *dir, int mode); +struct inode *logfs_new_master_inode(struct super_block *sb); +int logfs_init_inode_cache(void); +void logfs_destroy_inode_cache(void); + + +/* journal.c */ +int logfs_write_anchor(struct inode *inode); +int logfs_init_log(struct super_block *sb); +void logfs_cleanup_log(struct super_block *sb); + + +/* readwrite.c */ +int logfs_inode_read(struct inode *inode, void *buf, size_t n, loff_t _pos); +int logfs_inode_write_nolock(struct inode *inode, const void *buf, size_t n, + loff_t _pos); +int logfs_inode_write(struct inode *inode, const void *buf, size_t n, + loff_t pos); +int logfs_inode_write_loop(struct inode *inode, const void *buf, size_t n, + loff_t _pos); + +int logfs_readpage(struct file *file, struct page *page); +int logfs_write_buf(struct inode *inode, pgoff_t index, void *buf); +int logfs_rewrite_block(struct inode *inode, pgoff_t index, u64 ofs, void *buf); +int logfs_is_valid_block(struct super_block *sb, u64 ofs, u64 ino, u64 pos); +void logfs_truncate(struct inode *inode); + +int logfs_init_rw(struct logfs_super *super); +void logfs_cleanup_rw(struct logfs_super *super); +void logfs_set_blocks(struct inode *inode, u64 no); + +/* super.c */ +int mtderase(struct mtd_info *mtd, loff_t ofs, size_t len); +int mtdread(struct mtd_info *mtd, loff_t ofs, size_t len, void *buf); +int mtdwrite(struct mtd_info *mtd, loff_t ofs, size_t len, void *buf); +int logfs_statfs(struct dentry *dentry, struct kstatfs *stats); + + +/* symlink.c */ + + +#define EOF 256 + + +#endif --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/dir.c 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,464 @@ +#include +#include + +#include "logfs.h" + +static inline u8 logfs_type(struct inode *inode) +{ + return (inode->i_mode >> 12) & 15; +} + + +static inline void logfs_inc_count(struct inode *inode) +{ + inode->i_nlink++; + mark_inode_dirty(inode); +} + + +static inline void logfs_dec_count(struct inode *inode) +{ + inode->i_nlink--; + mark_inode_dirty(inode); +} + + +typedef int (*dir_callback)(struct inode *dir, struct dentry *dentry, + struct logfs_disk_dentry *dd, loff_t pos); + + +static int __logfs_dir_walk(struct inode *dir, struct dentry *dentry, + dir_callback handler, struct logfs_disk_dentry *dd, loff_t *pos) +{ + struct qstr *name = dentry ? &dentry->d_name : NULL; + int ret; + + TRACE(); + BUG_ON(sizeof(*dd) != 256); + BUG_ON(i_size_read(dir) % sizeof(*dd)); + for (; ; (*pos)++) { + ret = logfs_inode_read(dir, dd, sizeof(*dd),(*pos)*sizeof(*dd)); + if (ret == -EOF) + return 0; + if (ret) + return ret; + if (be16_to_cpu(dd->namelen) == 0) + continue; + + if (name) { + if (name->len != be16_to_cpu(dd->namelen)) + continue; + if (memcmp(name->name, dd->name, name->len)) + continue; + } + + return handler(dir, dentry, dd, *pos); + } + return ret; +} + + +static int logfs_dir_walk(struct inode *dir, struct dentry *dentry, + dir_callback handler) +{ + struct logfs_disk_dentry dd; + loff_t pos = 0; + return __logfs_dir_walk(dir, dentry, handler, &dd, &pos); +} + + +static int logfs_lookup_handler(struct inode *dir, struct dentry *dentry, + struct logfs_disk_dentry *dd, loff_t pos) +{ + struct inode *inode; + + TRACE(); + inode = iget(dir->i_sb, be64_to_cpu(dd->ino)); + if (!inode) + return -EIO; + return PTR_ERR(d_splice_alias(inode, dentry)); +} + + +static struct dentry *logfs_lookup(struct inode *dir, struct dentry *dentry, + struct nameidata *nd) +{ + struct dentry *ret; + + TRACE(); + ret = ERR_PTR(logfs_dir_walk(dir, dentry, logfs_lookup_handler)); + return ret; +} + + +/* unlink currently only makes the name length zero */ +static int logfs_unlink_handler(struct inode *dir, struct dentry *dentry, + struct logfs_disk_dentry *dd, loff_t pos) +{ + TRACE(); + dd->namelen = 0; + return logfs_inode_write(dir, dd, sizeof(*dd), pos*sizeof(*dd)); +} + + +static void logfs_post_unlink(struct inode *dir, struct inode *inode) +{ + inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME; + logfs_dec_count(inode); + printk("unlink: %lx, %x\n", inode->i_ino, inode->i_nlink); + mark_inode_dirty(dir); +} + + +static int logfs_unlink(struct inode *dir, struct dentry *dentry) +{ + struct inode *inode = dentry->d_inode; + int ret; + + TRACE(); + ret = logfs_dir_walk(dir, dentry, logfs_unlink_handler); + if (ret) + return ret; + + logfs_post_unlink(dir, inode); + return 0; +} + + +static int logfs_empty_handler(struct inode *dir, struct dentry *dentry, + struct logfs_disk_dentry *dd, loff_t pos) +{ + TRACE(); + return -ENOTEMPTY; +} +static inline int logfs_empty_dir(struct inode *dir) +{ + return logfs_dir_walk(dir, NULL, logfs_empty_handler) == 0; +} + + +static void logfs_post_rmdir(struct inode *dir, struct inode *inode) +{ + inode->i_size = 0; /* FIXME: why this? */ + logfs_dec_count(inode); + logfs_dec_count(dir); +} + + +static int logfs_rmdir(struct inode *dir, struct dentry *dentry) +{ + struct inode *inode = dentry->d_inode; + int err; + + TRACE(); + if (!logfs_empty_dir(inode)) + return -ENOTEMPTY; + + err = logfs_unlink(dir, dentry); + if (err) + return err; + + logfs_post_rmdir(dir, inode); + return 0; +} + + +/* FIXME: readdir currently has it's own dir_walk code. I don't see a good + * way to combine the two copies */ +#define IMPLICIT_NODES 2 +static int __logfs_readdir(struct file *file, void *buf, filldir_t filldir) +{ + struct logfs_disk_dentry dd; + loff_t pos = file->f_pos - IMPLICIT_NODES; + int err; + + TRACE(); + BUG_ON(pos<0); + for (;; pos++) { + struct inode *dir = file->f_dentry->d_inode; + err = logfs_inode_read(dir, &dd, sizeof(dd), pos*sizeof(dd)); + if (err == -EOF) + break; + if (err) + return err; + + /* zero-length indicates deleted dentries */ + if (be16_to_cpu(dd.namelen) == 0) + continue; + + if (filldir(buf, dd.name, be16_to_cpu(dd.namelen), pos, + be64_to_cpu(dd.ino), dd.type)) + break; + } + + file->f_pos = pos + IMPLICIT_NODES; + return 0; +} + + +static int logfs_readdir(struct file *file, void *buf, filldir_t filldir) +{ + struct inode *inode = file->f_dentry->d_inode; + + TRACE(); + if (file->f_pos < 0) + return -EINVAL; + + if (file->f_pos == 0) { + if (filldir(buf, ".", 1, 1, inode->i_ino, DT_DIR) < 0) + return 0; + file->f_pos++; + } + if (file->f_pos == 1) { + ino_t pino = parent_ino(file->f_dentry); + if (filldir(buf, "..", 2, 2, pino, DT_DIR) < 0) + return 0; + file->f_pos++; + } + + return __logfs_readdir(file, buf, filldir); +} + + +static int logfs_write_dir(struct inode *dir, struct dentry *dentry, + struct inode *inode) +{ + struct logfs_disk_dentry dd; + int err; + + memset(&dd, 0, sizeof(dd)); + dd.ino = cpu_to_be64(inode->i_ino); + dd.namelen = cpu_to_be16(dentry->d_name.len); + BUG_ON(dentry->d_name.len > LOGFS_MAX_NAMELEN); + memcpy(dd.name, dentry->d_name.name, dentry->d_name.len); + dd.type = logfs_type(inode); + err = logfs_inode_write(dir, &dd, sizeof(dd), i_size_read(dir)); + if (err) { + logfs_dec_count(inode); + iput(inode); + return err; + } + d_instantiate(dentry, inode); + return 0; +} + + +/* FIXME: This should really be somewhere in the 64bit area. */ +#define LOGFS_LINK_MAX (2^30) +static int logfs_mkdir(struct inode *dir, struct dentry *dentry, int mode) +{ + struct inode *inode; + int ret; + + TRACE(); + if (dir->i_nlink >= LOGFS_LINK_MAX) + return -EMLINK; + + logfs_inc_count(dir); + + /* FIXME: why do we have to fill in S_IFDIR, while the mode is + * correct for mknod, creat, etc.? + */ + inode = logfs_new_inode(dir, S_IFDIR | mode); + if (IS_ERR(inode)) { + logfs_dec_count(dir); + return PTR_ERR(inode); + } + + inode->i_op = &logfs_dir_iops; + inode->i_fop = &logfs_dir_fops; + + logfs_inc_count(inode); + + ret = logfs_write_dir(dir, dentry, inode); + if (ret) { + logfs_dec_count(inode); + logfs_dec_count(inode); + iput(inode); + logfs_dec_count(dir); + } + return ret; +} + + +static int logfs_create(struct inode *dir, struct dentry *dentry, int mode, + struct nameidata *nd) +{ + struct inode *inode; + + TRACE(); + inode = logfs_new_inode(dir, mode); + if (IS_ERR(inode)) + return PTR_ERR(inode); + + inode->i_op = &logfs_reg_iops; + inode->i_fop = &logfs_reg_fops; + inode->i_mapping->a_ops = &logfs_reg_aops; + mark_inode_dirty(inode); + + return logfs_write_dir(dir, dentry, inode); +} + + +static int logfs_mknod(struct inode *dir, struct dentry *dentry, int mode, + dev_t rdev) +{ + struct inode *inode; + int ret; + + TRACE(); + BUG_ON(dentry->d_name.len > LOGFS_MAX_NAMELEN); + + inode = logfs_new_inode(dir, mode); + ret = PTR_ERR(inode); + if (IS_ERR(inode)) + goto out; + + init_special_inode(inode, mode, rdev); + mark_inode_dirty(inode); + + ret = logfs_write_dir(dir, dentry, inode); +out: + return ret; +} + + +static struct inode_operations ext2_symlink_iops = { + .readlink = generic_readlink, + .follow_link = page_follow_link_light, +}; + + +static int logfs_symlink(struct inode *dir, struct dentry *dentry, + const char *target) +{ + size_t len = strlen(target) + 1; + struct inode *inode; + int ret; + + inode = logfs_new_inode(dir, S_IFLNK | S_IRWXUGO); + if (IS_ERR(inode)) + return PTR_ERR(inode); + + inode->i_op = &ext2_symlink_iops; + inode->i_mapping->a_ops = &logfs_reg_aops; + + ret = logfs_inode_write_loop(inode, target, len, 0); + if (ret) { + logfs_dec_count(inode); + iput(inode); + return ret; + } + return logfs_write_dir(dir, dentry, inode); +} + + +static int logfs_permission(struct inode *inode, int mask, struct nameidata *nd) +{ + return generic_permission(inode, mask, NULL); +} + + +static int logfs_link(struct dentry *old_dentry, struct inode *dir, + struct dentry *dentry) +{ + struct inode *inode = old_dentry->d_inode; + + TRACE(); + if (inode->i_nlink >= LOGFS_LINK_MAX) + return -EMLINK; + + inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME; + logfs_inc_count(inode); + atomic_inc(&inode->i_count); + + return logfs_write_dir(dir, dentry, inode); +} + + +static int logfs_nop_handler(struct inode *dir, struct dentry *dentry, + struct logfs_disk_dentry *dd, loff_t pos) +{ + return 0; +} +static inline int logfs_get_dd(struct inode *dir, struct dentry *dentry, + struct logfs_disk_dentry *dd, loff_t *pos) +{ + return __logfs_dir_walk(dir, dentry, logfs_nop_handler, dd, pos); +} + + +static int logfs_rename(struct inode *old_dir, struct dentry *old_dentry, + struct inode *new_dir, struct dentry *new_dentry) +{ + struct inode *old_inode = old_dentry->d_inode; + struct inode *new_inode = new_dentry->d_inode; + int isdir = S_ISDIR(old_inode->i_mode); + int err; + + TRACE(); + /* FIXME: request sync semaphore */ + if (new_inode) { /* replace */ + struct logfs_disk_dentry new_dd; + loff_t new_pos = 0; + + BUG_ON(isdir && !S_ISDIR(new_inode->i_mode)); + if (isdir) { + if (!logfs_empty_dir(new_inode)) + return -ENOTEMPTY; + } + + err = logfs_get_dd(new_dir, new_dentry, &new_dd, &new_pos); + BUG_ON(err); /* target should exist */ + + /* replace old dd */ + new_dd.ino = cpu_to_be64(old_inode->i_ino); + new_dd.type = logfs_type(old_inode); + err = logfs_inode_write(new_dir, &new_dd, sizeof(new_dd), + new_pos*sizeof(new_dd)); + if (err) + return err; + + logfs_post_unlink(new_dir, new_inode); + + logfs_inc_count(old_inode); + err = logfs_unlink(old_dir, old_dentry); + BUG_ON(err); /* FUCK! we need to clean things up instead */ + + /* remove new_inode from old_dir - old_inode has moved to + * new_dir, so this is correct */ + if (isdir) + logfs_post_rmdir(old_dir, new_inode); + + return err; + } else { /* just a move */ + err = logfs_link(old_dentry, new_dir, new_dentry); + if (err) + return err; + + if (isdir) { + logfs_inc_count(new_dir); + return logfs_rmdir(old_dir, old_dentry); + } else { + return logfs_unlink(old_dir, old_dentry); + } + } +} + + +struct inode_operations logfs_dir_iops = { + .create = logfs_create, + .link = logfs_link, + .lookup = logfs_lookup, + .mkdir = logfs_mkdir, + .mknod = logfs_mknod, + .rename = logfs_rename, + .rmdir = logfs_rmdir, + .permission = logfs_permission, + .symlink = logfs_symlink, + .unlink = logfs_unlink, +}; +struct file_operations logfs_dir_fops = { + .readdir = logfs_readdir, + .read = generic_read_dir, +}; --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/file.c 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,82 @@ +#include +#include + +#include "logfs.h" + + +static int logfs_prepare_write(struct file *file, struct page *page, + unsigned start, unsigned end) +{ + void *buf; + + TRACE(); + buf = kmap(page); + if (!PageUptodate(page)) { + /* FIXME: shouldn't we read instead? */ + memset(buf, 0, PAGE_CACHE_SIZE); + SetPageUptodate(page); + } + + //set_page_dirty(page); + kunmap(page); + + return 0; +} + + +static int logfs_commit_write(struct file *file, struct page *page, + unsigned start, unsigned end) +{ + struct inode *inode = page->mapping->host; + pgoff_t index = page->index; + void *buf; + int ret; + + TRACE(); + pr_debug("ino: %lu, page:%lu, start: %d, len:%d\n", inode->i_ino, + page->index, start, end-start); + BUG_ON(PAGE_CACHE_SIZE != LOGFS_BLOCKSIZE); + BUG_ON(page->index > I3_BLOCKS); + + if (start == end) + return 0; /* FIXME: do we need to update inode? */ + + if (i_size_read(inode) < (index << PAGE_CACHE_SHIFT) + end) { + i_size_write(inode, (index << PAGE_CACHE_SHIFT) + end); + mark_inode_dirty(inode); + } + + buf = kmap(page); + ret = logfs_write_buf(inode, index, buf); + kunmap(page); + return ret; +} + + +static int logfs_writepage(struct page *page, struct writeback_control *wbc) +{ + BUG(); + return 0; +} + + +struct inode_operations logfs_reg_iops = { + .truncate = logfs_truncate, +}; + + +struct file_operations logfs_reg_fops = { + .llseek = generic_file_llseek, + .open = generic_file_open, + .read = generic_file_read, + .write = generic_file_write, +}; + + +struct address_space_operations logfs_reg_aops = { + .commit_write = logfs_commit_write, + .prepare_write = logfs_prepare_write, + .readpage = logfs_readpage, + .set_page_dirty = __set_page_dirty_nobuffers, + .writepage = logfs_writepage, +}; --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/gc.c 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,517 @@ +#include +#include + +#include "logfs.h" + + +static int logfs_is_valid_block_gc(struct super_block *sb, u64 ofs, u64 ino, + pos_t pos) +{ + /* Umount closes a segment with free blocks remaining. Those + * blocks are by definition invalid. */ + if (ino == -1) + return 0; + + /* Journal blocks are by definition valid. They will get + * erased from journal.c sooner or later. */ + if (ino == LOGFS_INO_JOURNAL) + return 1; + + return logfs_is_valid_block(sb, ofs, ino, pos); +} + + +static int logfs_valid_count(struct logfs_super *super, u64 seg_offset) +{ + struct mtd_info *mtd = super->s_mtd; + struct logfs_disk_sum *sum; + int end = super->s_no_blocks-1; + u64 footer = seg_offset + end * super->s_blocksize; + int valid = 0; + int i, err; + + /* Superblock. Don't touch, or else... */ + if (seg_offset == 0) + return end; + /* Primary journal segments. Don't touch, or else... */ + if ((seg_offset >= super->s_log_ofs) + && (seg_offset - super->s_log_ofs < super->s_log_len)) + return end; + + /* Currently open segments */ + for (i=0; is_segs[i]; + if (seg->active && (seg->ofs == seg_offset)) + return end; + } + + sum = alloc_disk_sum(super); + err = mtdread(mtd, footer, logfs_summary_size(super), sum); + BUG_ON(err); + + for (i=0; iblocks[i].ino); + u64 ofs = seg_offset + i*super->s_blocksize; + pos_t pos = be64_to_pos(sum->blocks[i].pos); + if (logfs_is_valid_block_gc(super->s_sb, ofs, ino, pos)) + valid++; + //printk("%6llx, %4llx, %6llx, %x\n", ofs, ino, pos, valid); + } + free_disk_sum(sum); + return valid; +} + + +int logfs_erase_segment(struct logfs_super *super, u64 ofs) +{ + u64 end = ofs + super->s_segsize; + long step = super->s_blocksize; + int ret; + + super->s_gec++; + + for ( ; ofs < end; ofs += step) { + ret = mtderase(super->s_mtd, ofs, step); + if (ret) + return -EIO; + } + return 0; +} + + +static void scan_valid_segments(struct logfs_super *super) +{ + int i; + int valid; + + super->s_no_free_segs = 0; + for (i=0; is_no_segs; i++) { + u64 ofs = (u64)i * super->s_segsize; + + valid = logfs_valid_count(super, ofs); + super->s_valid_count[i] = valid; + if (valid == 0) + super->s_no_free_segs++; + } +} + + +static int logfs_level(struct logfs_super *super, u64 seg_offset) +{ + struct mtd_info *mtd = super->s_mtd; + struct logfs_disk_sum *sum; + int end = super->s_no_blocks-1; + u64 footer = seg_offset + end * super->s_blocksize; + int i, level, err; + + /* Currently open segments */ + for (i=0; is_segs[i]; + if (seg->active && (seg->ofs == seg_offset)) + return seg->level; + } + + sum = alloc_disk_sum(super); + err = mtdread(mtd, footer, logfs_summary_size(super), sum); + BUG_ON(err); + + level = sum->level; + free_disk_sum(sum); + return level; +} + + +static void dump_segments(struct logfs_super *super) +{ + int i; + int valid; + + //return; + for (i=0; is_no_segs; i++) { + u64 ofs = (u64)i * super->s_segsize; + + valid = logfs_valid_count(super, ofs); + printk("%5llx, %3d, %2d, %2d ", ofs, logfs_level(super, ofs), + super->s_valid_count[i], valid); + if (i & 1) + printk("\n"); + } +} + + +static void logfs_cleanse_block(struct logfs_super *super, u64 ofs, u64 ino, + pos_t pos) +{ + struct super_block *sb = super->s_sb; + struct inode *inode; + int err; + + inode = logfs_iget(sb, ino); + BUG_ON(!inode); + err = logfs_rewrite_block(inode, logfs_index(pos), ofs, NULL); + BUG_ON(err); + logfs_iput(inode); +} + + +static void __logfs_gc_segment(struct logfs_super *super, u64 seg_ofs) +{ + struct mtd_info *mtd = super->s_mtd; + struct logfs_disk_sum *sum; + int end = super->s_no_blocks-1; + u64 footer = seg_ofs + end * super->s_blocksize; + int i, err; + + sum = alloc_disk_sum(super); + err = mtdread(mtd, footer, logfs_summary_size(super), sum); + BUG_ON(err); + + for (i=0; iblocks[i].ino); + u64 ofs = seg_ofs + i*super->s_blocksize; + pos_t pos = be64_to_pos(sum->blocks[i].pos); + if (! logfs_is_valid_block_gc(super->s_sb, ofs, ino, pos)) + continue; + + logfs_cleanse_block(super, ofs, ino, pos); + } + free_disk_sum(sum); +} + + +static void logfs_gc_segment(struct logfs_super *super, u64 seg_ofs) +{ + int i; + + /* Superblock. Don't touch, or else... */ + BUG_ON(seg_ofs == 0); + /* Primary journal segments. Don't touch, or else... */ + BUG_ON((seg_ofs >= super->s_log_ofs) + && (seg_ofs - super->s_log_ofs < super->s_log_len)); + + /* Currently open segments */ + for (i=0; is_segs[i]; + BUG_ON(seg->active && (seg->ofs == seg_ofs)); + } + __logfs_gc_segment(super, seg_ofs); +} + + +static void logfs_gc_once(struct logfs_super *super) +{ + int end = super->s_no_blocks-1; + int i; + + for (i = super->s_sweeper+1; 1 != super->s_sweeper; i++) { + u64 ofs; + int valid; + + if (i >= super->s_no_segs) + i=1; /* skip superblock */ + + ofs = (u64)i * super->s_segsize; + valid = super->s_valid_count[i]; + + if (valid == 0) + continue; + if (valid > end-1) + continue; + printk("candidate: %5llx\n", ofs); + logfs_gc_segment(super, ofs); + super->s_valid_count[i] = 0; + super->s_no_free_segs++; + super->s_sweeper = i; + return; + } + BUG(); +} + + +void logfs_gc_pass(struct logfs_super *super) +{ + u8 reserve = super->s_total_levels; + int passes = 0; + + for (;;) { + BUG_ON(passes++ > 100); + + if (super->s_no_free_segs >= reserve) + return; + + scan_valid_segments(super); + + if (super->s_no_free_segs >= reserve) + return; + + dump_segments(super); + logfs_gc_once(super); + dump_segments(super); + continue; + } +} + + +static u64 find_free_segment(struct logfs_super *super) +{ + int i; + + for (i=0; is_no_segs; i++) { + u64 ofs = (u64)i * super->s_segsize; + + if (super->s_valid_count[i] != 0) + continue; + + BUG_ON(logfs_valid_count(super, ofs) != 0); + + super->s_valid_count[i] = super->s_no_blocks-1; + super->s_no_free_segs--; + return ofs; + } + + BUG(); + return 0; +} + + +static int logfs_open_segment(struct logfs_segment *seg) +{ + struct logfs_super *super = seg->super; + struct mtd_info *mtd = super->s_mtd; + struct logfs_disk_sum *sum; + int end = super->s_no_blocks-1; + u64 footer; + int err; + + TRACE(); + if (seg->active) + return 0; /* nothing to do */ + + seg->ofs = find_free_segment(super); + seg->cur_block = 0; + + sum = alloc_disk_sum(super); + footer = seg->ofs + end * super->s_blocksize; + err = mtdread(mtd, footer, logfs_summary_size(super), sum); + seg->erase_count = be32_to_cpu(sum->erase_count) + 1; + super->s_maxec = max(super->s_maxec, (u64)seg->erase_count); + //printk("open %8llx, %x\n", seg->ofs, seg->erase_count); + free_disk_sum(sum); + BUG_ON(err); /* FIXME */ + if (err) + return err; + + memset(&seg->blocks, 0xff, logfs_summary_size(super)); + seg->active = 1; + + logfs_erase_segment(super, seg->ofs); + + return 0; +} + + +void logfs_disk_to_sum(struct logfs_super *super, struct logfs_segment *seg, + struct logfs_disk_sum *sum) +{ + int end = super->s_no_blocks-1; + int i; + + seg->ofs = be64_to_cpu(sum->ofs); + if (seg->ofs + 1 == 0) { /* inactive segment */ + seg->active = 0; + return; + } + + seg->active = 1; + seg->erase_count = be32_to_cpu(sum->erase_count); + seg->level = sum->level; + + seg->cur_block = 0; + for (i=0; iblocks[i].ino = be64_to_cpu(sum->blocks[i].ino); + seg->blocks[i].pos = be64_to_pos(sum->blocks[i].pos); + if (seg->blocks[i].ino + 1 != 0) + seg->cur_block = i+1; + } +} + + +void logfs_sum_to_disk(struct logfs_super *super, struct logfs_segment *seg, + struct logfs_disk_sum *sum) +{ + int end = super->s_no_blocks-1; + int i; + + if (!seg->active) { + memset(sum, 0xff, logfs_summary_size(super)); + return; + } + + for (i=0; iblocks[i].ino = cpu_to_be64(seg->blocks[i].ino); + sum->blocks[i].pos = pos_to_be64(seg->blocks[i].pos); + } + sum->erase_count = cpu_to_be32(seg->erase_count); + sum->level = seg->level; + sum->pad[0] = 's'; + sum->pad[1] = 'u'; + sum->pad[2] = 'm'; + sum->ofs = cpu_to_be64(seg->ofs); +} + + +static int logfs_finish_segment(struct logfs_super *super, + struct logfs_segment *seg) +{ + struct mtd_info *mtd = super->s_mtd; + struct logfs_disk_sum *sum; + int end = super->s_no_blocks-1; + u64 ofs = seg->ofs + end * super->s_blocksize; + int err; + + TRACE(); + if (!seg->active) + return 0; + + sum = alloc_disk_sum(super); + logfs_sum_to_disk(super, seg, sum); + sum->gec = cpu_to_be64(super->s_gec); /* we overwrite ofs here */ + err = mtdwrite(mtd, ofs, logfs_summary_size(super), sum); + //printk("finish %8llx, %x\n", seg->ofs, seg->erase_count); + free_disk_sum(sum); + BUG_ON(err); /* lacking any better means */ + return err; +} + + +static void logfs_close_segment(struct logfs_segment *seg) +{ + struct logfs_super *super = seg->super; + + if (seg->cur_block == super->s_no_blocks - 1) { + logfs_finish_segment(super, seg); /* FIXME: return code */ + seg->active = 0; + } +} + + +static s64 __logfs_get_free_block(struct logfs_segment *seg, u64 ino, pos_t pos) +{ + struct logfs_super *super = seg->super; + //struct logfs_segment *bug = super->s_segs[1]; + s64 ofs; + int ret; + + TRACE(); + ret = logfs_open_segment(seg); + BUG_ON(ret>0); + if (ret) + return ret; + + seg->blocks[seg->cur_block].ino = ino; + seg->blocks[seg->cur_block].pos = pos; + + ofs = seg->ofs + seg->cur_block * super->s_blocksize; + seg->cur_block++; + logfs_close_segment(seg); + + BUG_ON(ofs >= super->s_size); + return ofs; +} + + +s64 logfs_get_free_block(struct logfs_super *super, int level, u64 ino, pos_t pos) +{ + s64 ret; + + TRACE(); + BUG_ON(level >= LOGFS_MAX_LEVELS); + + if (ino == LOGFS_INO_MASTER) /* ifile has seperate segments */ + level += LOGFS_MAX_LEVELS; + + ret = __logfs_get_free_block(super->s_segs[level], ino, pos); + BUG_ON(ret <= 0); /* not sure, but it's safer to BUG than to accept */ + return ret; +} + + +static void logfs_measure_free_space(struct logfs_super *super) +{ + u64 free = 0; + int i; + + /* FIXME: superblock also needs a "don't touch" marker */ + for (i=0; is_no_segs; i++) { + int valid = super->s_valid_count[i]; + free += super->s_segsize/LOGFS_BLOCKSIZE - 1 - valid; + } + super->s_free = free; + printk("free: %lld\n", free); + return; +} + + +int logfs_init_segments(struct logfs_super *super) +{ + struct logfs_segment *segs; + int i; + + segs = kzalloc(LOGFS_SEGMENTS * logfs_segstruct_size(super), + GFP_KERNEL); + if (!segs) + return -ENOMEM; + for (i=0; is_segs[i] = (void*)segs + i*logfs_segstruct_size(super); + super->s_segs[i]->super = super; + super->s_segs[i]->level = i; + } + return 0; +} + + +/* needs to be called after init_journal, as we use s_last here */ +int logfs_init_gc(struct logfs_super *super) +{ + u64 div; + + div = super->s_size; + do_div(div, super->s_segsize); + super->s_no_segs = div; + + super->s_valid_count = kmalloc(super->s_no_segs, GFP_KERNEL); + if (!super->s_valid_count) + goto fail0; + + super->s_gc_buf = kmalloc(super->s_blocksize, GFP_KERNEL); + if (!super->s_gc_buf) + goto fail1; + + /* order is important - scan first */ + scan_valid_segments(super); + logfs_measure_free_space(super); + + return 0; +fail1: + kfree(super->s_valid_count); +fail0: + return -ENOMEM; +} + + +void logfs_cleanup_segments(struct logfs_super *super) +{ + int i; + for (i=0; is_segs[i]); + } + kfree(super->s_segs[0]); +} + + +void logfs_cleanup_gc(struct logfs_super *super) +{ + kfree(super->s_gc_buf); + kfree(super->s_valid_count); +} --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/inode.c 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,385 @@ +#include +#include +#include + +#include "logfs.h" + + +static kmem_cache_t *logfs_inode_cache; + + +static struct inode *logfs_alloc_inode(struct super_block *sb) +{ + struct logfs_inode *li; + + TRACE(); + li = kmem_cache_alloc(logfs_inode_cache, SLAB_KERNEL); + if (!li) + return NULL; + return &li->vfs_inode; +} + + +static void logfs_init_inode(struct inode *inode) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + int i; + + TRACE(); + li->li_flags = LOGFS_IF_VALID; + li->li_blocks = 0; + inode->i_uid = 0; + inode->i_gid = 0; + inode->i_size = 0; + inode->i_blocks = 0; + inode->i_ctime = CURRENT_TIME; + inode->i_mtime = CURRENT_TIME; + inode->i_nlink = 1; + + for (i=0; ili_data[i] = 0; + + return; +} + + +struct inode *logfs_new_master_inode(struct super_block *sb) +{ + struct inode *inode; + + inode = logfs_alloc_inode(sb); + if (!inode) + return ERR_PTR(-ENOMEM); + + logfs_init_inode(inode); + inode->i_mode = 0; + inode->i_ino = LOGFS_INO_MASTER; + inode->i_sb = sb; + + return inode; +} + + +static struct timespec be64_to_timespec(be64 betime) +{ + u64 time = be64_to_cpu(betime); + struct timespec tsp; + tsp.tv_sec = time >> 32; + tsp.tv_nsec = time & 0xffffffff; + return tsp; +} + + +static be64 timespec_to_be64(struct timespec tsp) +{ + u64 time = ((u64)tsp.tv_sec << 32) + (tsp.tv_nsec & 0xffffffff); + return cpu_to_be64(time); +} + + +static void logfs_disk_to_inode(struct logfs_disk_inode *di, struct inode*inode) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + int i; + + TRACE(); + inode->i_mode = be16_to_cpu(di->di_mode); + li->li_flags = be32_to_cpu(di->di_flags); + inode->i_uid = be32_to_cpu(di->di_uid); + inode->i_gid = be32_to_cpu(di->di_gid); + inode->i_size = be64_to_cpu(di->di_size); + logfs_set_blocks(inode, be64_to_cpu(di->di_blocks)); + inode->i_ctime = be64_to_timespec(di->di_ctime); + inode->i_mtime = be64_to_timespec(di->di_mtime); + inode->i_nlink = be32_to_cpu(di->di_refcount); + inode->i_generation = be32_to_cpu(di->di_generation); + + switch (inode->i_mode & S_IFMT) { + case S_IFCHR: /* fall through */ + case S_IFBLK: /* fall through */ + case S_IFIFO: + inode->i_rdev = be64_to_cpu(di->di_data[0]); + break; + default: + for (i=0; ili_data[i] = be64_to_cpu(di->di_data[i]); + break; + } +} + + +static void logfs_inode_to_disk(struct inode *inode, struct logfs_disk_inode*di) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + int i; + + TRACE(); + di->di_mode = cpu_to_be16(inode->i_mode); + di->di_pad = 0; + di->di_flags = cpu_to_be32(li->li_flags); + di->di_uid = cpu_to_be32(inode->i_uid); + di->di_gid = cpu_to_be32(inode->i_gid); + di->di_size = cpu_to_be64(i_size_read(inode)); + di->di_blocks = cpu_to_be64(li->li_blocks); + di->di_ctime = timespec_to_be64(inode->i_ctime); + di->di_mtime = timespec_to_be64(inode->i_mtime); + di->di_refcount = cpu_to_be32(inode->i_nlink); + di->di_generation = cpu_to_be32(inode->i_generation); + + switch (inode->i_mode & S_IFMT) { + case S_IFCHR: /* fall through */ + case S_IFBLK: /* fall through */ + case S_IFIFO: + di->di_data[0] = cpu_to_be64(inode->i_rdev); + break; + default: + for (i=0; idi_data[i] = cpu_to_be64(li->li_data[i]); + break; + } +} + + +static void dump_di(struct logfs_disk_inode *di) +{ + int i, k; + return; + for (i=0; ii_sb); + ino_t ino = inode->i_ino; + int ret; + + TRACE(); + + BUG_ON(!super->s_master_inode); + ret = logfs_inode_read(super->s_master_inode, di, sizeof(*di), + ino * sizeof(*di)); + dump_di(di); + if (ret) + return -EIO; + + if ( !(be32_to_cpu(di->di_flags) & LOGFS_IF_VALID)) + return -EIO; + + if (be32_to_cpu(di->di_flags) & LOGFS_IF_INVALID) + return -EIO; + + return 0; +} + + +static int __logfs_read_inode(struct inode *inode) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + struct logfs_disk_inode di; + int ret; + + TRACE(); + ret = logfs_read_disk_inode(&di, inode); + if (ret) + return ret; + logfs_disk_to_inode(&di, inode); + + if ( !(li->li_flags&LOGFS_IF_VALID) || (li->li_flags&LOGFS_IF_INVALID)) + return -EIO; + + switch (inode->i_mode & S_IFMT) { + case S_IFDIR: + inode->i_op = &logfs_dir_iops; + inode->i_fop = &logfs_dir_fops; + break; + case S_IFREG: + inode->i_op = &logfs_reg_iops; + inode->i_fop = &logfs_reg_fops; + inode->i_mapping->a_ops = &logfs_reg_aops; + break; + default: + ; + } + + return 0; +} + + +static void logfs_read_inode(struct inode *inode) +{ + int ret; + + TRACE(); + BUG_ON(inode->i_ino == LOGFS_INO_MASTER); + + ret = __logfs_read_inode(inode); + if (ret) { + printk("%lx\n", inode->i_ino); + BUG(); + } +} + + +static int logfs_write_disk_inode(struct logfs_disk_inode *di, + struct inode *inode) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + int ret; + + TRACE(); + BUG_ON(!super->s_master_inode); + ret = logfs_inode_write_nolock(super->s_master_inode, di, sizeof(*di), + inode->i_ino * sizeof(*di)); + dump_di(di); + return ret; +} + + +static int logfs_write_inode(struct inode *inode, int do_sync) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct logfs_disk_inode old, new; + int ret = 0; + + BUG_ON(inode->i_ino == LOGFS_INO_MASTER); + + mutex_lock(&super->s_write_inode_mutex); + super->s_write_inode = inode; + + logfs_inode_to_disk(inode, &new); + if (logfs_read_disk_inode(&old, inode)) + ret = logfs_write_disk_inode(&new, inode); + if (memcmp(&old, &new, sizeof(old))) + ret = logfs_write_disk_inode(&new, inode); + + super->s_write_inode = NULL; + mutex_unlock(&super->s_write_inode_mutex); + return ret; +} + + +static void logfs_delete_inode(struct inode *inode) +{ + TRACE(); + if (i_size_read(inode) > 0) { + i_size_write(inode, 0); + logfs_truncate(inode); + truncate_inode_pages(&inode->i_data, 0); + } + logfs_write_inode(inode, 1); + clear_inode(inode); +} + + +static void logfs_destroy_inode(struct inode *inode) +{ + TRACE(); + kmem_cache_free(logfs_inode_cache, LOGFS_INODE(inode)); +} + + +static u64 logfs_get_ino(struct super_block *sb) +{ + struct logfs_super *super = LOGFS_SUPER(sb); + u64 ino; + + /* FIXME: ino allocation should work in two modes: + * o nonsparse - ifile is mostly occupied, just append + * o sparse - ifile has lots of holes, fill them up + */ + spin_lock(&super->s_ino_lock); + ino = super->s_last_ino; /* ifile shouldn't be too sparse */ + super->s_last_ino++; + spin_unlock(&super->s_ino_lock); + return ino; +} + + +struct inode *logfs_new_inode(struct inode *dir, int mode) +{ + struct super_block *sb = dir->i_sb; + struct inode *inode; + int ret; + + inode = new_inode(sb); + if (!inode) + return ERR_PTR(-ENOMEM); + + logfs_init_inode(inode); + + inode->i_mode = mode; + inode->i_ino = logfs_get_ino(sb); + + /* If we don't spend an option early, we may end up with dirty inodes + * and no options left at umount time. So write this inode NOW. + */ + ret = logfs_write_inode(inode, 1); + if (ret) { + logfs_destroy_inode(inode); + /* FIXME: we just grew super->s_last_ino */ + return NULL; + } + /* FIXME: need to understand vfs inode handling a bit more */ + insert_inode_hash(inode); + + return inode; +} + + +static void logfs_init_once(void *_li, kmem_cache_t *cachep, + unsigned long flags) +{ + struct logfs_inode *li = _li; + struct inode *inode = _li; + int i; + + TRACE(); + if ((flags & (SLAB_CTOR_VERIFY|SLAB_CTOR_CONSTRUCTOR)) == + SLAB_CTOR_CONSTRUCTOR) { + li->li_flags = 0; + li->li_blocks = 0; + for (i=0; ili_data[i] = 0; + inode_init_once(&li->vfs_inode); + /* FIXME: would block size be better? */ + inode->i_blksize = PAGE_SIZE; + } + +} + + +struct super_operations logfs_super_operations = { + .alloc_inode = logfs_alloc_inode, + .delete_inode = logfs_delete_inode, + .destroy_inode = logfs_destroy_inode, + .read_inode = logfs_read_inode, + .write_inode = logfs_write_inode, + .statfs = logfs_statfs, +}; + + +int logfs_init_inode_cache(void) +{ + TRACE(); + logfs_inode_cache = kmem_cache_create("logfs_inode_cache", + sizeof(struct logfs_inode), 0, SLAB_RECLAIM_ACCOUNT, + logfs_init_once, NULL); + if (!logfs_inode_cache) + return -ENOMEM; + return 0; +} + + +void logfs_destroy_inode_cache(void) +{ + TRACE(); + kmem_cache_destroy(logfs_inode_cache); +} --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/journal.c 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,216 @@ +#include +#include + +#include "logfs.h" + + +/** + * FIXME: this code assumes that journal entries all fit into a block. + * Might become untrue someday. + */ + + +static inline u32 seg_offset(struct logfs_super *super, u64 ofs) +{ + u64 div = ofs; + u32 mod; + + mod = do_div(div, super->s_segsize); + return mod; +} + + +static s64 __logfs_get_free_entry(struct logfs_super *super) +{ + u64 ofs; + + ofs = super->s_anchor_ofs + super->s_blocksize; + if (ofs - super->s_log_ofs >= super->s_log_len) + ofs = super->s_log_ofs; + if ( !seg_offset(super, ofs)) { + if (logfs_erase_segment(super, ofs)) + return -EIO; + } + BUG_ON((s64)ofs < 0); + return ofs; +} + + +/** + * logfs_get_free_entry - return free space for journal entry + */ +static s64 logfs_get_free_entry(struct logfs_super *super) +{ + s64 ret; + + TRACE(); + mutex_lock(&super->s_log_sem); + ret = __logfs_get_free_entry(super); + mutex_unlock(&super->s_log_sem); + BUG_ON(ret <= 0); /* not sure, but it's safer to BUG than to accept */ + return ret; +} + + +static s64 logfs_find_anchor(struct logfs_super *super, + struct logfs_journal_entry *je) +{ + struct mtd_info *mtd = super->s_mtd; + u64 ofs, version, last_ofs = -EIO, last_version = 0; + int ret; + + for (ofs = super->s_log_ofs; ofs - super->s_log_ofs < super->s_log_len; + ofs += super->s_blocksize) { + ret = mtdread(mtd, ofs, sizeof(*je), je); + if (ret) + return -EIO; + version = be64_to_cpu(je->je_version); + if (version == -1ULL) + continue; + if (version == last_version) + return -EIO; + if (version < last_version) + continue; + last_version = version; + last_ofs = ofs; + } + return last_ofs; +} + + +static void logfs_load_sums(struct logfs_super *super) +{ + struct logfs_journal_entry *je = super->s_je; + int i; + + for (i=0; is_segs[i]; + void *sum = (void*)je + super->s_sum_start; + sum += i * logfs_summary_size(super); + logfs_disk_to_sum(super, seg, sum); + } +} + + +static int logfs_read_anchor(struct inode *inode) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct mtd_info *mtd = super->s_mtd; + struct logfs_inode *li = LOGFS_INODE(inode); + struct logfs_journal_entry *je = super->s_je; + int i, ret; + s64 ofs; + + TRACE(); + ofs = logfs_find_anchor(super, je); + if (ofs < 0) + return ofs; + + printk("%x\n", super->s_anchor_size); + ret = mtdread(mtd, ofs, super->s_anchor_size, je); + if (ret) + return ret; + + logfs_load_sums(super); + + BUG_ON(je->je_type != cpu_to_be16(JE_ANCHOR)); + super->s_last_version = be64_to_cpu(je->je_version); + super->s_last_ino = be64_to_cpu(je->da.da_last_ino); + super->s_gec = be64_to_cpu(je->da.da_gec); + super->s_maxec = be64_to_cpu(je->da.da_maxec); + super->s_sweeper= be64_to_cpu(je->da.da_sweeper); + super->s_anchor_ofs = ofs; + li->li_flags = LOGFS_IF_VALID; + i_size_write(inode, be64_to_cpu(je->da.da_size)); + + for (i=0; ili_data[i] = be64_to_cpu(je->da.da_data[i]); + + return 0; +} + + +static void logfs_save_sums(struct logfs_super *super) +{ + struct logfs_journal_entry *je = super->s_je; + int i; + + for (i=0; is_segs[i]; + void *sum = (void*)je + super->s_sum_start; + sum += i * logfs_summary_size(super); + logfs_sum_to_disk(super, seg, sum); + } +} + + +int logfs_write_anchor(struct inode *inode) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct mtd_info *mtd = super->s_mtd; + struct logfs_inode *li = LOGFS_INODE(inode); + struct logfs_journal_entry *je = super->s_je; + u64 ofs; + int i, ret; + + TRACE(); + ofs = logfs_get_free_entry(super); + BUG_ON(ofs >= super->s_size); + + memset(je, 0, super->s_anchor_size); + je->je_type = cpu_to_be16(JE_ANCHOR); + super->s_last_version++; + je->je_version = cpu_to_be64(super->s_last_version); + je->da.da_gec = cpu_to_be64(super->s_gec); + je->da.da_maxec = cpu_to_be64(super->s_maxec); + je->da.da_sweeper = cpu_to_be64(super->s_sweeper); + je->da.da_last_ino = cpu_to_be64(super->s_last_ino); + je->da.da_size = cpu_to_be64(i_size_read(inode)); + for (i=0; ida.da_data[i] = cpu_to_be64(li->li_data[i]); + + logfs_save_sums(super); + + ret = mtdwrite(mtd, ofs, super->s_anchor_size, je); + if (ret) + return ret; + super->s_anchor_ofs = ofs; + return 0; +} + + +int logfs_init_log(struct super_block *sb) +{ + struct logfs_super *super = LOGFS_SUPER(sb); + struct inode *inode; + int ret; + + TRACE(); + mutex_init(&super->s_log_sem); + + super->s_je = kzalloc(super->s_anchor_size, GFP_KERNEL); + if (!super->s_je) + return -ENOMEM; + + inode = logfs_new_master_inode(sb); + BUG_ON(!inode); + ret = logfs_read_anchor(inode); + if (ret) + return ret; + inode->i_nlink = 1; /* lock it in ram (FIXME: remove) */ + + super->s_master_inode = inode; + return 0; +} + + +void logfs_cleanup_log(struct super_block *sb) +{ + struct logfs_super *super = LOGFS_SUPER(sb); + + logfs_write_anchor(super->s_master_inode); + sb->s_op->destroy_inode(super->s_master_inode); + super->s_master_inode = NULL; + + kfree(super->s_je); +} --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/readwrite.c 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,992 @@ +#include +#include +#include + +#include "logfs.h" + + +static int logfs_read_empty(void *buf) +{ + TRACE(); + memset(buf, 0, PAGE_CACHE_SIZE); + return 0; +} + + +static int logfs_read_embedded(struct inode *inode, void *buf) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + + TRACE(); + memcpy(buf, li->li_data, LOGFS_EMBEDDED_SIZE); + return 0; +} + + +static int logfs_read_direct(struct inode *inode, pgoff_t index, void *buf) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + struct mtd_info *mtd = LOGFS_SUPER(inode->i_sb)->s_mtd; + u64 block; + + TRACE(); + block = li->li_data[index]; + if (!block) + return logfs_read_empty(buf); + + return mtdread(mtd, block, LOGFS_BLOCKSIZE, buf); +} + + +static be64 *logfs_get_rblock(struct logfs_super *super) +{ + TRACE(); + mutex_lock(&super->s_r_sem); + return super->s_rblock; +} + + +static void logfs_put_rblock(struct logfs_super *super) +{ + mutex_unlock(&super->s_r_sem); +} + + +static be64 **logfs_get_wblocks(struct logfs_super *super) +{ + TRACE(); + mutex_lock(&super->s_w_sem); + logfs_gc_pass(super); + return super->s_wblock; +} + + +static void logfs_put_wblocks(struct logfs_super *super) +{ + TRACE(); + mutex_unlock(&super->s_w_sem); +} + + +static unsigned long get_bits(u64 val, int skip, int no) +{ + u64 ret = val; + ret >>= skip; + ret <<= 64 - no; + ret >>= 64 - no; + BUG_ON((unsigned long)ret != ret); + return ret; +} + + +static int logfs_read_loop(struct inode *inode, pgoff_t index, void *buf, + int count) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct mtd_info *mtd = super->s_mtd; + be64 *rblock; + u64 bofs = li->li_data[I1_INDEX + count]; + int bits = LOGFS_BLOCK_BITS; + int i, ret; + + TRACE(); + + if (!bofs) + return logfs_read_empty(buf); + + rblock = logfs_get_rblock(super); + + for (i=count*bits; i>=0; i-=bits) { + ret = mtdread(mtd, bofs, LOGFS_BLOCKSIZE, rblock); + if (ret) + goto out; + bofs = be64_to_cpu(rblock[get_bits(index, i, bits)]); + + if (!bofs) { + ret = logfs_read_empty(buf); + goto out; + } + } + + ret = mtdread(mtd, bofs, LOGFS_BLOCKSIZE, buf); +out: + logfs_put_rblock(super); + return ret; +} + + +static int logfs_read_block(struct inode *inode, pgoff_t index, void *buf) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + + TRACE(); + if (li->li_flags & LOGFS_IF_EMBEDDED) { + if (index != 0) + return logfs_read_empty(buf); + else + return logfs_read_embedded(inode, buf); + } else if (index < I0_BLOCKS) + return logfs_read_direct(inode, index, buf); + else if (index < I1_BLOCKS) + return logfs_read_loop(inode, index, buf, 0); + else if (index < I2_BLOCKS) + return logfs_read_loop(inode, index, buf, 1); + else if (index < I3_BLOCKS) + return logfs_read_loop(inode, index, buf, 2); + + BUG(); + return -EIO; +} + + +static int logfs_is_valid_direct(struct logfs_inode *li, pgoff_t index, u64 ofs) +{ + TRACE(); + return li->li_data[index] == ofs; +} + + +static int logfs_is_valid_loop(struct inode *inode, pgoff_t index, + int count, u64 ofs) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct mtd_info *mtd = super->s_mtd; + be64 *rblock; + u64 bofs = li->li_data[I1_INDEX + count]; + int bits = LOGFS_BLOCK_BITS; + int i, ret; + + TRACE(); + + if (!bofs) + return 0; + + rblock = logfs_get_rblock(super); + + for (i=count*bits; i>=0; i-=bits) { + ret = mtdread(mtd, bofs, LOGFS_BLOCKSIZE, rblock); + if (ret) + goto fail; + + bofs = be64_to_cpu(rblock[get_bits(index, i, bits)]); + if (!bofs) + goto fail; + + if (bofs == ofs) { + ret = 1; + goto out; + } + } + +fail: + ret = 0; +out: + logfs_put_rblock(super); + return ret; +} + + +static int __logfs_is_valid_block(struct inode *inode, pgoff_t index, u64 ofs) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + + //printk("%lx, %x, %x\n", inode->i_ino, inode->i_nlink, atomic_read(&inode->i_count)); + if ((inode->i_nlink == 0) && atomic_read(&inode->i_count) == 1) + return 0; + + if (li->li_flags & LOGFS_IF_EMBEDDED) + return 0; + + if (index < I0_BLOCKS) + return logfs_is_valid_direct(li, index, ofs); + else if (index < I1_BLOCKS) + return logfs_is_valid_loop(inode, index, 0, ofs); + else if (index < I2_BLOCKS) + return logfs_is_valid_loop(inode, index, 1, ofs); + else if (index < I3_BLOCKS) + return logfs_is_valid_loop(inode, index, 2, ofs); + + BUG(); + return 0; +} + + +int logfs_is_valid_block(struct super_block *sb, u64 ofs, u64 ino, u64 pos) +{ + struct inode *write_inode = LOGFS_SUPER(sb)->s_write_inode; + struct inode *inode; + u64 idx; + int ret; + + TRACE(); + idx = logfs_index(pos); + + BUG_ON((u64)(u_long)ino != ino); + inode = write_inode ? : logfs_iget(sb, ino); + if (!inode) + return 0; + ret = __logfs_is_valid_block(inode, idx, ofs); + if (!write_inode) + logfs_iput(inode); + return ret; +} + + +int logfs_readpage(struct file *file, struct page *page) +{ + struct inode *inode = page->mapping->host; + void *buf; + int ret = -EIO; + + TRACE(); + buf = kmap(page); + ret = logfs_read_block(inode, page->index, buf); + kunmap(page); + + if (ret) { + ClearPageUptodate(page); + SetPageError(page); + } else { + SetPageUptodate(page); + ClearPageError(page); + } + flush_dcache_page(page); + + unlock_page(page); + return ret; +} + + +/** + * logfs_file_read - generic_file_read for in-kernel buffers + */ +static ssize_t __logfs_inode_read(struct inode *inode, char *buf, size_t count, + loff_t *ppos) +{ + void *block_data = NULL; + loff_t size = i_size_read(inode); + int err = -ENOMEM; + + TRACE(); + pr_debug("read from %lld, count %zd\n", *ppos, count); + + if (*ppos >= size) + return 0; + if (count > size - *ppos) + count = size - *ppos; + + BUG_ON(logfs_index(*ppos) != logfs_index(*ppos + count - 1)); + + block_data = kzalloc(LOGFS_BLOCKSIZE, GFP_KERNEL); + if (!block_data) + goto fail; + + err = logfs_read_block(inode, logfs_index(*ppos), block_data); + if (err) + goto fail; + + memcpy(buf, block_data + (*ppos % LOGFS_BLOCKSIZE), count); + *ppos += count; + kfree(block_data); + return count; +fail: + kfree(block_data); + return err; +} + + +static s64 __logfs_write_block(struct logfs_super *super, void *buf, int level, + u64 inode, u64 pos) +{ + struct mtd_info *mtd = super->s_mtd; + u64 block; + int err; + + TRACE(); + block = logfs_get_free_block(super, level, inode, (__force pos_t) pos); + if (block < 0) { + BUG(); + return block; + } + + err = mtdwrite(mtd, block, PAGE_CACHE_SIZE, buf); + if (err) { + BUG(); + return err; + } + return block; +} + + +static s64 logfs_write_block(struct logfs_super *super, void *buf, int level, + u64 inode, pgoff_t index) +{ + u64 pos = (u64)index * super->s_blocksize; + return __logfs_write_block(super, buf, level, inode, pos); +} + + +static void __logfs_set_blocks(struct inode *inode) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + + inode->i_blocks = ULONG_MAX; + if (li->li_blocks<<3 < ULONG_MAX) + inode->i_blocks = li->li_blocks<<3; +} + + +void logfs_set_blocks(struct inode *inode, u64 no) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + + li->li_blocks = no; + __logfs_set_blocks(inode); +} + + +static void logfs_add_blocks(struct inode *inode, u64 no) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + + BUG_ON(li->li_blocks + no < no); /* wraps are bad, mkay */ + li->li_blocks += no; + __logfs_set_blocks(inode); +} + + +static void logfs_remove_blocks(struct inode *inode, u64 no, u64 ofs) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct logfs_inode *li = LOGFS_INODE(inode); + + BUG_ON(li->li_blocks < no); + li->li_blocks -= no; + __logfs_set_blocks(inode); + super->s_free += no; +} + + +/* FIXME: s_free needs to be decremented as well */ +static int logfs_alloc_blocks(struct inode *inode, int no) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + + if (!no) + return 0; + + //printk("%3llx %2x %2llx\n", super->s_free, no, super->s_gc_reserve); + if (super->s_free < no + super->s_gc_reserve) + return -ENOSPC; + + super->s_free -= no; + logfs_add_blocks(inode, no); + return 0; +} + + +static int logfs_dirty_inode(struct inode *inode) +{ + TRACE(); + if (inode->i_ino == LOGFS_INO_MASTER) + return logfs_write_anchor(inode); + + mark_inode_dirty(inode); + return 0; +} + + +/* + * File is too large for embedded data when called. Move data to first + * block and clear embedded area + */ +static int logfs_move_embedded(struct inode *inode, be64 **wblocks) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + void *buf; + s64 block; + int i; + + TRACE(); + if (! (li->li_flags & LOGFS_IF_EMBEDDED)) + return 0; + + if (logfs_alloc_blocks(inode, 1)) + return -ENOSPC; + + buf = wblocks[0]; + + memcpy(buf, li->li_data, LOGFS_EMBEDDED_SIZE); + block = logfs_write_block(super, buf, 0, inode->i_ino, 0); + if (block < 0) + return block; + + li->li_data[0] = block; + + li->li_flags &= ~LOGFS_IF_EMBEDDED; + for (i=1; ili_data[i] = 0; + + return logfs_dirty_inode(inode); +} + + +static int logfs_write_embedded(struct inode *inode, void *buf) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + void *dst = li->li_data; + + TRACE(); + //printk("inode->i_size: %lld\n", i_size_read(inode)); + memcpy(dst, buf, max((long long)LOGFS_EMBEDDED_SIZE, i_size_read(inode))); + + li->li_flags |= LOGFS_IF_EMBEDDED; + logfs_set_blocks(inode, 0); + + return logfs_dirty_inode(inode); +} + + +static int logfs_write_direct(struct inode *inode, pgoff_t index, void *buf) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + s64 block; + + TRACE(); + if (! li->li_data[index]) + if (logfs_alloc_blocks(inode, 1)) + return -ENOSPC; + + block = logfs_write_block(super, buf, 0, inode->i_ino, index); + if (block < 0) + return block; + + li->li_data[index] = block; + + return logfs_dirty_inode(inode); +} + + +static int logfs_write_loop(struct inode *inode, pgoff_t index, void *buf, + be64 **wblocks, int count) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct mtd_info *mtd = super->s_mtd; + u64 bofs = li->li_data[I1_INDEX + count]; + s64 block; + int bits = LOGFS_BLOCK_BITS; + int allocs = 0; + int i, ret; + + for (i=count; i>=0; i--) { + if (bofs) { + ret = mtdread(mtd, bofs, LOGFS_BLOCKSIZE, wblocks[i]); + if (ret) + return ret; + } else { + allocs++; + memset(wblocks[i], 0, LOGFS_BLOCKSIZE); + } + bofs = be64_to_cpu(wblocks[i][get_bits(index, i*bits, bits)]); + } + + if (! wblocks[0][get_bits(index, 0, bits)]) + allocs++; + if (logfs_alloc_blocks(inode, allocs)) + return -ENOSPC; + + block = logfs_write_block(super, buf, 0, inode->i_ino, index); + if (block < 0) + return block; + + for (i=0; i<=count; i++) { + wblocks[i][get_bits(index, i*bits, bits)] = cpu_to_be64(block); + block = logfs_write_block(super, wblocks[i], 1, inode->i_ino, + index); + if (block < 0) + return block; + } + + li->li_data[I1_INDEX + count] = block; + + return logfs_dirty_inode(inode); +} + + +static int __logfs_write_buf(struct inode *inode, pgoff_t index, void *buf, + be64 **wblocks) +{ + u64 size = i_size_read(inode); + int err; + + TRACE(); + + inode->i_ctime.tv_sec = inode->i_mtime.tv_sec = get_seconds(); + + if (size <= LOGFS_EMBEDDED_SIZE) + return logfs_write_embedded(inode, buf); + + err = logfs_move_embedded(inode, wblocks); + if (err) + return err; + + if (index < I0_BLOCKS) + return logfs_write_direct(inode, index, buf); + if (index < I1_BLOCKS) + return logfs_write_loop(inode, index, buf, wblocks, 0); + if (index < I2_BLOCKS) + return logfs_write_loop(inode, index, buf, wblocks, 1); + if (index < I3_BLOCKS) + return logfs_write_loop(inode, index, buf, wblocks, 2); + + BUG(); + return -EIO; +} + + +int logfs_write_buf(struct inode *inode, pgoff_t index, void *buf) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + be64 **wblocks; + int ret; + + wblocks = logfs_get_wblocks(super); + ret = __logfs_write_buf(inode, index, buf, wblocks); + logfs_put_wblocks(super); + return ret; +} + + +static int logfs_rewrite_direct(struct inode *inode, pgoff_t index, void *buf) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct mtd_info *mtd = super->s_mtd; + s64 block; + int err; + + TRACE(); + block = li->li_data[index]; + BUG_ON(! block); + + err = mtdread(mtd, block, LOGFS_BLOCKSIZE, buf); + if (err) + return err; + + block = logfs_write_block(super, buf, 0, inode->i_ino, index); + if (block < 0) + return block; + + li->li_data[index] = block; + + return logfs_dirty_inode(inode); +} + + +static int logfs_rewrite_loop(struct inode *inode, pgoff_t index, void *buf, + be64 **wblocks, int count) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct mtd_info *mtd = super->s_mtd; + u64 bofs = li->li_data[I1_INDEX + count]; + s64 block; + int bits = LOGFS_BLOCK_BITS; + int i, err; + + for (i=count; i>=0; i--) { + if (bofs) { + err = mtdread(mtd, bofs, LOGFS_BLOCKSIZE, wblocks[i]); + if (err) + return err; + } else { + BUG(); + } + bofs = be64_to_cpu(wblocks[i][get_bits(index, i*bits, bits)]); + } + + block = be64_to_cpu(wblocks[0][get_bits(index, 0, bits)]); + BUG_ON(! block); + + err = mtdread(mtd, block, LOGFS_BLOCKSIZE, buf); + if (err) + return err; + + block = logfs_write_block(super, buf, 0, inode->i_ino, index); + if (block < 0) + return block; + + for (i=0; i<=count; i++) { + wblocks[i][get_bits(index, i*bits, bits)] = cpu_to_be64(block); + block = logfs_write_block(super, wblocks[i], 1, inode->i_ino, + index); + if (block < 0) + return block; + } + + li->li_data[I1_INDEX + count] = block; + + return logfs_dirty_inode(inode); +} + + +static int __logfs_rewrite_block(struct inode *inode, pgoff_t index, void *buf, + be64 **wblocks) +{ + TRACE(); + + if (index < I0_BLOCKS) + return logfs_rewrite_direct(inode, index, buf); + if (index < I1_BLOCKS) + return logfs_rewrite_loop(inode, index, buf, wblocks, 0); + if (index < I2_BLOCKS) + return logfs_rewrite_loop(inode, index, buf, wblocks, 1); + if (index < I3_BLOCKS) + return logfs_rewrite_loop(inode, index, buf, wblocks, 2); + + BUG(); + return -EIO; +} + + +int logfs_rewrite_block(struct inode *inode, pgoff_t index, u64 ofs, void *buf) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + be64 **wblocks; + int ret; + + wblocks = super->s_wblock; + buf = wblocks[LOGFS_MAX_INDIRECT]; + ret = __logfs_rewrite_block(inode, index, buf, wblocks); + return ret; +} + + +/** + * Three cases exist: + * size <= pos - remove full block + * size >= pos + chunk - do nothing + * pos < size < pos + chunk - truncate, rewrite + */ +static s64 __logfs_truncate_i0(struct inode *inode, u64 size, u64 bofs, + u64 pos, be64 **wblocks) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct mtd_info *mtd = super->s_mtd; + size_t len = size - pos; + void *buf = wblocks[LOGFS_MAX_INDIRECT]; + int err; + + if (size <= pos) { /* remove whole block */ + logfs_remove_blocks(inode, 1, bofs); + return 0; + } + + /* truncate this block, rewrite it */ + memset(buf, 0, LOGFS_BLOCKSIZE); + err = mtdread(mtd, bofs, len, buf); + if (err) + return err; + + return __logfs_write_block(super, buf, 0, inode->i_ino, pos); +} + + +/* FIXME: move to super */ +static u64 logfs_factor[] = { + LOGFS_BLOCKSIZE, + LOGFS_I1_SIZE, + LOGFS_I2_SIZE, + LOGFS_I3_SIZE +}; + + +static u64 logfs_start[] = { + LOGFS_I0_SIZE, + LOGFS_I1_SIZE, + LOGFS_I2_SIZE, + LOGFS_I3_SIZE +}; + + +/* + * One recursion per indirect block. Logfs supports 5fold indirect blocks. + */ +static s64 __logfs_truncate_loop(struct inode *inode, u64 size, u64 old_bofs, + u64 pos, be64 **wblocks, int i) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + struct mtd_info *mtd = super->s_mtd; + s64 ofs; + int e, ret; + + ret = mtdread(mtd, old_bofs, LOGFS_BLOCKSIZE, wblocks[i]); + if (ret) + return ret; + + for (e = LOGFS_BLOCK_FACTOR-1; e>=0; e--) { + u64 bofs; + u64 new_pos = pos + e*logfs_factor[i]; + + if (size >= new_pos + logfs_factor[i]) + break; + + bofs = be64_to_cpu(wblocks[i][e]); + if (!bofs) + continue; + + BUG_ON(bofs > super->s_size); + + if (i) + ofs = __logfs_truncate_loop(inode, size, bofs, new_pos, + wblocks, i-1); + else + ofs = __logfs_truncate_i0(inode, size, bofs, new_pos, + wblocks); + if (ofs < 0) + return ofs; + + wblocks[i][e] = cpu_to_be64(ofs); + } + + if (size <= max(pos, logfs_start[i])) { + /* complete indirect block is removed */ + logfs_remove_blocks(inode, 1, old_bofs); + return 0; + } + + /* partially removed - write back */ + return __logfs_write_block(super, wblocks[i], 1, inode->i_ino, pos); +} + + +static int logfs_truncate_direct(struct inode *inode, u64 size, be64 **wblocks) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + int e; + s64 bofs, ofs; + + for (e = I1_INDEX-1; e>=0; e--) { + u64 new_pos = e*logfs_factor[0]; + + if (size > e*logfs_factor[0]) + break; + + bofs = li->li_data[e]; + if (!bofs) + continue; + + ofs = __logfs_truncate_i0(inode, size, bofs, new_pos, wblocks); + if (ofs < 0) + return ofs; + + li->li_data[e] = ofs; + } + return 0; +} + + +static int logfs_truncate_loop(struct inode *inode, u64 size, be64 **wblocks, + int i) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + u64 bofs = li->li_data[I1_INDEX + i]; + s64 ofs; + + if (!bofs) + return 0; + + ofs = __logfs_truncate_loop(inode, size, bofs, 0, wblocks, i); + if (ofs < 0) + return ofs; + + li->li_data[I1_INDEX + i] = ofs; + return 0; +} + + +static void logfs_truncate_embedded(struct inode *inode, u64 size) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + void *buf = (void*)li->li_data + size; + size_t len = LOGFS_EMBEDDED_SIZE - size; + + TRACE(); + if (size >= LOGFS_EMBEDDED_SIZE) + return; + memset(buf, 0, len); +} + + +/* TODO: might make sense to turn inode into embedded again */ +static void __logfs_truncate(struct inode *inode, be64 **wblocks) +{ + struct logfs_inode *li = LOGFS_INODE(inode); + u64 size = i_size_read(inode); + int ret; + + if (li->li_flags & LOGFS_IF_EMBEDDED) + return logfs_truncate_embedded(inode, size); + + if (size >= logfs_factor[3]) + return; + ret = logfs_truncate_loop(inode, size, wblocks, 2); + BUG_ON(ret); + + if (size >= logfs_factor[2]) + return; + ret = logfs_truncate_loop(inode, size, wblocks, 1); + BUG_ON(ret); + + if (size >= logfs_factor[1]) + return; + ret = logfs_truncate_loop(inode, size, wblocks, 0); + BUG_ON(ret); + + ret = logfs_truncate_direct(inode, size, wblocks); + BUG_ON(ret); +} + + +void logfs_truncate(struct inode *inode) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + be64 **wblocks; + + wblocks = logfs_get_wblocks(super); + __logfs_truncate(inode, wblocks); + logfs_put_wblocks(super); + mark_inode_dirty(inode); +} + + +static ssize_t __logfs_inode_write(struct inode *inode, const char *buf, + size_t count, loff_t *ppos) +{ + void *block_data = NULL; + int err = -ENOMEM; + + TRACE(); + pr_debug("write to 0x%llx, count %zd\n", *ppos, count); + + BUG_ON(logfs_index(*ppos) != logfs_index(*ppos + count - 1)); + + block_data = kzalloc(LOGFS_BLOCKSIZE, GFP_KERNEL); + if (!block_data) + goto fail; + + err = logfs_read_block(inode, logfs_index(*ppos), block_data); + if (err) + goto fail; + + memcpy(block_data + (*ppos % LOGFS_BLOCKSIZE), buf, count); + + if (i_size_read(inode) < *ppos + count) + i_size_write(inode, *ppos + count); + + err = logfs_write_buf(inode, logfs_index(*ppos), block_data); + if (err) + goto fail; + + *ppos += count; + pr_debug("write to %lld, count %zd\n", *ppos, count); + kfree(block_data); + return count; +fail: + kfree(block_data); + return err; +} + + +int logfs_inode_read(struct inode *inode, void *buf, size_t n, loff_t _pos) +{ + loff_t pos = _pos; + ssize_t ret; + + TRACE(); + if (pos >= i_size_read(inode)) + return -EOF; + ret = __logfs_inode_read(inode, buf, n, &pos); + ret = ret==n ? 0 : -EIO; + return ret; +} + + +int logfs_inode_write_nolock(struct inode *inode, const void *buf, size_t n, + loff_t _pos) +{ + loff_t pos = _pos; + ssize_t ret; + + TRACE(); + ret = __logfs_inode_write(inode, buf, n, &pos); + ret = ret==n ? 0 : -EIO; + return ret; +} + + +int logfs_inode_write(struct inode *inode, const void *buf, size_t n, + loff_t pos) +{ + struct logfs_super *super = LOGFS_SUPER(inode->i_sb); + int ret; + + mutex_lock(&super->s_write_inode_mutex); + ret = logfs_inode_write_nolock(inode, buf, n, pos); + mutex_unlock(&super->s_write_inode_mutex); + return ret; +} + + +int logfs_inode_write_loop(struct inode *inode, const void *buf, size_t n, + loff_t _pos) +{ + loff_t pos = _pos; + int ret; + + while (n > LOGFS_BLOCKSIZE) { + ret = logfs_inode_write(inode, buf, LOGFS_BLOCKSIZE, pos); + if (ret) + return ret; + pos += LOGFS_BLOCKSIZE; + buf += LOGFS_BLOCKSIZE; + n -= LOGFS_BLOCKSIZE; + } + return logfs_inode_write(inode, buf, n, pos); +} + + +int logfs_init_rw(struct logfs_super *super) +{ + int i; + + mutex_init(&super->s_r_sem); + mutex_init(&super->s_w_sem); + super->s_rblock = kmalloc(LOGFS_BLOCKSIZE, GFP_KERNEL); + if (!super->s_wblock) + return -ENOMEM; + for (i=0; i<=LOGFS_MAX_INDIRECT; i++) { + super->s_wblock[i] = kmalloc(LOGFS_BLOCKSIZE, GFP_KERNEL); + if (!super->s_wblock) { + logfs_cleanup_rw(super); + return -ENOMEM; + } + } + + return 0; +} + + +void logfs_cleanup_rw(struct logfs_super *super) +{ + int i; + + for (i=0; i<=LOGFS_MAX_INDIRECT; i++) + kfree(super->s_wblock[i]); + kfree(super->s_rblock); +} --- /dev/null 2006-08-15 20:12:53.000000000 +0200 +++ logfs3/fs/logfs/super.c 2006-08-24 15:39:42.000000000 +0200 @@ -0,0 +1,435 @@ +#include +#include +#include +#include + +#include "logfs.h" + + +#define FAIL_ON(cond) do { if (unlikely((cond))) return -EINVAL; } while(0) + +int mtdread(struct mtd_info *mtd, loff_t ofs, size_t len, void *buf) +{ + size_t retlen; + int ret; + + TRACE(); + ret = mtd->read(mtd, ofs, len, &retlen, buf); + if (ret || (retlen != len)) { + printk("ret: %d\n", ret); + printk("retlen: %d, len: %d\n", retlen, len); + printk("ofs: %lld, mtd->size: %d\n", ofs, mtd->size); + dump_stack(); + return -EIO; + } + + return 0; +} + + +int mtdwrite(struct mtd_info *mtd, loff_t ofs, size_t len, void *buf) +{ + size_t retlen; + int ret; + + TRACE(); + //printk("write ofs=%llx, len=%x\n", ofs, len); + BUG_ON((ofs >= mtd->size) || (len > mtd->size - ofs)); + ret = mtd->write(mtd, ofs, len, &retlen, buf); + if (ret || (retlen != len)) + return -EIO; + + return 0; +} + + +static DEFINE_MUTEX(logfs_erase_sem); +static void logfs_erase_callback(struct erase_info *ei) +{ + mutex_unlock(&logfs_erase_sem); +} +int mtderase(struct mtd_info *mtd, loff_t ofs, size_t len) +{ + struct erase_info ei; + int ret; + + TRACE(); + BUG_ON(len % mtd->erasesize); + + memset(&ei, 0, sizeof(ei)); + ei.mtd = mtd; + ei.addr = ofs; + ei.len = len; + ei.callback = logfs_erase_callback; + ret = mtd->erase(mtd, &ei); + if (ret) + return -EIO; + mutex_lock(&logfs_erase_sem); + return 0; +} + + +int logfs_statfs(struct dentry *dentry, struct kstatfs *stats) +{ + struct logfs_super *super = LOGFS_SUPER(dentry->d_sb); + + stats->f_type = LOGFS_MAGIC_U32; + stats->f_bsize = LOGFS_BLOCKSIZE; + stats->f_blocks = super->s_size >> LOGFS_BLOCK_BITS >> 3; + stats->f_bfree = super->s_free; + stats->f_bavail = super->s_free; /* FIXME: leave some for root */ + stats->f_files = 0; + stats->f_ffree = 0; + stats->f_namelen= LOGFS_MAX_NAMELEN; + return 0; +} + + +static int logfs_sb_set(struct super_block *sb, void *_super) +{ + struct logfs_super *super = _super; + + TRACE(); + sb->s_fs_info = super; + sb->s_dev = MKDEV(MTD_BLOCK_MAJOR, super->s_mtd->index); + + return 0; +} + + +/* + * FIXME: the error recovery logic appears to be wrong. redo. + */ +static int logfs_get_sb_final(struct super_block *sb, struct vfsmount *mnt) +{ + struct inode *inode; + + TRACE(); + + /* root dir */ + inode = iget(sb, LOGFS_INO_ROOT); + if (!inode) + goto fail; + + sb->s_root = d_alloc_root(inode); + if (!sb->s_root) + goto fail1; + + return simple_set_mnt(mnt, sb); + +fail1: + iput(inode); +fail: + iput(LOGFS_SUPER(sb)->s_master_inode); + return -EIO; +} + + +static int logfs_mkfs_rootdir(struct logfs_super *super, + struct logfs_disk_super *ds, u32 seg_size) +{ + struct logfs_disk_inode *di; + u64 root_ofs; + int ret; + + di = kzalloc(sizeof(*di), GFP_KERNEL); + if (!di) + return -ENOMEM; + + di->di_flags = cpu_to_be32(LOGFS_IF_VALID); + di->di_mode = cpu_to_be16(S_IFDIR | 0755); + di->di_refcount = cpu_to_be32(2); + root_ofs = 3*seg_size + LOGFS_INO_ROOT*sizeof(*di); + ret = mtdwrite(super->s_mtd, root_ofs, sizeof(*di), di); + kfree(di); + return ret; +} + + +static int logfs_mkfs_summary(struct logfs_super *super, + struct logfs_disk_super *ds, u32 seg_size) +{ + struct logfs_disk_sum *sum; + u64 sum_ofs; + int ret; + + sum = kmalloc(LOGFS_BLOCKSIZE, GFP_KERNEL); + if (!sum) + return -ENOMEM; + memset(sum, 0xff, LOGFS_BLOCKSIZE); + + sum->blocks[0].ino = cpu_to_be64(LOGFS_INO_MASTER); + sum->blocks[0].pos = cpu_to_be64(0); + sum_ofs = 4*seg_size - LOGFS_BLOCKSIZE; + sum->level = LOGFS_MAX_LEVELS; + ret = mtdwrite(super->s_mtd, sum_ofs, LOGFS_BLOCKSIZE, sum); + kfree(sum); + return ret; +} + + +static int logfs_mkfs_anchor(struct logfs_super *super, + struct logfs_disk_super *ds, u32 seg_size) +{ + struct logfs_journal_entry *je; + int ret; + + je = kzalloc(sizeof(*je), GFP_KERNEL); + if (!je) + return -ENOMEM; + + je->je_type = cpu_to_be16(JE_ANCHOR); + je->je_version = cpu_to_be64(1); + je->da.da_gec = 0; + je->da.da_maxec = 0; + je->da.da_sweeper = cpu_to_be64(4); + je->da.da_last_ino = cpu_to_be64(LOGFS_RESERVED_INOS); + je->da.da_size = cpu_to_be64((LOGFS_INO_ROOT+1) + * sizeof(struct logfs_disk_inode)); + je->da.da_data[0] = cpu_to_be64(3*seg_size); + ret = mtdwrite(super->s_mtd, seg_size, sizeof(*je), je); + kfree(je); + return ret; +} + + +static int logfs_mkfs_super(struct logfs_super *super, + struct logfs_disk_super *ds, u32 seg_size, u32 block_size) +{ + u64 no_segments; + u64 size; + u32 mod; + int sum_start; + int no_blocks; + + ds->ds_magic = cpu_to_be64(LOGFS_MAGIC); + ds->ds_segment_size = cpu_to_be32(seg_size); + ds->ds_block_size = cpu_to_be32(block_size); + + ds->ds_journal_ofs = cpu_to_be64(seg_size); + ds->ds_journal_len = cpu_to_be64(2*seg_size); + + ds->ds_root_reserve = 0; + + size = super->s_mtd->size; /* size must be a multiple of seg_size */ + mod = do_div(size, seg_size); + no_segments = size; + size = super->s_mtd->size - mod; + ds->ds_filesystem_size = cpu_to_be64(size); + +#if 0 /* sane defaults */ + ds->ds_ifile_levels = 3; /* 2+1, 1GiB */ + ds->ds_iblock_levels = 4; /* 3+1, 512GiB */ + ds->ds_data_levels = 3; /* old, young, unknown */ +#else + ds->ds_ifile_levels = 1; /* 0+1, 80kiB */ + ds->ds_iblock_levels = 4; /* 3+1, 512GiB */ + ds->ds_data_levels = 1; /* unknown */ +#endif + + ds->ds_anchor_size = cpu_to_be32(block_size); + no_blocks = seg_size / block_size; + sum_start = block_size; + sum_start -= LOGFS_SEGMENTS * no_blocks * sizeof(struct logfs_block); + BUG_ON(sum_start < 2048); + ds->ds_sum_start = cpu_to_be32(sum_start); + return mtdwrite(super->s_mtd, 0, sizeof(*ds), ds); +} + + +static int logfs_mkfs(struct logfs_super *super, struct logfs_disk_super *ds) +{ + u32 seg_size = 1<<15; + u32 block_size = 1<<12; + int ret = 0; + + TRACE(); + + ret = logfs_mkfs_rootdir(super, ds, seg_size); + if (ret) + return ret; + + ret = logfs_mkfs_summary(super, ds, seg_size); + if (ret) + return ret; + + ret = logfs_mkfs_anchor(super, ds, seg_size); + if (ret) + return ret; + + ret = logfs_mkfs_super(super, ds, seg_size, block_size); + if (ret) + return ret; + + return 0; +} + + +static int logfs_read_sb(struct super_block *sb) +{ + struct logfs_super *super = LOGFS_SUPER(sb); + struct logfs_disk_super ds; + int ret; + + TRACE(); + ret = mtdread(super->s_mtd, 0, sizeof(ds), &ds); + if (ret) + return ret; + + if (be64_to_cpu(ds.ds_magic) != LOGFS_MAGIC) { + ret = logfs_mkfs(super, &ds); + if (ret) + return ret; + } + super->s_segsize = be32_to_cpu(ds.ds_segment_size); + super->s_blocksize = be32_to_cpu(ds.ds_block_size); + super->s_no_blocks = super->s_segsize / super->s_blocksize; + + super->s_log_ofs = be64_to_cpu(ds.ds_journal_ofs); + super->s_log_len = be64_to_cpu(ds.ds_journal_len); + super->s_size = be64_to_cpu(ds.ds_filesystem_size); + super->s_anchor_size = be32_to_cpu(ds.ds_anchor_size); + super->s_sum_start = be32_to_cpu(ds.ds_sum_start); + super->s_root_reserve = be64_to_cpu(ds.ds_root_reserve); + + + super->s_ifile_levels = ds.ds_ifile_levels; + super->s_iblock_levels = ds.ds_iblock_levels; + super->s_data_levels = ds.ds_data_levels; + super->s_total_levels = super->s_ifile_levels + super->s_iblock_levels + + super->s_data_levels; + super->s_gc_reserve = super->s_total_levels * (2*super->s_no_blocks -1); + + /* FIXME: store data in flash superblock */ + mutex_init(&super->s_write_inode_mutex); + + ret = logfs_init_rw(super); + if (ret) + return ret; + + ret = logfs_init_segments(super); + if (ret) + return ret; + + ret = logfs_init_log(sb); + if (ret) + return ret; + + ret = logfs_init_gc(super); + if (ret) + return ret; + + spin_lock_init(&super->s_ino_lock); + return 0; +} + + +static void logfs_kill_sb(struct super_block *sb) +{ + struct logfs_super *super = LOGFS_SUPER(sb); + + TRACE(); + generic_shutdown_super(sb); + logfs_cleanup_gc(super); + logfs_cleanup_log(sb); + logfs_cleanup_segments(super); + logfs_cleanup_rw(super); + put_mtd_device(super->s_mtd); + kfree(super); +} + + +static int logfs_get_sb_mtd(struct file_system_type *type, int flags, + struct mtd_info *mtd, struct vfsmount *mnt) +{ + struct logfs_super *super = NULL; + struct super_block *sb; + int err = -ENOMEM; + + TRACE(); + super = kzalloc(sizeof*super, GFP_KERNEL); + if (!super) + goto err0; + + super->s_mtd = mtd; + err = -EINVAL; + sb = sget(type, NULL, logfs_sb_set, super); + if (IS_ERR(sb)) + goto err0; + + sb->s_maxbytes = LOGFS_I3_SIZE; + sb->s_op = &logfs_super_operations; + sb->s_flags = flags | MS_NOATIME; + + super->s_sb = sb; + err = logfs_read_sb(sb); + if (err) + goto err0; + + sb->s_flags |= MS_ACTIVE; + return logfs_get_sb_final(sb, mnt); + +err0: + kfree(super); + put_mtd_device(mtd); + return err; +} + + +static int logfs_get_sb(struct file_system_type *type, int flags, + const char *devname, void *data, struct vfsmount *mnt) +{ + ulong mtdnr; + struct mtd_info *mtd; + + TRACE(); +#if 0 + if (!devname) + return ERR_PTR(-EINVAL); + if (strncmp(devname, "mtd", 3)) + return ERR_PTR(-EINVAL); + + { + char *garbage; + mtdnr = simple_strtoul(devname+3, &garbage, 0); + if (*garbage) + return ERR_PTR(-EINVAL); + } +#else + mtdnr = 0; +#endif + + mtd = get_mtd_device(NULL, mtdnr); + if (!mtd) + return -EINVAL; + + return logfs_get_sb_mtd(type, flags, mtd, mnt); +} + + +static struct file_system_type logfs_fs_type = { + .owner = THIS_MODULE, + .name = "logfs", + .get_sb = logfs_get_sb, + .kill_sb = logfs_kill_sb, +}; + + +static int __init logfs_init(void) +{ + int ret = logfs_init_inode_cache(); + if (ret) + return ret; + return register_filesystem(&logfs_fs_type); +} + + +static void __exit logfs_exit(void) +{ + unregister_filesystem(&logfs_fs_type); + logfs_destroy_inode_cache(); +} + + +module_init(logfs_init); +module_exit(logfs_exit); From posaune at hotmail.com Fri Aug 25 18:11:21 2006 From: posaune at hotmail.com (Han Chang) Date: Fri, 25 Aug 2006 15:11:21 -0700 Subject: A question about reading newly erased page with NAND_ECC_SOFT. Message-ID: Hi All, For a newly erased page, the content of both user data and oob are 0xff. If NAND_ECC_SOFT is enabled, the ecc code in the oob, which is 0xff, is not right ecc code. Then if the file system tries to read a newly erased page, it will be problem. Does anyone know how to get around this? Thanks, Han From mrmacman_g4 at mac.com Sun Aug 27 14:02:51 2006 From: mrmacman_g4 at mac.com (Kyle Moffett) Date: Sun, 27 Aug 2006 14:02:51 -0400 Subject: LogFS In-Reply-To: <20060827171728.GB3502@wohnheim.fh-wedel.de> References: <20060824134430.GB17132@wohnheim.fh-wedel.de> <20060827053245.GA15747@gen.formicary.org> <20060827171728.GB3502@wohnheim.fh-wedel.de> Message-ID: On Aug 27, 2006, at 13:17:28, J?rn Engel wrote: > On Sun, 27 August 2006 01:32:45 -0400, Ian Lindsay wrote: >> +/* FIXME: This should really be somewhere in the 64bit area. */ >> +#define LOGFS_LINK_MAX (2^30) >> >> Interesting choice of constant. > > Yes. I didn't spend a long time thinking about whether it should > be 2^31 or 2^31-1 or 2^31-2. It will be a while before it becomes > an issue in real life anyway. :) Uhm, I think his point is that "^" is the xor operation: 2^30 == 28 2^31 == 29 2^21-1 == 28 2^21-2 == 31 Probably what you wanted was something more like this: # define LOGFS_LINK_MAX (1<<30) Cheers, Kyle Moffett From joern at wohnheim.fh-wedel.de Sun Aug 27 16:16:48 2006 From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel) Date: Sun, 27 Aug 2006 22:16:48 +0200 Subject: LogFS In-Reply-To: <20060827181245.GA14544@gen.formicary.org> References: <20060827171728.GB3502@wohnheim.fh-wedel.de> <20060827181245.GA14544@gen.formicary.org> Message-ID: <20060827201648.GA8845@wohnheim.fh-wedel.de> On Sun, 27 August 2006 14:12:45 -0400, Ian Lindsay wrote: > > So, 28 should be enough for everyone? No, it just took me more prodding to notice my thinko. Thank you for noticing, the bloody bug is fixed now. Btw, isn't 2^30 32 rather than 28? J?rn -- Geld macht nicht gl?cklich. Gl?ck macht nicht satt. From mrmacman_g4 at mac.com Sun Aug 27 16:53:14 2006 From: mrmacman_g4 at mac.com (Kyle Moffett) Date: Sun, 27 Aug 2006 16:53:14 -0400 Subject: LogFS In-Reply-To: <20060827201648.GA8845@wohnheim.fh-wedel.de> References: <20060827171728.GB3502@wohnheim.fh-wedel.de> <20060827181245.GA14544@gen.formicary.org> <20060827201648.GA8845@wohnheim.fh-wedel.de> Message-ID: <49D5FD4D-4DEC-48CB-B097-D8FD113EA542@mac.com> On Aug 27, 2006, at 16:16:48, J?rn Engel wrote: > On Sun, 27 August 2006 14:12:45 -0400, Ian Lindsay wrote: >> >> So, 28 should be enough for everyone? > > No, it just took me more prodding to notice my thinko. Thank you > for noticing, the bloody bug is fixed now. > > Btw, isn't 2^30 32 rather than 28? Not really. 30 already has the 2 bit set: 30 = 0b11110 = 16 + 8 + 4 + 2 + 0 28 = 0b11100 = 16 + 8 + 4 + 0 + 0 Feel free to run this in a terminal to check: :-) perl -e 'print( (30^2) ."\n" );' Cheers, Kyle Moffett From joern at wohnheim.fh-wedel.de Sun Aug 27 13:17:28 2006 From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel) Date: Sun, 27 Aug 2006 19:17:28 +0200 Subject: LogFS In-Reply-To: <20060827053245.GA15747@gen.formicary.org> References: <20060824134430.GB17132@wohnheim.fh-wedel.de> <20060827053245.GA15747@gen.formicary.org> Message-ID: <20060827171728.GB3502@wohnheim.fh-wedel.de> On Sun, 27 August 2006 01:32:45 -0400, Ian Lindsay wrote: > > +/* FIXME: This should really be somewhere in the 64bit area. */ > +#define LOGFS_LINK_MAX (2^30) > > Interesting choice of constant. Yes. I didn't spend a long time thinking about whether it should be 2^31 or 2^31-1 or 2^31-2. It will be a while before it becomes an issue in real life anyway. :) J?rn -- It's not whether you win or lose, it's how you place the blame. -- unknown From kalev at colleduc.ee Tue Aug 29 08:20:04 2006 From: kalev at colleduc.ee (Kalev Lember) Date: Tue, 29 Aug 2006 15:20:04 +0300 Subject: DiskOn Chip Millennium Plus 32MB + INFTL In-Reply-To: <200606261917.45429.husamsenussi@gmail.com> References: <4488665D.5010908@kalikstein.com> <200606101321.37502.husamsenussi@gmail.com> <1149977115.18635.158.camel@shinybook.infradead.org> <200606261917.45429.husamsenussi@gmail.com> Message-ID: <44F430F4.9040906@colleduc.ee> Husam wrote: > I have manage to get the driver work with 32MiB, so now I need to see if I can > get it to work with 64 MiB. > Hello, Did you manage to get the driver to work with all Diskonchip Millennium Plus devices? Can you please send your latest patch. -- Best regards, Kalev Lember From sudharshana at motorola.com Tue Aug 29 07:27:07 2006 From: sudharshana at motorola.com (M Sudharshana-A18475) Date: Tue, 29 Aug 2006 19:27:07 +0800 Subject: Linux Kernel booting the root file system compiled for another processor In-Reply-To: <200608231745406401974@gmail.com> Message-ID: Hello, Was unsure this question could be raised in this forum. Please ignore if it shouldn't be this forum. I have scenario where, I have options to compile the ROOT file system for either ARM or another processor, with a raider, Linux Kernel is compiled for ARM only. Assuming, "CramFS" is used for both the processor's image. In such a case, Can Linux Kernel mount root file system that is compiled for another processor? Is there any such dependency or nothing at all? Thanks Sudharshana From jaredeh at gmail.com Tue Aug 29 00:44:11 2006 From: jaredeh at gmail.com (Jared Hulbert) Date: Mon, 28 Aug 2006 21:44:11 -0700 Subject: [PATCH] CORE: adding mtd_get_partition_physaddr() Message-ID: <6934efce0608282144ge2250dbv1635377c005a9f74@mail.gmail.com> This is to allow axfs to get the physical address on the flash of it's partition. Signed-off-by: Jared Hulbert diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c index 06a9303..37aed8a 100644 --- a/drivers/mtd/mtdpart.c +++ b/drivers/mtd/mtdpart.c @@ -40,6 +40,17 @@ struct mtd_part { */ #define PART(x) ((struct mtd_part *)(x)) +/* + * Allow other modules to get the physical address of a given partition + */ +void * mtd_get_partition_physaddr (struct mtd_info *mtd) +{ + struct mtd_part *part = PART(mtd); + struct map_info *map = part->master->priv; + + return (void *)(map->phys + part->offset); +} +EXPORT_SYMBOL_GPL(mtd_get_partition_physaddr); /* * MTD methods which simply translate the effective address and pass through diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h index da6b3d6..adf6207 100644 --- a/include/linux/mtd/partitions.h +++ b/include/linux/mtd/partitions.h @@ -68,6 +68,7 @@ extern int register_mtd_parser(struct mt extern int deregister_mtd_parser(struct mtd_part_parser *parser); extern int parse_mtd_partitions(struct mtd_info *master, const char **types, struct mtd_partition **pparts, unsigned long origin); +extern void * mtd_get_partition_physaddr(struct mtd_info *mtd); #define put_partition_parser(p) do { module_put((p)->owner); } while(0) From jdub at us.ibm.com Tue Aug 29 13:13:47 2006 From: jdub at us.ibm.com (Josh Boyer) Date: Tue, 29 Aug 2006 12:13:47 -0500 Subject: [PATCH] CORE: adding mtd_get_partition_physaddr() In-Reply-To: <6934efce0608282144ge2250dbv1635377c005a9f74@mail.gmail.com> References: <6934efce0608282144ge2250dbv1635377c005a9f74@mail.gmail.com> Message-ID: <1156871627.2003.15.camel@zod.rchland.ibm.com> On Mon, 2006-08-28 at 21:44 -0700, Jared Hulbert wrote: > This is to allow axfs to get the physical address on the flash of it's > partition. > > Signed-off-by: Jared Hulbert > > diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c > index 06a9303..37aed8a 100644 > --- a/drivers/mtd/mtdpart.c > +++ b/drivers/mtd/mtdpart.c > @@ -40,6 +40,17 @@ struct mtd_part { > */ > #define PART(x) ((struct mtd_part *)(x)) > > +/* > + * Allow other modules to get the physical address of a given partition > + */ > +void * mtd_get_partition_physaddr (struct mtd_info *mtd) Nit: No space between the paren and the function name please. > /* > * MTD methods which simply translate the effective address and pass through > diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h > index da6b3d6..adf6207 100644 > --- a/include/linux/mtd/partitions.h > +++ b/include/linux/mtd/partitions.h > @@ -68,6 +68,7 @@ extern int register_mtd_parser(struct mt > extern int deregister_mtd_parser(struct mtd_part_parser *parser); > extern int parse_mtd_partitions(struct mtd_info *master, const char **types, > struct mtd_partition **pparts, unsigned long origin); > +extern void * mtd_get_partition_physaddr(struct mtd_info *mtd); Couldn't this be a proper prototype instead of an extern? josh From sharma.amit at samsung.com Tue Aug 29 20:03:06 2006 From: sharma.amit at samsung.com (Amit Kumar Sharma) Date: Wed, 30 Aug 2006 09:03:06 +0900 Subject: JFFS2 message after fsstress test Message-ID: <003401c6cbc7$ac095120$3d92340c@dsn.sec.samsung.com> Hi I am using JFFS2 on oneNand mtd ,After mount I run fsstress test ./fsstress -d mount point -n 50 -c After test complete I restart my target and remount my partition during boot time ,I got following message from JFFS2 ,Can some one tell me why JFFs2 giving these messages. Mounting local filesystems... Eep. Child "f8" (ino #16572) of dir ino #16571 doesn't exist! Eep. Child "fb" (ino #16594) of dir ino #16592 doesn't exist! Inode #16645 was a directory with children - removing those too... Inode #16646 was a directory with children - removing those too... Inode #16574 was a directory with children - removing those too... Inode #16576 was a directory with children - removing those too... /dev/mtdblock5 on /tmp type jffs2 (rw) Cleaning: /etc/network/ifstate. Setting up IP spoofing protection: rp_filter. Disable TCP/IP Explicit Congestion Notification: done. Configuring network interfaces: done. Starting portmap daemon: portmap. Cleaning: /tmp jffs2_do_read_inode() on nonexistent ino 16594 find: ./p0/d4/fb: Input/output error jffs2_do_read_inode() on nonexistent ino 16572 find: ./p0/d7/f8: Input/output error JFFS2 compression type 0x06 not available. Error: jffs2_decompress returned -5 JFFS2 compression type 0x06 not available. Error: jffs2_decompress returned -5 /var/lock /var/run. Rgs Amit From jaredeh at gmail.com Tue Aug 29 15:37:28 2006 From: jaredeh at gmail.com (Jared Hulbert) Date: Tue, 29 Aug 2006 12:37:28 -0700 Subject: [PATCH] CORE: adding mtd_get_partition_physaddr() In-Reply-To: <1156871627.2003.15.camel@zod.rchland.ibm.com> References: <6934efce0608282144ge2250dbv1635377c005a9f74@mail.gmail.com> <1156871627.2003.15.camel@zod.rchland.ibm.com> Message-ID: <6934efce0608291237m7779c57dj23ebc8435c8f43ea@mail.gmail.com> > > +void * mtd_get_partition_physaddr (struct mtd_info *mtd) > > Nit: No space between the paren and the function name please. oops > > +extern void * mtd_get_partition_physaddr(struct mtd_info *mtd); > > Couldn't this be a proper prototype instead of an extern? I thought EXPORT_SYMBOL_GPL() implied it should be extern. Is that incorrect? From hae at port.de Wed Aug 30 03:12:18 2006 From: hae at port.de (=?iso-8859-1?q?R=FCdiger_H=E4rtel?=) Date: Wed, 30 Aug 2006 09:12:18 +0200 Subject: DiskOn Chip Millennium Plus 32MB + INFTL In-Reply-To: <44F430F4.9040906@colleduc.ee> References: <4488665D.5010908@kalikstein.com> <200606261917.45429.husamsenussi@gmail.com> <44F430F4.9040906@colleduc.ee> Message-ID: <200608300912.19081.hae@port.de> Am Tuesday 29 August 2006 14:20 schrieb Kalev Lember: > Husam wrote: > > I have manage to get the driver work with 32MiB, so now I need > > to see if I can get it to work with 64 MiB. > > Hello, > > Did you manage to get the driver to work with all Diskonchip > Millennium Plus devices? > Can you please send your latest patch. Hello Kalev, I didn't get it to work. The device had another "normal" flash chip. A bigger flash was used and so the Diskonchip option was removed. Best reagrds, R?diger From sshtylyov at ru.mvista.com Wed Aug 30 08:32:20 2006 From: sshtylyov at ru.mvista.com (Sergei Shtylyov) Date: Wed, 30 Aug 2006 16:32:20 +0400 Subject: [PATCH] CORE: adding mtd_get_partition_physaddr() In-Reply-To: <6934efce0608291237m7779c57dj23ebc8435c8f43ea@mail.gmail.com> References: <6934efce0608282144ge2250dbv1635377c005a9f74@mail.gmail.com> <1156871627.2003.15.camel@zod.rchland.ibm.com> <6934efce0608291237m7779c57dj23ebc8435c8f43ea@mail.gmail.com> Message-ID: <44F58554.5040801@ru.mvista.com> Hello. Jared Hulbert wrote: >>>+extern void * mtd_get_partition_physaddr(struct mtd_info *mtd); >>Couldn't this be a proper prototype instead of an extern? > I thought EXPORT_SYMBOL_GPL() implied it should be extern. Is that incorrect? Function declarations in C imply 'extern' by default. WBR, Sergei From buytenh at wantstofly.org Wed Aug 30 10:04:21 2006 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Wed, 30 Aug 2006 16:04:21 +0200 Subject: PM for physmap.c ? In-Reply-To: <44EC6F2F.7070508@imc-berlin.de> References: <44EC6F2F.7070508@imc-berlin.de> Message-ID: <20060830140421.GK19179@xi.wantstofly.org> On Wed, Aug 23, 2006 at 05:07:27PM +0200, Steven Scholz wrote: > Hi all, Hello, > for quite some time physmap.c uses platform_{device,driver}. > > I wonder why it does not contain any (generic) code for power management > yet, i.e. .suspend/.resume functions. > > Is it correct that all I would need to survive a suspend/resume cycle is > something like > > int physmap_flash_suspend(struct platform_device *dev, pm_message_t state) > { > struct sa_info *info = platform_get_drvdata(dev); > int ret = 0; > if (info) > ret = info->mtd->suspend(info->mtd); > return ret; > } > > int physmap_flash_resume(struct platform_device *dev) > { > struct sa_info *info = platform_get_drvdata(dev); > if (info) > info->mtd->resume(info->mtd); > return 0; > } > > as stolen from sa1100-flash.c? Looks OK to me, but that doesn't say much. cheers, Lennert From steven.scholz at imc-berlin.de Wed Aug 30 11:04:35 2006 From: steven.scholz at imc-berlin.de (Steven Scholz) Date: Wed, 30 Aug 2006 17:04:35 +0200 Subject: PM for physmap.c ? In-Reply-To: <20060830140421.GK19179@xi.wantstofly.org> References: <44EC6F2F.7070508@imc-berlin.de> <20060830140421.GK19179@xi.wantstofly.org> Message-ID: <44F5A903.1050104@imc-berlin.de> Lennert, >> for quite some time physmap.c uses platform_{device,driver}. >> >> I wonder why it does not contain any (generic) code for power management >> yet, i.e. .suspend/.resume functions. >> >> Is it correct that all I would need to survive a suspend/resume cycle is >> something like >> >> int physmap_flash_suspend(struct platform_device *dev, pm_message_t state) >> { >> struct sa_info *info = platform_get_drvdata(dev); >> int ret = 0; >> if (info) >> ret = info->mtd->suspend(info->mtd); >> return ret; >> } >> >> int physmap_flash_resume(struct platform_device *dev) >> { >> struct sa_info *info = platform_get_drvdata(dev); >> if (info) >> info->mtd->resume(info->mtd); >> return 0; >> } >> >> as stolen from sa1100-flash.c? > > Looks OK to me, but that doesn't say much. ;-) Thanks for your reply anyway. Thought I am getting ignored for asking stupid things... However could one of the MTD gurus please state on the following: - Would the above be enough? - Is it needed at all? For normal NOR flash (that's what physmap.c is for?). - What could happen without proper PM handling? - Is it worth it to provide a proper patch? Thanks a million! -- Steven From tglx at linutronix.de Wed Aug 30 12:37:57 2006 From: tglx at linutronix.de (Thomas Gleixner) Date: Wed, 30 Aug 2006 18:37:57 +0200 Subject: Issue with h/w ecc based NAND driver. In-Reply-To: References: Message-ID: <1156955877.29250.186.camel@localhost.localdomain> On Wed, 2006-08-23 at 11:12 -0700, Han Chang wrote: > Hi there, > > I'm using a NAND with h/w ecc. When a block is erased, both main data and > oob are set to 0xff, and if the driver read the main data in the page with > hardware enabled ecc, the 0xff in the oob is not the right ecc code, so the > ecc mechanism in the h/w try to recover the error and trash the content in > the main data area. > > I tried to set the right ecc code in the oob for every page whenever a block > is erased. But then the problem is with page programming. When write a page, > the h/w ecc controller generates the ecc code and write it to the oob, since > the oob is already written once during erase, the 2nd write to the oob is > not taken well. So when read back the same page, it causes ecc error again. > > I would appreciate very much if someone can shed some light on this kind of > delimma. That's a know problem with braindead hardware. One solution is to apply cluesticks (i.e. baseball bats) on the hardware designer. This only helps for your well-being and does not solve the problem itself. Look into drivers/mtd/nand/diskonchip.c doc200x_correct_data(). There is an approach to tackle exactly the same problem. tglx From mark.ferguson1 at virgilio.it Wed Aug 30 13:40:36 2006 From: mark.ferguson1 at virgilio.it (Mark Ferguson) Date: Wed, 30 Aug 2006 18:40:36 +0100 (GMT+01:00) Subject: I AWAIT YOUR RESPONSE Message-ID: <10d602b0d9d.mark.ferguson1@virgilio.it> Dear Friend, I write to you based on a request by an investor and his need for investment/funding in your country. My name is Mark Ferguson, a financial consultant and I work with a reputable financial services firm. My company most times represents the interests of very wealthy investors. Due to the sensitivity of the position they hold in thier society and the unstable investment environment of their country, they evacuate majority of their funds into more stable economies and developed nations where they can get good yield for their money. I was recently approached by a Reserved Client, whom I had personally worked with a few years ago with a proposal.What he request is an individual such as yourself, who will be willing to receive money on his behalf abroad, and put it to good use for a period not exceeding 6 years for a start. The client has offered these terms: 1. 30% commission paid to me and my foreign partner of the total funds successfully evacuated. The funds in question are over 13.2Million USDollars. 2. The funds will be used by the foreign partner for six years as a loan without any interest. That is, you do not pay any interest on the money but you give the client 50% of all profits after tax that accrued from the use of the funds. If these terms are agreeable to you, kindly let me know and I will provide you with all necessary information and procedures involved. Looking forward for your prompt response. Sincerely yours, Mark Ferguson. From tglx at linutronix.de Wed Aug 30 18:29:38 2006 From: tglx at linutronix.de (Thomas Gleixner) Date: Thu, 31 Aug 2006 00:29:38 +0200 Subject: A question about reading newly erased page with NAND_ECC_SOFT. In-Reply-To: References: Message-ID: <1156976978.29250.233.camel@localhost.localdomain> On Fri, 2006-08-25 at 15:11 -0700, Han Chang wrote: > Hi All, > > For a newly erased page, the content of both user data and oob are 0xff. If > NAND_ECC_SOFT is enabled, the ecc code in the oob, which is 0xff, is not > right ecc code. Then if the file system tries to read a newly erased page, > it will be problem. Does anyone know how to get around this? It is correct. The software based ECC value of all 0xFF is 0xFF tglx From lanconelli.claudio at eptar.com Fri Aug 25 10:00:48 2006 From: lanconelli.claudio at eptar.com (Claudio Lanconelli) Date: Fri, 25 Aug 2006 14:00:48 -0000 Subject: [PATCH][NAND] Add ssfdc read-only translation layer In-Reply-To: <1151417243.17609.151.camel@hades.cambridge.redhat.com> References: <449AA7E2.5020609@eptar.com> <1151417243.17609.151.camel@hades.cambridge.redhat.com> Message-ID: <44EF0001.3000803@eptar.com> Hi, > >> One question, I use major number 44 (since it's the number used by old >> ssfdc.c) but I don't know if it's the correct number. >> > > It isn't. Please send mail to device at lanana.org requesting a new major > number. > It takes some time but finally I got a new major number: 257 block SSFDC Flash Translation Layer filesystem 0 = /dev/ssfdca First SSFDC layer 8 = /dev/ssfdcb Second SSFDC layer 16 = /dev/ssfdcc Third SSFDC layer 24 = /dev/ssfdcd 4th SSFDC layer 32 = /dev/ssfdce 5th SSFDC layer 40 = /dev/ssfdcf 6th SSFDC layer 48 = /dev/ssfdcg 7th SSFDC layer 56 = /dev/ssfdch 8th SSFDC layer > Also, why is the GETGEO stuff conditional? Why not just build it in > always? And do we need the table? Can't we just calculate it? There's > code to do similar calculations in NFTL already. > > and also I removed GETGETO conditional stuffs. New version in the attachment Cheers, Claudio Lanconelli -------------- next part -------------- A non-text attachment was scrubbed... Name: ssfdc_ro.patch Type: text/x-patch Size: 4622 bytes Desc: not available Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20060825/6eec1a8b/attachment.bin