Qsys UART IP core not binding at boot despite being in DTS and Driver Module Running

I have instantiated an avalon UART IP core (not the jtag UART) in my qsys design. After generating the HDL, and then recreating a DTS/DTB file I am unable to see device binding occur on system boot.

I have verified that the .DTS file does in fact contain the information for the UART. specifically:

		uart_0: serial@0x1000100e0 {
			compatible = "altr,uart-15.0", "altr,uart-1.0";
			reg = <0x00000001 0x000100e0 0x00000020>;
			interrupt-parent = <&HPS_Wrapper_hps_0_arm_gic_0>;
			interrupts = <0 49 4>;
			clocks = <&lw_h2f_clk_source>;
			clock-frequency = <75000000>;	/* embeddedsw.dts.params.clock-frequency type NUMBER */
			current-speed = <9600>;	/* embeddedsw.dts.params.current-speed type NUMBER */
		}; //end serial@0x1000100e0 (uart_0)

I have also confirmed that this is shown in the /device-tree folder on the target’s filesystem so I am reasonably confident that the DTB is being parsed correctly. I know the UART is working because I can do a manual read/write to its registers and see the status / data registers change in ways that make sense for how its being used.

I took a look at altera’s UART driver source file next. the name in the “compatible” field of the dts for the UART matches what the driver source file is looking for. I would expect that if binding worked , that a ttyAL0 would appear in /dev. However it did not, so next i verified that that the module is running.

Turns out that it wasn’t (verified by lsmod -l). I discovered that it wasn’t enabled in the kernel, so i rebuild the kernel, being sure to enable the UART. I am able to see that the driver is running (again, by lsmod -l) after this change. At this point rebooting should have fixed things but alas no luck.

Thinking it might be an issue with my particular modified kernel or FPGA design, I then grabbed the GHRD and added the same UART IP component and regenerate HDL from Qsys, then regenerate the dts/dtb. I also rebuild the stock kernel (making sure to enable the uart again) and still do not see driver successfully binding.

I’ve dug into the ePAPR spec, as well as several device tree tutorials. The Altera generated dts does not have a “enabled” status which seems a bit unexpected. However in my .dts file, some of them do and some do not so I don’t think this is the problem.

There are some debugging tools (dtdiff, dt_node_info, etc) which look promising but are reported to not work with kernel versions less than v3.17. Since my kernel is older than that, i have cannot debug this issue further using those experimental tools.

I can’t possibly be the first person to try to instantiate a UART in qsys that binds properly to a kernel driver module. I’ve I’m hoping to avoid having to write my own kernel driver for a plain old UART. Do I need to “create” the ttyAL0 file manually before this will bind? I attempted this using “mknod /dev/ttyAL0 c 204 213” and then attempted a “echo test > /dev/ttyAL0” command but get an error: “can’t create /dev/ttyAL0: No such device or address”.

Am I missing a critical step here in the build process?

I found a similar topic in the forums from a search but there hasn’t been any follow up posts on whether or not the person was able to figure out their problem.

I’ve exhausted all paths I can think of and so hoping that one of my fellow rocketboards developers can offer some insight here. FWIW, I am using a kernel version 3.10 and quartus II / SoC EDS tool version 15.0.


Try posting this question on the mailing list.

There are some useful tips in this video about solving DTS/driver binding problems. Starting from about 1h 6’ 0"

I have already read his slides, but have not seen this video - thanks for that link. the debugging info used in the presentation requires use of newer (>3.17) kernel. So as useful as the information in this presentation is, it does not help my particular case since I cannot use dt_node_info or other utilities. It would seem that I might have to just file a SR with altera on this one since I’m at a dead end.