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