Device tree.

Device tree.

[Ian Molton]

I've found some references to this in the mailinglist archives but 
nothing conclusive.

Whats the recommended way of dealing with devicetree when one is stuck 
with an unco-operative bootloader?

I've made a small hack (below) to allow me to append a .dtb to the end 
of the kernel image. I note that other similar hacks have not been 
picked up, but I can't see why. Or I've missed the one that did get chosen.

TTFN!

-Ian

------------------------------- arch/arm/Kconfig 
-------------------------------
index 519b5e0..cd82cbc 100644
@@ -1105,6 +1105,10 @@ source "arch/arm/mach-vt8500/Kconfig"

  source "arch/arm/mach-w90x900/Kconfig"

+config EMBEDDED_DTB
+    string "Embedded device tree blob" if OF
+    default ""
+
  # Definitions to make life easier
  config ARCH_ACORN
      bool

---------------------------- arch/arm/boot/Makefile 
----------------------------
index c877087..8e43741 100644
@@ -44,6 +44,9 @@ $(obj)/xipImage: FORCE
      @echo 'Kernel not configured for XIP (CONFIG_XIP_KERNEL!=y)'
      @false

+#append Device Tree .dtb file after vmlinux
+cmd_do_append_dtb = if [ "$(CONFIG_EMBEDDED_DTB)" != "" ]; then cat 
$(CONFIG_EMBEDDED_DTB) >> $@ ; fi
+
  $(obj)/Image: vmlinux FORCE
      $(call if_changed,objcopy)
      @echo '  Kernel: $@ is ready'
@@ -53,6 +56,7 @@ $(obj)/compressed/vmlinux: $(obj)/Image FORCE

  $(obj)/zImage:    $(obj)/compressed/vmlinux FORCE
      $(call if_changed,objcopy)
+    $(call if_changed,do_append_dtb)
      @echo '  Kernel: $@ is ready'

  endif

Device tree.

[Thomas Petazzoni]

Le Tue, 17 Jul 2012 12:55:53 +0100,
Ian Molton <ian.molton@codethink.co.uk> a ?crit :

> I've found some references to this in the mailinglist archives but 
> nothing conclusive.
> 
> Whats the recommended way of dealing with devicetree when one is
> stuck with an unco-operative bootloader?
> 
> I've made a small hack (below) to allow me to append a .dtb to the
> end of the kernel image. I note that other similar hacks have not
> been picked up, but I can't see why. Or I've missed the one that did
> get chosen.

You surely want to have a look at CONFIG_ARM_APPENDED_DTB, which does
what you want and is already part of the ARM kernel.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Device tree.

[Ian Molton]

On 17/07/12 13:01, Thomas Petazzoni wrote:
> You surely want to have a look at CONFIG_ARM_APPENDED_DTB, which does 
> what you want and is already part of the ARM kernel.

Hi, and thanks.

Unless I'm misunderstanding it, thats not quite what I need - although I 
should probably have made my hack depend on it.

I'm using a uImage; The prepending needs to happen to the zImage / Image.

-Ian

Device tree.

[Thomas Petazzoni]

Le Tue, 17 Jul 2012 13:13:03 +0100,
Ian Molton <ian.molton@codethink.co.uk> a ?crit :

> Unless I'm misunderstanding it, thats not quite what I need -
> although I should probably have made my hack depend on it.
> 
> I'm using a uImage; The prepending needs to happen to the zImage /
> Image.

What I typically do is generate a zImage, do the appending, and then
generate the uImage manually with mkimage. But I agree it could be
useful to have a 'make uImage.myboard' target which would happen the
myboard.dtb before preparing the uImage.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Device tree.

[Josh Coombs]

On Tue, Jul 17, 2012 at 8:13 AM, Ian Molton <ian.molton@codethink.co.uk> wrote:
> On 17/07/12 13:01, Thomas Petazzoni wrote:
>>
>> You surely want to have a look at CONFIG_ARM_APPENDED_DTB, which does what
>> you want and is already part of the ARM kernel.
>
>
> Hi, and thanks.
>
> Unless I'm misunderstanding it, thats not quite what I need - although I
> should probably have made my hack depend on it.
>
> I'm using a uImage; The prepending needs to happen to the zImage / Image.
>
> -Ian

CONFIG_ARM_APPENDED_DTB sets the kernel up to expect a dtb appended to
the end of the zImage.  Neither make or make uImage do the appending
for you however.  What I've been doing is:

make
make target.dtb
cat arch/arm/boot/target.dtb >> arch/arm/boot/zImage
make uImage
move arch/arm/boot/uImage to wherever it needs to be and try booting

My understanding is you can only append one DTB, there is no
restriction on how many systems a given kernel could support, so at
the moment there isn't a clean way of defining which DTB to append
during make uImage?

Josh C

Device tree.

[Florian Fainelli]

On Tuesday 17 July 2012 14:29:26 Thomas Petazzoni wrote:
> Le Tue, 17 Jul 2012 13:13:03 +0100,
> Ian Molton <ian.molton@codethink.co.uk> a ?crit :
> 
> > Unless I'm misunderstanding it, thats not quite what I need -
> > although I should probably have made my hack depend on it.
> > 
> > I'm using a uImage; The prepending needs to happen to the zImage /
> > Image.
> 
> What I typically do is generate a zImage, do the appending, and then
> generate the uImage manually with mkimage. But I agree it could be
> useful to have a 'make uImage.myboard' target which would happen the
> myboard.dtb before preparing the uImage.

Appending a given device tree blob to a zImage is something that should be 
solved outside of the kernel build imho.

Since your bootloader is already "non-cooperative" wrt DTBs, you need to 
provide a specific uImage (zImage + dtb) for it.

I do not think the kernel build should try to generate as many zImages as 
there dtb files, nor any other combination, this really is distribution 
specific.
--
Florian

Device tree.

[Ian Molton]

On 17/07/12 13:32, Josh Coombs wrote:
> make make target.dtb
> cat arch/arm/boot/target.dtb  >> arch/arm/boot/zImage
 >make uImage

Yick...

 >My understanding is you can
 > only append one DTB, there is no restriction on how many systems a
 > given kernel could support, so at the moment there isn't a clean way
 > of defining which DTB to append during make uImage? Josh C

