Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Frank Rowand]

adding devicetree list, devicetree maintainers

On 11/18/17 12:59, Ulf Samuelsson wrote:
> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
> does not support device trees.
> 
> Is this something that would be considered useful for including in mainstream:
> 
> BACKGROUND:
> Trying to load a yocto kernel into a MIPS target (MT7620A based),
> and the U-Boot is more than stupid.
> Does not support the "run" command as an example.
> They modified the U-Boot MAGIC Word to complicate things.
> The U-Boot is not configured to use device tree files.
> The board runs a 2.6 kernel right now.
> 
> Several attempts by me a and others to rebuild U-Boot according to the H/W vendors source code and build instructions results in a bricked unit. Bricked units cannot be recovered.
> 
> Not my choice of H/W, so I cannot change it.
> 
> 
> ===================================================================
> OPENWRT:
> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
> does not support device trees.
> 
> What they do is to reserve 16 kB of kernel space, and tag it with an ASCII string "OWRTDTB:".
> After the kernel and dtb is built, a utility "patch-dtb" will update the vmlinux binary, copying in the device tree file.
> 
> ===================================================================
> It would be useful to me, and I could of course patch the mainstream kernel, but first I would like to check if this is of interest for mainstream.
> 
> I envisage the support would look something like:
> 
> ============
> Kconfig.
> config MIPS
>     select    HAVE_IMAGE_DTB
> 
> config    HAVE_IMAGE_DTB
>     bool
> 
> if HAVE_IMAGE_DTB
> config     IMAGE_DTB
>     bool    "Allocated space for DTB within image
> 
> config    DTB_SIZE
>     int    "DTB space (kB)
> 
> config    DTB_TAG
>     string    "DTB space tag"
>     default    "OWRTDTB:"
> endif
> 
> ============
> Some Makefile
> obj-$(CONFIG_INCLUDE_DTB) += image_dtb.o
> 
> ============
> image_dtb.S:
>     .text
>     .align    5
>     .ascii    CONFIG_DTB_TAG
>     EXPORT(__image_dtb)
>     .fill    DTB_SIZE * 1024
> 
> ===================
> arch/mips/xxx/of.c:
> 
> #if    defined(CONFIG_IMAGE_DTB)
>     if (<conditions to boot from dtb_space>)
>         __dt_setup_arch(__dtb_start);
>     else
>         __dt_setup_arch(&__image_dtb);
> #else
>     __dt_setup_arch(__dtb_start);
> #endif
> 
> I imagine that if the support is enabled for a target, it should
> be possible to override it with a CMDLINE argument
>     
>     
> They do something similar for the CMDLINE; copying it into the vmlinux, to allow a smaller boot
> 
> 
> 

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Frank Rowand]

Hi Ulf,


On 11/19/17 23:23, Frank Rowand wrote:
> adding devicetree list, devicetree maintainers
> 
> On 11/18/17 12:59, Ulf Samuelsson wrote:
>> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
>> does not support device trees.
>>
>> Is this something that would be considered useful for including in mainstream:
>>
>> BACKGROUND:
>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>> and the U-Boot is more than stupid.
>> Does not support the "run" command as an example.
>> They modified the U-Boot MAGIC Word to complicate things.
>> The U-Boot is not configured to use device tree files.
>> The board runs a 2.6 kernel right now.
>>
>> Several attempts by me a and others to rebuild U-Boot according to
>> the H/W vendors source code and build instructions results in a
>> bricked unit. Bricked units cannot be recovered.

Hopefully you have brought this to the attention of the vendor.  U-Boot
is GPL v2 (or in some ways possibly GPL v2 or later), so if you can not
build U-Boot that is equivalent to the binary U-Boot they shipped, the
vendor may want to ensure that they are shipping the proper source and
build instructions.


>> Not my choice of H/W, so I cannot change it.
>>
>>
>> ===================================================================
>> OPENWRT:
>> I noticed when checking out the OpenWRT support for the board that
>> they have a method to avoid having to pass the device tree address
>> to the kernel, and can thus boot device tree based kernels with
>> U-boots that does not support device trees.
>> 
>> What they do is to reserve 16 kB of kernel space, and tag it with
>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>> utility "patch-dtb" will update the vmlinux binary, copying in the
>> device tree file.
>>
>> ===================================================================
>> It would be useful to me, and I could of course patch the
>> mainstream kernel, but first I would like to check if this is of
>> interest for mainstream.

Not in this form.  Hard coding a fixed size area in the boot image
to contain the FDT (aka DTB) is a non-starter.

And again, I would first approach the H/W vendor before trying to
come up with a work around like this.


>> I envisage the support would look something like:
>>
>> ============
>> Kconfig.
>> config MIPS
>>     select    HAVE_IMAGE_DTB
>>
>> config    HAVE_IMAGE_DTB
>>     bool
>>
>> if HAVE_IMAGE_DTB
>> config     IMAGE_DTB
>>     bool    "Allocated space for DTB within image
>>
>> config    DTB_SIZE
>>     int    "DTB space (kB)
>>
>> config    DTB_TAG
>>     string    "DTB space tag"
>>     default    "OWRTDTB:"
>> endif
>>
>> ============
>> Some Makefile
>> obj-$(CONFIG_INCLUDE_DTB) += image_dtb.o
>>
>> ============
>> image_dtb.S:
>>     .text
>>     .align    5
>>     .ascii    CONFIG_DTB_TAG
>>     EXPORT(__image_dtb)
>>     .fill    DTB_SIZE * 1024
>>
>> ===================
>> arch/mips/xxx/of.c:
>>
>> #if    defined(CONFIG_IMAGE_DTB)
>>     if (<conditions to boot from dtb_space>)
>>         __dt_setup_arch(__dtb_start);
>>     else
>>         __dt_setup_arch(&__image_dtb);
>> #else
>>     __dt_setup_arch(__dtb_start);
>> #endif
>>
>> I imagine that if the support is enabled for a target, it should
>> be possible to override it with a CMDLINE argument
>>     
>>     
>> They do something similar for the CMDLINE; copying it into the vmlinux, to allow a smaller boot
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Mark Rutland]

