From owner-freebsd-arm@FreeBSD.ORG Sun Feb 17 09:49:41 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8C58687; Sun, 17 Feb 2013 09:49:41 +0000 (UTC) (envelope-from iain@g7iii.net) Received: from hal.g7iii.net (unknown [IPv6:2600:3c02::f03c:91ff:feae:1cbe]) by mx1.freebsd.org (Postfix) with ESMTP id 75D57F6D; Sun, 17 Feb 2013 09:49:41 +0000 (UTC) Received: from [192.168.39.76] (157.17.187.81.in-addr.arpa [81.187.17.157]) by hal.g7iii.net (Postfix) with ESMTP id 358B5208F5; Sun, 17 Feb 2013 09:49:34 +0000 (UTC) Message-ID: <5120A7AD.40903@g7iii.net> Date: Sun, 17 Feb 2013 09:49:33 +0000 From: Iain Young User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Damjan Marion Subject: Re: Beaglebone Serial Ports Progress References: <511E1A08.4020105@g7iii.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 09:49:41 -0000 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