Compiler/TDA2EX17EVM: About dfu flashing firmware

Hi,

Could you tell us which step is not working for you?

Regards,
Vishal

Hi,

I use Usbboot tool,load the first-stage bootloader to evm board,I can  observe the message below on the host machine.

but on target console  i don't see console output similar to mentioned below:

 I used the "dfu-util -l " following command to query the dfu device on the host side, but no useful information was found.

my question:

1、The host side shows that u-boot-spl.bin has been successfully downloaded, why does the debug serial port of the target board have no information about spl running?

2、Is spl not operating normally at this time? How can I debug each problem?

3、Why can't the host side use the dfu-util -l command to query any dfu information? Is it because spl is not running correctly?

Thank you very much!

Hi,

You need to rebuild the u-boot SPL by enabling DFU and then use that. Is the below config enabled in the SPL you are sending via usbboot tool?

make dra7xx_evm_config
make menuconfig # Enable "Boot Images" -> "Enable SPL with DFU"


Regards,
Vishal

Hi,

I am using dra7xx_evm_config configuration, Cannot find "Enable SPL with DFU" in "Boot Images".But I opened the following configuration items in "SPL / TPL ---> "

What I don't understand is，After using the usbboot tool to download u-boot-spl.bin via usb to the internal ram of the chip, shouldn’t u-boot-spl.bin be executed first?

Then execute u-boot-spl.bin, there should be version number information input, but no information can be seen through the debug serial port, why?

The step you mentioned is only after boot-spl.bin runs, is there any dfu tool?

Hi vishal

I also encountered the same problem. I also want to know why there is no information output from the debug serial port after usbboot downloads

u-boot-spl.bin to the internal ram of the chip? Is u-boot-spl.bin not downloaded successfully at all? Or after downloading to ram, it does not run normally?

Why is this happening?

Hi,

In this u-boot version "Support DFU (Device Firmware Upgrade)" option should be enabled.
Was this already enabled?

Could you try following instructions from here?
https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/linux/Foundational_Components_U-Boot.html#usb-device-firmware-upgrade-dfu


Regards,
Vishal

Hi, vishal

Your solution makes me very disappointed. Under the instructions I have confirmed here, I have read the post you mentioned, and also checked my uboot configuration, all the configuration about dfu has been opened, please take the screenshot above.I will list my questions again below:

1、The host side shows that u-boot-spl.bin has been successfully downloaded, why does the debug serial port of the target board have no information about spl running?

2、Is spl not operating normally at this time? How can I debug each problem?

3、Why can't the host side use the dfu-util -l command to query any dfu information? Is it because spl is not running correctly?

I understand the process of rbl loading u-boot-spl.bin as follows: rbl will jump from rbl to u-boot-spl.bin after downloading u-boot-spl.bin to the internal ram of the chip through the usbboot tool ,

When u-boot-spl.bin starts to execute in the chip kernel ram, there will be information output to the debug serial port of the target board, but the debug serial port cannot see any information, why?

I understand that the host side executes the dfu-util -l command query process as follows: when rbl has loaded boot-spl.bin and successfully transferred to boot-spl.bin for execution,

dfu-util -l can be used from the host side Command to query the devices supported by spl's dfu.

The above three questions and the understanding of the execution flow of the two programs, please reply me accurately, thank you

Hi,

-1-
This would mean that the SPL did not run correctly.

-2-
Since you are not seeing anything on console, I would say SPL is not running properly.
Does the same u-boot codebase boot properly on some other boot mode?

-3-
Only if the SPL you sent run's successfully, the dfu-util will show the list of devices.


I just tested the u-boot that went as part of this release on one of the boards I have and I don't see any issue.

PC log:

$ sudo ./usbboot-stand-alone -s ../../../u-boot/spl/u-boot-spl.bin
[sudo] password for vishallocal:
reading ASIC ID
CHIP: 5641
rom minor version: 02
IDEN: 0000000000000000000000000000000000000000
MPKH: 0000000000000000000000000000000000000000000000000000000000000000
CRC0: 51d2f9a7
CRC1: 00000000
device is GP
sending 2ndstage to target...

EVM log:

U-Boot SPL 2019.01-00007-ga0ff74425a (Sep 18 2020 - 11:50:24 -0500)
DRA752-GP ES2.0
Trying to boot from DFU

dfu-util log:

$ sudo dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to sourceforge.net/.../

