Prune zephyr manifest

[Mikefly123]

Improving CI Build Times

Description

This pull request adds a custom west.yml Zephyr manifest and also refactors the build CI to significantly reduce the GitHub Actions Runtime!

By my best estimate we are going to put that build time in about half!

How Has This Been Tested?

• Ran on GitHub Actions

Screenshots / Recordings (if applicable)

Checklist

• Written detailed sdd with requirements, channels, ports, commands, telemetry defined and correctly formatted and spelled
• Have written relevant integration tests and have documented them in the sdd
• Have done a code review with
• Have tested this PR on every supported board with correct board definitions

Further Notes / Considerations

[Copilot]

Pull Request Overview

This PR introduces a custom minimal West manifest for Zephyr and optimizes the CI/CD build process to significantly reduce build times by approximately 50%. The changes focus on including only the essential modules needed for RP2040/RP2350 development rather than the entire Zephyr ecosystem.

Key changes:

• Creates a minimal West manifest (west.yml) with only RP2040/RP2350-specific modules
• Updates the Makefile to use ARM-only toolchain installation for ~92% SDK size reduction
• Refactors CI workflow with intelligent caching and dependency management
• Adds comprehensive documentation for the new setup process

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
west.yml	New minimal manifest targeting only RP2040/RP2350 modules, reducing workspace size by ~80%
lib/zephyr-workspace/.west/config	Removes old West configuration to use new manifest
docs/additional-resources/west-manifest-setup.md	Comprehensive documentation for minimal setup, migration, and troubleshooting
Makefile	Updates Zephyr setup targets to use minimal modules and ARM-only toolchain
CMakeLists.txt	Adds BOARD_ROOT configuration for custom board support
.github/workflows/ci.yaml	Major CI refactor with intelligent caching and optimized dependency management

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The hal_st module is included but the comment in the documentation indicates it's for LIS2MDL and LSM6DSO sensors. Consider adding a comment explaining why this STM HAL is needed for RP2040/RP2350 builds or remove it if it's not actually required for the minimal setup.

Suggested change

	- name: hal_st
	revision: 9f81b4427e955885398805b7bca0da3a8cd9109c
	path: lib/zephyr-workspace/modules/hal/st
	groups:
	- hal

[Copilot]

This appears to be a test comment that should be removed as it doesn't provide any meaningful information about the Zephyr setup.

Suggested change

# Hello World!

[Copilot]

The awk command for summing directory sizes is incorrect. The du -sh output includes units (like 'M', 'G') that can't be directly summed. This will likely produce incorrect output or fail silently.

Suggested change

	echo "Zephyr modules size: $(du -sh lib/zephyr-workspace/modules lib/zephyr-workspace/bootloader 2>/dev/null | awk '{sum+=$1} END {print sum"M"}' || echo 'N/A')"
	echo "Zephyr modules size: $(du -sb lib/zephyr-workspace/modules lib/zephyr-workspace/bootloader 2>/dev/null | awk '{sum+=$1} END {print sum}' | numfmt --to=iec --suffix=B 2>/dev/null || echo 'N/A')"

[Copilot]

The -o flags attempt to skip make targets, but this syntax is for skipping files, not targets. Consider using a different approach like conditional logic in the Makefile or separate build commands that don't depend on these targets.

Suggested change

	# Skip both zephyr-setup and submodules since we cached them separately
	make build -o zephyr-setup -o submodules
	# Build, setup and submodules have already been handled (cached or run above)
	make build

[nateinaction]

I think the zephyr module downloads are not being cached anymore because, at least locally, are being downloaded to a parent directory of the repo. They are indeed faster but and the builds are functional so I think this is an OK step forward but we should pend more time here to understand how to store the modules in the repo instead.