From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751097AbdKTEc2 (ORCPT ); Sun, 19 Nov 2017 23:32:28 -0500 Received: from mail-yb0-f195.google.com ([209.85.213.195]:34758 "EHLO mail-yb0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750969AbdKTEc1 (ORCPT ); Sun, 19 Nov 2017 23:32:27 -0500 X-Google-Smtp-Source: AGs4zMbUKIDVb3EcuLgrYLPGIrh1VJvvmgLE6PzqU6w5jmLT7vj+IlBifzDGAGfQfj6a+rpbfrcXWQ== Subject: Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment To: linux-kernel@emagii.com, LKML , "devicetree@vger.kernel.org" , Rob Herring References: <0b31e22b-202f-6fca-28f2-e16e6af6c6b7@emagii.com> From: Frank Rowand Message-ID: Date: Sun, 19 Nov 2017 23:32:24 -0500 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 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. >> 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. 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