Only port 2 has an SGMII compatible SERDES. When referencing the
SERDES (comphy), the second argument must contain the port number in
order for the comphy driver to pick the correct configuration.
Since the Nanopi R2S does not have a VPD, we use this mechanism to set
the default admin password. Without one, Infix will refuse to generate
the factory- and failure-config files, and thus refuse to start.
On custom boards in production we have VPD in ONIE format that contains
a per-device unique SHA256 hashed admin user password.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Support for this is based on the upstream Buildroot R2S defconfig and
the myLinux extensions and stripped-down kernel defconfig. For more
information about the Nanopi R2S, see the FriendlyELC wiki at:
https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R2S
Please note, due to the lack of a VPD on the board, and some very poor
devicetree skills by yours truly, Infix currently refuse to boot on this
board. An in-devicetree factory-password-hash node has to be added, and
will be done soon.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Empirical studies shows that the surge protection on the alder board
is not compatible with Energy Efficient Ethernet.
Root cause has not yet been determined.
On the P2's the only reasonable way (in terms of hardware patching
effort) of driving the LEDs is to have the green LEDs at the top and
the yellow ones at the bottom.
Turns out that the gpio-charger doesn't have polled fallback if the
GPIO pin can't function as an interrupt controller.
Fortunately, we have access to the IRQ pin, so we can just use that
for now and leave the driver as-is.
As we may need to load firmware to the PHYs, we can't load those
modules until we have access to the rootfs. In order for that to work,
the MDIO driver must not be built-in, as that will cause the kernel to
bind devices with missing (built-in) drivers to bind to the genphy
driver.
Therefore, build everything as modules and let udev load it during
boot.
For some reason, the controller disables the bus power sometime after
it was enabled by the driver. The reference manual says, in Table 645,
about the SD_BUS_POWER bit:
> ... It will be cleared if one of the following occurs: the
> sd_bus_vlt and the voltage support in the Capabilities Register 1 do
> not match or if a card removal state was detected.
Further investigation will be needed to find the (electrical?)
root-cause of this issue.
This is the layout expected by the "distro boot" effort in U-Boot.
As far as I understand, the contract is:
- U-Boot built for `fooboard` by `vendor`, will set the `fdtfile`
variable to `vendor/fooboard.dtb` - or more precisely: matching
whatever path the dtb is built at in the kernel tree.
- A distro (e.g. Infix) then just needs to specify the `fdtdir` in its
syslinux config (/boot in our case), and U-Boot will be able to find
the correct dtb.
This let's us report the installed software versions, before any
updates have been made. Since the info should _not_ be erased in a
factory reset (since the installed software versions will not change),
move the status file to aux, which is the proper place for this class
of information.
/dev/ram is accepted by the kernel during boot, but there's no actual
file with this name in /dev, so RAUC will get confused about which
slot is actually one we booted from.
Instead of having to rely on the kernel command line, we convert all the
kernel functionality in question into modules and rely on the auto-load
feature in the kernel and modprobe to add options at load time.
The fb_tunnels setting is a net core setting, for that we use sysctl.
This commit also syncs the kernel config between our two main archs,
disabling DRM and SOUND for the Amd64 build as a spin-off.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Add support for firmware updates via RAUC on aarch64. The created RAUC
bundle (images/infix-$BR2_ARCH.pkg) is signed with the same key used
to sign the raw FIT image.
Store FIT headers separately on aux, and place the raw SquashFS images
on primary/secondary. This removes the need to muck about with the
device mapper to setup the rootfs, and it allows us to boot using
syslinux files.
mkimage will generate an FIT image containing a signature of the
rootfs, where the data is kept out of the DTB data structure, i.e.:
.---------.
| DTB |
:---------:
| Padding |
:---------:
| |
| |
| rootfs |
| |
| |
'---------'
This is the on-disk format of Infix. At boot, we extract kernel and
device trees from the rootfs, and then use Linux's device mapper to
create a virtual block device that exposes the rootfs (squash).
In the new model, we have three sources of storage:
- /mnt/var: Mountpoint for a disk with the label "var"
- /mnt/cfg: Mountpoint for a disk with the label "cfg"
- /mnt/tmp: Mountpoint for a ramdisk
These sources are used for the following overlays:
- **/cfg, /home, /root**: /mnt/cfg if available, else /mnt/tmp
- **/etc**: /mnt/cfg if available and the boot/etc finit condition is
set, else /mnt/tmp
- **/var**: /mnt/var if available, else /mnt/tmp
- **/var/lib**: /mnt/var if available, else /mnt/cfg if available,
else /mnt/tmp
See board/common/rootfs/lib/infix/mnt for more information.
This change checks¹ if the system does not have a br0 interface, creates
a default one consisting of all switch ports in VLAN 1 of br0.
On top of br0 a vlan1 management interface is created with DHCP address.
For emulation and test purposes, a way to supply tap interfaces from
Qemu, and pass off as if they were regular switch ports, is added.
____
¹ obviously a better way to detect a factory-reset device is needed,
not all systems running infix will need or want a br0 interface.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
