Ok Charles,

It doesn't seem very promising this comment from Gilles:

I just had a quick look at the omap-serial.c driver and:

- it does not do anything that I can see to enable its clocks
- it does NOT  use byte access but word access, that is, its registers are 
16 bits wide.

Unfortunately, as far as I can tell, the xeno_16550A driver only supports 
byte access. So, if you want it to work, you have to modify the driver to 
accept a "regshift" parameter applied to all offsets and use the 
corresponding readw if regshift is 2 or readl if regshift is 4.


On Wednesday, November 12, 2014 3:52:19 PM UTC+1, Charles Steinkuehler 
wrote:
>
> Gilles' 3rd option is what I was referring to trying. 
>
> The other two options seem workable as well.  The best choice depends on 
> what you're more comfortable working with. 
>
> On 11/12/2014 8:41 AM, Terje Froysa wrote: 
> > Thanks Charles, 
> > 
> > I appreciate your ideas. 
> > I seem stuck "between a rock and a hard place" with very little 
> substantial 
> > experiences to collect from the communities. 
> > 
> > I will try a couple of permutations more before I may revert to using 
> the 
> > standard Linux drivers. 
> > 
> > I also got some comments from Xenomai (Gilles Chanteperdrix) below. 
> > 
> > Regards 
> > Terje Froysa 
> > 
> > 
> > At first sight, I would say that the omap_serial driver does not 
> implement 
> > the necessary support (probably some ioctls), for what setserial is 
> trying 
> > to do. 
> > 
> >  I see several ways out: 
> > 
> > - implement the missing support in omap serial so that you can use the 
> > "setserial none" command; 
> > 
> > - try and use the 8250 driver instead of the omap_serial driver, since 
> the 
> > omap serial devices are 8250 compatible, this driver supports the 
> necessary 
> > ioctls for the "setserial none" command to work. At some point in time, 
> I 
> > know using this serial driver for the kernel console worked, but I do 
> not 
> > know if it was by chance (u-boot enables the clock, so the driver does 
> not 
> > have to enable it), and if it still works; 
> > 
> > - do not enable any uart in the kernel configuration, neither 
> omap_serial, 
> > nor 8250, and arrange for the clocks to be started before loading the 
> > xeno_16550a driver. 
> > 
> > On Wednesday, November 12, 2014 3:28:52 PM UTC+1, Charles Steinkuehler 
> > wrote: 
> >> 
> >> On 11/12/2014 6:21 AM, Terje Froysa wrote: 
> >>>     
> >>> 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? 
> >> 
> >> I _think_ the problem may be that if you don't enable the serial port 
> in 
> >> the device-tree than Xenomai encounters a bus error when accessing the 
> >> address range (not entirely unexpected, since the UART's clock is 
> >> probably turned off).  But if you enable the UART in the device tree, 
> >> Linux takes control of the port and Xenomai can't access it. 
> >> 
> >> Other than asking for advice on the Xenomai list, you might try booting 
> >> with the Xenomai kernel and a device tree that _disables_ the UART 
> >> you're trying to use.  I would expect trying to load the xeno_16550A 
> >> module to fail (as it does when you boot the kernel with the module 
> >> enabled), but you should be able to manually setup the required 
> >> low-level hardware configuration at which point you ought to be able to 
> >> load the driver. 
> >> 
> >> Or in other words, I think you need to perform the hardware setup from 
> >> the TI UART driver prior to loading the Xenomai serial driver. 
> >> 
> >> -- 
> >> Charles Steinkuehler 
> >> [email protected] <javascript:> 
> >> 
> > 
>
>
> -- 
> Charles Steinkuehler 
> [email protected] <javascript:> 
>

-- 
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.

Reply via email to