Tried with an alias for the ttyO4: alias char-major-248-4 xeno_16550A
But no reaction or error messages in dmesg, nor a change in driver link: lrwxrwxrwx 1 root root 0 Nov 12 13:41 /sys/dev/char/248:4/device/driver -> ../../../bus/platform/drivers/omap_uart Do the aliases require the kernel module to be included in the kernel or am I barking up the wrong tree? Please advice anyone... Regards Terje On Wednesday, November 12, 2014 2:34:51 PM UTC+1, Terje Froysa wrote: > > Hello again, > > While having problems with the command: > > setserial /dev/ttyOx usart none > > I started to look at /lib/modprobe.d/aliases.conf > > I wonder if it is possible to set the xeno_16550A as an alias to the major > number 248 (ttyOx): > > alias char-major-248-1 xeno_16550A > alias char-major-248-2 xeno_16550A > alias char-major-248-4 xeno_16550A > > Would this be a feasible solution for installing the xeno_16550A driver > instead of the omap_usart driver? > > Best regards > Terje > > > > ------------------------------------------------------------------ > > debian@beaglebone:/lib/modprobe.d$ more aliases.conf > > # These are the standard aliases for devices and kernel drivers. > > # This file does not need to be modified. > > # > > # No new aliases should be added to this file, please file a bug against > > # the kernel for any aliases which are still not built-in. > > : > > # character devices > ########################################################## > > alias char-major-10-1 psmouse > > : > > #alias char-major-240-* hsfserial > > #alias char-major-241-* hsfserial > > On Wednesday, November 12, 2014 1:21:06 PM UTC+1, Terje Froysa wrote: >> >> Hello Charles, >> >> I have now carefully checked your suggestions. >> >> >> - I have checked that the UART dtbo are loaded at boot-time (by >> uEnv.txt) >> - I have built (and booted) the kernel with the xeno_16550A as >> loadable module. >> - I have checked the functionality of the /dev/ttyOx by running >> physical loop-back data traffic. >> The sudo cat /proc/tty/driver/OMAP-SERIAL reports the correct amount >> of traffic and the sent data is echoed correctly in another terminal >> window. >> - I have crawled the /proc/device-tree/ocp/serial* and cannot find >> any discrepancies. >> >> Everything seem correct. >> But the UARTs are now occupied by the omap_serial driver. >> According to Xenomai (http://xenomai.org/serial-16550a-driver/) the >> driver should be disabled by the setserial command. >> I can't get this command working. It reports the serial port but changing >> it results in error (regardless of the ttyO -number): >> debian@beaglebone:~$ setserial /dev/ttyO2 >> /dev/ttyO2, UART: undefined, Port: 0x0000, IRQ: 74 >> >> debian@beaglebone:/boot$ sudo setserial /dev/ttyO2 uart none >> Cannot set serial info: *Invalid argument* >> Consequently, I cannot load the xeno_16550A.ko module. >> I have browsed the net for the same problem, but have not found relevant >> subjects. >> There are no shared irq's in my problem (closest subject I found). >> >> Do you have any idea for a solution? >> >> Best regards >> Terje Froysa >> >> >> >> On Tuesday, November 11, 2014 3:59:51 PM UTC+1, Charles Steinkuehler >> wrote: >>> >>> On 11/11/2014 8:42 AM, Terje Froysa wrote: >>> > >>> > >>> > Dear forum, >>> > >>> > I have struggled for 4 days and I am out of ideas/suggestions on how >>> to >>> > make this xeno_16550A driver work. >>> > 1. I have successfully installed the Xenomai 2.6.4 and the Debian >>> 3.8.13. >>> > 2. Self-developed RTDM driver is working satisfactory. >>> > 3. But when irq numbers are defined for the kernel installed >>> xeno_16550A >>> > driver the boot process crashes (attached log). >>> > >>> > >>> > Questions from Xenomai forum is: >>> > >>> > >>> > 1. The xeno_16550A driver uses byte access, have you checked the >>> AM33xx >>> > TRM to check that this is valid? >>> > 2. Is the interface clock for the serial device you want to use >>> enabled? >>> > >>> > From the TRM it seems that the 16550 compliant UART accommodates byte >>> > accesses. >>> > >>> > When installing and removing serial port drivers I can't see any >>> associated >>> > clock enabling options in the menuconfig. >>> >>> I haven't tried getting the UARTs working with Xenomai, but have some >>> general suggestions if you haven't tried them already, mostly focused on >>> making sure the UART is actually enabled in the device-tree: >>> >>> * Do you have the UART enabled in the default device-tree being loaded >>> by U-Boot? This should setup the clocks and other house-keeping >>> required to make the UART actually work at the hardware level. >>> >>> * Can you build the Xenomai driver as a loadable module and try to load >>> it after the system boots? If so, this will make it much easier to test >>> variations on the running system. >>> >>> * Have you tried booting without the Xenomai serial module enabled and >>> talking directly to the memory region used by the UART (via mmap() of >>> /dev/mem or similar)? This could help you get your device tree properly >>> setup so you know the UART is enabled before trying to boot the kernel >>> with the serial driver enabled. >>> >>> * If it's a device-tree problem, you can boot with a working kernel and >>> crawl through the live device-tree (via /proc/device-tree/ocp/serial*/) >>> and make sure everything is as you expect. >>> >>> -- >>> Charles Steinkuehler >>> cha...@steinkuehler.net >>> >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
