[U-Boot-Users] uboot clock configuration on mpc5200 boards

[U-Boot-Users] uboot clock configuration on mpc5200 boards

[Jon Smirl]

On the Linux kernel the mpc52xx_setup_cpu() function used to do this
fix up. Does uboot handle this for mpc5200 boards? If so, which
version?

uboot is accessing these registers but it is not clear to me if the
clocks are completely being set up.

The 5200lite code has been changed to this:

/*
 * Fix clock configuration.
 *
 * Firmware is supposed to be responsible for this.  If you are creating a
 * new board port, do *NOT* duplicate this code.  Fix your boot firmware
 * to set it correctly in the first place
 */
static void __init
lite5200_fix_clock_config(void)
{
       struct mpc52xx_cdm  __iomem *cdm;

       /* Map zones */
       cdm = mpc52xx_find_and_map("mpc5200-cdm");
       if (!cdm) {
               printk(KERN_ERR "%s() failed; expect abnormal behaviour\n",
                      __FUNCTION__);
               return;
       }

       /* Use internal 48 Mhz */
       out_8(&cdm->ext_48mhz_en, 0x00);
       out_8(&cdm->fd_enable, 0x01);
       if (in_be32(&cdm->rstcfg) & 0x40)       /* Assumes 33Mhz clock */
               out_be16(&cdm->fd_counters, 0x0001);
       else
               out_be16(&cdm->fd_counters, 0x5555);

       /* Unmap the regs */
       iounmap(cdm);
}

-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot-Users] uboot clock configuration on mpc5200 boards

[Grant Likely]

On 11/20/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On the Linux kernel the mpc52xx_setup_cpu() function used to do this
> fix up. Does uboot handle this for mpc5200 boards? If so, which
> version?
>
> uboot is accessing these registers but it is not clear to me if the
> clocks are completely being set up.
>
> The 5200lite code has been changed to this:
>
> /*
>  * Fix clock configuration.
>  *
>  * Firmware is supposed to be responsible for this.  If you are creating a
>  * new board port, do *NOT* duplicate this code.  Fix your boot firmware
>  * to set it correctly in the first place
>  */
> static void __init
> lite5200_fix_clock_config(void)
> {
----8<----snip---->8----
> }
>
> Is uboot setting this up correct now that they kernel has been changed?
>

Strictly speaking; firmware should be responsible for configuring the
SoC (clocks, pinouts, etc).  It makes it easier to add new boards if
each one doesn't need it's own fixups.

I haven't checked the clock setup for lite5200 in u-boot yet, but it
is not a complex change.  And even if I do change it for the lite5200
in u-boot; this code probably won't go away in the kernel so as not to
break compatibility with lite5200's with older u-boot firmware.

The point is that firmware should setup the CPU correctly at boot.  It
should not be Linux's responsibility.  However, if there is *existing*
firmware that needs to be supported; then I'll grudgingly accept hacks
like this to keep the board bootable.  If it is a new board, do it
right the first time and do it in firmware (be it u-boot or otherwise)

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] uboot clock configuration on mpc5200 boards

[Jon Smirl]

On 11/20/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/20/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On the Linux kernel the mpc52xx_setup_cpu() function used to do this
> > fix up. Does uboot handle this for mpc5200 boards? If so, which
> > version?
> >
> > uboot is accessing these registers but it is not clear to me if the
> > clocks are completely being set up.
> >
> > The 5200lite code has been changed to this:
> >
> > /*
> >  * Fix clock configuration.
> >  *
> >  * Firmware is supposed to be responsible for this.  If you are creating a
> >  * new board port, do *NOT* duplicate this code.  Fix your boot firmware
> >  * to set it correctly in the first place
> >  */
> > static void __init
> > lite5200_fix_clock_config(void)
> > {
> ----8<----snip---->8----
> > }
> >
> > Is uboot setting this up correct now that they kernel has been changed?
> >
>
> Strictly speaking; firmware should be responsible for configuring the
> SoC (clocks, pinouts, etc).  It makes it easier to add new boards if
> each one doesn't need it's own fixups.
>
> I haven't checked the clock setup for lite5200 in u-boot yet, but it
> is not a complex change.  And even if I do change it for the lite5200
> in u-boot; this code probably won't go away in the kernel so as not to
> break compatibility with lite5200's with older u-boot firmware.

Let me know when you sort it out in uboot. I'm using a Phytec pc030
and they've copied all of the 5200lite code. We're also building our
own hardware which isn't ready yet.


