[Xenomai] 16550 serial driver on Beaglebone Black

[Xenomai] 16550 serial driver on Beaglebone Black

[Steve B]

Hello all,
Was there ever a resolution to running the 16550 driver on Beaglebone
Black? I see that there was a discussion on this in November but I don't
see anything saying that somebody got it to work.

Thanks,

Steve

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Steve B]

Hello Gilles,
I tried your patch to 16550A_io.h from the discussion with Terje Frosya in
November and I believe I can see why it didn't work.

I added a couple of printk statements to verify that the driver is reading
and writing to the intended addresses, and here's what I got:

[   40.594119] xeno_16550A: Init IO at address 0x481AA000
[   40.594159] xeno_16550A: Writing: FA1AA004. Regwidth 2 Regshift 2
[   40.594169] xeno_16550A: Reading: FA1AA008. Regwidth 2 Regshift 2
[   40.594183] Unhandled fault: external abort on non-linefetch (0x1028) at
0xfa1aa008

It looks like the regshift is operating on the most significant byte of the
base address rather than the least significant! Perhaps it's something to
do with the endianness, but I still haven't wrapped my brain around why. Of
course it makes sense that you are getting a segfault because the code is
trying to read/write entirely the wrong address.

Any thoughts?

PS, Terje I think I saw on a Google Groups thread elsewhere that you had
given up on this and found a different solution, but I am including you on
this in case you may be curious about it.

Thanks,

Steve


On Wed, Feb 11, 2015 at 8:02 PM, Steve B <sbattazzo@gmail.com> wrote:

> Hello all,
> Was there ever a resolution to running the 16550 driver on Beaglebone
> Black? I see that there was a discussion on this in November but I don't
> see anything saying that somebody got it to work.
>
> Thanks,
>
> Steve
>

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Steve B]

Nevermind, the shift looks OK, I guess that the 0xFA in the uppermost byte
of the address is because of the ioremap call?

Steve

On Thu, Feb 12, 2015 at 4:51 PM, Steve B <sbattazzo@gmail.com> wrote:

> Hello Gilles,
> I tried your patch to 16550A_io.h from the discussion with Terje Frosya in
> November and I believe I can see why it didn't work.
>
> I added a couple of printk statements to verify that the driver is reading
> and writing to the intended addresses, and here's what I got:
>
> [   40.594119] xeno_16550A: Init IO at address 0x481AA000
> [   40.594159] xeno_16550A: Writing: FA1AA004. Regwidth 2 Regshift 2
> [   40.594169] xeno_16550A: Reading: FA1AA008. Regwidth 2 Regshift 2
> [   40.594183] Unhandled fault: external abort on non-linefetch (0x1028)
> at 0xfa1aa008
>
> It looks like the regshift is operating on the most significant byte of
> the base address rather than the least significant! Perhaps it's something
> to do with the endianness, but I still haven't wrapped my brain around why.
> Of course it makes sense that you are getting a segfault because the code
> is trying to read/write entirely the wrong address.
>
> Any thoughts?
>
> PS, Terje I think I saw on a Google Groups thread elsewhere that you had
> given up on this and found a different solution, but I am including you on
> this in case you may be curious about it.
>
> Thanks,
>
> Steve
>
>
> On Wed, Feb 11, 2015 at 8:02 PM, Steve B <sbattazzo@gmail.com> wrote:
>
>> Hello all,
>> Was there ever a resolution to running the 16550 driver on Beaglebone
>> Black? I see that there was a discussion on this in November but I don't
>> see anything saying that somebody got it to work.
>>
>> Thanks,
>>
>> Steve
>>
>
>

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Steve B]

On Thu, Feb 12, 2015 at 5:03 PM, Steve B <sbattazzo@gmail.com> wrote:

