Hummingboard additional UART

[Gyver]

On 5/5/2016 at 8:54 PM, zador.blood.stained said:

Initial output after start/reboot is from u-boot.

To use serial console as main for kernel messages and init progress, change

console=tty1

to

console=ttyS0,115200

in boot script and recompile it using command at the end of the file.

Hello,

I am having a problem using the uart and I guess it is related with this topic.

I am trying to make my Hummingboard to communicate via UART with a serial ublox GPS. I identified that the right device in armbian (5.34) is /dev/ttymxc0 since it echoes characters when I join tx/rx together.

When I connect the GPS it starts sending gps data normally, but when I have to reboot the hummingboard, it does not boot.

I connected a screen to the HDMI interface to see what was happening, and I get the screen message as if a key had been pressed in order to stop booting process, so the boot stops here and the hummingboard does not come up. When I disconnect the GPS power or the UART, the HB boots normally, and the gpsd gets the serial port. when the gpsd is closed, agetty takes the control of the uart and I cannot use it again until I reboot.

 

I concluded that the boot was configured to take the console keyboard from the UART, so I modified /boot/boot.cmd as suggested in this thread; I found the line:

 

if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttymxc0,115200"; fi

 

So I changed to 

 

if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "console=tty1"; fi

 

in order to avoid the boot to grab the ttymxc0 serial port. I recompiled the boot.cmd and rebooted, but the problem persists. The boot is still stopped due to an abnormal keypress.

 

I have no idea of how to make it work, since I have tried the procedure above and also explored the alternative of resetting via hardware the GPS during hummingboard boot, but it still stops the booting. The GPS will be permanently connected to the hummingboard, so I cannot disconnect it everytime I reboot. Do you have any ideas about what would be the problem? How to avoid the boot to depend on the uart?

 

I also checked the boot configuration built on the kernel:

 

cat /boot/config-4.13.12-cubox |grep ttymxc

 

and th result was:

CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"

 

Does this mean  that I have to recompile the kernel to solve it?

Thanks very much in advance

Regards

 

[Igor]

1 hour ago, Gyver said:

Does this mean  that I have to recompile the kernel to solve it?

Not a problem of kernel but configuration. You need to make use of some other UART, not the one used/reserved for serial console (already by u-boot) and you should not have troubles. Check documentation where is ttymx1

[Gyver]

On 11/24/2017 at 6:34 PM, Igor said:

Not a problem of kernel but configuration. You need to make use of some other UART, not the one used/reserved for serial console (already by u-boot) and you should not have troubles. Check documentation where is ttymx1

in armbian I can see only /dev/ttymcx0 and 3 as devices, according to these pinout 

http://forum.solid-run.com/hummingboard-hardware-lab-f18/gpio-header-pinout-t1476.html

there is only one uart and it answers to /dev/ttymcx0. I am abit confused if it is not present in the documentation, also schematics show one uart: http://download.solid-run.com/pub/solidrun/HummingBoard/rev-3.0/HummingBoard-rev-3_0-schematics.pdf

 

On 5/5/2016 at 8:54 PM, zador.blood.stained said:

Initial output after start/reboot is from u-boot.

To use serial console as main for kernel messages and init progress, change

console=tty1

to

console=ttyS0,115200

in boot script and recompile it using command at the end of the file.

Hello,

I am having a problem using the uart and I guess it is related with this topic.

I am trying to make my Hummingboard to communicate via UART with a serial ublox GPS. I identified that the right device in armbian (5.34) is /dev/ttymxc0 since it echoes characters when I join tx/rx together.

When I connect the GPS it starts sending gps data normally, but when I have to reboot the hummingboard, it does not boot.

I connected a screen to the HDMI interface to see what was happening, and I get the screen message as if a key had been pressed in order to stop booting process, so the boot stops here and the hummingboard does not come up. When I disconnect the GPS power or the UART, the HB boots normally, and the gpsd gets the serial port. when the gpsd is closed, agetty takes the control of the uart and I cannot use it again until I reboot.

 

I concluded that the boot was configured to take the console keyboard from the UART, so I modified /boot/boot.cmd as suggested in this thread; I found the line:

 

if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttymxc0,115200"; fi

 

