Hi everyone,

any ideas?

>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

_______________________________________________
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

Reply via email to