i.MX ProcessorsのトピックRe: Any examples on how to modify the .dts (device tree) source for custom hardware?

Any examples on how to modify the .dts (device tree) source for custom hardware?

EdSutter — Fri, 10 Jan 2014 20:45:51 GMT

I've been working with hardware that is similar to the SABRESDB iMX6 board.

My next step is to redefine a few interfaces that are custom to my board.

For starters, I'd like to just tweek my GPIO configuration, by undoing some of

the GPIO setup that was used by SABRESDB and establish my own GPIO

configuration based on my schematic.

Maybe I'm just tired, or maybe this is just hard...

I'm not having much luck figuring out how to modify the .dts files that are used with

the sabresd board.

I'm currently reading the Documentation/devicetree stuff and A Tutorial on the Device Tree (Zynq) -- Part I .

Is there any other examples or good documentation that discusses this?

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

AnsonHuang — Thu, 16 Jan 2014 05:50:13 GMT

Hi, Ed

We have may GPIO use case in our dts, please refer to arch/arm/boot/dts/imx6qdl-sabresd.dtsi, grep charger-led or other GPIO settings. Also, there is device tree binding DOC you can refer to, Documentation/devicetree/bindings/gpio/gpio.txt, all other GPIO related feature are in same folder.

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

EdSutter — Fri, 17 Jan 2014 13:59:07 GMT

Hi, Thanks for responding.

What kernel tree are you referring to? I'm working with mainline 3.12 (patched for some eMMC fixes) at the moment.

My real problem (at the moment) is I'm trying to figure out how to "release" some of the GPIO pins that are apparently still configured for use (in ALT mode) with some other peripheral (from SABRESD configuration I started with) that I'm not using on my custom board. Know what I mean? There seems to be no clean way to do this, so for example I need to use GPIO_4 as GPIO, but when I try to access this through /sys/class/gpio/gpio4/value, I can't change the state; hence, I'm assuming it is configured in some ALT mode. To work backwards then, the only thing I can see to do is to look at all the possible ALT modes for GPIO_4 and look in the .dts/dtsi files to see if one of those peripherals is active. Does this make sense? Is there a better way?

Also regarding the Documentation directory on the bindings, I guess I don't quite follow the whole point of this directory yet. There are .txt files here for several different systems (non of which appear to be related to imx6).

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

EdSutter — Fri, 17 Jan 2014 14:33:27 GMT

Just to get a little bit more specific to my problem...

I am trying to use GPIO_4 simply as a gpio output.

On the SABRESD board is a volume control button.

Is there anything else I need to change in the imx6qdl-sabresd.dtsi file besides comment out the gpio-keys node?

Re: Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

EdSutter — Fri, 17 Jan 2014 20:38:25 GMT

Replying to my own question here, but I'd love to hear from someone else on this...

I managed to get the GPIO_4 issue resolved. Turns out that uboot was configuring

