Joachim WibergandTobias Waldekranz 01a4eedcad board/aarch64/r2s: map board LEDs to Infix system LEDs
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 <troglobit@gmail.com>
2024-08-16 16:47:28 +02:00
2024-08-08 13:35:27 +02:00
2024-06-28 12:54:27 +02:00
2022-12-05 21:09:05 +01:00

License Badge GitHub Status Coverity Status Discord

Infix - Linux <3 NETCONF

Infix is a free, Linux based, immutable Network Operating System (NOS) built on Buildroot, and sysrepo. A powerful mix that ease porting to different platforms, simplify long-term maintenance, and provide made-easy management using NETCONF1 or the built-in command line interface (CLI) from a console or SSH login.

Click the ▶ Example CLI Session foldout below for an example, or head on over to the Infix Documentation for more information on how to set up the system.

Although primarily focused on switches and routers, the core values may be appealing for other use-cases as well:

  • Runs from a squashfs image on a read-only partition
  • Single configuration file on a separate partition
  • Built around YANG with standard IETF models
  • Linux switchdev provides open switch APIs
  • Atomic upgrades to secondary partition
  • Highly security focused

An immutable2 operating system enhances security and inherently makes it maintenance-free. Configuration and data, e.g, containers, is stored on separate partitions to ensure complete separation from system files and allow for seamless backup, restore, and provisioning.

In itself Infix is perfectly suited for dedicated networking tasks and native support for Docker containers provides a versatile platform that can easily be adapted to any customer need. Be it legacy applications, network protocols, process monitoring, or edge data analysis, it can run close to end equipment. Either directly connected on dedicated Ethernet ports or indirectly using virtual network cables to exist on the same LAN as other connected equipment.

The simple design of Infix provides complete control over both system and data, minimal cognitive burden, and makes it incredibly easy to get started.

Example CLI Session

The CLI configure context is automatically generated from the loaded YANG models and their corresponding sysrepo plugins. The following is brief example of how to set the IP address of an interface:

admin@infix-12-34-56:/> configure
admin@infix-12-34-56:/config/> edit interface eth0
admin@infix-12-34-56:/config/interface/eth0/> set ipv4 <TAB>
      address     autoconf bind-ni-name      enabled
	  forwarding  mtu      neighbor
admin@infix-12-34-56:/config/interface/eth0/> set ipv4 address 192.168.2.200 prefix-length 24
admin@infix-12-34-56:/config/interface/eth0/> show
type ethernet;
ipv4 {
  address 192.168.2.200 {
    prefix-length 24;
  }
}
ipv6
admin@infix-12-34-56:/config/interface/eth0/> diff
interfaces {
  interface eth0 {
+    ipv4 {
+      address 192.168.2.200 {
+        prefix-length 24;
+      }
+    }
  }
}
admin@infix-12-34-56:/config/interface/eth0/> leave
admin@infix-12-34-56:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA
eth0            ethernet   UP          52:54:00:12:34:56
                ipv4                   192.168.2.200/24 (static)
                ipv6                   fe80::5054:ff:fe12:3456/64 (link-layer)
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
admin@infix-12-34-56:/> copy running-config startup-config

Click here for more details.

Infix can run on many different types of architectures and boards, much thanks to Linux and Buildroot. Currently the focus is on 64-bit ARM devices, optionally with switching fabric supported by Linux switchdev. The following boards are fully supported:

  • Marvell CN9130 CRB
  • Marvell EspressoBIN
  • Microchip SparX-5i PCB135 (eMMC)
  • StarFive VisionFive2
  • NanoPi R2S

An x86_64 build is also available, primarily intended for development and testing, but can also be used for evaluation and demo purposes. For more information, see: Infix in Virtual Environments.

See the GitHub Releases page for our pre-built images. The Latest Build has bleeding edge images, if possible we recommend using a versioned release.

For customer specific builds of Infix, see your product repository.


  1. NETCONF or RESTCONF, https://datatracker.ietf.org/doc/html/rfc8040 ↩︎

  2. An immutable operating system is one with read-only file systems, atomic updates, rollbacks, declarative configuration, and workload isolation. All to improve reliability, scalability, and security. For more information, see https://ceur-ws.org/Vol-3386/paper9.pdf and https://www.zdnet.com/article/what-is-immutable-linux-heres-why-youd-run-an-immutable-linux-distro/. ↩︎

Languages
Python 36.9%
C 16.3%
Go 16.1%
HTML 13.5%
Shell 8.2%
Other 8.9%