> Nevermind, the shift looks OK, I guess that the 0xFA in the uppermost byte
> of the address is because of the ioremap call?
>
> Steve
>
> On Thu, Feb 12, 2015 at 4:51 PM, Steve B <sbattazzo@gmail.com> wrote:
>
>> Hello Gilles,
>> I tried your patch to 16550A_io.h from the discussion with Terje Frosya
>> in November and I believe I can see why it didn't work.
>>
>> I added a couple of printk statements to verify that the driver is
>> reading and writing to the intended addresses, and here's what I got:
>>
>> [   40.594119] xeno_16550A: Init IO at address 0x481AA000
>> [   40.594159] xeno_16550A: Writing: FA1AA004. Regwidth 2 Regshift 2
>> [   40.594169] xeno_16550A: Reading: FA1AA008. Regwidth 2 Regshift 2
>> [   40.594183] Unhandled fault: external abort on non-linefetch (0x1028)
>> at 0xfa1aa008
>>
>> It looks like the regshift is operating on the most significant byte of
>> the base address rather than the least significant! Perhaps it's something
>> to do with the endianness, but I still haven't wrapped my brain around why.
>> Of course it makes sense that you are getting a segfault because the code
>> is trying to read/write entirely the wrong address.
>>
>> Any thoughts?
>>
>> PS, Terje I think I saw on a Google Groups thread elsewhere that you had
>> given up on this and found a different solution, but I am including you on
>> this in case you may be curious about it.
>>
>> Thanks,
>>
>> Steve
>>
>>
>> On Wed, Feb 11, 2015 at 8:02 PM, Steve B <sbattazzo@gmail.com> wrote:
>>
>>> Hello all,
>>> Was there ever a resolution to running the 16550 driver on Beaglebone
>>> Black? I see that there was a discussion on this in November but I don't
>>> see anything saying that somebody got it to work.
>>>
>>> Thanks,
>>>
>>> Steve
>>>
>>
>>
>
Hello again,
I was not able to run a C program to directly set the one register that
needs to be set to turn on the UART clock, but I was able to get
xeno_16550A to load by sort of tricking the OS into enabling the UART clock
without loading the regular driver for a given UART.
I had to sacrifice one UART that I'm not using, which is not ideal in the
long run but will work for now.

Here's what I did:
Commented out the UART that I want to use from the device tree
(serial5/uart6).
Replaced the line ti,hwmods="uart3"; with ti,hwmods="uart6"; for the one
that I do want to use.
This is evidently what causes the power/clock management driver to enable
the clock for that particular module.

This causes a segfault when trying to enable UART3 because it's obviously
not turned on with this little hack.

If there is a way to create a sort of dummy device tree entry with only the
ti,hwmods part then I think the problem may be solved.
The problem right now is each entry begins something like serial@481a8000{
or similar, which evidently links the driver to the address which we don't
want.

Cheers,

Steve

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Wolfgang Grandegger]

On Thu, 12 Feb 2015 18:36:14 -0800, Steve B <sbattazzo@gmail.com> wrote:
> On Thu, Feb 12, 2015 at 5:03 PM, Steve B <sbattazzo@gmail.com> wrote:
> 
>> Nevermind, the shift looks OK, I guess that the 0xFA in the uppermost
>> byte
>> of the address is because of the ioremap call?
>>
>> Steve
>>
>> On Thu, Feb 12, 2015 at 4:51 PM, Steve B <sbattazzo@gmail.com> wrote:
>>
>>> Hello Gilles,
>>> I tried your patch to 16550A_io.h from the discussion with Terje
Frosya
>>> in November and I believe I can see why it didn't work.
>>>
>>> I added a couple of printk statements to verify that the driver is
>>> reading and writing to the intended addresses, and here's what I got:
>>>
>>> [   40.594119] xeno_16550A: Init IO at address 0x481AA000
>>> [   40.594159] xeno_16550A: Writing: FA1AA004. Regwidth 2 Regshift 2
>>> [   40.594169] xeno_16550A: Reading: FA1AA008. Regwidth 2 Regshift 2
>>> [   40.594183] Unhandled fault: external abort on non-linefetch
(0x1028)
>>> at 0xfa1aa008
>>>
>>> It looks like the regshift is operating on the most significant byte
of
>>> the base address rather than the least significant! Perhaps it's
>>> something
>>> to do with the endianness, but I still haven't wrapped my brain around
>>> why.
>>> Of course it makes sense that you are getting a segfault because the
>>> code
>>> is trying to read/write entirely the wrong address.
>>>
>>> Any thoughts?
>>>
>>> PS, Terje I think I saw on a Google Groups thread elsewhere that you
had
>>> given up on this and found a different solution, but I am including
you
>>> on
>>> this in case you may be curious about it.
>>>
>>> Thanks,
>>>
>>> Steve
>>>
>>>
>>> On Wed, Feb 11, 2015 at 8:02 PM, Steve B <sbattazzo@gmail.com> wrote:
>>>
>>>> Hello all,
>>>> Was there ever a resolution to running the 16550 driver on Beaglebone
>>>> Black? I see that there was a discussion on this in November but I
>>>> don't
>>>> see anything saying that somebody got it to work.
>>>>
>>>> Thanks,
>>>>
>>>> Steve
>>>>
>>>
>>>
>>
> Hello again,
> I was not able to run a C program to directly set the one register that
> needs to be set to turn on the UART clock, but I was able to get
> xeno_16550A to load by sort of tricking the OS into enabling the UART
clock
> without loading the regular driver for a given UART.
> I had to sacrifice one UART that I'm not using, which is not ideal in
the
> long run but will work for now.
> 
> Here's what I did:
> Commented out the UART that I want to use from the device tree
> (serial5/uart6).
> Replaced the line ti,hwmods="uart3"; with ti,hwmods="uart6"; for the one
> that I do want to use.
> This is evidently what causes the power/clock management driver to
enable
> the clock for that particular module.
> 
> This causes a segfault when trying to enable UART3 because it's
obviously
> not turned on with this little hack.
> 
> If there is a way to create a sort of dummy device tree entry with only
the
> ti,hwmods part then I think the problem may be solved.
> The problem right now is each entry begins something like
serial@481a8000{
> or similar, which evidently links the driver to the address which we
don't
> want.

Maybe unbinding the Linux device from the driver as shown below (for
another
device) already helps:

# echo f0002400.serial \
   /sys/devices/f000.soc5200/f0002400.serial/driver/unbind

Then load the Xenomai driver.

Wolfgang.

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Wolfgang Grandegger]

