Date:   Tue, 21 Nov 2017 13:02:07 +0100
From:   Ulf Samuelsson <linux-kernel@...gii.com>
To:     Frank Rowand <frowand.list@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: RFC: Copying Device Tree File into reserved area of VMLINUX
 before deployment



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

Powered by blists - more mailing lists