this pin to be an input (because that's how it was used on sabresd). As soon as I

changed uboot, then these commands (at the unix prompt) worked..

echo 4 >/sys/class/gpio/export

echo out >/sys/class/gpio/gpio4/direction

echo 1 >/sys/class/gpio/gpio4/value

echo 0 >/sys/class/gpio/gpio4/value

This makes me wonder what (if anything) is done by the first

two lines (which supposedly configured the direction to be output)...

Can anyone explain this?

Re: Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

peteewg — Thu, 23 Jan 2014 19:51:23 GMT

Hi Ed,

Line 1, exports the pin. i.e initialises the hardware register, checks for conflicts such as if it's been configured for another function e.g a serial port. It also exposes the sysfs functionality. If you look at the gpio directory before and after you export you'll see a new folder containing the sysfs functions gets created (gpio4 or similar). These functions then update the appropriate registers but with a common Linux interface.

All gpios are set as inputs to begin with for safety so you don't accidentally drive into another output on your hardware, if one was driving high waggle the other low, damage could occur. So you must explicitly set it to output.

Also after use you should unexport the pin to tidy everything up.

With regards to the .dts (device tree specification) file you'll probably see it inherits from one or two other files. One thing to look out for is the pin ctrl. This is not to be confused with the pin, it is a hardware block in its own right and therefore has its own entry in the dts (which is a description of each hardware block in the system). So you'll need to define this to allow your pin to be a gpio as well as adding the pin itself.

I think I'm about 3 days ahead of you in my own development for an imx28 board, so if any experts would like to add anything, or rubbish the above explanation, be my guest.

Re: Re: Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

EdSutter — Thu, 23 Jan 2014 20:17:17 GMT

Peter,

Thanks for the clarification; however, my fundamental problem is that this line

echo out >/sys/class/gpio/gpio4/direction

had no effect. I would have thought that anything uboot did to the pin would

have been overridden; but that was not the case. When I changed uboot so

that it configured the pin as ouput, then I was able to use

echo 1 >/sys/class/gpio/gpio4/value

echo 0 >/sys/class/gpio/gpio4/value

to toggle the GPIO level. That is still a mystery to me. Note that this is

with a MUCH newer kernel (3.12) than what is in YOCTO/LTIB, so I am starting to

conclude that I may need to step back to something that is a bit more

supported in the iMX community. Unfortunately, I think that means a kernel

that is pre-dts. I spent the time getting to know this (a bit); so I hate to have

to do that.

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

YixingKong — Thu, 20 Feb 2014 06:34:40 GMT

Had your issue got resolved? If yes, we are going to close the discussion in 3 days. If you still need help please feel

free to contact Freescale.

Thanks,
Yixing

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

EdSutter — Thu, 20 Feb 2014 14:45:25 GMT

Yixing,

No this has not been resolved. The device tree in general I understand; however, its direct connection to

iMX6 device interfaces is still a mystery to me.

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

YixingKong — Fri, 21 Feb 2014 02:59:01 GMT

I will branch your questions into an internal group and assigin engineer to answer your question.

Regards,

Yixing

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

EdSutter — Fri, 21 Feb 2014 22:07:34 GMT

Conceptually I get the device tree; however, applying it is a different beast (IMHO).

My question should be simple for anyone that really understands this device tree stuff as it applies to iMX6.

I want to be able to use certain GPIO pins as input, some as output.

I want to be able to access them through /sys/class/gpio.

What do I need to do in the device tree to configure, for example, GPIO_0 as an input and GPIO_1 as an output?

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

fabio_estevam — Mon, 24 Feb 2014 16:51:47 GMT

How did you configure the GPIO in the dts?

Regards,

Fabio Estevam

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

EdSutter — Mon, 24 Feb 2014 17:08:59 GMT

Fabio,

That's the part that I don't get!

How do I configure the GPIO in the dts?

I see the use of "gpio" all over the place, but I just wanna allocate a couple

of pins as basic GPIO pins (some input, some output) so that I can then use

/sys/class/gpio to monitor and/or modify them.

I have not seen any examples of this that make any sense to me.

For example:

Say I want to configure pad GPIO_0 as GPIO1_IO00 (ALT5), and use it as an input; and I

want to configure pad GPIO_1 as GPIO1_IO01 (ALT5), and use it as an output.

How would I do that with the DTS file so that I could then access these pins with

/sys/class/gpio/gpio0 and /sys/class/gpio/gpio1?

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

fabio_estevam — Mon, 24 Feb 2014 18:01:01 GMT

Every pin needs to have its PAD configured in the dts file. For example:

MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0

MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x80000000

The explanation of what these values mean is available at:

Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt

and

Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt

The 0x80000000 means that the kernel will not touch the PAD settings and it will use whatever comes from default (or from U-boot in case it was previously configured in U-boot).

Regards,

Fabio Estevam

Re: Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

EdSutter — Mon, 24 Feb 2014 20:12:49 GMT

I've been reading through that stuff, but something just isn't sinking in.

Bear with me here (thanks for your patience)...

If I have this in my .dts file...

&iomuxc {

pinctrl-names = "default";

pinctrl-0 = <&pinctrl_hog_1>;

hog {

pinctrl_hog_1: hoggrp-1 {

fsl,pins = <

MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x80000000

MX6QDL_PAD_GPIO_1__GPIO1_IO01 0x80000000

...

}

and I've got these two pins configured in uboot, the way I want them (GPIO_0=out, GPIO_1=in)

shouldn't I be able to access them as regular GPIO using /sys/class/gpio?

I know they are configured correctly in uboot because I can access them there and they do what

I expect; however when I try to read the input line (/sys/class/gpio/gpio1/value) its not reading

back the value on the bit.

Note, I realize that GPIO_1 *could* be allocated to usbotg, but I don't have USB on

this board; so that node is removed from my dts file.

Re: Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

fabio_estevam — Mon, 24 Feb 2014 22:20:52 GMT

I think you would need to register your input GPIO as 'gpio-keys' in the dts.

Please see sabresd for reference.

Regards,

Fabio Estevam

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

YixingKong — Wed, 05 Mar 2014 06:31:48 GMT

Has your issue got resolved? If not, please reply with an update here, otherwise we would like to close the DI in 3 days..

Regards,

Yixing

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

EdSutter — Wed, 05 Mar 2014 12:47:18 GMT

Yixing,

No it hasn't been resolved. The connection between device tree and the underlying kernel drivers; specifically those unique to iMX6, is still somewhat of a mystery to me. I understand the device tree concept (I'm using it); but I still have not had time to dig into the code to really see the connection between the iMX6-specific hooks and the entries in the device tree .dts file(s). I can hack my way through it, but would like to have a better understanding of it. Sooner or later I'll just dig into the code and figure it out. Meanwhile, if for some reason you need to close this discussion, go for it.

What's the point here? Why does this need to be closed?

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

YixingKong — Thu, 06 Mar 2014 05:18:31 GMT

Ed, if your issue/question is still there, I will leave the discussion open. Please do not leave the discussion here withno action and keep exchanging emails with our engineers so that you could get response quicker.

Thanks,

Yixing

Re: Any examples on how to modify the .dts (device tree) source for custom hardware?

YixingKong — Thu, 20 Mar 2014 06:39:01 GMT

This discussion is closed since no activity. If you still need help, please feel free to reply with an update to this discussion, or create another discussion.

Thanks,

Regards,

Yixing