feat(boards): add AkidaTag hardware revision 2 as a build target

AGENTS.md

@@ -25,27 +25,41 @@ The selectable application is `demo_apps`, with its entry point at
 [src/apps/demo_apps/main.cpp](src/apps/demo_apps/main.cpp). It combines the
 existing demonstrations and shared firmware services.
 
-Build for the AkidaTag board:
+Build for the AkidaTag board, hardware revision 1:
 
 ```sh
 ./scripts/run.sh -d -b --app demo_apps
 ```
 
+Build for AkidaTag hardware revision 2 into a separate directory:
+
+```sh
+BUILD_DIR=build_docker_rev2 ./scripts/run.sh -d -b --rev 2 --app demo_apps
+```
+
 Build for the nRF5340 DK into a separate directory:
 
 ```sh
 BUILD_DIR=build_docker_dk ./scripts/run.sh -d -b --dk --app demo_apps
 ```
 
-The outputs are `build_docker/demo_apps/` and `build_docker_dk/demo_apps/`,
-respectively. Without a `BUILD_DIR` override, both commands use the same output
-directory. Each build starts with a pristine configuration.
-
-Both boards use Zephyr's `nrf5340dk/nrf5340/cpuapp` target. `--dk` selects the DK
-application and MCUboot overlays, `CONFIG_AKIDATAG_BOARD=n` and
-[src/boards/dk.conf](src/boards/dk.conf). Keep board-specific settings with the
-appropriate overlay or configuration fragment; the Zephyr target name alone
-does not distinguish the two boards.
+The outputs are `build_docker/demo_apps/`, `build_docker_rev2/demo_apps/` and
+`build_docker_dk/demo_apps/`, respectively. Without a `BUILD_DIR` override, all
+three commands use the same output directory. Each build starts with a pristine
+configuration.
+
+The AkidaTag board is a Zephyr board definition in
+[src/boards/brainchip/akidatag/](src/boards/brainchip/akidatag/), and its hardware
+revisions are Zephyr board revisions. `run.sh` builds it as
+`akidatag/nrf5340/cpuapp`, or `akidatag@2/nrf5340/cpuapp` with `--rev 2`, and
+passes `src` as the board root; revision 1 is the default in its `board.yml`.
+Settings shared by both revisions live in `akidatag_nrf5340_cpuapp.dts`, and each
+revision's differences in `akidatag_nrf5340_cpuapp_<revision>.overlay`. MCUboot's
+own adjustments follow the same naming in `src/sysbuild/mcuboot/boards/`. Kconfig
+defaults that depend on the revision, such as the INA190 variant, test
+`BOARD_REVISION` in `src/Kconfig`. `--dk` builds Zephyr's `nrf5340dk/nrf5340/cpuapp`
+target with the DK application overlay, `CONFIG_AKIDATAG_BOARD=n` and
+[src/boards/dk.conf](src/boards/dk.conf).
 
 Ordinary builds use the RSA-3072 development key committed at
 `.env/development_key.pem`. It is intentionally public so a fresh clone can
