Quantcast

Beaglebone Serial Ports Progress

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Beaglebone Serial Ports Progress

Iain Young
Hi Folks,

After waiting for deliveries, and a few false starts, I have made
-some- progress on adding support for the Beaglebone's serial ports
(UARTS1-5) to FreeBSD

First thing I did was add the pinmux stuff, having worked out exactly
what I needed to add to the DTS, and recompile. This seems to have
worked out well, and on a reboot I see:

setting internal 28 for uart1_rxd
setting internal 0 for uart1_txd


This is good. kernel comes up,curiously though, I don't see lines
output for the RTS and CTS lines (which I do set to the correct mode,
yet I do for UART3 CTS and UART4 CTS, which I added as a test.

I then proceeded to add  the uart1 device itself to the DTS, and
added the following:

  uart1: serial@48022000 {
                         compatible = "ns16550";
                         reg = <0x48022000 0x1000>;
                         reg-shift = <2>;
                         interrupts = < 73 >;
                         interrupt-parent = <&AINTC>;
                         clock-frequency = < 48000000 >;
                 };

This caused the kernel to dump me in db (debugger I guess). I figured
out that 't' gave me a trace, and it looked like it was in the middle
of probing for UARTS. (This is about as much knowledge I have about the
kernel debugger)

I tried changing 0x1000 for 0x2000, as it seems the next reg is also
reserved for UART1. No more luck. So, thinking I needed to add it as an
alias (as UART0 is), I added that, but it still dumped me at the
debugger on boot.

The only other thing is reg-shift. I must confess, I am a bit blind
here. Not knowing what it actually did I left it as with UART0. I'm
hoping it essentially includes the next register up for UART1, as
while that's listed as "Reserved" in the memory map [Yes, I consulted
SPRUH73G :)] , it seems to be reserved for UART1, but I am just
guessing (Yes, I know, not good practice when kernel hacking...)

I've attached the latest version of my patch, the output from the
kernel until it blows up, as well as the trace. Patch is based on
r246610

Anyone able to point me in the right direction ? I can't be too far
away, and I can then add UART2-5, and submit an actual working patch!


All the Best

Iain



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

beaglebone.uart1.patch (678 bytes) Download Attachment
boot_msgs_uart1 (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beaglebone Serial Ports Progress

Damjan Marion-2

On Feb 15, 2013, at 12:20 PM, Iain Young <[hidden email]> wrote:

> Hi Folks,
>
> After waiting for deliveries, and a few false starts, I have made
> -some- progress on adding support for the Beaglebone's serial ports
> (UARTS1-5) to FreeBSD
>
> First thing I did was add the pinmux stuff, having worked out exactly
> what I needed to add to the DTS, and recompile. This seems to have
> worked out well, and on a reboot I see:
>
> setting internal 28 for uart1_rxd
> setting internal 0 for uart1_txd
>
>
> This is good. kernel comes up,curiously though, I don't see lines
> output for the RTS and CTS lines (which I do set to the correct mode,
> yet I do for UART3 CTS and UART4 CTS, which I added as a test.
>
> I then proceeded to add  the uart1 device itself to the DTS, and
> added the following:
>
> uart1: serial@48022000 {
>                        compatible = "ns16550";
>                        reg = <0x48022000 0x1000>;
>                        reg-shift = <2>;
>                        interrupts = < 73 >;
>                        interrupt-parent = <&AINTC>;
>                        clock-frequency = < 48000000 >;
>                };
>
> This caused the kernel to dump me in db (debugger I guess). I figured
> out that 't' gave me a trace, and it looked like it was in the middle
> of probing for UARTS. (This is about as much knowledge I have about the
> kernel debugger)
>
> I tried changing 0x1000 for 0x2000, as it seems the next reg is also
> reserved for UART1. No more luck. So, thinking I needed to add it as an
> alias (as UART0 is), I added that, but it still dumped me at the
> debugger on boot.
>
> The only other thing is reg-shift. I must confess, I am a bit blind
> here. Not knowing what it actually did I left it as with UART0. I'm
> hoping it essentially includes the next register up for UART1, as
> while that's listed as "Reserved" in the memory map [Yes, I consulted
> SPRUH73G :)] , it seems to be reserved for UART1, but I am just
> guessing (Yes, I know, not good practice when kernel hacking...)
>
> I've attached the latest version of my patch, the output from the
> kernel until it blows up, as well as the trace. Patch is based on
> r246610
>
> Anyone able to point me in the right direction ? I can't be too far
> away, and I can then add UART2-5, and submit an actual working patch!
>