Yes, hence why it'd be useful to have a way of specifying a .dtb file as 
a config option...

There isnt really a good way to solve this, AFAICT.

-Ian

Device tree.

[Ben Dooks]

On 17/07/2012 14:07, Ian Molton wrote:
> On 17/07/12 13:32, Josh Coombs wrote:
>> make make target.dtb
>> cat arch/arm/boot/target.dtb  >> arch/arm/boot/zImage
>>make uImage
>
> Yick...

How about adding a dts=<address> argument to the current
command line handling. If this is found, then the system
ignores the rest of the atags passed and uses the passed
address for the device-tree settings.

This means in u-boot, you just need to load the .dts file
into place before booting the kernel.

-- 
Ben

Device tree.

[Thomas Petazzoni]

Le Tue, 17 Jul 2012 14:41:35 +0200,
Florian Fainelli <florian@openwrt.org> a ?crit :

> > What I typically do is generate a zImage, do the appending, and then
> > generate the uImage manually with mkimage. But I agree it could be
> > useful to have a 'make uImage.myboard' target which would happen the
> > myboard.dtb before preparing the uImage.
> 
> Appending a given device tree blob to a zImage is something that
> should be solved outside of the kernel build imho.

Well, both PowerPC and Microblaze, and apparently C6X, have some sort
of <imageFormat>.<dtbName> make target:

$ make ARCH=microblaze help
[...]
  simpleImage.<dt> - ELF image with /boot/dts/<dt>.dts linked in
                   - stripped elf with fdt blob
  simpleImage.<dt>.unstrip - full ELF image with fdt blob

$ make ARCH=powerpc help
[...]
  cuImage.<dt>    - Backwards compatible U-Boot image for older
                    versions which do not support device trees
  dtbImage.<dt>   - zImage with an embedded device tree blob
  simpleImage.<dt> - Firmware independent image.
  treeImage.<dt>  - Support for older IBM 4xx firmware (not U-Boot)

$ make ARCH=c6x help
[...]
  dtbImage.<dt>   - ELF image with /boot/dts/<dt>.dts linked in
                  - stripped elf with fdt blob

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Device tree.

[Rob Herring]

On 07/17/2012 08:25 AM, Ben Dooks wrote:
> On 17/07/2012 14:07, Ian Molton wrote:
>> On 17/07/12 13:32, Josh Coombs wrote:
>>> make make target.dtb
>>> cat arch/arm/boot/target.dtb  >> arch/arm/boot/zImage
>>> make uImage
>>
>> Yick...
> 
> How about adding a dts=<address> argument to the current
> command line handling. If this is found, then the system
> ignores the rest of the atags passed and uses the passed
> address for the device-tree settings.
> 
> This means in u-boot, you just need to load the .dts file
> into place before booting the kernel.
> 
You mean dtb...

But no, we don't need a 3rd boot interface in the kernel. I don't see
why cat + mkimage is too hard to run.

Now that u-boot has direct support for zImage booting, I doubt anything
uImage building related will ever be accepted into the kernel.

Rob

Device tree.

[Ben Dooks]

On 17/07/2012 14:52, Rob Herring wrote:
> On 07/17/2012 08:25 AM, Ben Dooks wrote:
>> On 17/07/2012 14:07, Ian Molton wrote:
>>> On 17/07/12 13:32, Josh Coombs wrote:
>>>> make make target.dtb
>>>> cat arch/arm/boot/target.dtb  >> arch/arm/boot/zImage
>>>> make uImage
>>>
>>> Yick...
>>
>> How about adding a dts=<address> argument to the current
>> command line handling. If this is found, then the system
>> ignores the rest of the atags passed and uses the passed
>> address for the device-tree settings.
>>
>> This means in u-boot, you just need to load the .dts file
>> into place before booting the kernel.
>>
> You mean dtb...
>
> But no, we don't need a 3rd boot interface in the kernel. I don't see
> why cat + mkimage is too hard to run.

I suppose we can produce our own build-script

> Now that u-boot has direct support for zImage booting, I doubt 
> anything
> uImage building related will ever be accepted into the kernel.

Depends on u-boot, the one we have been supplied doesn't seem to
have any interest in booting zImages.

-- 
Ben

Device tree.

[Florian Fainelli]

On Tuesday 17 July 2012 14:56:33 Ben Dooks wrote:
> On 17/07/2012 14:52, Rob Herring wrote:
> > On 07/17/2012 08:25 AM, Ben Dooks wrote:
> >> On 17/07/2012 14:07, Ian Molton wrote:
> >>> On 17/07/12 13:32, Josh Coombs wrote:
> >>>> make make target.dtb
> >>>> cat arch/arm/boot/target.dtb  >> arch/arm/boot/zImage
> >>>> make uImage
> >>>
> >>> Yick...
> >>
> >> How about adding a dts=<address> argument to the current
> >> command line handling. If this is found, then the system
> >> ignores the rest of the atags passed and uses the passed
> >> address for the device-tree settings.
> >>
> >> This means in u-boot, you just need to load the .dts file
> >> into place before booting the kernel.
> >>
> > You mean dtb...
> >
> > But no, we don't need a 3rd boot interface in the kernel. I don't see
> > why cat + mkimage is too hard to run.
> 
> I suppose we can produce our own build-script
> 
> > Now that u-boot has direct support for zImage booting, I doubt 
> > anything
> > uImage building related will ever be accepted into the kernel.
> 
> Depends on u-boot, the one we have been supplied doesn't seem to
> have any interest in booting zImages.

In that case you just need to make sure that you produce a valid uImage of 
your zImage+dtb appended. This is what I use on old (1.1.6) uboot versions 
without any issues.
--
Florian

Device tree.

[Mark Brown]

On Tue, Jul 17, 2012 at 08:52:34AM -0500, Rob Herring wrote:
> On 07/17/2012 08:25 AM, Ben Dooks wrote:

> > This means in u-boot, you just need to load the .dts file
> > into place before booting the kernel.

> You mean dtb...

> But no, we don't need a 3rd boot interface in the kernel. I don't see
> why cat + mkimage is too hard to run.

> Now that u-boot has direct support for zImage booting, I doubt anything
> uImage building related will ever be accepted into the kernel.

