From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lo.gmane.org ([80.91.229.12]) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QNSV5-0001R3-Q9 for linux-mtd@lists.infradead.org; Fri, 20 May 2011 16:24:32 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QNSV4-0006HU-6p for linux-mtd@lists.infradead.org; Fri, 20 May 2011 18:24:30 +0200 Received: from 524B25FE.cm-4-4a.dynamic.ziggo.nl ([82.75.37.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 May 2011 18:24:30 +0200 Received: from timonterbraak by 524B25FE.cm-4-4a.dynamic.ziggo.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 May 2011 18:24:30 +0200 To: linux-mtd@lists.infradead.org From: Timon ter Braak Subject: Re: ubiattach error! Date: Fri, 20 May 2011 16:24:18 +0000 (UTC) Message-ID: References: <71103bce1003230226q7fce2443vad3853d7c6d6d947@mail.gmail.com> <1270715032.6754.108.camel@localhost> <1305901388.2630.151.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Artem Bityutskiy gmail.com> writes: > Hmm. Can you confirm that: > > 1. you can attach the mtd device successfully. > 2. detach it and attach again successfully. > 3. Have a power cut, and then be unable attach it again because of this > error? > > Do you flash an UBI image? How do you do this? UBI itself is always able to attach to the mtd. The kernel is present on the same chip and is never corrupted (of course it is never written to). However, many times either the recovery of UBIFS fails, or we get some errors after booting the kernel (probably spawned by 'ubi_bgt0d'?). I will be happy to provide more information, but I am not sure what exactly. It is difficult to separate what procedure corrupt the filesystem and what does work. For example, even a normal 'reboot' command results in the message 'recovery needed'; is that normal? We flash a UBI image generated by the buildroot toolchain (we used buildroot 2010.05 and 2011.02). We are able to work with the system for an arbitrary amount of reboots and/or power cycles, but I can almost destroy the filesystem on command. I am working with a custom designed board for research purposes. The board has been available for about a year right now. We started with linux 2.6.33.4 and tried various patches and kernel upgrades, to no avail. We think the main problem is that we use a Spansion GL512P NOR flash, while most mechanisms within UBI(FS) assume a certain state machine within the chip that may not hold at all times for this one? Best regards, Timon ter Braak Creating 3 MTD partitions on "physmap-flash.0": 0x000000000000-0x000000400000 : "linux" 0x000000400000-0x000002000000 : "rootfs" 0x000002000000-0x000004000000 : "rest" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 130944 bytes UBI: smallest flash I/O unit: 1 UBI: VID header offset: 64 (aligned 64) UBI: data offset: 128 UBI: max. sequence number: 76 UBI: attached mtd1 to ubi0 UBI: MTD device name: "rootfs" UBI: MTD device size: 28 MiB UBI: number of good PEBs: 224 UBI: number of bad PEBs: 0 UBI: number of corrupted PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 0 UBI: total number of reserved PEBs: 224 UBI: number of PEBs reserved for bad PEB handling: 0 UBI: max/mean erase counter: 2/1 UBI: image sequence number: 0 UBI: background thread "ubi_bgt0d" started, PID 21 macb macb: invalid hw address, using random macb macb: eth0: Features changed: 0x00004800 -> 0x00004000 MACB_mii_bus: probed eth0: Atmel MACB at 0xfffbc000 irq 22 (aa:4b:67:1f:7a:58) eth0: attached PHY driver [Marvell 88E1111] cpuidle: using governor ladder cpuidle: using governor menu TCP cubic registered NET: Registered protocol family 17 Installing 9P2000 support UBIFS: recovery needed UBIFS: recovery completed UBIFS: mounted UBI device 0, volume 0, name "rootfs" UBIFS: file system size: 27498240 bytes (26853 KiB, 26 MiB, 210 LEBs) UBIFS: journal size: 7725696 bytes (7544 KiB, 7 MiB, 59 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: lzo UBIFS: reserved for root: 0 bytes (0 KiB)