Oops, I almost forgot to mention I posted the modified sources in the same
directory of our FTP site. Please keep in mind files in the tmp directory are
temporary files and are not official releases, these files may be cleaned up in
the future to reclaim space on our server.
Eddie Dawydiuk wrote:
> Hello,
>
>> I would respectfully point out however that posting a diff here is not
>> GPL compliance. You should make the full source available. Exactly the
>> source that builds the binary.
>>
>> I'm sure it's an over sight and since you have asked to be notified of
>> any cases on non compliance ,,, it would be nice not to have to call
>> transatlantic or email and wait the weekend for a reply. Having a
>> source tarball on the server next to the binary would save you and
>> "us" time and effort. As well as fulfilling your license obligations.
>>
>> This is exactly what GPL is about. You profit from the work of others
>> and if you make a mod, you contribute that back in.
>
> As you know the flash_eraseall.c util comes from MTD. We use it in house
> with out modifications. Although, in the past I recall a bug in Yaffs
> that caused blocks to be marked bad that weren't actually bad. As a
> result we compiled a kernel and corresponding user space utility to
> ignore all blocks as marked bad and erase them I posted a binary on our
> website for customers so they didn't have to ship there boards back to
> us to be repaired. This was really just a temporary work around to "fix"
> the nand flash on boards that had become bricked as a result. Please
> note this utility should only be used by knowledgeable developers who
> are working on Nand flash drivers or working on porting a new filesystem
> to Nand flash. This utility should not be used to periodically repair
> bad blocks, if you are getting large amounts of bad blocks(>1-2%) then
> there is more than likely a bug somewhere or your writing huge amounts
> of data to Nand flash at a very fast rate(IIRC a 2KB block is guaranteed
> good for 10K writes). If you are truly getting bad blocks because they
> have been worn out, then you should not attempt to recover these blocks
> as they are truly bad and will lose data in the future.
>
>> Thanks again for your help. I hope this can undo the damage done by
>> yaffs2. There are reports on the aleph1 site about some chips becoming
>> unusable after this sort of erase.
>
> I should start by saying I am by no means a Nand flash expert. Although,
> I can tell you the original thinking when we released this modification
> was to allow people to get there boards into a bootable state. We knew
> that there was a very high probability that truly bad blocks existed on
> almost every board and these blocks would have to be rediscovered, as
> this utility mod marks every block as good. The result of rediscovering
> these bad blocks would be data loss, that is the bad sectors would be
> used to write data and later we would find the data we read back did not
> match the ECC we wrote. As a result the 2KB block would be marked as bad
> and the data stored on that block would be lost. As I said I am not an
> expert on Nand flash, although I don't see how an entire chip could
> become unusable as the result of marking all blocks as good...
>
> I'm assuming you are running an experimental kernel, although if you are
> using one of our default kernels and are seeing large amounts of blocks
> marked bad please let me know as this is a sign of a bug.
>
> > Do you do anything else before mkfs on boards that you get back with
> this sort of problem?
>
> As I mentioned earlier we use the default flash_eraseall.c util in
> production. On an occasion in the past we did run into a Yaffs2 bug that
> caused large amounts of blocks to be marked bad. Typically we simply run
> flash_eraseall on the char device, mount the block device, and untar the
> Linux filesystem.
>
--
Best Regards,
________________________________________________________________
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web: www.embeddedARM.com
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|