[U-Boot-Users] BRGs on ep8248 after updating CLKIN

[Alan Bennett]

The main reason I began looking down this path was that within my
linux drivers, things were quite strange.  I'd do a schedule_timeout
for HZ/10 and with the help of a few test points and a logic analyzer,
I'd sleep a lot less than 1/10 of a second!  Often times I'd be out of
the loop in 60-80 msecs.  The only thing I could figure out was that
there was a miscalculation of the clocks by "something".
/proc/cpuinfo and other methods, u-boot included, seemed to think I
was running at 231 MHz, but empirical data showed that I was running
faster than that.  I also remembered that a while back, when we were
on the reference board (with the same clock configuration) we were
seeing ~350MHz.

Flawed, though it may have been, I began blaming many parts of the
system without understanding them, as you've read in my email.
However, I'm now wondering if the following interpretation is is
acceptable.  From what I read in the reference manual, the bus_clock
and clk_in are not "required" to be the same. Though several
references in the manual and in u-boot hard wire them to each other.

Looking at the Ref Manual for the 8272, Figure 10-1,
  It shows a conflict:
       1. MAIN_PLL = 66MHz * (SCMR[pllmf]+1)
               my board this is = 66MHz*(5+1) = 396 MHz
       2. BUSCLK = MAIN_PLL/(SCMR[busdf]+1)
               my board this is = 396MHz /(3+1) = 99 MHz
       3. CPU_CLK = SCMR[corecnf] multiplier 1E * BUS_CLK
               My board this is =3.5*99MHz = 346.5 MHz

BUT CLKIN != BUS_CLK  (66MHz != 99MHz) and (231MHz != 346.5MHz)

So the only way we can handle both the HIGH and LOW configuration
case, within speed.c is by calculating bus_clk according to the
reference manual and not hardcoding it to clkin.
i.e.
  gd->bus_clk = vco_out / (SCMR[busdf]+1)
and
  gd->cpu_clk = (gd->bus_clk * cp->b2c_mult) / 2

At least this is what I believe now.  Note: My serial port is much
happier and a 1/10 of a second timeout takes 1/10th of a second!

-Alan

On 11/29/07, Erik Christiansen <erik at dd.nec.com.au> wrote:
> On Thu, Nov 29, 2007 at 01:43:30PM -0700, Alan Bennett wrote:
> > When I originally supported my ep8248-style board, I had
> > #define CONFIG_8260_CLKIN     66000000        /* in Hz */
> >
> > However, I noticed (after far too much time had passed) that my cpu
> > speed wasn't matching my expectations.  (reported 230 MHz, and
> > expected 350 MHz).
> >
> > This was rather easily fixed by changing the CONFIG_8260_CLKIN to 100 MHz:
> > #define CONFIG_8260_CLKIN     100000000       /* in Hz */
> >
> > However, my BRGs / SMC1 uart is now broke(baud-rate mismatch).  Does
> > anyone have experience with this section of u-boot that could help me
> > out?
>
> Only that U-Boot built and ran fine for me on an ep8248 board, without
> any need to change the default CONFIG_8260_CLKIN.
>
> If the "ep8248-style board" were mine, I'd physically compare the
> crystal frequency with a real ep8248, before adjusting
> CONFIG_8260_CLKIN. (Assuming PLL config is unchanged.)
>
> What does a frequency meter or CRO show on core_clk_out, during
> core_hreset, on yours? Incidentally, mine also reports:
>
> CPU:   MPC8248 (HiP7 Rev 14, Mask 1.0 1K50M) at 231 MHz
> Board: EP8248E 1.0 CPLD revision 2
>
> > My BRG7 is configured by u-boot(1.3+) = 0x00010078 ~ CD = 60 (0x3c).
> > And there is an apparent baud-rate mismatch and all the output is
> > garbled now.  (with a scope I measured ~ 25.5 / 26 K, when I'm
> > expecting 38.4k)
> >
> > I think I'm missing something in the equation, but I'm not sure where
> > it is.  If I simply update the CD to be 162 (162*38400*16 = 99,532,800
> > ~ 100 MHz) the serial port is still dead.
> >
> > Any ideas?
>
> From way over here, it looks a bit like an incorrect assumption. But
> that's based on my tentative understanding that 350 MHz is "expected",
> but 230 MHz works. (Serial was OK in that case.)
>
> What is it that doesn't work with the default CONFIG_8260_CLKIN?
> (And if it's only low CPU speed, then a higher crystal frequency or
> lower PLL divider will be of more benefit?)
>
> Regards,
> Erik
>
>