UART1 (/dev/ttyS1) on DE0-nano-SoC does not work

Hi! This is another question from a newbie.

HPS in DE0-nano-SoC has 2 UARTs. First of them (UART0) is used for console (ttyS0) via USB.
I want to use second UART (UART1) for data transfer from Linux (Debian wheezy armhf).
I used Linux 4.3

My first test was to open /dev/ttyS0 via ssh. (stty -F /dev/ttyS0)
Device was successfully opened and keystrokes successfully transmitted to the serial terminal

But I was unable to open /dev/ttyS1 (stty -F /dev/ttyS1) with error

stty: /dev/ttyS1: input/output error

In /proc/tty/driver/serial I have:

serinfo:1.0 driver revision:
0: uart:16550A mmio:0xFFC02000 irq:35 tx:10401 rx:724 RTS|DTR
1: uart:unknown mmio:0xFFC03000 irq:36

Output of Linux starting:

Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[0.204597] ffc02000.serial0: ttyS0 at MMIO 0xffc02000 (irq = 35, base_baud = 6250000) is a 16550A

but no information about ttyS1.

Its seems that ttyS1 is not connected to UART1.

Same problem is in system image from official terasic site
But in Linux image from rocketboards /dev/ttyS1 works well!

How can I activate /dev/ttyS1?

Thanks. Sorry for my english

hi!!
take a look at the device tree and hps.xml(qsys files) in your altera project!

if (cat proc/device-tree/soc/serial1@ffc03000/status = disable) then
change your device tree src file and enable uart1
else
if (uart1 = disable (in hps.xml > altera project)) then
change the qsys project and enable uart1(under hps/periph) with the right pinning
else
???
end if;
end if;

:smiley:

So!! check your fpga project and your device tree!!!
bye

Enable the UART1 from the Qsys tool for your HPS. And then the regular steps of preloader and Device tree generation, should let you use the UART1.

Hi Murillo,

I have done the same and enabled UART1. I am accessing this throught the HPS using a Linux application. I am able to use ‘open’ on ‘/dev/ttyS1’. However, any write to the UART1(Tx and Rx mapped to GPIO_0 pins), does not produce any output at the pins. Do yo have any idea on this?

I have also tried accessing the UART1 directly via terminal using the following command
update : echo 0xFF < /dev/ttyS1

However, there seems to be no change in signal on the GPIO pins mapped to UART:

After some substantial headaches with that issue I found that I was not able to generate a sufficent device tree using

sopc2dts --input quartus/soc_system.sopcinfo
–board DE0_NANO_SOC_GHRD/soc_system_board_info.xml
–board DE0_NANO_SOC_GHRD/hps_common_board_info.xml
–bridge-removal all
–type dts
–clocks
–output socfpga.dts

I had to use the DeviceTreeCompiler from the Linux Kernel and the target
make socfpga_cyclone5_de0_nano_soc.dtb

I had to patch the …dts first

aliases {
	ethernet0 = &gmac1;
            serial0   = &uart0;
            serial1   = &uart1;
};

&uart0 {
status = “okay”;
};

&uart1 {
status = “okay”;
};

I am not sure why the other approach with sopc2dts does not work.

So after that I got the tx-side of UART1 running, rx side didn’t .
After reading a lot of stuff I found one possible problem:
The pin-muxing has to be set in the HPS, meaning of you go via FPGA fabric and route the RX TX lines to GPIOs, the tx is line is always connected as the HPS UART1 TX is anyway always there and doesn’t need to be muxed.
For the RX as input, story is different: It must be configured properly and this is done by u-boot and the preload.
After I generated the preloader with bsp editor again I found u-boot pin muxing not updated.
This means initially RX is not switched to FPGA. It appears you need to do this manually.

To verify, grep in Linux for USEFPGA,
find . -type f | xargs grep USEFPGA |grep UART
./soc_system/synthesis/submodules/hps.pre.xml: <pin_mux name=‘UART0USEFPGA’ value=‘0’ />
./soc_system/synthesis/submodules/hps.pre.xml: <pin_mux name=‘UART1USEFPGA’ value=‘1’ />
./generated/pinmux_config_cyclone5.c: 0, /* UART0USEFPGA /
./generated/pinmux_config_cyclone5.c: 1, /
UART1USEFPGA /
./hps_isw_handoff/soc_system_hps_0/hps.xml: <pin_mux name=‘UART0USEFPGA’ value=‘0’ />
./hps_isw_handoff/soc_system_hps_0/hps.xml: <pin_mux name=‘UART1USEFPGA’ value=‘1’ />
./software/spl_bsp/generated/pinmux_config_cyclone5.c: 0, /
UART0USEFPGA /
./software/spl_bsp/generated/pinmux_config_cyclone5.c: 1, /
UART1USEFPGA /
./software/spl_bsp/uboot-socfpga/board/altera/socfpga/pinmux_config_cyclone5.c:0, /
UART0USEFPGA /
./software/spl_bsp/uboot-socfpga/board/altera/socfpga/pinmux_config_cyclone5.c:0, /
UART1USEFPGA /
./software/spl_bsp/uboot-socfpga/board/altera/socfpga/pinmux_config_arria5.c: 0, /
UART0USEFPGA /
./software/spl_bsp/uboot-socfpga/board/altera/socfpga/pinmux_config_arria5.c: 0, /
UART1USEFPGA */

So you need hand-off and soc_system files for the procedure to work.
u-boot files will be updated only after the preloader was generated !

find . -type f | xargs grep USEFPGA |grep UART
./generated/pinmux_config_cyclone5.c: 0, /* UART0USEFPGA /
./generated/pinmux_config_cyclone5.c: 1, /
UART1USEFPGA /
./uboot-socfpga/board/altera/socfpga/pinmux_config_cyclone5.c: 0, /
UART0USEFPGA /
./uboot-socfpga/board/altera/socfpga/pinmux_config_cyclone5.c: 1, /
UART1USEFPGA /
./uboot-socfpga/board/altera/socfpga/pinmux_config_arria5.c: 0, /
UART0USEFPGA /
./uboot-socfpga/board/altera/socfpga/pinmux_config_arria5.c: 0, /
UART1USEFPGA */

I hope it will save other people some time for debugging as I wasn’t aware of the dependencies.