Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment
From: Ulf Samuelsson
Date: Mon Nov 20 2017 - 15:19:34 EST
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