[U-Boot] [PATCH 0/9] Switch bcm283x platform to use OF_CONTROL

[Stefan Bruens <stefan.bruens@rwth-aachen.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 <stefan.bruens@rwth-aachen.de> writes:
> > > On Donnerstag, 6. Oktober 2016 12:32:12 CEST Eric Anholt wrote:
> > >> Alexander Graf <agraf@suse.de> writes:
> > >> >> Am 05.10.2016 um 18:48 schrieb Fabian Vogt <fvogt@suse.com>:
> > >> >> 
> > >> >> 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