[U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support

André Przywara andre.przywara at arm.com
Wed Jan 4 23:36:13 CET 2017 

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):

--- 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
>>>>
>>>
>>>
>>>
>>
> 
> 
>

More information about the U-Boot mailing list