MFC r342936, r343873r342936:Import DTS from Linux 4.20r343873:arm64: dtb: allwinner: Add the new pine64-lts dtb file to the buildX-MFC-With: r342936
dts: Import DTS for arm64 - Most of the boards are using U-Boot, u-boot embed a DTB that isn'tcompiled with -@ (overlay ready) so we cannot use overlays. We wantoverlays, overlays are nice. - Th
dts: Import DTS for arm64 - Most of the boards are using U-Boot, u-boot embed a DTB that isn'tcompiled with -@ (overlay ready) so we cannot use overlays. We wantoverlays, overlays are nice. - The DTS life is going to linux, then sometimes it's imported inU-Boot but it depend on the SoC family, U-Boot doesn't batch importevery DTS like we do. So sometimes to U-Boot DTS are very old. Or whenan interesting patch in commited upstream it is in Linux X+2 (roughly 4months from now), we then have to wait for U-Boot to catch up, thatgive us between 4 and 6 months to have an update. - Some boards like the Marvell ones have 3 DTS, the one in thevendor U-Boot made by Marvell themselves, the one in u-boot mainlineand the one in Linux. I found that the DTS in the Marvell U-Boot havesome problem with FreeBSD (especially the macchiatobin that declarenode with the same address but not the same size, that is not somethingthat the rman code can handle, it could be modified, I don't know thecode well enough). Also some compatible are used when they shouldn't,for example they declare the gpio being orion-gpio while this bindingrequires interrupts supports, which the node doesn't have. - The above situation is mostly the same with RockChip SoCs (possiblyothers, those are the only SoCs I work on that have this problem). Note that importing the DTS doesn't mean that every board will usethem, I don't intend to copy the DTB to the GENERIC memstick image forthe Overdrive 1000/3000 for example, the ones provided by the firmwareworks fine. RPI3 will still stay an exception as we use the DTB provided by therpi-firmware package, so they come from the rpi foundation linux fork.
show more ...