Switch bcm283x platform to use OF_CONTROL
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 9 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 9 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 0/9] Switch bcm283x platform to use OF_CONTROL
Quoted 46 lines · On Freitag, 7. Oktober 2016 16:42:40 CEST Tom Rini wrote:
Quoted 45 lines · Eric Anholt
Quoted 44 lines · Stefan Bruens
Quoted 42 lines · On Donnerstag, 6. Oktober 2016 12:32:12 CEST Eric Anholt wrote:
Quoted 24 lines · Alexander Graf
Quoted 24 lines
Am 05.10.2016 um 18:48 schrieb Fabian Vogt <[email protected]>:
Hi,
Am Mittwoch, 5. Oktober 2016, 09:54:46 CEST schrieb Stephen Warren:
Quoted 7 lines · Fabian Vogt
Quoted 5 lines
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.Quoted 6 lines
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
Quoted 6 lines
Quoted 1 line
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.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
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
Signature · 3 lines
Stefan Br?ns / Bergstra?e 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424