DRA829J: Loading tiboot3.bin using USB DFU does not seem to work

Hi Steve,

You will need to transfer the sysfw.itb binary from host to target to even see the first prints on the UART console. Can you try that?

Steps: software-dl.ti.com/.../UG-DFU.html

- Keerthy

Hi Keerthy,

Thanks for your reply,

The issue is I can't load sysfw.itb.  Once tiboot3.bin is loaded, the J721e DFU USB port disappears.  I've also tried loading these files using the UART/XMODEM protocol.  same issue.

I'm using the stock tiboot3.bin, built using "make" and have not changed any of the configuration at this stage

thanks

Stephen Turner said:

The issue is I can't load sysfw.itb.  Once tiboot3.bin is loaded, the J721e DFU USB port disappears.

Are you using a virtual ubuntu machine? If yes this issue is expected. You will need a native ubuntu machine.

Stephen Turner said:

I've also tried loading these files using the UART/XMODEM protocol.

Are the pins used for MAIN_UART the same on your custom board compared with the TI EVM?

- Keerthy

Hi Keerthy.

tiboot3.bin is being compiled on an Ubuntu VM, but downloaded using dfu-util on a real Windows machine.

When put in UART boot mode, the WKUP UART port is being used.

thanks

Further to this, how do I configure the u-boot inside tiboot3.bin to be as minimal as possible, while still supporting DFU-USB?.  Where is the config file for this (and sysfw.itb)?.

thanks

Today I tried loading tiboot3.bin on the EVM using dfu-util and can confirm that it loads and the EVM still shows a USBB DFU device.  I'm further able to load sysfw.itb and the other files to get to a u-boot prompt

So there is something about my custom h/w that tiboot3.bin in its current form does not like.  And the question is how to figure this out?.  How do I go about chopping stuff out of tiboot3 until it loads?

thanks

Hi Keerthy,

Any ideas why the J721E USB DFU port disappears on my h/w after I load tiboot3.bin?. This prevents me from loading sysfw.itb

thanks

Hi Stephen,

We are trying to reproduce at our end on other hardware. Can you attach a debugger after the first binary gets through?
The R5 SPL should be executing. Can you check that on your hardware?

- Keerthy

Hi Keerthy,

Unfortunately I do not have a JTAG connector on this design.

So are you saying that after tiboot3.bin is loaded, the DMSC starts it running?.  Then who (DMSC or tiboot3) asks for sysfw.itb?.

I am trying to set an LED "on" at the beginning of tiboot3.bin but am not quite sure where to put this code.  For instance I have an LED on GPIO0-16 and added this code below in evm.c.  The LED did not come on:

int board_init(void)
{
    struct gpio_desc desc = {0};
    dm_gpio_lookup_name("16", &desc);
    dm_gpio_request(&desc, "16");
    dm_gpio_set_dir_flags(&desc, GPIOD_IS_OUT);
    dm_gpio_set_value(&desc, 0);
    return 0;
}

Hi Stephen,

I checked internally. Do you use the same binaries for both custom board(non-working) & TI EVM(Working).
If not please check if the custom board defconfig has the DFU related CONFIG options enabled.

- Keerthy

Hi Keerthy,

Yes, we have tried the same tiboot3 binary which came with and works on the EVM, with our h/w.  Also have tried tiboot3 that we have compiled with the same results.  We do have all the DFU CONFIG options enabled.

Can you confirm that as soon as tiboot3 is loaded by the DMSC DFU mechanism it is run and then takes over the DFU role from the DMSC?.

thanks

Hi Keerthy,

Do you know the exact variant of J721E that is on the EVM?.  Because of the heatsink, I can't see that.  Here is what I'm using:

Hi Keerthy,

Can the MCU (R5) access the GPIO?.  I'd like to turn on one of my LEDs, i.e an LED on GPIO0-16.

thanks

Stephen,

R5 SPL should be able to access the GPIO. One of the first things that R5 SPL(tiboott3.bin) does is to load the sysfw.itb.
It will be really helpful to check with a debugger where the code is stuck on the custom board. Since we do not get any prints
before we load sysfw.itb this debug will be really hard without debugger.

