• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 730 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.

TMDS64EVM: AM64 NOR SPI U-Boot write issues

Pierre Buffo
Prodigy 120 points
Part Number: TMDS64EVM


Hi,

I'm having an issue writing in the s28hs512t xSPI nor on the am64 evm from U-Boot. To be more specific I can't write/erase/update the integrated nor using sf commands. sf probe and read works normally though. Of course it also means that I can't save my env in the NOR, which is ultimately what I'm trying to achieve.

=> sf probe
SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
=> sf erase 0 100
SF: 256 bytes @ 0x0 Erased: ERROR
=> sf update $loadaddr 0 100
device 0 offset 0x0, size 0x100
0 bytes written, 256 bytes skipped in 0.2s, speed 52428 B/s
=> sf write $loadaddr 0 100 
device 0 offset 0x0, size 0x100
jedec_spi_nor flash@0: flash operation timed out
SF: 256 bytes @ 0x0 Written: ERROR -110
=> sf read $loadaddr 0 100 
device 0 offset 0x0, size 0x100
SF: 256 bytes @ 0x0 Read: OK
=> md.w $loadaddr 100
82000000: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
82000010: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
82000020: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
82000030: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
82000040: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
82000050: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
82000060: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
82000070: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
82000080: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
82000090: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
820000a0: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
820000b0: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
820000c0: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
820000d0: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
820000e0: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
820000f0: 2563 2563 2563 2563 2563 2563 2563 2563    c%c%c%c%c%c%c%c%
82000100: 5355 0b31 0930 0306 0455 0c08 5402 3158    US1.0...U....TX1
82000110: 300f 060d 5503 0704 060c 6144 6c6c 7361    .0...U....Dallas
82000120: 2731 2530 0306 0455 0c0a 541e 7865 7361    1'0%..U....Texas
82000130: 4920 736e 7274 6d75 6e65 7374 4920 636e     Instruments Inc
82000140: 726f 6f70 6172 6574 3164 3013 0611 5503    orporated1.0...U
82000150: 0b04 0a0c 7250 636f 7365 6f73 7372 1331    ....Processors1.
82000160: 1130 0306 0455 0c03 540a 2049 7553 7070    0...U....TI Supp
82000170: 726f 3174 301d 061b 2a09 4886 f786 010d    ort1.0...*.H....
82000180: 0109 0e16 7573 7070 726f 4074 6974 632e    ....support@ti.c
82000190: 6d6f 8230 2202 0d30 0906 862a 8648 0df7    om0.."0...*.H...
820001a0: 0101 0501 0300 0282 000f 8230 0a02 8202    ..........0.....
820001b0: 0102 bf00 ae14 d849 727f 6bd3 cd23 48eb    ......I..r.k#..H
820001c0: 650e 22dc f24d 4f0e f682 b5ed ddf2 7cdb    .e."M..O.......|
820001d0: fa91 596e d5ff b6f7 04de 8a1d d2cc d995    ..nY............
820001e0: e0d1 c1c4 50f8 ffbf 0c48 2291 9a50 7b4c    .....P..H.."P.L{
820001f0: f38b 0a96 2628 a4b3 e0d9 55a9 1a41 3efb    ....(&.....UA..>

Interestingly my device boots from xSPI, meaning the NOR itself is ok. To flash boot binaries I'm using flashcp from my custom yocto based OS and things work very well. That distribution is based on the Kirkstone branch of the meta-ti and meta-arago layers.

I customized a U-Boot defconfig, based on the am64x_evm_a53_defconfig by adding:

CONFIG_CMD_PART=y
CONFIG_CMD_MBR=y

CONFIG_BOOTCOUNT_LIMIT=y
CONFIG_BOOTCOUNT_ENV=y
CONFIG_SYS_BOOTCOUNT_MAGIC=0xB001C041
CONFIG_BOOTCOUNT_BOOTLIMIT=4

CONFIG_CMD_BOOTMENU=y
CONFIG_AUTOBOOT_KEYED=y
CONFIG_AUTOBOOT_STOP_STR="abc"

CONFIG_DEFAULT_SPI_BUS=0
CONFIG_DEFAULT_SPI_MODE=0
CONFIG_SPI_BOOT=y
# CONFIG_ENV_IS_IN_MMC is not set
# CONFIG_SPL_ENV_IS_IN_MMC is not set
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_VERSION_VARIABLE=y
CONFIG_ENV_OFFSET=0x700000
CONFIG_ENV_SECT_SIZE=0x20000
CONFIG_ENV_OFFSET_REDUND=0x740000
CONFIG_ENV_ADDR=0x0
CONFIG_ENV_SECT_SIZE_AUTO=y
CONFIG_ENV_SPI_BUS=0
CONFIG_ENV_SPI_CS=0
CONFIG_ENV_SPI_MAX_HZ=100000
CONFIG_ENV_SPI_MODE=0x0
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y

CONFIG_CMD_MTDPARTS=y
CONFIG_CMD_MTDPARTS_SPREAD=y
CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y
CONFIG_CMD_CLONE=y
CONFIG_CMD_MTD=y
CONFIG_CMD_SF_TEST=y
CONFIG_CMD_SPI=y

I doubt that anything in there is likely to cause my issue. especially knowing that I observe similar issues using the binaries from the SDK 08.02.00.23.

Any suggestion or idea is welcome.

Regards
Pierre

  • 0
    TI__Guru 72070 points

    Hello Pierre,
    I'm attaching the working log for flashing OSPI with SDK 8.2 on AM64x EVM for your reference.
    software-dl.ti.com/.../UG-QSPI.html
    Best,
    -Hong

    Fullscreen am6_8.2_hs_ospi_flash.txt Download 
    U-Boot SPL 2021.01-00001-g09763be-dirty (Apr 06 2022 - 18:15:13 -0500)
SYSFW ABI: 3.1 (firmware rev 0x0016 '22.1.1--v2022.01 (Terrific Llam')
SPL initial stack usage: 13392 bytes
Trying to boot from MMC2
Authentication passed
Authentication passed
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.5(release):08.01.00.006-dirty
NOTICE:  BL31: Built : 10:52:55, Apr  5 2022

U-Boot SPL 2021.01-00001-g09763be-dirty (Apr 06 2022 - 18:13:52 -0500)
SYSFW ABI: 3.1 (firmware rev 0x0016 '22.1.1--v2022.01 (Terrific Llam')
Trying to boot from MMC2
Authentication passed
Authentication passed


U-Boot 2021.01-00001-g09763be-dirty (Apr 06 2022 - 18:13:52 -0500)

SoC:   AM64X SR1.0
Model: Texas Instruments AM642 EVM
Board: AM64-GPEVM rev E2
DRAM:  2 GiB
NAND:  0 MiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1
Hit any key to stop autoboot:  2  0 
=> mmc rescan
=> ls mmc 1
   572771   tiboot3.bin
   858295   tispl.bin
     1490   uEnv.txt
   131072   uboot.env
        1   .psdk_setup
  1123667   u-boot_8.2_hs.img
   858331   tispl_8.2_hs.bin
   572755   tiboot3_8.2_hs.bin
  1123631   u-boot.img

9 file(s), 0 dir(s)

=> sf probe
SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
=> fatload mmc 1 ${loadaddr} tiboot3.bin
572771 bytes read in 27 ms (20.2 MiB/s)
=> sf update $loadaddr 0x0 $filesize
device 0 offset 0x0, size 0x8bd63
   Updating, 46% 162491 B/s   Updating, 92% 164987 B/s572771 bytes written, 0 bytes skipped in 4.455s, speed 131535 B/s
=> fatload mmc 1 ${loadaddr} tispl.bin
858295 bytes read in 39 ms (21 MiB/s)
=> sf update $loadaddr 0x100000 $filesize
device 0 offset 0x100000, size 0xd18b7
   Updating, 31% 169788 B/s   Updating, 62% 170165 B/s   Updating, 92% 168157 B/s858295 bytes written, 0 bytes skipped in 6.0s, speed 146409 B/s
=> fatload mmc 1 ${loadaddr} u-boot.img
1123631 bytes read in 51 ms (21 MiB/s)
=> sf update $loadaddr 0x300000 $filesize
device 0 offset 0x300000, size 0x11252f
   Updating, 24% 170760 B/s   Updating, 47% 170597 B/s   Updating, 70% 170291 B/s   Updating, 94% 170300 B/s1123631 bytes written, 0 bytes skipped in 7.532s, speed 152700 B/s
=> md.l 0x43000030 1
43000030: 00000243                               C...
=>

  • +1
    Prodigy 120 points

    Hello Hong,

    Turns out sf erase does not align the requested erase size to the bloc size, explaining why my sf erase 0 100 was failing.

    Since I wrote my initial message I discovered where my issues came from.

    I use a redundant env, which combined with a NOR creates issues.

    The reason is very simple, the U-Boot methodology to update dual env simply doesn't work with the concept of NOR memories. U-Boot doesn't save twice the updated env, it simply attempts to overwrite the olde one and then mark the second one as obsolete.

    Prior to the new env being written an erase operation takes place. Everything goes well here. But to mark the second one as obsolete it simply attempts to write a few bytes in the middle of the env. Which simply doesn't work because no erase operation takes place prior. In my case the erase size is the same size as my env, so I patched the sources to write the new env on both slots and marking one of them as obsolete (although in reality it isn't, this just avoids messing the state machine).

    Fun fact is that the libubootenv project to manipulate U-Boot env from Linux has the same issue. I also ended up patching it...

    I guess not that many people use dual env, otherwise this would have been noticed earlier...

    Regards

    Pierre