Build for rpi4 and nanopi r2s

[viralpump]

Hu, do you know how to configure infix for rpi4 and nanopi?

[troglobit]

Infix is built on top of Buildroot, so all Buildroot defconfigs work also in Infix. But for the NETCONF features (like confd & statd) to be enabled, specific RPi and R2S defconfigs need to be ported to Infix.

It so happens I have just got myself an R2S, and was planning to look at it for Infix this coming weekend. If you like to help out testing or contributing you are most welcome!

There are basically two paths:

1. Integrate support for R2S (and RPi) in the aarch64_defconfig, meaning add missing drivers to the Linux .config in board/aarch64/, and board specific packages to aarch64_defconfig
2. Add separate r2s_defconfig (and similar for the RPi's) and board/r2s/ (or similar) to hold the Linux .config and other files, inheriting from the board/aarch64/ post-build and post-image scripts.

I think (2) is the most attractive one to start with, take one board at a time, and then integrate them into the generic aarch64 depending on demand.

Customers we support on custom boards right now use the aarch64_defconfig as a reference build, so it's targeted at our reference and customer boards. It will receive the most testing and any other defconfig will need more help from the community or company sponsor.

Hope this answers your question.

[minexn]

@troglobit I have several R2S units sitting idle that I used for VxLAN testing. I would be happy to do some testing with R2S.

[troglobit]

Initial work on the Nanopi R2S has now started on the branch https://github.com/kernelkit/infix/commits/nanopi-r2s-support/

Please note, even though Infix generates an sdcard.img and boots, it currently refuses to let you in because of lack of a VPD factory password, or a device tree fallback. I'll have a chat with @wkz about this in the morning (CET). When we have something that works, I'll post a separate discussion thread ab out it. (ping @supapavel)

[troglobit]

It boots, it runs, it's here! #271

[troglobit]

Aaaaand merged to mainline! Next up, I'll add some more documentation and GitHub build actions to make it easier to try it out.

[minexn]

We are testing infix on a phyCORE-AM64x and want to contribute the code back to infix, so it would be good to see if we can integrate it into the aarch64_defconfig or a separate am64x_defconfig.

[troglobit]

I haven't discussed all the details yet with @wkz, but have a look at #271 to see how I integrated the R2S. I think it's a good starting (staging?) point for new HW before we "mainline" them in the aarch64_defconfig.

[wkz]

We are testing infix on a phyCORE-AM64x and want to contribute the code back to infix, so it would be good to see if we can integrate it into the aarch64_defconfig or a separate am64x_defconfig.

Out of curiosity, how is the handover between the bootloader and Linux done, are you using the standard image format with our U-Boot scripts or some custom glue?

[troglobit]

@troglobit I have several R2S units sitting idle that I used for VxLAN testing. I would be happy to do some testing with R2S.

Awesome, I'll let you know by the end of the weekend, hopefully!

[troglobit]

We are testing infix on a phyCORE-AM64x and want to contribute the code back to infix, so it would be good to see if we can integrate it into the aarch64_defconfig or a separate am64x_defconfig.

To begin with I think we should start with a separate am64x_defconfig, add it to all GitHub actions, and then merge it when it's stabilized. That's what I'll do with the R2S defconfig too. Hope that's OK?

(The RPi builds will come a bit later, I'm hoping to use them as internal training for our junior devs. It'll be at least one separate build here too, that can be merged to the generic aarch64_defconfig later.)

[minexn]

@troglobit is your device reporting the eth0 MAC address to be ea:b1:0e:3c:f2:01?

[troglobit]

@wkz iirc, lots of vendors store their base MAC in the uboot env, or am i misremembering? In your travels, have you looked into how we leverage anything like as a poor-man's VPD?

[minexn]

The MAC address is stored in uboot env.

=> printenv ethaddr                
ethaddr=ea:b1:0e:3c:f2:01

[troglobit]

The MAC address is stored in uboot env.

=> printenv ethaddr                
ethaddr=ea:b1:0e:3c:f2:01

Yeah, that's the same as I have on mine. I guess U-Boot must have a built-in default, we use the vanilla/upstream U-Boot so not anything from Rockchip or NanoPi themselves.

[wkz]

@troglobit: Yes they do. I order for the kernel to pick it up, U-Boot needs to mangle the DTB and insert it in the interface's node, either in the mac-address or local-mac-address property (see of_get_mac_address). IIRC, U-Boot should update local-mac-address.

When you boot your boards, what properties are set on the ethernet interface in /sys/firmware/devicetree/...? If the address is there, then we'll have to look at the driver. If it is not there, then we need to figure out why U-Boot doesn't inject it.

[troglobit]

@minexn I talked to @wkz AFK today, and he reminded me of the schematics he mentioned previously, and I've just double-checked with my R2S at home. The EEPROM for the unique MAC address does not appear to be mounted, and I suspect it's the same with your boards.

The way to go for these types of devices is unfortunately to manually set a unique MAC address in U-Boot. So, getting RAUC upgrades working for SD-card partitions seem to be the way forward to avoid having to reprogram U-Boot every time the sdcard is reflashed.