From: "André Schwarz" <andre.schwarz@matrix-vision.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] using a flat device tree to drive u-boot config
Date: Tue, 29 Jul 2008 11:09:53 +0200 [thread overview]
Message-ID: <488EDE61.4030901@matrix-vision.de> (raw)
In-Reply-To: <488ED7BC.1050905@grandegger.com>
Wolfgang Grandegger schrieb:
> Andr? Schwarz wrote:
>> Ben Warren schrieb:
>>> On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood
>>> <scottwood@freescale.com> wrote:
>>>> Ben Warren wrote:
>>>>> On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <scottwood@freescale.com>
>>>>> wrote:
>>>>>> I find a device tree much easier to figure out than a tangled mess of
>>>>>> header
>>>>>> files, #defines, and #ifdefs...
>>>>> In many ways, yes. But are you an average Joe or a Linux kernel
>>>>> propellerhead?
>>>> Is u-boot work normally done by average Joes, and does the average Joe
>>>> really find the preprocessor mess more intuitive than a
>>>> "propellerhead"?
>>>>
>>> You know what I mean. Some people like yourself do this for a living,
>>> and are involved day-to-day in its specification. Of course it's
>>> intuitive to you. For most people, getting U-boot going is one stage
>>> in the development process of software for an embedded device. They
>>> work on it for a few weeks or months, then on something completely
>>> different. A few months or years later, they come back to it.
>>
>> You're absolutely right - just have a look at the vast lists of
>> maintainers/contributors ... they are "average Joes" like myself.
>> Realizing 2-3 projects each year should be possible without having to
>> re-learn from scratch.
>>
>>>> While we're at it, let's re-write u-boot in Visual Basic. :-)
>>> Uh, yeah. I like the idea of a central repo for hardware info, and
>>> the device tree concept is good. My point is that the syntax, while
>>> concise and exact, can be intimidating. Just look at the amount of
>>> traffic on the mailing lists of people that don't understand what all
>>> the fields mean when specifying IRQs etc. Anything we can do to make
>>> it less so for noobies is a good thing for everybody.
>>>
>>
>> Please keep in mind that WDenk is always watching if code is slowing
>> things down or increasing size significantly. Improving things is very
>> good - but not at the cost of size and/or speed. Configuring a board
>> using a dtb usually needs far more code being present than needed.
>> After all it's a bootloader and not another pseudo OS.
>>
>> But don't get me wrong ! The device tree is a very nice and usefuly
>> thing ... for an OS.
>
> There are customer request for a dynamically configurable U-Boot and the
> FDT is the right tool to provide the functionality. It has its price but
> U-Boot using a FDT blob for booting would also save some fixup code
> (required to boot Linux) and furthermore it would resolves some
> dependencies between hardcoded U-Boot and FDT defined addresses and ranges.
>
yes of course ... if you're thinking about paying customers.
What I can _definitely_ say is that we had to change flash layout twice
on *existing* products simply because bootloader and kernel are
constantly growing. It's nearly impossible to keep it small ... even
with same core functionality.
Only way out would be to freeze versions. That's what lots of companies
are doing ... and this is why so many out-of-tree branches exist. But
that's another topic ;-)
regards,
Andr?
> Wolfgang.
MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
next prev parent reply other threads:[~2008-07-29 9:09 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-28 15:07 [U-Boot-Users] using a flat device tree to drive u-boot config Kumar Gala
2008-07-28 17:28 ` Ben Warren
2008-07-28 17:32 ` Scott Wood
2008-07-28 17:35 ` Ben Warren
2008-07-28 17:43 ` Scott Wood
2008-07-28 18:05 ` Ben Warren
2008-07-28 18:59 ` Scott Wood
2008-07-29 8:26 ` André Schwarz
2008-07-29 8:41 ` Wolfgang Grandegger
2008-07-29 9:09 ` André Schwarz [this message]
2008-08-03 1:10 ` Jerry Van Baren
2008-07-29 16:41 ` Timur Tabi
2008-07-28 17:40 ` Grant Likely
2008-07-28 18:17 ` Kumar Gala
2008-07-28 19:07 ` Scott Wood
2008-07-29 7:54 ` Haavard Skinnemoen
2008-07-28 18:13 ` Wolfgang Grandegger
2008-07-28 18:19 ` Kumar Gala
2008-07-29 14:30 ` Jon Loeliger
2008-07-29 15:51 ` Robert Schwebel
2008-07-29 15:51 ` Robert Schwebel
2008-07-29 16:46 ` Timur Tabi
2008-08-03 1:58 ` Jon Smirl
2008-08-03 7:51 ` Wolfgang Denk
2008-08-03 12:57 ` Jon Smirl
2008-08-03 15:47 ` Wolfgang Denk
2008-08-03 17:49 ` Timur Tabi
2008-08-03 19:06 ` Grant Likely
2008-08-03 20:08 ` Timur Tabi
2008-08-04 8:08 ` Albert ARIBAUD
2008-08-04 7:16 ` Jens Gehrlein
2008-08-03 19:45 ` Wolfgang Denk
2008-08-04 14:33 ` Timur Tabi
2008-08-04 15:31 ` Wolfgang Denk
2008-08-04 15:36 ` Timur Tabi
2008-08-03 20:47 ` Andrew Dyer
2008-08-04 15:02 ` Jon Smirl
2008-08-04 15:05 ` Timur Tabi
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=488EDE61.4030901@matrix-vision.de \
--to=andre.schwarz@matrix-vision.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