[Qi] bad magic when booting from NAND

Dmitry Kurochkin dmitry.kurochkin at gmail.com
Sun Apr 5 16:56:11 CEST 2009


2009/4/5 Paul Fertser <fercerpav at gmail.com>:
> Dmitry Kurochkin <dmitry.kurochkin at gmail.com> writes:
>> On Fri, Apr 3, 2009 at 8:44 PM, Werner Almesberger <werner at 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.

Thanks for the explanation!

Regards,
  Dmitry

>
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav at gmail.com
>



More information about the openmoko-kernel mailing list