[OpenWrt-Devel] uboot-lantiq cgu settings for ramboot image
diff mbox

Message ID CACUy__U3gJ-M6Hz7A_GTewGaTJ+FK4fiZXANbxhLmmXt_0SM=g@mail.gmail.com
State Not Applicable
Headers show

Commit Message

Daniel Schwierzeck Jan. 19, 2015, 3:47 p.m. UTC
2015-01-19 15:44 GMT+01:00 Ben Mulvihill <ben.mulvihill@gmail.com>:
> On Mon, 2015-01-19 at 11:51 +0000, Conor O'Gorman wrote:
>> On 19/01/15 10:46, Ben Mulvihill wrote:
>> > Hello,
>> >
>> > I am trying to build uboot-lantiq for the BT Home Hub 3A (lantiq
>> > ar9), and am wondering where to initialise the cgu, in the case
>> > of a ramboot image for uart booting. Normally the cgu is initialised
>> > in lowlevel_init, but that code is bypassed in ramboot images. The
>> > result is that the board boots with the wrong cgu settings, which
>> > sends the console haywire. So far I have tried two solutions:
>>
>> Another option is to try and not change anything. The console is already
>> configured and running. The ram does need config.
>>
>> I was used to seeing the ramboot version running at half clock speed, at
>> least on danube, previous to ar9.
>>
>> Conor
>
> Hi Conor,
>
> Thanks for the reply. But with the latest uboot-lantiq, not changing
> anything means that I don't get a usable console. With an older
> version I do at least get a uboot console, but no linux console when
> I boot openwrt. Correcting the cgu settings solves both problems.
>

could you try this?


the UART driver calculates the baudrate from the FPI bus clock, but
FPI_SEL is not available on AR9. FPI bus clock is always the same as
DDR clock, Obviously a copy&paste error from VR9 code ;)

Comments

Ben Mulvihill Jan. 19, 2015, 6:21 p.m. UTC | #1
On Mon, 2015-01-19 at 16:47 +0100, Daniel Schwierzeck wrote:
> 2015-01-19 15:44 GMT+01:00 Ben Mulvihill <ben.mulvihill@gmail.com>:
> > On Mon, 2015-01-19 at 11:51 +0000, Conor O'Gorman wrote:
> >> On 19/01/15 10:46, Ben Mulvihill wrote:
> >> > Hello,
> >> >
> >> > I am trying to build uboot-lantiq for the BT Home Hub 3A (lantiq
> >> > ar9), and am wondering where to initialise the cgu, in the case
> >> > of a ramboot image for uart booting. Normally the cgu is initialised
> >> > in lowlevel_init, but that code is bypassed in ramboot images. The
> >> > result is that the board boots with the wrong cgu settings, which
> >> > sends the console haywire. So far I have tried two solutions:
> >>
> >> Another option is to try and not change anything. The console is already
> >> configured and running. The ram does need config.
> >>
> >> I was used to seeing the ramboot version running at half clock speed, at
> >> least on danube, previous to ar9.
> >>
> >> Conor
> >
> > Hi Conor,
> >
> > Thanks for the reply. But with the latest uboot-lantiq, not changing
> > anything means that I don't get a usable console. With an older
> > version I do at least get a uboot console, but no linux console when
> > I boot openwrt. Correcting the cgu settings solves both problems.
> >
> 
> could you try this?
> 
> diff --git a/arch/mips/cpu/mips32/arx100/cgu.c
> b/arch/mips/cpu/mips32/arx100/cgu.c
> index 6e71ee7..e0afbda 100644
> --- a/arch/mips/cpu/mips32/arx100/cgu.c
> +++ b/arch/mips/cpu/mips32/arx100/cgu.c
> @@ -95,15 +95,5 @@ unsigned long ltq_get_cpu_clock(void)
> 
>  unsigned long ltq_get_bus_clock(void)
>  {
> -       u32 fpi_sel;
> -       unsigned long clk;
> -
> -       fpi_sel = ltq_cgu_sys_readl(1, CGU_SYS_FPI_SEL);
> -
> -       if (fpi_sel)
> -               clk = ltq_get_io_region_clock() / 2;
> -       else
> -               clk = ltq_get_io_region_clock();
> -
> -       return clk;
> +       return ltq_get_io_region_clock();
>  }
> 
> the UART driver calculates the baudrate from the FPI bus clock, but
> FPI_SEL is not available on AR9. FPI bus clock is always the same as
> DDR clock, Obviously a copy&paste error from VR9 code ;)
> 

