[PATCH] ARM: Include Makefile.boot only when it exists

[PATCH] ARM: Include Makefile.boot only when it exists

[Eric Miao]

If AUTO_ZRELADDR is selected and target is not uImage, the existence
of Makefile.boot could be optional.

Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
---
 arch/arm/boot/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 9128fdd..277368f 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -14,7 +14,7 @@
 MKIMAGE         := $(srctree)/scripts/mkuboot.sh
 
 ifneq ($(MACHINE),)
-include $(srctree)/$(MACHINE)/Makefile.boot
+-include $(srctree)/$(MACHINE)/Makefile.boot
 endif
 
 # Note: the following conditions must always be true:
-- 
1.7.1

[PATCH] ARM: Include Makefile.boot only when it exists

[Shawn Guo]

Hi Eric,

On Mon, Apr 18, 2011 at 01:19:36PM +0800, Eric Miao wrote:
> If AUTO_ZRELADDR is selected and target is not uImage, the existence
> of Makefile.boot could be optional.
> 
> Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
> ---
>  arch/arm/boot/Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> index 9128fdd..277368f 100644
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -14,7 +14,7 @@
>  MKIMAGE         := $(srctree)/scripts/mkuboot.sh
>  
>  ifneq ($(MACHINE),)
> -include $(srctree)/$(MACHINE)/Makefile.boot
> +-include $(srctree)/$(MACHINE)/Makefile.boot
   ^ Makefile grammar?
>  endif
>  
I do not understand the patch.  But looking at the patch below, the
dtb rule uses Makefile.boot too.

[PATCH v2] arm/dt: Add a make rule to build dtb for enabled boards
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/047129.html

-- 
Regards,
Shawn

[PATCH] ARM: Include Makefile.boot only when it exists

[Eric Miao]

On Wed, Apr 20, 2011 at 4:32 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> Hi Eric,
>
> On Mon, Apr 18, 2011 at 01:19:36PM +0800, Eric Miao wrote:
>> If AUTO_ZRELADDR is selected and target is not uImage, the existence
>> of Makefile.boot could be optional.
>>
>> Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
>> ---
>> ?arch/arm/boot/Makefile | ? ?2 +-
>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
>> index 9128fdd..277368f 100644
>> --- a/arch/arm/boot/Makefile
>> +++ b/arch/arm/boot/Makefile
>> @@ -14,7 +14,7 @@
>> ?MKIMAGE ? ? ? ? := $(srctree)/scripts/mkuboot.sh
>>
>> ?ifneq ($(MACHINE),)
>> -include $(srctree)/$(MACHINE)/Makefile.boot
>> +-include $(srctree)/$(MACHINE)/Makefile.boot
> ? ^ Makefile grammar?

Yes. GNU make will only include the file if it _exists_.

>> ?endif
>>
> I do not understand the patch. ?But looking at the patch below, the
> dtb rule uses Makefile.boot too.
>

Since originally there are only definitions like zreladdr defined in
Makefile.boot,
and with AUTO_ZRELADDR, some platforms do not need this definition any
more, which makes Makefile.boot useless on these platforms. Yet it does now
look like Makefile.boot is so far the best place for these DTB rules.

> [PATCH v2] arm/dt: Add a make rule to build dtb for enabled boards
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/047129.html
>
> --
> Regards,
> Shawn
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[PATCH] ARM: Include Makefile.boot only when it exists

[Shawn Guo]

