1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
From patchwork Tue Jan 20 11:28:45 2015
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [OpenWrt-Devel] uboot-lantiq cgu settings for ramboot image
From: Ben Mulvihill <ben.mulvihill@gmail.com>
X-Patchwork-Id: 431024
Message-Id: <1421753325.25187.58.camel@merveille.lan>
To: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: OpenWrt Development List <openwrt-devel@lists.openwrt.org>
Date: Tue, 20 Jan 2015 12:28:45 +0100
On Tue, 2015-01-20 at 00:39 +0100, Ben Mulvihill wrote:
> 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!
>
>
Some of the bitshifting in arch/mips/cpu/mips32/arx100/cgu.c is 1
out. A patch along these lines should fix it:
--- a/arch/mips/cpu/mips32/arx100/cgu.c 2015-01-20 11:57:22.000000000 +0100
+++ b/arch/mips/cpu/mips32/arx100/cgu.c 2015-01-20 12:00:15.000000000 +0100
@@ -10,12 +10,17 @@
#include <asm/lantiq/clk.h>
#include <asm/lantiq/io.h>
-#define CGU_SYS_DDR_SEL (1 << 0)
-#define CGU_SYS_CPU_SEL (1 << 2)
+#define CGU_SYS_DDR_SHIFT 0
+#define CGU_SYS_CPU_SHIFT 2
#define CGU_SYS_SYS_SHIFT 3
+#define CGU_SYS_FPI_SHIFT 6
+#define CGU_SYS_PPE_SHIFT 7
+
+#define CGU_SYS_DDR_MASK (1 << CGU_SYS_DDR_SHIFT)
+#define CGU_SYS_CPU_MASK (1 << CGU_SYS_CPU_SHIFT)
#define CGU_SYS_SYS_MASK (0x3 << CGU_SYS_SYS_SHIFT)
-#define CGU_SYS_FPI_SEL (1 << 6)
-#define CGU_SYS_PPE_SEL (1 << 7)
+#define CGU_SYS_FPI_MASK (1 << CGU_SYS_FPI_SHIFT)
+#define CGU_SYS_PPE_MASK (1 << CGU_SYS_PPE_SHIFT)
struct ltq_cgu_regs {
u32 rsvd0;
@@ -68,7 +73,7 @@ unsigned long ltq_get_io_region_clock(vo
u32 ddr_sel;
unsigned long clk;
- ddr_sel = ltq_cgu_sys_readl(1, CGU_SYS_DDR_SEL);
+ ddr_sel = ltq_cgu_sys_readl(CGU_SYS_DDR_MASK, CGU_SYS_DDR_SHIFT);
if (ddr_sel)
clk = ltq_get_system_clock() / 3;
@@ -83,7 +88,7 @@ unsigned long ltq_get_cpu_clock(void)
u32 cpu_sel;
unsigned long clk;
- cpu_sel = ltq_cgu_sys_readl(1, CGU_SYS_CPU_SEL);
+ cpu_sel = ltq_cgu_sys_readl(CGU_SYS_CPU_MASK, CGU_SYS_CPU_SHIFT);
if (cpu_sel)
clk = ltq_get_io_region_clock();
@@ -98,7 +103,7 @@ unsigned long ltq_get_bus_clock(void)
u32 fpi_sel;
unsigned long clk;
- fpi_sel = ltq_cgu_sys_readl(1, CGU_SYS_FPI_SEL);
+ fpi_sel = ltq_cgu_sys_readl(CGU_SYS_FPI_MASK, CGU_SYS_FPI_SHIFT);
if (fpi_sel)
clk = ltq_get_io_region_clock() / 2;
|