u-boot isn't the only bootloader that does uImage, and of course the
issue here is people stuck with old bootloaders that they don't want to
upgrade for whatever reason (or just don't want to let the bootloader
know about DT due to the incompatibility with non-DT kernels) so the
availability of new bootloaders doesn't help as much as it should.

Device tree.

[Ian Molton]

On 17/07/12 15:02, Florian Fainelli wrote:
> Depends on u-boot, the one we have been supplied doesn't seem to
> have any interest in booting zImages.
> In that case you just need to make sure that you produce a valid uImage of
> your zImage+dtb appended. This is what I use on old (1.1.6) uboot versions
> without any issues.

Thats what my little patch does. It just makes life a bit less painful 
if you're stuck with a particular bootloader. Its not an uncommon problem.

-Ian

Device tree.

[Nicolas Pitre]

On Tue, 17 Jul 2012, Ian Molton wrote:

> On 17/07/12 15:02, Florian Fainelli wrote:
> > Depends on u-boot, the one we have been supplied doesn't seem to
> > have any interest in booting zImages.
> > In that case you just need to make sure that you produce a valid uImage of
> > your zImage+dtb appended. This is what I use on old (1.1.6) uboot versions
> > without any issues.
> 
> Thats what my little patch does. It just makes life a bit less painful if
> you're stuck with a particular bootloader. Its not an uncommon problem.

That pain is the only leverage we have to have you fix the bootloader 
somehow.  If you prefer or have to bodge around it then you keep the 
hack for yourself.

We want people to get into the habit of building and distributing a 
generic kernel image.  Appending a dtb to zImage and/or wrapping it into 
a uImage should be considered installation steps which are best done 
outside of the kernel build system.  And they are quite trivial to do as 
well.


Nicolas

Device tree.

[Ian Molton]

On 17/07/12 22:18, Nicolas Pitre wrote:

> That pain is the only leverage  we have to have you fix the bootloader
 > somehow.

Yes, because this tactic has worked just great historically...

Other than chainbooting /another/ bootloader, how do you propose people 
fix this issue? Not everyone has a co-operative vendor.

> If you prefer or have to bodge  around it then you keep the
 > hack for yourself.

And for those of us where this is not an option?

> We want people to get into the  habit of building and distributing a
 > generic kernel image.

Which is all lovely, but sometimes simply not appropriate.

> Appending a dtb to zImage  and/or wrapping it
 > into a uImage should be considered installation steps which are best
 > done outside of the kernel build system. And they are quite trivial
 > to do as well.

Then perhaps the 'hack' to allow appending should be removed from the 
kernel, too, by the same logic - after all, its only 'enabling' people 
to cling to ancient bootloaders...

Honestly, all the fuss about "R2 + ATAGS must be the only way", and now 
we can pass in data in non-ATAG form, via appending to the kernel image, 
at whatever random location that might wind up being.

Either ATAGs the only way, or they aren't. If appending to zImage is 
'way 2' then it should be possible to choose what gets appended at build 
time. If not, the option has no business being in the kernel at all. Do 
it properly or not at all.

Whats the point in make uImage if you cant use it?

Device tree.

[Nicolas Pitre]

On Wed, 18 Jul 2012, Ian Molton wrote:

> On 17/07/12 22:18, Nicolas Pitre wrote:
> 
> > That pain is the only leverage  we have to have you fix the bootloader
> > somehow.
> 
> Yes, because this tactic has worked just great historically...

It certainly did.  Look at the latest u-Boot which 1) has support for 
device tree on ARM, and 2) has support to boot a zImage directly.  And 
some people were able to modify their old u-Boot as well because of this 
policy.

> Other than chainbooting /another/ bootloader, how do you propose people fix
> this issue? Not everyone has a co-operative vendor.

Ask your vendor harder.  They would care even less if the kernel was 
more accommodating.

> > If you prefer or have to bodge  around it then you keep the
> > hack for yourself.
> 
> And for those of us where this is not an option?

This is always an option to you.  You have the patch already, it doesn't 
necessarily have to live in mainline.

> > We want people to get into the  habit of building and distributing a
> > generic kernel image.
> 
> Which is all lovely, but sometimes simply not appropriate.

Please deal with it.  Going the other way isn't appropriate for mainline 
either.

> > Appending a dtb to zImage  and/or wrapping it
> > into a uImage should be considered installation steps which are best
> > done outside of the kernel build system. And they are quite trivial
> > to do as well.
> 
> Then perhaps the 'hack' to allow appending should be removed from the kernel,
> too, by the same logic - after all, its only 'enabling' people to cling to
> ancient bootloaders...

Absolutely.  But it is there now and that's the extent of what mainline 
is providing in terms of accommodation.

> Honestly, all the fuss about "R2 + ATAGS must be the only way", and now we can
> pass in data in non-ATAG form, via appending to the kernel image, at whatever
> random location that might wind up being.
> 
> Either ATAGs the only way, or they aren't. If appending to zImage is 'way 2'
> then it should be possible to choose what gets appended at build time. If not,
> the option has no business being in the kernel at all. Do it properly or not
> at all.

The "proper" way is to remove the DTB append option and force everyone 
to use a DT aware bootloader.  Are you ready for that?

Instead, we made a compromise which is to let you append a DTB to 
zImage.

> Whats the point in make uImage if you cant use it?

I advocated its removal for quite a long time now.  But it is still 
there which is also a compromise.  This way, people with ancient target 
which are not DT enabled aren't affected.


Nicolas

Device tree.

[Ian Molton]

On 18/07/12 14:42, Nicolas Pitre wrote

TL;DR: Summary

* make uImage is *broken* with CONFIG_ARM_APPENDED_DTB
* Trimmed down single-configuration kernels have merit. forcing
   .dtb to be passed from the bootloader
   - Increases bootloader complexity
     - and we know bootloaders suck and can be hard (if not impossible)
       to replace.
   - buys you nothing.
* Three other architectures support
   'make <image>.<embedded_dtb>'
* Old bootloaders cant always be replaced (ROM) or chainload (lack
   of flash) a newer one.
* No way to pass a .dtb address on the kernel commandline (where
   the bootloader cant pass it in a register, but can load arbitrary data
   into RAM, which most u-boot versions can.)

Conclusion:

There are three 'real' solutions, IMO.
1) Copy the other arches, and have make <image>.<embedded_dtb>
   - dtb could be properly embedded, linked into the kernel image.
   - makes for a consistent way of building images across more archs.
   - allows for simpler bootloaders.

2) Display a warning when building a uImage with
CONFIG_ARM_APPENDED_DTB, because that simply wont work the way
things are now.
   - Doesn't really fix anything, but at least it helps people see why
     its not working...

3) Add an option to specify the address of a .dtb file in RAM via
the kernel commandline.
  - removes the need for appending .dtb files to the kernel
  - still requires the bootloader to grok .dtb

 >> Yes, because this tactic has worked just great historically...
 >
 > It certainly did.  Look at the latest u-Boot which 1) has support
 > for device tree on ARM, and 2) has support to boot a zImage
 > directly. And some people were able to modify their old u-Boot as
 > well because of this policy.

I don't agree. u-boot has always been the weirdo that didnt just use a
zImage. Its taken *years* for that to change, and its not like uImages
were /ever/ easier to work with. I'd say the very presence of
'make uImage' slowed that change to a near halt.

 >> Other than chainbooting /another/ bootloader, how do you propose
 >> people fix this issue? Not everyone has a co-operative vendor.
 >
 > Ask your vendor harder.  They would care even less if the kernel was
 > more accommodating.

They don't care anyway - vendors never have. They just ship some
cruddy bootloader and let the clients fix it all up after its run. There are
more than a few boards out there that boot a u-boot from another
u-boot. Theres at least one that runs through *three* u-boots before
getting to a kernel...

 >> And for those of us where this is not an option?
 >
 > This is always an option to you.  You have the patch already, it
 > doesn't necessarily have to live in mainline.

I mean't *changing u-boot* is often not an option. Sometimes, neither
is chainbooting (limited flash).

 >> Which is all lovely, but sometimes simply not appropriate.
 >
 > Please deal with it.  Going the other way isn't appropriate for
 > mainline either.

Being able to make one zImage for lots of devices is a Good Thing.

Being able to pair an image down for just one device is *also* a
Good Thing.

**This isn't either/or**  In the 'one device' case, having the .dtb
appended can be useful. Having it passed in seperately is actually
fairly pointless, merely adding to the bootloader complexity.

Also, completely missing, AFAICT, is the option to pass the address
of a .dtb preloaded in RAM on the kernel commandline - which would
at least mean that people with crap u-boots could copy a .dtb to RAM
  and then point the kernel at it. (this was actually the first thing I 
tried,
until I realised that there is no option (that I can find) for that.)

 > Absolutely.  But it is there now and that's the extent of what
 > mainline is providing in terms of accommodation.

I really don't see why. We're talking about a couple of lines of patch.
If you're going to allow appending at all, you might as well let people
specify the file to append...

The way it is now, building uImages with 'make uImage' is
*actually broken*, if you want an appended DT.

 >> Whats the point in make uImage if you cant use it?
 >
 > I advocated its removal for quite a long time now.  But it is still
 > there which is also a compromise.  This way, people with ancient
 > target which are not DT enabled aren't affected.

What about those of us with a DT target and a crap bootloader? Or
Those who want a one-device image?

DT wont magically make drivers available for some other device, no
matter how hard you describe them in the .dts file, so 'one device'
images are still going to be pretty useless in the case of someone
trying to boot some other board with them.

If zImage is the one true way, thats fine - and I actually would prefer
that, I think uImages are stupid.

But - since its not the only way, it'd be sensible if the 'other way'
actually worked, or was officially made an out of tree option (thus
making it work again because you can concat. the .dtb file prior to
making the uImage.)

Device tree.

[Nicolas Pitre]

On Thu, 19 Jul 2012, Ian Molton wrote:

> On 18/07/12 14:42, Nicolas Pitre wrote
> 
> TL;DR: Summary
> 
> * make uImage is *broken* with CONFIG_ARM_APPENDED_DTB

Why do you say so?

In my own opinion, make uImage is broken, period.  But that is not the 
topic here.

> * Trimmed down single-configuration kernels have merit. forcing
>   .dtb to be passed from the bootloader
>   - Increases bootloader complexity
>     - and we know bootloaders suck and can be hard (if not impossible)
>       to replace.
>   - buys you nothing.

Hence CONFIG_ARM_APPENDED_DTB.

> * Three other architectures support
>   'make <image>.<embedded_dtb>'

If this is a generically useful feature, then something generic should 
be done about it instead. Duplicating the maintenance cost is silly.  
At least commit e339364514 moved things in the right direction for the 
uImage flavours.

> * Old bootloaders cant always be replaced (ROM) or chainload (lack
>   of flash) a newer one.

Hence CONFIG_ARM_APPENDED_DTB.  And don't tell me that you have u-Boot 
in ROM, in which case uImage shouldn't matter.

> * No way to pass a .dtb address on the kernel commandline (where
>   the bootloader cant pass it in a register, but can load arbitrary data
>   into RAM, which most u-boot versions can.)

That could be a nice compromize as an alternative to 
CONFIG_ARM_ATAG_DTB_COMPAT.

> Conclusion:
> 
> There are three 'real' solutions, IMO.
> 1) Copy the other arches, and have make <image>.<embedded_dtb>
>   - dtb could be properly embedded, linked into the kernel image.
>   - makes for a consistent way of building images across more archs.
>   - allows for simpler bootloaders.

If you want a consistent way, make that generic and not duplicated per 
architecture.

> 2) Display a warning when building a uImage with
> CONFIG_ARM_APPENDED_DTB, because that simply wont work the way
> things are now.
>   - Doesn't really fix anything, but at least it helps people see why
>     its not working...

Agreed.

> 3) Add an option to specify the address of a .dtb file in RAM via
> the kernel commandline.
>  - removes the need for appending .dtb files to the kernel
>  - still requires the bootloader to grok .dtb

See above.

> >> Yes, because this tactic has worked just great historically...
> >
> > It certainly did.  Look at the latest u-Boot which 1) has support
> > for device tree on ARM, and 2) has support to boot a zImage
> > directly. And some people were able to modify their old u-Boot as
> > well because of this policy.
> 
> I don't agree. u-boot has always been the weirdo that didnt just use a
> zImage. Its taken *years* for that to change, and its not like uImages
> were /ever/ easier to work with. I'd say the very presence of
> 'make uImage' slowed that change to a near halt.

