G2 Updated files and simplified update procedure

[Trucker]

I updated the FPGA in my Ultra just yesterday from Laurence's Github page.
No issues with the front panel display. Maybe a setting that your friend was using previously has changed?
James
WD5GWY


https://github.com/laurencebarker/Saturn/tree/main/FPGA

[syracusepro]

I got V17 of the firmware. Trying to upgrade to V25, but there is no folder called Saturn/scripts.
Saturn is there, but within Saturn, there is no folder called scripts.
Thanks.

[WB9HKO]

I got V17 of the firmware. Trying to upgrade to V25, but there is no folder called Saturn/scripts.
Saturn is there, but within Saturn, there is no folder called scripts.
Thanks.

I also have V17 firmware in my non-display G2. I can easily enough create a "scripts" directory, just don't know where to go from there. I've watched @N4VFR's video quite a few times, but not I'm sure whether to start from the @LauerenceBarker github or the @KD4YAL github since the firmware is older and components are obviously missing.

Tom

[WB9HKO]

Do I just need to create a local scripts directory, then copy the contents (*.sh's) of the script directory on Lauerance's github to my RPi4 and then execute "update-G2.sh" in terminal?

Then follow with the firmware update process to update the FPGA from v17 to v25?

[laurencebarker]

I can't remember when the "scripts" folder was added but it is possible that you haven't pulled it in from git yet.

open a terminal window and type:
cd ~/github/Saturn
git pull


that should net you a scripts folder!

[WB9HKO]

I can't remember when the "scripts" folder was added but it is possible that you haven't pulled it in from git yet.

open a terminal window and type:
cd ~/github/Saturn
git pull


that should net you a scripts folder!

Thanks, that bit worked great. I then ran only the update-G2.sh script, and looking through the log file it seemed to process everything ok. Unfortunately, the Flashwriter app does not seem to be among the desktop icons any more. There is just a text file (see pic). When I ran the P2app to re-check firmware, it says the firmware v17 (major version0) is not compatible because p2app requires major version = 1, so I may have a chicken and egg problem in that I can't flash the v25?

There is still a Flashwriter directory with what looks like everything in it. Do I just execute directly from there?

UPDATE: Rebooted the pi and Flashwriter was there on the desktop as it should be. I then ran the update to v25 with success.

Saturn p2app output - 1.jpeg (390.69 KiB) Viewed 2310 times

[WB9HKO]

Text file on desktop

Flashwriter text file on desktop - 1.jpeg (233.82 KiB) Viewed 2308 times

Flashwriter directory

Flashwriter directory - 1.jpeg (218.31 KiB) Viewed 2308 times

Log file is also attached

[laurencebarker]

you can run flashwriter from its own folder:


cd ~/Saturn/sw_tools/flashwriter
./flashwriter


if there is no flashwriter application file:

make clean
make

[WB9HKO]

you can run flashwriter from its own folder:


cd ~/Saturn/sw_tools/flashwriter
./flashwriter


if there is no flashwriter application file:

make clean
make

Thanks Laurence. I figured out to reboot the RPi and everything worked perfectly after that. Flashwriter app icon appeared, so I was able to upgrade to v25 on the FPGA also. Already made a few contacts today

[DO7DV]

I successfully updated the FPGA to V25TTL using flashwriter.
In the source files there is a reference to a "command line tool" it was derived from. Where can I find this command line tool?

For a completley automated Anan-G2 update procedure the cli tool to program the FPGA should also be pulled into the /home/pi/github/Saturn folder.



I tried to create a new SD card for my CM4 with the most current "Trixie" release.
But I encountered problems when trying to build p2app. (everything else did compile correctly)
Below there is the output of make.

I suspect it has something to do with Trixie having libgpiod v2 (and gpiod 2.2), while in Bookworm you get libgpio v1 (and gpiod 1.6).
The new interface breaks compatibility.

Building a new SD card for CM4 with Bookworm does work.

Code: Select all

pi@raspberrypi:~/github/Saturn/sw_projects/P2_app $ make
gcc -c -o g2panel.o -Wall -Wextra -Wno-unused-function -g -D_GNU_SOURCE -D GIT_DATE='"3 Dec 2025 19:52:54"' g2panel.c
g2panel.c:100:8: error: variable ‘config’ has initializer but incomplete type
  100 | struct gpiod_line_request_config config = {"p2app", GPIOD_LINE_REQUEST_DIRECTION_INPUT, 0};
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~
g2panel.c:100:44: warning: excess elements in struct initializer
  100 | struct gpiod_line_request_config config = {"p2app", GPIOD_LINE_REQUEST_DIRECTION_INPUT, 0};
      |                                            ^~~~~~~
g2panel.c:100:44: note: (near initialization for ‘config’)
g2panel.c:100:53: error: ‘GPIOD_LINE_REQUEST_DIRECTION_INPUT’ undeclared here (not in a function); did you mean ‘GPIOD_LINE_DIRECTION_INPUT’?
  100 | struct gpiod_line_request_config config = {"p2app", GPIOD_LINE_REQUEST_DIRECTION_INPUT, 0};
      |                                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                     GPIOD_LINE_DIRECTION_INPUT
g2panel.c:100:53: warning: excess elements in struct initializer
g2panel.c:100:53: note: (near initialization for ‘config’)
g2panel.c:100:89: warning: excess elements in struct initializer
  100 | struct gpiod_line_request_config config = {"p2app", GPIOD_LINE_REQUEST_DIRECTION_INPUT, 0};
      |                                                                                         ^
g2panel.c:100:89: note: (near initialization for ‘config’)
g2panel.c: In function ‘VFOEventHandler’:
g2panel.c:260:29: error: storage size of ‘Event’ isn’t known
  260 |     struct gpiod_line_event Event;
      |                             ^~~~~
g2panel.c:265:21: error: implicit declaration of function ‘gpiod_line_event_wait’; did you mean ‘gpiod_edge_event_cop’? [-Wimplicit-function-declaration]
  265 |         returnval = gpiod_line_event_wait(VFO1, &ts);
      |                     ^~~~~~~~~~~~~~~~~~~~~
      |                     gpiod_edge_event_copy
g2panel.c:268:25: error: implicit declaration of function ‘gpiod_line_event_read’; did you mean ‘gpiod_edge_event_fre’? [-Wimplicit-function-declaration]
  268 |             returnval = gpiod_line_event_read(VFO1, &Event);            // undocumented: this is needed to clear the event
      |                         ^~~~~~~~~~~~~~~~~~~~~
      |                         gpiod_edge_event_free
g2panel.c:269:28: error: implicit declaration of function ‘gpiod_line_get_value’; did you mean ‘gpiod_line_request_get_value’? [-Wimplicit-function-declaration]
  269 |             DirectionBit = gpiod_line_get_value(VFO2);
      |                            ^~~~~~~~~~~~~~~~~~~~
      |                            gpiod_line_request_get_value
g2panel.c:260:29: warning: unused variable ‘Event’ [-Wunused-variable]
  260 |     struct gpiod_line_event Event;
      |                             ^~~~~
g2panel.c: In function ‘G2PanelTick’:
g2panel.c:343:9: error: implicit declaration of function ‘gpiod_line_get_value_bulk’ [-Wimplicit-function-declaration]
  343 |         gpiod_line_get_value_bulk(&PBInLines, IOPinValues);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~
g2panel.c: In function ‘SetupG2PanelGPIO’:
g2panel.c:442:16: error: implicit declaration of function ‘gpiod_chip_get_line’; did you mean ‘gpiod_chip_get_info’? -Wimplicit-function-declaration]
  442 |         VFO1 = gpiod_chip_get_line(chip, 17);
      |                ^~~~~~~~~~~~~~~~~~~
      |                gpiod_chip_get_info
g2panel.c:442:14: error: assignment to ‘struct gpiod_line *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
  442 |         VFO1 = gpiod_chip_get_line(chip, 17);
      |              ^
g2panel.c:443:14: error: assignment to ‘struct gpiod_line *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
  443 |         VFO2 = gpiod_chip_get_line(chip, 18);
      |              ^
g2panel.c:445:9: error: implicit declaration of function ‘gpiod_line_request_rising_edge_events’; did you mean ‘gpiod_line_request_read_edge_events’? [-Wimplicit-function-declaration]
  445 |         gpiod_line_request_rising_edge_events(VFO1, "VFO 1");
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |         gpiod_line_request_read_edge_events
g2panel.c:446:9: error: implicit declaration of function ‘gpiod_line_request_input’; did you mean ‘gpiod_line_request_get_fd’? [-Wimplicit-function-declaration]
  446 |         gpiod_line_request_input(VFO2, "VFO 2");
      |         ^~~~~~~~~~~~~~~~~~~~~~~~
      |         gpiod_line_request_get_fd
g2panel.c:449:9: error: implicit declaration of function ‘gpiod_chip_get_lines’; did you mean ‘gpiod_chip_get_info’? -Wimplicit-function-declaration]
  449 |         gpiod_chip_get_lines(chip, PBIOPins, VNUMGPIO, &PBInLines);
      |         ^~~~~~~~~~~~~~~~~~~~
      |         gpiod_chip_get_info
g2panel.c:450:9: error: implicit declaration of function ‘gpiod_line_request_bulk’; did you mean ‘gpiod_line_request_get_fd’? [-Wimplicit-function-declaration]
  450 |         gpiod_line_request_bulk(&PBInLines, &config, IOPinValues);
      |         ^~~~~~~~~~~~~~~~~~~~~~~
      |         gpiod_line_request_get_fd
g2panel.c: In function ‘ShutdownG2PanelHandler’:
g2panel.c:531:9: error: implicit declaration of function ‘gpiod_line_release’; did you mean ‘gpiod_line_request_release’? [-Wimplicit-function-declaration]
  531 |         gpiod_line_release(VFO1);
      |         ^~~~~~~~~~~~~~~~~~
      |         gpiod_line_request_release
g2panel.c:533:9: error: implicit declaration of function ‘gpiod_line_release_bulk’ [-Wimplicit-function-declaration]
  533 |         gpiod_line_release_bulk(&PBInLines);
      |         ^~~~~~~~~~~~~~~~~~~~~~~
g2panel.c: At top level:
g2panel.c:99:24: error: storage size of ‘PBInLines’ isn’t known
   99 | struct gpiod_line_bulk PBInLines;
      |                        ^~~~~~~~~
g2panel.c:100:34: error: storage size of ‘config’ isn’t known
  100 | struct gpiod_line_request_config config = {"p2app", GPIOD_LINE_REQUEST_DIRECTION_INPUT, 0};
      |                                  ^~~~~~
make: *** [Makefile:31: g2panel.o] Error 1

[laurencebarker]

Martin CT1IQI has already reported the issue with newer kernels and libgpiod. Yesterday he sent me code to try, but I don't know yet if I can test it. If I can it won't be till next week because my access to the radio is blocked by visitors.