>
> The point is that firmware should setup the CPU correctly at boot.  It
> should not be Linux's responsibility.  However, if there is *existing*
> firmware that needs to be supported; then I'll grudgingly accept hacks
> like this to keep the board bootable.  If it is a new board, do it
> right the first time and do it in firmware (be it u-boot or otherwise)
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely at secretlab.ca
> (403) 399-0195
>


-- 
Jon Smirl
jonsmirl at gmail.com

[U-Boot-Users] uboot clock configuration on mpc5200 boards

[Robert Schwebel]

On Tue, Nov 20, 2007 at 07:16:08PM -0700, Grant Likely wrote:
> Strictly speaking; firmware should be responsible for configuring the
> SoC (clocks, pinouts, etc).  It makes it easier to add new boards if
> each one doesn't need it's own fixups.
>
> I haven't checked the clock setup for lite5200 in u-boot yet, but it
> is not a complex change.  And even if I do change it for the lite5200
> in u-boot; this code probably won't go away in the kernel so as not to
> break compatibility with lite5200's with older u-boot firmware.
>
> The point is that firmware should setup the CPU correctly at boot.  It
> should not be Linux's responsibility.  However, if there is *existing*
> firmware that needs to be supported; then I'll grudgingly accept hacks
> like this to keep the board bootable.  If it is a new board, do it
> right the first time and do it in firmware (be it u-boot or otherwise)

In an ideal world, yes. Unfortunately, we have the situation that...

- There are old firmwares out there, so init code in Linux has to stay
  anyway, which means code duplication.

- For module-type boards, you don't even know which hardware the end
  user has attached to his module, so what do you want to initialize?

In general I really like your idea, but our experience is that, taken
that there are these shortcommings, in reality the ARM model of
transferring only a device number to the kernel and let the kernel do
everything else works much better than all the fdt stuff and makes by
far less problems in the long term.

Maybe we have an idea how to solve the problem in u-boot-v2. It already
has loadable module support, so you can make generic board support for
u-boot which does only minimum initialization, plus a loadable module
for each "variant" (which is the generic board + a customer specific
baseboard).

rsc
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

[U-Boot-Users] uboot clock configuration on mpc5200 boards

[Wolfgang Denk]

In message <20071121070159.GI11448@pengutronix.de> you wrote:
>
> - For module-type boards, you don't even know which hardware the end
>   user has attached to his module, so what do you want to initialize?

...what has been specified in the device tree.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Don't tell me how hard you work.  Tell me how much you get done.
- James J. Ling

[U-Boot-Users] uboot clock configuration on mpc5200 boards

[Robert Schwebel]

On Wed, Nov 21, 2007 at 12:21:20PM +0100, Wolfgang Denk wrote:
> ...what has been specified in the device tree.

How do you handle the fact that device trees do not cover the whole
system, i.e. chips behind SPI and I2C busses?

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

[U-Boot-Users] uboot clock configuration on mpc5200 boards

[Wolfgang Denk]

In message <20071121121451.GU11448@pengutronix.de> you wrote:
> On Wed, Nov 21, 2007 at 12:21:20PM +0100, Wolfgang Denk wrote:
> > ...what has been specified in the device tree.
> 
> How do you handle the fact that device trees do not cover the whole
> system, i.e. chips behind SPI and I2C busses?

The  device  tree  is  supposed  to  contain  a   complete   hardware
description, i. e. including devices attached to such busses.

[How do you handle this with an ARM machine ID? ;-) ]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Don't try to outweird me, three-eyes. I get stranger things than you
free with my breakfast cereal."
           - Zaphod Beeblebrox in  "Hitchhiker's Guide to the Galaxy"

[U-Boot-Users] uboot clock configuration on mpc5200 boards

[Robert Schwebel]

On Wed, Nov 21, 2007 at 02:00:42PM +0100, Wolfgang Denk wrote:
> > How do you handle the fact that device trees do not cover the whole
> > system, i.e. chips behind SPI and I2C busses?
>
> The  device  tree  is  supposed  to  contain  a   complete   hardware
> description, i. e. including devices attached to such busses.

Yes, it is supposed to, but reality is different. Ok, so we have to
double-code everything until the world has achieved perfectionism.

> [How do you handle this with an ARM machine ID? ;-) ]

Well, we don't have to. Linux has a driver model which handles all this
once you know the machine. No need to duplicate everything. Redundancy
is generally a bad thing.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9