On Thu, 22 Sep 2005, Charles Manning wrote: > On Thursday 22 September 2005 04:13, Sergey Kubushyn wrote: > > > OK, now for the yesterday's torture test. First of all, YAFFS failed > > miserably. Now about setup and results. > > > > I did not expect your test to last very long. > > Those ecc errors you talk about are: "YAFFS TELLING YOU THAT THE > MTD/YAFFS > INTERFACE IS WRONG AND DATA IS GETTING SCREWED UP" That FS mounted as root FS is not giving errors. The second one does. > Now I've tried to tell you this a few times, but it seems you do not > wish to > listen. If you will not listen then we can't help you and further > responses > to your postings is a waste of time. I'm trying to help. > YAFFS is telling you there is a problem. Focus on the problem. There > are > numerous posts in the past on how to look into the issue and that this > is > combined YAFFS/mtd effort to get things going. Many people have had to > tread > this path before. It is far from ideal, but we're working on improving > it > (currently waiting on mtd fixes) OK, as I understand you're trying to say that every single kernel is unique and there is no way to fix that yaffs/mtd problem because of that uniqueness? Can you simply tell something like "When using its internal ECC YAFFS uses such and such MTD functions and expects that they would return the raw NAND data?" It would be very easy to fix those functions instead of trying to understand what YAFFS is trying to do and what MTD think of that? I simply can't believe that it requires two years to fix a couple of functions in MTD. Name those functions and I'll fix them myself. Would you also be so kind to disclose what mtd fixes you're waiting on? MTD code is not that big and there is no reason to drag that same matter for years. Please say it loud and clear: "We do use the following functions from MTD and expect them to behave in such and such way." Then MTD can be fixed. As for now there is no other requirements than that old mantra "MTD is bad." It's easy to fix any code if one knows what to fix. Having those errors still not fixed after at least two years clearly indicates that nobody even tried to do that. I don't think anyone has enough time to grok how the entire yaffs/yaffs2 works and anticipate what it supposed to expect from MTD and whatever else. MTD, on the other hand, is as simple as a shovel so if you want its blade to be bent in some particular way, just whistle. Generic MTD utilities (nanddump, nandwrite etc.) do NOT have any problems getting anything they need from MTD. That means they DO know how to ask MTD layer for what they want. YAFFS, on the other hand, has been having problems for as long as the list goes. May be it's time to finally fix something, be it misbehaving MTD or buggy YAFFS? Such a thing as a filesystem should NOT require any black magic or monkey drum dances, it MUST compile and work right out of the box. Let's start with 512-byte devices that are more common now and code for those is more of a legacy. Don't ask MTD for any funny tricks, just ask it to read and write data exactly as it's instructed to do and do everything else yourself. Make at least that work out of the box without resorting to "MTD is bad." Than formulate the requirements for anything missing or misbehaving in MTD so that could be written or fixed and you will be able to finally show that yaffs2 in all its shine and glory. Define all the data structures and check they match those from MTD. I'm pretty sure they don't and this is the principal cause of all that sorry state. One more time - MTD is simple as a shovel. It's not a filesystem, network stack or something like that. It is just a mere physical device driver. If it does not work as it supposed to please point to its bugs. THE bugs, not bugginess. > Unfortunately these yaffs/mtd problems go all the way through to the > yaffs > tools too. That is why the mkyaffs and mkyaffsimage have problems with > some > mtds. What is "some mtds?" Are there many of them? I do only know one, that in the Linux kernel. If you mean some particular snapshot happened to work with YAFFS, NAME it. Then, mkyaffsimage can NOT have ANY problems with ANY mtd because it doesn't use MTD at all, it simply generates some image of a predetermined format no matter MTD or not. It doesn't even know of MTD existance. Then, when using a bare YAFFS, without NAND ECC and tools--just erase the flash, mount it and copy files to the mounted filesystem--you mean MTD somehow changes data it receives from yaffs when writing files and send back to yaffs when reading them? No, that's NOT a case, I clearly see that it gets back exactly what it wrote. And MTD tools (e.g. nanddump) confirm that NAND itself has exactly the same data YAFFS instructed MTD to write at exactly the same locations it asked MTD to put it at. > I would like to suggest that either: > * accept the above and try to be constructive and work the problem from > both > yaffs and mtd sides, and actually listen to the advice you are getting. > *withdraw yourself from the list and find some other creative outlet > for your > energy. I AM trying to be constructive. And NO, I am NOT getting any advice. "Fix your MTD" is NOT an advice of any kind. It's not MY MTD, it's what every single Linux user have. There is NO way to work the problem from either yaffs or MTD side because you do NOT tell what the problem is. One more time: please, list all the functions from MTD you want to use with all the data structures passed and returned defined and the expected result and those "mtds" will be fixed in no time if there is anything to fix there. It is the noble decision to make something for a community. And nobody forces anybody to do so, it's a matter of personal choice. But if one already made such a decision he also took some moral responsibilities. Remember, we are responsible for all we tamed... OK, if you don't need any help and prefer to "fix mtds" forever and to keep your creation in diapers for years, go for it. I'd rather withdraw from the list. I just tried to kick somebody's ass to make them do something. Looks like it doesn't make any sence, nobody here wants to solve problems. --- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************