The command line flash programmer is available in ~/github/Saturn/sw_tools/spiload. I will need to work out the offset address that the flash device should be written to (it isn't zero, or the "fall back boot" process will be lost).

[kd4yal]

Hi all,

I’ve been running Raspberry Pi OS Trixie since its release and have developed several patches in my GitHub repo to address the issues I encountered getting Trixie working on the G2 CM module. I think the bigger long-term concern is how GPIO will be handled to maintain compatibility across OS versions. Also, please note that my patches have not been tested on an Ultra I have only tested with the (black face) unit.

https://github.com/kd4yal2024/Saturn/tree/main/scripts

I also have a Trixie image that’s currently being tested by several users. So far, the only issue being reported is IPv4 link-local (APIPA). It was widely expected that IPv4 link-local behavior would be “fixed” in Trixie, but reports still indicate cases where IPv4LL/APIPA is not assigned correctly, depending on the configuration and how NetworkManager is provisioned. I have a patch for this as well, but I’m continuing to validate it before publishing it to GitHub.


Jerry, KD4YAL

[KD1GA]

Thanks Jerry for posting this and all the help it's truly appreciated.

[ct1iqi]

@DO7DV
as Laurence already mentioned I found the same problem when compiling an OS for the upgrade with Radxa CM5.
Using the Armbian build system, kernel 6.18, and Debian Trixie. Got p2app to compile again by some edits to Makefile and g2panel.c
You can find them here:
https://cacelense.pt/G2/p2app_gpiod_v2
In Makefile you can choose either gpiod v1 or v2.

[kd4yal]

Thanks for sharing that, and yes — we’re converging on the same underlying issue.

For clarity, I have already implemented a more robust and forward-compatible solution in my GitHub repository, which includes conditional handling for libgpiod v1 vs. v2, build fixes, and a simplified update procedure that avoids breaking older images. That work has been running successfully on multiple G2 CM systems under Raspberry Pi OS Trixie.

However, those changes have not been accepted upstream, which is why different parallel solutions are now appearing. My approach was designed specifically to survive OS transitions (Bullseye → Bookworm → Trixie) with minimal churn and without requiring users to manually edit Makefiles or source files during upgrades.

It’s encouraging to see others independently arrive at similar conclusions — it reinforces that the root cause is well understood now. The remaining challenge isn’t technical so much as consolidation: agreeing on a single, maintainable upstream solution so we don’t fragment fixes across multiple repos and images.

For reference, my implementation and update scripts are here:
https://github.com/kd4yal2024/Saturn/tr ... cts/P2_app

I’m happy to compare approaches or help align things if there’s interest in merging efforts upstream. Long-term stability across OS releases should really be the goal here.

Jerry, KD4YAL

[ct1iqi]

@KD4YAL
Don't think indeed there is doubt about the underlying cause of the compilation problem. Libgpiod's API changed quite a bit.
I think the code that did not compile comes into action for a G2 with v1 front panel controls and I don't have such a panel. So a test using a v1 front is recommended before introduction of this code refinement.
To make the code changes I actually used AI (codeconvert.ai), not wanting to dive into the gpiod intricacies.
(G2 here: v2 control panel, USB virtual serial connected to Saturn, Radxa CM5 with Rockchip rk3588s2 on Saturn and the OS in eMMC memory; kernel 6.18, Debian Trixie w.o. desktop, labwc Wayland compositor, Armbian custom built)

[laurencebarker]

Testing is the problem here. I don't have a G1 panel ready for use either; and I have time sensitive work to do on another radio project. That means I can't stop, reconfigure my radio to another OS release, add back the G1 panel (if indeed I have all of it) and then test the new library code. It will have to wait until the current work is complete. I certainly don't have several radios, in each of the different build standards, ready to go.

If someone with a G2V1 front panel is able to test Martin's or Jerry's code, and tell me that it works, I can incorporate it into the code base.

I have raised the problem with Abhi. OS updates are creating a greater support burden that was anticipated.

[kd4yal]

Laurence,

That’s completely fair — testing is the bottleneck, not the code.

I’m in the same boat on hardware coverage: I don’t have a G2V1 front panel available to test, and my current dev/test platform is a G2 without the LCD/control panel, so all I can directly validate right now is:

Buildability on Trixie / libgpiod v2

Service stability / runtime sanity on a headless unit

To reduce the “OS updates → support burden” problem, I’ve been pushing toward a Makefile-only auto-detect approach (via pkg-config --modversion libgpiod) that selects the correct implementation at build time — i.e. no patch scripts required, no generated source files, and existing comments left intact.

What we need (and what would help you upstream this)

If anyone here has a G2V1 front panel and can run a quick verification on Trixie (or any libgpiod v2+ platform), that would be the missing piece. Even a simple “buttons/encoders/VFO works for 30–60 minutes without the edge-wait falling over” report would be enough for you to confidently pull it into the code base.

A minimal test looks like:

cd sw_projects/P2_app && make clean && make -j$(nproc)

sudo systemctl restart p2app

Confirm panel operation (encoders/buttons) and leave it running for a while

If it fails, grab:

pkg-config --modversion libgpiod

journalctl -u p2app -n 200 --no-pager



I’ve also built a Trixie image that’s been intentionally kept to limited distribution while we shake out the rough edges and avoid creating noise/support expectations. That said, if someone wants to help test and can give actionable feedback, I’m happy to share it privately on request.

The big known “field issue” on Trixie has been intermittent IPv4LL/APIPA behavior depending on NetworkManager provisioning, so I included a conservative ethernet fallback safety net in my test image — and early testers have reported it restored predictable reachability in the cases where the unit otherwise came up “unreachable.”

If someone can put the code through its paces on a G2V1 panel and share outcomes (and logs if it gets cranky), that would unblock the upstream decision.

— Jerry (KD4YAL)

[w-u-2-o]

I have raised the problem with Abhi. OS updates are creating a greater support burden that was anticipated.

I warned of this issue during G2 development. I recommended that the hardware boot out of a write protected partition, and that updates be performed in a wholesale fashion by distributing updated boot images. This is a proven method for system stability and used on the vast majority of Linux-based "appliances" such as network-attached storage (NAS) units, etc. It was never articulated why this idea was rejected. Undoubtedly rejecting it saved a lot of up front development work, but now the pendulum has swung the other way.

It is an open source project. There are a lot of talented folks in the community, many of whom are posting in this topic. Why not band together, fork the repository, and work the changes as a team? This would take a great deal of stress off of Laurence, and wouldn't in any way preclude Laurence guiding development as time permits. It doesn't have to be a one person show.

[kd4yal]

w-u-2-o — agreed. OS churn is turning this into a support treadmill, and it shouldn’t be a one-person show.

The “appliance” model (known-good images, controlled updates, and a recovery path) is how you keep Linux systems stable. Even if we can’t do full write-protected/A-B partitions everywhere, we *can* move toward:

* a **community maintenance fork/branch** to absorb OS compatibility work (libgpiod v2, NetworkManager quirks, build/tooling)
* a **repeatable test checklist + build matrix** so “works/doesn’t work” isn’t guesswork

Testing is the bottleneck right now. I don’t have a G2V1 front panel available either (my G2 is headless), and I have time-sensitive work on another project — so I can’t keep reimaging and validating multiple hardware variants. If someone with a **G2V1 panel** can run a structured test and report back, Laurence can merge with confidence. I can provide the exact steps/logs to capture.

Regarding images: I’ve kept distribution limited to avoid creating friction with Apache Labs or blurring “official support.” But I’m happy to provide the current image **to anyone who requests it**, clearly labeled as a community/test image.

— Jerry (KD4YAL)

[w-u-2-o]

Testing is the bottleneck right now. I don’t have a G2V1 front panel available either (my G2 is headless), and I have time-sensitive work on another project — so I can’t keep reimaging and validating multiple hardware variants. If someone with a **G2V1 panel** can run a structured test and report back, Laurence can merge with confidence. I can provide the exact steps/logs to capture.

A very good point! A comprehensive set of intrepid alpha testers is definitely a requirement for success. Perhaps take a page out of Richie's book where Thetis is concerned? Stand up a Discord channel where dev's and alpha/beta testers can converge, communicate and collaborate.

Regarding images: I’ve kept distribution limited to avoid creating friction with Apache Labs or blurring “official support.” But I’m happy to provide the current image **to anyone who requests it**, clearly labeled as a community/test image.

No, no, no! Not this old misconception again

Once the hardware leaves the factory Apache doesn't give a hoot what people do with it from a software/firmware perspective. There can be friction, but it is between the very few dev's that make up the openHPSDR open source development community, none of whom work for Apache. Some dev's like to be one person shows, others are happy to collaborate. Similarly, some dev's have a strong sense of ownership over the code, others are more open (ha, a pun!).

The good news is that, unless a dev locks down read access to their public repo, not something that should be done with open source code, the code can always be forked and developed along a different path. The user community will then make their own choices.

At any rate, nothing ventured, nothing gained. For people with the time and the talent it would be a huge boon to the G2 community if there was active development to improve and extend the code base.