This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem by putting u-boot in NAND memory on a DM6446

I'm trying  to put u-boot on  a custom board  based on dm6446 in a NAND memory.

I find  some mismatches between  the montavista linux kernel  and u-boot 2009.11 .

Particularly,  in  linux-2.6.18_pro500/arch/arm/mach-davinci/board-evm.c the variable davinci_nand_partitions has 4 elements bootloader of 265KB, params 128K, kernel 4M and filesystem the rest of the memory.

But  u-boot  2009.11 has  a  different  partitions layout  specified  by mtdparts=davinci_nand.0:384k(bootloader)ro,4m(kernel),-(filesystem)

In any case I would assume that  after 0x60000 (i.e. 384k) no data would be present,  and by erasing it  nothing would happen. But  By erasing it u-boot stops working.

The commands I give are:

nand erase 0x00060000 0x00400000
nand write 0x80700000 0x00060000 0x00400000
reset

and u-boot does not work any more and I have to reinstall it with sfh.

If I try  to write to 0x02060000  instead of 0x00060000 it  works, but I think it  is wrong  because when I  to flash_eraseall  -j /dev/mtdblock3 from  linux I  delete the  kernel  from the  NAND and also because the correct address seems to be 0x00060000 in this post http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg06694.html

So, I  think that the position of u-boot at  the beginning of  the NAND memory does not start  at 0x0 and does not finish  at 0x0005ffff . Thus, my questions are:

1) what is the correct place for u-boot in the NAND memory?
2) is it due to sfh?
3) how should I change mtdparts? how?

Did you experience something similar?

  • Ottavio,

    Don't go by what is in the montavista linux kernel or by what u-boot 2009.11 says the partitions are.  The location of u-boot is determined by where sfh puts it, which is typically block 6 of the NAND device.  I don't know the size of your nand's eraseblock so I can't give you an exact answer as to where it should be.  The best thing to do is to look at the sfh output and see what blocks it is erasing and writing to.  Then in u-boot, you can use the nand dump command to view the memory at the first page of those blocks.  You should see the header with magic number in that first page and the actual image starting in the second page.

    Once you have verified where your bootargs, UBL, and u-boot are being put by sfh, you should modify the u-boot and linux kernel mtd definitions to match.  If you want something different, you should modify the sfh code and rebuild it.

    But there are several more issues here besides where u-boot is put.  First, if you want to put a new u-boot into nand, you will have to make a header that UBL can read and put it in the first page of the block where you put your u-boot.  And most importantly, you will have to write that u-boot image with an ECC layout that matches what UBL expects to see.  This isn't easy, but it can be done.  Why do you want to program in a new u-boot using the old u-boot?  Can't you just let sfh program in your new u-boot (2009.11)?

    If this isn't helpful enough, please let us know what your nand eraseblock size is.  Also, what version of sfh are you using?

     

    Luke

  • my problem was not being able to update u-boot. IT was just putting u-boot, the kernel and the rootfs in the NAND memory correctly.

    I ended with the solution of giving the first MB of the nand to uboot. I don't exactly know where it starts and where it stops, but fortunately the NAND memory is bigger than what I need so even if I waste a bunch of KB there's no problem.

  • Ottavio,

    Another way to see where u-boot is is to look at the serial output at bootup.  Here's mine:

    Booting TI User Boot Loader
            UBL Version: 1.65
            UBL Flashtype: NAND
    Starting NAND Copy...
    Valid magicnum, 0x55424CBB, found in block 0x00000006.
       DONE
    Jumping to entry point at 0x81080000.

     

    My eraseblock size is 128k so block 6 is at 000C0000.  If I nand dump there, I can see the magic number and other parts of the header:

    nand dump c0000
    Page 000c0000 dump:
            bb 4c 42 55 00 00 08 81  55 00 00 00 06 00 00 00
            01 00 00 00 00 00 08 81  ff ff ff ff ff ff ff ff
            ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
            ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff

    .....

     

    Luke