kernelkit · troglobit · Sep 24, 2026 · Sep 24, 2026 · Sep 24, 2026 · Sep 24, 2026
diff --git a/README.md b/README.md
@@ -143,9 +143,9 @@ compromised service or container can't rewrite the OS underneath it.
 
 <a href="https://bitsign.se">
   <picture>
-    <source media="(prefers-color-scheme: dark)" srcset="https://bitsign.se/assets/badges/bitsign-badge-dark-mode.png">
-    <source media="(prefers-color-scheme: light)" srcset="https://bitsign.se/assets/badges/bitsign-badge-light-mode.png">
-    <img alt="bitSign - Code Signing" src="https://bitsign.se/assets/badges/bitsign-badge-light-mode.png" align="right" width=150 padding=10>
+    <source media="(prefers-color-scheme: dark)" srcset="doc/img/bitsign-badge-dark-mode.png">
+    <source media="(prefers-color-scheme: light)" srcset="doc/img/bitsign-badge-light-mode.png">
+    <img alt="bitSign - Code Signing" src="doc/img/bitsign-badge-light-mode.png" align="right" width=150 padding=10>
   </picture>
 </a>
 

diff --git a/board/aarch64/Config.in b/board/aarch64/Config.in
@@ -11,6 +11,7 @@ source "$BR2_EXTERNAL_INFIX_PATH/board/aarch64/marvell-cn9130-crb/Config.in"
 source "$BR2_EXTERNAL_INFIX_PATH/board/aarch64/marvell-espressobin/Config.in"
 source "$BR2_EXTERNAL_INFIX_PATH/board/aarch64/microchip-ev23x71a/Config.in"
 source "$BR2_EXTERNAL_INFIX_PATH/board/aarch64/microchip-sparx5-pcb135/Config.in"
+source "$BR2_EXTERNAL_INFIX_PATH/board/aarch64/novarq-tactical-1000/Config.in"
 source "$BR2_EXTERNAL_INFIX_PATH/board/aarch64/raspberrypi-rpi64/Config.in"
 source "$BR2_EXTERNAL_INFIX_PATH/board/aarch64/styx-dcp-sc-28p/Config.in"
 

diff --git a/board/aarch64/microchip-ev23x71a/README.md b/board/aarch64/microchip-ev23x71a/README.md
@@ -52,9 +52,8 @@ up DDR and loads BL31 and U-Boot as BL33.
 > [!NOTE]
 > The vendor U-Boot has neither `blkmap`, SquashFS support nor `sysboot`, so
 > it cannot map a signed `rootfs.itb` and read `/boot/syslinux/*.conf` out of
