From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> To: Dave Martin <dave.martin@linaro.org> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [ARM] Use AT() in the linker script to create correct program headers Date: Fri, 12 Oct 2012 15:24:06 -0600 [thread overview] Message-ID: <20121012212406.GN4124@obsidianresearch.com> (raw) In-Reply-To: <20121010095544.GB2131@linaro.org> On Wed, Oct 10, 2012 at 10:55:44AM +0100, Dave Martin wrote: > As a side comment, some things such as MAC addresses can be probed and > set from userspace after kernel boot, assuming that you have a way > to fetch the device description blob from userspace. If it's accessible > via MTD I'm guessing you may have some chance of doing that. Yes, there is a whole wack of other data in this structure (serial numbers, etc) that are captured and used by userspace, so access is always made possible. Setting the MAC via userspace is interesting, I will bear that in mind. However, we have several development-support boot scenarios that enable the ethernet before the userspace code to fetch the data structure is loaded - one of interest has the kernel's initramfs perform a NBD mount of the actual application filesystem. So having the kernel tend to this is very convenient. > However, I worry that if you have to run hardware-dependent code in > order to fetch or generate parts of the DT, then we have a chicken- > and-egg problem with no guaranteed solution with the frameworks that > exist today -- although I am not familiar with how DT gets used on > all other arches, so you might have counterexamples I'm not aware of. Certainly, in some cases, (like what I have done) such kernels are non-generic and could only work with the hardware they are intended for. However, if you assume the bootloader provides a dtb (even an incomplete one would do) then fixups/replacements/whatever could be run based on tags in the dtb without creating a chicken-and-egg problem. > At least in ARM-land, the DT is inherently monolithic and static: the > DT is not expected to change once you enter the kernel. Sort of, it is the same on all arches, the DT block is expected to remain valid, but all the of_node pointers go directly into the block so you can alter values but not the structure without breaking any invariants. As an example our DTBs all have mac address blocks, with a 0 value. The fixup simply overwrites with the correct value before the ethernet driver reads from it. > > I'm not sure there is a great interest in this? What are other folks > > working on production embedded stuff doing? I suppose that will be > > more clear as device tree is rolled out. > > For now, the architecturally simplest solution still seems to me to be > to write your own boot shim which customises the DT before booting the > kernel. As discussed, this can continue to look like a simple ELF image > from the bootloader's point of view -- but I appreciate that it will > involve effort and some duplication of some low-level driver components. I admit, I am a bit conflicted. Viewing from the kernel perspective, I definitely think this kind of very low level extremely board specific stuff should not be in the kernel. That could be a maintenance nightmare. However, as an OEM, I need the smallest, simplest boot loader possible so I want to push this into the kernel to lighten my development load. > Your problem is unlikely to affect people outside the embedded space > too much, but it doesn't sound likely to be unique. Agreed.. This thread has left the original topic, what do you think I should do with the linker patch? Jason
WARNING: multiple messages have this Message-ID (diff)
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] [ARM] Use AT() in the linker script to create correct program headers Date: Fri, 12 Oct 2012 15:24:06 -0600 [thread overview] Message-ID: <20121012212406.GN4124@obsidianresearch.com> (raw) In-Reply-To: <20121010095544.GB2131@linaro.org> On Wed, Oct 10, 2012 at 10:55:44AM +0100, Dave Martin wrote: > As a side comment, some things such as MAC addresses can be probed and > set from userspace after kernel boot, assuming that you have a way > to fetch the device description blob from userspace. If it's accessible > via MTD I'm guessing you may have some chance of doing that. Yes, there is a whole wack of other data in this structure (serial numbers, etc) that are captured and used by userspace, so access is always made possible. Setting the MAC via userspace is interesting, I will bear that in mind. However, we have several development-support boot scenarios that enable the ethernet before the userspace code to fetch the data structure is loaded - one of interest has the kernel's initramfs perform a NBD mount of the actual application filesystem. So having the kernel tend to this is very convenient. > However, I worry that if you have to run hardware-dependent code in > order to fetch or generate parts of the DT, then we have a chicken- > and-egg problem with no guaranteed solution with the frameworks that > exist today -- although I am not familiar with how DT gets used on > all other arches, so you might have counterexamples I'm not aware of. Certainly, in some cases, (like what I have done) such kernels are non-generic and could only work with the hardware they are intended for. However, if you assume the bootloader provides a dtb (even an incomplete one would do) then fixups/replacements/whatever could be run based on tags in the dtb without creating a chicken-and-egg problem. > At least in ARM-land, the DT is inherently monolithic and static: the > DT is not expected to change once you enter the kernel. Sort of, it is the same on all arches, the DT block is expected to remain valid, but all the of_node pointers go directly into the block so you can alter values but not the structure without breaking any invariants. As an example our DTBs all have mac address blocks, with a 0 value. The fixup simply overwrites with the correct value before the ethernet driver reads from it. > > I'm not sure there is a great interest in this? What are other folks > > working on production embedded stuff doing? I suppose that will be > > more clear as device tree is rolled out. > > For now, the architecturally simplest solution still seems to me to be > to write your own boot shim which customises the DT before booting the > kernel. As discussed, this can continue to look like a simple ELF image > from the bootloader's point of view -- but I appreciate that it will > involve effort and some duplication of some low-level driver components. I admit, I am a bit conflicted. Viewing from the kernel perspective, I definitely think this kind of very low level extremely board specific stuff should not be in the kernel. That could be a maintenance nightmare. However, as an OEM, I need the smallest, simplest boot loader possible so I want to push this into the kernel to lighten my development load. > Your problem is unlikely to affect people outside the embedded space > too much, but it doesn't sound likely to be unique. Agreed.. This thread has left the original topic, what do you think I should do with the linker patch? Jason
next prev parent reply other threads:[~2012-10-12 21:24 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-09-30 23:21 [PATCH] [ARM] Use AT() in the linker script to create correct program headers Jason Gunthorpe 2012-09-30 23:21 ` Jason Gunthorpe 2012-10-01 15:39 ` Dave Martin 2012-10-01 15:39 ` Dave Martin 2012-10-01 16:06 ` Jason Gunthorpe 2012-10-01 16:06 ` Jason Gunthorpe 2012-10-01 17:56 ` Dave Martin 2012-10-01 17:56 ` Dave Martin 2012-10-01 18:35 ` Jason Gunthorpe 2012-10-01 18:35 ` Jason Gunthorpe 2012-10-02 10:23 ` Dave Martin 2012-10-02 10:23 ` Dave Martin 2012-10-02 17:47 ` Jason Gunthorpe 2012-10-02 17:47 ` Jason Gunthorpe 2012-10-03 10:43 ` Dave Martin 2012-10-03 10:43 ` Dave Martin 2012-10-03 18:44 ` Jason Gunthorpe 2012-10-03 18:44 ` Jason Gunthorpe 2012-10-04 11:36 ` Dave Martin 2012-10-04 11:36 ` Dave Martin 2012-10-04 17:59 ` Jason Gunthorpe 2012-10-04 17:59 ` Jason Gunthorpe 2012-10-08 10:46 ` Dave Martin 2012-10-08 10:46 ` Dave Martin 2012-10-09 18:25 ` Jason Gunthorpe 2012-10-09 18:25 ` Jason Gunthorpe 2012-10-10 9:55 ` Dave Martin 2012-10-10 9:55 ` Dave Martin 2012-10-12 21:24 ` Jason Gunthorpe [this message] 2012-10-12 21:24 ` Jason Gunthorpe 2012-10-05 8:45 ` Russell King - ARM Linux 2012-10-05 8:45 ` Russell King - ARM Linux 2012-10-08 10:24 ` Dave Martin 2012-10-08 10:24 ` Dave Martin 2012-10-09 17:37 ` Jason Gunthorpe 2012-10-09 17:37 ` Jason Gunthorpe 2012-10-10 9:18 ` Dave Martin 2012-10-10 9:18 ` Dave Martin
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=20121012212406.GN4124@obsidianresearch.com \ --to=jgunthorpe@obsidianresearch.com \ --cc=dave.martin@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.