Add native Linux/Ardulinux repeater target - #2025
Open
l5yth wants to merge 16 commits into
Open
Conversation
Author
|
The benefit of Portduino is it "just works" (tm) with very little overhead on our end. If we prefer to not use an external framework, we can also implement a minimal Arduino abstraction layer ourselves. I gave it a go (unreviewed yet) and it only adds ~600-800 lines of code to the Linux variant. Please let me know if you prefer it this way over the rather minimalist Portduino variant. |
I like it more. Portduino did not allow me to run 2 concurrent meshcore services at once (with separate config and workdir). |
Member
|
I haven't read through all the comments and discussions on this, but my personal preference would be to avoid depending on a Meshtastic owned project. Portduino does look like a neat project, but I tend to avoid GPL licensed code, and we've had issues with using some of their GPL licensed code in MIT related projects in the past. Plus, it would be good to not have to rely on an external project getting updated if we can do it in house with a small wrapper/helper class to shim out the Arduino methods as you suggested. |
Author
|
Thanks, I appreciate the early feedback. @ggodlewski are you still using your Pi Zero 2W? Mind giving this a test? It is upgraded to 1.14.0 now and I added your config to a ini file named @liamcottle Thanks for the comment. I spent some more time replacing the Portduino framework but it turns out it's not as straight-forward as I hoped it would be. As a middle ground, what do you think about hosting our own minimalist 'portduino' framework in the meshcore-dev organization (meshduino?)? Would give us a bit more control and we can iterate faster without needing to add too much code to the firmware itself. |
robekl
reviewed
Mar 17, 2026
l5yth
changed the title
|
I would be happy to help you test any of this I have many pi/nebra setups i could use. @l5yth |
Author
|
@liamcottle this is ready for review. I removed platform native, framework portduino, and all monkey-patched meshtastic modules. Instead, I created a clean-slate platform for linux support of arduino API with only upstream dependencies (no copy-paste, no drive-by-patching). Benefit is, that this allowed me to make @Littleaton please do. I just finished the work on this. working branch is |
very cool id be happy to contrib all the diff radio yaml/config files that are used, do you have this type of thing setup? |
|
Also are you on discord so i can discuss/talk faster? :P @l5yth |
Author
|
I don't have Discord, sorry. Feel free to suggest new configs directly in my downstream repo, wdyt? |
|
ok can do. |
|
I was able to compile this on Fedora 43 using the following steps. This provides an Click to show build logThe diff --git a/variants/linux/platformio.ini b/variants/linux/platformio.ini
index 8f42ce46..7dc65821 100644
--- a/variants/linux/platformio.ini
+++ b/variants/linux/platformio.ini
@@ -1,8 +1,3 @@
-[env:linux]
-extends = linux_base
-build_flags = ${linux_base.build_flags}
- !pkg-config --cflags --libs libbsd-overlay --silence-errors || :
-
[env:linux_repeater]
extends = linux_base
build_flags = |
Author
|
Thanks for the review. ✌️
This is scaffholding for the companion code. See l5yth#16 I didn't merge the companion work yet because I want to get general feedback on the repeater target first. |
|
I can also confirm the same findings as @rgrizzell and was able to run linux native on a linux system. I used Dietpi and was able to use a zebra hat, and a few other pi hat options and can confirm worked as a meshcore repeater. |
|
@l5yth I was doing a cross-compile for 32-bit ARM ( --- a/Adafruit_SPIDevice.h
+++ b/Adafruit_SPIDevice.h
@@ -80,7 +80,7 @@
#elif (defined(__arm__) || defined(ARDUINO_FEATHER52)) && \
!defined(ARDUINO_ARCH_RP2040) && !defined(ARDUINO_SILABS) && \
!defined(ARDUINO_UNOR4_MINIMA) && !defined(ARDUINO_UNOR4_WIFI) && \
- !defined(PORTDUINO)
+ !defined(PORTDUINO) && !defined(ARDULINUX_PLATFORM)
typedef volatile uint32_t BusIO_PortReg;
typedef uint32_t BusIO_PortMask;
#if !defined(__ASR6501__) && !defined(__ASR6502__) |
rgrizzell
reviewed
Aug 16, 2026
Member
|
@l5yth This looks like it will be a good addition, I can see there's been a lot of work put into it already. Is there an intention to resolve the merge conflicts? |
|
I was able to rebase this branch on the latest commits in https://github.com/rgrizzell/MeshCore/tree/linux-rebase It builds cleanly with these two additional changes. diff --git a/platformio.ini b/platformio.ini
index 2df022d8..bbccfaa5 100644
--- a/platformio.ini
+++ b/platformio.ini
@@ -147,6 +147,7 @@ build_src_filter =
-<helpers/nrf52/*.cpp>
-<helpers/stm32/*.cpp>
-<helpers/bridges/ESPNowBridge.cpp>
+ -<helpers/ethernet/>
-<helpers/*/*Display.cpp>
lib_deps =
${env.lib_deps}
diff --git a/src/helpers/radiolib/LinuxSX1262Wrapper.h b/src/helpers/radiolib/LinuxSX1262Wrapper.h
index 17e168c7..58102d49 100644
--- a/src/helpers/radiolib/LinuxSX1262Wrapper.h
+++ b/src/helpers/radiolib/LinuxSX1262Wrapper.h
@@ -30,8 +30,8 @@ public:
}
uint8_t getSpreadingFactor() const override { return ((LinuxSX1262 *)_radio)->spreadingFactor; }
- void setRxBoostedGainMode(bool en) override {
- ((LinuxSX1262 *)_radio)->setRxBoostedGainMode(en);
+ bool setRxBoostedGainMode(bool en) override {
+ return ((LinuxSX1262 *)_radio)->setRxBoostedGainMode(en);
}
bool getRxBoostedGainMode() const override {
return ((LinuxSX1262 *)_radio)->getRxBoostedGainMode(); |
l5yth
force-pushed
the
linux
branch
2 times, most recently
from
August 31, 2026 11:15
1ac5e7d to
036c777
Compare
Author
|
@oltaco I'll be maintaining and rebasing this on a regular basis. The August summer break this year delayed my response though. I'd be happy to see this included, so I can rebase my other native linux work on upstream in future. @rgrizzell thank you for your contributions and reviews. the upstream PR at Please check again. |
|
@l5yth The latest version works great, thank you! 🎉 The only missing feature for the Linux variant is a way to send commands using
I'll reach out to the Adafruit Devs and ask for a review. 🙏🏼 |
* variants: add scaffolding for linux native * address review comments * address review comments
* variants: allow linux repeater to be configured at runtime * address review comments * address review comments * address review comments
* replace portduino with ardulinux * replace portduino with ardulinux * replace portduino with ardulinux * Remove flags now owned by the ardulinux platform framework ARDULINUX_LINUX_HARDWARE, -lgpiod, and -li2c are detected and injected by builder/frameworks/arduino.py via pkg-config. Hardcoding them here caused linker failures on machines without libgpiod even though the framework would have gracefully omitted them. Also switch variants/ardulinux to the git+ platform URL (dropping the platform-native + platform_packages indirection), update the linux variant board name, and add arduino to the frameworks list in linux.json. * address review comments * Remove stale portduino branding note The startup string was already fixed in l5yth/ardulinux — main.cpp says "An application written with ardulinux". Remove the pending-fix note and update the description to match the current behaviour. * replace portduino with ardulinux * Wire up ardulinux platform and fix SPI/VFS/printf for Linux target variants/ardulinux/platformio.ini: revert local symlink:// back to git+ URL — the symlink only works in a co-located checkout and would break CI. variants/linux/LinuxBoard.cpp: - Add empty ardulinuxSetup() to satisfy the weak symbol; without it the default prints a noisy "No ardulinuxSetup() found" message on startup. - Replace Serial.printf with printf — Serial.printf is not available until after Serial.begin(); using stdio printf is safe at this init-time call site. - Pass 2MHz frequency to SPI.begin() to match the expected SPI clock. variants/linux/target.cpp: fix spiTransfer — ArduLinux's SPI only has a 2-arg transfer(buf, len) that operates in-place; copy out→in first then call the 2-arg form. examples/simple_repeater/main.cpp: fix arduLinuxVFS → ardulinuxVFS (case was wrong; symbol is defined as ardulinuxVFS in ArduLinuxFS.cpp). * set app info to meshcored * fix linux sx1262 wrapper * address review: fix GPIO hardware guard, document spiTransfer, use printf * docs: fix linux variant README (binary name, deps, SPI setup, config keys; use install(1))
#8) * variants/linux: on-hardware smoke-test fixes (rx_boost, dio2, --fsdir, docs) * address review comments
* proofread README * proofread README
* variants/linux: use linux_base for platformio * variants/linux: use linux_base for platformio
* pin ardulinux to wire-fix branch, document pkg-config * pin ardulinux 0.2.1
…#14) * variants/linux: fail loud when libgpiod is missing or pin claim fails * variants/linux: exit when configured GPIO pins fail to bind
* variants/linux: make lora_gpiochip configurable, refresh docs * ci: variants/linux: add lora_gpiochip hint to base meshcored.ini too * bump ardulinux to 0.2.2
`mesh::MainBoard::sleep()` is a no-op by default and `LinuxBoard` never overrode it, so `board.sleep(0)`/`sleep(30)` returned immediately and the repeater loop spun a core at 100%. Only `NRF52Board` and `ESP32Board` implement it. Implement it with `sleep()`/`usleep()`, and add a `delay(1)` in the main loop's non-powersaving branch so platforms without power management do not spin either. Reported and fixed by brianhealey, measured at 99% -> 0-9% CPU on a Pi Compute Module 5 with an SX1262. Cherry-picked from #21, which could not be merged. (cherry picked from commit 11d6ddf) Co-authored-by: brianhealey <brian.healey@gmail.com>
The linux repeater's CLI reads Serial, but on ardulinux Serial is a
stdout-only stub, so the CLI was unreachable — the node could only be
configured over the mesh, with no way to fix a bad radio preset locally
without a second node.
Add a console on a pseudo-terminal (PTY), in MeshCore application code
(not the ardulinux platform layer, so it survives a platform swap) with
logs and the CLI on separate streams. A PTY rather than a socket so
meshcore-cli's repeater mode can attach directly:
meshcore-cli -r -s /run/meshcored/console
(meshcore-cli -r drives a raw-text serial CLI via pyserial, which needs
a tty.)
- src/helpers/PtyConsole.{h,cpp}: pure-POSIX PTY engine (no Arduino
dependency, so it is host-unit-testable). posix_openpt + a stable
symlink to /dev/pts/N; raw termios; maps '\n'->'\r' (1:1) so tools that
send newline work with the CR-terminated CLI. The pts device is chmod
0600 -- the unauthenticated local CLI's access gate. The master
persists across client attach/detach, so there is no accept/reap and a
write to a closed peer returns EIO (never SIGPIPE).
- src/helpers/LinuxConsole.h: thin Arduino Stream adapter; write()
mirrors to stdout (so commands/replies reach journald) and the PTY.
- variants/linux: LinuxConfig.console_path INI key (default: a per-user
path); systemd unit + README document /run/meshcored/console and
meshcore-cli. User docs avoid the PTY/serial internals.
- examples/simple_repeater: route the CLI loop to the console stream;
logs (MESH_DEBUG) and the boot banner stay on Serial. MCU targets keep
console == &Serial, so their behavior is unchanged.
- platformio.ini [env:native]: define MESHCORE_HOST_TEST and add
PtyConsole.cpp to build_src_filter. PtyConsole is compiled out without
the macro and the suite does not link without the source, so both are
required for CI to build test_console at all.
- test/test_console: 18 googletest cases for the engine. Client I/O,
newline mapping, peek, reconnect, write-after-close and the 0600
char-device perms; begin() idempotency; default link resolution via
XDG_RUNTIME_DIR and the /tmp/meshcore-<uid> fallback; path() falling
back to the pts device when the symlink cannot be published;
available() accounting for a peeked byte alongside the queue; end()
idempotency and post-close inertness; destructor cleanup. All three
begin() failure paths are exercised: posix_openpt via RLIMIT_NOFILE,
and grantpt/ptsname_r (unreachable once posix_openpt has succeeded)
via strong definitions that forward to libc unless a test arms them.
Refs #25
Author
|
@oltaco @liamcottle Could we get a review or an indication where we should go from here? We already have people that use the companion target (downstream) that we implemented on top of this work but I would prefer if we could look at the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a continuation of #1137 (and #395) to fix #619. The goal is to keep this diff clean and rebased on upstream so it can eventually be merged into the MeshCore firmware, but I'm also happy to maintain the fork until then.
It adds a
linux_repeaterPlatformIO environment that compiles the simple repeater firmware for Linux SBCs (Raspberry Pi Zero, 3, 4, 5) using the ArduLinux Arduino-compatibility layer. Compared to #1137, it no longer depends on Meshtastic's Portduino framework, and repeater name/password/etc. no longer need compile-time constants, they're parsed from an INI file on first run and changed thereafter via CLI or remote config.New files
variants/linux/,LinuxBoard(SPI + libgpiod GPIO init),LinuxSX1262/LinuxSX1262Wrapper(RadioLib SX1262 driver),target.cpp/h, PlatformIO config, INI templates, systemd unit, and udev rulesboards/linux.json, board descriptorShared-helper changes (guarded by
ARDULINUX_PLATFORM)IdentityStore,ClientACL,CommonCLI,RegionMap: use the 2-argfs::open(path, mode)(string-mode, as on RP2040) since the ArduLinux FS has no 3-arg overloadTxtDataHelpers: usesprintf/PRId32instead ofltoa(not available)MyMesh: filesystem init,formatFileSystem()stub, andsaveIdentity()path for Linux; apply INI config as first-run defaults beforeloadPrefs()Real hardware GPIO/I2C in
LinuxBoardis compiled in automatically (guarded byARDULINUX_HARDWARE, which ArduLinux defines whenlibgpiodis detected viapkg-config); without it the build falls back to ArduLinux's simulated devices.The following repeater is live and in service using this linux branch on a Raspberry Pi 4B with a LoRa hat: MeshCoreD LinuxRepeater (
63, regionBER)I'll attach screenshots from remote management as manual testing did not reveal any issues.
/cc @ggodlewski