On Wed, Apr 20, 2011 at 05:27:06PM +0800, Eric Miao wrote:
> On Wed, Apr 20, 2011 at 4:32 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> > Hi Eric,
> >
> > On Mon, Apr 18, 2011 at 01:19:36PM +0800, Eric Miao wrote:
> >> If AUTO_ZRELADDR is selected and target is not uImage, the existence
> >> of Makefile.boot could be optional.
> >>
> >> Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
> >> ---
> >> ?arch/arm/boot/Makefile | ? ?2 +-
> >> ?1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> >> index 9128fdd..277368f 100644
> >> --- a/arch/arm/boot/Makefile
> >> +++ b/arch/arm/boot/Makefile
> >> @@ -14,7 +14,7 @@
> >> ?MKIMAGE ? ? ? ? := $(srctree)/scripts/mkuboot.sh
> >>
> >> ?ifneq ($(MACHINE),)
> >> -include $(srctree)/$(MACHINE)/Makefile.boot
> >> +-include $(srctree)/$(MACHINE)/Makefile.boot
> > ? ^ Makefile grammar?
> 
> Yes. GNU make will only include the file if it _exists_.
> 
Ok, something learnt ...

> >> ?endif
> >>
> > I do not understand the patch. ?But looking at the patch below, the
> > dtb rule uses Makefile.boot too.
> >
> 
> Since originally there are only definitions like zreladdr defined in
> Makefile.boot,
> and with AUTO_ZRELADDR, some platforms do not need this definition any
> more, which makes Makefile.boot useless on these platforms. Yet it does now
> look like Makefile.boot is so far the best place for these DTB rules.
> 
... so your patch still stands, as DTB is also optional.

-- 
Regards,
Shawn

[PATCH] ARM: Include Makefile.boot only when it exists

[Uwe Kleine-König]

Hello,

On Wed, Apr 20, 2011 at 05:27:06PM +0800, Eric Miao wrote:
> On Wed, Apr 20, 2011 at 4:32 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> >> -include $(srctree)/$(MACHINE)/Makefile.boot
> >> +-include $(srctree)/$(MACHINE)/Makefile.boot
> > ? ^ Makefile grammar?
> 
> Yes. GNU make will only include the file if it _exists_.
To be more exact it will still try to "make" the include files if they
don't exist.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] ARM: Include Makefile.boot only when it exists

[Russell King - ARM Linux]

On Wed, Apr 20, 2011 at 05:27:06PM +0800, Eric Miao wrote:
> Since originally there are only definitions like zreladdr defined in
> Makefile.boot,
> and with AUTO_ZRELADDR, some platforms do not need this definition any
> more, which makes Makefile.boot useless on these platforms. Yet it does now
> look like Makefile.boot is so far the best place for these DTB rules.

Let's get this sorted out right now.  We know that Linus doesn't like
the current situation with lots of data tables in .c files in the kernel.
He explicitly doesn't like the conflicts and churn that it is causing.

If/when we move to DT, do people think that Linus is going to accept
having the DT files in the kernel for all these platforms, and will he
be happy to see stuff like the files containing the OMAP clock definitions
being constantly patched?  Remember, it's *exactly* this data which Linus
wants out of the kernel source.

I suspect the answer to that is no.  So I think we should start right now
with the idea that putting DT files - even the core SoC ones - into the
kernel isn't going to be acceptable.

[PATCH] ARM: Include Makefile.boot only when it exists

[Nicolas Pitre]

On Thu, 28 Apr 2011, Russell King - ARM Linux wrote:

> If/when we move to DT, do people think that Linus is going to accept
> having the DT files in the kernel for all these platforms, and will he
> be happy to see stuff like the files containing the OMAP clock definitions
> being constantly patched?  Remember, it's *exactly* this data which Linus
> wants out of the kernel source.

Well, here's what he said:

