From: Timur Tabi <timur@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree
Date: Wed, 10 Nov 2010 14:54:30 -0600 [thread overview]
Message-ID: <4CDB0686.300@freescale.com> (raw)
In-Reply-To: <20101110203451.550DD1522C0@gemini.denx.de>
Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message <4CDAFC37.40309@freescale.com> you wrote:
>>
>> It's more than that. Any mismatch in the CCSR base address, serial device
>> offsets, or PCI addresses will be caught. For instance, if you put the PCIE1
>> memory range at ff800000 in the device tree, but ff6000000 in U-Boot, it will
>> catch that.
>
> Would that hurt? I though Linux does it's own initialization of the
> PCI system anyway, so does it matter what we did in U-Boot?
Well, it probably isn't an *error* technically, but it might be unexpected. But
I will consider removing that code, if there's some kind of consensus that it's
not worthwhile.
>> Because the problem shows up when you least expect it. It's designed to
>> eliminate debug problems. If we make this enabled only when people define a
>> macro that isn't normally defined, then people won't know about it. We have so
>> many problems with customers and other developers getting the device tree wrong,
>> and immediately contacting us for help without doing even the slightest
>> debugging. I'm sure you're familiar with that.
>
> Hey, you are not supposed to bring us out of work. Rather help to make
> the code complex and difficult to understand ;-)
Heh.
>> I can add a macro that needs to be defined in order to *disable* it, so that on
>> finalized systems where the device tree is known to be correct, this check can
>> be skipped. But I really would prefer to have this feature enabled by default.
>
> I understand what you want to do, and why you want to do it, but then
> I also feel thatit is inherently wrong. It cannot be U-Boot's taks to
> validate the correctness of the device tree on every boot.
Well, I really do think it should be done at every boot by default, but I would
be willing to consider an "fdt verify" command. Would you be willing to buy me
a beer every time someone forgets to run "fdt verify" and emails me instead?
> If we agree that this is adebug help, then please provide a separate
> command to perform this operation. Make this command optional (feel
> free to add it to the default list, but it must be possible to disable
> it if wanted). Then users who want this feature can add it to their
> boot command sequence, and others, who are interested in fast boot
> times can omit it.
Would "fdt verify" be a good place?
>> So you're saying you want to see this:
>>
>> if (parent_address_cells == 1)
>> dt_addr = be32_to_cpup(ranges + address_cells);
>> else {
>
> Yes, at least. Actually I prefer to use braces for the "then" branch
> as well if the "else" branch needs them.
Ok.
--
Timur Tabi
Linux kernel developer at Freescale
next prev parent reply other threads:[~2010-11-10 20:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-09 23:01 [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree Timur Tabi
2010-11-10 19:51 ` Wolfgang Denk
2010-11-10 20:10 ` Timur Tabi
2010-11-10 20:34 ` Wolfgang Denk
2010-11-10 20:54 ` Timur Tabi [this message]
2010-11-10 21:13 ` Wolfgang Denk
2010-11-10 21:15 ` Timur Tabi
2010-11-10 21:30 ` Wolfgang Denk
2010-11-16 22:16 ` Timur Tabi
2010-11-16 23:10 ` Wolfgang Denk
2010-11-16 23:12 ` Timur Tabi
2010-11-16 23:29 ` Wolfgang Denk
2010-11-17 0:21 ` Tabi Timur-B04825
2010-11-10 21:12 ` Scott Wood
2010-11-10 21:30 ` Wolfgang Denk
2010-11-10 21:49 ` Scott Wood
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=4CDB0686.300@freescale.com \
--to=timur@freescale.com \
--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 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.