Date: Mon, 20 Aug 2018 17:11:50 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: Importing DTS for arm64 Message-ID: <20180820171150.cc8e08114a1d9553da6056f9@bidouilliste.com>
next in thread | raw e-mail | index | archive | help
Hello arm@ I would like to import the DTS for arm64 in the tree and use them like we do for the arm ones. We currently rely on the bootloader/firmware to give us a DTB to work with, this works nicely until it doesn't. Here is why I want to import the DTS : - 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. I would love to do that for 12 even if we are approching code freeze, this will allow FreeBSD 12 to be more than awesome on arm64. Cheers, -- Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180820171150.cc8e08114a1d9553da6056f9>