Cheers!  

The uImage format also has other obnoxious limitations such as the 
absolute load address encoded into it.  This prevents a kernel built to 
run on multiple devices with different RAM offsets to be used on all of 
them.  This might have changed recently, but the old u-Boot installation 
base remains.

> >> Other than chainbooting /another/ bootloader, how do you propose
> >> people fix this issue? Not everyone has a co-operative vendor.
> >
> > Ask your vendor harder.  They would care even less if the kernel was
> > more accommodating.
> 
> They don't care anyway - vendors never have. They just ship some
> cruddy bootloader and let the clients fix it all up after its run. There are
> more than a few boards out there that boot a u-boot from another
> u-boot. Theres at least one that runs through *three* u-boots before
> getting to a kernel...

Hopefully the latest one could be updated to a recent one?

> >> And for those of us where this is not an option?
> >
> > This is always an option to you.  You have the patch already, it
> > doesn't necessarily have to live in mainline.
> 
> I mean't *changing u-boot* is often not an option. Sometimes, neither
> is chainbooting (limited flash).

Limited flash rules out u-Boot, right?

> >> Which is all lovely, but sometimes simply not appropriate.
> >
> > Please deal with it.  Going the other way isn't appropriate for
> > mainline either.
> 
> Being able to make one zImage for lots of devices is a Good Thing.
> 
> Being able to pair an image down for just one device is *also* a
> Good Thing.
> 
> **This isn't either/or**  In the 'one device' case, having the .dtb
> appended can be useful. Having it passed in seperately is actually
> fairly pointless, merely adding to the bootloader complexity.

It is not pointless if you think about Linux distributions.  They want a 
single kernel binary that can run anywhere and that they can update as 
often they want, while the DTB should be tied to each different device, 
ideally produced by the device vendor and shipped with the device.  
That could even allow yet to be produced devices to boot existing 
distributions, just like on x86.

That may not be applicable to you if your u-Boot only accommodates 
uImage which are already fixed to a particular memory address and 
therefore can't accept a universal zImage.  But short of not having a 
single 'make <image>.<embedded_dtb' command, you can still do

	make zImage
	cat your_board.dtb >> arch/arm/boot/zImage
	make uImage

or make the last 2 commands into the kernel _installation_ procedure for 
your board, running mkimage directly instead of using 'make uImage'.

Because 'make uImage' is really impairing progress here.  The kernel is 
already physical address agnostic i.e. it can be loaded anywhere and 
it'll figure out at run time what the actual physical memory location 
is.  We are trying to get rid of such knowledge as fixed physical 
addresses in the kernel and right now the only thing that prevents that 
is mkimage's _need_ for one.

> Also, completely missing, AFAICT, is the option to pass the address
> of a .dtb preloaded in RAM on the kernel commandline - which would
> at least mean that people with crap u-boots could copy a .dtb to RAM
>  and then point the kernel at it. (this was actually the first thing I tried,
> until I realised that there is no option (that I can find) for that.)

If only u-Boot would have let you set that address into the r2 register 
before booting the kernel this would have worked just fine.

[...]
> If zImage is the one true way, thats fine - and I actually would prefer
> that, I think uImages are stupid.
> 
> But - since its not the only way, it'd be sensible if the 'other way'
> actually worked, or was officially made an out of tree option (thus
> making it work again because you can concat. the .dtb file prior to
> making the uImage.)

Isn't that what I just showed above?


Nicolas

Device tree.

[Mark Brown]

On Thu, Jul 19, 2012 at 05:32:09PM -0400, Nicolas Pitre wrote:
> On Thu, 19 Jul 2012, Ian Molton wrote:

> > * Old bootloaders cant always be replaced (ROM) or chainload (lack
> >   of flash) a newer one.

> Hence CONFIG_ARM_APPENDED_DTB.  And don't tell me that you have u-Boot 
> in ROM, in which case uImage shouldn't matter.

