Showing results for 
Show  only  | Search instead for 
Did you mean:
Registered: ‎10-28-2007

device-tree generator and 16550 uarts

Gidday there,


There appears to be a bug in the device-tree generator and how it generates the 'compatible' entries for the 16550 core.  I've just done an update from the xilinx git and the compatible line is listed as 16550 instead of 16550a.


This is important because in of_serial.c, if the compatible line is 16550 instead of 16550a, then the serial driver will not enable the FIFO.  This may not be noticed with a fast PPC405, but running a slow-microblaze you will begin to notice missed bytes very quickly.


This isn't a huge deal because I edit the .dts files by hand after they are generated by the DTS generator (e.g. adding SPI slaves) but perhaps whomever maintains the generator code may want to apply the following patch.



--- device-tree_v0_00_x/data/device-tree_v2_1_0.tcl	(revision 460)
+++ device-tree_v0_00_x/data/device-tree_v2_1_0.tcl	(working copy)
@@ -754,7 +754,7 @@
 			lappend alias_node_list [list serial$serial_count aliasref $name]
 			incr serial_count
-			set ip_tree [slaveip_intr $slave $intc [interrupt_list $slave] "serial" [default_parameters $slave] "" "" [list "ns16550"] ]
+			set ip_tree [slaveip_intr $slave $intc [interrupt_list $slave] "serial" [default_parameters $slave] "" "" [list "ns16550a"] ]
 			set ip_tree [tree_append $ip_tree [list "device_type" string "serial"]]
 			set ip_tree [tree_append $ip_tree [list "current-speed" int "9600"]]





0 Kudos
3 Replies
Registered: ‎10-05-2010

Hello Joshua,

interesting, we indeed missed some bytes when transmitting a large data amount to the microblaze.

We started investigating and I found out that the interrupts of the 16550 uart didn't show up in the proc dir:


# cat /proc/interrupts
  0:       3404     level Xilinx INTC  eth0
  1:       1281     level Xilinx INTC  eth0
  3:    3256236      edge Xilinx INTC  timer
  4:         87      edge Xilinx INTC  uartlite
  5:          0      edge Xilinx INTC  observer


However, it seems that the driver got the information from the dtb:


[    1.020000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    1.030000] 84000000.serial: ttyUL0 at MMIO 0x84000000 (irq = 4) is a uartlite
[    1.040000] console [ttyUL0] enabled
[    1.050000] 85000000.serial: ttyS0 at MMIO 0x85001003 (irq = 6) is a 16550

Do you have this behaviour as well?



0 Kudos
Registered: ‎10-28-2007

Gidday there,


I don't have the time right now to revert to my previous code, but I can give you the output of /proc/interrupts and dmesg after I changed compatible to "16550a".



$ cat /proc/interrupts 
 11:          0     level Xilinx INTC  xilinx_spi
 12:          0     level Xilinx INTC  xilinx_spi
 13:     478709     level Xilinx INTC  xilinx_spi
 15:          0     level Xilinx INTC  xilinx_spi
 16:          0     level Xilinx INTC  
 19:    1127668     level Xilinx INTC  timer
 20:      65883      edge Xilinx INTC  serial

 And dmesg for serial



$ dmesg |grep serial
[    7.630000] 90000000.serial: ttyS0 at MMIO 0x90001003 (irq = 20) is a 16550A
[    7.910000] 90100000.serial: ttyS1 at MMIO 0x90101003 (irq = 14) is a 16550A
[    7.930000] 90200000.serial: ttyS2 at MMIO 0x90201003 (irq = 2) is a 16550A
[    7.950000] 90300000.serial: ttyS3 at MMIO 0x90301003 (irq = 1) is a 16550A



So, it looks a little different from yours.




0 Kudos
Registered: ‎10-05-2010

Hello Joshua,

thanks for the post.

It looks that all instances of the uart core are on interrupt #20.

In your case I would expect the ints 1, 2 and 14 also in /proc/devices



0 Kudos