01-19-2011 10:18 AM
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"]]
01-19-2011 11:11 AM
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?
01-19-2011 12:14 PM
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 CPU0 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.
01-20-2011 02:47 AM
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