For most of the boards I have it doesn't matter that the bootloader is
in flash, there's no way I'm going to risk bricking the board by trying
to replace the bootloader as I've got no way to recover the board if the
bootloader fails.  There's also the fact that if the bootloader supplies
the DT it can't boot kernels that don't understand DT as the machine ID
is changed (which isn't enormously helpful).

> > If zImage is the one true way, thats fine - and I actually would prefer
> > that, I think uImages are stupid.

> > But - since its not the only way, it'd be sensible if the 'other way'
> > actually worked, or was officially made an out of tree option (thus
> > making it work again because you can concat. the .dtb file prior to
> > making the uImage.)

> Isn't that what I just showed above?

It's possible to work with it, but then it's not clear to me why we have
CONFIG_ARM_APPENDED_DTB at all since pretty much the same thing applies
to non-DT cases.

Device Tree

[Valdis.Kletnieks at vt.edu]

On Tue, 25 Oct 2016 15:46:05 +0530, Madhu K said:

> You mean In non embedded system( laptop, desktop and server ) DT is not at
> all required?

Basically, that's correct.  Those types of systems have already evolved
ways (boot loaders, ACPI, and so on) to do things so there's no real need
to use DT on those systems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161025/cc9daff7/attachment.bin 

Device Tree

[Madhu K]

Hi Valdis,

You mean In non embedded system( laptop, desktop and server ) DT is not at
all required?

Regards,
Madhu

On Tue, Oct 25, 2016 at 1:09 PM, <Valdis.Kletnieks@vt.edu> wrote:

> On Tue, 25 Oct 2016 11:51:38 +0530, Madhu K said:
>
> > If in case Device tree is not there, where and how to pass the hardware
> > information to the linux kernel.
>
> For many types of hardware, the bus protocol provides a standard way to
> find everything on the bus.  And that sort of bus scanning is how
> non-embedded
> systems find all their devices.  If it's a laptop or a desktop or server,
> there's always the possibility that the user has plugged in a new graphics
> card or a different network card - so being able to scan and detect is
> important there.
>
> However, in an embedded system, the configuration is fixed - all the parts
> are
> soldered in place, and there's no place to add new devices.  So the
> hardware
> designers save the US$0.08 per chip by picking stripped down chips that
> don't
> have full function (for instance, leave off the PCI config circuitry and
> just
> provide a hardwired "this device will live at this address permanently")
>
> And yes, if you're building microwave ovens, and selling 10 million of
> them,
> suddenly saving 8 cents US per chip adds up to some major profits...
>
> > Does all embedded systems contains Device tree?
>
> No, only embedded systems that have I/O devices that cannot be
> enumerated by the hardware.  So for instance, usually a PCI device
> or a USB device can be detected by a bus scan.  So if that's all you
> have, you don't need device tree - the system can find all the hardware
> resources.
>
> But if you have GPIO pins, or an audio or ethernet card that's hard-wired
> in
> some non-scannable way, or weird clock chips, or anything like that, you'll
> need device tree.
>
> And it's certainly possible to do *both* - let the kernel scan for PCI and
> USB devices, *and* provide a device tree for non-scannable resources.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161025/b41b9786/attachment.html 

Device Tree

[Joel]

> On Oct 25, 2016, at 12:39 AM, Valdis.Kletnieks at vt.edu wrote:
> 
> On Tue, 25 Oct 2016 11:51:38 +0530, Madhu K said:
> 
>> If in case Device tree is not there, where and how to pass the hardware
>> information to the linux kernel.
> 
> For many types of hardware, the bus protocol provides a standard way to
> find everything on the bus.  And that sort of bus scanning is how non-embedded
> systems find all their devices.  If it's a laptop or a desktop or server,
> there's always the possibility that the user has plugged in a new graphics
> card or a different network card - so being able to scan and detect is
> important there.
> 
> However, in an embedded system, the configuration is fixed - all the parts are
> soldered in place, and there's no place to add new devices.  So the hardware
> designers save the US$0.08 per chip by picking stripped down chips that don't
> have full function (for instance, leave off the PCI config circuitry and just
> provide a hardwired "this device will live at this address permanently")
> 
> And yes, if you're building microwave ovens, and selling 10 million of them,
> suddenly saving 8 cents US per chip adds up to some major profits...
> 
>> Does all embedded systems contains Device tree?
> 
> No, only embedded systems that have I/O devices that cannot be
> enumerated by the hardware.  So for instance, usually a PCI device
> or a USB device can be detected by a bus scan.  So if that's all you
> have, you don't need device tree - the system can find all the hardware
> resources.
> 
> But if you have GPIO pins, or an audio or ethernet card that's hard-wired in
> some non-scannable way, or weird clock chips, or anything like that, you'll
> need device tree.
> 
> And it's certainly possible to do *both* - let the kernel scan for PCI and
> USB devices, *and* provide a device tree for non-scannable resources.

This is not entirely true, usually things like the CPU and machine information can?t be auto detected and DT provides this info.

It is also used to communicate things like bootargs to the kernel [1]
[1] http://lxr.free-electrons.com/source/drivers/of/fdt.c#L1081

DT is not the only way to do these things. But I just wanted to highlight that DT is used as a vehicle for more than just solving ?bus scanning? issues so you?ve to either use it or use other alternate methods to have such meta-data communicated from firmware.

- Joel

Device Tree

[Valdis.Kletnieks at vt.edu]

On Tue, 25 Oct 2016 11:51:38 +0530, Madhu K said:

> If in case Device tree is not there, where and how to pass the hardware
> information to the linux kernel.

For many types of hardware, the bus protocol provides a standard way to
find everything on the bus.  And that sort of bus scanning is how non-embedded
systems find all their devices.  If it's a laptop or a desktop or server,
there's always the possibility that the user has plugged in a new graphics
card or a different network card - so being able to scan and detect is
important there.

However, in an embedded system, the configuration is fixed - all the parts are
soldered in place, and there's no place to add new devices.  So the hardware
designers save the US$0.08 per chip by picking stripped down chips that don't
have full function (for instance, leave off the PCI config circuitry and just
provide a hardwired "this device will live at this address permanently")

And yes, if you're building microwave ovens, and selling 10 million of them,
suddenly saving 8 cents US per chip adds up to some major profits...

> Does all embedded systems contains Device tree?

No, only embedded systems that have I/O devices that cannot be
enumerated by the hardware.  So for instance, usually a PCI device
or a USB device can be detected by a bus scan.  So if that's all you
have, you don't need device tree - the system can find all the hardware
resources.

But if you have GPIO pins, or an audio or ethernet card that's hard-wired in
some non-scannable way, or weird clock chips, or anything like that, you'll
need device tree.

And it's certainly possible to do *both* - let the kernel scan for PCI and
USB devices, *and* provide a device tree for non-scannable resources.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161025/3ca3e1e6/attachment.bin 

Device Tree

[Laurent Navet]

Hi Madhu,

Here is an introduction to device tree :

http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf

2016-10-25 8:21 UTC+02:00, Madhu K <madhu.sk89@gmail.com>:
> Hi All,
>
> This is to understand how Device tree works in linux kernel.
>
> If in case Device tree is not there, where and how to pass the hardware
> information to the linux kernel.
>
> Does all embedded systems contains Device tree?
>
> Regards,
> Madhu
>


-- 
? On ne r?sout pas un probl?me avec les modes de pens?e qui l?ont engendr?. ?
? We cannot solve our problems with the same thinking we used when we
created them. ?

Device Tree

[Madhu K]

Hi All,

This is to understand how Device tree works in linux kernel.

If in case Device tree is not there, where and how to pass the hardware
information to the linux kernel.

Does all embedded systems contains Device tree?

Regards,
Madhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161025/81b42d10/attachment.html 

Re: Device Tree

[Sébastien Chrétien]

Thank for your answers.
Sébastien

Matt Sealey a écrit :
> Benjamin Herrenschmidt wrote:
>> On Tue, 2008-09-30 at 18:08 -0500, Matt Sealey wrote:
>>> It's far more common than people might think at first glance. With x86
>>> I am sure it would benefit the platform a little more if the OF support
>>> was in-line with the shared code between PPC and SPARC (and now I 
>>> guess,
>>> ARM) but nevertheless it's an Open Firmware platform and something that
>>> appeared not too long ago.
>>>
>>> OF is still a going concern; if you want a nice flexible firmware, why
>>> not use it? Most of the implementations are open source (FirmWorks and
>>> CodeGen trees, and the Sun reference design) too.
>>
>> And SLOF :-)
>
> I guess OpenBIOS counts too :)
>