On Fri, 13 Feb 2015 08:10:23 +0100, Wolfgang Grandegger
<wg@grandegger.com> wrote:
...
> Maybe unbinding the Linux device from the driver as shown below (for
> another
> device) already helps:
> 
> # echo f0002400.serial \
>    /sys/devices/f000.soc5200/f0002400.serial/driver/unbind

Oops, the redirection ">" is missing!

Wolfgang,

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Steve B]

On Thu, Feb 12, 2015 at 11:14 PM, Wolfgang Grandegger <wg@grandegger.com>
wrote:

> On Fri, 13 Feb 2015 08:10:23 +0100, Wolfgang Grandegger
> <wg@grandegger.com> wrote:
> ...
> > Maybe unbinding the Linux device from the driver as shown below (for
> > another
> > device) already helps:
> >
> > # echo f0002400.serial \
> >    /sys/devices/f000.soc5200/f0002400.serial/driver/unbind
>
> Oops, the redirection ">" is missing!
>
> Wolfgang,
>
>
>
Thanks Wolfgang, I will give that a try. Otherwise I think it looks
promising that just playing with the device tree settings may be enough to
get the peripheral clock and power enabled without actually binding the
driver!

Steve

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Gilles Chanteperdrix]

On Thu, Feb 12, 2015 at 06:36:14PM -0800, Steve B wrote:
> On Thu, Feb 12, 2015 at 5:03 PM, Steve B <sbattazzo@gmail.com> wrote:
> 
> > Nevermind, the shift looks OK, I guess that the 0xFA in the uppermost byte
> > of the address is because of the ioremap call?
> >
> > Steve
> >
> > On Thu, Feb 12, 2015 at 4:51 PM, Steve B <sbattazzo@gmail.com> wrote:
> >
> >> Hello Gilles,
> >> I tried your patch to 16550A_io.h from the discussion with Terje Frosya
> >> in November and I believe I can see why it didn't work.
> >>
> >> I added a couple of printk statements to verify that the driver is
> >> reading and writing to the intended addresses, and here's what I got:
> >>
> >> [   40.594119] xeno_16550A: Init IO at address 0x481AA000
> >> [   40.594159] xeno_16550A: Writing: FA1AA004. Regwidth 2 Regshift 2
> >> [   40.594169] xeno_16550A: Reading: FA1AA008. Regwidth 2 Regshift 2
> >> [   40.594183] Unhandled fault: external abort on non-linefetch (0x1028)
> >> at 0xfa1aa008
> >>
> >> It looks like the regshift is operating on the most significant byte of
> >> the base address rather than the least significant! Perhaps it's something
> >> to do with the endianness, but I still haven't wrapped my brain around why.
> >> Of course it makes sense that you are getting a segfault because the code
> >> is trying to read/write entirely the wrong address.
> >>
> >> Any thoughts?
> >>
> >> PS, Terje I think I saw on a Google Groups thread elsewhere that you had
> >> given up on this and found a different solution, but I am including you on
> >> this in case you may be curious about it.
> >>
> >> Thanks,
> >>
> >> Steve
> >>
> >>
> >> On Wed, Feb 11, 2015 at 8:02 PM, Steve B <sbattazzo@gmail.com> wrote:
> >>
> >>> Hello all,
> >>> Was there ever a resolution to running the 16550 driver on Beaglebone
> >>> Black? I see that there was a discussion on this in November but I don't
> >>> see anything saying that somebody got it to work.
> >>>
> >>> Thanks,
> >>>
> >>> Steve
> >>>
> >>
> >>
> >
> Hello again,
> I was not able to run a C program to directly set the one register that
> needs to be set to turn on the UART clock, but I was able to get
> xeno_16550A to load by sort of tricking the OS into enabling the UART clock
> without loading the regular driver for a given UART.
> I had to sacrifice one UART that I'm not using, which is not ideal in the
> long run but will work for now.
> 
> Here's what I did:
> Commented out the UART that I want to use from the device tree
> (serial5/uart6).
> Replaced the line ti,hwmods="uart3"; with ti,hwmods="uart6"; for the one
> that I do want to use.
> This is evidently what causes the power/clock management driver to enable
> the clock for that particular module.
> 
> This causes a segfault when trying to enable UART3 because it's obviously
> not turned on with this little hack.
> 
> If there is a way to create a sort of dummy device tree entry with only the
> ti,hwmods part then I think the problem may be solved.
> The problem right now is each entry begins something like serial@481a8000{
> or similar, which evidently links the driver to the address which we don't
> want.

I would create another module, rt_ti16550a, sharing code with
rt_16550a (so definitely not a duplication of the code), which does
the necessary stuff with DT to get and enable the necessary clocks.

-- 
					    Gilles.

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Steve B]

