I haven't specifically tested this with Hermes, but I would expect so. Hermes is orchestrating things - it decides it needs to...whatever you want, book a trip for you. Forge will help make sure that the API calls to hotel booking sites parse correctly or gracefully retry.
Without forge, I'd guess a small model used for Hermes would have to retry entire workflows when an uncaught exception triggerd when it tried to reply with text when "calling a tool" ("Here is the tool call: [json blob]"). The issue there becomes partial successes can lead to state changes that need to be addressed (it booked the flight already, home it doesn't double-book).
Forge won't help with model reasoning quality though. If it the model thinks the right thing to do is to book 3 buses for your trip, forge doesn't care, it'll just make sure those api calls land.
I used Claude, back then when the free tier was usable, to port Linux on a obsolete, unsupported and undocumented board whose manufacturer didn't publish any info aside binary only Android images, which fortunately were enough to obtain some info.
This tickled my imagination and I wondered about a AI assisted reverse engineering platform with a complete build system in which the AI is connected to ports (serial console, gpio, i2c, spi, etc) normal physical switches (on/off, reset, etc) of the target board and a logical switch that can rotate among multiple SD cards either to the development PC and to the board so that the AI itself can download, build in parallel and test images and software freely offloading the most time consuming parts.
What sort of debug/probing harness did you have? I find it hard to conceptualise, when nothing boots yet. Did you have serial output working right from the beginning? Or did you have to get that first and then everything else was possible?
Nothing aside a normal PC. I was the slow human in the middle swapping cards and typing/copying/pasting commands and results; I admit being far away from being able to do that myself; tried a few years ago and failed, then AI happened. The board SoC (Allwinner A20) is already well supported by Linux but there was no image available and the on board hardware wasn't documented, but at least I had a working system to probe the hardware with. The hardest part however was finding the pins used to turn on and off peripherals since reading the Android script.bin and other boot files brought some inconsistencies anyway, so it took long probing sessions. It took weeks before I could have a working video output for example.
Here's an excerpt from a Claude snapshot, probably too long to post entirely (I don't have a GH account, thinking of opening a Codeberg one some day). I later moved everything to Deepseek because Claude became unusable giving just one single prompt before hitting the daily limit; I was about to subscribe to a paid plan but paying users started complaining about shrinking limits as well, so I left.
First came Armbian, then I wanted to have a lighter OS and ported Alpine which boots from a Armbian kernel that then gives control to a full Alpine userland.
Feel free to ask if you need further details. I'm sure the same process could be automated by removing the incredibly slow human and building an interface that would let the AI probe, try and fail, essentially brute forcing unknown hardware until it responds.
GIADA NI-A20 - BOARD SNAPSHOT 2026-03-21
=========================================
Board: Giada NI-A20, Nano-ITX form factor
SoC: Allwinner A20 (sun7i) - see snapshot-soc-allwinner-a20.txt
RAM: 1GB
Storage: SD card (primary), NAND (data only), SATA
Serial console: ttyS0 at 115200, RS232 level on DB9 COM2
STATUS:
Armbian: COMPLETE
Alpine: COMPLETE
HARDWARE
--------
SoC: Allwinner A20 (sun7i), dual-core ARM Cortex-A7, ARM Mali-400 MP2
RAM: 1GB
Storage: 8GB NAND (data only, NOT bootable), SD card, SATA
Serial console: ttyS0 at 115200, RS232 level on DB9 COM2
PMU: AXP209 on TWI0 (I2C address 0x34)
RTC: PCF8563 on TWI1 (I2C address 0x51)
Ethernet: GMAC (Gigabit), interface end0
WiFi: AP6210 (Broadcom BCM43362), SDIO on mmc3, 2.4GHz b/g/n
Bluetooth: BCM20710 on uart2 (NOT YET ENABLED in DTS)
GPS: unknown chip, power enable PC22, UART on ttyS1, NMEA at 9600 baud
USB Hub: GL850G on EHCI1, power enable PH7
IR receiver: /dev/lirc0
SATA power connector: JST PH 2.0mm 4-pin (pin1=12V, pin2=5V, pin3=GND, pin4=GND)
LVDS: 30-pin dual channel 8-bit, max 1920x1080
COM2: RS232 Tx/Rx/CTS/RTS 4-wire (DB9 connector)
COM3: RS232 Tx/Rx 2-wire only
VGA: available via J4 14-pin header (non-standard connector)
Mini-PCIe: present, intended for 3G module
SIM card slot: present, for use with 3G module
GPIO MAP
--------
PH1 - SD card detect, active LOW
PH4 - USB OTG ID detect
PH5 - USB OTG VBUS detect
PB9 - USB OTG VBUS drive, active LOW
PH6 - USB Host1 VBUS, active HIGH
PH7 - USB Hub power enable (GL850), active HIGH
PH17 - SATA power enable
PH19 - Ethernet PHY power (vcc3v0 regulator), active HIGH
PH25 - USB Host2 VBUS, active HIGH
PI1 - WiFi WL_REGON, active HIGH (mmc3 pwrseq reset gpio)
PI14 - WiFi WL_HOST_WAKE (input)
PI20 - GPS UART7 TX (uart7_pi_pins)
PI21 - GPS UART7 RX (uart7_pi_pins)
PB5 - Bluetooth BT_REGON, active HIGH
PC22 - GPS VCC_EN power enable, active HIGH
PC00-PC16 - NAND bus
The mainline A20 DTS was missing pinctrl for mmc3 (WiFi SDIO).
Without it sunxi-mmc driver silently skips mmc3 initialization.
Fix applied to:
~/devel/embedded/armbian-build/build/patch/kernel/archive/sunxi-6.12/sun7i-a20-giada-ni-a20.dts
Added to &mmc3 node:
&mmc3 {
pinctrl-names = "default";
pinctrl-0 = <&mmc3_pins>; /\* <-- this line was missing \*/
vmmc-supply = <®_vcc3v3>;
mmc-pwrseq = <&mmc3_pwrseq>;
...
};
DTB recompiled manually (Armbian build used cached version):
cd ~/devel/embedded/armbian-build/build/cache/sources/linux-kernel-worktree/6.12__sunxi__armhf/
sudo touch arch/arm/boot/dts/allwinner/sun7i-a20-giada-ni-a20.dts
sudo make ARCH=arm allwinner/sun7i-a20-giada-ni-a20.dtb
CRITICAL: DTB lives in /boot/dtb/ not /boot/ on this board.
U-Boot boot.cmd looks in ${prefix}dtb/ directory.
Correct location: /boot/dtb/sun7i-a20-giada-ni-a20.dtb
Chip: Broadcom BCM43362, SDIO on mmc3, 2.4GHz b/g/n only
Driver: brcmfmac + pwrseq_simple
Firmware: brcmfmac43362-sdio.bin + brcmfmac43362-sdio.txt
Location: /lib/firmware/brcm/
Board-specific symlinks (created by build-image.sh):
brcmfmac43362-sdio.giada,ni-a20.bin -> brcmfmac43362-sdio.bin
brcmfmac43362-sdio.giada,ni-a20.txt -> brcmfmac43362-sdio.txt
No CLM blob available for BCM43362 (chip predates CLM blob requirement).
Result: limited to channels 1-11, TX power 31dBm.
The driver logs "no clm_blob available" - this is normal, not an error.
P2P error at init is harmless - BCM43362 does not support P2P mode.
WIFI BOOT SEQUENCE:
1. eudev starts at sysinit runlevel
2. pwrseq_simple loads from /etc/modules
3. mmc1 (SDIO) initializes, BCM43362 detected
4. brcmfmac loads from /etc/modules
5. eudev firmware rule instantly rejects missing clm_blob (no 60s timeout)
6. wlan0 appears, wifi OpenRC service starts wpa_supplicant
7. dhcpcd obtains IP on wlan0
eudev firmware rule (/etc/udev/rules.d/50-firmware.rules):
SUBSYSTEM=="firmware", ACTION=="add", \
TEST!="/lib/firmware/$env{FIRMWARE}", ATTR{loading}="-1"
Purpose: instantly rejects missing firmware requests instead of waiting
60 seconds per file for a userspace agent that never comes.
Without this rule: 120s boot delay (2x 60s timeouts for clm_blob + txcap_blob)
With this rule: WiFi up in ~15 seconds
Yeah. It makes me wonder if it would be possible to reverse engeneer firmware for popular TQ ebike motors. This firmware can be downloaded if you intercept dealer tool API calls. I have no experience at all with this, otherwise I would probably try.
I decompiled dealer tool, but it it quite complex WPF app and I cannot make it compilable. Make latest iteration of Claude can. It takes a lot of time, otherwise I would be probably try again.
It has an WPF app, which I tried to decompiled already, but firmware is a different beast. App downloads firmware during update proces. I have no idea about format or MCU used.
I will try to reverse engeneer firmware with claude when I will get all things needed for that.
I'll probably write another article on the star tracker itself. But I can give you a quick summary of the spiral search mechanism. It was electromechanical: a motor turned a resolver, a device with coils to generate sine and cosine from the shaft angle. This gives the X and Y deflections for a circle. These signals went through potentiometers that were also turned by the motor to produce constantly growing magnitudes, so you get a spiral. But you need to slow down the motor as you spiral outwards since you're covering a much larger linear region. So the motor also turns a stepping switch that progressively reduces its speed.
Once the system finds a star, a complicated feedback mechanism keeps it locked onto the star. There is a spinning slotted disk in front of the photomultiplier tube. If the star is off center, the output will peak when the slot lines up with the star. Thus there is an error signal with phase that indicates the direction to the star. This signal is demodulated to produce X and Y signals that change the aim to move towards the star.
I would absolutely love to read something about that - thanks for putting in the work and sharing it.
I have a buddy working on restoring a set of binoculars that were attached to the Target Bearing Transmitter system for a US sub from the 50s. Last I heard he was able to find someone that actually had parts of the original schematics for it so that he’s able to machine some new pieces.
Am I right in thinking it didn't matter which star it locked onto, and it didn't need to know which star it was? Would it be a problem if it locked onto another celestial body (e.g. Venus)?
No, it needed to lock onto the right star, the one that matched the coordinates. Otherwise, it would be pointing in a random direction. The navigator would check against three different stars to detect an error.
The system could also use planets or even the sun for navigation. A special filter was used with the sun to avoid burning out the photomultiplier tube.
Ah, so it could be used in the daytime. I read the whole article assuming it was only useful at night. (When else would you be flying a bomber and need high accuracy?)
I can see valid uses of this but I also feel like a probabilistic calculator would be more useful.
e.g. the result for the 1 / [-1, 2] example doesn’t tell you how likely each value is and it clearly won’t be uniformly distributed (assuming the inputs are).
