Linux/AM5728: GPIO, UART and I2C operations in AM572X EVM

Hi Yordan,


Thank You for the reply.
Is there any wiki or guide to pinmux and enable the peripherals.

My doubts are these.

How we calculate the pin number or offset ?

How a particular gpio pin may be enabled ?

For uarts, whether enabling requires only pinmux?


Thanks in advance for the help.


Thanks & Regards,
Sajeevan.K

Hi Yordan,


I added the following lines to am57xx-evm.dts

&dra7_pmx_core {
pinctrl-names = "default";
pinctrl-0 = <&board_pins>;

board_pins: pinmux_board_pins {
pinctrl-single,pins = <
0x16DB 0x020E
0x16E0 0x020E
0x1474 0x020E
0x1488 0x020E

0x14C4 0x060E
0x14CC 0x060E
0x14D8 0x060E
>;
};

uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
0x17E0 0x00
0x17E4 0x00

>;
};

};

&uart1 {
status = "okay";
pinctrl-names="default";
pinctrl-0 = <uart1_pins>;
};

I was attempting to make GPIO4_17,GPIO5_11,GPIO2_3 and GPIO2_8 as outputs and GPIO2_23, GPIO2_25 and GPIO2_28 as inputs.
Also I tried to enable uart1.

dts file is compiled.

After replacing dtb also, it is not working.
Am I missing something? Or anything wrong?

Thanks for the help,

Thanks & Regards,
Sajeevan.K

Hi,

Module pin number can be seen in the device Data Manual:
Table 4-2. Ball Characteristics

The column BALL NAME, corresponds to the Control Module register, which should be set. The CTRL_MODULE register can be found in device Technical Reference Manual, see :
CTRL_CORE_PAD_*
Table 18-28. CTRL_MODULE_CORE Registers Mapping Summary of the TRM.

Then the offset that is written in the dts file can be calculated, by checking dra7.dtsi,
l4_cfg: l4@4a000000 ---> interconnect base address
scm: scm@2000 ---> system control module offset
dra7_pmx_core: pinmux@1400 ---> Pinmux registers start address

If you add the above addresses you'll get the address of the first PADCONF reigister: CTRL_CORE_PAD_GPMC_AD0 0x4A003400
By adding the needed registers offset you get the address of the corresponding padconf.

Best Regards,
Yordan

Hi Yordan,

Thank You very much for the reply.

From Your mail I could understand that, the offset I written is wrong.

I think correcting it would solve the issue.

But unfortunately, my AM572x evm is not in working condition now.

So I would not be able to test it immediately.

The problem is PMIC shutting off the power to controllers after 7 seconds.

I don't know whether this shutting off has any link with wrong .dts file.

But even with an SD card with pre built images, the same problem is happening.

 If this PMIC shutting off has any link with wrong .dts file, please suggest to recover from this state.

Anyway I have already created another thread for this PMIC shut off problem in Sitara E2E community.

So I am closing this thread.

Thanks & Regards,

Sajeevan.K

Hi Yordan,.


I got a new Processor card.
I tested this card with corrected .dtb.

But still states of port pins are not getting changed as specified in software.

The corrected .dts file portions is as shown below.

&dra7_pmx_core {
pinctrl-names = "default";
pinctrl-0 = <&board_pins>;

board_pins: pinmux_board_pins {
pinctrl-single,pins = <
0x2E0 0x020E
0x2D8 0x020E
0x74 0x020E
0x88 0x020E

0xC4 0x060E
0xCC 0x060E
0xD8 0x060E
>;
};

uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
0x3E0 0x00
0x3E4 0x00

>;
};

};

&uart1 {
status="okay";
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins>;
};

As I mentioned earlier , the /sys/class/gpio/gpioxx folders are getting created. The file "value" is getting updated as in the software.

But this value is not appeared in the pin output.


Thank You in advance for the help.




Thanks & Regards,
Sajeevan.K

Hi Yordan,


As I told in the previous mail, gpio software, which was successfully running in Beaglebone black is not working in A572x.

This software was just writing into the files /sys/class/gpio/gpioxx/direction and /sys/class/gpio/gpioxx/value.
The file /sys/class/gpio/gpioxx/value is correctly updated as per software. Once more I verified this.

But this value in file /sys/class/gpio/gpioxx/value is not updated to the port pin.



Now I tested with another software " 4174.am335x_gpio_key_led.c" which I got from

e2e.ti.com/.../1111256. With this software, port pins are correctly updated. Everything is working fine.