On Thu, Feb 12, 2015 at 11:53 PM, Steve B <sbattazzo@gmail.com> wrote:

>
>
> On Thu, Feb 12, 2015 at 11:14 PM, Wolfgang Grandegger <wg@grandegger.com>
> wrote:
>
>> On Fri, 13 Feb 2015 08:10:23 +0100, Wolfgang Grandegger
>> <wg@grandegger.com> wrote:
>> ...
>> > Maybe unbinding the Linux device from the driver as shown below (for
>> > another
>> > device) already helps:
>> >
>> > # echo f0002400.serial \
>> >    /sys/devices/f000.soc5200/f0002400.serial/driver/unbind
>>
>> Oops, the redirection ">" is missing!
>>
>> Wolfgang,
>>
>>
>>
> Thanks Wolfgang, I will give that a try. Otherwise I think it looks
> promising that just playing with the device tree settings may be enough to
> get the peripheral clock and power enabled without actually binding the
> driver!
>
> Steve
>

Hmm, unfortunately this one didn't work. I think it un-did the clock enable.

By doing something ugly as I mentioned before with the device tree I can
get the driver running and the register reads/writes seem OK, but for some
reason I'm not seeing any IRQs, so I can't get any bytes out on TX.

I tried adding the right IRQ number into my "sacrificed" UART's device tree
entry and that caused some other issue entirely.

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Steve B]

On Fri, Feb 13, 2015 at 4:40 PM, Steve B <sbattazzo@gmail.com> wrote:

>
> On Thu, Feb 12, 2015 at 11:53 PM, Steve B <sbattazzo@gmail.com> wrote:
>
>>
>>
>> On Thu, Feb 12, 2015 at 11:14 PM, Wolfgang Grandegger <wg@grandegger.com>
>> wrote:
>>
>>> On Fri, 13 Feb 2015 08:10:23 +0100, Wolfgang Grandegger
>>> <wg@grandegger.com> wrote:
>>> ...
>>> > Maybe unbinding the Linux device from the driver as shown below (for
>>> > another
>>> > device) already helps:
>>> >
>>> > # echo f0002400.serial \
>>> >    /sys/devices/f000.soc5200/f0002400.serial/driver/unbind
>>>
>>> Oops, the redirection ">" is missing!
>>>
>>> Wolfgang,
>>>
>>>
>>>
>> Thanks Wolfgang, I will give that a try. Otherwise I think it looks
>> promising that just playing with the device tree settings may be enough to
>> get the peripheral clock and power enabled without actually binding the
>> driver!
>>
>> Steve
>>
>
> Hmm, unfortunately this one didn't work. I think it un-did the clock
> enable.
>
> By doing something ugly as I mentioned before with the device tree I can
> get the driver running and the register reads/writes seem OK, but for some
> reason I'm not seeing any IRQs, so I can't get any bytes out on TX.
>
> I tried adding the right IRQ number into my "sacrificed" UART's device
> tree entry and that caused some other issue entirely.
>

Hello all, in case anybody is curious I have an update.

