cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
johank
Observer
Observer
505 Views
Registered: ‎09-02-2018

Uart_16550 IP not showing up in Petalinux

Jump to solution

Hello,

 

I'm running Petalinux on a Zynq. In the PL, I have five UartLite-IP's running. This is all working fine, they are all recognized by Petalinux and I'm able to use them as a UART/serial port. Because of flexibility-reasons, they need to be changed to Uart_16550's. I've changed one (to test) and found out that it's not recognized by Petalinux; it's not showing up while booting and it's not showing up in the filesystem.

What I did:

  • Added IP to block design, configured the correct AXI-clock-speed. Connected S_AXI to AXI-Interconnect, connected axi_clk, axi_reset, connected I/O (rx, tx, etc)
  • Connected interrupt to PS via concat; interrupt is shared with other IP's.
  • (auto)configured address
  • Run bitstream, exported design
  • Imported design in Petalinux, built new image

 

The Petalinux-config seems to have recognized the UART:

		axi_uart16550_0: serial@43c10000 {
			clock-frequency = < 50000000>;
			clock-names = "s_axi_aclk";
			clocks = <&clkc 15>;
			compatible = "xlnx,xps-uart16550-2.00.a", "ns16550a";
			current-speed = <115200>;
			device_type = "serial";
			interrupt-names = "ip2intc_irpt";
			interrupt-parent = <&intc>;
			interrupts = <0 31 4>;
			port-number = <1>;
			reg = <0x43c10000 0x10000>;
			reg-offset = <0x1000>;
			reg-shift = <2>;
			xlnx,external-xin-clk-hz = <0x17d7840>;
			xlnx,external-xin-clk-hz-d = <0x19>;
			xlnx,has-external-rclk = <0x0>;
			xlnx,has-external-xin = <0x0>;
			xlnx,is-a-16550 = <0x1>;
			xlnx,s-axi-aclk-freq-hz-d = "50.0";
			xlnx,use-modem-ports = <0x1>;
			xlnx,use-user-ports = <0x1>;
		};

 

According to various posts on this forum, some additional kernel-settings are needed:

CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=16
CONFIG_SERIAL_UARTLITE=y
CONFIG_SERIAL_UARTLITE_NR_UARTS=16
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y

 

I've also manually added some parts to the device-tree:

&axi_uart16550_0 {
	status = "okay";
	port-number = <1>;
	current-speed = <57600>;
	xlnx,use-modem-ports = <0x0>;
	xlnx,use-user-ports = <0x0>;
};

 

Relevant parts of the log while booting:

Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
42c00000.serial: ttyUL2 at MMIO 0x42c00000 (irq = 57, base_baud = 0) is a uartlite
42c10000.serial: ttyUL3 at MMIO 0x42c10000 (irq = 58, base_baud = 0) is a uartlite
42c30000.serial: ttyUL4 at MMIO 0x42c30000 (irq = 59, base_baud = 0) is a uartlite
42c40000.serial: ttyUL5 at MMIO 0x42c40000 (irq = 60, base_baud = 0) is a uartlite

 

It simply never shows up, whatever I do. I can change the kernel-config, I can add or remove or change things to the device-tree, I've tried a lot of combinations; it just never shows. 

Because of automated builds, we're running on Petalinux 2019.1. FPGA-design is made with Vivado 2019.1.
Probably because I'm missing something very obvious, I just can't figure out what. Would someone be able to point me in the right direction?

 

Thank you very much!

Johan

0 Kudos
Reply
1 Solution

Accepted Solutions
johank
Observer
Observer
209 Views
Registered: ‎09-02-2018

Thank you for your suggestion, it was a good idea to go "back to the basics".

 

However, this didn't solved our problem. What did solve our problem was a change in the kernel-configuration; the option "Devicetree based probing for 8250 ports" needs to be enabled. In retrospective, this makes very much sense, it only took us a while to figure out that this option needed to be enabled. In fact, shouldn't this be enabled by default? Since the only way to add 8250-ports to the system is via the devicetree.

Our (working) kernel-configuration (petalinux-config -c kernel) is like this:

johank_0-1611312734544.png

and right now, it's working in both Petalinux 2020.2 with a minimal design and Petalinux 2019.1 with the original design. Handshake connected or left open has no effect. We've been able to replace all the uart-lite blocks with UART16550 blocks and it's all working fine.

Apparently, configuring this line switches on the "CONFIG_SERIAL_OF_PLATFORM"-option. We've enabled this option by hand as shown in the first post, but this line apparently has dependencies which were not enabled by us.

 

The only question remains is weather we should have read this somewhere? As far as we could find, there is no documentation that covers this.

 

Thank you all for your support and your assistance!

View solution in original post

9 Replies
johank
Observer
Observer
395 Views
Registered: ‎09-02-2018

Does anyone have the slightest idea what we're missing? Since this is still not resolved.

 

Thank you so much!

 

Kind regards,

Johan

0 Kudos
Reply
hokim
Scholar
Scholar
377 Views
Registered: ‎10-21-2015

