U-boot device tree confusion

Technical Support
, , , ,
1

Hi,

I’m little confused how u-boot device tree is configured. I assume it has its own, completely isolated, device tree built from here?

I have a “problem” with USB OTG while in u-boot console. I have an ID pin (from external TUSB320) connected to GPIO5_8 (pin 135) and it works, but I don’t understand why.

VBUS detection pin 137 is always 1 in my system and I can see that with gpio status GPIO5_09.

On the other hand, gpio status GPIO5_08 for pin 135 returns always 0, no matter whether there is mass storage or a PC connected, but both modes work. If I disconnect the ID pin from 135, host role doesn’t work anymore, so the pin clearly is significant.

From fsl-imx8qxp-colibri-u-boot.dtsi I find that

	usbg1: usbg1 {
		compatible = "fsl,imx27-usb-gadget";
		dr_mode = "peripheral";
		chipidea,usb = <&usbotg1>;
		status = "okay";
		u-boot,dm-pre-proper;
	};

which I think means that the port is in peripheral ONLY mode (I have only this one port). And in fsl-imx8qxp-colibri.dtsi is

		pinctrl_usbc_det: usbc-det {
			fsl,pins = <
				SC_P_ENET0_REFCLK_125M_25M_LSIO_GPIO5_IO09	0x06000040
			>;
		};

which means GPIO5_9 (pin 137) is monitored. U-boot’s gpio status also says this GPIO is named usb_cdet (notice place of underscore) and I don’t find anywhere where this name would be defined?

So I guess my question is, where is it defined that pin 135 in u-boot is monitored for OTG role change?
Where the names of gpio’s in u-boot come?
Is Linux-side DTB used in any way while in u-boot console? (except for booting linux later)

Thank you!

Colibri iMX8QXP V1.0D
Toradex_5.4-2.3.x-imx
Custom carrier

2

Greetings @tuomas86,

Let me try and go through your questions here one by one and see if I can help answer/clarify things here.

I’m little confused how u-boot device tree is configured. I assume it has its own, completely isolated, device tree built from here ?

Yes, so the u-boot device tree is taken from the U-Boot source separate from the Linux kernel. The way the right device tree is chosen and configured is based on the config for the hardware you’re building U-Boot for. For example, the Colibri i.MX8X used the coibri-imx8x_defconfig. In this config there’s the following config: CONFIG_DEFAULT_DEVICE_TREE="fsl-imx8qxp-colibri".
This is how the right device tree gets chosen.

U-boot’s gpio status also says this GPIO is named usb_cdet (notice place of underscore) and I don’t find anywhere where this name would be defined?

This part is a little tricky. If you look only in the device tree you’d wouldn’t find anything regarding usb_cdet. Instead you need to look in the U-Boot board file for the Colibri i.MX8X here.

This file defines some characteristics of the board. However the board file can also set hardware behavior and characteristic separate from the U-Boot device tree. In the board file I linked you’ll see references to usb_cdet. There’s even a define statement towards the top that references GPIO5_9 with regards to usb_cdet. This is the only place in the entire U-Boot code-base where usb_cdet gets referred to so I can only assume this is where it happens.

where is it defined that pin 135 in u-boot is monitored for OTG role change?

So this question is a bit complex and I may need to do more research myself. But I believe the answer or at least the path to the answer can be found in the datasheet for the Colibri i.MX8X. This excerpt in particular on page 38:

The Colibri iMX8X module does not support true OTG, but the interface can be configured as host
or client. Due to compatibility with other Colibri modules, the current evaluation board and the
other Toradex carrier board do not use the USB OTG ID pin to detect whether a Type A or Type B
cable is plugged in. Instead, the VBUS is used for detecting the Host or Client mode. We
recommend implementing the same circuit as on the evaluation board to ensure the design is
compatible with the provided Toradex OS images (BSP).

Not sure if this helps your question but let me know what you think.

Where the names of gpio’s in u-boot come?

Could you clarify which names you are referring to specifically? Or is this about the usb_cdet naming again?

Is Linux-side DTB used in any way while in u-boot console?

It is not. The Linux device tree is not even loaded/used until the boot sequence passes control from U-Boot over to the Linux Kernel.

Let me know if this helps at all. Or if anything I just said requires further clarification.

Best Regards,
Jeremias

3

Hi, thank you for answer! That cleared up many things.

Still the GPIO5_08 (pin 135) thing is a mystery to me. I understand that in Colibri standard/reference design, the ID pin is used at hardware level to control the power switch IC, that in turn leads to VBUS detection signal to toggle based on host/client connection. This VBUS detection signal is connected in Colibri reference design to GPIO5_09 (pin 137) and works in u-boot, tezi, and linux side for OTG role change. But the ID signal is not used directly. Pin 135 is called USB_OTG1_ID in datasheet, with comment that it is not used.

With our custom carrier, ID is supposed to be used directly, and VBUS detection not used, and ID pin does not control VBUS detection (it is always 1 at the moment). I’ve changed Linux DTS to listen to pin 135 instead of 137 for role change. This now (kind of) works on Linux side. It does not work in TEZI console because of the different implementation, and I understand why not.

But it works in u-boot console, and I don’t understand why. If I disconnect pin 135, role change does not work in u-boot, so it is definitely that gpio that matters.

I just want to be sure how things work, before I start suggesting what hardware changes we might or might not need!

4

But it works in u-boot console, and I don’t understand why. If I disconnect pin 135, role change does not work in u-boot, so it is definitely that gpio that matters.

This detail is actually puzzling for me as well. As far as I can tell from the U-Boot source code this pin isn’t defined as anything that would related to the USB OTG interface. Let me reach out to our development teams to see if they have an idea of why 135 is behaving this way in U-Boot.

Also for clarity it sounds like your project intends to use USB OTG role switching in both U-Boot and Linux correct? So I have an idea could you perhaps explain a bit about your use-case/needs here and what exactly you want to do with USB OTG, specially in U-Boot?

Best Regards,
Jeremias

5

Thanks for looking into it!

We have only one USB-C port available in our device, so we would just want it to work flexibly both ways in all situations (updating, recovery, debugging…). In gadget mode I can connect it with ums to PC and access boot partitions. In host mode I want to be able to access mass storage device and boot from USB etc.

6

I went back and forth with the team on this question and I got some information. We believe this to just be an inherent function of the hardware rather than the software. While the Colibri standard pintout doesn’t use the USB ID pin, it still functions as you’ve seen. Our best assumption is that if the software doesn’t specify, which is the case in U-Boot, the USB controller just automatically uses/handles the ID pin here.

We haven’t found hard confirmation on this but it seems the most likely thing that is happening here.

Best Regards,
Jeremias

7

Thank you for looking into it! Did you test and see the same behavior on your end?

8

The team member I was discussing with noticed a similar phenomenon. I believe it was on the evaluation board since you can change the connection of the ID pin via jumper.

Best Regards,
Jeremias

1 Like