I still haven't found/verified a proper way to load the driver with the
device tree such that the pinmux and clock enable happen as they need to,
but I think maybe I should build an of_match_table into the driver so that
the device tree can connect the dots with compatible = "ti,xeno_16550A" or
something to that effect (as I think Gilles was hinting at last week).

Also I realized that I was naively trying to invoke the modprobe of
xeno_16550A using the actual hardware IRQ number that I see in the AM335X
TRM and the device tree for this UART, which is not the IRQ number that's
in the OS. Fixing that to the correct IRQ number, I was able to send
something out on the UART once before totally locking up my CPU, so I think
I'm stuck in the ISR somehow. But at least it's some progress!

Steve

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Gilles Chanteperdrix]

On Tue, Feb 17, 2015 at 10:22:32AM -0800, Steve B wrote:
> On Fri, Feb 13, 2015 at 4:40 PM, Steve B <sbattazzo@gmail.com> wrote:
> 
> >
> > On Thu, Feb 12, 2015 at 11:53 PM, Steve B <sbattazzo@gmail.com> wrote:
> >
> >>
> >>
> >> On Thu, Feb 12, 2015 at 11:14 PM, Wolfgang Grandegger <wg@grandegger.com>
> >> wrote:
> >>
> >>> On Fri, 13 Feb 2015 08:10:23 +0100, Wolfgang Grandegger
> >>> <wg@grandegger.com> wrote:
> >>> ...
> >>> > Maybe unbinding the Linux device from the driver as shown below (for
> >>> > another
> >>> > device) already helps:
> >>> >
> >>> > # echo f0002400.serial \
> >>> >    /sys/devices/f000.soc5200/f0002400.serial/driver/unbind
> >>>
> >>> Oops, the redirection ">" is missing!
> >>>
> >>> Wolfgang,
> >>>
> >>>
> >>>
> >> Thanks Wolfgang, I will give that a try. Otherwise I think it looks
> >> promising that just playing with the device tree settings may be enough to
> >> get the peripheral clock and power enabled without actually binding the
> >> driver!
> >>
> >> Steve
> >>
> >
> > Hmm, unfortunately this one didn't work. I think it un-did the clock
> > enable.
> >
> > By doing something ugly as I mentioned before with the device tree I can
> > get the driver running and the register reads/writes seem OK, but for some
> > reason I'm not seeing any IRQs, so I can't get any bytes out on TX.
> >
> > I tried adding the right IRQ number into my "sacrificed" UART's device
> > tree entry and that caused some other issue entirely.
> >
> 
> Hello all, in case anybody is curious I have an update.
> 
> I still haven't found/verified a proper way to load the driver with the
> device tree such that the pinmux and clock enable happen as they need to,
> but I think maybe I should build an of_match_table into the driver so that
> the device tree can connect the dots with compatible = "ti,xeno_16550A" or
> something to that effect (as I think Gilles was hinting at last week).
> 
> Also I realized that I was naively trying to invoke the modprobe of
> xeno_16550A using the actual hardware IRQ number that I see in the AM335X
> TRM and the device tree for this UART, which is not the IRQ number that's
> in the OS. Fixing that to the correct IRQ number, I was able to send
> something out on the UART once before totally locking up my CPU, so I think
> I'm stuck in the ISR somehow. But at least it's some progress!

What I was saying was that you should use the same compatible string
as the one used by the TI driver (otherwise you will not match the
device tree data). And put this in a file, compiled as a separate
module. Not xeno_16550A. I makes no sense to have this in the
xeno_16550A module. You can probably get the irq module
automatically via DT.

-- 
					    Gilles.

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Steve B]