In the second software direction register and value register are directly accessed through their address.

In the first software, the files in /sys/class/gpio/gpioxx/ are changed to control. This method was working fine in BBB. Why this method is not working in AM572x?


Before the correction of .dts file, both softwares were not working.


Now I am moving to uart and i2c. Here also I am using the software which was working in BBB. In BBB, there was cape manager slots which is defined in /sys/devices/platform/bone_capemgr/slots.

For example if UART4 need to be activated, then the command sudo su -c "echo BB-UART4 > $SLOTS" to be given to enable BB_UART4 overlay. Is there any similar procedure required in AM572x?

Thanks & Regards,
Sajeevan.K

Hi Yordan,

For UART also I am facing the same problem.

The code which is working fine in BBB is not working in AM572x.

In the code, I am using in BBB

 ser_fd = open("/dev/tty1",O_RDWR | O_NOCTTY);

   if(ser_fd == -1)

   {

      printf("\n  Error! in Opening tty1\n");

   }

   else

   {

      printf("\n  tty1 Opened Successfully\n");

   }

   tcgetattr(ser_fd, &ser_settings);

   cfsetispeed(&ser_settings,B9600);

   cfsetospeed(&ser_settings,B9600);

the file /dev/tty1 is opened successfully.

But transmission or reception is not happening.

Like in the case of GPIO code, register level access is required here also?

Any sample code available for the same?

Thanks for the help.

Thanks & Regards,

Sajeevan.K

Hello, SAJEEVAN.
I've encountered a problem with GPIO too: leds connected to gpio3_8, gpio3_11, gpio3_16 and gpio3_20 didn't working by programming via sysfs attributes.
Key point of this problem is, that gpio banks mapping on am5728 doesn't match with mapping on am33xx.
Firstly you can try to ensure, that you request correct number of gpio. You can set your gpio as leds via dts, and after linux boot up, check assigned gpio numbers in the system via debugfs:

1. Add the following test nodes into your dts with corresponding gpio bank and port numbers:

leds {
  compatible = "gpio-leds";
  led@0 {
    label = "VD1:AH3";
    gpios = <&gpio3 8 GPIO_ACTIVE_LOW>; //set your bank and port numbers here
    linux,default-trigger = "default-on";
    default-state = "off";
};
...
(you can add there more gpio-leds, if you need)
...

};

2. Than boot up your board with this dts and check numbers of assigned gpios via command 

cat /sys/kernel/debug/gpio

According this example you can get following log, where clearly seen, that our gpio3_8 has a number 232, and it doesn't correspond with cross-cut enumeration like on am33xx (where it should to be 104):

Hi Ilya Kravchuk,

Thank You very much for the reply.

We are busy with another work now. Once that work is completed, we will check this and give You feedback.

Thanks & Regards,

Sajeevan.K

Hi,

I have had the same problem with gpios going from a am3358 to a am5728 EVM. I found out that with the am5728, the gpio banks start at 1 while they start at 0 for the am3358. That is:
on am335x:
gpio2_7 would be gpio71 ((2-0)*32 + 7)
on am5728:
gpio2_7 would be gpio39 ((2-1)*32 + 7)

II lost a big day on this...

I edited this entry to add more info on name indexing in general with the am5728 which could explain the problem you have with UARTS. UART0 is not available to the ARM (only to the PRU), so the UARTs start at UART1. Therefore:

on am572x:

UART1 maps to TTYS0

UART2 maps to TTYS1 ...

on am335x:

UART0 maps to TTYO0

UART1 maps to TTYO1...

And if you need to work with PWM, than you have that bizarre mapping of indexes:

Device tree to hardware mapping on am57xx:

ehrpw0 maps to ehrpw1

ehrpw1 maps to ehrpw2

ehrpw2 maps to ehrpw3

Be careful with all naming of device as the indexing has moved around with the am572x.

And as for muxing, be very careful since all the pin muxing is done by the bootloader. If you have hardware that does not use the pins of the EVM connector the way that they were meant, you must rebuild the boot loader accordingly. Just overriding the muxing in the device tree might be to late if your hardware component has an output pin corresponding to an output pin on the connector! I personally think that the muxing should have been kept at the device tree level. Those that know how it was to develop before the "device tree era" will remember how difficult it was to keep up with kernel versions, I don't think we want this to be the same thing with the boot loader! I hope that TI goes back to putting the muxing in the device tree.

Hope this helps,

Vincent Fournier