Importing DTS for arm64

[Emmanuel Vadot]

On Mon, 20 Aug 2018 16:46:01 +0100
Alexandru Elisei <alexandru.elisei at 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 at 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 at bidouilliste.com> <manu at freebsd.org>
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> >


-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>