It is very likely that clock is disabled for USART1. Problem is that usart uses
standard serial driver which is not requesting clock to be enabled during the attach
by invoking ti_prcm_clk_enable().

Can you try to put following at the end of am335x_prcm_attach()?

        prcm_write_4(6c, 2);


This should be register CM_PER_UART1_CLKCTRL.

Damjan


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beaglebone Serial Ports Progress

Iain Young
Hi Damjan,

On 15/02/13 16:46, You wrote:

>>
>> I tried changing 0x1000 for 0x2000, as it seems the next reg is also
>> reserved for UART1. No more luck. So, thinking I needed to add it as an
>> alias (as UART0 is), I added that, but it still dumped me at the
>> debugger on boot.
>>
>> The only other thing is reg-shift. I must confess, I am a bit blind
>> here. Not knowing what it actually did I left it as with UART0. I'm
>> hoping it essentially includes the next register up for UART1, as
>> while that's listed as "Reserved" in the memory map [Yes, I consulted
>> SPRUH73G :)] , it seems to be reserved for UART1, but I am just
>> guessing (Yes, I know, not good practice when kernel hacking...)
>>
>> I've attached the latest version of my patch, the output from the
>> kernel until it blows up, as well as the trace. Patch is based on
>> r246610
>>
>> Anyone able to point me in the right direction ? I can't be too far
>> away, and I can then add UART2-5, and submit an actual working patch!
>>
>
> It is very likely that clock is disabled for USART1. Problem is that usart uses
> standard serial driver which is not requesting clock to be enabled during the attach
> by invoking ti_prcm_clk_enable().
>
> Can you try to put following at the end of am335x_prcm_attach()?
>
> prcm_write_4(6c, 2);
>
>
> This should be register CM_PER_UART1_CLKCTRL.

That indeed fixed it, and adding the other CLKCTRL registers in a
similar way enabled them as well.

Have not been able to test fully, as my GPS units are 70 ft away in the
shed at the end of the garden, however, my radio clock receivers are now
happily twiddling CTS on UARTS3 and 4 (also tested on UART1), so I'm
pretty sure all UARTS are fine.


Before I send the full patch what are the FreeBSD standards wrt the
above lines in am335x_prcm_attach() ? Should I leave as is ? Create
a separate function, and call it from am335x_prcm_attach() ? Or do I
create a #define in the same file, and create functions for each UART,
as I see some other clocks do ?


Now, An aside...PPS traditionally uses DCD. But on the 'bone, we need
to use CTS instead. So I went looking through the source, and found:

  if (COM_PPSCTS(flags))
                 com->pps_bit = MSR_CTS;
         else
                 com->pps_bit = MSR_DCD;
         pps_init(&com->pps);

in sys/dev/sio/sio.c

Wasn't sure if/how to set flags to make that if true from userspace,
so hacked it so even the else set com->pps_bit to CTS, and hacked
radioclkd2 to look at CTS rather than DCD as well in PPS mode, but to
no avail.

(radioclkd2 is working in poll mode, but that isn't great up against
iwait under Linux, which will also be switched to PPS this week when
the new 8 Gig microSD cards arrive)

Anyone know where else I may want to look to complete the job ?
The actual PPS code doesn't seem to mention DCD at all...So I
guess that is particularly

[And yes, in my opinion, ntpd has it's own issues with PPS, and
assuming it's coming in on a serial port on DCD, and needing
the prefer statement  the atom_pps reference clock driver  is
something else for me to break :)]

Now in the meantime, I'll go play with Ian's timer PPS patch :)


Best Regards

Iain


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beaglebone Serial Ports Progress

Tim Kientzle-2

On Feb 17, 2013, at 1:49 AM, Iain Young wrote:

