From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752617AbdKTUTb (ORCPT ); Mon, 20 Nov 2017 15:19:31 -0500 Received: from v-smtpout1.han.skanova.net ([81.236.60.154]:55937 "EHLO v-smtpout1.han.skanova.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751173AbdKTUTa (ORCPT ); Mon, 20 Nov 2017 15:19:30 -0500 Reply-To: linux-kernel@emagii.com Subject: Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment To: Frank Rowand , LKML , "devicetree@vger.kernel.org" , Rob Herring References: <0b31e22b-202f-6fca-28f2-e16e6af6c6b7@emagii.com> From: Ulf Samuelsson Organization: eMagii Message-ID: Date: Mon, 20 Nov 2017 21:19:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfCxYCGU5e5RrhZt/C7Dnsm8wmOQMpXExKI8GGPNxLsIZSjLFQ0gH+W/dMYYl8uV7BfV7D923az5XfftdlIIrzPUeuKp4hUA0MMpotWSjnnlvzORGO4FC EUS5sPdZ7+J7nSKL5F6A2WZgMbWoMJoxKXV2gByMG+yHiUvlpRe3Jh9bRgZIhjcQGkX5xpJeFHREiFBLs/nxNRtDcurl/CqWJ1Gi3DL8nqAMx2RCcoUiqRVQ PbZnJ9L/A49Im/JIDBpMq9kP/eblX0cEaZjXSc6YKZyfPRae761tDGtYc0V1uLYw Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 () >>>         __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