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

reply
That's the future
reply
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?
reply

   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

  DTS FIX - MMC3 WIFI PINCTRL
  -----------------------------
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 = <&reg_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

  WIFI - AP6210 (BCM43362)
  -------------------------
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
reply
Ha! I spent time also hacking together Armbian on an old A20 TV box.

Claude was definitely helpful the second time around to help with the DTS.

reply
Agreed. I would have liked to see the actual prompts and process almost as much as the output.
reply
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.
reply