From: Peter Korsgaard <jacmet@sunsite.dk>
To: Sven Luther <sven@genesi-usa.com>
Cc: linuxppc-dev <Linuxppc-dev@ozlabs.org>
Subject: Re: USB support on mpc5200 broken
Date: Mon, 29 Sep 2008 19:05:34 +0200 [thread overview]
Message-ID: <87iqseopb5.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <20080929151854.GA29375@powerlinux.fr> (Sven Luther's message of "Mon\, 29 Sep 2008 17\:18\:54 +0200")
>>>>> "Sven" == Sven Luther <sven@genesi-usa.com> writes:
Hi,
>> This, of course, is exactly why I *don't* recommend embedded platforms
>> move to including the device tree in the flashed firmware. Keeping
>> the device tree in the bootwrapper means that it *is* updated with the
>> kernel and we don't have to mess around with as much backwards
>> compatibility junk.
Sven> This completely defeats the purpopse of having a separate
Sven> device tree though, no ? I mean, we could just as well hardcode
Sven> the device-tree info in the kernel in this case ?
Well, yes and no. The device tree brings a number of advantages (and a
few disadvantages as well), one of those being the potential
decoupling of kernel and DT. Even if you don't make use of that
feature in a production build you still have the other advantages
(E.G. easy compile test of multiple boards, limited
repeated-these-are-my-platform-devices code in board files, ...).
Sven> (In embedded cases, the kernel is usyually in the flash as
Sven> well, so you just upgrade both at the same time :)
Sure, but if you do that you might as well include them in a single
uImage because:
- They are always in sync
- You don't waste flash space (E.G. the DT is very small, but you
waste a complete flash sector)
With uImage.<platform> U-Boot can still fix up the tree before booting
the kernel, so you don't lose any functionality (E.G. if you
enable/disable certain nodes based on what option boards are
available).
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2008-09-29 17:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 21:51 USB support on mpc5200 broken Jon Smirl
2008-09-25 1:09 ` Jon Smirl
2008-09-25 1:50 ` Benjamin Herrenschmidt
2008-09-25 2:40 ` Jon Smirl
2008-09-29 1:30 ` Matt Sealey
2008-09-29 3:43 ` David Gibson
2008-09-29 14:14 ` Jon Smirl
2008-09-29 14:22 ` Peter Korsgaard
2008-09-29 14:28 ` Jon Smirl
2008-09-29 15:07 ` Peter Korsgaard
2008-09-29 20:18 ` Scott Wood
2008-09-29 21:04 ` Jon Smirl
2008-09-29 22:02 ` Grant Likely
2008-09-30 15:20 ` Matt Sealey
2008-10-01 3:31 ` Benjamin Herrenschmidt
2008-10-01 9:46 ` Carsten Schlote
2008-10-01 10:36 ` Benjamin Herrenschmidt
2008-10-06 21:06 ` Matt Sealey
2008-09-29 15:18 ` Sven Luther
2008-09-29 17:05 ` Peter Korsgaard [this message]
2008-09-30 1:12 ` David Gibson
2008-09-30 1:24 ` Raquel and Bill
2008-09-30 15:15 ` Matt Sealey
2008-11-03 15:41 ` Grant Likely
2008-11-03 16:21 ` Jon Smirl
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=87iqseopb5.fsf@macbook.be.48ers.dk \
--to=jacmet@sunsite.dk \
--cc=Linuxppc-dev@ozlabs.org \
--cc=sven@genesi-usa.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.