Update NanoPi R2S #551
Update NanoPi R2S #551
Conversation
This was a temporary fix to a Buildroot regression, reverted in Infix commit c7c21b3 Signed-off-by: Joachim Wiberg <[email protected]>
- Bump kernel to 6.10.3
- Initial defconfig sync with aarch64
- Enable kprobes, ksyms, and function tracer
- Enable missing file systems for parity with Infix
- Enable bridging, netfilter, and other Infix requirements
- Initial virtion support for running in Qemu (untested)
- Enable device mapper, required for rauc bundle install
- Make dummy and tunnel drivers modules to be able to drop dummy0
and tunl0 interfaces that otherwise mess up "show interfaces"
- Disable suspend and hibernation, not supported in Infix
- Disable unused GPIO, PHY, MDIO, and USB drivers
- Disable RK3328 watchdog driver, cannot perform reset on R2S,
enablle softdog instead as a seamless replacement for Infix.
Even though not optimal (since it's software) reboot works
- Disable ethtool netlink support, does not work and breaks
interface configuration completely on R2S!
- Enable netdev LED triggers, for LAN and WAN LEDs
- Bump u-boot to 2024.07
- Hard code developer mode to allow shell access
- Disable factory reset button support (not yet supported)
- Bump ATF to v2.9
- Enable squashfs for rootfs image
- Enable signing of images
- Add secondary partition
- Add dedicated var partition
- Add aux partition for signatures and uboot env
Signed-off-by: Joachim Wiberg <[email protected]>
U-Boot (2024.07) does not yet support the 'metadata_csum' feature flag to Ext4 file systems. So let's disable it for now in mkaux.sh so we can allow builds for, e.g., the R2S and VisionFive2 boards to modify and save their U-Boot environment. Needed on the NanoPi R2S to set ethaddr + eth1addr since it does not have any VPD EEPROM mounted. Signed-off-by: Joachim Wiberg <[email protected]>
This change allows modifying and saving the U-Boot environment to the aux partition on the NanoPi R2S. Required to able to safely maintain multiple R2S devices on the same LAN. Signed-off-by: Joachim Wiberg <[email protected]>
- Enable BR2_DOWNLOAD_FORCE_CHECK_HASHES for R2S - Relocate VisionFive2 patches to global patch dir for sharing with R2S - Add hash for ATF v2.9 Signed-off-by: Joachim Wiberg <[email protected]>
Fixes #275 Signed-off-by: Joachim Wiberg <[email protected]>
With new features & fixes, Infix grows. With the latest support for rauc upgrades introduced with the VisionFive2, and now also for R2S, we need to reserve room for future upgrades even when running from an SD card. This is a quick fix for genimge generated SD card imaages before we get a proper installer in place that can be used both on the target and host systems to partition and provision an eMMC, NVME, SSD, or an SD card. Signed-off-by: Joachim Wiberg <[email protected]>
Signed-off-by: Joachim Wiberg <[email protected]>
For prototyping experimental wireless support for Infix. Signed-off-by: Joachim Wiberg <[email protected]>
The R2S has a minimal set of system LEDs, all of which are single color. This commit tries to distill and map the essence of the Infix functions to available LEDs. The SYS LED is turned on (fainy red) at power-on, when U-Boot has loaded the kernel it turns the SYS LED bright red on. The idea is then to turn the red SYS LED off as soon as the system has successfully loaded system startup-config, and then turn the green LAN LED on. Indicating that the both the device is operational and that the user can connect to the LAN port. The WAN LED is given a "wan-up" input condition, with the intention of turning it on (green) when the device has acquired a DHCP address. The failure modes, which in many ways is the essence of Infix signaling, are fail-safe and panic, triggered by loading failure-config, or failing to loadd failure-config, respectively. In fail-safe mode the SYS LED is blinking red at 5 Hz and in panic mode *all* LEDs blink at 5 Hz. Issue #276 Signed-off-by: Joachim Wiberg <[email protected]>
Only the most important bridge and usb fixes have been ported in this commit, and a new patch for the r8153 link/traffic LEDs, ported from the FriendlyELEC/Rockchip kernel tree. Fixes #274 Signed-off-by: Joachim Wiberg <[email protected]>
This serves as an example of how a board specific builds in Infix can carry a static factory-config. This will be extended upon as we add support for DHCP server, WiFi access point, and firewall support. For now the following features are added: - Default hostname: r2s instead of infix-00-00-00 - LAN port always at 192.168.2.1/24, IPv6 SLAAC enabled - WAN port has DHCP enabled for IPv4, IPv6 SLAAC disabled - NTP client enabled, default server pool.ntp.org - DHCP client is set up to request and allow ntp server Signed-off-by: Joachim Wiberg <[email protected]>
This patch further cleans up the r2s kernel config and also enables the input event framework for the gpio0 reset button on the device. The very simple input-event-daemon is introduced, with the only purpose of listening to /dev/input/event1 for KEY_RESTART and trigger reboot. Some helpful tooling is also added to help debug events (evtest). Issue #276 Signed-off-by: Joachim Wiberg <[email protected]>
This patch allows us to define the rauc manifest compatibility string with menuconfig. The INFIX_IMAGE_ID is a direct replacement for the previously composed "infix-$ARCH" in mkrauc.sh. For example, the compatibility string "infix-aarch64" is replaced for the NanoPi R2S with "infix-r2s" to ensure users get a proper warning if they try upgrading to an image that maybe boots, but is not likely to work. The CLI upgrade command gets a 'force' flag to override the compat string. Signed-off-by: Joachim Wiberg <[email protected]>
Fixes to SC2086 mostly. Signed-off-by: Joachim Wiberg <[email protected]>
| ### Changes | ||
| - Initial RISC-V (riscv64) support: StarFive VisionFive2 | ||
| - Massive updates to the NanoPi R2S: | ||
| - Update Linux kernel to v6.10.3 and sync defconfig with aarch64 |
There was a problem hiding this comment.
I do not really like this, i think all platform should use the same kernel (if possible). To ease maintainability for potental bugfixes etc. To get But that is just my principles, please challenge it.
There was a problem hiding this comment.
Interesting point of discussion. I think of it more as a long-term goal to work towards rather than an absolute. In particular to keep differences between Infix-based boards to a minimum, but unlike previous places of employment I'm not as conservative now.
I see both the NanoPi and the VisionFive boards as references for Infix, to help lower the barrier of entry, ease adoption, and show off the operating system's capabilities. In that sense some boards will have features that it doesn't share with others, even though they share the same base architecture. E.g., with/without: switchcore, wifi, cellular, etc.
It's also a question of the number of users on a board, paying customers vs freebie users. I don't think we should spend too much time on maintaining and testing support for all boards in a common kernel, for instance. I tried that with the EspressoBIN and MacchiatoBIN boards, but the pace at which our development progressed on the aarch64_defconfig it was impossible to keep them working -- same with the CRB board. I've actually planned to break out more boards from the standard aarch64 build to be able to maintain them more easily, because man power is another component we need to consider here.
So, that's where I'm coming from. Love to hear what @wkz has to say on this as well.
There was a problem hiding this comment.
What i mean is if we use the same kernel for the "platform" we could for example build a small test system with R2S (or more likely, something with 2 more ports) and actually gain from it.
And if a (non-maintained) board breaks after an upgrade, so be it, open a bug report. But at least it has the same patch level as all other supported boards and we can draw conclusions about behavior.
There was a problem hiding this comment.
OK, we've had a talk about this AFK now too. Can we agree on merging this for now, and postpone the merge to the aarch64_defconfig in the next PR, @lazzer + @wkz ?
Then I could base my planned refresh of the EspressoBIN support on this and coax it all together in the same build for that PR. I'd like to get on that as soon as possible, even this coming weekend 🤓
This patch greatly improves the security of the Infix factory reset by replacing 'rm' with 'shred'. The shred tool overwrites the contents of files three times. With the -z and -u options the last pass writes zeroes and then uninks the files. On the NanoPi R2S the factory-reset now takes 24 seconds: Aug 11 16:00:34 infix mnt[121]: Resetting to factory defaults. Aug 11 16:00:58 infix mnt[173]: Factory reset complete. A visual aid is also added, setting *all* LEDs to on, that can be found mounted on the device, before starting the file shredders. The LEDs are reset back to off and SYS red blinking as soon as the wipe has completed and iitod has been started. Fixes #158 Signed-off-by: Joachim Wiberg <[email protected]>
Backport pam-lastlog build fix from latest Buildroot master and enable in all defconfigs to fix syslog warning: login[2819]: PAM unable to dlopen(/lib/security/pam_lastlog.so) Fixes #542 Signed-off-by: Joachim Wiberg <[email protected]>
Signed-off-by: Joachim Wiberg <[email protected]>
Allow reset button on the R2S to be used for factory reset at power-on. See board README for details. Signed-off-by: Joachim Wiberg <[email protected]>
When the interface is up and has a 'proto dhcp' address the WAN LED is lit up. When the interface goes down, or loses its DHCP lease, the LED is turned off. Signed-off-by: Joachim Wiberg <[email protected]>
There was a problem hiding this comment.
I vote for merging this for now. I really hope we can get this to a state where it becomes a fully supported Tier 1 board soon though.
Side note: when that happens, I think we should move lots of the excellent docs in this PR, regarding LEDs, factory reset, etc., to the general documentation 👍
3 participants
Description
This PR holds massive updates of the Infix support to the NanoPi R2S, initially added in #271. From the ChangeLog:
rebootcommand "hang" on NanoPi R2S (failure to reboot) by replacing the Rockchip watchdog driver with "softdog"infix-r2s$ver.ext, not same as other aarch64rebootatm.factory-configas an example/sys/class/ledsare turned on while clearing writable partitionslogin, cannot findpam_lastlog.soChecklist
Tick relevant boxes, this PR is-a or has-a: