Date: Mon, 20 Aug 2018 17:53:19 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Alexandru Elisei <alexandru.elisei@gmail.com> Cc: arm@freebsd.org Subject: Re: Importing DTS for arm64 Message-ID: <20180820175319.e3c4ebbc8b805da931d2239c@bidouilliste.com> In-Reply-To: <CAB-4s4mYzf5mbWstcbJNUsTBQaR8DKyEt0vT29sk9MrYncgbSg@mail.gmail.com> References: <20180820171150.cc8e08114a1d9553da6056f9@bidouilliste.com> <CAB-4s4mYzf5mbWstcbJNUsTBQaR8DKyEt0vT29sk9MrYncgbSg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Aug 2018 16:46:01 +0100 Alexandru Elisei <alexandru.elisei@gmail.com> wrote: > Hello, > > Where do you plan to put the DTS files? In sys/dts/arm64? No sys/gnu/dts/arm64 > I am using a custom DTS for bhyve guest (in that location), I think having > a standard directory for arm64 DTS files is a good idea. I plan to make overlays in sys/dts/arm64, we could put the bhyve DTS here, or if you plan to generate one based on bhyve option having the base one in share/ would be better I think. > Regards, > Alex > > On Mon, Aug 20, 2018 at 4:12 PM Emmanuel Vadot <manu@bidouilliste.com> > wrote: > > > > > 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> > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > -- 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?20180820175319.e3c4ebbc8b805da931d2239c>