Add native Linux/Portduino repeater target

[l5yth]

This is a continuation of #1137 (and #395) to fix #619. The goal is to keep this diff clean and rebased on upstream to get this merged into the meshcore firmware on day eventually but I'm also willing to maintain the fork until this happens.

Adds a linux_repeater PlatformIO environment that compiles the simple repeater firmware for Linux SBCs (Raspberry Pi Zero, 3, 4, 5) using the Portduino Arduino-compatibility layer. The main difference to #1137 (besides the rebase) is that you don't need compile-time constants for repeater name, password, etc. as this can now be parsed from the INI on first run (and later changed via CLI or remote config).

New files:

• variants/linux/: LinuxBoard (SPI/GPIO init via libgpiod), LinuxSX1262/LinuxSX1262Wrapper (RadioLib SX1262 driver), target.cpp/h, PlatformIO config, INI config file, systemd service unit, and udev rules
• boards/linux.json: board descriptor

Changes to shared helpers (ARCH_PORTDUINO guards throughout):

• IdentityStore, ClientACL, CommonCLI, RegionMap: use 2-arg fs::open() (Portduino lacks ESP32's 3-arg overload)
• TxtDataHelpers: replace ltoa (not POSIX) with sprintf/PRId32
• MyMesh: add ARCH_PORTDUINO filesystem init, formatFileSystem() stub, and saveIdentity() path; apply runtime INI config as first-run defaults before loadPrefs()

The following repeater is live and in service using this linux branch on a Raspberry Pi 4B with a LoRa hat: MeshCoreD LinuxRepeater (63, region BER)

• https://analyzer.letsmesh.net/nodes/repeaters?public_key=63E822CAEE5548B7CB891F002F032247C1F54B08CEC4E39EAD2450F5C06E6AE2

I'll attach screenshots from remote management as manual testing did not reveal any issues.

/cc @ggodlewski

[l5yth]

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.

l5yth#3

Please let me know if you prefer it this way over the rather minimalist Portduino variant.

[ggodlewski]

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.

l5yth#3

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).

[liamcottle]

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.

[l5yth]

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 .pow-sx1262 - it does read the ini on first run, so you don't need to set advert name and admin password as build flag anymore. It might need to recreate the com_prefs in the working dir.

@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]

value != 0 means "the pointer is not null". should this check whether the string pointer exists, not whether the config value is truthy

[l5yth]

You are correct. This always returns true, apparently. Fixed l5yth#6