> Hi Damjan,
>
> On 15/02/13 16:46, You wrote:
>
>>>
>>> I tried changing 0x1000 for 0x2000, as it seems the next reg is also
>>> reserved for UART1. No more luck. So, thinking I needed to add it as an
>>> alias (as UART0 is), I added that, but it still dumped me at the
>>> debugger on boot.
>>>
>>> The only other thing is reg-shift. I must confess, I am a bit blind
>>> here. Not knowing what it actually did I left it as with UART0. I'm
>>> hoping it essentially includes the next register up for UART1, as
>>> while that's listed as "Reserved" in the memory map [Yes, I consulted
>>> SPRUH73G :)] , it seems to be reserved for UART1, but I am just
>>> guessing (Yes, I know, not good practice when kernel hacking...)
>>>
>>> I've attached the latest version of my patch, the output from the
>>> kernel until it blows up, as well as the trace. Patch is based on
>>> r246610
>>>
>>> Anyone able to point me in the right direction ? I can't be too far
>>> away, and I can then add UART2-5, and submit an actual working patch!
>>>
>>
>> It is very likely that clock is disabled for USART1. Problem is that usart uses
>> standard serial driver which is not requesting clock to be enabled during the attach
>> by invoking ti_prcm_clk_enable().
>>
>> Can you try to put following at the end of am335x_prcm_attach()?
>>
>> prcm_write_4(6c, 2);
>>
>>
>> This should be register CM_PER_UART1_CLKCTRL.
>
> That indeed fixed it, and adding the other CLKCTRL registers in a
> similar way enabled them as well.
>
> Have not been able to test fully, as my GPS units are 70 ft away in the
> shed at the end of the garden, however, my radio clock receivers are now
> happily twiddling CTS on UARTS3 and 4 (also tested on UART1), so I'm
> pretty sure all UARTS are fine.
>
>
> Before I send the full patch what are the FreeBSD standards wrt the
> above lines in am335x_prcm_attach() ? Should I leave as is ? Create
> a separate function, and call it from am335x_prcm_attach() ? Or do I
> create a #define in the same file, and create functions for each UART,
> as I see some other clocks do ?

It would require a little more work but I think the natural
place to put this would be to put

    uart1: serial@48022000 {
       ...
       clocks = "UART1";
       clock-parent = <&PRCM>;
    };

in the FDT (which is a straightforward way of
saying "this device needs the PRCM to turn on
"UART1" clocks) and then figure out how to
actually support it.  ;-)

This is the same issue that we've been discussing
for pinmux, and the above is essentially the same solution
being discussed for pinmux.

It's not yet clear to me where/how this info should be acted on.
It could actually be handled in the simplebus driver, I
think, without modifying (in this case) the UART driver code
at all.   That would need only a standard way for simplebus to
communicate the clock-init string to the designated
clock handler.

The current handling for interrupt and memory resources
could also be used as a model, though that might
require modifying each driver to manage pinmux and
clock resources.

The nicest approach might be for simplebus to
handle the clock-init key transparently in
the many cases where there's a single clock and
the driver doesn't need any special management
and then provide a separate internal API for drivers
that want to manage multiple clock modes or enable/disable
clocks dynamically.

Tim

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beaglebone Serial Ports Progress

Warner Losh

On Feb 17, 2013, at 11:21 AM, Tim Kientzle wrote:

