From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bruens Date: Fri, 7 Oct 2016 01:22:53 +0200 Subject: [U-Boot] [PATCH 0/9] Switch bcm283x platform to use OF_CONTROL In-Reply-To: <871sztw9xf.fsf@eliezer.anholt.net> References: <20160926122651.22132-1-fvogt@suse.com> <18FBD080-6E6A-42BB-AAF4-36A626E3E3F1@suse.de> <871sztw9xf.fsf@eliezer.anholt.net> Message-ID: <5195146.vhkPzrWSSn@pebbles.site> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Donnerstag, 6. Oktober 2016 12:32:12 CEST Eric Anholt wrote: > Alexander Graf writes: > >> Am 05.10.2016 um 18:48 schrieb Fabian Vogt : > >> > >> Hi, > >> > >> Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren: > >>> On 09/26/2016 06:26 AM, Fabian Vogt wrote: > >>>> This patch series modifies the used drivers to work with OF_CONTROL > >>>> and switches the board code and configs to use it. > >>>> The added device trees are directly from the linux kernel tree > >>>> and can thus be used for booting the (upstream) kernel. > >>> > >>> Is there a user-visible or developer-visible benefit to this change? In > >>> general, converting to use DT to instantiate devices simply ends up > >>> using more code (and hence complexity and time) to get to the exact same > >>> state afterwards. > >> > >> There are various reasons, like: > >> > >> - The device tree describes the platform, so it can also be used by the > >> > >> linux kernel for configuration (no separate dtb needed) > > > > With a bit of lobbying, we might even be able to get a working dt from > > the rpi firmware. That again would enable awesome things like hat > > support in u-boot :). > > I can't imagine the firmware handing any DT off to the kernel other than > the one that's being shipped from whatever kernel is being loaded. > Being able to update the DT in lockstep with the kernel is very much > part of their process. (This makes linux insisting that DT is ABI that > must maintain backwards compat quite painful for upstreaming) > > Given that the firmware already hands the kernel's DT back to the > kernel, it seems like we should be able to load the kernel's DT too if > we wanted that. You mean the DT modified by the firmware according to config.txt, at least applying the specified DT overlays? Kind regards, Stefan -- Stefan Br?ns / Bergstra?e 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424