On Tue, Feb 17, 2015 at 10:27 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On Tue, Feb 17, 2015 at 10:22:32AM -0800, Steve B wrote:
> > On Fri, Feb 13, 2015 at 4:40 PM, Steve B <sbattazzo@gmail.com> wrote:
> >
> > >
> > > On Thu, Feb 12, 2015 at 11:53 PM, Steve B <sbattazzo@gmail.com> wrote:
> > >
> > >>
> > >>
> > >> On Thu, Feb 12, 2015 at 11:14 PM, Wolfgang Grandegger <
> wg@grandegger.com>
> > >> wrote:
> > >>
> > >>> On Fri, 13 Feb 2015 08:10:23 +0100, Wolfgang Grandegger
> > >>> <wg@grandegger.com> wrote:
> > >>> ...
> > >>> > Maybe unbinding the Linux device from the driver as shown below
> (for
> > >>> > another
> > >>> > device) already helps:
> > >>> >
> > >>> > # echo f0002400.serial \
> > >>> >    /sys/devices/f000.soc5200/f0002400.serial/driver/unbind
> > >>>
> > >>> Oops, the redirection ">" is missing!
> > >>>
> > >>> Wolfgang,
> > >>>
> > >>>
> > >>>
> > >> Thanks Wolfgang, I will give that a try. Otherwise I think it looks
> > >> promising that just playing with the device tree settings may be
> enough to
> > >> get the peripheral clock and power enabled without actually binding
> the
> > >> driver!
> > >>
> > >> Steve
> > >>
> > >
> > > Hmm, unfortunately this one didn't work. I think it un-did the clock
> > > enable.
> > >
> > > By doing something ugly as I mentioned before with the device tree I
> can
> > > get the driver running and the register reads/writes seem OK, but for
> some
> > > reason I'm not seeing any IRQs, so I can't get any bytes out on TX.
> > >
> > > I tried adding the right IRQ number into my "sacrificed" UART's device
> > > tree entry and that caused some other issue entirely.
> > >
> >
> > Hello all, in case anybody is curious I have an update.
> >
> > I still haven't found/verified a proper way to load the driver with the
> > device tree such that the pinmux and clock enable happen as they need to,
> > but I think maybe I should build an of_match_table into the driver so
> that
> > the device tree can connect the dots with compatible = "ti,xeno_16550A"
> or
> > something to that effect (as I think Gilles was hinting at last week).
> >
> > Also I realized that I was naively trying to invoke the modprobe of
> > xeno_16550A using the actual hardware IRQ number that I see in the AM335X
> > TRM and the device tree for this UART, which is not the IRQ number that's
> > in the OS. Fixing that to the correct IRQ number, I was able to send
> > something out on the UART once before totally locking up my CPU, so I
> think
> > I'm stuck in the ISR somehow. But at least it's some progress!
>
> What I was saying was that you should use the same compatible string
> as the one used by the TI driver (otherwise you will not match the
> device tree data). And put this in a file, compiled as a separate
> module. Not xeno_16550A. I makes no sense to have this in the
> xeno_16550A module. You can probably get the irq module
> automatically via DT.
>
> --
>                                             Gilles.
>

OK, but wouldn't there be a problem that it has the same string as the
non-RT driver?
What about giving it its own compatible string and updating the device tree
to look for that one?
I want to keep most of my UARTs in the non-RT domain and use the RT driver
on just one UART in my particular application,


Also, after taking a look at the code, I have found a couple of extra
things needed to make this compatible with TI's UART on the Beaglebone
Black (and presumably OMAP devices as well):
According to AM335x TRM, the DLH and DLL registers need to be set to zero
when setting up the FIFO (writing to FCR).

Also, with the xeno_16550A driver as-is, the driver gets stuck in the
while(1) loop in the ISR after a TX is initiated once, freezing my OS.
This is because the operation that masks the TX interrupt is not done until
that loop has been cleared.
But with this UART the TX interrupt stays active as long as the TX fifo is
not full beyond a certain threshold.
I have solved this by masking the TX interrupt and posting the
rtdm_event_signal(&ctx->out_event) when ctx->out_npend goes to zero within
the tx_interrupt function instead of outside of that while(1) loop. Is
there any reason why I should not be doing it that way?

Steve

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Gilles Chanteperdrix]

