>
> I'm new to the list so don't mind me if I'm just repeating something that's
> been said already but... here goes:

No worries Christian, the list is pretty young, so once you've posted more 
than about twice you're a seasoned pro.

>
> Equipment:
>
> Custom ARM720 core SBC running Linux (2.4.6), MTD is upgraded to newest
> version.
> Toshiba 16MB NAND flash w/ HW ECC (through custom FPGA design).

This is pretty funky hardware. Most yaffs setups are using raw NAND without 
FPGA etc. Questions:
* Is the flash still 512 data bytes + 16 bytesOOB per page and 32 pages/block?
* Does the FPGA use any of the OOB for its own purposes? Maybe this is 
preventing the YAFFS tagging from working properly. See below.

>
> Question 1:
>
> I managed to get the MTD and yaffs working after tweaking both to match our
> interface to the NAND (via the FPGA).
>
> Here's the breakdown:
> 1.  Copy a file onto the yaffs directory.
> 2.  Delete it.
> 3.  Copy another file into the directory with the same name.
> 4.  Reboot and remount the yaffs directory.
>
> What I sometimes find now is that the file is there but the size is 0.
> Anyone else see this?

OK. I just tried this out using yaffsram on my PC with the currently checked 
in code and I did not get this problem. The only difference between yaffsram 
and yaffs on mtd is that yaffsram emulates the mtd with RAM.

Assumptions:
* You're working with the latest code.
* You umounted the YAFFS fs before the reboot.

In a nutshell here's a quick explanation of how YAFFS works on the media and 
thus what might be happening.

YAFFS stores everything as 512byte+16byte OOB "chunks". Chunks can be 
ObjectHeaders (ie. named entities) or file data chunks.
Each Object has an objectId. The ObjectHeader chunk is tagged with ObjectId:0 
and data and other status info. Tags live in the OOB area.

When an chunk becomes invalidated (when overwritten or deleted), it gets 
marked as deleted (by setting a byte in the OOB area). When all the chunks in 
a block get deleted, the block is erased and reused.

Now let's walk through what happens when we do what you did.
* Copy file. This has the following sub-steps:
 - Create file: Makes an ObjectHeader for the file. Length 0.
 - Write data to file: Writes a bunch of file data chunks.
 - Close/flush file: Writes an updated object header with the right length 
and deletes the old one.
 * Delete file: Deletes the file data chunks and the ObjectHeader for the 
file.
* Create new file does the above all over agian.

On the flash, we now have more than one ObjectHeader for the file, but all 
except one should be deleted.

While all the data structures are in RAM relative sanity prevails.

When the device is rebooted it needs to scan the media to reconstruct the fs 
state. You can see what it does in yaffs_Scan(). Basically it just iterates 
over the pages in flash ignoring unused and deleted chunks. As it encounters 
valid chunks it reconstructs the state.

Now, here's my theory... Maybe the deletion is not working properly (because 
perhaps your FPGA is using bytes that YAFFS wants to use for tags) and when 
the scanning is done,  more than one ObjectHeader is read and the wrong 
ObjectHeader (the zero length one) is being used by mistake.

To test this theory, could you turn on some of the tracing in yaffs_Scan and 
see if that tells anything (eg. see if you get multiple ObjectHeaders for the 
same file).

>
> Question 2:
>
> I also find that when I keep copying files into the directory until it is
> full, the last copy will be stuck in an infinite loop.

Yup looks like a problem. Thanx. I thought I'd fixed this. I'll look into 
this ASAP.

-- 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.