On 05/27/2010 03:22 AM, Everett Wang wrote: > On Wed, May 26, 2010 at 1:38 PM, Wolfgang Grandegger <[email protected]> > wrote: >> On 05/25/2010 03:47 PM, Everett Wang wrote: >>> On Mon, May 24, 2010 at 11:45 PM, Wolfgang Grandegger <[email protected]> >>> wrote: >>>> On 05/24/2010 09:32 AM, Everett Wang wrote: >>>>> On Mon, May 24, 2010 at 7:36 AM, Everett Wang <[email protected]> wrote: >>>>>> On Mon, May 24, 2010 at 12:28 AM, Wolfgang Grandegger >>>>>> <[email protected]> wrote: >>>>>>> On 05/23/2010 06:19 PM, Everett Wang wrote: >>>>>>>> On Sun, May 23, 2010 at 11:46 PM, Wolfgang Grandegger >>>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>>>> There are other possibilities to interact with Linux, e.g. telnet, >>>>>>>>> slogin or netcat. But it's always good to have a console. >>>>>>>>> >>>>>>>> I guess I need a USB to ethernet for these. >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>> ... >>>>>>>>> All three uarts are occupied by Linux and you cannot use them as >>>>>>>>> rtserial. First you need to release at least one of them. What Linux >>>>>>>>> config do you use for your board? >>>>>>>> >>>>>>>> I didn't do any configuration. Do you mean to config these during >>>>>>>> kernel >>>>>>>> configuration? >>>>>>> >>>>>>> Can you show us the .config of your kernel? >>>>>>> >>>>>>> Some more insights: >>>>>>> >>>>>>> I think the serial ports for the beagle boards are configured in: >>>>>>> >>>>>>> http://lxr.linux.no/#linux+v2.6.34/arch/arm/mach-omap2/serial.c >>>>>>> >>>>>>> Therein you find entries like: >>>>>>> >>>>>>> http://lxr.linux.no/#linux+v2.6.34/arch/arm/mach-omap2/serial.c#L82 >>>>>>> >>>>>>> As you can see, a regshift of 2 is used, which is not yet supported by >>>>>>> the 16550A RTDM driver. Should not be a big deal to add it, though. >>>>>>> Also, as "baud_base" you should use OMAP24XX_BASE_BAUD. >>>>>>> >>>>>>> Wolfgang. >>>>>>> >>>>>> >>>>>> Thanks for the suggestions. The .config file is attached. I will look at >>>>>> the >>>>>> code you pointed to today to study the configuration of the serial port. >>>>>> >>>>>> Everett >>>>>> >>>>> >>>>> Hi Wolfgang, >>>>> >>>>> I looked at the serial.c and function you pointed too. I have can't figure >>>>> out how to modify it. Could you point me to the right direction to read so >>>>> I can understand and eventually improve the serial for beagleboard? I >>>>> thought >>>>> I could limit the kernel to use only one of the uart (console) by >>>>> changing function >>>>> __init omap_serial_init(void): >>>>> >>>>> void __init omap_serial_init(void) >>>>> { >>>>> int i; >>>>> >>>>> // for (i = 0; i < ARRAY_SIZE(omap_uart); i++) >>>>> // omap_serial_init_port(i); >>>>> omap_serial_init_port(2); >>>>> } >>>>> >>>>> But the kernel hangs during booting after printing this message: >>>>> >>>>> uncompressing Linux... done. >>>>> >>>>> I guess it is not that simple to let kernel not to claim the uart0 and >>>>> uart1. >>>> >>>> Yes, unfortunately. I would try to comment out the uarts you want to >>>> use for rtser in the following struct: >>>> >>>> http://lxr.linux.no/#linux+v2.6.34/arch/arm/mach-omap2/serial.c#L562 >>>> >>>> Maybe the better option is to download setserial from >>>> >>>> http://sourceforge.net/projects/setserial/files/setserial/2.17/setserial-2.17.tar.gz/download >>>> >>>> and cross-compile it for your target. Then try: >>>> >>>> # setserial /dev/ttyS2 uart none >>>> >>>> Wolfgang. >>>> >>>> >>> >>> Hi Wolfgang, >>> >>> Thanks, >>> >>> I took the easiest way by >>> opkg install setserial >>> >>> The setserial got installed into my flash. I then >>> >>> # setserial /dev/ttyS0 uart none >>> Linux has no complain. dmesg | tail doesn't show anything >>> >>> Finally I did this: >>> # setserial /dev/ttyS2 uart none >>> Linux reports "Can't set serial info: Device or resource busy". The >>> uart3 is used by console login. >>> And my console login still works, >>> >>> I guess I still don't have a clear direction what to do next. What are >>> needed to make the uart >>> to work with xenomai? I also want to make SPI to work with xenomai. Is >>> that even harder to >>> do? >> >> Next I would try to load the xeno_16550a.ko as described earlier. Then >> you need to fix the register access by introducing a proper regshift, at >> least. I can't tell if other fixups are necessary but if you are lucky >> it will already work. And yes, implementing a RTDM SPI driver is even >> harder, unfortunately. >> >> Wolfgang. >> > > Hi Wolfgang, > > Thanks for your information. I am still interested in doing work on both > xeno_16550a.ko and RTDM SPI. Could you give me an overview of > what kind of knowledge is required, and where I can find more information > about them? Right now I feel I don't have a clear understanding to > modify the code.
I already explained what I would do to get the xeno_16550a.ko working on your hardware (see above). Concerning a RTDM SPI driver, there has been some discussion on this topic recently. You can find further information in t he following thread (see also follow-up mail): https://mail.gna.org/public/xenomai-help/2010-04/msg00084.html The doc for the RTDM driver interface is here: http://www.xenomai.org/documentation/trunk/html/api/index.html Wolfgang. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