On Tue, Feb 17, 2015 at 02:58:40PM -0800, Steve B wrote:
> On Tue, Feb 17, 2015 at 10:27 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
> > On Tue, Feb 17, 2015 at 10:22:32AM -0800, Steve B wrote:
> > > On Fri, Feb 13, 2015 at 4:40 PM, Steve B <sbattazzo@gmail.com> wrote:
> > >
> > > >
> > > > On Thu, Feb 12, 2015 at 11:53 PM, Steve B <sbattazzo@gmail.com> wrote:
> > > >
> > > >>
> > > >>
> > > >> On Thu, Feb 12, 2015 at 11:14 PM, Wolfgang Grandegger <
> > wg@grandegger.com>
> > > >> wrote:
> > > >>
> > > >>> On Fri, 13 Feb 2015 08:10:23 +0100, Wolfgang Grandegger
> > > >>> <wg@grandegger.com> wrote:
> > > >>> ...
> > > >>> > Maybe unbinding the Linux device from the driver as shown below
> > (for
> > > >>> > another
> > > >>> > device) already helps:
> > > >>> >
> > > >>> > # echo f0002400.serial \
> > > >>> >    /sys/devices/f000.soc5200/f0002400.serial/driver/unbind
> > > >>>
> > > >>> Oops, the redirection ">" is missing!
> > > >>>
> > > >>> Wolfgang,
> > > >>>
> > > >>>
> > > >>>
> > > >> Thanks Wolfgang, I will give that a try. Otherwise I think it looks
> > > >> promising that just playing with the device tree settings may be
> > enough to
> > > >> get the peripheral clock and power enabled without actually binding
> > the
> > > >> driver!
> > > >>
> > > >> Steve
> > > >>
> > > >
> > > > Hmm, unfortunately this one didn't work. I think it un-did the clock
> > > > enable.
> > > >
> > > > By doing something ugly as I mentioned before with the device tree I
> > can
> > > > get the driver running and the register reads/writes seem OK, but for
> > some
> > > > reason I'm not seeing any IRQs, so I can't get any bytes out on TX.
> > > >
> > > > I tried adding the right IRQ number into my "sacrificed" UART's device
> > > > tree entry and that caused some other issue entirely.
> > > >
> > >
> > > Hello all, in case anybody is curious I have an update.
> > >
> > > I still haven't found/verified a proper way to load the driver with the
> > > device tree such that the pinmux and clock enable happen as they need to,
> > > but I think maybe I should build an of_match_table into the driver so
> > that
> > > the device tree can connect the dots with compatible = "ti,xeno_16550A"
> > or
> > > something to that effect (as I think Gilles was hinting at last week).
> > >
> > > Also I realized that I was naively trying to invoke the modprobe of
> > > xeno_16550A using the actual hardware IRQ number that I see in the AM335X
> > > TRM and the device tree for this UART, which is not the IRQ number that's
> > > in the OS. Fixing that to the correct IRQ number, I was able to send
> > > something out on the UART once before totally locking up my CPU, so I
> > think
> > > I'm stuck in the ISR somehow. But at least it's some progress!
> >
> > What I was saying was that you should use the same compatible string
> > as the one used by the TI driver (otherwise you will not match the
> > device tree data). And put this in a file, compiled as a separate
> > module. Not xeno_16550A. I makes no sense to have this in the
> > xeno_16550A module. You can probably get the irq module
> > automatically via DT.
> >
> > --
> >                                             Gilles.
> >
> 
> OK, but wouldn't there be a problem that it has the same string as the
> non-RT driver?
> What about giving it its own compatible string and updating the device tree
> to look for that one?
> I want to keep most of my UARTs in the non-RT domain and use the RT driver
> on just one UART in my particular application,

As Wolfgang said, you can bind/unbind device to a particular driver.

> 
> 
> Also, after taking a look at the code, I have found a couple of extra
> things needed to make this compatible with TI's UART on the Beaglebone
> Black (and presumably OMAP devices as well):
> According to AM335x TRM, the DLH and DLL registers need to be set to zero
> when setting up the FIFO (writing to FCR).
> 
> Also, with the xeno_16550A driver as-is, the driver gets stuck in the
> while(1) loop in the ISR after a TX is initiated once, freezing my OS.
> This is because the operation that masks the TX interrupt is not done until
> that loop has been cleared.
> But with this UART the TX interrupt stays active as long as the TX fifo is
> not full beyond a certain threshold.
> I have solved this by masking the TX interrupt and posting the
> rtdm_event_signal(&ctx->out_event) when ctx->out_npend goes to zero within
> the tx_interrupt function instead of outside of that while(1) loop. Is
> there any reason why I should not be doing it that way?

All this make it clear that you need another driver for the TI UART
(as I said already twice), say xeno_ti16550A.You just have to
arrange to factor the common code and not copy/paste it.

-- 
					    Gilles.

Re: [Xenomai] 16550 serial driver on Beaglebone Black

[Steve B]