- Keerthy

Keerthy J said:

R5 SPL should be able to access the GPIO.

Hi Keerthy,

Do you have some example code for this?.

thanks

Stephen,

No I do not have an example code but one thing to check before we get to the details of failure. To see if the sample is a GP or NOT on the custom board.
Boot using UART boot mode and grab the hex characters that appear on the MCU_UART terminal. That should give us all the details of the sample type.
Can we check that to start with?

- Keerthy

Hi Keerthy,

Unfortunately, I do not have the MCU_UART terminals exposed on my custom h/w.

I do have the WKUP_UART exposed and can see the XMODEM prompt being output when put in UART boot mode.  I am able to load tiboot3.bin using this mode, but once loaded there is no additional prompt for sysfw.itb

thanks

Stephen,

Stephen Turner said:

Unfortunately, I do not have the MCU_UART terminals exposed on my custom h/w.

I believe that was the detail I was not aware of!

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1109996/faq-tda4vm-how-to-boot-using-wkup-uart

Please follow the above link in particular the section for SPL:

Modifications needed for SPL based boot flow:

If we use the below dip switch settings on the EVM we get the the hex dump initially on WKUP_UART as well.

SW8: 0000_1000
SW9: 0111_0000

- Keerthy

Hi Keerthy,

Using this https://e2e.ti.com/support/processors-group/processors/f/processors-forum/958582/tda4vm-wkup-gpio-control-during-boot

I was able to toggle a GPIO pin at various points of tiboot3's execution.  It seems to get all the way to run_usb_dnl_gadget(), but then get stuck waiting for the download.  The USB port goes from being a J721E DFU interface before tiboot3 is downloaded to:

I have checked our USB circuitry and that fact that it works when the R5 ROM code is initially running must indicate that its OK?.

thanks

Stephen Turner said:

I have checked our USB circuitry and that fact that it works when the R5 ROM code is initially running must indicate that its OK?.

Yes. That does look to be okay. I infer the same. So is the circuitry different when compared to EVM? Something that RoM code seems to be okay with but R5 SPL somehow fails with that.

- Keerthy

HI Stephen ,

Can you check with the attached binarys once.

prebuilt-images.zip

When you test with the evm which sdk you used?

Regards
Diwakar

Hi Diwaker,

I tried the tiboot3.bin you sent and unfortunately it does not work.

I'm building tiboot3.bin using SDK 08_05_00_08

I have been tracing the execution of the USB DFU code.  It seems the code gets stuck in this while(1) loop in run_usb_dnl_gadget() in dfu.c.  On the EVM, once this loop starts running the DFU USB interface appears and I can download sysfw.itb.  On my h/w I only get a an invalid USB interface and cannot proceed.

