Again 2.6.18-RC6 XScale P30 issues
Hi, me again ...
I am sorry to bother you again, but I still have issues withe the P30 flashes.
Now that I can write to the chips I tested it a little more. After a fresh write of a clean rootfs I can create and delete files almost fine (I just get very few CRC errors but everything else works OK, also the files are intact).
But after creating and deleting files and a reboot I get:
----------
[42949375.760000] Write of 68 bytes at 0x00cf91d0 failed. returned -30, retlen 0 [42949375.770000] Not marking the space at 0x00cf91d0 as dirty because the flash driver returned retlen zero [42949375.780000] Write of 68 bytes at 0x00cf91d0 failed. returned -30, retlen 0 [42949375.780000] Not marking the space at 0x00cf91d0 as dirty because
the flash driver returned retlen zero
ifup: /var/run/ifstate: Read-only file system
............
Starting telnetd...
Starting slideshow with images from the internal flash... Starting pid 695, console /dev/ttyS0: '/bin/sh'
Processing /etc/profile... Done
[@colineator /]#cd
[@colineator /root]#ls -l
-rw-r--r-- 1 0 0 5242880 Jan 1 00:14 blub
[@colineator /root]#rm blub
[42949387.590000] Write of 44 bytes at 0x00cf91d0 failed. returned -30, retlen 0 [42949387.600000] Not marking the space at 0x00cf91d0 as dirty because the flash driver returned retlen zero [42949387.610000] Write of 44 bytes at 0x00cf91d0 failed. returned -30, retlen 0 [42949387.620000] Not marking the space at 0x00cf91d0 as dirty because
the flash driver returned retlen zero
rm: unable to remove `blub': Read-only file system
----------------
So something is still wrong. At runtime the filesystem seems to be OK but after a reboot it seems to be defect. Only way to recover is to reflash the rootfs.
I am quite desperate right now.
For the new approach I took the Mainstone MTD mapping driver and modified it for the single two-chip configuration. But I did not change anything beyond that.
Cheers
nils faerber
Signature · 4 lines
kernel concepts GbR Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen Mob: +49-176-21024535 --
Quoted 4 lines · Nils Faerber
So something is still wrong. At runtime the filesystem seems to be OK but after a reboot it seems to be defect. Only way to recover is to reflash the rootfs.
Is the bootup process writing to flash before you unlock it? syslogd might be a culprit...
Quoted 6 lines · Justin Clacherty
Quoted 3 lines · Nils Faerber
So something is still wrong. At runtime the filesystem seems to be OK but after a reboot it seems to be defect. Only way to recover is to reflash the rootfs.
Is the bootup process writing to flash before you unlock it? syslogd might be a culprit...
Well, yes, there are some scripts that touch the fs, but that is IMHO not the issue here. If it would be I would get the other "unable to write to locked sector" error.
Instead the fs gets permanently corrupted, i.e. data is written and the written data is wrong.
Last night I found that the JFFS2 write cache is configured. I will disable that now and see if that helps - I have the impression that the fs may contain half-baked stuff after a write. On the other hand, the JFFS2 write cache is not marked as an experimental feature so I thought I should be safe...
Well, that like poking with a long pole in the mist, I have to admit. Very nasty to debug...
If I find something new I'll let you know ;)
But many thanks for your (all of you) help so far!
Cheers
nils faerber
Signature · 4 lines
kernel concepts GbR Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen Mob: +49-176-21024535 --
Quoted 5 lines · Nils Faerber
Quoted 4 lines · Justin Clacherty
Quoted 3 lines · Nils Faerber
So something is still wrong. At runtime the filesystem seems to be OK but after a reboot it seems to be defect. Only way to recover is to reflash the rootfs.
Quoted 8 lines
Quoted 2 lines
Is the bootup process writing to flash before you unlock it? syslogd might be a culprit...
Well, yes, there are some scripts that touch the fs, but that is IMHO not the issue here. If it would be I would get the other "unable to write to locked sector" error.
Instead the fs gets permanently corrupted, i.e. data is written and the written data is wrong.
How are you resetting the board?
Quoted 5 lines
Last night I found that the JFFS2 write cache is configured. I will disable that now and see if that helps - I have the impression that the fs may contain half-baked stuff after a write. On the other hand, the JFFS2 write cache is not marked as an experimental feature so I thought I should be safe...
It typically is if you do things correctly. You should remount the filesystem as read-only or at the very least sync it before resetting. The writecache gets flushed every 5 seconds or so. Depending on the amount of data in there, if you reset without it being flushed you'll loose data or even whole files.
josh
Quoted 3 lines · Nils Faerber
not the issue here. If it would be I would get the other "unable to write to locked sector" error.
Yes, you're probably right about that.
Quoted 3 lines
Instead the fs gets permanently corrupted, i.e. data is written and the written data is wrong.
hmmm,,,didn't realise it was getting permanently corrupted.
Quoted 6 lines
Last night I found that the JFFS2 write cache is configured. I will disable that now and see if that helps - I have the impression that the fs may contain half-baked stuff after a write. On the other hand, the JFFS2 write cache is not marked as an experimental feature so I thought I should be safe...
Can't speak from experience here as I don't have write cache enabled, but I don't imagine you'd lose the whole fs if you were using write cache and lost power. I suspect you'd just lose your changes or maybe the file that was being updated.
Justin.