2009/4/5 Paul Fertser <[email protected]>: > Dmitry Kurochkin <[email protected]> writes: >> On Fri, Apr 3, 2009 at 8:44 PM, Werner Almesberger <[email protected]> >> wrote: >>> Dmitry Kurochkin wrote: >>>> 2: kernel 0x00820000 >>> >>> Uh uh, a bad block. Maybe that's causing the trouble. You could >>> find out what's happening by first determining where the bad block >>> is located, e.g., with >>> http://svn.openmoko.org/developers/werner/badnand/ >>> >>> and then checking if Qi finds it, e.g., by inserting a printf into >>> the bad block handling code in >>> src/cpu/s3c2442/nand_read.c:nand_read_ll >> >> I ran badnand /dev/mtd6 and got this: >> >> Factory 2, worn 0, good 2046 >> >> Now I will look at Qi as you suggest. >> >> BTW How did you find out that there were badblocks? > > U-boot command dynpart searches for bad blocks and creates nand > partition table accordingly. > > Werner saw a unusual address for kernel partition; that means that the > previous partition was enlarged to compensate for a bad block. > > Unfortunately, that badblock business is tricky as this information is > kept in 2 different places (OOB data and BBT at the end of NAND) and > is not always in sync. There was a discussion on the kernel list about > various ways of storing, searching and using bad blocks information > and the differences between NOR, NAND u-boots, Qi and the kernel.
Thanks for the explanation! Regards, Dmitry > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:[email protected] >