>
> On Feb 17, 2013, at 1:49 AM, Iain Young wrote:
>
>> Hi Damjan,
>>
>> On 15/02/13 16:46, You wrote:
>>
>>>>
>>>> I tried changing 0x1000 for 0x2000, as it seems the next reg is also
>>>> reserved for UART1. No more luck. So, thinking I needed to add it as an
>>>> alias (as UART0 is), I added that, but it still dumped me at the
>>>> debugger on boot.
>>>>
>>>> The only other thing is reg-shift. I must confess, I am a bit blind
>>>> here. Not knowing what it actually did I left it as with UART0. I'm
>>>> hoping it essentially includes the next register up for UART1, as
>>>> while that's listed as "Reserved" in the memory map [Yes, I consulted
>>>> SPRUH73G :)] , it seems to be reserved for UART1, but I am just
>>>> guessing (Yes, I know, not good practice when kernel hacking...)
>>>>
>>>> I've attached the latest version of my patch, the output from the
>>>> kernel until it blows up, as well as the trace. Patch is based on
>>>> r246610
>>>>
>>>> Anyone able to point me in the right direction ? I can't be too far
>>>> away, and I can then add UART2-5, and submit an actual working patch!
>>>>
>>>
>>> It is very likely that clock is disabled for USART1. Problem is that usart uses
>>> standard serial driver which is not requesting clock to be enabled during the attach
>>> by invoking ti_prcm_clk_enable().
>>>
>>> Can you try to put following at the end of am335x_prcm_attach()?
>>>
>>> prcm_write_4(6c, 2);
>>>
>>>
>>> This should be register CM_PER_UART1_CLKCTRL.
>>
>> That indeed fixed it, and adding the other CLKCTRL registers in a
>> similar way enabled them as well.
>>
>> Have not been able to test fully, as my GPS units are 70 ft away in the
>> shed at the end of the garden, however, my radio clock receivers are now
>> happily twiddling CTS on UARTS3 and 4 (also tested on UART1), so I'm
>> pretty sure all UARTS are fine.
>>
>>
>> Before I send the full patch what are the FreeBSD standards wrt the
>> above lines in am335x_prcm_attach() ? Should I leave as is ? Create
>> a separate function, and call it from am335x_prcm_attach() ? Or do I
>> create a #define in the same file, and create functions for each UART,
>> as I see some other clocks do ?
>
> It would require a little more work but I think the natural
> place to put this would be to put
>
>    uart1: serial@48022000 {
>       ...
>       clocks = "UART1";
>       clock-parent = <&PRCM>;
>    };
>
> in the FDT (which is a straightforward way of
> saying "this device needs the PRCM to turn on
> "UART1" clocks) and then figure out how to
> actually support it.  ;-)
>
> This is the same issue that we've been discussing
> for pinmux, and the above is essentially the same solution
> being discussed for pinmux.
>
> It's not yet clear to me where/how this info should be acted on.
> It could actually be handled in the simplebus driver, I
> think, without modifying (in this case) the UART driver code
> at all.   That would need only a standard way for simplebus to
> communicate the clock-init string to the designated
> clock handler.

Yes. We also need to augment our clock support a bit too...  In linux land, which may prove illustrative, you create the clocks as part of the SoC, associate names in the FDT and then each device requests the proper clock from their FDT node. There is (or was a few months ago) a move afoot to make this more automatic by default.

> The current handling for interrupt and memory resources
> could also be used as a model, though that might
> require modifying each driver to manage pinmux and
> clock resources.
>
> The nicest approach might be for simplebus to
> handle the clock-init key transparently in
> the many cases where there's a single clock and
> the driver doesn't need any special management
> and then provide a separate internal API for drivers
> that want to manage multiple clock modes or enable/disable
> clocks dynamically.

I rather like this idea, frankly...

Warner
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Beaglebone Serial Ports Progress

Iain Young
In reply to this post by Tim Kientzle-2
On 17/02/13 18:21, Tim Kientzle wrote:

>>
>> Before I send the full patch what are the FreeBSD standards wrt the
>> above lines in am335x_prcm_attach() ? Should I leave as is ? Create
>> a separate function, and call it from am335x_prcm_attach() ? Or do I
>> create a #define in the same file, and create functions for each UART,
>> as I see some other clocks do ?
>
> It would require a little more work but I think the natural
> place to put this would be to put
>
>      uart1: serial@48022000 {
>         ...
>         clocks = "UART1";
>         clock-parent = <&PRCM>;
>      };
>
> in the FDT (which is a straightforward way of
> saying "this device needs the PRCM to turn on
> "UART1" clocks) and then figure out how to
> actually support it.  ;-)
>
> This is the same issue that we've been discussing
> for pinmux, and the above is essentially the same solution
> being discussed for pinmux.
>
> It's not yet clear to me where/how this info should be acted on.
> It could actually be handled in the simplebus driver, I
> think, without modifying (in this case) the UART driver code
> at all.   That would need only a standard way for simplebus to
> communicate the clock-init string to the designated
> clock handler.
In that case, I shall leave things as they are for now, until a
consensus is come to, and other, better kernel coders than I
have written the necessary glue :)

In the meantime, the patch is attached here for anyone that wants
to use the other 5 UARTS (note UART3's TX and RX lines are not
brought out, but it's CTS and RTS lines can still be used for
other things.

The patch is in two parts, one for beaglebone.dts, and one for
am335x_prcm.c. You need to apply both. patch -p0 from /usr/src
or patch -p1 from /usr/src/sys should suffice.

Thanks to all those that helped point me in the right direction,
I couldn't have got the UARTs  working without your help.

Iain




_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

beaglebone.dts.patch (3K) Download Attachment
am335x_prcm_uart_clks.patch (559 bytes) Download Attachment
Loading...