[uClinux-dev] dont get jffs2 formated on snapgear4.0.7

Siegfried Müller - MB Connect Line GmbH mueller at mbconnectline.de
Mon Jul 11 08:59:15 EDT 2011


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



More information about the uClinux-dev mailing list