-> it, which is how Infix boots.  It is possible to [Netboot](#netboot) from
-> it, though we recommend going for the adapted [Bootloader](#bootloader) to
-> be able to boot properly from eMMC.
+> it, which is how Infix boots.  [Netboot](#netboot) works from it, but
+> booting properly from eMMC needs the adapted [Bootloader](#bootloader).
 
 ## Boot Mode Strapping
 
@@ -119,12 +118,6 @@ build needs mbed TLS to parse X.509 in BL1 and BL2.  That comes from the
 `mbedtls-atf` package, pinned to the 2.28 series ATF 2.8 builds against, since
 Buildroot's `mbedtls` tracks 3.x.
 
-This defconfig builds the `mchp_lan969x_defconfig` plus local fragments, which
-add `blkmap`, SquashFS, `sysboot`, and the signed image validation the Infix
-boot flow needs, and pin the control device tree to this board.  The board
-environment, `lan969x-env.dtsi`, sets the load addresses and names the kernel
-device tree to pick out of the SquashFS.
-
 Two build variables are not obvious.  `KEY_ALG=ecdsa`, because the LAN969x
 crypto driver is built around the Silex ECDSA engine and will not compile
 against an mbed TLS configured for RSA only.  And `GENERATE_COT=1`, because
@@ -148,8 +141,8 @@ see [`ERRATA.md`][5] in the Microchip Trusted Firmware tree.
 
 ## Installing
 
-The bootloader and the Linux image are separate builds, combined into one eMMC
-image using the `mkimage.sh` script:
+The bootloader and the Linux image are separate builds, combined into one
+eMMC image with `mkimage.sh`:
 
 ```bash
 make laguna_boot_defconfig O=x-boot-laguna && make O=x-boot-laguna
@@ -210,8 +203,8 @@ environment, so it is only there when booting the NOR image.
 
 ## Netboot
 
-Once the Infix U-Boot is in place, netbooting needs no script at all: hand out
-a `rootfs.itb` as the DHCP boot file and `ixprepdhcp` fetches, validates, and
+With the Infix U-Boot in place netbooting needs no script: hand out a
+`rootfs.itb` as the DHCP boot file and `ixprepdhcp` fetches, validates, and
 boots it, see the [netboot HowTo][1].
 
 The recipe below is for boards still running the vendor U-Boot, before our FIP
@@ -284,10 +277,18 @@ build, flash, and boot cycle.
 ## Switch Core
 
 The board reports part `0x969b` revision 0, a LAN9696RED (lan969x-60-RED).
-The driver reads `GCB_CHIP_ID` at probe but never prints it, so read it out:
+The driver reads `GCB_CHIP_ID` at probe but never prints it, so read it out.
+
+From Linux:
 
 ```
-devmem 0xe2010000 32
+$ devmem 0xe2010000 32
+```
+
+or from U-Boot:
+
+```
+m => md.l 0xe2010000 1
 ```
 
 Bits 27:12 hold the part, 31:28 the revision.  Which part it is decides what
@@ -320,32 +321,32 @@ without either.
 | `0x0556` | SparX-5-160i | Industrial  | yes           |
 | `0x0558` | SparX-5-200i | Industrial  | yes           |
 
+`0x9697` is a LAN9696TSN, the [Novarq Tactical
+1000](../novarq-tactical-1000/README.md).
+
 The register is the same on SparX-5, only the address differs, since
 `TARGET_GCB` sits elsewhere in that family's register map:
 
 ```
-devmem 0x611010000 32
+$ devmem 0x611010000 32
 ```
 
 The RED in the part number is hardware HSR/PRP RedBox support.
 
 ## Interfaces
 
 The sparx5 driver leaves naming to the kernel, which hands out `eth0` and up
-in probe order, this makes it off-by-one from the numbering in the official
-documentation.  The product specific `90-ev23x71a-rename-ifaces.rules` renames
-them to the usual interface names:
+in probe order, one off from the numbering in the official documentation.  The
+product specific `90-ev23x71a-rename-ifaces.rules` renames them:
 
 | **Device tree**    | **Interface**  | **Port**            |
 |--------------------|----------------|---------------------|
 | `port@0..port@23`  | `e1` .. `e24`  | 1G copper, QSGMII   |
 | `port@24..port@27` | `e25` .. `e28` | 10G SFP+            |
 | `port@29`          | `e29`          | 1G RGMII management |
 
-Attaching 29 PHYs takes the driver a good half second each, far longer than
-the ten seconds `hw-wait` waits for slow devices by default.  The product
-therefore raises it in `/etc/default/hw-wait`, so that services which expect
-the ports to exist do not start ahead of them.
+Attaching 29 PHYs takes about half a second each, far longer than `hw-wait`'s
+ten second default, so the product raises it in `/etc/default/hw-wait`.
 
 ## LEDs
 
@@ -385,7 +386,7 @@ state there:
 Reading `is2_0` after a `tc filter add` shows what the classifier actually
 programmed, which is the quickest way to separate an unsupported match from a
 broken one.  The per port files show which key sets each lookup is configured
-for, which is what decides whether a rule can match on a given port at all.
+for, which decides whether a rule can match on that port at all.
 
 Every port netdev links to its device tree node, so they can be mapped back to
 switch ports whatever order they probed in:

diff --git a/board/aarch64/microchip-ev23x71a/uboot/lan969x-env.dtsi b/board/aarch64/microchip-ev23x71a/uboot/lan969x-env.dtsi
diff --git a/...64/microchip-ev23x71a/uboot/extras.config → ...h64/microchip-lan969x/uboot/extras.config b/...64/microchip-ev23x71a/uboot/extras.config → ...h64/microchip-lan969x/uboot/extras.config
@@ -1,8 +1,10 @@
-# One board, one control device tree.  The vendor defconfig carries a
-# device tree for each LAN969x board and selects between them with
-# MULTI_DTB_FIT, which also makes fit_conf_get_node() match FIT
-# configurations by compatible string instead of honoring the default
-# property, see the board README.
+# One control device tree for every Laguna board.  U-Boot drives the
+# same peripherals on each, and the Linux device tree is chosen at boot,
+# see lan969x-env.dtsi.  The vendor defconfig instead carries a control
+# device tree per board and selects between them with MULTI_DTB_FIT,
+# which also makes fit_conf_get_node() match FIT configurations by
+# compatible string instead of honoring the default property, see the
+# EV23X71A README.
 CONFIG_DEFAULT_DEVICE_TREE="lan969x_ev23x71a"
 CONFIG_OF_LIST="lan969x_ev23x71a"
 # CONFIG_MULTI_DTB_FIT is not set

diff --git a/board/aarch64/microchip-lan969x/uboot/lan969x-env.dtsi b/board/aarch64/microchip-lan969x/uboot/lan969x-env.dtsi
@@ -0,0 +1,50 @@
+/*
+ * Laguna board environment, applied on top of the common Infix one and
+ * shared by every LAN969x board.  U-Boot drives the same console, eMMC,
+ * I2C, and GPIO on all of them, so one control device tree serves; only
+ * the Linux device tree differs, and that is picked at boot, see ixboard.
+ *
+ * DRAM starts at 0x60000000 on all of them too, and the addresses mirror
+ * the layout used on other Infix boards: the kernel is staged 64 MiB in,
+ * clear of where booti relocates it to at the start of DRAM.
+ */
+/ {
+	config {
+		/*
+		 * Name the partition holding the environment, rather than
+		 * inheriting the offset from lan969x.dtsi, which points
+		 * into the middle of the Infix layout.
+		 */
+		u-boot,mmc-env-partition = "Env";
+	};
+};
+
+&env {
+	bootcmd = "run ixboard; run ixboot";
+	boot_targets = "mmc0";
+
+	/*
+	 * Which board this is.  The EV23X71A is the default, so a Laguna
+	 * board this knows nothing about boots as one, which is what it
+	 * did before.  The Tactical 1000 is told apart by its part number,
+	 * bits 27:12 of GCB_CHIP_ID: 0x9697 against the eval board's
+	 * 0x969b.  That is the SoC variant rather than the board, and the
+	 * best there is until Novarq give us a real board ID.
+	 */
+	board   = "microchip,ev23x71a";
+	fdtfile = "microchip/lan9696-ev23x71a.dtb";
+	ixboard = "if setexpr.l cid *0xe2010000 && setexpr cid ${cid} / 0x1000 && setexpr cid ${cid} % 0x10000 && test ${cid} = 9697; then setenv board novarq,tactical-1000; setenv fdtfile microchip/lan9696-tactical-1000.dtb; fi";
+
+	loadaddr          = "0x63000000";
+	fdt_addr_r        = "0x63f00000";
+	kernel_addr_r     = "0x64000000";
+	fdtoverlay_addr_r = "0x67f00000";
+	scriptaddr        = "0x68000000";
+	ramdisk_addr_r    = "0x6a000000";
+
+	/* Development boards and test rigs, keep developer mode enabled. */
+	ixbtn-devmode = "setenv dev_mode yes; echo Enabled";
+
+	/* No button command built, whether or not the board has one. */
+	ixbtn-factory = "echo Unavailable";
+};
diff --git a/board/aarch64/novarq-tactical-1000/Config.in b/board/aarch64/novarq-tactical-1000/Config.in
@@ -0,0 +1,7 @@
+config BR2_PACKAGE_NOVARQ_TACTICAL_1000
+	bool "Novarq Tactical 1000 (Laguna)"
+	depends on BR2_aarch64
+	help
+	  Support for the Novarq Tactical 1000, based on the LAN969x
+	  (Laguna) family of TSN capable switches.  24 GbE copper ports,
+	  4 SFP+ ports, and a separate management port.
diff --git a/board/aarch64/novarq-tactical-1000/LICENSE b/board/aarch64/novarq-tactical-1000/LICENSE
@@ -0,0 +1,13 @@
+Copyright (c) 2026 The KernelKit Authors
+
+Permission to use, copy, modify, and/or distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.