Messages in this thread | | | Subject | Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment | From | Ulf Samuelsson <> | Date | Tue, 21 Nov 2017 21:03:09 +0100 |
| |
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
| |