Any good alternative to Raspberry for Arm64?

[Dan Kotowski]

On Wednesday, March 31st, 2021 at 23:20, Alexander Kabaev <kabaev at gmail.com> wrote:

> On Tue, 30 Mar 2021 17:14:01 -0700
>
> Mark Millard via freebsd-arm freebsd-arm at freebsd.org wrote:
>
> > On 2021-Mar-30, at 16:32, Ian Lepore <ian at freebsd.org> wrote:
> >
> > > On Tue, 2021-03-30 at 22:52 +0000, Dan Kotowski wrote:
> > >
> > > > > `guess SFP+ would need more special driver-attention ...
> > > > > from quick reading around the web I guess the DPAA2 also needs a
> > > > > closed source binary blob.
> > > >
> > > > So this actually comes from NXP, not SolidRun. Linux already has
> > > > some/most of what's needed, and the license is GPL-2.0+ OR BSD-3-
> > > > Clause so there's hope, but I haven't heard a peep from NXP and
> > > > SolidRun doesn't really have the manpower to port to FreeBSD
> > > > themselves.
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/ethernet/freescale/dpaa2/
> > >
> > > That's actually very good news. If it's dual-licensed it can be
> > > included in freebsd without any drama. Still needs porting work, or
> > > maybe it could run using the linuxkpi stuff?
> >
> > The files there are a mix: a few list just:
> >
> > SPDX-License-Identifier: GPL-2.0-only
> > =====================================
> >
> > or:
> >
> > SPDX-License-Identifier: GPL-2.0
> > ================================
> >
> > or:
> >
> > // SPDX-License-Identifier: GPL-2.0
> >
> > or:
> >
> > /* SPDX-License-Identifier: GPL-2.0 */
> >
> > ( Kconfig Makefile dpaa2-ptp.[ch] dprtc-cmd.h dprtc.[ch] )
> >
> > The others (most) list:
> >
> > // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> >
> > or:
> >
> > /* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
> >
> > The Copyrights seem to be Freescale Semiconductor Inc. and/or
> > NXP when documented on a file. May be they would be willing
> > to add the BSD-3-Clause where it is missing?
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
> > ( dsl-only.net went
> > away in early 2018-Mar)
>
> If one does not need to run custom firmware on DPAA2 subsystem, then
> the only binary blob one needs if an MC firmware which is and always
> will be the binary-only thing, per our NXP contacts. MC provides
> intermediate layer API that abstracts hardware configuration at somewhat
> higher level that DPAA from older Layerscape chips did. MC blob is
> freely downloadable and NXP documents MC and DPAA2 interfaces quite
> well, but it is a sizable code to write to get things properly
> integrated. NXP also ships a lot of their low-level code as part of
> DPDK, which is licensed liberally and can be referenced for the
> inspiration. Most of fls_dp* files are available there.
>
> Alexander Kabaev

For what it's worth, this SoC is starting to show up in SmartNICs too:

https://www.xilinx.com/applications/data-center/network-acceleration/alveo-sn1000.html

I don't have the free cycles or expertise to write/port this code myself, but would love to work with someone who does