Dmitry Kurochkin <dmitry.kuroch...@gmail.com> writes: > On Fri, Apr 3, 2009 at 8:44 PM, Werner Almesberger <wer...@openmoko.org> > 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. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