|But trust me, if you start doing a better job at platform code, I
|won't be complaining when I get lots of deleted code, or when I start
|getting devicetree descriptions instead of new drivers.
(http://article.gmane.org/gmane.linux.kernel/1121387)

So of course this "getting devicetree descriptions" might be interpreted 
to mean different things.

OTOH, the device tree source files can be arranged with common 
definitions in something like a header file that is included by board 
specific files.  So, at least in theory, differences between similar 
boards should be small, hopefully smaller than the equivalent in C.

Also, DT files should be a representation of the hardware which is meant 
to be stable.  If it wasn't stable, there would be no point using a data 
structure that can also be used outside of the kernel.  Remember that 
one of the selling point for DT is to be able to boot an existing kernel 
binary on yet-to-be-created hardware simply by creating the appropriate 
DT description for it.  Hence the DT files for existing hardware 
shouldn't have to change even if the kernel side implementation does.

> I suspect the answer to that is no.  So I think we should start right now
> with the idea that putting DT files - even the core SoC ones - into the
> kernel isn't going to be acceptable.

Well, if you look at arch/powerpc/boot/dts/* you'll find a bunch of 
board specific DT files in there already, and Linus has identified PPC 
as one architecture that did it right in his mind.


Nicolas

[PATCH] ARM: Include Makefile.boot only when it exists

[Russell King - ARM Linux]

On Thu, Apr 28, 2011 at 09:00:08PM -0400, Nicolas Pitre wrote:
> On Thu, 28 Apr 2011, Russell King - ARM Linux wrote:
> 
> > If/when we move to DT, do people think that Linus is going to accept
> > having the DT files in the kernel for all these platforms, and will he
> > be happy to see stuff like the files containing the OMAP clock definitions
> > being constantly patched?  Remember, it's *exactly* this data which Linus
> > wants out of the kernel source.
> 
> Well, here's what he said:
> 
> |But trust me, if you start doing a better job at platform code, I
> |won't be complaining when I get lots of deleted code, or when I start
> |getting devicetree descriptions instead of new drivers.
> (http://article.gmane.org/gmane.linux.kernel/1121387)
> 
> So of course this "getting devicetree descriptions" might be interpreted 
> to mean different things.
> 
> OTOH, the device tree source files can be arranged with common 
> definitions in something like a header file that is included by board 
> specific files.  So, at least in theory, differences between similar 
> boards should be small, hopefully smaller than the equivalent in C.
> 
> Also, DT files should be a representation of the hardware which is meant 
> to be stable.  If it wasn't stable, there would be no point using a data 
> structure that can also be used outside of the kernel.  Remember that 
> one of the selling point for DT is to be able to boot an existing kernel 
> binary on yet-to-be-created hardware simply by creating the appropriate 
> DT description for it.  Hence the DT files for existing hardware 
> shouldn't have to change even if the kernel side implementation does.
>
> > I suspect the answer to that is no.  So I think we should start right now
> > with the idea that putting DT files - even the core SoC ones - into the
> > kernel isn't going to be acceptable.
> 
> Well, if you look at arch/powerpc/boot/dts/* you'll find a bunch of 
> board specific DT files in there already, and Linus has identified PPC 
> as one architecture that did it right in his mind.

Sigh, you really don't understand.

For OMAP we're likely to see several dts files around 200K in size
describing _just_ the clock trees.  As we've seen, the OMAP clock tree
information is modified fairly regularly, adding new clocks, changing
flags, and so forth.

Linus wants this information _out_ of the kernel tree (remember he
referred to the "crazy clock files") which in his opinion should be in
some kind of pre-loader to the kernel and not the kernel itself.
Remember that this is what sparked this whole shebang in the first
place.

Merely moving it from a .c file to a .dts file doesn't move it out of
the kernel tree, and with the constant changes to it, it doesn't solve
the problem of the merge conflicts which Linus ultimately has to fix
up either.

Merely moving it from a .c file to a .dts file in the kernel tree
doesn't solve anything.  At all.  And it isn't going to make Linus
feel any happier about ARM.

[PATCH] ARM: Include Makefile.boot only when it exists

[Nicolas Pitre]

On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:

> On Thu, Apr 28, 2011 at 09:00:08PM -0400, Nicolas Pitre wrote:
> > On Thu, 28 Apr 2011, Russell King - ARM Linux wrote:
> > 
> > > If/when we move to DT, do people think that Linus is going to accept
> > > having the DT files in the kernel for all these platforms, and will he
> > > be happy to see stuff like the files containing the OMAP clock definitions
> > > being constantly patched?  Remember, it's *exactly* this data which Linus
> > > wants out of the kernel source.
> > 
> > Well, here's what he said:
> > 
> > |But trust me, if you start doing a better job at platform code, I
> > |won't be complaining when I get lots of deleted code, or when I start
> > |getting devicetree descriptions instead of new drivers.
> > (http://article.gmane.org/gmane.linux.kernel/1121387)
> > 
> > So of course this "getting devicetree descriptions" might be interpreted 
> > to mean different things.
> > 
> > OTOH, the device tree source files can be arranged with common 
> > definitions in something like a header file that is included by board 
> > specific files.  So, at least in theory, differences between similar 
> > boards should be small, hopefully smaller than the equivalent in C.
> > 
> > Also, DT files should be a representation of the hardware which is meant 
> > to be stable.  If it wasn't stable, there would be no point using a data 
> > structure that can also be used outside of the kernel.  Remember that 
> > one of the selling point for DT is to be able to boot an existing kernel 
> > binary on yet-to-be-created hardware simply by creating the appropriate 
> > DT description for it.  Hence the DT files for existing hardware 
> > shouldn't have to change even if the kernel side implementation does.
> >
> > > I suspect the answer to that is no.  So I think we should start right now
> > > with the idea that putting DT files - even the core SoC ones - into the
> > > kernel isn't going to be acceptable.
> > 
> > Well, if you look at arch/powerpc/boot/dts/* you'll find a bunch of 
> > board specific DT files in there already, and Linus has identified PPC 
> > as one architecture that did it right in his mind.
> 
> Sigh, you really don't understand.
> 
> For OMAP we're likely to see several dts files around 200K in size
> describing _just_ the clock trees.  As we've seen, the OMAP clock tree
> information is modified fairly regularly, adding new clocks, changing
> flags, and so forth.

What do I not understand?  Let me repeat myself again:

| DT files should be a representation of the hardware which is meant to 
| be stable. [...] Hence the DT files for existing hardware shouldn't 
| have to change even if the kernel side implementation does.

So there shouldn't be constant changes to those files as they are 
supposed to be hardware description only.

I agree that having a DT source file for every piece of hardware in 
existence out there being stuffed in the kernel tree is a bit silly.  
In a perfect world, the DT data would be tied and maintained with the 
bootloader, but I'm a bit skeptical about this going well given past 
history with even much simpler data. Therefore I think it is important 
to have at least a few ones being shipped with the kernel tree to 
provide at least a few reference cases for which the corresponding 
kernel code was tested and thus having some kind of officially validated 
combinations available.


Nicolas

[PATCH] ARM: Include Makefile.boot only when it exists

[Russell King - ARM Linux]

On Fri, Apr 29, 2011 at 08:32:59AM -0400, Nicolas Pitre wrote:
> On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:
> 
> > On Thu, Apr 28, 2011 at 09:00:08PM -0400, Nicolas Pitre wrote:
> > > On Thu, 28 Apr 2011, Russell King - ARM Linux wrote:
> > > 
> > > > If/when we move to DT, do people think that Linus is going to accept
> > > > having the DT files in the kernel for all these platforms, and will he
> > > > be happy to see stuff like the files containing the OMAP clock definitions
> > > > being constantly patched?  Remember, it's *exactly* this data which Linus
> > > > wants out of the kernel source.
> > > 
> > > Well, here's what he said:
> > > 
> > > |But trust me, if you start doing a better job at platform code, I
> > > |won't be complaining when I get lots of deleted code, or when I start
> > > |getting devicetree descriptions instead of new drivers.
> > > (http://article.gmane.org/gmane.linux.kernel/1121387)
> > > 
> > > So of course this "getting devicetree descriptions" might be interpreted 
> > > to mean different things.
> > > 
> > > OTOH, the device tree source files can be arranged with common 
> > > definitions in something like a header file that is included by board 
> > > specific files.  So, at least in theory, differences between similar 
> > > boards should be small, hopefully smaller than the equivalent in C.
> > > 
> > > Also, DT files should be a representation of the hardware which is meant 
> > > to be stable.  If it wasn't stable, there would be no point using a data 
> > > structure that can also be used outside of the kernel.  Remember that 
> > > one of the selling point for DT is to be able to boot an existing kernel 
> > > binary on yet-to-be-created hardware simply by creating the appropriate 
> > > DT description for it.  Hence the DT files for existing hardware 
> > > shouldn't have to change even if the kernel side implementation does.
> > >
> > > > I suspect the answer to that is no.  So I think we should start right now
> > > > with the idea that putting DT files - even the core SoC ones - into the
> > > > kernel isn't going to be acceptable.
> > > 
> > > Well, if you look at arch/powerpc/boot/dts/* you'll find a bunch of 
> > > board specific DT files in there already, and Linus has identified PPC 
> > > as one architecture that did it right in his mind.
> > 
> > Sigh, you really don't understand.
> > 
> > For OMAP we're likely to see several dts files around 200K in size
> > describing _just_ the clock trees.  As we've seen, the OMAP clock tree
> > information is modified fairly regularly, adding new clocks, changing
> > flags, and so forth.
> 
> What do I not understand?  Let me repeat myself again:
> 
> | DT files should be a representation of the hardware which is meant to 
> | be stable. [...] Hence the DT files for existing hardware shouldn't 
> | have to change even if the kernel side implementation does.
> 
> So there shouldn't be constant changes to those files as they are 
> supposed to be hardware description only.

You really haven't seen what goes on in the OMAP community then.  If
you think its possible to come up with a hardware description of the
OMAP clock tree which is right first time, you're in cloud cuckoo land.

Even the OMAP4 clock data which is supposedly generated from TIs
internal hardware database changes on a fairly regular basis.  You'll
find that the per-clk flags get changed, the operations get changed,
etc.

It doesn't _matter_ how it is represented, it will continue to be patched
whether it's structures in a .c file (as it currently is) or whether it's
a device tree description for each clock.

So please, get rid of this stupid idea that its possible to come up with
a One True Hardware Description which is fixed for all time.

[PATCH] ARM: Include Makefile.boot only when it exists

[Nicolas Pitre]

On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:

> On Fri, Apr 29, 2011 at 08:32:59AM -0400, Nicolas Pitre wrote:
> > What do I not understand?  Let me repeat myself again:
> > 
> > | DT files should be a representation of the hardware which is meant to 
> > | be stable. [...] Hence the DT files for existing hardware shouldn't 
> > | have to change even if the kernel side implementation does.
> > 
> > So there shouldn't be constant changes to those files as they are 
> > supposed to be hardware description only.
> 
> You really haven't seen what goes on in the OMAP community then.  If
> you think its possible to come up with a hardware description of the
> OMAP clock tree which is right first time, you're in cloud cuckoo land.

(sigh) I wish you were wrong on that, but admittedly I'm highly skeptical 
myself.

> Even the OMAP4 clock data which is supposedly generated from TIs
> internal hardware database changes on a fairly regular basis.  You'll
> find that the per-clk flags get changed, the operations get changed,
> etc.
> 
> It doesn't _matter_ how it is represented, it will continue to be patched
> whether it's structures in a .c file (as it currently is) or whether it's
> a device tree description for each clock.

If that is the case, the associated drivers have to change as well to be 
in sync with the new flags, etc.  And to me it is way better to have 
both the data and the drivers maintained in a single place compared to 
the unavoidable bugs that will crop up due to version skews.

Unfortunately, and IMHO, this whole drama has put one spotlight on the 
OMAP clock tables, but that alone is not such a problem in the big 
picture compared to the issue of code duplication which is actually a 
real maintenance problem.  And now we of course have to throw out the 
baby with the bath water.

Whatever... Rest assured that you are not the one to blame here.


Nicolas

[PATCH] ARM: Include Makefile.boot only when it exists

[Brian Swetland]

On Fri, Apr 29, 2011 at 12:43 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:
>>
>> Even the OMAP4 clock data which is supposedly generated from TIs
>> internal hardware database changes on a fairly regular basis. ?You'll
>> find that the per-clk flags get changed, the operations get changed,
>> etc.
>>
>> It doesn't _matter_ how it is represented, it will continue to be patched
>> whether it's structures in a .c file (as it currently is) or whether it's
>> a device tree description for each clock.
>
> If that is the case, the associated drivers have to change as well to be
> in sync with the new flags, etc. ?And to me it is way better to have
> both the data and the drivers maintained in a single place compared to
> the unavoidable bugs that will crop up due to version skews.

This is a one reason why I'm skeptical of the "device tree" approach
and somewhat concerned about a potential future where board files
would vanish, to be replaced by device trees which may well come from
some place disconnected from the kernel that will depend on them being
correct to work.

I live in a world where the bootloader is often a black box and rarely
updated. Mobile device OEMs usually have their own bootloader
(nothing standard nor open source) which is closely tied to their
factory process and testing, etc.  Having to trust the bootloader to
get anything right beyond passing me a machine type, system revision,
and a commandline is pretty scary.  Add to that the fact that
bootloaders often aren't updated in the field (it's the riskiest piece
of the system to update).

The other reason is that I've rarely seen a board spin that didn't
involve some quirky change that would be hard to represent in a static
configuration format.  Oh, you need to power up this level shifter
before you can talk to the back half of that i2c bus, by way of this
gpio over here?  Eventually you end up with something like a byte-code
or forth runtime to handle these cases and then things really get fun
from the "where's the code that does what?!" standpoint.

Brian

[PATCH] ARM: Include Makefile.boot only when it exists

[Mark Brown]

On Sat, Apr 30, 2011 at 01:44:15AM -0700, Brian Swetland wrote:
> On Fri, Apr 29, 2011 at 12:43 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Fri, 29 Apr 2011, Russell King - ARM Linux wrote:

> >> It doesn't _matter_ how it is represented, it will continue to be patched
> >> whether it's structures in a .c file (as it currently is) or whether it's
> >> a device tree description for each clock.

> > If that is the case, the associated drivers have to change as well to be
> > in sync with the new flags, etc. ??And to me it is way better to have
> > both the data and the drivers maintained in a single place compared to
> > the unavoidable bugs that will crop up due to version skews.

> This is a one reason why I'm skeptical of the "device tree" approach
> and somewhat concerned about a potential future where board files
> would vanish, to be replaced by device trees which may well come from
> some place disconnected from the kernel that will depend on them being
> correct to work.

I agree for that particular argument for device tree - I've had to push
back on some of the audio drivers that use device tree currently, the
maintainers were trying to push changes which would result in an
immediate ABI break in the device tree files.  That sort of stuff is
completely insane 

This sort of stuff is the major reason for supporting multiple DT blobs
- it allows the descriptions of the chip internals outside of the per
board device tree so we could ship that bit in the kernel (I know Russel
is pushing back against that right now but...).

> The other reason is that I've rarely seen a board spin that didn't
> involve some quirky change that would be hard to represent in a static
> configuration format.  Oh, you need to power up this level shifter
> before you can talk to the back half of that i2c bus, by way of this
> gpio over here?  Eventually you end up with something like a byte-code
> or forth runtime to handle these cases and then things really get fun
> from the "where's the code that does what?!" standpoint.

This sort of thing is more a problem in the smartphone space - they're
generally pushing pretty much any limit you can think of here.  For 
lower complexity/density designs it tends to be more plausible to just
describe the system this way.

My expectation is that device tree will help quite a lot with designs
that don't push the limits quite so hard, which there are quite a lot of
out there.

[PATCH] ARM: Include Makefile.boot only when it exists

[Shawn Guo]

Hi Russell,

On Fri, Apr 29, 2011 at 08:53:46AM +0100, Russell King - ARM Linux wrote:
[...]
> Linus wants this information _out_ of the kernel tree (remember he
> referred to the "crazy clock files") which in his opinion should be in
> some kind of pre-loader to the kernel and not the kernel itself.
> Remember that this is what sparked this whole shebang in the first
> place.
> 
If I understand correctly, you are suggesting put dts into bootloader
tree.  Here are the possible problems I can see.

* Thought u-boot is the most popular bootloader, it's not the only
  option.  Some platforms sitting on mainline does not use it, e.g.
  mach-mxs.  That means the dts file for the same platform has to
  get maintained in various bootloader tree.

* Maintaining dts file in bootloader tree will get kernel depend on
  bootloader so heavily.  The kernel code and dts file will easily
  get out of sync, which may stop kernel booting immediately.

Also, I failed to understand how Linus could complain about getting
dts files maintained in kernel tree, which is the thing that powerpc
have been doing for quite some time.  As dtc is sitting in the
kernel tree (scripts/dtc/), it's hard for me to understand why dts
can not be put in the tree.

-- 
Regards,
Shawn

[PATCH] ARM: Include Makefile.boot only when it exists

[Russell King - ARM Linux]

On Fri, Apr 29, 2011 at 09:32:24PM +0800, Shawn Guo wrote:
> Hi Russell,
> 
> On Fri, Apr 29, 2011 at 08:53:46AM +0100, Russell King - ARM Linux wrote:
> [...]
> > Linus wants this information _out_ of the kernel tree (remember he
> > referred to the "crazy clock files") which in his opinion should be in
> > some kind of pre-loader to the kernel and not the kernel itself.
> > Remember that this is what sparked this whole shebang in the first
> > place.
> > 
> If I understand correctly, you are suggesting put dts into bootloader
> tree.  Here are the possible problems I can see.

No, I'm talking about putting it into an entirely separate "ARM
device tree description" project.

> Also, I failed to understand how Linus could complain about getting
> dts files maintained in kernel tree, which is the thing that powerpc
> have been doing for quite some time.  As dtc is sitting in the
> kernel tree (scripts/dtc/), it's hard for me to understand why dts
> can not be put in the tree.

You need to read:

http://lists.arm.linux.org.uk/lurker/message/20110330.192132.f01e0669.en.html

and understand Linus' position on this:

   Something needs to be done. A small part is to make sure the source
   code is more hierarchical, so that we don't have those crazy shared
   data-files that are ugly as hell and get conflicts because different
   boards all think they need to care.

|| But the larger problem is that somebody really REALLY needs to think   ||
|| about how to get those crazy board details out of the kernel entirely. ||
|| Having per-board drivers for real hardware is sane - having to have    ||
|| per-board detail files for clock chips is just crazy. Split off that   ||
|| thing a "Linux ARM second-stage bootloader" project that has the       ||
|| per-board tables or something. Don't pollute the main kernel with      ||
|| crazy details like this.                                               ||

That is pretty clear to me that Linus does _not_ want these kinds of
details in the main kernel source _at_ _all_.  No matter how they're
represented, be it .c file or .dts file.

[PATCH] ARM: Include Makefile.boot only when it exists

[Mark Brown]

On Fri, Apr 29, 2011 at 02:47:46PM +0100, Russell King - ARM Linux wrote:

> http://lists.arm.linux.org.uk/lurker/message/20110330.192132.f01e0669.en.html

> and understand Linus' position on this:

>    Something needs to be done. A small part is to make sure the source
>    code is more hierarchical, so that we don't have those crazy shared
>    data-files that are ugly as hell and get conflicts because different
>    boards all think they need to care.

> || But the larger problem is that somebody really REALLY needs to think   ||
> || about how to get those crazy board details out of the kernel entirely. ||
> || Having per-board drivers for real hardware is sane - having to have    ||
> || per-board detail files for clock chips is just crazy. Split off that   ||
> || thing a "Linux ARM second-stage bootloader" project that has the       ||
> || per-board tables or something. Don't pollute the main kernel with      ||
> || crazy details like this.                                               ||

> That is pretty clear to me that Linus does _not_ want these kinds of
> details in the main kernel source _at_ _all_.  No matter how they're
> represented, be it .c file or .dts file.

Reading this he's talking a lot about "per-board" things, but what he's
talking about is things which should be done once per chip.  There does
seem to be some room for discussion here, "actually what you're seeing
here is X, here's why we don't want to start doing Y" type things.

[PATCH] ARM: Include Makefile.boot only when it exists

[Richard Cochran]

On Fri, Apr 29, 2011 at 09:32:24PM +0800, Shawn Guo wrote:
> 
> * Maintaining dts file in bootloader tree will get kernel depend on
>   bootloader so heavily.  The kernel code and dts file will easily
>   get out of sync, which may stop kernel booting immediately.

The kernel already depends on the bootloader heavily, at least for
Freescale powerpc boards. If you don't believe me, just try and freely
mix and match kernel/uboot/dts over a few minor versions or so, and
see what happens...

Richard

[PATCH] ARM: Include Makefile.boot only when it exists

[Richard Cochran]

On Thu, Apr 28, 2011 at 09:00:08PM -0400, Nicolas Pitre wrote:
 
> Remember that one of the selling point for DT is to be able to boot
> an existing kernel binary on yet-to-be-created hardware simply by
> creating the appropriate DT description for it.

So, can you report from your own experience that it really works like
that?

I surely cannot.

Richard

[PATCH] ARM: Include Makefile.boot only when it exists

[Nicolas Pitre]

On Sun, 1 May 2011, Richard Cochran wrote:

> On Thu, Apr 28, 2011 at 09:00:08PM -0400, Nicolas Pitre wrote:
>  
> > Remember that one of the selling point for DT is to be able to boot
> > an existing kernel binary on yet-to-be-created hardware simply by
> > creating the appropriate DT description for it.
> 
> So, can you report from your own experience that it really works like
> that?

No.  I'm firmly in the DT-still-has-to-prove-itself camp and I wish I 
I'd never had to deal with it.  I believe that the current way for 
configuring hardware on ARM is more reliable and less prone to errors 
and bugs such as what you described about Freescale powerpc boards.  

And for the record I don't believe the current crisis about ARM board 
code duplication can be directly linked to the lack of DT support on ARM 
even if many people are blending those issues together.

> I surely cannot.

If so then this whole DT idea has been oversold with false pretenses.  
In good faith I'm willing to try it out and so I'm working towards its 
implementation for ARM not against it, but if the DTS files are to be 
maintained out of tree then all I can see for the future is additional 
maintenance pain not less.


Nicolas

[PATCH] ARM: Include Makefile.boot only when it exists

[Richard Cochran]

On Sun, May 01, 2011 at 09:07:53AM -0400, Nicolas Pitre wrote:
> On Sun, 1 May 2011, Richard Cochran wrote:
> 
> > On Thu, Apr 28, 2011 at 09:00:08PM -0400, Nicolas Pitre wrote:
> >  
> > > Remember that one of the selling point for DT is to be able to boot
> > > an existing kernel binary on yet-to-be-created hardware simply by
> > > creating the appropriate DT description for it.
> > 
> > So, can you report from your own experience that it really works like
> > that?
> 
> No.  I'm firmly in the DT-still-has-to-prove-itself camp and I wish I 
> I'd never had to deal with it.  I believe that the current way for 
> configuring hardware on ARM is more reliable and less prone to errors 
> and bugs such as what you described about Freescale powerpc boards.  

Yes, I would agree that the current way works well.

> And for the record I don't believe the current crisis about ARM board 
> code duplication can be directly linked to the lack of DT support on ARM 
> even if many people are blending those issues together.

Sometimes it seems that DT is being promoted as a silver bullet.
 
> > I surely cannot.
> 
> If so then this whole DT idea has been oversold with false pretenses.  
> In good faith I'm willing to try it out and so I'm working towards its 
> implementation for ARM not against it, but if the DTS files are to be 
> maintained out of tree then all I can see for the future is additional 
> maintenance pain not less.

I think the DT advocates really believe in it (not with false, but
honest pretenses). Also, I agree that DT sounds great in theory, but,
in my experience, it has been not so great in practice.

Richard