On Sun, Nov 19, 2017 at 11:23:42PM -0500, Frank Rowand wrote:
> adding devicetree list, devicetree maintainers
> 
> On 11/18/17 12:59, Ulf Samuelsson wrote:
> > I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
> > does not support device trees.
> > 
> > Is this something that would be considered useful for including in mainstream:

On 32-bit arm, we support an appended DTB for cases like this. The DTB
is appended to the end of the kernel image, rather than being embedded.

Does mips not support something similar?

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Frank Rowand]

Ulf,

On 11/20/17 06:44, Mark Rutland wrote:
> On Sun, Nov 19, 2017 at 11:23:42PM -0500, Frank Rowand wrote:
>> adding devicetree list, devicetree maintainers
>>
>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
>>> does not support device trees.
>>>
>>> Is this something that would be considered useful for including in mainstream:
> 
> On 32-bit arm, we support an appended DTB for cases like this. The DTB
> is appended to the end of the kernel image, rather than being embedded.

That is CONFIG_ARM_APPENDED_DTB, if you want to see what it looks like.


> Does mips not support something similar?
> 
> Thanks,
> Mark.
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Ulf Samuelsson]

On 2017-11-20 05:32, Frank Rowand wrote:
> Hi Ulf,
> 
> 
> On 11/19/17 23:23, Frank Rowand wrote:
>> adding devicetree list, devicetree maintainers
>>
>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
>>> does not support device trees.
>>>
>>> Is this something that would be considered useful for including in mainstream:
>>>
>>> BACKGROUND:
>>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>>> and the U-Boot is more than stupid.
>>> Does not support the "run" command as an example.
>>> They modified the U-Boot MAGIC Word to complicate things.
>>> The U-Boot is not configured to use device tree files.
>>> The board runs a 2.6 kernel right now.
>>>
>>> Several attempts by me a and others to rebuild U-Boot according to
>>> the H/W vendors source code and build instructions results in a
>>> bricked unit. Bricked units cannot be recovered.
> 
> Hopefully you have brought this to the attention of the vendor.  U-Boot
> is GPL v2 (or in some ways possibly GPL v2 or later), so if you can not
> build U-Boot that is equivalent to the binary U-Boot they shipped, the
> vendor may want to ensure that they are shipping the proper source and
> build instructions.
> 

I am not the one in contact with the H/W vendor.
The U-boot is pretty old, and from comments from those
in contact with them, the U-Boot knowledge at the H/W vendor
is minimal at best.
It might even be that they program an U-boot where the upgrade of the 
U-boot is broken...


> 
>>> Not my choice of H/W, so I cannot change it.
>>>
>>>
>>> ===================================================================
>>> OPENWRT:
>>> I noticed when checking out the OpenWRT support for the board that
>>> they have a method to avoid having to pass the device tree address
>>> to the kernel, and can thus boot device tree based kernels with
>>> U-boots that does not support device trees.
>>>
>>> What they do is to reserve 16 kB of kernel space, and tag it with
>>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>>> utility "patch-dtb" will update the vmlinux binary, copying in the
>>> device tree file.
>>>
>>> ===================================================================
>>> It would be useful to me, and I could of course patch the
>>> mainstream kernel, but first I would like to check if this is of
>>> interest for mainstream.
> 
> Not in this form.  Hard coding a fixed size area in the boot image
> to contain the FDT (aka DTB) is a non-starter.

OK, Is it the fixed size, which is a problem?
Is generally combining an image with a DTB into a single file also a 
non-starter?


> 
> And again, I would first approach the H/W vendor before trying to
> come up with a work around like this.
> 
> 
>>> I envisage the support would look something like:
>>>
>>> ============
>>> Kconfig.
>>> config MIPS
>>>      select    HAVE_IMAGE_DTB
>>>
>>> config    HAVE_IMAGE_DTB
>>>      bool
>>>
>>> if HAVE_IMAGE_DTB
>>> config     IMAGE_DTB
>>>      bool    "Allocated space for DTB within image
>>>
>>> config    DTB_SIZE
>>>      int    "DTB space (kB)
>>>
>>> config    DTB_TAG
>>>      string    "DTB space tag"
>>>      default    "OWRTDTB:"
>>> endif
>>>
>>> ============
>>> Some Makefile
>>> obj-$(CONFIG_INCLUDE_DTB) += image_dtb.o
>>>
>>> ============
>>> image_dtb.S:
>>>      .text
>>>      .align    5
>>>      .ascii    CONFIG_DTB_TAG
>>>      EXPORT(__image_dtb)
>>>      .fill    DTB_SIZE * 1024
>>>
>>> ===================
>>> arch/mips/xxx/of.c:
>>>
>>> #if    defined(CONFIG_IMAGE_DTB)
>>>      if (<conditions to boot from dtb_space>)
>>>          __dt_setup_arch(__dtb_start);
>>>      else
>>>          __dt_setup_arch(&__image_dtb);
>>> #else
>>>      __dt_setup_arch(__dtb_start);
>>> #endif
>>>
>>> I imagine that if the support is enabled for a target, it should
>>> be possible to override it with a CMDLINE argument
>>>      
>>>      
>>> They do something similar for the CMDLINE; copying it into the vmlinux, to allow a smaller boot

-- 
Best Regards
Ulf Samuelsson

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Frank Rowand]

Hi Ulf, Rob,

