[U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support
BongHo Lee
techcap at gmail.com
Thu Jun 15 06:48:48 UTC 2017
I'm trying to find how to use higher baud rate through modifying uart clock.
I followed your u-boot patch. But there's nothing changed.
After patching u-boot, uart clock still has 24MHz.
I checked using this command "cat /sys/class/tty/ttyS1/uartclk".
Should I modify dts file also?
On Thursday, January 5, 2017 at 7:36:24 AM UTC+9, André Przywara wrote:
> On 04/01/17 19:00, jons... at gmail.com <javascript:> wrote:
> > On Wed, Jan 4, 2017 at 12:29 PM, André Przywara <andre.p... at arm.com
> <javascript:>> wrote:
> >> On 04/01/17 16:40, jons... at gmail.com <javascript:> wrote:
> >>> On Wed, Jan 4, 2017 at 8:36 AM, André Przywara <andre.p... at arm.com
> <javascript:>> wrote:
> >>>>
> >>>> On 04/01/17 11:25, Chen-Yu Tsai wrote:
> >>>>> On Wed, Jan 4, 2017 at 6:28 PM, Jagan Teki <ja... at openedev.com
> <javascript:>> wrote:
> >>>>>> On Tue, Jan 3, 2017 at 2:52 PM, jons... at gmail.com <javascript:> <
> jons... at gmail.com <javascript:>> wrote:
> >>>>>>> On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki <jaganna... at gmail.com
> <javascript:>> wrote:
> >>>>>>>> On Tue, Jan 3, 2017 at 3:38 AM, jons... at gmail.com <javascript:> <
> jons... at gmail.com <javascript:>> 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-B... at lists.denx.de <javascript:>
> >>>>>> http://lists.denx.de/mailman/listinfo/u-boot
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>
More information about the U-Boot
mailing list