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_16540A alias char-major-248-2 xeno_16540A alias char-major-248-4 xeno_16540A 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 >> [email protected] >> > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
