Hi Mathew,
Am 2021-02-15 01:28, schrieb Mathew McBride:
On Sat, Feb 13, 2021, at 2:13 AM, Michael Walle wrote:
Hi,
I am looking into how to bring openwrt support for my board
(Kontron sl28) upstream. The board has upstream support in
both vanilla linux (since 5.8) and vanilla u-boot. Someone
in IRC told me there will be a new release based on 5.10 after
the 21.02 branch is created. So that would be a nice fit.
I'd have thought the board will fit it linux/layerscape but that
is the vanilla kernel with all the NXP lsdk patches on top of it,
which my board doesn't need and frankly speaking I don't want. The
same is true for the uboot-layerscape package. Thats the LSDK
version.
I/we (Traverse) also have layerscape boards that run OpenWrt.
I've seen that.
When the layerscape target was first introduced (~2017), most of the
drivers for these SoCs were not in mainline linux yet.
Since then, the situation has changed, the newer SoCs (e.g
DPAA2/LS1088/LS2088) are very much complete (and in some ways, better)
in >=5.10 and the others are not far behind.
I understand there are some edge cases, such as the DPAA1
(LS1043/LS1046) Ethernet drivers in mainline were a 'clean' rewrite of
NXP/Freescale's long standing 'Netcomm' driver and have different
performance and features to mainline.
I would put forward the following options:
1. For future OpenWrt releases with kernel >=5.10, stop using LSDK
patches, or only pick the required patchset for SoCs not in upstream
(e.g any new Layerscape SoCs that are introduced)
I suspect the size of the NXP LSDK patchset will decrease signifcantly
when rebased onto >=5.10 so this problem may solve itself.
From what I can tell they just exported the patches of their LSDK
kernel regardless if they are needed or not. For example, there are
patches for the LS1028A and its integrated switch, although it is not
supported according to the README in openwrt. So really, I presume NXP
took the simple way and just export all their patches regardless if
they are really needed or not.
One might argue, that is actually a good thing, because that way it
is also easy to support other SoCs. But yeah..
Anyway, for my board I really don't like to use the LSDK kernel.
2. Introduce a generic 'armv8' target for systems that have 'block
storage' (SATA/MMC/NVMe), targetting U-Boot distroboot and ARM
EBBR(EFI), which would look a lot like the existing x86 target.
That sounds exactly what I had in mind. Both distroboot and EFI
boot is supported on my board.
I did have a go myself at introducing an 'armserver' target for EFI
boot a while ago, this was before x86-64 EFI support was introduced.
There were suggestions that it should go into 'armvirt', though the
existing armvirt/32 target may not share the same goals.
I'd presume that armvirt has a rather limited set of actual
hardware drivers, in contrast to a generic armv8 board which would
need all kind of hardware drivers for its supported boards.
Since I'm new to openwrt, is there a rule which drivers are compiled
into the kernel and which are not? Could we make the generic arm64
board use modules as much as possible?
Boards that boot from flash (ubifs) or have special requirements (such
as bundling the RCW/ATF) could continue using the individual targets.
Right, I don't see a need to actually cover the board startup for the
layerscape SoC and assume there will be a functional bootloader and
block storage device. I mean, I don't think there will be memory and
flash constrained boards which actually use these SoCs. And I guess
this is also true for EFI (or distroboot) capable arm64 boards.
-michael
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
