From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: linux-kernel-AoFPY8dbyRPQT0dZR+AlfA@public.gmane.org,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment
Date: Sun, 19 Nov 2017 23:32:24 -0500 [thread overview]
Message-ID: <fe7925f3-30d4-ec03-a6c5-61a8644dcdfe@gmail.com> (raw)
In-Reply-To: <a0f9d598-04af-fddd-58ad-09db10ec19da-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 (<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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-11-20 4:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0b31e22b-202f-6fca-28f2-e16e6af6c6b7@emagii.com>
2017-11-20 4:23 ` RFC: Copying Device Tree File into reserved area of VMLINUX before deployment Frank Rowand
[not found] ` <a0f9d598-04af-fddd-58ad-09db10ec19da-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-20 4:32 ` Frank Rowand [this message]
2017-11-20 20:19 ` Ulf Samuelsson
2017-11-20 21:39 ` Frank Rowand
2017-11-20 23:09 ` Ulf Samuelsson
2017-11-21 6:19 ` Ulf Samuelsson
[not found] ` <4d2f0bf4-d49a-27bc-75aa-11c78bc074fa-AoFPY8dbyRPQT0dZR+AlfA@public.gmane.org>
2017-11-21 12:02 ` Ulf Samuelsson
2017-11-21 17:09 ` Rob Herring
2017-11-21 20:03 ` Ulf Samuelsson
2017-11-20 11:44 ` Mark Rutland
[not found] ` <20171120114405.cpsf4xtvvfpuk76u-agMKViyK24J5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
2017-11-20 16:38 ` Frank Rowand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fe7925f3-30d4-ec03-a6c5-61a8644dcdfe@gmail.com \
--to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-AoFPY8dbyRPQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).