From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bruens Date: Fri, 7 Oct 2016 23:59:02 +0200 Subject: [U-Boot] [PATCH 0/9] Switch bcm283x platform to use OF_CONTROL In-Reply-To: <20161007204240.GK4884@bill-the-cat> References: <20160926122651.22132-1-fvogt@suse.com> <87shs87os3.fsf@eliezer.anholt.net> <20161007204240.GK4884@bill-the-cat> Message-ID: <4387203.cBMEeMVPVY@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 Freitag, 7. Oktober 2016 16:42:40 CEST Tom Rini wrote: > On Thu, Oct 06, 2016 at 09:42:52PM -0700, Eric Anholt wrote: > > Stefan Bruens writes: > > > 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? > > > > Yeah, that. > > That would also be a good thing, yes. My primary concern here was the bcm2708-rpi-b.dtb vs bcm2835-rpi-b.dtb devicetrees, i.e. the one distributed by the RPi foundation vs the upstream kernel one. This concern may no longer be valid, https://www.raspberrypi.org/ documentation/configuration/device-tree.md#part3 says: --- The loader now supports builds using bcm2835_defconfig, which selects the upstreamed BCM2835 support. This configuration will cause bcm2835-rpi-b.dtb and bcm2835-rpi-b-plus.dtb to be built. If these files are copied with the kernel, and if the kernel has been tagged by a recent mkknlimg, then the loader will attempt to load one of those DTBs by default. --- Open points: 1. is u-boot.bin tagged in an appropriate way (i.e. as done by mkknlimg)? 2. what about the other RPis, i.e. RPi2, RPI3, RPi1-CM? Kind regards, Stefan -- Stefan Br?ns / Bergstra?e 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424