Add FriendlyArm NanoPi R4S config for generation of release images

[decke]

Summary

Adds support for FriendlyArm NanoPi R4S (4GB/LPDDR4).

This is basically a copy of the ROCKPRO64 config but with the correct u-boot.

There is a problem with the MAC address for the second NIC (RealTek, labelled LAN) because it is written (or parts of it) in a EEPROM so the device is currently detected properly but comes up without MAC address. The manufacturer has implemented this in u-boot [1] but Linux distros seem to favorize to fix this in the kernel. Patches to get that EEPROM visible do exist already [2] but I have not seen a final decision yet.

For the moment the easiest way was to get the MAC address by booting one of the vendor images and then set it in FreeBSD manually like this:
ifconfig re0 link 12:89:1E:60:A1:9C

[1] https://github.com/friendlyarm/uboot-rockchip/blob/244492a7a5451eca042d3ec7ccff8de6e23dd288/board/friendlyarm/nanopi4/nanopi4.c#L49
[2] https://lkml.org/lkml/2021/6/10/297

Test Plan

Tested images with current (20210621) and 13.0-RELEASE on NanoPi R4S 4G.

The SoC including USB and sdcard and both NICs work fine (once you set a MAC address for the RealTek NIC).

The manufacturer also sold a NanoPi R4S 1GB/DDR3 but that is not supported by official u-boot yet and they don't seem to sell it anymore.

Idle power consumption with FreeBSD is around 2.9W (no NICs active) and 3.6W with both NICs active.
FriendlyWrt is at 2.4W idle (no NICs active).

[manu]

I'm not sure that we want to add all possible image.
RPI was added because, unfortunately it's popular.
All the Pine devices are too and most have LTS status.
If we start adding every FriendlyElec we're in trouble because they release a lot of boards (like a lot).

[gjb]

In D31134#704406, @manu wrote:

I'm not sure that we want to add all possible image.
RPI was added because, unfortunately it's popular.
All the Pine devices are too and most have LTS status.
If we start adding every FriendlyElec we're in trouble because they release a lot of boards (like a lot).

If that is the case, it would also add a significant amount of time for snapshot/release builds.

I wonder if we should poll the community at large to solicit feedback on what boards we build images for that are actually being used. (Although, this could backfire spectacularly, perhaps.)

[manu]

In D31134#704419, @gjb wrote:

In D31134#704406, @manu wrote:

I'm not sure that we want to add all possible image.
RPI was added because, unfortunately it's popular.
All the Pine devices are too and most have LTS status.
If we start adding every FriendlyElec we're in trouble because they release a lot of boards (like a lot).

If that is the case, it would also add a significant amount of time for snapshot/release builds.

I wonder if we should poll the community at large to solicit feedback on what boards we build images for that are actually being used. (Although, this could backfire spectacularly, perhaps.)

I think that the first thing that we need to do is to do a GENERICSD image like we do for armv7.
This should be GPT with enough space for u-boot (the rockchip part scheme is enough).
This will cover all board except RPI3 and RPI4 with old firmware (iirc).

[decke]

In D31134#704419, @gjb wrote:

In D31134#704406, @manu wrote:

I'm not sure that we want to add all possible image.
RPI was added because, unfortunately it's popular.
All the Pine devices are too and most have LTS status.
If we start adding every FriendlyElec we're in trouble because they release a lot of boards (like a lot).

If that is the case, it would also add a significant amount of time for snapshot/release builds.

I wonder if we should poll the community at large to solicit feedback on what boards we build images for that are actually being used. (Although, this could backfire spectacularly, perhaps.)

Well yes, they produce a lot of boards but the number of boards where FreeBSD really runs fine without a lot of troubles and patches is a lot lower. Some are not supported by upstream u-boot, some use SoCs that we don't support, many have peripherals on it we don't support (from graphics to wifi to bluetooth, ...). From that point of view the R4S is really unique because FreeBSD actually runs just fine on it and supports all the hardware that is there. What also makes the hardware special is that it has two NICs and that makes it very interesting as a firewall appliance and many people asking for it are from our OPNsense / pfSense downstreams.

Right now we only have 6 u-boot ports for FriendlyArm boards in the portstree - don't know about the status of those boards but we don't build images for any of them.

Since aarch64 is Tier 1 now I think it would be a shame if end users cannot easily download a FreeBSD image for hardware that is supported very well but have to produce images themselves or rely on images from an untrusted 3rd party because they can actually do it.

[manu]

In D31134#704489, @decke wrote:

In D31134#704419, @gjb wrote:

In D31134#704406, @manu wrote:

I'm not sure that we want to add all possible image.
RPI was added because, unfortunately it's popular.
All the Pine devices are too and most have LTS status.
If we start adding every FriendlyElec we're in trouble because they release a lot of boards (like a lot).

If that is the case, it would also add a significant amount of time for snapshot/release builds.

I wonder if we should poll the community at large to solicit feedback on what boards we build images for that are actually being used. (Although, this could backfire spectacularly, perhaps.)

Well yes, they produce a lot of boards but the number of boards where FreeBSD really runs fine without a lot of troubles and patches is a lot lower. Some are not supported by upstream u-boot, some use SoCs that we don't support, many have peripherals on it we don't support (from graphics to wifi to bluetooth, ...). From that point of view the R4S is really unique because FreeBSD actually runs just fine on it and supports all the hardware that is there. What also makes the hardware special is that it has two NICs and that makes it very interesting as a firewall appliance and many people asking for it are from our OPNsense / pfSense downstreams.

Downstream can always produce image for this board.

Right now we only have 6 u-boot ports for FriendlyArm boards in the portstree - don't know about the status of those boards but we don't build images for any of them.

Most (if not all) where added by me because I own those boards and test FreeBSD on them.

Since aarch64 is Tier 1 now I think it would be a shame if end users cannot easily download a FreeBSD image for hardware that is supported very well but have to produce images themselves or rely on images from an untrusted 3rd party because they can actually do it.

[decke]

Some time has passed so can we continue with the discussion now?

[decke]

Can we please continue the discussion if it is feasible to add more images/boards to the release scripts?

[gjb]

In D31134#718456, @decke wrote:

Can we please continue the discussion if it is feasible to add more images/boards to the release scripts?

Apologies for the delay getting back to this. Please bear with me, as I have been extremely busy the past few weeks.

[manu]

IMHO it would be better to not add new images for a specific board but instead do a GENERICSD image like I did for armv7.
Something with a GPT scheme and the same gap between start of card and first partition like ROCKPRO64 would suit any board compliant with GPT (all but earlier RPI4 and all RPI3).
Also since there is still some problem with the MAC address like you said that will be a very bad first impression for someone who tries the image.

[s199p.wa1k9r_gmail.com]

it is a very correct idea to have a GENERICSD image and you can use it as a template
and based on it you can quickly generate a lot of images simply by replacing u-boot and applying overlays

[s199p.wa1k9r_gmail.com]

Maybe you can write a simple program that will read the eeprom using the i2c protocol and extract the correct MAC address?