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
From 1584655463678912452@xxx Tue Nov 21 06:20:16 +0000 2017
X-GM-THRID: 1584466498009191251
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread