Hi Greg, >Hi Siegfried, > >On 07/09/2011 01:58 AM, Siegfried Müller - MB Connect Line GmbH wrote: >> Hi Greg, >> >>> Hi Siegfried, >> >>> On 05/07/11 15:28, Siegfried M³ller - MB Connect Line GmbH wrote: >>>> Hi Greg, >>>> >>>>> Hi Siegfried, >>>> >>>>> On 24/06/11 21:36, Siegfried Mâ"¬â"'ller - MB Connect Line GmbH wrote: >>>>>> Hi, >>>>>> >>>>>>> I'm trying to get jffs2 running on snapgear4.0.7. I have an IXP430 with >>>>>>> Intel Strataflash. The configuration is very similar to the montajade >>>>>>> board and IXPDG425, but with IXP430. I fixed now to run the >>>>>>> snapgear4.0.7 with this hardware, but the only thing is the jffs >>>>>>> filesystem. I have: >>>>>> >>>>>> # cat /proc/mtd >>>>>> dev: size erasesize name >>>>>> mtd0: 00080000 00020000 "RedBoot" >>>>>> mtd1: 00c80000 00020000 "Image" >>>>>> mtd2: 00300000 00020000 "zImage" >>>>>> mtd3: 00980000 00020000 "ramdisk" >>>>>> mtd4: 002c0000 00020000 "s600" >>>>>> mtd5: 00001000 00020000 "RedBoot config" >>>>>> mtd6: 00020000 00020000 "FIS directory" >>>>>> >>>>>> "s600" is my config fs, which I want to mount on /etc/config with jffs2.. >>>>>> >>>>>> I do: >>>>>> >>>>>> # eraseall /dev/flash/config >>>>>> Erased 2816 Kibyte @ 0 -- 100% complete. >>>>>> >>>>>> # mount -t jffs2 /dev/flash/configblock /etc/config >>>>>> >>>>>> I get this messages... >>>>>> --snipp >>>>>> Further such events for this erase block will not be printed >>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0000: >>>>>> 0x0080 id >>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0004: >>>>>> 0x0080 id >>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0008: >>>>>> 0x0080 id >>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c000c: >>>>>> 0x0080 id >>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0010: >>>>>> 0x0080 id >>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0014: >>>>>> 0x0080 id >>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0018: >>>>>> 0x0080 id >>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c001c: >>>>>> 0x0080 id >>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0020: >>>>>> 0x0080 id >>>>>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c0024: >>>>>> 0x0080 id --snipp >>>>>> >>>>>> I already goggled a lot of this issue, but don't solved it. >>>>>> What I can say, it that I also have a image with snapgear3.4 and this >>>>>> IXP430 and there I get everything running. But I cant >this version, >>>>>> because there are also a few other things in SG3.4 what are not ready >>>>>> for this IXP430.. >>>>>> But in anycase, if I first start the image with SG3.4 on this hardware, >>>>>> I'm able to mount the /etc/config and read/write. When I then start the >>>>>> image with SG4.0.7 I can also read/write. So I guess it couldn't be the >>>>>> hardware, it must be something in the changes of jffs2 from SG3.4 to >>>>>> SG4.0.7. >>>>>> >>>>>> Does anyone has an idea? >>>>> >>>>> That is going from a 2.6.17 kernel to a 2.6.26. And a diff of the >>>>> fs/jffs2 in each is kinda large. >>>>> >>>>> What type of flash is this board using? From the erase sizes I am >>>>> guessing some type of intel strata flash? Is it a J3 or P30 type? >>>> >>>> I use the Intel Strata Flash JS28F128 J3F75. >>> >>> Ok, you don't have to deal with the power up locked segments then. >>> >>> The "0x0080" read value sure looks like the read status result of the >>> flash, and not the contents of that addressed location. >>> >>> If you dump the contents of the flash what does it look like after the >>> erase. Something like with: >>> >>> hexdump /dev/flash/config >>> >> Here is the result after "eraseall" >> >> # hexdump /dev/flash/config >> 0000000 ffff ffff ffff ffff ffff ffff ffff ffff >> * >> 02c0000 >> # > >That certainly looks good. It sure does look like the flash is properly erased. > > >> Could that be a timing problem on expansion bus? Well I use the same >> adjustments as in 2.6.17. > >Perhaps. But it sure looks like the underlying MTD driver has the flash in the >wring mode when trying to read the data values (it looks to be in status mode).
But if it is a general problem of the underlying MTD driver I don't understand, why it is ok when the flash is formatted with my image from 2.6.17 and the I start the 2.6.26 and everything could be read and from/to flash. The only thing I cannot do is formatting. Do you have an idea how to more detail the problem? kind regards Siegfried _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
