Any good alternative to Raspberry for Arm64?

[Klaus Küchemann]

> Am 01.04.2021 um 16:12 schrieb Dan Kotowski <dan.kotowski at a9development.com>:
> 
> 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
> _______________________________________________
> 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“


What is this ??   :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253177

….    https://gist.github.com/yarshure/1cc3350b4cbd86d7514514b57987b9d7.     …. 
pcib1: <Generic PCI host controller> on acpi0
pci1: <PCI bus> on pcib1
ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver> port 0x20-0x3f mem 0xa400080000-0xa4000fffff,0xa400504000-0xa400507fff at device 0.0 on pci1
ix0: Using 2048 TX descriptors and 2048 RX descriptors
ix0: Using 16 RX queues 16 TX queues
ix0: Using MSI-X interrupts with 17 vectors
ix0: allocated for 16 queues
ix0: allocated for 16 rx queues
ix0: Ethernet address: 90:1b:0e:44:36:0f
ix0: PCI Express Bus: Speed 5.0GT/s Width x8
……



K.