On 11/20/17 15:19, Ulf Samuelsson wrote:
> 
> 
> On 2017-11-20 05:32, Frank Rowand wrote:
>> Hi Ulf,
>>
>>
>> On 11/19/17 23:23, Frank Rowand wrote:
>>> adding devicetree list, devicetree maintainers
>>>
>>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>>> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
>>>> does not support device trees.
>>>>
>>>> Is this something that would be considered useful for including in mainstream:
>>>>
>>>> BACKGROUND:
>>>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>>>> and the U-Boot is more than stupid.
>>>> Does not support the "run" command as an example.
>>>> They modified the U-Boot MAGIC Word to complicate things.
>>>> The U-Boot is not configured to use device tree files.
>>>> The board runs a 2.6 kernel right now.
>>>>
>>>> Several attempts by me a and others to rebuild U-Boot according to
>>>> the H/W vendors source code and build instructions results in a
>>>> bricked unit. Bricked units cannot be recovered.
>>
>> Hopefully you have brought this to the attention of the vendor.  U-Boot
>> is GPL v2 (or in some ways possibly GPL v2 or later), so if you can not
>> build U-Boot that is equivalent to the binary U-Boot they shipped, the
>> vendor may want to ensure that they are shipping the proper source and
>> build instructions.
>>
> 
> I am not the one in contact with the H/W vendor.
> The U-boot is pretty old, and from comments from those
> in contact with them, the U-Boot knowledge at the H/W vendor
> is minimal at best.
> It might even be that they program an U-boot where the upgrade of the U-boot is broken...
> 
> 
>>
>>>> Not my choice of H/W, so I cannot change it.
>>>>
>>>>
>>>> ===================================================================
>>>> OPENWRT:
>>>> I noticed when checking out the OpenWRT support for the board that
>>>> they have a method to avoid having to pass the device tree address
>>>> to the kernel, and can thus boot device tree based kernels with
>>>> U-boots that does not support device trees.
>>>>
>>>> What they do is to reserve 16 kB of kernel space, and tag it with
>>>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>>>> utility "patch-dtb" will update the vmlinux binary, copying in the
>>>> device tree file.
>>>>
>>>> ===================================================================
>>>> It would be useful to me, and I could of course patch the
>>>> mainstream kernel, but first I would like to check if this is of
>>>> interest for mainstream.
>>
>> Not in this form.  Hard coding a fixed size area in the boot image
>> to contain the FDT (aka DTB) is a non-starter.
> 
> OK, Is it the fixed size, which is a problem?

Yes, it is the fixed size which is a problem.

> Is generally combining an image with a DTB into a single file also a non-starter?

Can you jump in here Rob?  My understanding is that CONFIG_ARM_APPENDED_DTB,
which is the ARM based solution that Mark mentioned, was envisioned as a
temporary stop gap until boot loaders could add devicetree support.  I don't
know if there is a desire to limit this approach or to remove it in the
future.

I'm not sure why this feature should not be permanently supported.  I'm being
cautious, just in case I'm overlooking or missing an important issue, thus
asking for Rob's input.  I do know that this feature does not advance the
desires of people who want a single kernel (single boot image?) that runs on
many different systems, instead of a boot image that is unique to each
target platform.  But I don't see why that desire precludes also having
an option to have a target specific boot image.

-Frank


>>
>> And again, I would first approach the H/W vendor before trying to
>> come up with a work around like this.
>>
>>
>>>> I envisage the support would look something like:
>>>>
>>>> ============
>>>> Kconfig.
>>>> config MIPS
>>>>      select    HAVE_IMAGE_DTB
>>>>
>>>> config    HAVE_IMAGE_DTB
>>>>      bool
>>>>
>>>> if HAVE_IMAGE_DTB
>>>> config     IMAGE_DTB
>>>>      bool    "Allocated space for DTB within image
>>>>
>>>> config    DTB_SIZE
>>>>      int    "DTB space (kB)
>>>>
>>>> config    DTB_TAG
>>>>      string    "DTB space tag"
>>>>      default    "OWRTDTB:"
>>>> endif
>>>>
>>>> ============
>>>> Some Makefile
>>>> obj-$(CONFIG_INCLUDE_DTB) += image_dtb.o
>>>>
>>>> ============
>>>> image_dtb.S:
>>>>      .text
>>>>      .align    5
>>>>      .ascii    CONFIG_DTB_TAG
>>>>      EXPORT(__image_dtb)
>>>>      .fill    DTB_SIZE * 1024
>>>>
>>>> ===================
>>>> arch/mips/xxx/of.c:
>>>>
>>>> #if    defined(CONFIG_IMAGE_DTB)
>>>>      if (<conditions to boot from dtb_space>)
>>>>          __dt_setup_arch(__dtb_start);
>>>>      else
>>>>          __dt_setup_arch(&__image_dtb);
>>>> #else
>>>>      __dt_setup_arch(__dtb_start);
>>>> #endif
>>>>
>>>> I imagine that if the support is enabled for a target, it should
>>>> be possible to override it with a CMDLINE argument
>>>>           They do something similar for the CMDLINE; copying it into the vmlinux, to allow a smaller boot
> 

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Ulf Samuelsson]

On 2017-11-20 22:39, Frank Rowand wrote:
> Hi Ulf, Rob,
> 
> On 11/20/17 15:19, Ulf Samuelsson wrote:
>>
>>
>> On 2017-11-20 05:32, Frank Rowand wrote:
>>> Hi Ulf,
>>>
>>>
>>> On 11/19/17 23:23, Frank Rowand wrote:
>>>> adding devicetree list, devicetree maintainers
>>>>
>>>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>>>> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
>>>>> does not support device trees.
>>>>>
>>>>> Is this something that would be considered useful for including in mainstream:
>>>>>
>>>>> BACKGROUND:
>>>>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>>>>> and the U-Boot is more than stupid.
>>>>> Does not support the "run" command as an example.
>>>>> They modified the U-Boot MAGIC Word to complicate things.
>>>>> The U-Boot is not configured to use device tree files.
>>>>> The board runs a 2.6 kernel right now.
>>>>>
>>>>> Several attempts by me a and others to rebuild U-Boot according to
>>>>> the H/W vendors source code and build instructions results in a
>>>>> bricked unit. Bricked units cannot be recovered.
>>>
>>> Hopefully you have brought this to the attention of the vendor.  U-Boot
>>> is GPL v2 (or in some ways possibly GPL v2 or later), so if you can not
>>> build U-Boot that is equivalent to the binary U-Boot they shipped, the
>>> vendor may want to ensure that they are shipping the proper source and
>>> build instructions.
>>>
>>
>> I am not the one in contact with the H/W vendor.
>> The U-boot is pretty old, and from comments from those
>> in contact with them, the U-Boot knowledge at the H/W vendor
>> is minimal at best.
>> It might even be that they program an U-boot where the upgrade of the U-boot is broken...
>>
>>
>>>
>>>>> Not my choice of H/W, so I cannot change it.
>>>>>
>>>>>
>>>>> ===================================================================
>>>>> OPENWRT:
>>>>> I noticed when checking out the OpenWRT support for the board that
>>>>> they have a method to avoid having to pass the device tree address
>>>>> to the kernel, and can thus boot device tree based kernels with
>>>>> U-boots that does not support device trees.
>>>>>
>>>>> What they do is to reserve 16 kB of kernel space, and tag it with
>>>>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>>>>> utility "patch-dtb" will update the vmlinux binary, copying in the
>>>>> device tree file.
>>>>>
>>>>> ===================================================================
>>>>> It would be useful to me, and I could of course patch the
>>>>> mainstream kernel, but first I would like to check if this is of
>>>>> interest for mainstream.
>>>
>>> Not in this form.  Hard coding a fixed size area in the boot image
>>> to contain the FDT (aka DTB) is a non-starter.
>>
>> OK, Is it the fixed size, which is a problem?
> 
> Yes, it is the fixed size which is a problem.

The size can of course be changed, by setting the size configuration 
option (DTB_SIZE).
OpenWRT does not support that, but I think it needs to be there for a 
generic option (but You have to recompile the kernel to increase the size).

One problem is that you normally compile and link the kernel before you
compile the dtbs, so you do not know what size is until afterwards.


> 
>> Is generally combining an image with a DTB into a single file also a non-starter?
> 
> Can you jump in here Rob?  My understanding is that CONFIG_ARM_APPENDED_DTB,
> which is the ARM based solution that Mark mentioned, was envisioned as a
> temporary stop gap until boot loaders could add devicetree support.  I don't
> know if there is a desire to limit this approach or to remove it in the
> future.
> 
> I'm not sure why this feature should not be permanently supported.  I'm being
> cautious, just in case I'm overlooking or missing an important issue, thus
> asking for Rob's input.  I do know that this feature does not advance the
> desires of people who want a single kernel (single boot image?) that runs on
> many different systems, instead of a boot image that is unique to each
> target platform.  But I don't see why that desire precludes also having
> an option to have a target specific boot image.
The main reason to keep it is when you are really constrained for memory.
The U-Boot on the board is 96 kB, which is just a fraction of a more 
normal U-Boot.
Also, the u-boot is old.


> 
> -Frank
> 
> 
>>>
>>> And again, I would first approach the H/W vendor before trying to
>>> come up with a work around like this.
>>>
>>>
>>>>> I envisage the support would look something like:
>>>>>
>>>>> ============
>>>>> Kconfig.
>>>>> config MIPS
>>>>>       select    HAVE_IMAGE_DTB
>>>>>
>>>>> config    HAVE_IMAGE_DTB
>>>>>       bool
>>>>>
>>>>> if HAVE_IMAGE_DTB
>>>>> config     IMAGE_DTB
>>>>>       bool    "Allocated space for DTB within image
>>>>>
>>>>> config    DTB_SIZE
>>>>>       int    "DTB space (kB)
>>>>>
>>>>> config    DTB_TAG
>>>>>       string    "DTB space tag"
>>>>>       default    "OWRTDTB:"
>>>>> endif
>>>>>
>>>>> ============
>>>>> Some Makefile
>>>>> obj-$(CONFIG_INCLUDE_DTB) += image_dtb.o
>>>>>
>>>>> ============
>>>>> image_dtb.S:
>>>>>       .text
>>>>>       .align    5
>>>>>       .ascii    CONFIG_DTB_TAG
>>>>>       EXPORT(__image_dtb)
>>>>>       .fill    DTB_SIZE * 1024
>>>>>
>>>>> ===================
>>>>> arch/mips/xxx/of.c:
>>>>>
>>>>> #if    defined(CONFIG_IMAGE_DTB)
>>>>>       if (<conditions to boot from dtb_space>)
>>>>>           __dt_setup_arch(__dtb_start);
>>>>>       else
>>>>>           __dt_setup_arch(&__image_dtb);
>>>>> #else
>>>>>       __dt_setup_arch(__dtb_start);
>>>>> #endif
>>>>>
>>>>> I imagine that if the support is enabled for a target, it should
>>>>> be possible to override it with a CMDLINE argument
>>>>>            They do something similar for the CMDLINE; copying it into the vmlinux, to allow a smaller boot
>>
> 

-- 
Best Regards
Ulf Samuelsson

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Ulf Samuelsson]

On 2017-11-21 00:09, Ulf Samuelsson wrote:
> 
> 
> On 2017-11-20 22:39, Frank Rowand wrote:
>> Hi Ulf, Rob,
>>
>> On 11/20/17 15:19, Ulf Samuelsson wrote:
>>>
>>>
>>> On 2017-11-20 05:32, Frank Rowand wrote:
>>>> Hi Ulf,
>>>>
>>>>
>>>> On 11/19/17 23:23, Frank Rowand wrote:
>>>>> adding devicetree list, devicetree maintainers
>>>>>
>>>>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>>>>> I noticed when checking out the OpenWRT support for the board that 
>>>>>> they have a method to avoid having to pass the device tree address 
>>>>>> to the kernel, and can thus boot device tree based kernels with 
>>>>>> U-boots that
>>>>>> does not support device trees.
>>>>>>
>>>>>> Is this something that would be considered useful for including in 
>>>>>> mainstream:
>>>>>>
>>>>>> BACKGROUND:
>>>>>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>>>>>> and the U-Boot is more than stupid.
>>>>>> Does not support the "run" command as an example.
>>>>>> They modified the U-Boot MAGIC Word to complicate things.
>>>>>> The U-Boot is not configured to use device tree files.
>>>>>> The board runs a 2.6 kernel right now.
>>>>>>
>>>>>> Several attempts by me a and others to rebuild U-Boot according to
>>>>>> the H/W vendors source code and build instructions results in a
>>>>>> bricked unit. Bricked units cannot be recovered.
>>>>
>>>> Hopefully you have brought this to the attention of the vendor.  U-Boot
>>>> is GPL v2 (or in some ways possibly GPL v2 or later), so if you can not
>>>> build U-Boot that is equivalent to the binary U-Boot they shipped, the
>>>> vendor may want to ensure that they are shipping the proper source and
>>>> build instructions.
>>>>
>>>
>>> I am not the one in contact with the H/W vendor.
>>> The U-boot is pretty old, and from comments from those
>>> in contact with them, the U-Boot knowledge at the H/W vendor
>>> is minimal at best.
>>> It might even be that they program an U-boot where the upgrade of the 
>>> U-boot is broken...
>>>
>>>
>>>>
>>>>>> Not my choice of H/W, so I cannot change it.
>>>>>>
>>>>>>
>>>>>> ===================================================================
>>>>>> OPENWRT:
>>>>>> I noticed when checking out the OpenWRT support for the board that
>>>>>> they have a method to avoid having to pass the device tree address
>>>>>> to the kernel, and can thus boot device tree based kernels with
>>>>>> U-boots that does not support device trees.
>>>>>>
>>>>>> What they do is to reserve 16 kB of kernel space, and tag it with
>>>>>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>>>>>> utility "patch-dtb" will update the vmlinux binary, copying in the
>>>>>> device tree file.
>>>>>>
>>>>>> ===================================================================
>>>>>> It would be useful to me, and I could of course patch the
>>>>>> mainstream kernel, but first I would like to check if this is of
>>>>>> interest for mainstream.
>>>>
>>>> Not in this form.  Hard coding a fixed size area in the boot image
>>>> to contain the FDT (aka DTB) is a non-starter.
>>>
>>> OK, Is it the fixed size, which is a problem?
>>
>> Yes, it is the fixed size which is a problem.
> 
> The size can of course be changed, by setting the size configuration 
> option (DTB_SIZE).
> OpenWRT does not support that, but I think it needs to be there for a 
> generic option (but You have to recompile the kernel to increase the size).
> 
> One problem is that you normally compile and link the kernel before you
> compile the dtbs, so you do not know what size is until afterwards.
> 
Found this link:	https://csl.name/post/embedding-binary-data/

=======================================
...
Let's say you have an image target.dtb and want to embed it into your 
application. You can create an object file with


image_dtb.o:	<target dtb>
	mv <target dtb>   image_dtb
	ld -r -b binary image_dtb -o image_dtb.o

The object file will have three symbols in it,

$ nm cat.o
0000000000000512 D _binary_image_dtb_end
0000000000000512 A _binary_image_dtb_size
0000000000000000 D _binary_image_dtb_start
=======================================

This assumes that the dtbs are built before the kernel is linked.
The copy step is neccessary, since the generated names are
taken from the name of the "in file".
(Would have been better, if they used the "out file")

Otherwise you can create an assembler file which "incbin's" the dtb file.




> 
>>
>>> Is generally combining an image with a DTB into a single file also a 
>>> non-starter?
>>
>> Can you jump in here Rob?  My understanding is that 
>> CONFIG_ARM_APPENDED_DTB,
>> which is the ARM based solution that Mark mentioned, was envisioned as a
>> temporary stop gap until boot loaders could add devicetree support.  I 
>> don't
>> know if there is a desire to limit this approach or to remove it in the
>> future.
>>
>> I'm not sure why this feature should not be permanently supported.  
>> I'm being
>> cautious, just in case I'm overlooking or missing an important issue, 
>> thus
>> asking for Rob's input.  I do know that this feature does not advance the
>> desires of people who want a single kernel (single boot image?) that 
>> runs on
>> many different systems, instead of a boot image that is unique to each
>> target platform.  But I don't see why that desire precludes also having
>> an option to have a target specific boot image.
> The main reason to keep it is when you are really constrained for memory.
> The U-Boot on the board is 96 kB, which is just a fraction of a more 
> normal U-Boot.
> Also, the u-boot is old.
> 
> 
>>
>> -Frank
>>
>>
>>>>
>>>> And again, I would first approach the H/W vendor before trying to
>>>> come up with a work around like this.
>>>>
>>>>
>>>>>> I envisage the support would look something like:
>>>>>>
>>>>>> ============
>>>>>> Kconfig.
>>>>>> config MIPS
>>>>>>       select    HAVE_IMAGE_DTB
>>>>>>
>>>>>> config    HAVE_IMAGE_DTB
>>>>>>       bool
>>>>>>
>>>>>> if HAVE_IMAGE_DTB
>>>>>> config     IMAGE_DTB
>>>>>>       bool    "Allocated space for DTB within image
>>>>>>
>>>>>> config    DTB_SIZE
>>>>>>       int    "DTB space (kB)
>>>>>>
>>>>>> config    DTB_TAG
>>>>>>       string    "DTB space tag"
>>>>>>       default    "OWRTDTB:"
>>>>>> endif
>>>>>>
>>>>>> ============
>>>>>> Some Makefile
>>>>>> obj-$(CONFIG_INCLUDE_DTB) += image_dtb.o
>>>>>>
>>>>>> ============
>>>>>> image_dtb.S:
>>>>>>       .text
>>>>>>       .align    5
>>>>>>       .ascii    CONFIG_DTB_TAG
>>>>>>       EXPORT(__image_dtb)
>>>>>>       .fill    DTB_SIZE * 1024
>>>>>>
>>>>>> ===================
>>>>>> arch/mips/xxx/of.c:
>>>>>>
>>>>>> #if    defined(CONFIG_IMAGE_DTB)
>>>>>>       if (<conditions to boot from dtb_space>)
>>>>>>           __dt_setup_arch(__dtb_start);
>>>>>>       else
>>>>>>           __dt_setup_arch(&__image_dtb);
>>>>>> #else
>>>>>>       __dt_setup_arch(__dtb_start);
>>>>>> #endif
>>>>>>
>>>>>> I imagine that if the support is enabled for a target, it should
>>>>>> be possible to override it with a CMDLINE argument
>>>>>>            They do something similar for the CMDLINE; copying it 
>>>>>> into the vmlinux, to allow a smaller boot
>>>
>>
> 

-- 
Best Regards
Ulf Samuelsson

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Ulf Samuelsson]

On 2017-11-21 07:19, Ulf Samuelsson wrote:
> 
> 
> On 2017-11-21 00:09, Ulf Samuelsson wrote:
>>
>>
>> On 2017-11-20 22:39, Frank Rowand wrote:
>>> Hi Ulf, Rob,
>>>
>>> On 11/20/17 15:19, Ulf Samuelsson wrote:
>>>>
>>>>
>>>> On 2017-11-20 05:32, Frank Rowand wrote:
>>>>> Hi Ulf,
>>>>>
>>>>>
>>>>> On 11/19/17 23:23, Frank Rowand wrote:
>>>>>> adding devicetree list, devicetree maintainers
>>>>>>
>>>>>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>>>>>> I noticed when checking out the OpenWRT support for the board 
>>>>>>> that they have a method to avoid having to pass the device tree 
>>>>>>> address to the kernel, and can thus boot device tree based 
>>>>>>> kernels with U-boots that
>>>>>>> does not support device trees.
>>>>>>>
>>>>>>> Is this something that would be considered useful for including 
>>>>>>> in mainstream:
>>>>>>>
>>>>>>> BACKGROUND:
>>>>>>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>>>>>>> and the U-Boot is more than stupid.
>>>>>>> Does not support the "run" command as an example.
>>>>>>> They modified the U-Boot MAGIC Word to complicate things.
>>>>>>> The U-Boot is not configured to use device tree files.
>>>>>>> The board runs a 2.6 kernel right now.
>>>>>>>
>>>>>>> Several attempts by me a and others to rebuild U-Boot according to
>>>>>>> the H/W vendors source code and build instructions results in a
>>>>>>> bricked unit. Bricked units cannot be recovered.
>>>>>
>>>>> Hopefully you have brought this to the attention of the vendor.  
>>>>> U-Boot
>>>>> is GPL v2 (or in some ways possibly GPL v2 or later), so if you can 
>>>>> not
>>>>> build U-Boot that is equivalent to the binary U-Boot they shipped, the
>>>>> vendor may want to ensure that they are shipping the proper source and
>>>>> build instructions.
>>>>>
>>>>
>>>> I am not the one in contact with the H/W vendor.
>>>> The U-boot is pretty old, and from comments from those
>>>> in contact with them, the U-Boot knowledge at the H/W vendor
>>>> is minimal at best.
>>>> It might even be that they program an U-boot where the upgrade of 
>>>> the U-boot is broken...
>>>>
>>>>
>>>>>
>>>>>>> Not my choice of H/W, so I cannot change it.
>>>>>>>
>>>>>>>
>>>>>>> ===================================================================
>>>>>>> OPENWRT:
>>>>>>> I noticed when checking out the OpenWRT support for the board that
>>>>>>> they have a method to avoid having to pass the device tree address
>>>>>>> to the kernel, and can thus boot device tree based kernels with
>>>>>>> U-boots that does not support device trees.
>>>>>>>
>>>>>>> What they do is to reserve 16 kB of kernel space, and tag it with
>>>>>>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>>>>>>> utility "patch-dtb" will update the vmlinux binary, copying in the
>>>>>>> device tree file.
>>>>>>>
>>>>>>> ===================================================================
>>>>>>> It would be useful to me, and I could of course patch the
>>>>>>> mainstream kernel, but first I would like to check if this is of
>>>>>>> interest for mainstream.
>>>>>
>>>>> Not in this form.  Hard coding a fixed size area in the boot image
>>>>> to contain the FDT (aka DTB) is a non-starter.
>>>>
>>>> OK, Is it the fixed size, which is a problem?
>>>
>>> Yes, it is the fixed size which is a problem.
>>
>> The size can of course be changed, by setting the size configuration 
>> option (DTB_SIZE).
>> OpenWRT does not support that, but I think it needs to be there for a 
>> generic option (but You have to recompile the kernel to increase the 
>> size).
>>
>> One problem is that you normally compile and link the kernel before you
>> compile the dtbs, so you do not know what size is until afterwards.
>>
> Found this link:    https://csl.name/post/embedding-binary-data/
> 
> =======================================
> ...
> Let's say you have an image target.dtb and want to embed it into your 
> application. You can create an object file with
> 
> 
> image_dtb.o:    <target dtb>
>      mv <target dtb>   image_dtb
>      ld -r -b binary image_dtb -o image_dtb.o
> 
> The object file will have three symbols in it,
> 
> $ nm cat.o
> 0000000000000512 D _binary_image_dtb_end
> 0000000000000512 A _binary_image_dtb_size
> 0000000000000000 D _binary_image_dtb_start
> =======================================
> 
> This assumes that the dtbs are built before the kernel is linked.
> The copy step is neccessary, since the generated names are
> taken from the name of the "in file".
> (Would have been better, if they used the "out file")
> 
> Otherwise you can create an assembler file which "incbin's" the dtb file.
> 

Just checked the kernel source, and it appears that the discussion is 
somewhat redundant, since the support is already in the linux kernel
for some MIPS boards

arch/mips/Kconfig:
	config MIPS_ELF_APPENDED_DTB
		bool "vmlinux"
		help
		  With this option, the boot code will look for a device tree binary
		  DTB) included in the vmlinux ELF section .appended_dtb. By default
		  it is empty and the DTB can be appended using binutils command
		  objcopy:

		    objcopy --update-section .appended_dtb=<filename>.dtb vmlinux

		  This is meant as a backward compatiblity convenience for those
		  systems with a bootloader that can't be upgraded to accommodate
		  the documented boot protocol using a device tree.

arch/mips/kernel/setup.c:
#ifdef CONFIG_MIPS_ELF_APPENDED_DTB
const char __section(.appended_dtb) __appended_dtb[0x100000];
#endif /* CONFIG_MIPS_ELF_APPENDED_DTB */

arch/mips/bmips/setup.c

#ifdef CONFIG_MIPS_ELF_APPENDED_DTB
	if (!fdt_check_header(&__appended_dtb))
		dtb = (void *)&__appended_dtb;
	else
#endif




> 
> 
> 
>>
>>>
>>>> Is generally combining an image with a DTB into a single file also a 
>>>> non-starter?
>>>
>>> Can you jump in here Rob?  My understanding is that 
>>> CONFIG_ARM_APPENDED_DTB,
>>> which is the ARM based solution that Mark mentioned, was envisioned as a
>>> temporary stop gap until boot loaders could add devicetree support.  
>>> I don't
>>> know if there is a desire to limit this approach or to remove it in the
>>> future.
>>>
>>> I'm not sure why this feature should not be permanently supported. 
>>> I'm being
>>> cautious, just in case I'm overlooking or missing an important issue, 
>>> thus
>>> asking for Rob's input.  I do know that this feature does not advance 
>>> the
>>> desires of people who want a single kernel (single boot image?) that 
>>> runs on
>>> many different systems, instead of a boot image that is unique to each
>>> target platform.  But I don't see why that desire precludes also having
>>> an option to have a target specific boot image.
>> The main reason to keep it is when you are really constrained for memory.
>> The U-Boot on the board is 96 kB, which is just a fraction of a more 
>> normal U-Boot.
>> Also, the u-boot is old.
>>
>>
>>>
>>> -Frank
>>>
>>>
>>>>>
>>>>> And again, I would first approach the H/W vendor before trying to
>>>>> come up with a work around like this.
>>>>>
>>>>>
>>>>>>> I envisage the support would look something like:
>>>>>>>
>>>>>>> ============
>>>>>>> Kconfig.
>>>>>>> config MIPS
>>>>>>>       select    HAVE_IMAGE_DTB
>>>>>>>
>>>>>>> config    HAVE_IMAGE_DTB
>>>>>>>       bool
>>>>>>>
>>>>>>> if HAVE_IMAGE_DTB
>>>>>>> config     IMAGE_DTB
>>>>>>>       bool    "Allocated space for DTB within image
>>>>>>>
>>>>>>> config    DTB_SIZE
>>>>>>>       int    "DTB space (kB)
>>>>>>>
>>>>>>> config    DTB_TAG
>>>>>>>       string    "DTB space tag"
>>>>>>>       default    "OWRTDTB:"
>>>>>>> endif
>>>>>>>
>>>>>>> ============
>>>>>>> Some Makefile
>>>>>>> obj-$(CONFIG_INCLUDE_DTB) += image_dtb.o
>>>>>>>
>>>>>>> ============
>>>>>>> image_dtb.S:
>>>>>>>       .text
>>>>>>>       .align    5
>>>>>>>       .ascii    CONFIG_DTB_TAG
>>>>>>>       EXPORT(__image_dtb)
>>>>>>>       .fill    DTB_SIZE * 1024
>>>>>>>
>>>>>>> ===================
>>>>>>> arch/mips/xxx/of.c:
>>>>>>>
>>>>>>> #if    defined(CONFIG_IMAGE_DTB)
>>>>>>>       if (<conditions to boot from dtb_space>)
>>>>>>>           __dt_setup_arch(__dtb_start);
>>>>>>>       else
>>>>>>>           __dt_setup_arch(&__image_dtb);
>>>>>>> #else
>>>>>>>       __dt_setup_arch(__dtb_start);
>>>>>>> #endif
>>>>>>>
>>>>>>> I imagine that if the support is enabled for a target, it should
>>>>>>> be possible to override it with a CMDLINE argument
>>>>>>>            They do something similar for the CMDLINE; copying it 
>>>>>>> into the vmlinux, to allow a smaller boot
>>>>
>>>
>>
> 

-- 
Best Regards
Ulf Samuelsson
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Rob Herring]

On Mon, Nov 20, 2017 at 3:39 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> Hi Ulf, Rob,
>
> On 11/20/17 15:19, Ulf Samuelsson wrote:
>>
>>
>> On 2017-11-20 05:32, Frank Rowand wrote:
>>> Hi Ulf,
>>>
>>>
>>> On 11/19/17 23:23, Frank Rowand wrote:
>>>> adding devicetree list, devicetree maintainers
>>>>
>>>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>>>> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
>>>>> does not support device trees.
>>>>>
>>>>> Is this something that would be considered useful for including in mainstream:
>>>>>
>>>>> BACKGROUND:
>>>>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>>>>> and the U-Boot is more than stupid.
>>>>> Does not support the "run" command as an example.
>>>>> They modified the U-Boot MAGIC Word to complicate things.
>>>>> The U-Boot is not configured to use device tree files.
>>>>> The board runs a 2.6 kernel right now.
>>>>>
>>>>> Several attempts by me a and others to rebuild U-Boot according to
>>>>> the H/W vendors source code and build instructions results in a
>>>>> bricked unit. Bricked units cannot be recovered.
>>>
>>> Hopefully you have brought this to the attention of the vendor.  U-Boot
>>> is GPL v2 (or in some ways possibly GPL v2 or later), so if you can not
>>> build U-Boot that is equivalent to the binary U-Boot they shipped, the
>>> vendor may want to ensure that they are shipping the proper source and
>>> build instructions.
>>>
>>
>> I am not the one in contact with the H/W vendor.
>> The U-boot is pretty old, and from comments from those
>> in contact with them, the U-Boot knowledge at the H/W vendor
>> is minimal at best.
>> It might even be that they program an U-boot where the upgrade of the U-boot is broken...
>>
>>
>>>
>>>>> Not my choice of H/W, so I cannot change it.
>>>>>
>>>>>
>>>>> ===================================================================
>>>>> OPENWRT:
>>>>> I noticed when checking out the OpenWRT support for the board that
>>>>> they have a method to avoid having to pass the device tree address
>>>>> to the kernel, and can thus boot device tree based kernels with
>>>>> U-boots that does not support device trees.
>>>>>
>>>>> What they do is to reserve 16 kB of kernel space, and tag it with
>>>>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>>>>> utility "patch-dtb" will update the vmlinux binary, copying in the
>>>>> device tree file.
>>>>>
>>>>> ===================================================================
>>>>> It would be useful to me, and I could of course patch the
>>>>> mainstream kernel, but first I would like to check if this is of
>>>>> interest for mainstream.
>>>
>>> Not in this form.  Hard coding a fixed size area in the boot image
>>> to contain the FDT (aka DTB) is a non-starter.
>>
>> OK, Is it the fixed size, which is a problem?
>
> Yes, it is the fixed size which is a problem.
>
>> Is generally combining an image with a DTB into a single file also a non-starter?
>
> Can you jump in here Rob?  My understanding is that CONFIG_ARM_APPENDED_DTB,
> which is the ARM based solution that Mark mentioned, was envisioned as a
> temporary stop gap until boot loaders could add devicetree support.  I don't
> know if there is a desire to limit this approach or to remove it in the
> future.

Yes, but I doubt we'll ever remove it. Most android devices use it (or
the multiple appended dtb stuff Qcom did) and there's out of tree
patches to do appended dtb on arm64. However, arm64 is a done a bit
differently in that the bootloader has to find the dtb rather than the
kernel (or really the decompressor). The purpose for arm64 is people
like the single kernel+dtb image, not legacy bootloader support as DT
support was there from day 1.

Another option is to do what's called an impedance matcher like this[1].

