• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 101 subscribers
  • Views 623 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM3517: Failure using "nandwrite" in the target system to write to Nand block 0

Kirby Cartwright
Prodigy 40 points
Part Number: AM3517
Other Parts Discussed in Thread: AM3505

Dear Sir or Madam,

We are using a CM-T3517  computer-on-module ("COM") from Compulab. It contains the subject microcontroller and a Hynix H27U1G8F2BTR-BC NAND chip. Our target system software ( Yocto embedded Linux) needs to be able to update x-loader ("x-load.bin.ift" also known as "MLO") in nand block 0. After erasing block 0 and programming it with a new version of the x-loader (in the target system) the system does not boot. I know that block 0 should be treated differently as far as error correction. I have used "nanddump" to read out the x-loader from block 0 and the files show no difference. Here are example commands that I use:

flash_eraseall /dev/mtd0 or

flash_erase /dev/mtd0 0 0

nandwrite -p --noecc /dev/mtd0 x-load.bin.ift

nanddump --noecc -l 34614 -f x-load.bin.ift.dump /dev/mtd0

diff x-load.bin.ift x-load.bin.ift.dump

I'm guessing that the 1-bit ECC scheme is not being done correctly by either "nandwrite" or the kernel driver for the Nand. I know that block 0 is special because its error-correcting has to match what the ROM loader expects.

Thanks for your help,

Kirby Cartwright

(Contract) Software Engineer - Sustaining

  • 0
    TI__Guru* 89995 points

    Hello Kirby,

    What version of target system software are you using?

    Have you confirmed that the issue is with the flashing process, and not the new x-loader? (i.e., does it start working again when you program the original x-loader back into nand block 0?)

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 40 points

    Nick,

    The following are useful extracts from the boot messages that will answer your question:

    U-Boot SPL 2020.01-rc3-ts-g4fa6070cdd (Aug 05 2020 - 19:49:53 +0000)
    Trying to boot from NAND

    U-Boot 2020.01-rc3-ts-g4fa6070cdd (Aug 05 2020 - 19:49:53 +0000)

    AM35XX-GP ES2.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
    Model: TI AM3517 EVM (AM3517/05 TMDSEVM3517)
    AM3517EVM Board + LPDDR/NAND

    NAND read: device 0 offset 0x2a0000, size 0x40000
    262144 bytes read: OK
    Running boot script ...
    ## Executing script at 80000000
    Script loaded successfully...

    NAND read: device 0 offset 0x2a0000, size 0x40000
    262144 bytes read: OK
    Running boot script ...
    ## Executing script at 80000000
    Script loaded successfully...
    Booting system from K1R1D1...

    NAND read: device 0 offset 0x2e0000, size 0x300000
    3145728 bytes read: OK

    NAND read: device 0 offset 0x6e0000, size 0xa00000
    10485760 bytes read: OK

    Booting system from K1R1D1...

    NAND read: device 0 offset 0x78e0000, size 0x10000
    65536 bytes read: OK
    ## Booting kernel from Legacy Image at 81000000 ...
    Image Name: Linux-4.14.148-yocto-tiny-ts-cmm
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 2807968 Bytes = 2.7 MiB
    Load Address: 80008000
    Entry Point: 80008000
    Verifying Checksum ... OK
    ## Loading init Ramdisk from Legacy Image at 82000000 ...
    Image Name: cmm-image-test-cmm-2020102018562
    Image Type: ARM Linux RAMDisk Image (uncompressed)
    Data Size: 8304609 Bytes = 7.9 MiB
    Load Address: 00000000
    Entry Point: 00000000
    Verifying Checksum ... OK
    ## Flattened Device Tree blob at 80c00000
    Booting using the fdt blob at 0x80c00000
    Loading Kernel Image
    Loading Ramdisk to 8577a000, end 85f657e1 ... OK
    Loading Device Tree to 85768000, end 85779cf0 ... OK

    Starting kernel ...

    Uncompressing Linux... done, booting the kernel.
    [ 0.000000] Booting Linux on physical CPU 0x0
    [ 0.000000] Linux version 4.14.148-yocto-tiny-ts-cmm (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 Wed Oct 14 16:33:42 UTC 2020
    [ 0.000000] CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c5387d
    [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
    [ 0.000000] OF: fdt: Machine model: Physio Control CMM
    [ 0.000000] Memory policy: Data cache writeback
    [ 0.000000] CPU: All CPU(s) started in SVC mode.
    [ 0.000000] AM3505 ES1.1 (l2cache neon)

    The operating system is Linux 4.14.148 based on TI's Linux for the AM3517EVM Board. It uses a more modern kernel and a device-tree-binary file to define I/O.

    Thanks,

    Kirby Cartwright

  • 0 in reply to Kirby Cartwright
    TI__Guru* 89995 points

    Hello Kirby,

    Please note that the AM35x software is considered "mature" - we have not updated the AM35x Linux EZSDK since 2013. I cannot support questions on getting more recent software working on the AM35x.

    Have you confirmed that the issue is with the flashing process, and not the new x-loader? (i.e., does it start working again when you program the original x-loader back into nand block 0?)

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 40 points

    Nick,

    I'll ignore the fact that the microcontroller is obsolete and hope you will still help.

    I have found that version of U-Boot I am using can flash mtd block 0 successfully. Here are the commands I use based on the TI application note (URL below):

    nandecc hw hamming

    nand read 0x80000000 0x00000000 0x8736

    nand erase 0x0 0x50000

    nand write 0x80000000 0x0 0x8736

    0x8736 is the size of the "x-load.bin.ift" file, and 0x00000000 is the location in the NAND flash.

    Do you know if the obsolete LInux kernel in 2013 modified by TI could write to mtd0?

    Kirby W. Cartwright

  • 0 in reply to Kirby Cartwright
    TI__Guru* 89995 points

    Hello Kirby,

    To make sure I understand you properly: You were initially trying to flash NAND from the AM35x Linux command line, but you were having problems. However, you were able to flash NAND from AM35x uboot based on instructions at the wiki link above? Is flashing from uboot an acceptable alternative for your usecase?

    On a separate note, please save any wiki pages you find on AM35x that you will want to reference going forward. The wikis will go offline at the end of the year, and AM35x pages are not currently slated for migration to other sites.

    I am doing a bit of digging. The BeagleBoardNAND page indicates that Linux sees NAND xloader and uboot as read-only, and most of the TI flashing instructions for later parts like AM335x only provide instructions for doing it from uboot.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 40 points

    Nick,

    Thanks for the reply. All of our mtd blocks are set to read/write. And, yes the problem is at the command line. Your suggestion won't work for us as U-boot is not available to the user.

    I'm going to try the older version of the kernel (2.26.32), flashwrite and etc and see if they work at the command line.

    Regards,

    Kirby Cartwright

  • 0 in reply to Kirby Cartwright
    TI__Guru* 89995 points

    Hello Kirby,

    Let me know what you find in your tests. I am still looking to see if flashing xloader and uboot from Linux is supported.

    Regards,

    Nick