@@ -75,7 +89,8 @@ and make `JLinkExe` available on `PATH`, then flash the container-built output:
 BUILD_DIR=build_docker ./scripts/run.sh -f -jf --app demo_apps
 ```
 
-For the DK build, use `BUILD_DIR=build_docker_dk` and add `--dk`. The script loads
+For a revision 2 build, use `BUILD_DIR=build_docker_rev2`; for the DK build, use
+`BUILD_DIR=build_docker_dk` and add `--dk`. The script loads
 `merged_CPUNET.hex` on the network core first and `merged.hex` on the application
 core second. These files include the bootloader needed for initial programming.
 Do not substitute an application-only image for the initial full flash.
@@ -136,10 +151,10 @@ named `my_demo`, update the following pieces together:
    still apply the old app's configuration.
 4. Add `my_demo` to the app-selection case in `scripts/run.sh`, use `src` as
    `APP_SRC_DIR`, and pass `-DCONFIG_MY_DEMO=y` instead of `CONFIG_DEMO_APPS`.
-   Carry over the board-selection arguments for each supported board. Add the
-   corresponding entry to `get_jlink_jobs` for J-Link flashing and update the
-   help text and available-app error. The build directory is already derived
-   from the app name.
+   Carry over the board target and board-selection arguments for each supported
+   board. Add the corresponding entry to `get_jlink_jobs` for J-Link flashing
+   and update the help text and available-app error. The build directory is
+   already derived from the app name.
 5. If the demo needs different model metadata, add the matching profile to
    `APP_PROFILES` in `src/utils/generate_info.py` and document its configuration
    fields. The existing model profile is `demo_apps`; a new firmware app name

NOTICE

@@ -167,6 +167,30 @@ that a source redistribution retains the list of conditions it asks for:
     NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
     SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
+--------------------------------------------------------------------------------
+Zephyr nRF5340 DK board and MCUboot configuration
+--------------------------------------------------------------------------------
+
+Upstream:   Zephyr RTOS and MCUboot as shipped in nRF Connect SDK v3.1.1,
+            zephyr/boards/nordic/nrf5340dk/ and
+            bootloader/mcuboot/boot/zephyr/prj.conf
+Paths:      src/boards/brainchip/akidatag/
+            src/sysbuild/mcuboot/prj.conf
+Licence:    Apache License, Version 2.0 (SPDX-License-Identifier: Apache-2.0)
+Copyright:  Copyright (c) 2019-2022 Nordic Semiconductor ASA
+            Copyright (c) 2022 Zephyr Project members and individual contributors
+            Copyright (c) 2021 Linaro Limited (pre_dt_board.cmake)
+
+The AkidaTag board definition is adapted from Zephyr's nRF5340 DK board. Its
+Kconfig files, board.cmake, pre_dt_board.cmake and defconfig files, the network
+core devicetree and its pinctrl file follow the DK's, and the application core
+devicetree keeps the DK's chosen nodes, regulator, crystal and partition
+settings. Each of those files carries the upstream copyright and SPDX lines;
+the pin descriptions, the revision overlays and board.yml are BrainChip's.
+src/sysbuild/mcuboot/prj.conf restates MCUboot's own prj.conf, which declares
+no copyright or licence of its own; MCUboot is distributed under the Apache
+License, Version 2.0. The licence text is in LICENSE.
+
 --------------------------------------------------------------------------------
 Keyword-spotting sample input
 --------------------------------------------------------------------------------

README.md

@@ -78,7 +78,7 @@ git clone https://github.com/Brainchip-Inc/AkidaTag.git && cd AkidaTag
 # put SEGGER's J-Link V8.88 .deb in docker/tools/ first (docker/tools/README.md), accepting SEGGER's terms
 ./scripts/build_docker_image.sh --ncs v3.1.1 --python 3.12   # once; downloads the SDK
 
-./scripts/run.sh -d -b --app demo_apps        # build for the AkidaTag board (add --dk for the nRF5340 DK)
+./scripts/run.sh -d -b --app demo_apps        # build for the AkidaTag board (add --rev 2 for hardware revision 2)
 ./scripts/run.sh -d -f --app demo_apps        # flash MCUboot and the application over the debug probe
 ./scripts/run.sh -d -t                        # drive the shell over UART and check the AKD1500 link
 ```

docs/developer-guide.md

@@ -21,7 +21,7 @@ If you only want to run the demos from your phone, read the [user guide](user-gu
 .
 ├── src/                 The firmware. Source directory of the demo_apps application.
 │   ├── apps/demo_apps/  main.cpp, the app's Kconfig fragment and its sample inputs
-│   ├── boards/          Devicetree overlays and board-specific configuration
+│   ├── boards/          The AkidaTag board definition, with one devicetree overlay per hardware revision
 │   ├── core/            SPI to the AKD1500, its flash, BLE services, audio, LEDs, battery, boot manager
 │   ├── deps/            Imported code: the Akida engine, FlatBuffers headers, kissfft (see deps/VENDORING.md)
 │   ├── include/         Headers
@@ -40,9 +40,11 @@ If you only want to run the demos from your phone, read the [user guide](user-gu
 └── CONTRIBUTING.md      Commit and pull request rules, enforced in CI
 ```
 
-The AkidaTag build uses the Zephyr board target `nrf5340dk/nrf5340/cpuapp` with the board's
-devicetree and MCUboot overlays and `CONFIG_AKIDATAG_BOARD=y`. The target name comes from Zephyr;
-the custom overlays define the AkidaTag hardware.
+The AkidaTag board is a Zephyr board definition, `src/boards/brainchip/akidatag/`, and its
+hardware revisions are Zephyr board revisions: `akidatag_nrf5340_cpuapp.dts` holds what both
+revisions share and `akidatag_nrf5340_cpuapp_1.overlay` and `akidatag_nrf5340_cpuapp_2.overlay`
+what each revision changes. Together they list every pin. `scripts/run.sh` builds revision 1
+unless you give it `--rev 2`.
 
 ## 2. Set up the environment
 
@@ -71,10 +73,14 @@ On macOS, Docker Desktop has no USB passthrough, so build inside Docker and flas
 ## 3. Build
 
 ```sh
-./scripts/run.sh -d -b --app demo_apps
+./scripts/run.sh -d -b --app demo_apps                                      # hardware revision 1
+BUILD_DIR=build_docker_rev2 ./scripts/run.sh -d -b --rev 2 --app demo_apps  # hardware revision 2
 ```
 
-A Docker build lands in `build_docker/demo_apps/`; a host build in `build/demo_apps/`.
+A Docker build lands in `build_docker/demo_apps/`; a host build in `build/demo_apps/`. `--rev 2`
+changes the configuration, not the directory, so the two revisions overwrite each other's build
+unless you set `BUILD_DIR`, which is why the revision 2 command above builds into
+`build_docker_rev2/`.
 `./scripts/run.sh -d -i` opens a shell inside the image.
 
 | Output                         | What it is                                                                                                                    |
@@ -97,9 +103,11 @@ Flashing `merged.hex` and `merged_CPUNET.hex` over SWD replaces everything on th
 bootloader included. It does not touch the AKD1500's flash, so a model on the board survives.
 
 ```sh
-./scripts/run.sh -d -f -jf --app demo_apps                       # Linux: J-Link inside Docker
-BUILD_DIR=build_docker ./scripts/run.sh -f -jf --app demo_apps   # macOS: host J-Link
-./scripts/run.sh -d -r                                           # reset the board
+./scripts/run.sh -d -f -jf --app demo_apps                              # Linux: J-Link inside Docker
+BUILD_DIR=build_docker ./scripts/run.sh -f -jf --app demo_apps          # macOS: host J-Link
+BUILD_DIR=build_docker_rev2 ./scripts/run.sh -d -f -jf --app demo_apps  # Linux: the revision 2 build
+BUILD_DIR=build_docker_rev2 ./scripts/run.sh -f -jf --app demo_apps     # macOS: the revision 2 build
+./scripts/run.sh -d -r                                                  # reset the board
 ```
 
 Use the J-Link path, `-jf`, on an AkidaTag board. The board's debug header reports a target

docs/hardware/block-diagram.md

@@ -267,7 +267,7 @@ The revision 2 schematic (SI-NRF-AKD_BRD-002 V11, 2026-08-25), netlist report, b
 materials and board outline; the earlier system block diagram and labelled layout
 drawing (January 2026); the Texas Instruments INA190 datasheet (SBOS863D) and BQ27427
 datasheet (SLUSEB5B); BrainChip AKD1500 documentation for the strap meanings; and the
-firmware board overlay `src/boards/nrf5340_cpuapp_akidatag.overlay`,
+firmware board definition `src/boards/brainchip/akidatag/`,
 `src/core/interface/gpio/gpio.c`, `src/core/interface/akd_spi_flash/akd_spi_flash_handler.cpp`
 and `src/README.md` on `main`.