Re: Device Tree

[Matt Sealey]

Benjamin Herrenschmidt wrote:
> On Tue, 2008-09-30 at 18:08 -0500, Matt Sealey wrote:
>> It's far more common than people might think at first glance. With x86
>> I am sure it would benefit the platform a little more if the OF support
>> was in-line with the shared code between PPC and SPARC (and now I guess,
>> ARM) but nevertheless it's an Open Firmware platform and something that
>> appeared not too long ago.
>>
>> OF is still a going concern; if you want a nice flexible firmware, why
>> not use it? Most of the implementations are open source (FirmWorks and
>> CodeGen trees, and the Sun reference design) too.
> 
> And SLOF :-)

I guess OpenBIOS counts too :)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: Device Tree

[Benjamin Herrenschmidt]

On Tue, 2008-09-30 at 18:08 -0500, Matt Sealey wrote:
> It's far more common than people might think at first glance. With x86
> I am sure it would benefit the platform a little more if the OF support
> was in-line with the shared code between PPC and SPARC (and now I guess,
> ARM) but nevertheless it's an Open Firmware platform and something that
> appeared not too long ago.
> 
> OF is still a going concern; if you want a nice flexible firmware, why
> not use it? Most of the implementations are open source (FirmWorks and
> CodeGen trees, and the Sun reference design) too.

And SLOF :-)

Cheers,
Ben.

Re: Device Tree

[Matt Sealey]

Gerald Van Baren wrote:
> Matt Sealey wrote:
 >>
>> The Toshiba TOPAS910 ARM development board also runs Open Firmware and
>> contains patches to support OF device trees.
>>
>> I dare say there might be an x86 box or two out there, too. But they
>> have ACPI tables too which is far more common..
> 
> More than a box or two: lots of OLPC XOs out there now.  ;-)
>     <http://wiki.laptop.org/go/Open_Firmware>

I was thinking more in a platform kind of numbers rather than a sales
kind of numbers, but you're right.

It's far more common than people might think at first glance. With x86
I am sure it would benefit the platform a little more if the OF support
was in-line with the shared code between PPC and SPARC (and now I guess,
ARM) but nevertheless it's an Open Firmware platform and something that
appeared not too long ago.

OF is still a going concern; if you want a nice flexible firmware, why
not use it? Most of the implementations are open source (FirmWorks and
CodeGen trees, and the Sun reference design) too.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: Device Tree

[Gerald Van Baren]

Matt Sealey wrote:
>
> Sergei Shtylyov wrote:
>> Hello.
>>
>> S=E9bastien Chr=E9tien wrote:
>>> Hello,
>>> I have a question about Device Tree.
>>> Is Device Tree found only only on Linux Powerpc ?
>>
>>   Not only Linux as it's a part of Open Firmware which is also used at
>> least on SPARC.
>
> The Toshiba TOPAS910 ARM development board also runs Open Firmware and
> contains patches to support OF device trees.
>
> I dare say there might be an x86 box or two out there, too. But they
> have ACPI tables too which is far more common..

More than a box or two: lots of OLPC XOs out there now.  ;-)
    <http://wiki.laptop.org/go/Open_Firmware>

Best regards,
gvb

Re: Device Tree

[Matt Sealey]

Sergei Shtylyov wrote:
> Hello.
> 
> Sébastien Chrétien wrote:
>> Hello,
>> I have a question about Device Tree.
>> Is Device Tree found only only on Linux Powerpc ?
> 
>   Not only Linux as it's a part of Open Firmware which is also used at 
> least on SPARC.

The Toshiba TOPAS910 ARM development board also runs Open Firmware and
contains patches to support OF device trees.

I dare say there might be an x86 box or two out there, too. But they
have ACPI tables too which is far more common..

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: Device Tree

[Benjamin Herrenschmidt]

On Mon, 2008-09-29 at 08:24 +0200, Sébastien Chrétien wrote:
> Hello,
> I have a question about Device Tree.
> Is Device Tree found only only on Linux Powerpc ?

Sparc also uses open firmware and shares some of the device-tree
handling code with powerpc in linux. Other operating systems on those
platforms also use it (AIX, Solaris, MacOS, ...)

I think the proposed new Xilinx microblaze architecture also uses it,
and at least on x86, the OLPC has an Open Firmware implementation though
it doesn't use the device-tree the way we do currently on powerpc and
sparc and has its own interface to the firmware.

Ben.

Re: Device Tree

[Sergei Shtylyov]

Hello.

Sébastien Chrétien wrote:

> I have a question about Device Tree.
> Is Device Tree found only only on Linux Powerpc ?

   Not only Linux as it's a part of Open Firmware which is also used at 
least on SPARC.

WBR, Sergei

Re: Device Tree

[Sergei Shtylyov]

Hello.

Sébastien Chrétien wrote:
> Hello,
> I have a question about Device Tree.
> Is Device Tree found only only on Linux Powerpc ?

   Not only Linux as it's a part of Open Firmware which is also used at 
least on SPARC.

WBR, Sergei

Device Tree

[Sébastien Chrétien]

Hello,
I have a question about Device Tree.
Is Device Tree found only only on Linux Powerpc ?

Thanks
Sébastien

RE: Device Tree

[John Linn]

It is not integrated into the EDK, you need to pull it from our git tree
and use it from the EDK.

-- John

Here's part of the wiki page.

Generating a Device Tree

The Linux kernel from the git tree has device tree files, ml507.dts and
ml405.dts, in the arch/powerpc/boot/dts directory which are designed to
work with the hardware reference designs available from this site. Users
who have a Xilinx board, ML405 or ML507, should build the Linux kernel
using the provided dts file to get a solid baseline before generating a
new device tree file. After a baseline is established, the new dts files
can be compared to the existing to verify any differences.

The page, Generating A Device Tree, has details on how to generate a
device tree for the arch/powerpc Linux kernel.




> -----Original Message-----
> From: Georg Schardt [mailto:schardt@team-ctech.de]
> Sent: Tuesday, September 09, 2008 12:19 PM
> To: John Linn
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Device Tree
> =

> Hi John,
> =