On Tue, Feb 17, 2015 at 10:47 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On Tue, Feb 17, 2015 at 02:58:40PM -0800, Steve B wrote:
> > On Tue, Feb 17, 2015 at 10:27 AM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> > > On Tue, Feb 17, 2015 at 10:22:32AM -0800, Steve B wrote:
> > > > On Fri, Feb 13, 2015 at 4:40 PM, Steve B <sbattazzo@gmail.com>
> wrote:
> > > >
> > > > >
> > > > > On Thu, Feb 12, 2015 at 11:53 PM, Steve B <sbattazzo@gmail.com>
> wrote:
> > > > >
> > > > >>
> > > > >>
> > > > >> On Thu, Feb 12, 2015 at 11:14 PM, Wolfgang Grandegger <
> > > wg@grandegger.com>
> > > > >> wrote:
> > > > >>
> > > > >>> On Fri, 13 Feb 2015 08:10:23 +0100, Wolfgang Grandegger
> > > > >>> <wg@grandegger.com> wrote:
> > > > >>> ...
> > > > >>> > Maybe unbinding the Linux device from the driver as shown below
> > > (for
> > > > >>> > another
> > > > >>> > device) already helps:
> > > > >>> >
> > > > >>> > # echo f0002400.serial \
> > > > >>> >    /sys/devices/f000.soc5200/f0002400.serial/driver/unbind
> > > > >>>
> > > > >>> Oops, the redirection ">" is missing!
> > > > >>>
> > > > >>> Wolfgang,
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >> Thanks Wolfgang, I will give that a try. Otherwise I think it
> looks
> > > > >> promising that just playing with the device tree settings may be
> > > enough to
> > > > >> get the peripheral clock and power enabled without actually
> binding
> > > the
> > > > >> driver!
> > > > >>
> > > > >> Steve
> > > > >>
> > > > >
> > > > > Hmm, unfortunately this one didn't work. I think it un-did the
> clock
> > > > > enable.
> > > > >
> > > > > By doing something ugly as I mentioned before with the device tree
> I
> > > can
> > > > > get the driver running and the register reads/writes seem OK, but
> for
> > > some
> > > > > reason I'm not seeing any IRQs, so I can't get any bytes out on TX.
> > > > >
> > > > > I tried adding the right IRQ number into my "sacrificed" UART's
> device
> > > > > tree entry and that caused some other issue entirely.
> > > > >
> > > >
> > > > Hello all, in case anybody is curious I have an update.
> > > >
> > > > I still haven't found/verified a proper way to load the driver with
> the
> > > > device tree such that the pinmux and clock enable happen as they
> need to,
> > > > but I think maybe I should build an of_match_table into the driver so
> > > that
> > > > the device tree can connect the dots with compatible =
> "ti,xeno_16550A"
> > > or
> > > > something to that effect (as I think Gilles was hinting at last
> week).
> > > >
> > > > Also I realized that I was naively trying to invoke the modprobe of
> > > > xeno_16550A using the actual hardware IRQ number that I see in the
> AM335X
> > > > TRM and the device tree for this UART, which is not the IRQ number
> that's
> > > > in the OS. Fixing that to the correct IRQ number, I was able to send
> > > > something out on the UART once before totally locking up my CPU, so I
> > > think
> > > > I'm stuck in the ISR somehow. But at least it's some progress!
> > >
> > > What I was saying was that you should use the same compatible string
> > > as the one used by the TI driver (otherwise you will not match the
> > > device tree data). And put this in a file, compiled as a separate
> > > module. Not xeno_16550A. I makes no sense to have this in the
> > > xeno_16550A module. You can probably get the irq module
> > > automatically via DT.
> > >
> > > --
> > >                                             Gilles.
> > >
> >
> > OK, but wouldn't there be a problem that it has the same string as the
> > non-RT driver?
> > What about giving it its own compatible string and updating the device
> tree
> > to look for that one?
> > I want to keep most of my UARTs in the non-RT domain and use the RT
> driver
> > on just one UART in my particular application,
>
> As Wolfgang said, you can bind/unbind device to a particular driver.
>
> >
> >
> > Also, after taking a look at the code, I have found a couple of extra
> > things needed to make this compatible with TI's UART on the Beaglebone
> > Black (and presumably OMAP devices as well):
> > According to AM335x TRM, the DLH and DLL registers need to be set to zero
> > when setting up the FIFO (writing to FCR).
> >
> > Also, with the xeno_16550A driver as-is, the driver gets stuck in the
> > while(1) loop in the ISR after a TX is initiated once, freezing my OS.
> > This is because the operation that masks the TX interrupt is not done
> until
> > that loop has been cleared.
> > But with this UART the TX interrupt stays active as long as the TX fifo
> is
> > not full beyond a certain threshold.
> > I have solved this by masking the TX interrupt and posting the
> > rtdm_event_signal(&ctx->out_event) when ctx->out_npend goes to zero
> within
> > the tx_interrupt function instead of outside of that while(1) loop. Is
> > there any reason why I should not be doing it that way?
>
> All this make it clear that you need another driver for the TI UART
> (as I said already twice), say xeno_ti16550A.You just have to
> arrange to factor the common code and not copy/paste it.
>
> --
>                                             Gilles.
>

OK, thanks for the help.
For now I will run keeping my changes local, and when I have some time I
will clean it up the right way and push it back if somebody wants it.

Steve