So I changed to 

 

if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "console=tty1"; fi

 

in order to avoid the boot to grab the ttymxc0 serial port. I recompiled the boot.cmd and rebooted, but the problem persists. The boot is still stopped due to an abnormal keypress.

 

I have no idea of how to make it work, since I have tried the procedure above and also explored the alternative of resetting via hardware the GPS during hummingboard boot, but it still stops the booting. The GPS will be permanently connected to the hummingboard, so I cannot disconnect it everytime I reboot. Do you have any ideas about what would be the problem? How to avoid the boot to depend on the uart?

 

I also checked the boot configuration built on the kernel:

 

cat /boot/config-4.13.12-cubox |grep ttymxc

 

and th result was:

CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"

 

Does this mean  that I have to recompile the kernel to solve it?

Thanks very much in advance

Regards

 

[Igor]

9 minutes ago, Gyver said:

Does this mean  that I have to recompile the kernel to solve it?

You need to recompile Device Tree Blob (DTB to DTS) and enable the second UART in a board configuration. Its not related to kernel recompilation or changes to boot scripts. If you want to make use of the first UART you will need to patch and recompile u-boot. Possible more complex.

In your device tree /boot/dtb/im6-hummingboard.dts ...  (convert to the source, edit and convert back) search for:

https://github.com/linux4kix/linux-linaro-stable-mx6/blob/linux-linaro-lsk-v3.14-mx6/arch/arm/boot/dts/imx6qdl.dtsi#L256-L265

and change status to:
 

status = "okay";

Reboot.

[Gyver]

I am getting a problem not being able to connect to serial uart on a Humming board base using armbian.

The ports available on devices are /dev/ttymcx0 and 3, so I tested looping back tx and rx of pins 8 and 10 of 26-pin header and tested echoed characters through minicom. The port corresponding to those pins is ttymcx0, and connecting my gps it seems to work, but after I reboot the board, booting stops, since it detects characters from the port coming from the gps and this stops booting process.

I previously posted this problem and I was told that I should look for another port, but there is not another port documented in the official solid run documents (https://www.solid-run.com/freescale-imx6-family/hummingboard/hummingboard-documentation-block-diagram/), so I would like to know if I can disable this behavior somehow in order to be able to use the serial uart, and to avoid to stop the booting process.

Thank you so much in advance.

Guido

Edited November 28, 2017 by zador.blood.stained
Moved here and locked the Lime2 thread

[Gyver]

On 11/27/2017 at 6:58 PM, Igor said:

You need to recompile Device Tree Blob (DTB to DTS) and enable the second UART in a board configuration. Its not related to kernel recompilation or changes to boot scripts. If you want to make use of the first UART you will need to patch and recompile u-boot. Possible more complex.

In your device tree /boot/dtb/im6-hummingboard.dts ...  (convert to the source, edit and convert back) search for:

https://github.com/linux4kix/linux-linaro-stable-mx6/blob/linux-linaro-lsk-v3.14-mx6/arch/arm/boot/dts/imx6qdl.dtsi#L256-L265

and change status to:
 

status = "okay";

Reboot.

I just checked the file and it is already in "okay", which i think means that it is enabled in device tree configuration, If I disable it in the dtb means that it will not be available for ubott, but also for linux system, right?

 

[Igor]

Just now, Gyver said:

If I disable it in the dtb means that it will not be available for ubott, but also for linux system, right?

Those settings are not related to u-boot.

[Gyver]

10 minutes ago, Igor said:

Those settings are not related to u-boot.

 

Please excuse me, I havent understood well what should I do in the dtb since it was already "okay". I just disabled it but the behavior is the same as before, it stops boot as a normal keyboard.

[Igor]

2 minutes ago, Gyver said:

since it was already "okay"

Then it should work. In a theory ... I have no other ideas ATM

[zador.blood.stained]

Looks like you are talking about different things. As it was said before, it's easier to use a different UART, not the debug one, than patching and recompiling the u-boot so it doesn't react to random key presses. Of course it will be enabled by default and editing DTB used by the kernel won't solve problems in u-boot. Another UART ports need to be activated in DT, where and how is another question - one has to read and understand the DT for this and possibly some other boards to find out.