Hi

Have you checked  whether /dev/ttyS* is working?

The default kernel has /dev/ttyS0~S3.

They are fake ports without hw.

When you use uart16650 ip, one of them becomes mapped to real hw.

0 Kudos
Reply
johank
Observer
Observer
371 Views
Registered: ‎09-02-2018

Hello,

 

Thank you for your reply!

I've checked /dev/ttyS0~3. When I try to read or write any of them; I'll get:

error: Input/output error

 

However, is it the case that uart16650-IP-UARTs are getting attached to the kernel without any notice? That would explain the lack of kernel-messages.

 

Thank you!

0 Kudos
Reply
vanmierlo
Mentor
Mentor
368 Views
Registered: ‎06-10-2008

What you have looks pretty ok. You can add an alias to locate the 16550 to a ttySn:

 

        aliases {
                serial1 = &axi_uart16550_0;
        };

 

This will place the 16550 at /dev/ttyS1.

Note how you cannot use the serial0 alias as it is required for /dev/ttyPS0, the PS UART0.

Further, how are the handshakes connected? And have you tried to open the port with hardware handshaking disabled? Are you using minicom or microcom or something else? Busybox microcom just fails with inactive handshakes.

A normal startup message should show something like:

Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
43c10000.serial: ttyS1 at MMIO 0x43c11000 (irq = 47, base_baud = 6250000) is a 16550A
42c00000.serial: ttyUL2 at MMIO 0x42c00000 (irq = 57, base_baud = 0) is a uartlite

 

0 Kudos
Reply
johank
Observer
Observer
355 Views
Registered: ‎09-02-2018

I've added the alias. This seems to change nothing though.

I have not connected any handshakes.

When I'm simply doing:

echo "12345679" > /dev/ttyS1

I get this "Input/output error".

When using Minicom with flow-control off, I don't get any output on the serial port (verified with oscilloscope..)

 

Thank you all for assisting!

0 Kudos
Reply
johank
Observer
Observer
262 Views
Registered: ‎09-02-2018

Hello all,

We're still struggling with this issue. With all the tips in this topic and on other pages we've found on the internet, we cannot get this to work in our PetaLinux, so we've decided to run some tests in a new build of Petalinux, based on the latest version (v2020.2). We've generated a new bitstream with Vivado 2020.2, and compiled a new Petalinux. Bootimage is generated with the Petalinux v2020.2-generated FSBL, u-boot and the Vivado-2020.2-generated bitstream.

We have exactly the same problem with this build, which leads us to suspect that there's really an issue with our FPGA-design.

For clarity, I've added a snippet of the design:

vivado.jpg

As shown, the interrupt from the uart-IP is connected to the PS via a concat. The AXI-bus is connected to the interconnect. aclk and aresetn are connected. Freeze is left open, but this is connected to a logical zero in the wrapper-file. Only sin and sout are connected, no handshake-signals are connected.

The uart_16550 appears on various places in the Petalinux configuration menu's. It also appears in the devicetree, exactly the same as when we import our hardware into Petalinux 2019.1. As far as we know, the config-files have been adjusted so that these ports and the drivers are enabled. 

 

It should be very straight-forward to have this UART16650 as a tty in Linux, which tends us to believe that we're missing something obvious. Can someone spot our (hopefully obvious) mistake and point as towards a solution?

 

Thank you!

0 Kudos
Reply
vanmierlo
Mentor
Mentor
253 Views
Registered: ‎06-10-2008

Have you tried tying off the unused modem status inputs to a constant?

Have you tried to build a minimal system?Minimal Zynq 16550.png

0 Kudos
Reply
johank
Observer
Observer
210 Views
Registered: ‎09-02-2018

Thank you for your suggestion, it was a good idea to go "back to the basics".

 

However, this didn't solved our problem. What did solve our problem was a change in the kernel-configuration; the option "Devicetree based probing for 8250 ports" needs to be enabled. In retrospective, this makes very much sense, it only took us a while to figure out that this option needed to be enabled. In fact, shouldn't this be enabled by default? Since the only way to add 8250-ports to the system is via the devicetree.

Our (working) kernel-configuration (petalinux-config -c kernel) is like this:

johank_0-1611312734544.png

and right now, it's working in both Petalinux 2020.2 with a minimal design and Petalinux 2019.1 with the original design. Handshake connected or left open has no effect. We've been able to replace all the uart-lite blocks with UART16550 blocks and it's all working fine.

Apparently, configuring this line switches on the "CONFIG_SERIAL_OF_PLATFORM"-option. We've enabled this option by hand as shown in the first post, but this line apparently has dependencies which were not enabled by us.

 

The only question remains is weather we should have read this somewhere? As far as we could find, there is no documentation that covers this.

 

Thank you all for your support and your assistance!

View solution in original post

vanmierlo
Mentor
Mentor
198 Views
Registered: ‎06-10-2008

Thanks for the update. You can mark your own reply as being the solution, because you actually gave the solution yourself. Good job!

0 Kudos
Reply