[U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support
jonsmirl at gmail.com
jonsmirl at gmail.com
Wed Jan 4 23:59:32 CET 2017
On Wed, Jan 4, 2017 at 5:36 PM, André Przywara <andre.przywara at arm.com> wrote:
> On 04/01/17 19:00, jonsmirl at gmail.com wrote:
>> On Wed, Jan 4, 2017 at 12:29 PM, André Przywara <andre.przywara at arm.com> wrote:
>>> On 04/01/17 16:40, jonsmirl at gmail.com wrote:
>>>> On Wed, Jan 4, 2017 at 8:36 AM, André Przywara <andre.przywara at arm.com> wrote:
>>>>>
>>>>> On 04/01/17 11:25, Chen-Yu Tsai wrote:
>>>>>> On Wed, Jan 4, 2017 at 6:28 PM, Jagan Teki <jagan at openedev.com> wrote:
>>>>>>> On Tue, Jan 3, 2017 at 2:52 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>>>>>>>> On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>>>>>>>> On Tue, Jan 3, 2017 at 3:38 AM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>>>>>>>>>> I recently ran into a probably with the UARTs on the A64. Many
>>>>>>>>>> Bluetooth modules (like Ampak) use the UART. The data rate of EDR BT
>>>>>>>>>> is 3Mb/s with about 2.1Mb/s though put. To handle this most systems
>>>>>>>>>> set the speed of the BT UART to 3Mb/s.
>>>>>>>>>>
>>>>>>>>>> By default the Allwinner UART clock input is OSC24. When using OSC24
>>>>>>>>>> the maximum speed the UART can be set to is 1.5Mb/s. The clock input
>>>>>>>>>> (apb2) can be changed over to PERIPH0x2 (1.2ghz) via the device tree
>>>>>>>>>> and 3Mb/s is then supported.
>>>>>>>>>>
>>>>>>>>>> But... there's a problem, UART0 (the console) is using the same master
>>>>>>>>>> clock source. So when you change the clock input over to PERIPH0x2 the
>>>>>>>>>> console stops working. There is no mechanism in Linux to handle this
>>>>>>>>>> clock source change and adjust the dividers on active uarts. So it
>>>>>>>>>> would be best if this master clock was set very early in u-boot and
>>>>>>>>>> then the console is adjusted to use it.
>>>>>>>>>>
>>>>>>>>>> Are there any downsides to making this change in u-boot?
>>>>>>>>>
>>>>>>>>> I don't understand, did you find this behaviour with these SPL changes
>>>>>>>>> or general sunxi u-boot?
>>>>>>>
>>>>>>> I think, this issue need to resolve, Andre any comments?
>>>>>>
>>>>>> This is a completely different issue unrelated to A64 SPL support.
>>>>>
>>>>> I agree that's a completely orthogonal issue. Someone needs to bake a
>>>>> patch (easy?) and post it. This doesn't depend in any way on this
>>>>> series, in fact would affect many sunxi boards.
>>>>>
>>>>>> What Jon is saying is that for the UART to go faster than 1.5 Mb/s,
>>>>>> The APB2 clock has to be reparented to the peripheral PLL. When do
>>>>>> we do this is the question. This is a generic sunxi issue.
>>>>>
>>>>> On the first glance this approach sounds a bit hackish, since we use
>>>>> firmware to setup the clocks in a way to solves a particular issue.
>>>>>
>>>>> On the other hand using PERIPH0(2x) as a base for APB2 seems like a
>>>>> completely proper setup, even somewhat recommended by Allwinner (after
>>>>> all the UARTs are based on this special clock for a reason).
>>>>>
>>>>>> Now, I think doing this as soon as possible (with regards to the
>>>>>> running system) would be best. Reparenting the clk on the fly
>>>>>> would change the baud rate, and result in the uart glitching.
>>>>>
>>>>> Can't we change it when observing the proper order: turning TX/RX off,
>>>>> programming new divisors, changing the clock source, turning TX/RX back on?
>>>>
>>>> You would expect to be able to achieve this reparenting by simply
>>>> changing the device tree in Linux.
>>>
>>> Why would this be done in DT? The APB2 clock is capable of being driven
>>> by 32KHz, 24 MHz or PERIPH0(2x), the DT should express this. The old
>>> Allwinner binding certainly did, the new hides this in the driver. But
>>> as the hardware allows it, the DT shouldn't have a say in the parenting
>>> decision - apart from listing the alternatives. This is actually a
>>> driver or clock system decision.
>>>
>>>> I tried that on the Allwinner 3.10
>>>
>>> <connection lost>
>>>
>>>> kernel and it actually works. But... it causes the console to quit
>>>> working.
>>>>
>>>> Do Linux clk_notifiers work soon enough to handle reparenting the
>>>> console in the device tree? It is not clear to me that they do. Plus
>>>> the 8250_dw driver doesn't support it.
>>>
>>> I believe Chen-Yu meant that clk_notifiers would allow to notify all
>>> clock users of some changed situation (like a different parent clock).
>>> As you know, _all_ UARTs plus I2C use this clock, so if *one* requires a
>>> higher base clock, *all* users have to notified to change their clock
>>> divisors to match the new base frequency.
>>> This has nothing to do with device tree directly.
>>>
>>>> Next I considered changing it in the u-boot device tree. But again,
>>>> console is set up before u-boot loads that device tree. In Allwinner
>>>> uboot console is set up in the SPL code before the device tree is
>>>> loaded.
>>>
>>> Traditionally for sunxi boards in upstream U-Boot we use the DT only
>>> sparingly. IIRC DT clock information is completely ignored and there is
>>> just some static setup - which is way easier and sufficient for our
>>> needs. The SPL doesn't use DT at all (mostly for space constraints).
>>>
>>> So as I said changing this in U-Boot looks like an easy patch, PLL6 is
>>> setup to 600 MHz already, so we just need to change the clock source for
>>> APB2 to that and adjust the dividers.
>>>
>>> Do you have an idea what a good APB2 frequency would be?
>>> IIRC someone one IRC mentioned that the UARTs can't do much higher than
>>> 3 Mb/s anyway, so I guess 48 MHz or 96 MHz would be enough?
>>> Allwinner's I2C is limited to 400 KHz anyway, so there is no need for a
>>> higher clock here.
>>
>> In the datasheet there is a note recommending not to change this
>> 600Mhz (2x 1.2Ghz).
>
> That refers to PERIPH0, I was asking for the APB2 frequency. Looking at
> the achievable baud rates and error rates for common speeds (115200) I
> came up with a divider of 5:
> 1200 MHz / 5 = 240 MHz APB2 frequency
> 240 MHz / 16 = 15 Mbps maximum baud rate
> divider|baud rate | error
> 5 3 Mbps 0.0%
> 10 1.5 Mbps 0.0%
> 16 921600 1.7%
> 130 115200 0.16%
>
> Reports seems to indicate that at least 12.5 Mbps is feasible with the
> UARTs, so this maximum of 15 Mbps seems like a good approach, because it
> gives 3 and 1.5 Mbps without errors.
>
> Alternatives would be max. baud rate of 3 Mbps (still limiting) or the
> system maximum of 75 Mbps, but clocking APB2 at 1.2 GHz sounds a bit
> over the top for me.
>
> Jon, can you try this U-Boot patch (copy & pasted in, so probably won't
> apply cleanly):
What is uboot is this against? I am not using mainline u-boot, we are
on the Allwinner stuff.
>
> --- a/arch/arm/mach-sunxi/clock_sun6i.c
> +++ b/arch/arm/mach-sunxi/clock_sun6i.c
> @@ -65,9 +65,9 @@ void clock_init_uart(void)
> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
>
> /* uart clock source is apb2 */
> - writel(APB2_CLK_SRC_OSC24M|
> + writel(APB2_CLK_SRC_PLL6|
> APB2_CLK_RATE_N_1|
> - APB2_CLK_RATE_M(1),
> + APB2_CLK_RATE_M(5),
> &ccm->apb2_div);
>
> /* open the clock for uart */
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -42,7 +42,7 @@
> /* Serial & console */
> #define CONFIG_SYS_NS16550_SERIAL
> /* ns16550 reg in the low bits of cpu reg */
> -#define CONFIG_SYS_NS16550_CLK 24000000
> +#define CONFIG_SYS_NS16550_CLK 240000000
> #ifndef CONFIG_DM_SERIAL
> # define CONFIG_SYS_NS16550_REG_SIZE -4
> # define CONFIG_SYS_NS16550_COM1 SUNXI_UART0_BASE
>
> Cheers,
> Andre.
>
>>
>>>
>>> It would be great if someone could do experiments to get the highest
>>> usable baudrate.
>>>
>>>> Is the PERIPH0(2x) clock always running?
>>>
>>> It seems so, anyway the Linux clock system would take care of this now,
>>> as the console UART would be at least one user. Though I believe there
>>> are more users, so it's unlikely that it would get turned off anyway.
>>>
>>> Cheers,
>>> Andre.
>>>
>>>
>>>> Maybe defaulting UARTs/I2C
>>>> to OSC24 was done to save power?
>>>>
>>>> After investigating this I now understand why Allwinner modified the
>>>> standard Broadcom Bluetooth driver in AOSP. They fixed it to run with
>>>> a 1.5Mb UART. Everyone else in AOSP uses it with a 3Mb/s UART. All of
>>>> this started because we were unaware of the changes Allwinner had made
>>>> to the Broadcom AOSP code and we couldn't get AOSP Bluetooth to work.
>>>> Who knows why Allwinner didn't just adjust the UART to run at 3Mb/s.
>>>> Probably two different programmer groups.
>>>>
>>>>>
>>>>> Nevertheless it seems worthwhile to give this rather simple U-Boot
>>>>> approach a go. But I would like to see some testing, since this will
>>>>> affect many sunxi boards.
>>>>>
>>>>>> Also, as Jon mentioned, the 8250_dw driver in the kernel doesn't
>>>>>> support clk notifiers. And it won't work with earlycon anyway...
>>>>>
>>>>> As a long-term goal teaching the Linux driver to reparent APB2 seems
>>>>> like a good thing, though I expect some nastiness in this.
>>>>>
>>>>> Cheers,
>>>>> Andre.
>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Previously the boot console uart0 was getting setup in the SPL code. I
>>>>>>>> have not been closely following these changes, is that still true?
>>>>>>>>
>>>>>>>> Changing the clock parent needs to be done before uart0 is
>>>>>>>> initialized. Changing this parent should have no other impact on
>>>>>>>> u-boot other than changing the clock divisor uart0 is using.
>>>>>>>>
>>>>>>>> Once Linux is up, the Linux uart code will see the changed clock
>>>>>>>> parent and allow higher baud rates to be set.
>>>>>>>>
>>>>>>>> This clock parent also impacts the I2C clocks, but I don't believe I2C
>>>>>>>> is enabled in A64 uboot.
>>>>>>>
>>>>>>> Jagan.
>>>>>>> _______________________________________________
>>>>>>> U-Boot mailing list
>>>>>>> U-Boot at lists.denx.de
>>>>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
--
Jon Smirl
jonsmirl at gmail.com
More information about the U-Boot
mailing list