public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Robert Schwebel <r.schwebel@pengutronix.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] uboot clock configuration on mpc5200 boards
Date: Wed, 21 Nov 2007 08:01:59 +0100	[thread overview]
Message-ID: <20071121070159.GI11448@pengutronix.de> (raw)
In-Reply-To: <fa686aa40711201816n64f43095kf447c0037f472156@mail.gmail.com>

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

  parent reply	other threads:[~2007-11-21  7:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-10 23:12 [U-Boot-Users] uboot clock configuration on mpc5200 boards Jon Smirl
     [not found] ` <9e4733910711201700o75f74c20k243b42d2595491dd@mail.gmail.com>
2007-11-21  2:16   ` Grant Likely
2007-11-21  2:37     ` Jon Smirl
2007-11-21  7:01     ` Robert Schwebel [this message]
2007-11-21 11:21       ` Wolfgang Denk
2007-11-21 12:14         ` Robert Schwebel
2007-11-21 13:00           ` Wolfgang Denk
2007-11-21 13:41             ` Robert Schwebel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071121070159.GI11448@pengutronix.de \
    --to=r.schwebel@pengutronix.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox