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.

PROCESSOR-SDK-AM64X: Custom board fails to boot u-boot

Part Number: PROCESSOR-SDK-AM64X

Hi, I am trying to bring up processor SDK 8.0 Linux on my custom board based on AM64 GPEVM.

Based on my logs, I think that the SPL is getting loaded and U-boot starts to load but ends up hanging with the following logs (obtained via enabling debug msgs):

clk_set_defaults(flash@0)
clk_set_default_parents: could not read assigned-clock-parents for 802399b0
ofnode_read_prop: assigned-clock-rates: <not found>
cadence_qspi_apb_config_baudrate_div: ref_clk 166666666Hz sclk 25000000Hz Div 0x3, actual 20833333Hz
cadence_spi_set_speed: speed=25000000
cadence_qspi_apb_chipselect : chipselect 0 decode 0
cadence_qspi_apb_chipselect : chipselect 0 decode 0
size=x, ptr=40, limit=640: aligned to 81f00600
cadence_qspi_apb_chipselect : chipselect 0 decode 0
cadence_qspi_apb_chipselect : chipselect 0 decode 0
jedec_spi_nor flash@0: Unknown command extension type
cadence_qspi_apb_chipselect : chipselect 0 decode 0
cadence_qspi_apb_chipselect : chipselect 0 decode 0
cadence_qspi_apb_chipselect : chipselect 0 decode 0
cadence_qspi_apb_chipselect : chipselect 0 decode 0
cadence_qspi_apb_chipselect : chipselect 0 decode 0
cadence_qspi_apb_chipselect : chipselect 0 decode 0
cadence_qspi_apb_chipselect : chipselect 0 decode 0
spi_get_bus_and_cs: bus=80239828, slave=81f00598
fdtdec_get_config_int: u-boot,spl-payload-offset
jedec_spi_nor flash@0: from 0x00280000, len d
cadence_qspi_apb_chipselect : chipselect 0 decode 0
Found FIT
jedec_spi_nor flash@0: from 0x00280000, len d
cadence_qspi_apb_chipselect : chipselect 0 decode 0
fit read sector 280000, sectors=1300, dst=807ffac0, count=1300, size=0x514
Selecting config 'k3-am642-evm'
firmware: 'firmware-1'
jedec_spi_nor flash@0: from 0x00280514, len d
cadence_qspi_apb_chipselect : chipselect 0 decode 0

I am trying to boot from QSPI and have removed the last 4 pins and have also set the tx, rx bus width to 4 in ospi dts file (k3-am642-evm.dts). Since the QSPI is based on Winbond, I have added the following entry in drivers/mtd/spi/spi-nor-ids.c { INFO("w25q01jv", 0xef4021, 0, 64 * 1024, 2048, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, and added CONFIG_SPI_FLASH_WINBOND=y in both A53 and R5 defconfigs.

How do I proceed to debug and solve this ?

Any help is appreciated Slight smile

  • Hi Abin,
    Can we upload the full boot log in attachment?
    I'll take a closer look after I'm back in office next Thursday (Sept-16).
    Best,
    -Hong

  • Hi , attached the log. Could you have a look at it as soon as you can ? We are a bit tight on schedule.

    26880.log.txt

    We are using the WinbondW25Q01JVSFIQ QSPI chip. Ref: https://www.winbond.com/resource-files/W25Q01JV%20SPI%20RevC%2005032021%20Plus%20dummy.pdf

    Flashed the tiboot3 at 0x0, tispl at 0x80000 and u-boot at 0x280000 using Dediprog software

  • Hi Abin,

    Sorry for delayed response. I'm catching up emails after one week time-off. Have you made progress on QSPI booting on your customer board?

    I’m adding some general notes below:
    (a). There’s always a specific DTB file associated with the each boot binary as listed below:
    1. tiboot3.bin: R5 SPL with the DTB build under “/r5_build_folder/spl/dts/”
    2. tispl.bin: A53 SPL with the DTB build under “/a53_build_folder/spl/dts/”
    3. u-boot.img: A53 u-boot with the DTB build under “/a53_build_folder/arch/arm/dts/”

    (b). One option to parse/decode the generated binary DTB file is listed below using “k3-am642-r5-evm.dtb” as an example.
    “dtc -I dtb k3-am642-r5-evm.dtb > k3-am642-r5-evm.dtb_decode”.
    I’d recommend to decode the three DTB files associated with the three boot binary noted in the last step to check the modified QSPI device node matching the QSPI flash device used on your customer board.

    (c). In TI Linux SDK package, in order to support TI boards, multiple DTB files are bundled together with the boot binary as a FIT image.
    During boot, the boot binary detects the board_ID via reading pre-programmed EEPROM, and then loads the matching DTB file from the FIT image.
    For example, “k3-am642-r5-evm.dtb” and “k3-am642-r5-sk.dtb” are packed into tiboot3.bin file, and “k3-am642-r5-evm.dtb” is loaded on AM64x GP EVM during boot.

    Best,
    -Hong

  • Thanks Hong, I will check the mentioned files.

    Since the log shows that it is booting u-boot, I was thinking that its something other than QSPI. The logs point to the QSPI only ?

  • Hi Abin,
    The log shows that R5 SPL, A53 SPL booted, and A53 SPL was loading u-boot.img (FIT image), and somehow stuck.
    Let's check all DTB files associated with each booting binary are correctly ported matching your board.
    Best,
    -Hong

  • Hi the dtb files match that of the custom board

  • Hi Abin,
    In my earlier reply:
    "(c). In TI Linux SDK package, in order to support TI boards, multiple DTB files are bundled together with the boot binary as a FIT image.
    During boot, the boot binary detects the board_ID via reading pre-programmed EEPROM, and then loads the matching DTB file from the FIT image.
    For example, “k3-am642-r5-evm.dtb” and “k3-am642-r5-sk.dtb” are packed into tiboot3.bin file, and “k3-am642-r5-evm.dtb” is loaded on AM64x GP EVM during boot."
    I recall that there's no EEPROM used for storing the board_ID on your board. Do we know how the board_ID is determined?, and how the board DTB file is loaded to DDR out of u-boot.img FIT image?
    Best,
    -Hong

  • Hi I am not sure how its loaded without the board_ID in EEPROM. Could it be because I am building for the evm ?

    Also we could see that the SDK 7.3 u-boot boots with the changes but SDK 8.0 u-boot fails with the logs attached as per the question. Since the customer requirement is the latest u-boot we will need to figure out this issue and solve it.

  • Hi were you able to look further on this issue ?

  • Hi Abin,
    From the log file, the issue appeared when A53 SPL was loading u-boot.img (FIT image).
    I'd recommend to focusing debugging effort around u-boot.img loading, where u-boot.img is a FIT image, and DTB loading depends on the detected board_ID.
    Best,
    -Hong