New layerscape/aarch64 board

[Michael Walle]

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