• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 708 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

mtd_utils for DM355

SAKHO
Intellectual 390 points

Hello,

I am trying to simply update my kernel image (not from u-boot, which works fine) using MTD_UTILS, and we work with a DM355 using arago-project sofware.

So when I use the command :   $ mtd_debug info /dev/mtd2
                                                            mtd.type = MTD_NANDFLASH
                                                            mtd.flags = MTD_CAP_NANDFLASH
                                                            mtd.size = 8388608 (8M)
                                                            mtd.erasesize = 131072 (128K)
                                                            mtd.writesize = 2048 (2K)
                                                            mtd.oobsize = 64
                                                            regions = 0
what seems to match the characteristics of my partition and my Nand flash (MT29F4G08AAC).

Then the command:  $ flash_eraseall /dev/mtd2

                                       Skipping bad block at 0x00000000
                                        Skipping bad block at 0x00020000
                                        Skipping bad block at 0x00040000

                                                               .

                                                               .

                                                               .

                                         Skipping bad block at 0x005e0000
                                         Erasing 128 Kibyte @ 800000 -- 100 % complete.

The problem is that the entire first half of the partition is regarded as "bad blocks". This finding is the same whatever the partition that I use with this command. And personally I find this result absurd. What do you think? what could be a problem, if there 'is one? Is it related to the version of mtd-utils (mtd-utils-230b13b) we use? Why so many "bad blocks" while at the base there was none?

The writing phase with the command: $ nandwrite -n -p /dev/mtd2 uImage

                                                                       Bad block at 0, 1 block(s) from 0 will be skipped
                                                                       Writing data to block 1 at offset 0x20000
                                                                       Bad block at 20000, 1 block(s) from 20000 will be skipped
                                                                       Writing data to block 2 at offset 0x40000
                                                                                                     .

                                                                                                     .

                                                                                                     .

                                                                         Bad block at 5e0000, 1 block(s) from 5e0000 will be skipped
                                                                         Writing data to block 48 at offset 0x600000
                                                                         Writing data to block 49 at offset 0x620000
                                                                         Writing data to block 50 at offset 0x640000
                                                                         Writing data to block 51 at offset 0x660000
                                                                         Writing data to block 52 at offset 0x680000
                                                                         Writing data to block 53 at offset 0x6a0000
                                                                         Writing data to block 54 at offset 0x6c0000
                                                                         Writing data to block 55 at offset 0x6e0000
                                                                         Writing data to block 56 at offset 0x700000
                                                                         Writing data to block 57 at offset 0x720000
                                                                         Writing data to block 58 at offset 0x740000
                                                                         Writing data to block 59 at offset 0x760000
                                                                         Writing data to block 60 at offset 0x780000
                                                                         Writing data to block 61 at offset 0x7a0000
                                                                         Writing data to block 62 at offset 0x7c0000

thus, we have arranged to change the settings "bootcmd" of u-boot to match the address where the uImage was row. but at boot, u-boot still manages to find the uImage with an error " Bad Data CRC"

Loading from NAND 512MiB 3,3V 8-bit, offset 0xa00000
   Image Name:   Linux-2.6.32-rc2-davinci1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1903276 Bytes =  1.8 MB
   Load Address: 80008000
   Entry Point:  80008000
## Booting image at 80700000 ...
   Image Name:   Linux-2.6.32-rc2-davinci1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1903276 Bytes =  1.8 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... Bad Data CRC

you have an idea what's wrong? what do you recommend for a good update of the kernel??

thank you in advance for your help.

SAKHO


  • 0
    TI__Genius 9510 points

    Have you tried using the u-boot nand erase utilities?

  • 0 in reply to Marcus Cooksey
    Intellectual 390 points

    thank you for your reply,

    in fact, we want to update the kernel from a linux prompt on DM355. Thus, we could use thee u-boot nand erase utilities? And how? Would there be another method that mtd_utils to get to this update from a linux prompt?

    thank you again,

     

    SAKHO

  • 0 in reply to SAKHO
    TI__Genius 9510 points

    You can still still update the kernel from a linux prompt, but try this after you've erase the blocks from uboot.

    for example

    nand erase <nand offset address> <number of bytes to erase>

    Just to confirm the erase was successful, perform a

    nand dump <nand offset addres>

    You should read by all 0xFF

     

  • 0 in reply to Marcus Cooksey
    Intellectual 390 points

    Then I did the procedure you recommended me, but the result is always the same. After the nand erase operation from u-boot, we made the nand dump operation and we read well 0xFF. But the update from a linux prompt does not work. what could be the problem?

    Best regard and thank you again

    SAKHO



  • 0 in reply to SAKHO
    TI__Genius 9510 points

    Are you certain that you bootcmd offset of where the kernel resides match the offset that you're writing to from linux.

    Just as a test could you flash the kernel from u-boot (either load the image over serial port or using tftp)

    From serial port

    1) loady 0x85000000 (then select uImage to load to memory)

    2) nand erase <nand offset address> <length of uImage> 

    3) nand write 0x85000000 <nand offset address> <length of uImage>

    4) from uboot

  • 0 in reply to Marcus Cooksey
    Intellectual 390 points

    When we flash the kernel from u-boot using tftp or serial port, everything goes well. But when we use "mtd_tools" from linux prompt, the first half of the partition (/ dev/mtd2) is seen as bad blocks (as described in my previous post). What could explain this?  Partitions from kernel:

    NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit)
    Creating 5 MTD partitions on "davinci_nand.0":
    0x000000000000-0x000000780000 : "bootloader"
    0x000000780000-0x000000800000 : "params"
    0x000000800000-0x000000c00000 : "kernel"
    0x000000c00000-0x000008c00000 : "filesystem1"
    0x000008c00000-0x000020000000 : "    filesystem2"

    Thus, we tried to match the bootcmd offset and the offset that we are writting from linux prompt. And so, starting from the actual offset  of the partition and the fact that the first half is skipped (bab blocks from mtd_utils), the bootcmd and the offset address becomes 0xA00000. But, even with all these little calculations, the problem persists. We do not know what to do. Have you any ideas?

    thank you for your help

    SAKHO