Found DFU: [0451:d022] ver=0223, devnum=18, cfg=1, intf=0, path="3-1", alt=2, name="ramdisk", serial="UNKNOWN"
Found DFU: [0451:d022] ver=0223, devnum=18, cfg=1, intf=0, path="3-1", alt=1, name="fdt", serial="UNKNOWN"
Found DFU: [0451:d022] ver=0223, devnum=18, cfg=1, intf=0, path="3-1", alt=0, name="kernel", serial="UNKNOWN"

Regards,
Vishal

By default all the configs needed for DFU are enabled in u-boot in SDK version you are using.
In the older versions of u-boot, we had to enable some configs explicitly and that's why I asked you to check those configs.

Hi,

Yes, you are right. Before I ask for your help, I have confirmed the configuration of dfu through make menuconfig and it has been opened.

What I am confused about now is that I use the same MLO compiled by the uboot of vsdk308, I can enter the MLO and load uboot.img normally

with the SD card, and download u-boot/spl/u-boot-spl.bin through the Usbboot tool After going to the ram in the Mainland, the EVM board cannot

see the following information:

EVM log:

U-Boot SPL 2019.01-00007-ga0ff74425a (Sep 18 2020-11:50:24 -0500)

DRA752-GP ES2.0

Trying to boot from DFU

What caused this situation? Where can I find the problem and solve it?

Thanks！

Hi Yanmm,

I don't have a TDA2EX17EVM handy, I am trying to locate one to test the same commands with PROCESSOR_SDK_VISION_03_08_00_00.

Could you try using the attached u-boot-spl.bin and check the behavior?
4237.u-boot-spl.bin


Regards,
Vishal

Hi vishal，

I use your firmware, and there is no prompt message. I have determined the following things.

1、Rbl can read my second stage startup code MLO from the sd card.

2、MLO can also run in the internal ram of the chip.

But the problem is as follows: MLO runs in the internal ram. When it jumps to the board_init_r function to execute, it will not continue to execute down when it runs to dram_init_banksize.

Ask ti experts to help analyze, why jump into the dram_init_banksize function and not continue to execute downwards, as if it is stuck?

Thank you

Hi Yanmm,

I just got hold of a TDA2EX17EVM board and was able to successfully trandfer u-boot-spl.bin and boot (with the binary I shared with you)

U-Boot SPL 2019.01-00007-ga0ff74425a (Sep 18 2020 - 11:50:24 -0500)
DRA722-GP ES2.0
Trying to boot from DFU


I am confused with your last response, 
The u-boot-spl.bin I shared is for using with usbboot tool, not SD card.

Regards,
Vishal

Hi vishal，

It doesn't matter whether you use the usbboot tool to load u-boot-spl.bin or load MLO from SD, it is the same,

but the format of the two boot programs is different, and they are both second-level boot programs. I have located the

program running to dram_init_banksize to initialize the memory failed and started, and the serial port has not been

initialized correctly at this time, so we can not see any output information.

Please share, after MLO is started, does i2c1 read the configuration information of the eeprom on the tda2ex17-evm board?

Hi Yanmm,

If this is the same that is being issue being discussed on the below thread, then let's track the issue on the other thread.
https://e2e.ti.com/support/processors/f/791/p/940207/3487161#3487161

Regards,
Vishal

Hi vishal

It looks the same now, but there is no solution for that thread until now.

On the tda2ex17 evm board, if MLO is downloaded to the internal sram correctly and runs,

reading the configuration in the eeprom via i2c1 fails, will it cause the external ddr initialization to fail?

I now locate that because of this reason, the external ddr initialization failed. Is there any way to skip the

read configuration information of eeprom and start evm normally?

Hi Yanmm,

Board needs to be booting successfully with SD card boot mode first, then we can debug the USB peripheral boot mode.

Follow the board_ti_get_emif_size() API in u-boot where values read from EEPROM are used to determine the ram size and accordingly choose configuration.
https://git.ti.com/gitweb?p=glsdk/psdkla-u-boot.git;a=blob;f=board/ti/dra7xx/evm.c;h=ff438d75bd148c9db1db657009ccd83df753a51c

Also board_ti_get_emif1_size() and board_ti_get_emif2_size() 
https://git.ti.com/gitweb?p=glsdk/psdkla-u-boot.git;a=blob;f=board/ti/common/board_detect.c;h=87aae76d6bf662f08d41c9cca30a0a372fd57112


Regards,
Vishal