int run_usb_dnl_gadget(int usbctrl_index, char *usb_dnl_gadget)
{
	bool dfu_reset = false;
	int ret, i = 0;

	ret = usb_gadget_initialize(usbctrl_index);
	
	if (ret) {
		pr_err("usb_gadget_initialize failed\n");
		return CMD_RET_FAILURE;
	}
	g_dnl_clear_detach();
	ret = g_dnl_register(usb_dnl_gadget);
	if (ret) {
		pr_err("g_dnl_register failed");
		return CMD_RET_FAILURE;
	}

#ifdef CONFIG_DFU_TIMEOUT
	unsigned long start_time = get_timer(0);
#endif

	while (1) {
		if (g_dnl_detach()) {
			/*
			 * Check if USB bus reset is performed after detach,
			 * which indicates that -R switch has been passed to
			 * dfu-util. In this case reboot the device
			 */
			if (dfu_usb_get_reset()) {
				dfu_reset = true;
				goto exit;
			}

			/*
			 * This extra number of usb_gadget_handle_interrupts()
			 * calls is necessary to assure correct transmission
			 * completion with dfu-util
			 */
			if (++i == 10000)
				goto exit;
		}

		if (ctrlc())
			goto exit;

		if (dfu_get_defer_flush()) {
			/*
			 * Call to usb_gadget_handle_interrupts() is necessary
			 * to act on ZLP OUT transaction from HOST PC after
			 * transmitting the whole file.
			 *
			 * If this ZLP OUT packet is NAK'ed, the HOST libusb
			 * function fails after timeout (by default it is set to
			 * 5 seconds). In such situation the dfu-util program
			 * exits with error message.
			 */
			usb_gadget_handle_interrupts(usbctrl_index);
			ret = dfu_flush(dfu_get_defer_flush(), NULL, 0, 0);
			dfu_set_defer_flush(NULL);
			if (ret) {
				pr_err("Deferred dfu_flush() failed!");
				goto exit;
			}
		}


#ifdef CONFIG_DFU_TIMEOUT
		unsigned long wait_time = dfu_get_timeout();

		if (wait_time) {
			unsigned long current_time = get_timer(start_time);

			if (current_time > wait_time) {
				debug("Inactivity timeout, abort DFU\n");
				goto exit;
			}
		}
#endif

		WATCHDOG_RESET();
		usb_gadget_handle_interrupts(usbctrl_index);
	}
exit:
	g_dnl_unregister();
	usb_gadget_release(usbctrl_index);

	if (dfu_reset)
		do_reset(NULL, 0, 0, NULL);

	g_dnl_clear_detach();

	return ret;
}

thanks

Hi Stephan,

1.Can you share your config file.

2.Are you able to boot upto linux using any other boot mode (uart ,sd). If yes are you able to connect disconnect usb multiple time without any issue we are suspecting reset is no happening  properly.

3.Also can you share the host side logs when you use dfu boot .

Regards
Diwakar

OK, progress:

I assumed that tiboot3.bin would read the PLL ref clock from the BOOTMODE pins as the ROM code does.  Our h/w has a 25MHz clock and the EVM has a 19.2MHz clock.  Bad assumption.  Once I changed this line in k3-j721e-r5-common-proc-board.dts 

	clk_19_2mhz: dummy_clock_19_2mhz {
		compatible = "fixed-clock";
		#clock-cells = <0>;
		clock-frequency = <25000000>; /*<19200000>;*/
		u-boot,dm-spl;
	};

I was able to download sysfw.itb and see the following on WKUP_UART0

0x430002
                  0xC30004
                          0x4003005
                                   0x4401611
                                            0x43000B
                                                    0xC30004

At this point my DFU USB device disappears again.

So my question is - where else is the PLL ref clock hard coded?

thanks

HI Stephan,

Stephen Turner said:

Our h/w has a 25MHz clock and the EVM has a 19.2MHz clock.

Oh I was not aware of this .

So my understanding is now you can flash upto sysfw.itb and then DFU device is getting disappears.

Diwakar Dhyani said:

1.Can you share your config file.

2.Are you able to boot upto linux using any other boot mode (uart ,sd). If yes are you able to connect disconnect usb multiple time without any issue we are suspecting reset is no happening  properly.

3.Also can you share the host side logs when you use dfu boot .

Can you share these ?

Reagards
Diwakar

Diwakar Dhyani said:

So my understanding is now you can flash upto sysfw.itb and then DFU device is getting disappears.

Correct.

I have traced further inside tiboot3.bin and the call to uclass_get_device(UCLASS_RAM, 0, &dev); never returns.  I have a 32Gb LPDDR4 DRAM connected to the EMIF and have used the SPRACU8B_Jacinto7_DDRSS_RegConfigTool spreadsheet to generate a custom DTSI file with what I think is the config for our LPDDR4

#if defined(CONFIG_K3_J721E_DDRSS)
	ret = uclass_get_device(UCLASS_RAM, 0, &dev); <---------- never returns
	if (ret)
		panic("DRAM init failed: %d\n", ret);
#endif

A request to TI.  Please document what changes are required in the bootloader configs to support custom h/w. 

For instance documenting that the USB subsystem needs to know in defconfig what the reference clock frequency is. 

Others include what to change if you have an LPDDR4 size of other than 4GB

Thanks!