> I'm not sure why this feature should not be permanently supported.  I'm being
> cautious, just in case I'm overlooking or missing an important issue, thus
> asking for Rob's input.  I do know that this feature does not advance the
> desires of people who want a single kernel (single boot image?) that runs on
> many different systems, instead of a boot image that is unique to each
> target platform.  But I don't see why that desire precludes also having
> an option to have a target specific boot image.

MIPS already supports built-in dtbs which is an in-kernel way to get
the dtb rather than the decompressor. The addition in this case is
just putting in a dummy dtb and putting in the real dtb later. I'm not
sure what MIPS image header looks like, but seems like it should be
possible to have the "built-in dtb" point to an appended dtb and just
update sizes in the image file. Then you don't have the fixed size.

But now that I finished writing this, I see there is already appended
DTB support in MIPS.

Rob

[1] https://github.com/zonque/pxa-impedance-matcher

Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment

[Ulf Samuelsson]

On 2017-11-21 18:09, Rob Herring wrote:
> On Mon, Nov 20, 2017 at 3:39 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> Hi Ulf, Rob,
>>
>> On 11/20/17 15:19, Ulf Samuelsson wrote:
>>>
>>>
>>> On 2017-11-20 05:32, Frank Rowand wrote:
>>>> Hi Ulf,
>>>>
>>>>
>>>> On 11/19/17 23:23, Frank Rowand wrote:
>>>>> adding devicetree list, devicetree maintainers
>>>>>
>>>>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>>>>> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
>>>>>> does not support device trees.
>>>>>>
>>>>>> Is this something that would be considered useful for including in mainstream:
>>>>>>
>>>>>> BACKGROUND:
>>>>>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>>>>>> and the U-Boot is more than stupid.
>>>>>> Does not support the "run" command as an example.
>>>>>> They modified the U-Boot MAGIC Word to complicate things.
>>>>>> The U-Boot is not configured to use device tree files.
>>>>>> The board runs a 2.6 kernel right now.
>>>>>>
>>>>>> Several attempts by me a and others to rebuild U-Boot according to
>>>>>> the H/W vendors source code and build instructions results in a
>>>>>> bricked unit. Bricked units cannot be recovered.
>>>>
>>>> Hopefully you have brought this to the attention of the vendor.  U-Boot
>>>> is GPL v2 (or in some ways possibly GPL v2 or later), so if you can not
>>>> build U-Boot that is equivalent to the binary U-Boot they shipped, the
>>>> vendor may want to ensure that they are shipping the proper source and
>>>> build instructions.
>>>>
>>>
>>> I am not the one in contact with the H/W vendor.
>>> The U-boot is pretty old, and from comments from those
>>> in contact with them, the U-Boot knowledge at the H/W vendor
>>> is minimal at best.
>>> It might even be that they program an U-boot where the upgrade of the U-boot is broken...
>>>
>>>
>>>>
>>>>>> Not my choice of H/W, so I cannot change it.
>>>>>>
>>>>>>
>>>>>> ===================================================================
>>>>>> OPENWRT:
>>>>>> I noticed when checking out the OpenWRT support for the board that
>>>>>> they have a method to avoid having to pass the device tree address
>>>>>> to the kernel, and can thus boot device tree based kernels with
>>>>>> U-boots that does not support device trees.
>>>>>>
>>>>>> What they do is to reserve 16 kB of kernel space, and tag it with
>>>>>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>>>>>> utility "patch-dtb" will update the vmlinux binary, copying in the
>>>>>> device tree file.
>>>>>>
>>>>>> ===================================================================
>>>>>> It would be useful to me, and I could of course patch the
>>>>>> mainstream kernel, but first I would like to check if this is of
>>>>>> interest for mainstream.
>>>>
>>>> Not in this form.  Hard coding a fixed size area in the boot image
>>>> to contain the FDT (aka DTB) is a non-starter.
>>>
>>> OK, Is it the fixed size, which is a problem?
>>
>> Yes, it is the fixed size which is a problem.
>>
>>> Is generally combining an image with a DTB into a single file also a non-starter?
>>
>> Can you jump in here Rob?  My understanding is that CONFIG_ARM_APPENDED_DTB,
>> which is the ARM based solution that Mark mentioned, was envisioned as a
>> temporary stop gap until boot loaders could add devicetree support.  I don't
>> know if there is a desire to limit this approach or to remove it in the
>> future.
> 
> Yes, but I doubt we'll ever remove it. Most android devices use it (or
> the multiple appended dtb stuff Qcom did) and there's out of tree
> patches to do appended dtb on arm64. However, arm64 is a done a bit
> differently in that the bootloader has to find the dtb rather than the
> kernel (or really the decompressor). The purpose for arm64 is people
> like the single kernel+dtb image, not legacy bootloader support as DT
> support was there from day 1.
> 
> Another option is to do what's called an impedance matcher like this[1].
> 
>> I'm not sure why this feature should not be permanently supported.  I'm being
>> cautious, just in case I'm overlooking or missing an important issue, thus
>> asking for Rob's input.  I do know that this feature does not advance the
>> desires of people who want a single kernel (single boot image?) that runs on
>> many different systems, instead of a boot image that is unique to each
>> target platform.  But I don't see why that desire precludes also having
>> an option to have a target specific boot image.
> 
> MIPS already supports built-in dtbs which is an in-kernel way to get
> the dtb rather than the decompressor. The addition in this case is
> just putting in a dummy dtb and putting in the real dtb later. I'm not
> sure what MIPS image header looks like, but seems like it should be
> possible to have the "built-in dtb" point to an appended dtb and just
> update sizes in the image file. Then you don't have the fixed size.
> 
> But now that I finished writing this, I see there is already appended
> DTB support in MIPS.

I just managed to complete a build using yocto where I made the 
following changes.

I build the dtbs before linking the uImage.

I add some configuration variables, which define
* if the dtb should be included
* which dtb file should be included

uImage always gziped

Checking the resulting uImage, shows that the ".appended_dtb" section 
now contains the dtb file.

I have not loaded it into a board yet, but the default init seems to 
check if there is a U-boot header in the ".appended_dtb" section.

My bootloader has a custom MAGIC so loading still won't work.


> 
> Rob
> 
> [1] https://github.com/zonque/pxa-impedance-matcher
> 

-- 
Best Regards
Ulf Samuelsson