On Wednesday 25 June 2003 06:55, you wrote:
> Thank you so much for all your help Charles,
>
> In case you're curious. I have successfully flashed a filesystem image
> from the bootloader. The YAFFS image was created by cross compiling
> mkyaffsimage (PPC32). I then mounted an root filesystem from x86 and ran
> mkyaffsimage on the device on a NFS directory. After flashing the image
> from the bootloader there are still some problems. I have about 5 objects
> that are in the lost+and+found, the same objects verified on 2 different
> devices (probably not bad block related).
>
> I'm assuming at the moment that the problem lies in the mkyaffsimage util,
> but not sure what is going wrong as I used a natively built mkyaffsimage.
> I'll keep you updated.
>
> Chris
Chris
That's a sneaky way of doing it :-).
Question 1: Once you've mounted the YAFFS image, does it work fine with
subsequent read/write/delete etc activity. ie. is it just the original image
files that got screwed up?
Question 2: What is the magnitude of the objxxx filenames? YAFFS starts
allocating these at 256.
I'll explain a bit about this: YAFFS scanning 101.
As YAFFS scans the device (on mount), it reads the chunks.
If a chunk discarded/deleted it is ignored. Otherwise it looks at the tags
which tell it whether the chunk is an object header or file data chunk.
If it is a file data chunk then it looks at the file id and chunkId (offset
into file). If YAFFS already knows about the file with this id, then the
chunk is just added to the tree for that file. If, however, the file is not
already known about, then a file entry with that id is created. If the
file's parent (ie the directory it is in) is not known about then we just
create the file in lost+and+found (LNF).
If, however, the chunk is an object header, this tells us the file name etc
and who its parent is. This helps us create the directory stucture.
The file might already exist (created already in LNF as per above) and the
directory structure is rectified.
When scanning is complete, everything should be sorted out and there should
be nothing in LNF.
The only reasons you will find things in lost and found are the following:
* Data chunks for which there are no corresponding object entries: These
will appear as files named objnnn where nnn is the object id (==inode) of the
file.
* Files who do not have parents (ie. parent directory is missing): These will
be of the form objnnn/filename. THis means that file filename thinks its
parent should be object nnn, but this object does not exist.
This could potentially be caused by data corruption of these fields, but
it is highly unlikely. More likely one of the following is happening:
* You're getting some endian mismatching issue (including bitfield
mismatching).
* You're somehow mismatching the area of NAND (ie. yaffs is not scanning some
of the data chunks where you wrote the image and thereby getting some missing
data).
If you can't make any headway with some effort, plz feel free to send me a
**small** image (say a directory or two with a few small files, links etc)
and a matching tar file. Send direct to me to not snow the list.
-- Charles
---------------------------------------------------------------------------------------
This mailing list is hosted by Toby Churchill open software (
www.toby-churchill.org).
If mailing list membership is no longer wanted you can remove yourself from the list by
sending an email to
yaffs-request@toby-churchill.org with the text "unsubscribe"
(without the quotes) as the subject.
(text/plain)