> yes, i found the wiki link in another post of you. nice , thank you.
> can you tell me how to generate the dts file in the EDK 10.2 ?  i have
> read that the gen_mhs_devtree script is now integrated ? i see no
> menu-item or config option ?
> =

> regards
> georg
> =

> =

> =

> John Linn wrote:
> > Hi Georg,
> >
> > Our git tree, git://git.xilinx.com, has support for the ML405 board
> > which is a V4 board. The following wiki page,
http://xilinx.wikidot.com,
> > shows how to generate a device tree for the kernel and other details
> > you'll need.
> >
> > The kernel from our git tree is configured for the device tree using
the
> > default kernel configuration.
> >
> > The mainline kernel is now more up to date also as we got many of
the
> > changes into the mainline, but we are still working on some of the
> > device drivers.
> >
> > Thanks,
> > John
> >
> >
> >> -----Original Message-----
> >> From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
> >>
> > [mailto:linuxppc-embedded-
> >
> >> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of Georg Schardt
> >> Sent: Tuesday, September 09, 2008 9:43 AM
> >> To: linuxppc-embedded@ozlabs.org
> >> Subject: Device Tree
> >>
> >> Hi,
> >>
> >> im searching for informations about the flatten device trees. the
only
> >> thing i know is, that the device tree is a kind of data-structure
> >>
> > which
> >
> >> the bios or bootloader gives to the operation system.
> >>
> >> until now, i boot linux with uboot without a device tree, but newer
> >> kernel wants a devicetree, i think ??
> >> i use a virtex4 board with an integrated powerpc
> >>
> >> how can i create the device tree file ?
> >> how must the linux kernel be configured ?
> >> is there a good internet page with informations ?
> >>
> >>
> >> thanks
> >> regards
> >> georg
> >> _______________________________________________
> >> Linuxppc-embedded mailing list
> >> Linuxppc-embedded@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >
> >
> > This email and any attachments are intended for the sole use of the
named recipient(s) and
> contain(s) confidential information that may be proprietary,
privileged or copyrighted under
> applicable law. If you are not the intended recipient, do not read,
copy, or forward this email
> message or any attachments. Delete this email message and any
attachments immediately.
> >
> >
> >
> =



This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: Device Tree

[Georg Schardt]

Hi John,

yes, i found the wiki link in another post of you. nice , thank you.
can you tell me how to generate the dts file in the EDK 10.2 ?  i have 
read that the gen_mhs_devtree script is now integrated ? i see no 
menu-item or config option ?

regards
georg



John Linn wrote:
> Hi Georg,
>
> Our git tree, git://git.xilinx.com, has support for the ML405 board
> which is a V4 board. The following wiki page, http://xilinx.wikidot.com,
> shows how to generate a device tree for the kernel and other details
> you'll need.
>
> The kernel from our git tree is configured for the device tree using the
> default kernel configuration.
>
> The mainline kernel is now more up to date also as we got many of the
> changes into the mainline, but we are still working on some of the
> device drivers.
>
> Thanks,
> John
>
>   
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org
>>     
> [mailto:linuxppc-embedded-
>   
>> bounces+john.linn=xilinx.com@ozlabs.org] On Behalf Of Georg Schardt
>> Sent: Tuesday, September 09, 2008 9:43 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: Device Tree
>>
>> Hi,
>>
>> im searching for informations about the flatten device trees. the only
>> thing i know is, that the device tree is a kind of data-structure
>>     
> which
>   
>> the bios or bootloader gives to the operation system.
>>
>> until now, i boot linux with uboot without a device tree, but newer
>> kernel wants a devicetree, i think ??
>> i use a virtex4 board with an integrated powerpc
>>
>> how can i create the device tree file ?
>> how must the linux kernel be configured ?
>> is there a good internet page with informations ?
>>
>>
>> thanks
>> regards
>> georg
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>     
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
>   

RE: Device Tree

[John Linn]

Hi Georg,

Our git tree, git://git.xilinx.com, has support for the ML405 board
which is a V4 board. The following wiki page, http://xilinx.wikidot.com,
shows how to generate a device tree for the kernel and other details
you'll need.

The kernel from our git tree is configured for the device tree using the
default kernel configuration.

The mainline kernel is now more up to date also as we got many of the
changes into the mainline, but we are still working on some of the
device drivers.

Thanks,
John

> -----Original Message-----
> From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of Georg Schardt
> Sent: Tuesday, September 09, 2008 9:43 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Device Tree
> =

> Hi,
> =

> im searching for informations about the flatten device trees. the only
> thing i know is, that the device tree is a kind of data-structure
which
> the bios or bootloader gives to the operation system.
> =

> until now, i boot linux with uboot without a device tree, but newer
> kernel wants a devicetree, i think ??
> i use a virtex4 board with an integrated powerpc
> =

> how can i create the device tree file ?
> how must the linux kernel be configured ?
> is there a good internet page with informations ?
> =

> =

> thanks
> regards
> georg
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: Device Tree

[Josh Boyer]

On Tue, Sep 09, 2008 at 05:43:12PM +0200, Georg Schardt wrote:
> Hi,
>
> im searching for informations about the flatten device trees. the only  
> thing i know is, that the device tree is a kind of data-structure which  
> the bios or bootloader gives to the operation system.
>
> until now, i boot linux with uboot without a device tree, but newer  
> kernel wants a devicetree, i think ??
> i use a virtex4 board with an integrated powerpc
>
> how can i create the device tree file ?
> how must the linux kernel be configured ?
> is there a good internet page with informations ?

In the kernel, look at Documentation/powerpc/booting-without-of.txt

You could also read the "A Symphony of Flavours: Using the device tree to
describe embedded hardware" paper on page 27 of:

http://www.linuxsymposium.org/2008/ols-2008-Proceedings-V2.pdf

josh

Device Tree

[Georg Schardt]

Hi,

im searching for informations about the flatten device trees. the only 
thing i know is, that the device tree is a kind of data-structure which 
the bios or bootloader gives to the operation system.

until now, i boot linux with uboot without a device tree, but newer 
kernel wants a devicetree, i think ??
i use a virtex4 board with an integrated powerpc

how can i create the device tree file ?
how must the linux kernel be configured ?
is there a good internet page with informations ?


thanks
regards
georg