Hey Charles, Thanks for the response, I've been busy with other things and haven't had the chance to try a few things out until today. My responses are below preceded by "CGAN:". Christian Gan -----Original Message----- From: Charles Manning [mailto:manningc2@actrix.gen.nz] Sent: Wednesday, August 21, 2002 2:46 AM To: Christian Gan; YAFFS list Subject: Re: YAFFS Pecularities in directory after remount > > 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. CGAN: Great, can I get a t-shirt or something now? :) > > 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. CGAN: Yes, our board is built with many IOs, we thought it would save us some lines to the ARM if we funnel the interface through the FPGA. This also allowed us to implement our own HW ECC as well as connect multiple NANDs that share the same CLE, ALE, WE, etc lines (FPGA takes care of the timing). CGAN: As to your other questions: - Yes the flash is still 512 data byes + 16 bytes oob and 32 pages/block. - No the FPGA does not actually write to the OOB itself, it just passes back the ECC value in a register that can be read. > > 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. CGAN: Hmmm, I was not unmounting the device before I rebooted. I tried a few preliminary tests and it SEEMS that things are okay and I do not get the 0 length files. I had thought the serial number algo in YAFFS takes care of situations like this when power goes down unexpectedly. What happens during a umount that may explain this? 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. --------------------------------------------------------------------------------------- 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.