No, even with this patch, I still don't get a working console I'm
afraid. If I don't set anything explicitly, the board comes up with
CGU_SYS set to 0x05, ie CGU_SYS_SYSSEL_PLL0_333_MHZ |
CGU_SYS_CPUSEL_EQUAL_DDRCLK | CGU_SYS_DDRSEL_THIRD_SYSCLK.
Is this a valid combination without CGU_SYS_PPESEL_250_MHZ ?
I don't understand what CGU_SYS_PPESEL_250_MHZ does?
The "right setting", as set by the stock uboot, is 0x80.
Ben Mulvihill Jan. 19, 2015, 11:39 p.m. UTC | #2
On Mon, 2015-01-19 at 19:21 +0100, Ben Mulvihill wrote:
> On Mon, 2015-01-19 at 16:47 +0100, Daniel Schwierzeck wrote:
> > 2015-01-19 15:44 GMT+01:00 Ben Mulvihill <ben.mulvihill@gmail.com>:
> > > On Mon, 2015-01-19 at 11:51 +0000, Conor O'Gorman wrote:
> > >> On 19/01/15 10:46, Ben Mulvihill wrote:
> > >> > Hello,
> > >> >
> > >> > I am trying to build uboot-lantiq for the BT Home Hub 3A (lantiq
> > >> > ar9), and am wondering where to initialise the cgu, in the case
> > >> > of a ramboot image for uart booting. Normally the cgu is initialised
> > >> > in lowlevel_init, but that code is bypassed in ramboot images. The
> > >> > result is that the board boots with the wrong cgu settings, which
> > >> > sends the console haywire. So far I have tried two solutions:
> > >>
> > >> Another option is to try and not change anything. The console is already
> > >> configured and running. The ram does need config.
> > >>
> > >> I was used to seeing the ramboot version running at half clock speed, at
> > >> least on danube, previous to ar9.
> > >>
> > >> Conor
> > >
> > > Hi Conor,
> > >
> > > Thanks for the reply. But with the latest uboot-lantiq, not changing
> > > anything means that I don't get a usable console. With an older
> > > version I do at least get a uboot console, but no linux console when
> > > I boot openwrt. Correcting the cgu settings solves both problems.
> > >
> > 
> > could you try this?
> > 
> > diff --git a/arch/mips/cpu/mips32/arx100/cgu.c
> > b/arch/mips/cpu/mips32/arx100/cgu.c
> > index 6e71ee7..e0afbda 100644
> > --- a/arch/mips/cpu/mips32/arx100/cgu.c
> > +++ b/arch/mips/cpu/mips32/arx100/cgu.c
> > @@ -95,15 +95,5 @@ unsigned long ltq_get_cpu_clock(void)
> > 
> >  unsigned long ltq_get_bus_clock(void)
> >  {
> > -       u32 fpi_sel;
> > -       unsigned long clk;
> > -
> > -       fpi_sel = ltq_cgu_sys_readl(1, CGU_SYS_FPI_SEL);
> > -
> > -       if (fpi_sel)
> > -               clk = ltq_get_io_region_clock() / 2;
> > -       else
> > -               clk = ltq_get_io_region_clock();
> > -
> > -       return clk;
> > +       return ltq_get_io_region_clock();
> >  }
> > 
> > the UART driver calculates the baudrate from the FPI bus clock, but
> > FPI_SEL is not available on AR9. FPI bus clock is always the same as
> > DDR clock, Obviously a copy&paste error from VR9 code ;)
> > 
> 
> No, even with this patch, I still don't get a working console I'm
> afraid. If I don't set anything explicitly, the board comes up with
> CGU_SYS set to 0x05, ie CGU_SYS_SYSSEL_PLL0_333_MHZ |
> CGU_SYS_CPUSEL_EQUAL_DDRCLK | CGU_SYS_DDRSEL_THIRD_SYSCLK.
> Is this a valid combination without CGU_SYS_PPESEL_250_MHZ ?
> I don't understand what CGU_SYS_PPESEL_250_MHZ does?
> The "right setting", as set by the stock uboot, is 0x80.

P.S. There also seems to be a discrepancy between the uboot and
linux code. I take it from what you say above that fpi clock, ddr
clock and io region clock are all the same. Now if the least 
significant bit of CGU_SYS is set, then according to the uboot
code - function ltq_get_bus_clock() - their value is one
third of the system clock. But according to the linux code
- function ltq_ar9_fpi_hz() in arch/mips/lantiq/xway/clk.c -
their value in this case is equal to the system clock.

Or am I getting muddled? It's past my bedtime!

Patch
diff mbox

diff --git a/arch/mips/cpu/mips32/arx100/cgu.c
b/arch/mips/cpu/mips32/arx100/cgu.c
index 6e71ee7..e0afbda 100644
--- a/arch/mips/cpu/mips32/arx100/cgu.c
+++ b/arch/mips/cpu/mips32/arx100/cgu.c
@@ -95,15 +95,5 @@  unsigned long ltq_get_cpu_clock(void)

 unsigned long ltq_get_bus_clock(void)
 {
-       u32 fpi_sel;
-       unsigned long clk;
-
-       fpi_sel = ltq_cgu_sys_readl(1, CGU_SYS_FPI_SEL);
-
-       if (fpi_sel)
-               clk = ltq_get_io_region_clock() / 2;
-       else
-               clk = ltq_get_io_region_clock();
-
-       return clk;
+       return ltq_get_io_region_clock();
 }