- Most of the boards are using U-Boot, u-boot embed a DTB that isn't
compiled with -@ (overlay ready) so we cannot use overlays. We want
overlays, overlays are nice.
- The DTS life is going to linux, then sometimes it's imported in
U-Boot but it depend on the SoC family, U-Boot doesn't batch import
every DTS like we do. So sometimes to U-Boot DTS are very old. Or when
an interesting patch in commited upstream it is in Linux X+2 (roughly 4
months from now), we then have to wait for U-Boot to catch up, that
give us between 4 and 6 months to have an update.
- Some boards like the Marvell ones have 3 DTS, the one in the
vendor U-Boot made by Marvell themselves, the one in u-boot mainline
and the one in Linux. I found that the DTS in the Marvell U-Boot have
some problem with FreeBSD (especially the macchiatobin that declare
node with the same address but not the same size, that is not something
that the rman code can handle, it could be modified, I don't know the
code well enough). Also some compatible are used when they shouldn't,
for example they declare the gpio being orion-gpio while this binding
requires interrupts supports, which the node doesn't have.
- The above situation is mostly the same with RockChip SoCs (possibly
others, those are the only SoCs I work on that have this problem).
Note that importing the DTS doesn't mean that every board will use
them, I don't intend to copy the DTB to the GENERIC memstick image for
the Overdrive 1000/3000 for example, the ones provided by the firmware
works fine.
RPI3 will still stay an exception as we use the DTB provided by the
rpi-firmware package, so they come from the rpi foundation linux fork.
19442a3a49