![\"skAInet](\"https://edge-compute.skainet.io/img/edge-branded.jpg\")
\n For about ten years, every monitoring system I helped build at\nAuto-Intern had the same thing sitting in the\nmiddle of it: a small Linux box with one uplink, a handful of PoE ports, and\nenough compute to make sense of the sensors hanging off it. It was never the\nproduct. The product was the PowerSense, or the reflow oven monitor, or\nwhatever the customer had actually asked for. The box was the thing we\nrebuilt each time to make the product work.
\n\nThat box now has a name, a version number, and its own website:\nskAInet Edge-Compute v1.5.
\n\n\n In one sentence: a programmable M12-PoE switch, router, and compute module\nfor industrial edge applications, built in Germany by Auto-Intern GmbH.
\n\nThe parts that matter, in the order I care about them:
\n\nUpstream, it speaks whatever your systems already speak: REST, WebSocket,\nwebhooks, MQTT, OPC UA, Modbus-TCP, EPICS, gRPC, AMQP, CoAP, SNMP,\nPrometheus, InfluxDB, SFTP and rsync. Downstream, it collects, polls and\nreceives from anything with a network port.
\n\nPricing starts at USD 299, and the\ntechnical specifications\nand a getting-started guide\nare public.
\n\nThe lineage is documented on this blog, in pieces:
\n\nTen years of rebuilding the same thing is a strong hint that it wants to be\na product. Version 1.5 and its predecessors have been running 365/24/7 in\nplants collecting data, operating measurement devices and delivering results\nfor long enough that the “product” step was mostly a matter of writing it\nall down.
\n\nI joined Auto-Intern in 2014, was head of development from 2016 to 2018,\nwhich is when the PoE-first architecture became the house style, and have\nbeen Chief Operating Officer since 2018. In parallel I run\nnabla B, my own engineering office. The\nEdge-Compute is the platform underneath most of the monitoring projects\nlisted on my about page. My role on it is system architect: I was system architect on the reflow oven monitor\nbuilt on top of it, co-developed the M12 adapter, and specified the\ncabling. Odin Holmes owns\nhardware and firmware, Tabea Bökelmann\nowns software and the APIs; the whole team is on the\nteam page.
\n\nIf you want an Edge-Compute in your plant, the product side is Auto-Intern:\ninfo@auto-intern.de or the\ncontact page. If you need\nsomeone to design the measurement chain that hangs off its seven PoE ports,\nor to get your own sensor onto that network, that is the part I do\nfreelance; see /hire.
", "date_published": "2026-09-01T00:00:00+00:00", "date_modified": "2026-09-01T00:00:00+00:00", "image": "https://edge-compute.skainet.io/img/edge-branded.jpg", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["electronics","embedded","linux","monitoring","engineering"] }, { "id": "https://maxclerkwell.tech/posts/alinx-ax7020-yocto-linux-qspi-august-2026/", "url": "https://maxclerkwell.tech/posts/alinx-ax7020-yocto-linux-qspi-august-2026/", "title": "ALINX AX7020, Stages 2 & 3: A Yocto Linux in QSPI Flash That Fetches Its Own Updates", "summary": "Stages 2 and 3 of the open bitstream pipeline: a self-built Yocto Linux for the ALINX AX7020, resident in QSPI flash, discoverable on the company network, key-only SSH: the walkthrough that works, followed by the nine detours it took to get there.", "content_html": "Stage 1 ended with mainline U-Boot booting from QSPI flash and answering over\nthe network, and I closed that article by saying the Linux build gets its own\npost. This is that post, and true to form it contains a flash chip that\nverified every checksum while storing everything one byte off, a bootloader\nthat goes mute the moment you plug it into a real switch, and a real-time\nclock that turns out to be physically unreachable until the FPGA is\nconfigured.
\n\nThis covers Stages 2 and 3 of the\nbitstream pipeline plan\nfor the AX7020 that ALINX sent me: a self-built\nYocto Linux that boots from QSPI flash on its own, shows up on the company\nnetwork under its own hostname, accepts SSH logins only with a key, and\ncarries the tooling to fetch and kexec fresh development images from a\nserver: no PetaLinux, no vendor kernel tree, no SD card. Stage 2, the image\nserver, is in here too, though not in the shape the plan promised: a real\nswitch talked me out of netboot, and the server ended up as a plain HTTP\nendpoint the running Linux pulls from; more on that below.
Same structure as last time: first the walkthrough that actually works,\nreproducible from the Stage 1 end state. Then every detour, because the\ndetours are where the learning was, and at least three of them will bite\nanyone doing this on any Zynq board.
\n\nOF: fdt: Machine model: Alinx AX7020 board\nMemory: 1008588K/1048576K available\nmacb e000b000.ethernet eth0: Cadence GEM rev 0x00020118\nfpga_manager fpga0: Xilinx Zynq FPGA Manager registered\nof-fpga-region fpga-region: FPGA Region probed\nThat is the end state, booted straight out of flash. Here is the way there.
\n\nAs in Stage 1, every step ends in something you can test, because the\nexpensive failures on this road are the ones that pass every check you did\nthink of. The walkthrough is built around seven checkpoints:
\n\n| # | \nAfter | \nWhat must be true | \n
|---|---|---|
| 1 | \nYocto build | \n3953 tasks succeed; the FIT exists, dumpimage -l lists kernel, DTB and initramfs with SHA256 hashes | \n
| 2 | \nRAM boot | \ntftpboot + bootm boots Linux; /sys/class/fpga_manager/fpga0/ exists; port 22 answers (ping does not count) | \n
| 3 | \nboard identity | \nDHCP log shows a lease for the fixed MAC 02:41:58:70:20:01 with hostname ax7020, surviving an environment wipe | \n
| 4 | \nflashing the FIT | \nread-back MD5 matches, and the first words at several different flash offsets differ from each other (see detour 7) | \n
| 5 | \nstandalone boot | \npower cycle with J13 on QSPI: Linux up, SSH reachable, no JTAG, no TFTP | \n
| 6 | \ncompany network | \nthe board appears in the DHCP inventory API by name; SSH works through the office switch | \n
| 7 | \nkey-only SSH | \nlogin with the deployed key succeeds; wrong key, no key and password login are all rejected | \n
If a checkpoint fails, everything before it is known-good. All self-written\nfiles (the Yocto layer, the U-Boot patches, the host tools) live in\ngithub.com/MaxClerkwell/ax7020-bringup.\nNow the walkthrough.
\n\nThe board is where Stage 1 left it: boot.bin (mainline SPL) and\nu-boot.img in QSPI, operated entirely over U-Boot’s netconsole on UDP port\n6666, no serial cable. The lab tools are the same two Python scripts from the\nrepo: tools/ncsh.py for the netconsole and tools/tftpd.py as an\nunprivileged TFTP server.
Goal of this session: Linux.
\n\nscarthgap (Yocto 5.0 LTS), and not out of preference:
git ls-remote --heads https://github.com/Xilinx/meta-xilinx | grep -E \"scarthgap|styhead|walnascar\"\n# -> only scarthgap\nmeta-xilinx offers no newer release branch, and that pins the common\ndenominator for everything else: poky, meta-arm and meta-openembedded all get\nchecked out on scarthgap, as shallow clones, about 170 MB total.
One host-side wrinkle before the first bitbake: Debian 13 no longer ships\nliblz4-tool, the binary lives in the lz4 package, and Yocto wants it\nunder the old name lz4c, which lz4 ≥ 1.10 no longer installs. Instead of a\nroot-owned symlink in /usr/local/bin, the symlink lives in the repo\n(yocto/hostbin/lz4c → /usr/bin/lz4) and setup-build.sh prepends\nhostbin to PATH. No root, and the fix travels with the repository.
yocto/meta-ax7020/ holds everything board-specific. The machine\nconfiguration builds on meta-xilinx’s generic Zynq machine and narrows it\ndown:
require conf/machine/zynq-generic.conf\n\nKERNEL_DEVICETREE = \"xilinx/zynq-ax7020.dtb\"\n\nKERNEL_IMAGETYPE = \"fitImage\"\nKERNEL_CLASSES = \"kernel-fitimage\"\nINITRAMFS_IMAGE = \"ax7020-initramfs\"\nINITRAMFS_IMAGE_BUNDLE = \"0\"\n\n# U-Boot comes from mainline, not from Yocto\nPREFERRED_PROVIDER_virtual/bootloader = \"\"\nThe kernel device tree is a sibling of the U-Boot one from Stage 1: every\nvalue traced back to the ALINX design_1.hwh and the schematic, none of it\ncopied from a template. The load-bearing nodes:
&gem0 {\n\tstatus = \"okay\";\n\tphy-mode = \"rgmii-id\";\n\tphy-handle = <ðernet_phy>;\n\tethernet_phy: ethernet-phy@1 { reg = <1>; }; /* RTL8211E-VL */\n};\n\n&qspi {\n\tstatus = \"okay\";\n\tnum-cs = <1>;\n\tflash@0 {\n\t\tcompatible = \"w25q256\", \"jedec,spi-nor\";\n\t\tspi-rx-bus-width = <1>;\n\t\tspi-max-frequency = <25000000>;\n\t};\n};\nA kernel config fragment switches on what the project needs (the FPGA\nmanager framework, device-tree overlays, SPI-NOR, netconsole) and throws out\nwhat the board does not have (DRM, sound, WLAN, IPv6). The pleasant surprise:\nzynq-7000.dtsi already ships devcfg@f8007000 and an fpga-region node\nenabled, so the FPGA manager, the one feature this Linux absolutely must have\nfor the later stages, needed nothing board-specific at all.
The image recipe is core-image-minimal as a cpio.gz initramfs, plus\ndropbear for SSH.
source yocto/setup-build.sh\nbitbake virtual/kernel\nOne operational rule that cost an hour before it was a rule: start bitbake\ndetached. If the client terminal goes away, it takes the bitbake-server\nwith it (“Exiting as we could obtain the lock”) and the build stalls:
setsid nohup bash -c 'source yocto/setup-build.sh >/dev/null 2>&1; \\\n exec bitbake virtual/kernel' > build.log 2>&1 < /dev/null &\nRestarts are cheap: sstate-cache and tmp/work let it resume where it\ndied. The build hit three genuine errors on the way through (detours 1–3\nbelow); with those fixed, 3953 tasks completed overnight.
Checkpoint 1: verify the artefacts on the host.
\n\n| Component | \nSize | \n
|---|---|
| Kernel (linux-xlnx 6.6.40) | \n3.79 MiB | \n
| Device tree | \n11,651 B | \n
initramfs cpio.gz | \n 4.27 MiB | \n
| FIT total | \n8.06 MiB | \n
dumpimage -l fitImage must list all three sub-images with their SHA256\nhashes. Nothing downstream can work if this fails, and unlike everything\ndownstream, this failure comes with an error message.
Deliberately without touching the flash: a failure here costs nothing.
\n\ntftpboot 0x2000000 fitImage\nsetenv bootargs 'console=ttyPS0,115200 ip=dhcp'\nbootm 0x2000000\nU-Boot verified all three sub-images against their SHA256 hashes and handed\nover. Linux came up, took a DHCP lease, and dropbear answered.
\n\nCheckpoint 2: Linux is provably running. Two parts. First,\n/sys/class/fpga_manager/fpga0/ must exist, with the attributes name,\nstate, status and firmware; the last one is the file-write interface\nStage 4 will use to load bitstreams. Second, port 22 must answer. Not\nping: U-Boot happily answers ICMP while sitting in its netconsole loop, so a\nsuccessful ping proves nothing about which of the two systems you are\ntalking to. The reliable liveness test for Linux is the SSH port.
(A netconsole= kernel parameter, the obvious way to keep the cable-free\nconsole into Linux, stayed silent; that is detour 4.)
Until now the board drew a random MAC on every boot\n(CONFIG_NET_RANDOM_ETHADDR) and sent no hostname, which makes “find the\nboard on a network with 40 other devices” a daily annoyance. Two changes,\nboth baked into the U-Boot binary so they survive a wiped environment:
CONFIG_BOOTP_SEND_HOSTNAME=y\n#define CFG_EXTRA_ENV_SETTINGS\t\\\n\t\"ethaddr=02:41:58:70:20:01\\0\"\t\\\n\t\"hostname=ax7020\\0\"\t\t\\\n\t...\nThe MAC is locally administered (02:), 41:58 is “AX” in ASCII, 70:20\nthe board number. Silly, memorable, and it can never collide with a vendor\nOUI.
While rebuilding U-Boot anyway, a twelve-line patch went in for shared-lab\npoliteness: as long as ncip is the broadcast address, the first host that\ntypes into the netconsole claims it; U-Boot sets ncip to that caller’s\naddress, and everyone else’s input is ignored. The claim lives only in the\nRAM environment, so a reboot releases the board, and the owner can release\nit early with setenv ncip 255.255.255.255. To be clear about what this is:\nconvenience, not security. The netconsole has no authentication; whoever\nwins the race owns a bootloader prompt with sf write on it.
Checkpoint 3: the identity sticks. The DHCP server’s log must show\nthe lease bound to the fixed MAC and carrying the name:
\n\nDHCPACK on 10.42.100.134 to 02:41:58:70:20:01 (ax7020) via eno4\nThe original plan for this stage was pure netboot: U-Boot fetches the FIT\nover TFTP on every power-up, nothing but the bootloader in flash. On the lab\nnetwork, board and workstation joined by one USB Ethernet adapter, that\nworked flawlessly. On the company switch it died in a way that took a packet\ncapture to understand (detour 6 has the full autopsy): U-Boot re-initialises\nthe Ethernet link on every netconsole poll, the switch port restarts its\nspanning-tree timers on every link bounce, and the two livelock each other\nforever. Two seconds of boot messages, then permanent silence.
\n\nThe conclusion is worth stating as a design rule: a bootloader is not a\nnetwork citizen. U-Boot’s network stack is a polling loop bolted to a\nconsole; it was never meant to hold a link on managed infrastructure. Linux\nbrings the interface up once and handles link changes like an adult.
\n\nSo the architecture flipped into what it should have been from the start: a\nsmall, boring maintenance system resident in flash, and development\nimages that never get written to flash at all.
\n\nFlash (rarely changes) Network (changes daily)\n├─ SPL + U-Boot\n└─ FIT: kernel + initramfs ──► Yocto image from HTTP/Nextcloud\n with curl, CA certificates, │\n kexec, ntpd, dropbear │\n └── fetch, verify, kexec ───────────┘\nThe flash-resident image gained an updater package and CONFIG_KEXEC=y in\nthe kernel. The updater is a short shell script: fetch the image with curl,\ncheck the first four bytes are the FIT magic d00dfeed (this catches error\npages and captive portals before they reach the kernel), then\nkexec -l and kexec -e straight into the new system. No reboot, no flash\nwrite, no jumper.
This is also where Stage 2 of the original plan quietly dissolved: the\n“image server” is no longer special boot infrastructure the board depends\non, just any HTTP endpoint the updater can reach. Fetching over HTTPS\nsurfaced one genuinely obscure board fact about the RTC, which is detour 8.
\n\nThe Stage 1 layout reserved 13 MiB for a 1 MiB U-Boot; that got tightened,\nand the FIT gets the rest of the chip:
\n\n| Offset | \nContent | \nSlot | \n
|---|---|---|
0x000000 | \n boot.bin | \n 1 MiB | \n
0x100000 | \n u-boot.img | \n 2 MiB | \n
0x300000 | \n environment + redundant copy | \n256 KiB | \n
0x340000 | \n FIT | \n28.75 MiB | \n
bootcmd went into the binary rather than the environment:
CONFIG_BOOTCOMMAND=\"sf probe 0 30000000 0; sf read 0x2000000 0x340000 0x1000000; bootm 0x2000000\"\nTwo reasons, both learned the hard way: saveenv simply does not work in\nJTAG boot mode (U-Boot reports ENVL_NOWHERE there), and long setenv\ncommands break over the netconsole, where a swallowed quote character leaves\nthe parser waiting for a continuation line and eating everything that\nfollows. The read covers 16 MiB rather than the exact image size so a\ngrowing maintenance system fits later without a U-Boot rebuild.
The flashing itself is the Stage 1 recipe: TFTP the FIT into DDR, sf\nerase, sf write, read back, compare MD5. It passed. And the board did not\nboot, because of the single nastiest failure of this whole project, the BAR\naddress-mode bug of detour 7, whose defining property is that write and\nread-back were self-consistent and both wrong. Every MD5 check passed\nwhile every byte sat one position off in the physical array.
Checkpoint 4 therefore has two parts, and the second exists purely\nbecause of that detour: the read-back MD5 of the flashed region must match\nthe host, and reading the first words at 0, 0x100000 and 0x340000\nmust return different data at each offset. If several distant offsets read\nidentically, the flash addressing is broken, not the content, and no\nchecksum will ever tell you.
Checkpoint 5: the board boots Linux entirely on its own. JTAG cable\noff, J13 on QSPI, power cycle. The chain is now BootROM → SPL → U-Boot →\nFIT from flash → Linux, and the test is the same as checkpoint 2: a lease\nfor ax7020 within seconds, and port 22 answering. On the company switch\nthis now works, because by the time spanning tree releases the port, the\none who retries is the Linux kernel, not a bootloader in a polling loop.
With the board destined for the company network, “which IP does it have\ntoday” needed a real answer. That turned into a small service of its own: a\nREST API that reports every device the DHCP server knows about as JSON,\nreading the server’s state (config reservations plus live leases) instead\nof scanning the subnet, so it also finds devices that are currently off. It\nis public and generic at\ngithub.com/MaxClerkwell/dhcp-inventory-api.
\n\ncurl -s http://10.42.0.1:8000/get_all_network_clients | jq\nDeploying it in a container on the actual router surfaced three details\nthat are anything but cosmetic, and each failed silently:
\n\n--network host is mandatory. /proc/net/arp is per network\nnamespace. A bind-mount of the file shows the container’s three\nneighbours, not the router’s 38, and the endpoint keeps answering\ncheerfully, just nearly empty.rename. A bind-mount of the file pins the old\ninode, and the container serves a snapshot frozen at container start.\nThis was only noticed because the freshly connected AX7020 had a lease\nand did not appear in the list.ss -lntp must show exactly one bound address.There was also a ghost device named fantasia: Debian’s commented-out\nexample block in dhcpd.conf, faithfully parsed. The parser now strips\ncomments and only accepts a fixed-address that parses as an address.
Checkpoint 6: the board is discoverable. The API must list ax7020\nwith its fixed MAC and current address, and SSH must work through the\noffice switch.
Once Linux runs, the jumper dance is over for good. The MTD partitions from\nthe device tree are visible, and /dev/mtdblockN handles erasure itself:
# file onto the board: scp fails for lack of an sftp-server in the minimal image\nssh root@ax7020 'cat > /tmp/fitImage' < tftp/fitImage\n\n# write and verify\nssh root@ax7020 '\n dd if=/tmp/fitImage of=/dev/mtdblock3 bs=64k conv=fsync\n sync\n dd if=/dev/mtdblock3 bs=1 count=<size> 2>/dev/null | md5sum'\nAbout ten minutes at QSPI pace, then reboot. The maintenance system\nupdates itself over SSH; JTAG is now strictly a rescue tool.
A passwordless root login is fine on a point-to-point lab cable and\nindefensible on a shared network. Two small recipes fix it: one installs\nauthorized_keys for root, one configures dropbear with -s (disable\npassword authentication).
One warning that will lock somebody out: poky’s shipped dropbear.default\nsets -w, which forbids root logins entirely, keys included; until now\nonly the debug-tweaks image feature was overriding that. Remove\ndebug-tweaks (as you must, it is what makes root passwordless) and leave\nthe rest as-is, and you have locked yourself out of the board. The correct\nconfiguration is -s alone, with * in root’s password field.
Checkpoint 7, verified on the running board:
\n\n| Test | \nResult | \n
|---|---|
| login with the deployed key | \n✅ | \n
| login with a different key | \n❌ rejected | \n
| login without a key | \n❌ Permission denied (publickey) | \n
| login with a password | \n❌ Permission denied (publickey) | \n
![\"Key-only](\"/assets/posts/alinx-ax7020-yocto-linux-qspi-august-2026/ssh-login-ax7020.png\")
Stage 3 complete. BootROM, SPL, U-Boot, FIT, Linux: everything from flash,\non the company network, reachable only with the right key, with a tested\npath to update itself over SSH and a built (though not yet fired) kexec\npath for development images.
Same rule as last time: the walkthrough above reads like a tidy evening, and\nit was not. Chronologically, because several only make sense in sequence.
\n\n${UNPACKDIR} does not exist in scarthgap| install: cannot stat '/zynq-ax7020.dts': No such file or directory\nERROR: linux-xlnx do_configure failed\nThe variable arrived with Yocto 5.1; in scarthgap, SRC_URI files land in\n${WORKDIR}. Copy a do_configure snippet from current documentation into\nan LTS build and the path expands to nothing, and the error message shows\nthe result of the empty expansion, not the variable that caused it.
Fix, as it ended up: the bbappend probes both locations:
\n\nsrc=\"${UNPACKDIR}/zynq-ax7020.dts\"\n[ -f \"$src\" ] || src=\"${WORKDIR}/zynq-ax7020.dts\"\nbootgen-native will not build with GCC 15utils/src/cdo-load.c:140:14: error: assignment to 'char *' from incompatible\npointer type 'uint32_t *' [-Wincompatible-pointer-types]\nSince GCC 14 this is an error, not a warning. The irony: this build does not\nneed bootgen at all, boot.bin comes from the mainline SPL, but meta-xilinx\npulls it into the dependency chain regardless.
Fix, as it ended up: a bbappend that defuses exactly this diagnostic\nwith -Wno-incompatible-pointer-types. Not pretty, but it patches a tool\nwhose output is thrown away.
IMAGE_NAME_SUFFIXERROR: Could not find a valid initramfs type for ax7020-initramfs-ax7020,\nthe supported types are: cpio.lz4 cpio.lzo ... cpio.gz ...\nscarthgap appends .rootfs to image names; kernel-fitimage looks for the\nname without it. The supported types listed in the error are a red herring:\nthe type was fine, the filename was not.
Fix, as it ended up: IMAGE_NAME_SUFFIX ?= \"\" in the image recipe, the\nsame line poky’s own initramfs recipes carry for exactly this reason.
netconsole= as a kernel parameter stays silentThe obvious way to keep the cable-free console into Linux,\nnetconsole=6666@/eth0,6666@192.168.77.1/, produced nothing. That early in\nboot, the module cannot do ARP resolution; without the target MAC spelled\nout in the parameter, it sends to nobody, and it does so without a single\ncomplaint in dmesg that would point at the cause.
Fix, as it ended up: accepted rather than fought. Linux gets a real\nconsole over SSH minutes later anyway; the netconsole matters for U-Boot,\nwhere it stays. Filed under “the boot parameter needs the full MAC syntax\nif it is ever needed.”
\n\nDuring the first RAM boots, “the board answers ping” repeatedly stood in\nfor “Linux is up”, and it repeatedly lied: U-Boot answers ICMP too, from\nits netconsole loop, with the same IP the kernel would have. When a boot\nhung, ping kept succeeding and the diagnosis ran in circles.
\n\nFix, as it ended up: a procedural rule that made it into the\ncheckpoints: liveness for Linux is port 22, never ICMP. Checkpoints 2\nand 5 both encode it.
\n\nThe one that changed the architecture. On the company switch, the DHCP\nhandshake completed cleanly, two seconds of netconsole output arrived, then\nnothing: no ARP, no ping, no console. Ever. The router had no tcpdump, so\na raw AF_PACKET capture in Python had to stand in, and it showed the\nboard sending its last packet at 15:14:01 and then falling silent.
The cause sits in plain sight in the source. Every netconsole poll calls\nnet_loop(), which re-initialises the Ethernet device; zynq_gem_init()\ncalls phy_startup(), which fails while the link is down. U-Boot even has\na provision to skip re-init when the last protocol was netconsole, but\nafter dhcp the last protocol is BOOTP, so the very first console poll\nneeds a full init. On a managed switch that init tears the link down while\nthe port is still in spanning-tree listening state, the switch restarts its\ntimers on the new link, and the two sides livelock: the port never\nforwards, U-Boot never gets a link. On the lab’s directly attached USB\nadapter this can never happen, because autonegotiation there completes in\nmilliseconds with nobody holding the port back.
Fix, as it ended up: not a patch, a design change. A bootloader is not\na network citizen; the thing that lives on the network must be Linux. That\nsingle realisation produced the flash-resident maintenance system of\nStep 4, which is a better architecture anyway.
\n\nAfter flashing the FIT, the BootROM parked at 0xffffff28 with the boot\nmode correctly reading QSPI, exactly as if the flash were empty, although\nall three regions had verified by MD5 immediately after writing. On the\nnext JTAG boot, offset 0 contained text data and 0x340000 zeros. A full\nerase read back 0xFF everywhere, so the chip was healthy.
The tell came from comparing several offsets:
\n\nsf read ... 0 -> fffffe00 fffffeea fffffeea\nsf read ... 0x100000 -> fffffe00 fffffeea fffffeea identical!\nsf read ... 0x340000 -> fffffe00 fffffeea fffffeea identical!\nThe same data at every address, shifted by one byte, and eafffffe is the\nstart of boot.bin. Cause: CONFIG_SPI_FLASH_BAR. The 32 MiB W25Q256 runs\nin 4-byte address mode; with BAR enabled, U-Boot sends only three address\nbytes, the chip consumes the dummy byte as the fourth address byte, the\naddress overflows and lands near zero, and all data arrives one byte\nshifted. The vicious part: writes and reads went through the same broken\naddressing, so they were mutually consistent. Every verification passed,\npatiently confirming a wrong thing, while the BootROM, which correctly\nspeaks three-byte addressing on its own, found nothing where boot.bin\nwas supposed to be.
Fix, as it ended up: ./scripts/config --disable SPI_FLASH_BAR,\nrebuild; spi-nor then uses native 4-byte opcodes, and the same flash\nprocedure immediately produced a booting board. Plus the second half of\ncheckpoint 4: always read back several distant offsets and require them\nto differ. That check costs seconds and is the only one in this list that\ncatches an addressing bug, because checksums by construction cannot.
The updater fetches images over HTTPS, and curl rejected every\ncertificate as “not yet valid”: the clock stood at the epoch. Setting the\ntime with NTP would be routine, except for why there was no hardware clock\nin the first place:
grep -o 'PCW_I2C[01]_I2C[01]_IO\" VALUE=\"[^\"]*\"' design_1.hwh\n# PCW_I2C0_I2C0_IO\" VALUE=\"EMIO\"\n# PCW_I2C1_I2C1_IO\" VALUE=\"EMIO\"\nBoth I²C controllers are routed through EMIO, i.e. through the FPGA fabric.\nWithout a loaded bitstream there is physically no path from the processor\nto the RTC. A dependency loop hides here: the pipeline exists to load\nbitstreams over HTTPS, HTTPS needs the time, and the clock sits behind a\nloaded bitstream.
\n\nFix, as it ended up: the updater runs ntpd -n -q against a\nconfigurable server before any HTTPS fetch, and dies with a clear message\nif the clock cannot be set. Busybox ships the ntpd applet disabled; a\none-line config fragment enables it. The board simply has no usable RTC\nuntil a bitstream provides the I²C route, and now the scripts know that.
-w locks out root completelyHardening SSH nearly bricked the access instead: poky’s default dropbear\narguments include -w, which rejects all root logins, key or not. The\nonly reason key logins had worked before was the debug-tweaks image\nfeature quietly overriding it. Removing debug-tweaks, which is mandatory\nfor anything leaving the lab since it is also what makes root passwordless,\nwould have left -w in force and the board unreachable, on a system whose\nonly console is SSH.
Fix, as it ended up: an own dropbear.default with -s alone\n(password authentication off, key logins allowed), root’s password field\nset to *, and the four-row login test matrix of checkpoint 7 run before\nthe old image was overwritten. On a box with no serial console, test the\nnew lock before discarding the old key.
The score this time: three build errors, one architecture change forced by\na switch, and one flash bug that defeated every checksum thrown at it. The\nrecurring shape is the same as in Stage 1, but sharpened: the worst\nfailures were not the loud ones, they were the ones where every\nverification passed. The BAR bug confirmed a physically shifted flash\nimage with an unbroken chain of matching MD5s; the container served a\nfrozen lease file and an incomplete ARP table without a single error; ping\ncheerfully vouched for a Linux that was not running. Verification can\npatiently confirm a wrong thing, and the countermeasure is always the same:\ntest the property you actually need (different data at different offsets,\nport 22, the inode inside the container) rather than a proxy for it.
\n\nEverything is in\ngithub.com/MaxClerkwell/ax7020-bringup:\nthe Yocto layer, the U-Boot identity and console-claim patches, the updater\nrecipes, the dropbear configuration, and this walkthrough in longer form.\nThe DHCP inventory API lives in its own repository,\ndhcp-inventory-api.
\n\nNext is Stage 4: a bitstream from the open toolchain, Yosys and\nnextpnr-xilinx, written into /sys/class/fpga_manager/fpga0/firmware over\nSSH. The FPGA manager is registered and waiting, the board is one curl\naway, and somewhere behind an EMIO pin there is a real-time clock that\nwould very much like a bitstream to finally exist. That build gets its own\narticle.
I thought this would be an afternoon. Load a bootloader over JTAG, poke it a\nbit, write it into flash: how hard can it be? It took the better part of a\nday and nine distinct detours, from cache lines silently corrupting a loaded\nimage to a QSPI controller that reads everything three bytes off, but only\nin SPL, and only in quad mode.
\n\nThis post is Stage 1 of the\nbitstream pipeline plan:\nan ALINX AX7020 (Zynq-7000, XC7Z020) that powers on and boots mainline\nU-Boot out of QSPI flash by itself: no Xilinx FSBL, no vendor U-Boot fork,\nno JTAG adapter attached, and no serial cable ever connected. The console is\nU-Boot’s netconsole over UDP; the whole board is operated from the\nworkstation over Ethernet.
\n\nThe structure follows how I wish someone had written it for me: first the\nwalkthrough that actually works, reproducible on a clean machine and a clean\nboard. Then, at the end, every detour, because the detours are where the\nlearning was, and because most of them will bite anyone doing this on any\nZynq board.
\n\nU-Boot 2026.10-rc2 (Aug 30 2026 - 20:25:52 +0200)\nmodeboot = qspiboot\nDRAM size = 0x40000000 (1 GiB)\nDDR frequency = 533 MHz\nARM frequency = 766 MHz\nSF: Detected w25q256 with page size 256 Bytes, erase size 64 KiB, total 32 MiB\nIP addr = 192.168.77.77 (DHCP)\nThat is the end state. Here is the way there.
\n\nEvery stage of this bring-up ends in something you can test. That is important,\nbecause most failures on this road are silent, and without a defined “this\nmust now be true” you cannot tell which layer broke. The walkthrough is\nbuilt around seven such checkpoints:
\n\n| # | \nAfter | \nWhat must be true | \n
|---|---|---|
| 1 | \nOpenOCD scan | \ntwo TAPs found: Xilinx PL (0x23727093) and ARM DAP, both cores attached | \n
| 2 | \ntelnet into OpenOCD | \nhalt stops the CPU at the BootROM park point; mdw reads SLCR | \n
| 3 | \nU-Boot build | \nmkimage -l validates both images; fdtget finds the model and the flash@0 node in the SPL DTB | \n
| 4 | \nlab network setup | \nhost address, route, DHCP server and TFTP server verifiably up, board not needed | \n
| 5 | \nJTAG bring-up | \nboard takes a DHCP lease, netconsole is interactive, bdinfo/sf probe/mii info answer correctly | \n
| 6 | \nflashing | \nread-back MD5 of both flash regions equals the host’s md5sum | \n
| 7 | \nstandalone boot | \nafter a power cycle with J13 on QSPI: lease within ~5 s, banner shows modeboot = qspiboot, console interactive | \n
If a checkpoint fails, everything before it is known-good. That is the\nwhole point. Every self-written file that appears below (OpenOCD configs,\ndevice tree, defconfig, host tools) is available at\ngithub.com/MaxClerkwell/ax7020-bringup.\nNow the walkthrough.
\n\n| \n | \n |
|---|---|
| Board | \nALINX AX7020, XC7Z020-2CLG400, JTAG IDCODE 0x23727093 | \n
| DDR3 | \n2× MT41J256M16, 32-bit bus, 533 MHz → 1 GiB | \n
| QSPI | \nWinbond W25Q256, 32 MiB, single chip select, MIO 1..6 | \n
| UART | \nPS UART1 on MIO 48/49 via CP2102 (not used, no serial console) | \n
| Ethernet | \nPS GEM0, RGMII on MIO 16..27, MDIO on MIO 52/53, RTL8211E-VL at PHY address 1 | \n
| SD | \nMIO 40..45, card detect MIO 47 | \n
| USB | \nULPI on MIO 28..39, reset MIO 46 (active low) | \n
| Boot jumper | \nJ13: left pins = SD, middle = QSPI, right = JTAG | \n
The on-board JTAG adapter is a bare FTDI FT232H (0403:6014) wired to the\nfour MPSSE pins only. First curiosity of the day: it enumerates on USB\nregardless of whether the board’s power switch is on: the FT232H hangs on\nUSB VBUS, not on the board supply. That is a design choice, and the cheaper\nof two common ones. Standalone FTDI dongles and low-cost dev boards power\nthe adapter from the host; Digilent and the Xilinx eval boards instead feed\ntheir on-board FTDI from the board supply (or put it behind a level shifter\nreferenced to the target voltage), so the adapter only appears once the\nboard is up. Professional external adapters go further still and sense\nVTREF before driving anything. The bus-powered variant has a wrinkle beyond\nthe confusing enumeration: it drives TCK/TDI/TMS into an unpowered Zynq,\nwhose ESD protection diodes clamp those levels onto the dead supply rail,\nweakly back-powering the switched-off board. At an FTDI pin’s few mA this\nis usually harmless, but tidy design it is not. The practical lesson holds\nfor any bus-powered adapter, which is most of the cheap ones: lsusb\nshowing the adapter proves the cable, nothing more; whether a live JTAG\nchain sits behind it is a separate question that a scan answers, not\nenumeration.
Host tools: arm-none-eabi-gcc 15.2, OpenOCD 0.12.0, Python 3.13. No Vivado,\nno Vitis, no Xilinx tool of any kind.
Side note on the physical link: the Ethernet connection runs through the M12\nadapter from Auto-Intern GmbH, which I\nco-developed; the cable comes from Dongguan Guanghui Electronic Technology\n(GH Electronic). In March I visited their factory and worked out our\nEthernet cable specifications with their engineers; the same cables now\nship with Auto-Intern’s new skAInet Edge-Compute. Industrial Ethernet cabling (M12\nX-coded, shielding, IP rating, EMC and the certification paperwork that\ngoes with it) is a topic I enjoy, and I am happy to help teams in the EU and\nthe USA specify and certify correct cables. Get in touch if that\nis a problem you have.
\n\n\n\n![\"Auto-Intern](\"/assets/posts/alinx-bring-up-jtag-detected-without-power-august-2026/m12-adapter.jpg\")
\n ![\"Visiting](\"/assets/posts/alinx-bring-up-jtag-detected-without-power-august-2026/gh-factory-visit.jpg\")
\n ![\"Cable](\"/assets/posts/alinx-bring-up-jtag-detected-without-power-august-2026/gh-production.jpg\")
\n ![\"EMC](\"/assets/posts/alinx-bring-up-jtag-detected-without-power-august-2026/emc-lab-test.jpg\")
\n OpenOCD is a translator. On one side it talks to a USB adapter, on the other\nside to a debug port on a chip, and it knows nothing about either until you\ntell it. That is why you always hand it two files: one describing the\nadapter, one describing the target. The target file is usually someone\nelse’s problem: target/zynq_7000.cfg ships with OpenOCD and describes the\nwhole chain: a Xilinx TAP for the programmable logic, an ARM DAP for the\nprocessing system, two Cortex-A9 cores. The adapter file is yours; nobody\nupstream knows what the vendor wired up. Running only the target file fails\nwith Error: Debug adapter does not support any transports?.
Three questions for an unknown board, in order:
\n\nlsusb. 0403:6014 = FT232H →\nOpenOCD’s ftdi driver (MPSSE). 1366:xxxx would be J-Link,\n0d28:0204 CMSIS-DAP: a different driver, not a different pin table.That yields openocd/ft232h.cfg, complete:
adapter driver ftdi\nftdi vid_pid 0x0403 0x6014\nftdi layout_init 0x0008 0x000b # TMS idles high; TCK/TDI/TMS out, TDO in\nadapter speed 1000\ntransport select jtag\nlayout_init is the working line: low byte = idle levels (0x0008: TMS\nhigh, keeping the TAP in reset until OpenOCD takes over), high byte =\ndirections (0x000b: bits 0, 1, 3 out; TDO in). Every untouched pin stays\nan input.
openocd -f openocd/ft232h.cfg -f target/zynq_7000.cfg\nSuccess, with the board powered and J13 on JTAG, is checkpoint 1:
\n\nInfo : JTAG tap: zynq_pl.bs tap/device found: 0x23727093 (mfg: 0x049 (Xilinx), part: 0x3727, ver: 0x2)\nInfo : JTAG tap: zynq.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)\nInfo : zynq.cpu0: hardware has 6 breakpoints, 4 watchpoints\nInfo : zynq.cpu1: hardware has 6 breakpoints, 4 watchpoints\nInfo : Listening on port 4444 for telnet connections\nPart 0x3727 is an XC7Z020, the DAP is reachable, both A9s attached. Note\nthat OpenOCD is now a server, not a prompt: the FT232H is the interface,\nJTAG the protocol, OpenOCD the daemon that owns the adapter and translates\nwhatever a client asks (telnet on 4444, gdb on 3333, Tcl on 6666) into\nJTAG transactions. From the client side you never see TAPs or scan chains,\nonly a chip with registers and memory.
Do this telnet test once in any case; it is checkpoint 2 of the\nbring-up (checkpoint 1 being the two TAPs in the scan). Since OpenOCD\noccupies its terminal as a server, you need a second terminal for it:
\n\n$ telnet localhost 4444\n> halt\ntarget halted in ARM state due to debug-request, current mode: Supervisor\ncpsr: 0x000001d3 pc: 0xffffff34\nMMU: disabled, D-Cache: disabled, I-Cache: disabled\n> mdw 0xF8000000\n0xf8000000: 00000000\nPC 0xffffff34 is inside the BootROM, where a Zynq with the jumper on JTAG\nparks, waiting for exactly this. mdw on the SLCR block proves memory-mapped\naccess through the DAP.
One caveat before moving on: JTAG sees the chip, not the board. IDCODE,\ndevice DNA, SLCR state (including the boot-mode pins at 0xF800025C): all\nreadable. DDR population, MIO wiring, flash type: not. The DDR controller\ncannot even be probed before it is initialised, and initialising it needs\ntiming values only the schematic knows. Boards from Xilinx or Digilent carry\nan I²C EEPROM with a board ID; the AX7020 has none. The board model stays\nmanual work.
Mainline U-Boot (v2026.10-rc2, commit 527115ef6783) has no AX7020\nsupport: no DTS, no defconfig, no board directory. Everything has to come\nfrom the vendor package (AX7020_2023.1, a 2.2 GB download kept only as a\nsource of facts):
course_s4_linux/linux_base/Vitis/design_1_wrapper.xsa →\nps7_init_gpl.c/.h. This is the PS initialisation Vivado generates\n(PLLs, MIO muxing, DDR timing) and the one thing that genuinely cannot be\nwritten by hand. Using it directly is the “Vivado init without the Vivado\nFSBL” approach.design_1.hwh inside the same XSA: the Vivado PS configuration as XML,\nevery setting a PCW_* parameter. Source for nearly every device-tree\nvalue.pdftotext) for what the HWH cannot say: which\npins go where on the PCB.system-user.dtsi from course_s6 as a third witness; it\nsettled the one value the other two sources cannot give (the PHY address,\nset by strapping resistors).arch/arm/dts/zynq-ax7020.dts (plus a Makefile entry)\nconfigs/alinx_ax7020_defconfig\nboard/xilinx/zynq/zynq-ax7020/ps7_init_gpl.c\nboard/xilinx/zynq/zynq-ax7020/ps7_init_gpl.h\nU-Boot picks the ps7_init up automatically: the directory name matches\nCONFIG_DEFAULT_DEVICE_TREE while CONFIG_XILINX_PS_INIT_FILE is empty.\nFive K&R declarations (int ps7_init(); et al.) need (void), because GCC 15\nbuilds SPL with -Werror=strict-prototypes.
The defconfig derives from xilinx_zynq_virt_defconfig. The full delta,\nevery line of which exists for a reason (the reasons are the detours at the\nend):
+ CONFIG_DEFAULT_DEVICE_TREE=\"zynq-ax7020\" (was \"zynq-zc706\")\n+ CONFIG_NET_LEGACY=y (replaces CONFIG_NET_LWIP)\n+ CONFIG_NETCONSOLE=y\n+ CONFIG_CONSOLE_MUX=y\n+ CONFIG_SYS_CONSOLE_IS_IN_ENV=y\n+ CONFIG_PREBOOT=\"setenv autoload no; dhcp; setenv stdin serial,nc; \\\n setenv stdout serial,nc; setenv stderr serial,nc\"\n+ CONFIG_BOOTCOMMAND=\"echo AX7020 netconsole ready\"\n+ CONFIG_CMD_TFTPPUT=y, CONFIG_TFTP_PORT=y\n+ CONFIG_CMD_MD5SUM=y, CONFIG_CMD_HASH=y, CONFIG_MD5=y\n- CONFIG_SPL_LOAD_FIT, CONFIG_SPL_FIT, CONFIG_SPL_FIT_PRINT\n- CONFIG_SPL_STACK_R\nAt power-on the Zynq has exactly two memories code can run from: the BootROM\n(fixed in silicon) and 256 KB of OCM. DDR is dead until ps7_init has\nbrought up PLLs and run the controller training. Full U-Boot is 1 MB: it does\nnot fit in OCM, must run from DDR. So somebody small enough for OCM has to\nswitch the DDR on first:
BootROM (in silicon)\n │ loads ≤ ~190 KB from QSPI/SD/JTAG into OCM, jumps there\n ▼\nSPL (u-boot-spl.bin, ~107 KB, runs in OCM)\n │ runs ps7_init → PLLs, MIO, DDR are up\n │ loads u-boot.img from QSPI into DDR\n ▼\nU-Boot proper (u-boot.bin, ~1 MB, runs in DDR)\n ▼\nLinux (later)\nSPL, the Secondary Program Loader, is not a second program but the same U-Boot\nsource, cut down via CONFIG_SPL_BUILD to board init, one boot-medium\ndriver, one loader. No shell, no network, no console to talk to. Xilinx\ncalls this stage FSBL and has Vitis generate it; U-Boot’s SPL is the same\nconcept, open, from one tree.
U-Boot is driver-model based: which UART, which GEM, which PHY address:\nall of it comes at runtime from a device tree compiled from\narch/arm/dts/zynq-ax7020.dts and appended to the binary. SPL gets its own\nheavily trimmed DTB, filtered from the same file by bootph-* properties.\n(The kernel later needs a separate device tree of its own; U-Boot’s\ndescribes only what U-Boot drives.)
Nothing in the file is guessed:
\n\ncompatible = \"alinx,zynq-ax7020\", \"xlnx,zynq-7000\";\nThe second string is what U-Boot’s Zynq drivers match on; the first is free.
\n\nmemory@0 { reg = <0x0 0x40000000>; };\nHWH: PCW_UIPARAM_DDR_PARTNO = MT41J256M16, 32-bit bus, 16-bit devices →\n2 × 512 MB = 1 GiB. Size only; bringing the DDR up is ps7_init’s job.
&clkc { ps-clk-frequency = <33333333>; };\nHWH: PCW_CRYSTAL_PERIPHERAL_FREQMHZ = 33.333333. Every derived clock\n(UART baud, QSPI, GEM) is computed from this one number.
aliases { serial0 = &uart1; };\nchosen { stdout-path = \"serial0:115200n8\"; };\nHWH: UART0 disabled, UART1 on MIO 48/49; schematic confirms the CP2102\nwiring. Without the alias, serial0 would land on the unpopulated UART0.
&gem0 {\n\tphy-mode = \"rgmii-id\";\n\tethernet_phy: ethernet-phy@1 { reg = <1>; };\n};\nHWH: ENET0 on MIO 16..27, MDIO on 52/53. Schematic: RTL8211E-VL. The PHY\naddress comes from strapping resistors and is not reliably readable from\neither source; ALINX’s own system-user.dtsi settled it at 1. rgmii-id:\nthe PHY inserts its own clock delays, standard for this chip.
&qspi {\n\tbootph-all;\n\tnum-cs = <1>;\n\tflash@0 {\n\t\tbootph-all;\n\t\tcompatible = \"w25q256\", \"jedec,spi-nor\";\n\t\treg = <0>;\n\t\tspi-rx-bus-width = <1>;\n\t\tspi-max-frequency = <50000000>;\n\t};\n};\nHWH: single flash on MIO 1..6, no dual/parallel; the ZC706 template’s\ntwo-chip setup had to go. Two lines here are paid for in blood:\nbootph-all on the flash node itself (detour 8) and\nspi-rx-bus-width = <1> instead of 4 (detour 9: quad read is broken in\nSPL on this board).
&sdhci0 { bootph-all; status = \"okay\"; };\n&uart1 { bootph-all; status = \"okay\"; };\nbootph-all marks what survives into the SPL DTB. GEM is absent there;\nSPL does no networking.
usb_phy0: phy0 { reset-gpios = <&gpio0 46 1>; };\nSchematic: PS_MIO46 → OTG_RESETN; HWH: active low. Not needed for Stage 1,\nbut correct.
\n\ngit clone https://source.denx.de/u-boot/u-boot.git && cd u-boot\ngit checkout 527115ef6783 # v2026.10-rc2\n# copy in the four files, add zynq-ax7020.dtb to arch/arm/dts/Makefile\nmake alinx_ax7020_defconfig\nscripts/config --disable TOOLS_MKEFICAPSULE # host tool wants gnutls\nmake olddefconfig\nmake -j$(nproc) CROSS_COMPILE=arm-none-eabi-\nProducts: spl/boot.bin (SPL + Xilinx boot header, 107 KB, what the\nBootROM loads) and u-boot.img (legacy uImage, ~1 MB, what SPL loads).
Checkpoint 3: verify the build before touching the board. All three\nchecks run on the host:
\n\ntools/mkimage -l spl/boot.bin # \"Image Type: Xilinx Zynq Boot Image support\"\ntools/mkimage -l u-boot.img # valid legacy uImage, load addr, size\nfdtget u-boot.dtb / model # \"Alinx AX7020 board\"\nfdtget spl/u-boot-spl.dtb /amba/spi@e000d000/flash@0 compatible\n # \"w25q256 jedec,spi-nor\": the SPL DTB\n # really contains the flash node (detour 8)\nIf any of these fails, nothing downstream can work, and unlike everything\ndownstream, these failures come with error messages.
\n\nThe board needs DHCP and somewhere to broadcast its console to. A USB\nEthernet adapter keeps it off the office LAN, and NetworkManager’s shared\nmode is a one-liner DHCP server (dnsmasq behind the scenes, NAT included).
Check for subnet collisions first. The lab subnet must not overlap with\nanything your machine already routes: the office LAN, VPN tunnels, Docker\nbridges. Two onboard commands show everything that is taken:
\n\nip -br -4 addr # every interface with its subnet\nip -4 route # every subnet the host routes, incl. VPN/Docker\nPick a /24 from RFC 1918 space that appears in neither list. Watch out for\nwide masks: a /16 on the LAN side occupies all 256 of “its” /24s, and\nDocker and NetworkManager both default into ranges (172.17+.0.0/16,\n10.42.0.0/24) that look free until they are not. Then:
\n\nnmcli connection add type ethernet ifname <usb-eth-if> con-name zynq-lab \\\n ipv4.method shared ipv4.addresses 192.168.77.1/24 ipv6.method disabled\nnmcli connection up zynq-lab\nHost = 192.168.77.1, DHCP range .10–.254. The board draws a random MAC each\nboot, so its address changes; find it with\nip neigh show dev <usb-eth-if>. The interface shows NO-CARRIER until\nU-Boot proper initialises the GEM; that is normal.
Two small host tools complete the setup (both in the repo, both plain\nPython, no root):
\n\ntools/tftpd.py tftp 6969: an unprivileged TFTP server; U-Boot is pointed\nat the port with setenv tftpdstp 6969.tools/ncsh.py <board-ip> \"bdinfo\": the netconsole shell. It exists because\nof two quirks handled inside it: U-Boot’s netconsole wants one input\ncharacter per UDP packet with a gap (it re-initialises the MAC around\nevery echo), and the USB NIC driver allocates ~16 KiB per received frame,\noverflowing the default socket buffer after ~13 packets unless a thread\ndrains it.Checkpoint 4: the lab network works without the board. All testable\nfrom the host alone:
\n\nip -br -4 addr show <usb-eth-if> # 192.168.77.1/24 on the interface\nip -4 route | grep 192.168.77 # route exists, only on that interface\npgrep -a dnsmasq | grep 192.168.77 # NetworkManager's DHCP server is up\necho hi | timeout 1 nc -u 192.168.77.1 6969; # tftpd.py logs the packet\nThe interface will show NO-CARRIER; the PHY link only comes up when\nU-Boot proper initialises the GEM. That is normal and not a failure of this\ncheckpoint. The board-side half of the test (a DHCP lease appearing in\njournalctl -u NetworkManager -f | grep -i dhcp) becomes checkpoint 5\nduring the bring-up.
Board cold, J13 on JTAG, one command:
\n\nopenocd -f openocd/ft232h.cfg -f target/zynq_7000.cfg -f openocd/load-uboot.cfg\nload-uboot.cfg plays BootROM and QSPI, and encodes four hard-won rules in\nits comments:
init\ntargets zynq.cpu0 ;# after halt the current target is often cpu1\nhalt\n\n# Stage 1: SPL into OCM (ps7_init: PLL, MIO, DDR)\nload_image build/.../spl/u-boot-spl.bin 0x0 bin\nreg pc 0x0\nresume\nsleep 3000\nhalt\ntargets zynq.cpu0\n\n# DDR sanity: write/read at the top of 1 GiB\nmww 0x3ffffffc 0xcafebabe\nmdw 0x3ffffffc 1\n\n# Stage 2: U-Boot proper into DDR, only while SPL (caches off) is halted\nload_image build/.../u-boot.bin 0x4000000 bin\nverify_image build/.../u-boot.bin 0x4000000 bin\nreg pc 0x4000000\nresume\n(SPL in JTAG mode finds no payload at 0x10000000, jumps into uninitialised\nDDR and traps at 0x40, which is expected; we halt it and hand over ourselves.\nverify_image is not optional; see detour 3.)
Then, on the host, nc -u -l 6666, or directly with ncsh.py, the small\nself-written netconsole shell from Step 4 (it lives in the repo’s tools/\ndirectory; plain Python, no dependencies):
tools/ncsh.py <board-ip> \"bdinfo\" \"sf probe 0 30000000 0\" \"mii info\"\nCheckpoint 5: a JTAG-loaded U-Boot answers over Ethernet. Three parts:\nthe DHCP lease appears in journalctl -u NetworkManager -f | grep -i dhcp\n(find the address with ip neigh show dev <usb-eth-if>), the netconsole is\ninteractive, and the three commands above return the right hardware:
DRAM bank size = 0x40000000\nSF: Detected w25q256 ... total 32 MiB\nPHY 0x01: OUI = 0x0732, Model = 0x11 ← RTL8211E at address 1\nDDR size, flash chip and PHY are the three things the DTS and ps7_init\nclaim about the board; this is where those claims meet reality.
Before overwriting anything, the full 32 MiB:
\n\ntftpd.py is the second self-written helper from tools/: an\nunprivileged TFTP server, so no root and no system service:
tools/tftpd.py tftp 6969 &\ntools/ncsh.py <ip> \"setenv tftpdstp 6969\" \"sf probe 0 30000000 0\" \\\n \"sf read 0x10000000 0 0x2000000\" \"md5sum 0x10000000 0x2000000\" \\\n \"tftpput 0x10000000 0x2000000 ax7020-qspi-factory.bin\"\nMD5 identical on board and host. The factory flash turned out to be blank\n(all 0xFF); ALINX ships the demos on SD card. Nothing was at risk, but\nyou only know that afterwards.
QSPI layout:
\n\n| Offset | \nContent | \n
|---|---|
0x000000 | \n boot.bin, what the BootROM loads | \n
0x100000 | \n u-boot.img, at CONFIG_SYS_SPI_U_BOOT_OFFS | \n
0xE00000 | \n environment (redundant copy at 0xE40000) | \n
Flashing: only from a U-Boot that was JTAG-loaded onto a freshly\npower-cycled board in JTAG mode (detour 7), and with the read-back\nverification that makes netconsole’s occasional lost characters (detour 6)\nsurvivable:
\n\ntools/ncsh.py <ip> \\\n \"tftpboot 0x10000000 boot.bin\" \"tftpboot 0x11000000 u-boot.img\" \\\n \"md5sum 0x10000000 <size_boot>\" \"md5sum 0x11000000 <size_img>\" \\\n \"sf erase 0 0x260000\" \\\n \"sf write 0x10000000 0 <size_boot>\" \\\n \"sf write 0x11000000 0x100000 <size_img>\" \\\n \"sf read 0x12000000 0 <size_boot>\" \"md5sum 0x12000000 <size_boot>\" \\\n \"sf read 0x13000000 0x100000 <size_img>\" \"md5sum 0x13000000 <size_img>\"\nSizes in hex: printf \"%x\\n\" $(stat -c %s tftp/boot.bin).
Checkpoint 6: the flash content is proven, not assumed. The read-back\nMD5 of both regions (0x12000000 / 0x13000000 above) must equal the\nhost’s md5sum of the files. Nothing counts as flashed until it does;\nthis is the only defence against netconsole’s occasional swallowed\ncharacters (detour 6) and it caught exactly one such case.
![\"Boot-mode](\"/assets/posts/alinx-bring-up-jtag-detected-without-power-august-2026/boot-mode-jumper-jtag.jpg\")
\n ![\"Boot-mode](\"/assets/posts/alinx-bring-up-jtag-detected-without-power-august-2026/boot-mode-jumper-qspi.jpg\")
\n JTAG cable off, J13 from JTAG to QSPI, power on.
\n\nCheckpoint 7: the board boots entirely on its own. Before the power\ncycle, start two watchers on the host:
\n\nsudo journalctl -u NetworkManager -f | grep -i dhcp # terminal 1: the lease\nnc -u -l 6666 # terminal 2: the console\nThen power on and check, in order:
\n\nboot.bin from QSPI, SPL\nran ps7_init and loaded u-boot.img from flash, U-Boot proper brought\nup the GEM and ran dhcp. Find the address with\nip neigh show dev <usb-eth-if> (it changes every boot, random MAC).The netconsole broadcast arrives in terminal 2, ending in the line\nthe bootcmd prints:
U-Boot 2026.10-rc2 (Aug 30 2026 - 20:25:52 +0200)\nmodeboot = qspiboot\nAX7020 netconsole ready\nmodeboot = qspiboot is the important word: U-Boot read the boot-mode\npins and confirms it was started from flash, not from a JTAG load.
tools/ncsh.py <ip> \"bdinfo\" \"sf probe 0 30000000 0\"\nmust return the 1 GiB DRAM bank and the W25Q256, the same two answers\nas over JTAG, now without any cable except Ethernet and power.If step 1 fails, SPL or the flash content is at fault and the board is\nmute; go back to the JTAG flow (Step 5) and check detours 8 and 9. If\nstep 1 works but step 2 stays silent, U-Boot runs and only the console\nconfig is wrong (detours 4–6).
\n\nStage 1 complete. The board boots an entirely open chain by itself, and the\nDHCP subnet on the USB adapter is already the foundation for Stage 2 (the\nimage server).
\n\nEverything above reads like an afternoon. It was not, and here is why,\nchronologically, because several detours only make sense in sequence.\nIf you bring up any Zynq board this way, expect to meet most of these.
\n\nAfter halt, OpenOCD’s current target is whichever core was last active,\noften cpu1. resume <addr> sets the PC only on the current target. First\nSPL run therefore happened on cpu1. Related trap: reg pc 0x0 + resume\ndoes not restart a CPU cleanly; every other register keeps its crashed\nstate; use the address form, and always targets zynq.cpu0 first.
Fix, as it ended up: load-uboot.cfg begins with targets zynq.cpu0\nimmediately after init, repeats it after every halt, and starts loaded\ncode with resume 0x0 / resume 0x4000000 (the address form) instead of\nsetting the PC and resuming. The script encodes it so it cannot be\nforgotten.
stdout=serial,nc silently ignoredWithout CONFIG_CONSOLE_MUX and CONFIG_SYS_CONSOLE_IS_IN_ENV, U-Boot\nignores the console environment entirely and writes to UART only. The board\npinged; the console did not exist.
Fix, as it ended up: two lines in alinx_ax7020_defconfig,\nCONFIG_CONSOLE_MUX=y and CONFIG_SYS_CONSOLE_IS_IN_ENV=y, plus the\nCONFIG_PREBOOT that sets stdin/stdout/stderr = serial,nc after DHCP.\nOnly with all three does output actually leave over UDP.
Reloading u-boot.bin while the previous U-Boot was halted with MMU and\nD-cache on: verify_image showed the DDR content wrong in 32-byte blocks:\none L1 cache line. Dirty lines from the old run were written back over the\nfresh image. Flush with zynq.cpu0 cache l1 d flush_all around the load, or\nbetter, load only while SPL (caches off) is halted. JTAG reads of DDR can\nlikewise return stale lines and fake a corruption.
Fix, as it ended up: the load sequence in load-uboot.cfg only ever\nwrites DDR while SPL is halted (SPL runs with caches off, so JTAG writes\nland in DRAM directly), and every load_image is followed by\nverify_image. For the rare case of reloading over a running U-Boot, the\nrepo README records the flush incantation\n(zynq.cpu0 cache l1 d flush_all before and after the load).
Since U-Boot 2026, lwIP is the default network stack, and\nCONFIG_NETCONSOLE exists only in the legacy one. olddefconfig dropped it\nsilently; the binary had not a single nc_* symbol. CONFIG_NET_LEGACY=y.
Fix, as it ended up: CONFIG_NET_LEGACY=y in the defconfig, which\nreplaces CONFIG_NET_LWIP and lets CONFIG_NETCONSOLE=y survive\nolddefconfig. Verification that the fix took:\narm-none-eabi-nm u-boot | grep nc_ must show the nc_* symbols, a\ncheck worth adding to the build checkpoint whenever the config changes.
In JTAG boot mode, distro_bootcmd loops forever through PXE/DHCP, and\nwhile U-Boot is inside a network operation, netconsole drops all output.\nPing worked, console stayed dark. A harmless\nCONFIG_BOOTCOMMAND=\"echo AX7020 netconsole ready\" drops to the prompt.
Fix, as it ended up: that CONFIG_BOOTCOMMAND line in the defconfig.\nIt replaces distro_bootcmd, prints one recognisable line and falls\nthrough to the prompt, which doubles as the success marker of\ncheckpoint 7. Once Stage 3 gives the board something real to boot, this\nplaceholder gets replaced by the actual boot command.
Output arrived truncated: the board sent ~92 packets, the socket received
\nUdpRcvbufErrors in nstat → the USB NIC driver allocates ~16 KiB per\nframe, the 208 KiB default buffer fills after 13 tiny packets. Input had the\nmirror problem: characters sent back-to-back arrive scrambled (vobfso for\nversion), because netconsole expects one character per packet, exactly\nwhat U-Boot’s own tools/netconsole script does with a delay. Both fixes\nlive in tools/ncsh.py. Residual risk: a mangled sf write becomes\nUnknown command and writes nothing. It happened once; the read-back MD5\ncaught it. Check the echo of every destructive command.Fix, as it ended up: both quirks are handled inside tools/ncsh.py:\na receiver thread with an enlarged buffer drains the socket continuously,\nand input goes out one character per packet with 0.4 s spacing. The\nresidual character-loss risk is covered by procedure, not code: the flash\nrecipe in Step 6 always reads back and compares MD5 before anything counts\nas written.
Writing PSS_RST_CTRL (0xF8000200) over JTAG to get a “clean slate”\nresets the debug logic too: cpu0 became unhaltable until a power cycle.\nSame family of mistake: after any QSPI-mode boot, ps7_init has already\nrun, and it is not idempotent: JTAG-loading and restarting SPL on such\na board crashes at ever-changing places (undefined instructions in\nuclass_find, alignment aborts in spi_nor_check_op) that cost an hour of\nbreakpoints before the pattern emerged. Rule: JTAG loading only on a board\nfreshly power-cycled with the jumper on JTAG. Flashing from a U-Boot that\nSPL had handed the QSPI controller to was equally poisoned: Written: OK,\nflash starting with zeros.
Fix, as it ended up: three procedural rules, written into\nload-uboot.cfg’s header comment so they travel with the script: (1) never\nwrite PSS_RST_CTRL from JTAG, because a power cycle is the only clean reset;\n(2) JTAG-load only onto a board freshly power-cycled with J13 on JTAG, so\nps7_init has not run yet; (3) flash only from a U-Boot that was\nJTAG-loaded in that state, never from one that SPL started out of QSPI.
bootph-all belongs on the flash node, not just the controllerFirst standalone QSPI boot: silence. The SPL DTB is produced by filtering on\nbootph-*; the filter keeps matching nodes and their parents, not their\nchildren. With the property only on the QSPI controller, flash@0 was\nmissing, and U-Boot 2026’s spi_find_chip_select() no longer has a\nfallback that binds a jedec_spi_nor without a DT node. SPL died in\nSPI probe failed., invisible without a console, and impossible to notice\nin the JTAG flow, where SPL never touches the flash.
Fix, as it ended up: bootph-all; inside flash@0 in\nzynq-ax7020.dts, in addition to the one on &qspi. Checkpoint 3 exists\nprecisely to catch this class of error on the host:\nfdtget spl/u-boot-spl.dtb /amba/spi@e000d000/flash@0 compatible must\nanswer w25q256 jedec,spi-nor before the board is touched.
The deepest one. With spi-rx-bus-width = <4>, QSPI reads inside SPL come\nback offset by 3 bytes. The image header is never recognised, SPL\nsilently falls back to its raw-image path and jumps into a uImage header.\nU-Boot proper does not show the fault: sf read + md5sum from the\nprompt happily verify a flash SPL cannot read, which sends the diagnosis in\nevery wrong direction first. Single-bit read (spi-rx-bus-width = <1>) is\ncorrect. Two neighbours from the same digging session:\n# CONFIG_SPL_STACK_R is not set (relocating the SPL stack to DDR produced\na corrupted stack pointer and alignment aborts, while plain JTAG memory\ntests of the same region pass) and # CONFIG_SPL_LOAD_FIT is not set (the\nSPL FIT loader placed the FDT at TEXT_BASE, so U-Boot executed a device\ntree; the legacy uImage path is one header parse plus one copy, and 24 KB\nsmaller).
The trick that cracked detour 9 deserves its own mention: instead of moving\nthe jumper and power-cycling for every attempt, two temporary patches made\nthe QSPI load path debuggable over JTAG: map ZYNQ_BM_JTAG to\nBOOT_DEVICE_SPI in arch/arm/mach-zynq/spl.c so SPL exercises the real\nflash path in JTAG mode, and have _spl_load() write its breadcrumbs\n(offset, size, read return, first words at the load address) into spare\nDDR at 0x3f000000. One run, read the breadcrumbs: offset = 0,\nsize = 0x32000, the raw-image fallback, with the uImage magic sitting at\nload_addr + 3. Revert both patches before building anything that gets\nflashed.
Fix, as it ended up: three config decisions that are all visible in the\nfinal DTS and defconfig: spi-rx-bus-width = <1> on flash@0 (single-bit\nread; slower, correct; U-Boot proper is unaffected because only SPL\nmisreads), # CONFIG_SPL_STACK_R is not set (SPL stack stays in OCM), and\n# CONFIG_SPL_LOAD_FIT is not set with u-boot.img built as a legacy\nuImage. Whether quad read can be fixed properly (dummy-cycle configuration\nfor the W25Q256 in the Zynq QSPI driver) is an open question for later;\nfor Stage 1, correctness beats speed.
Nine detours for four files and ~40 lines of config. None of the individual\nfacts was hard; what was hard was that almost every failure was invisible\n(no console yet), had multiple plausible causes, and sat in a different\nlayer than its symptom: a host socket buffer masquerading as a board\nproblem, a cache line masquerading as a flash problem, a device-tree filter\nmasquerading as an SPI driver problem.
\n\nAll self-written artefacts (the DTS, the defconfig, both OpenOCD configs\nand both host tools) are published at\ngithub.com/MaxClerkwell/ax7020-bringup,\nincluding a README that covers the build and the ps7_init extraction from\nthe vendor package.
The next step is Stage 3 of the plan: a Linux built for this board with\nYocto instead of PetaLinux, replacing the next vendor black box in the\nchain. The groundwork is already in place: U-Boot sits resident in QSPI, the\nlab network with DHCP and TFTP is running, and bootm is waiting for a\nkernel. (The image server of Stage 2 grows naturally out of the same lab\nnetwork along the way.) That build now has its own article:\na Yocto Linux in QSPI flash that fetches its own updates.
A while ago, Alinx reached out and asked whether I would like one of their boards for my content work. I said yes, and a few days later an AX7020 arrived on my desk. Full disclosure up front: the board is a sponsorship gift. Alinx has no say in what I write about it, and as you will see below, my plan involves ignoring most of the vendor-recommended workflow anyway.
\n\nThis article is not a tutorial. It is the concept post for a small series: what I want to build, why I want to build it that way, and where I expect things to get uncomfortable. The follow-up articles will document each stage as it actually happens, including the parts that fail.
\n\nThe AX7020 is built around a Xilinx Zynq-7020, which is a curious kind of chip. Half of it is an ordinary computer: two ARM Cortex-A9 cores, a DDR3 controller, Gigabit Ethernet, USB, SD, UART. Xilinx calls this half the PS, the Processing System. The other half is FPGA fabric, the PL or Programmable Logic, sitting on the same die and wired to the processor through a set of AXI ports.
\n\nIf you have read my introduction to FPGAs, you know that I think of an FPGA as a grid of configurable logic with a routing fabric between the cells. The Zynq takes that grid and bolts a Linux-capable computer onto it. That combination is the whole point of this project. The ARM side runs a normal operating system with a network stack, and the FPGA side is available as a resource that the operating system can reconfigure at runtime, in well under a second, as often as it likes.
\n\nRead that again, because it is the core idea: the processor can rewrite the hardware next to it while running. Most people program FPGAs the way we programmed microcontrollers in the nineties, with a cable and a vendor tool and a ritual. The Zynq allows something much closer to modern software deployment. Nobody walks to a server with a JTAG probe to update a web service. You push an artifact to an endpoint and the system takes it from there.
\n\nSo that is the goal I am committing to in writing:
\n\nA REST API running on the board itself. You POST a bitstream to it, and the FPGA next to the processor starts executing your design.
\n\nIf that sounds familiar, it is because AWS sells exactly this. Their F1 and F2 instances are servers with datacenter-grade FPGAs attached: you upload your design through an API, AWS loads it into the fabric, and your software talks to your custom hardware over PCIe. What I am building is the same idea shrunk from a datacenter rack to a 15-watt board on my desk, with one difference that matters to me: on AWS, every layer between your design and the silicon is proprietary and invisible. Here, every layer will be open and inspectable.
\n\nDeploying hardware like software. curl -T design.bin as the last step of a hardware CI pipeline.
Between an unboxed board and that API sit five stages. Each one is a natural checkpoint, and each one will get its own article.
\n\nThe Zynq-7000 boot ROM knows four boot sources: JTAG, QSPI flash, NAND, and SD card. What it does not know is USB, so there is no magic first contact over a USB cable like on more modern chips. The first code on this board will therefore arrive over JTAG.
\n\nThe usual path here is the Xilinx FSBL, the First Stage Boot Loader that Vivado generates for you. I am not taking that path. Mainline U-Boot has an SPL mode that replaces the FSBL entirely: a small first stage that initializes the DDR controller, the clocks, and the pin multiplexing, then loads the full U-Boot. The board-specific knowledge, which DDR chips are soldered down and which pins go where, lives in a generated file called ps7_init_gpl.c that can be extracted from the vendor’s hardware description without ever starting Vivado. Alinx publishes their reference design on GitHub, and the file is sitting inside the XSA archive, which turns out to be a plain zip.
Mainline U-Boot has never heard of the AX7020, so this stage involves teaching it about a board it does not know: adapting a device tree from a close relative like the ZedBoard and feeding the SPL the correct initialization data for this specific board. How that goes in practice, including whatever friction the vendor tutorials do not mention, is now documented in its own article: ALINX AX7020 Bring-up: Mainline U-Boot Over JTAG, No FSBL, No Serial Cable.
\n\nCheckpoint for this stage: a U-Boot prompt on the serial console, bdinfo reporting 1 GB of DDR, and the QSPI flash answering to sf probe. Once that works, U-Boot gets written to the QSPI flash and the JTAG cable goes back in the drawer. Everything after this point happens over the network.
U-Boot can fetch files over TFTP, and the Ethernet port of the AX7020 hangs directly off the processor side, so it works without any FPGA configuration at all. The plan is classic network boot, the same pattern that diskless workstations used thirty years ago: the board comes up, U-Boot asks the network for a kernel and a root filesystem, and boots what it receives.
\n\nThat requires infrastructure on my side, a small image server: TFTP for U-Boot, plus something to serve rootfs images. This is deliberately part of the project rather than an annoyance. If the endgame is treating hardware deployment like software deployment, then the boot images themselves should also come from a server I can push to, not from an SD card I have to carry around. The UART stays connected during all of this as the rescue line; serial consoles are to embedded bring-up what stack traces are to software.
\n\n(Spoiler from the future: this stage did not survive contact with a managed switch in its planned form. What actually happened is in the Stages 2 & 3 article.)
\n\nWith netboot working, the board needs a proper operating system. PetaLinux, the vendor’s offering, is a wrapper around Yocto, so I will skip the wrapper and use Yocto directly with the meta-xilinx layer, mainline kernel, mainline U-Boot. The Zynq-7000 is mature enough to be genuinely well supported upstream; the Ethernet controller, the SD controller, and, crucially for this project, the FPGA configuration interface all have mainline drivers.
\n\nHow this stage actually went, including a flash bug that defeated every checksum and a switch that silenced U-Boot for good, is documented in ALINX AX7020, Stages 2 & 3: A Yocto Linux in QSPI Flash That Fetches Its Own Updates.
\n\nThe one feature this Linux absolutely must have is the kernel’s FPGA manager framework. On the Zynq, the processor configures the FPGA fabric through an internal port called PCAP, and the mainline zynq-fpga driver exposes it in sysfs. Loading a new hardware design then degenerates into writing a filename into a sysfs node. No cable, no vendor tool, just a file write that any process with the right permissions can perform.
Now the FPGA side. The Zynq-7020 is a 7-series device, which means it is covered by the openXC7 flow: Yosys for synthesis, nextpnr-xilinx for place and route, on top of the Project X-Ray database that documents the bitstream format. I wrote about reverse-engineering bitstreams before; this project is where that world becomes daily practice, because the entire pipeline from HDL to configured silicon will run without a single proprietary tool.
\n\nI want to be honest about expectations here. The open 7-series flow works, but it is not Vivado. Timing analysis is rudimentary and some hard blocks are awkward to use. For this stage the design will be deliberately boring, a blinker or a counter on AXI, because the design is not the point. The point is the pipeline: synthesize on my desk, scp the bitstream to the board, log in over SSH, write it into the FPGA manager, watch the LED blink. The moment that works, the full loop exists, and every piece of it is open source.
The final stage removes the human from stage 4. A small service on the board, probably a few hundred lines, accepts a bitstream over HTTP, validates it, hands it to the FPGA manager, and reports back whether the fabric came up.
\n\nValidation is the part I refuse to hand-wave. A bitstream is arbitrary hardware configuration. The service will at minimum check the sync word and the device IDCODE so that only bitstreams built for this exact chip get loaded, and the endpoint will be authenticated. There is also a sharper issue lurking here: a design containing an AXI master has full access to system memory, DMA-style. An API that loads unreviewed bitstreams is remote code execution with extra steps, hardware edition. For my lab that is an acceptable and clearly labeled risk. For anything beyond a lab it is the reason AWS wraps every customer design on their FPGA instances in a fixed shell that polices its memory access. Knowing that this problem exists, and understanding why the cloud providers solved it the way they did, is half the educational value of building the small version.
\n\nA fair question. Alinx ships a working reference image; I could have the board on the network in an afternoon by flashing a card and following the manual.
\n\nBut my interest in this board is not the destination, it is the supply chain. Every stage of this plan replaces a vendor black box with an inspectable component: SPL instead of FSBL, Yocto instead of PetaLinux, Yosys and nextpnr instead of Vivado, sysfs instead of a programming cable. At the end, every byte that reaches this chip, from the first DDR register write to the configuration frames in the FPGA fabric, will have come out of a toolchain I can read the source of.
\n\nThat is worth something on its own. It is worth more as content, because the failures along the way are precisely the material that vendor documentation cannot provide.
\n\nThe board is on my desk, and stage 1 is done: building mainline U-Boot for a board that mainline has never heard of documents the whole bring-up, checkpoints and detours included.
\n\nProjects like this one are what I do professionally. I work as a freelancer on embedded systems: microcontroller firmware, PCB design, FPGA development, board bring-up, and the toolchains and infrastructure around them. If you have a project in that space, from “we need a prototype” to “our vendor toolchain is holding us hostage”, get in touch.
\n\nAnd if you just want to talk shop: I am regularly around on my Full Stack Engineering Discord, where we discuss everything from tape-out to JavaScript. Come say hi.
\n\n", "date_published": "2026-08-23T00:00:00+00:00", "date_modified": "2026-08-23T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["fpga","embedded","linux","open-source"] }, { "id": "https://maxclerkwell.tech/posts/orbitals-to-bands-august-2026/", "url": "https://maxclerkwell.tech/posts/orbitals-to-bands-august-2026/", "title": "Why Does Copper Conduct? A Tour for Non-Physicists", "summary": "Copper conducts, diamond doesn't, yet both are packed with electrons. A walk from single atoms to energy bands that explains why, ending with a back-of-the-envelope number that lands within ten percent of the measured conductivity of copper.", "content_html": "I recently finished a small paper that derives the electronic structure of solids step by step, aimed at first-year physics students. This post is the version without the mathematics: the story you can follow on a train ride. If you want the full derivations, the paper is linked at the end.
\n\nWhy does copper conduct electricity and diamond doesn’t?
\n\nThe answer you probably learned in school, “metals have free electrons”, is not wrong, but it quietly dodges the real question. A gram of diamond contains roughly as many electrons as a gram of copper. Nobody nailed them down. So why are the electrons in copper “free” and the ones in diamond not? What, physically, is the difference?
\n\nIt turns out the answer has nothing to do with electrons being loose or stuck. It has to do with seating.
\n\nQuantum mechanics makes one claim from which everything else follows: an electron bound to an atom cannot have just any energy. It can sit on step one, step two, step three, but never in between. The energy landscape of an atom is a staircase, not a ramp.
\n\n![\"Discrete](\"/assets/posts/orbitals-to-bands-august-2026/fig_atom_levels.png\")
On top of that comes a rule with enormous consequences, the Pauli principle: each step seats at most two electrons. Electrons fill the staircase from the bottom, two per step, and then the box office closes.
\n\nBring two atoms close together and something curious happens. An electron that belonged to one atom starts to notice the neighbor. Quantum mechanics allows it to tunnel across, and once the two atoms are close enough, the honest description is no longer “an electron at atom A” or “an electron at atom B” but a wave spread out over both. There are two ways to build such a shared wave: a smooth way, and a way with a kink in the middle. Kinks cost energy. So every single step of the staircase splits into a pair of steps, one slightly lower (the smooth, “bonding” arrangement) and one slightly higher (the kinked, “antibonding” one).
\n\n![\"Bonding](\"/assets/posts/orbitals-to-bands-august-2026/fig_bonding_antibonding_nodes.png\")
That’s it. That is the entire mechanism. The rest is repetition.
\n\nA crystal is not two atoms but something like $10^{23}$ of them. Each original step now splits $10^{23}$ ways. The resulting levels are spaced so absurdly finely, roughly $10^{-23}$ electron volts apart, that they stop being steps at all. They blur into a continuous band of allowed energies. Between the bands there may remain forbidden zones, so-called band gaps, where no electron can sit, period.
\n\n![\"From](\"/assets/posts/orbitals-to-bands-august-2026/fig_band_formation.png\")
So the energy landscape of a solid looks like a layer cake: bands of allowed energies, separated by gaps of forbidden ones. Now pour in the electrons, from the bottom, two per seat, exactly as in the single atom. Where the filling stops is called the Fermi level. And here is the punchline of the whole story:
\n\nA completely full band carries no current.
\n\nConducting means accelerating. An electron gains a tiny bit of energy from the applied voltage and moves to a slightly higher seat. In a full band there is no empty seat to move to, so every microscopic push is forbidden. The electrons are not stuck to their atoms; they are stuck in a fully booked theater. They can, in a quantum mechanical sense, move through the whole crystal, but for every electron drifting to the left there is a mirror partner drifting to the right, and the net current is exactly zero. A voltage cannot tip that balance, because tipping it would require moving someone to a free seat, and there is none.
\n\nTwo of these bands matter so much that they have names, and it is worth being precise about them.
\n\nThe valence band is the highest band that is (essentially) fully occupied. Its name is no accident: it is formed from the outermost atomic orbitals, the valence orbitals, the same electrons that chemistry uses for bonding. These electrons are doing a job. In diamond, every valence electron is part of a carbon-carbon bond, and the valence band being full is just the band-picture way of saying “all bonds are saturated”. Full band, fully booked theater, no current.
\n\nThe conduction band is the next band above it, and in an insulator or semiconductor it is (essentially) empty. An empty band carries no current either, for the trivial reason that there is nobody in it. But it is empty and has seats, and that combination is the key. Any electron that makes it up there has free seats in every direction and can be accelerated by even the smallest voltage. It behaves like the “free electron” from the school answer.
\n\nBetween the two lies the band gap, and the entire electrical character of a material hangs on this one number:
\n\n![\"Metal,](\"/assets/posts/orbitals-to-bands-august-2026/fig_band_types.png\")
It is worth pausing on how lopsided this lottery is. Temperature does not gently warm up all electrons; it only rattles the ones sitting within about $k_B T \\approx 0.025$ electron volts of the Fermi level. For an electron to cross a gap of 1.1 electron volts, dozens of these thermal portions have to pile up on one electron at the same moment, which is possible but rare, roughly a one-in-$10^{9}$ affair in silicon at room temperature. That is why the number of carriers in a semiconductor depends exponentially on the gap size and the temperature. Small changes have dramatic consequences: warm silicon up by a few tens of degrees and its conductivity multiplies, which is also why semiconductor circuits care so much about staying cool.
\n\nThe carrier density can also be engineered instead of left to thermal luck: doping, the deliberate sprinkling-in of foreign atoms, plants extra electrons just below the conduction band or extra holes just above the valence band. Controlling the carrier density this way, region by region, is the entire trick that diodes, transistors, and every chip in your pocket are built on.
\n\nA story like this should be checkable. It is. The model gives a formula for conductivity, $\\sigma = n e^2 \\tau / m$: carrier density $n$, electron charge $e$ and mass $m$, and the average time $\\tau$ between collisions with the vibrating crystal lattice. The formula tells a simple story: the voltage accelerates each carrier, a collision with a lattice vibration or a defect wipes out the gained speed after a time $\\tau$ on average, and the resulting steady drift, multiplied by how many carriers there are, is the current. Between a metal and an insulator, $\\tau$ and $m$ differ only by modest factors. What differs by more than twenty orders of magnitude is $n$, which is why the seating chart, and not some property of the individual electrons, decides everything.
\n\nFor copper, the band picture makes a sharp prediction about $n$, and it is more interesting than it first sounds. A copper atom brings 29 electrons. The inner 18 sit in compact orbitals close to the nucleus; neighboring atoms are simply too far away for these orbitals to overlap, so their levels never broaden into bands worth the name, and their electrons stay home. The next ten fill the so-called d orbitals, which do overlap and do form bands, but those bands offer exactly ten seats per atom and copper delivers exactly ten electrons: completely full, and by now we know what a full band means. That leaves precisely one electron per atom, the outermost one, in a wide, half-full band. Twenty-eight spectators, one player. From copper’s density and molar mass, that yields $n \\approx 8.5 \\times 10^{28}$ conduction electrons per cubic meter. With the measured collision time $\\tau \\approx 2.5 \\times 10^{-14}\\,\\mathrm{s}$:
\n\n\\[\\sigma = \\frac{8.5\\times10^{28} \\times (1.60\\times10^{-19})^2 \\times 2.5\\times10^{-14}}{9.11\\times10^{-31}}\\,\\frac{\\mathrm{S}}{\\mathrm{m}} \\approx 6\\times10^{7}\\,\\frac{\\mathrm{S}}{\\mathrm{m}}.\\]\n\nThe measured value is $5.96\\times10^{7}\\,\\mathrm{S/m}$. A staircase, a splitting rule, and a seating chart, and the number comes out right to within a few percent.
\n\nEverything I hand-waved here, where the staircase comes from, why kinks cost energy, how the bands and the Fermi level are actually computed, is derived explicitly and with historical sources in the paper: From Atomic Orbitals to Energy Bands. The repository builds the PDF automatically, and all figures are generated from a single Python script. If this post made you curious, that is the next step of the staircase.
\n\nYou can read the paper right here:
\n\n\n\n\n \n ⬇️ Download the paper (PDF)\n \n
", "date_published": "2026-08-21T00:00:00+00:00", "date_modified": "2026-08-21T00:00:00+00:00", "image": "https://maxclerkwell.tech/assets/posts/orbitals-to-bands-august-2026/fig_band_formation.png", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["physics","education"] }, { "id": "https://maxclerkwell.tech/posts/digital-communication-august-2026/", "url": "https://maxclerkwell.tech/posts/digital-communication-august-2026/", "title": "Digital Communication: Getting a Thought Out of One Head and Into Another", "summary": "Communication has one job: move the internal state of one system into another. This is a walk from a thought in your head to a wave on a wire, through the four sides of a message, a water canal, a push-pull driver, Shannon's channel, and the eye diagram that measures it all.", "content_html": "Communication has exactly one job. Everything else about it, the words, the wires, the protocols, the noise, is machinery in service of that one job.
\n\nYou have a model in your head. It has no clean shape. It is made of pictures, feelings, memories, half-formed intentions, a smell from last summer, a plan for tomorrow. It is entirely yours, and as long as it stays inside you it is useless to anyone else.
\n\nThe moment you want to cooperate, that changes. Cooperation means two systems acting on a shared understanding, and a shared understanding requires that the model in your head somehow also come to exist in someone else’s. If we rule out telepathy for the moment, the only thing you can do is take that internal, shapeless state and push it out through whatever channels you have available so that another person can pick it up and rebuild a copy of it inside themselves.
\n\nThis is the mandate, and it never changes: move the internal state of one system into another. Hold on to that sentence. Every layer we add from here, human or electronic, is just a different way of carrying it out.
\n\nAs humans we have a rich set of tools for the job: words, gestures, facial expressions, hand signals, sounds, drawings, music. What all of them have in common is that they are ways of serializing a model. Your inner state is high-dimensional and parallel; a channel is narrow and mostly sequential. So you flatten the model, stream it out symbol by symbol over the channels you have, and trust that the receiver on the other end can take that stream and reconstruct the state inside their own head.
\n\nNow look at a microcontroller, and you will find the identical problem wearing different clothes.
\n\nInside my program I have a data structure. Maybe it holds a measured state: a temperature, a set of flags, a timestamp. It lives in memory as a particular arrangement of bits, meaningful only inside this one processor. If a second processor is to act on that measurement, the arrangement has to be reproduced over there.
\n\nSo a driver takes the structure, serializes it into a stream of symbols, and imprints that stream onto a bus. On the far side, another processor with the matching bus receivers picks the stream back up and reconstructs the structure in its own memory. Sender, serialization, channel, reception, reconstruction. It is the same five steps, and it is the same mandate. A person talking and a chip driving a bus are solving one problem at two scales.
\n\nHuman communication theory noticed long ago that a single message is never just its literal content. Paul Watzlawick and, in more structured form, Friedemann Schulz von Thun described a message as having four sides at once. The interesting thing is that all four reappear, almost one to one, in a digital bus frame.
\n\nThe fourth side is the one that is most obvious in hindsight, because it is the part we usually think is the whole message: the factual content (Sachinhalt). It is the raw payload, the number, the data field itself. Strip away who is sending it, what they want done with it, and the machinery that proves the frame’s integrity, and there is still a bare fact being conveyed. In a bus frame it is simply the data bytes sitting between the header and the checksum.
\n\nFour sides in a human sentence, four fields in a frame. The overhead you see wrapped around every payload on every serious bus is not bureaucracy; it is the electronic version of tone, stance, and intent riding along with the words.
\n\nNone of this moves without a physical channel: something the sender can modulate and the receiver can sense.
\n\nTake air pressure. With my breath, my vocal cords, and the shape of my mouth and throat, I set the air vibrating in specific patterns. Those pressure waves travel outward, and the receiver’s eardrum vibrates in sympathy. First the ear filters the signal physically, by mechanical resonance, and only then do circuits in the brain get to work, unpacking the pattern step by step and in parallel until a meaning falls out.
\n\nNow push the sender and receiver so far apart that they can no longer see or hear each other directly. The channel of open air gives out. What can we do?
\n\nOne option is to guide the physical excitation instead of letting it spread. Speak into a long pipe, and the pressure wave, instead of dissipating in every direction, propagates along the tube and arrives with far more of its energy intact. The speaking tube on old ships is exactly this idea.
\n\nHere is a stranger alternative that makes the underlying principle unmistakable. Run a long water canal from sender to receiver. Before we start, both parties agree on a protocol, a contract that says what the signal will mean. Now the sender pours a bucket of water into their end. A wave travels down the canal, and after a while the level at the receiver’s end rises. Or the sender scoops water out, and after a while the far level drops.
\n\nTwo states, level-up and level-down, look like almost nothing. But if the protocol is good enough, two states are plenty. The trick is to stop trying to send whole complex symbols at once, and instead serialize each symbol into a chain of these tiny information units. We invent new, coded symbols: agreed sequences of highs and lows that stand for the larger pieces of meaning. BCD is one such scheme, four level-changes standing in for one decimal digit. Give me a reliable two-state channel and a code, and I can send you anything.
\n\nSwap the water canal for an electrical conductor and the picture snaps into focus as a real digital bus.
\n\nNow the sender is a push-pull stage. To send “high” it floods the line with electrons; to send “low” it pulls them back off. On the receiving end a comparator with a fixed threshold decides, at each moment, whether the level is above or below the line, and reconstructs the stream of highs and lows. Push-pull and comparator are just the bucket and the water-level gauge, moving far faster.
\n\nAnd the same subtleties survive the translation. The signal still takes time to arrive: a wave has to propagate down the wire, exactly as it did down the canal. More surprising, and worth sitting with: the information does not really travel inside the wire. The conductor only guides it. The signal is a field arrangement around and along the line, and the wire is a rail that keeps that arrangement aimed at the receiver.
\n\nYou can tell this is true precisely because it can be disturbed from outside. On a high-speed bus, a neighboring line’s switching field couples into yours, and you get crosstalk. A “loud” switching voltage regulator sitting nearby can inject enough of its own field to make a clean signal hard to read. Back in the world of our speaking pipe, the equivalent is a diesel generator the pipe happens to run past: it radiates its own noise straight into the channel, and now the receiver has to separate your words from the engine. The channel was never sealed. It was only ever guided, and anything that can reach the guide can add to the signal.
\n\nIn 1948, Claude Shannon gave this whole story its canonical diagram, and everything above is a retelling of it. His model is a straight line of five boxes with one arrow coming in from the side:
\n\ninformation source → transmitter → channel → receiver → destination, with a noise source injecting into the channel.
\n\nMap it onto what we already built and it lines up exactly. The information source is the model in your head, or the struct in memory. The transmitter is your vocal tract, or the push-pull driver, doing the serialization and modulation. The channel is the air, the pipe, the canal, the wire. The receiver is the ear, or the comparator. The destination is the reconstructed model in the other head, or the reconstructed struct in the other processor. And the noise source, entering at the channel and nowhere else, is the diesel generator, the crosstalk, the loud regulator.
\n\nShannon’s real contribution was to make this quantitative. He showed that a channel with bandwidth $B$ and a signal-to-noise ratio $S/N$ has a hard ceiling on how many bits per second you can push through it error-free:
\n\n\\[C = B \\log_2\\!\\left(1 + \\frac{S}{N}\\right).\\]\n\nRead that formula against everything so far and it says something almost obvious in hindsight. Your throughput is bounded by how fast you can wiggle the channel ($B$) and by how far your signal stands above the noise ($S/N$). The diesel generator does not just annoy you; it lowers $S/N$ and, with it, the number of bits the channel can ever carry. Noise is not a nuisance layered on top of communication. It is one of the two terms that decide what communication is even possible.
\n\nStep back and the arc is simple. Communicating a message is how the internal representation of one processor, silicon or biological, is transferred into another. But the channel alone is not enough. A wire, a canal, or a column of vibrating air only carries meaning if both ends run the same protocol: the same conventions, the same agreement about which pattern stands for what. Without that shared contract the signal arrives perfectly intact and means nothing. The physics delivers the envelope; the protocol is what lets the receiver open it. And the channel is never private either: disturbances can always couple in, and they set a ceiling on what can get through.
\n\nThere is a beautiful last move here. Because all of this is content-independent, we can judge the quality of a link without caring what it is saying.
\n\nPut an oscilloscope on the line and overlay every received symbol period on top of each other, aligned to the clock. The individual bits blur together into a shape called an eye diagram: a bright open region in the middle, framed by the tangle of rising and falling edges. That open “eye” is the margin the receiver has to work with. A wide, tall eye means the comparator can pick high from low with room to spare. A collapsing eye, edges smeared by crosstalk, levels pulled together by a noisy regulator, jitter blurring the timing, means the receiver is being asked to decide in a shrinking window, and errors are coming.
\n\nThe elegance is that none of this depends on the payload. You are not reading the data; you are measuring the shape it leaves behind. Content-independent quality metrics, jitter, noise margin, eye height and width, let you say how good a channel is before you have decoded a single meaningful bit through it. It is the same physical mandate we started with, now turned into something you can put a number on and watch on a screen.
\n\nThis is exactly what I showed in a couple of short Instagram videos, if you want to see a real eye diagram open and close on a scope instead of just reading about it:
\n\nCommunication had exactly one job. From a thought in your head to a wave on a wire, it never stopped being the same job.
", "date_published": "2026-08-21T00:00:00+00:00", "date_modified": "2026-08-21T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["electronics","embedded","information-theory","education"] }, { "id": "https://maxclerkwell.tech/posts/dual-uplink-load-balancing-july-2026/", "url": "https://maxclerkwell.tech/posts/dual-uplink-load-balancing-july-2026/", "title": "Dual Uplink, Part Two: From Failover to Load Balancing (and the Two Bugs That Broke It)", "summary": "The follow-up to our dual-uplink failover setup: weighted multipath load balancing, source-based policy routing, pinning a host to one link, and the two persistence bugs that silently killed it on every reboot.", "content_html": "Back in February, Philipp and I put a second uplink into the office and built dual-uplink failover on AI-heimdall: two default routes in the main table, separated by metric, DSL preferred and Starlink as a hot standby. That article ended on a promise. Two named routing tables, starlink (200) and dsl (201), were already registered in /etc/iproute2/rt_tables, sitting there unused, “as preparation for proper policy routing.” This is the article where they get used.
The move from failover to load balancing sounds like a small config change. It is not. Failover is one route winning; load balancing is every layer of the stack agreeing on which uplink a given packet leaves through. And getting it to survive a reboot turned out to hinge on two bugs that had nothing to do with routing at all.
\n\nMetric-based failover has a property that is great for a first deployment and useless for a busy office: only one link ever carries traffic. The lower-metric route wins completely, and the other one is a cold spare the kernel only touches when the primary disappears. We had resilience, but on a normal day all fifteen people were still crammed onto DSL while a perfectly good Starlink link sat idle.
\n\nLoad balancing is a different construct entirely. Instead of two default routes ranked by metric, you write one default route with multiple weighted next-hops:
\n\nip route replace default \\\n nexthop via 192.168.1.1 dev eno2 weight 2 \\\n nexthop via 192.168.99.1 dev eno1 weight 1\nThat is eno2 (Starlink) and eno1 (DSL) both carrying traffic at the same time, split roughly 2:1. One route, two next-hops, weights proportional to how much I want each link to shoulder.
The first thing to get straight, before anyone gets excited about “combined bandwidth,” is what multipath actually balances. Modern kernels hash the route by flow, using the layer-3 and layer-4 headers, not per packet. A single TCP connection is pinned to one uplink for its whole life; conntrack keeps established flows on the path they started on. Balancing happens across connections, not within one.
\n\nSo weight 2:1 means about two thirds of new connections go to Starlink, not two thirds of any single download’s packets. You cannot bond one connection’s bandwidth across two links this way. A single large git push rides one uplink at that uplink’s speed. What you gain is that fifteen people’s fifteen-plus connections spread out instead of stacking. For an office, that is exactly the win you want; for a single giant transfer, it does nothing, and it is better to say so up front than to field the “why isn’t my download twice as fast” question later.
A working multi-uplink router is four separate things, and leaving any one out produces a failure that looks like something else:
\n\nnet.ipv4.ip_forward=1. Obvious, and the source of bug number one below.iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE\niptables -t nat -A POSTROUTING -o eno2 -j MASQUERADE\nThis is the sneaky one. With failover there was only ever one active egress, so one masquerade rule was enough. The moment the multipath route starts sending some flows out the second uplink, those flows leave with un-rewritten internal source IPs, the upstream discards them, and you get the classic “half my connections just don’t work” symptom with nothing obviously wrong in the routes.
\nip route replace default via 192.168.99.1 dev eno1 table dsl\nip route replace default via 192.168.1.1 dev eno2 table starlink\nip rule add from 192.168.99.2 table dsl\nip rule add from 192.168.1.248 table starlink\nThat fourth piece is not optional polish, and it is the part people skip when they think “I only want load balancing.” Multipath handles traffic forwarded through the router. But the router itself, and any connection arriving at one of its uplink IPs, must reply out the same uplink the request came in on. Without a source rule, the router’s own reply follows the multipath default and can leave via the other uplink. That is asymmetric routing, and stateful firewalls plus rp_filter drop it on sight. The per-uplink tables and source rules are what make both links usable in both directions.
We have a concrete reason for this, not a hypothetical one. One machine talks to a license server that verifies against our public IP, and for that verification to work we had to arrange a static IP with the provider. That static IP lives on the DSL line. So the machine that connects to the license server must always egress via DSL; if load balancing ever sent its verification traffic out Starlink, it would arrive from the wrong public address and the check would fail. Failover never had this problem because everything used DSL anyway. The moment traffic started spreading across both links, that one host had to be nailed down.
\n\nAn ip rule with a lower priority number than the general source rules gets evaluated first:
ip rule add from 10.42.100.50 table dsl priority 100\nThe mental model is a walk down the rule list in priority order, low number first. A host-pin rule at priority 100 catches that machine’s forwarded traffic and hands it straight to the dsl table’s default route, before the weighted multipath default is ever consulted. Everything else falls through to main and gets split by flow-hash. Rule, then route, then NAT: every layer has to name the same uplink, or the flow breaks somewhere in the middle.
Here is the honest order of events, because it is why I touched a working configuration at all. The trigger was not ambition, it was the power going out. We had planned maintenance work that cut the electricity, so AI-heimdall went down and came back up on its own. And when it came back, it did not come online the way I wanted: the office was not routing as expected. Only then, with the router misbehaving after an unplanned reboot, did I sit down and dig into what was actually persisting across boots and what was not. That is when the two hidden problems surfaced.
\n\nRuntime ip, iptables, and sysctl state is ephemeral, which I knew; what I did not expect was that my careful persistence setup was being defeated by two unrelated traps.
/etc/sysctl.conf was being ignoredip_forward was set in /etc/sysctl.conf, and after every boot it was back to 0, so no traffic was forwarded at all and the whole thing looked dead. The cause has nothing to do with routing. systemd-sysctl reads /etc/sysctl.d/*.conf, /run/, and /usr/lib/, but it only picks up /etc/sysctl.conf through the conventional symlink /etc/sysctl.d/99-sysctl.conf -> ../sysctl.conf. On this box that symlink was missing, so the file was silently skipped at boot and I had been setting forwarding by hand without realising it. The fix is to stop relying on the symlink and drop a real file into the directory:
printf 'net.ipv4.ip_forward=1\\n' > /etc/sysctl.d/99-heimdall.conf\nThe second one is nastier because it is a race. The routing script runs as a systemd oneshot ordered After=network-online.target. But the Starlink interface is DHCP and marked allow-hotplug rather than auto, and with ifupdown a hotplug interface is not waited on by network-online.target. So the oneshot fired before the DHCP lease arrived, ip route ... nexthop via <dhcp-gw> failed with “Nexthop has invalid gateway,” and because the script runs under set -e, the whole setup aborted. A oneshot does not retry, so load balancing stayed dead until the next manual run.
The fix is belt and suspenders:
\n\nip route show dev eno2 | grep <subnet> with a timeout around 60 seconds), so the oneshot no longer races the lease./etc/network/if-up.d/, so it re-runs whenever the Starlink link comes up or renews its lease. This second hook matters for more than boot: a DHCP renewal happily reinstalls a plain default route that clobbers the multipath one, and the if-up.d hook is what puts it back.While hardening the setup, two smaller things bit and are worth writing down.
\n\nDo not mix nft and iptables for NAT. If nft list table ip nat warns that the table is “managed by iptables-nft, do not touch,” add masquerade rules with iptables -t nat, not nft add rule. Against an iptables-nft-managed chain, nft add rule ... masquerade fails with a baffling “No such file or directory.” Persist the result with netfilter-persistent save, which writes /etc/iptables/rules.v4.
ip rule add never deduplicates. It inserts a new entry every time, even if an identical rule already exists, so re-running the setup script quietly accumulates duplicate rules. Delete-then-add makes it idempotent:
while ip rule del from 192.168.1.248 table starlink 2>/dev/null; do :; done\nip rule add from 192.168.1.248 table starlink\nThe one command that made all of this debuggable is curl --interface, which forces egress from a given source address, which hits that address’s source rule, which selects that uplink:
curl --interface 192.168.1.248 https://ifconfig.co # Starlink's public IP\ncurl --interface 192.168.99.2 https://ifconfig.co # DSL's public IP\nTwo distinct WAN addresses come back, proving each path reaches the internet on its own. Combined with the Python dashboard from the first article, it is easy to confirm at a glance that traffic is actually spreading across both links instead of quietly collapsing onto one.
\n\nFailover was the safe version: one link at a time, automatic backup, nothing clever. Load balancing is the version that actually uses the capacity we pay for, and it demands that forwarding, per-uplink NAT, the weighted multipath route, and source-based rules all agree on the same uplink for every packet. The routing was the easy part. Making it survive a reboot came down to a missing sysctl symlink and a DHCP interface that was not ready when the script assumed it was. The durable setup is a real file in /etc/sysctl.d/, NAT via netfilter-persistent, and a routing script driven by both a self-contained systemd oneshot that waits for the DHCP uplink and an if-up.d hook that re-applies on every renewal. Belt and suspenders, because DHCP will erase your multipath the moment you stop putting it back.
Most FPGA tutorials, including my own, go forward: idea, block diagram, VHDL, simulate, synthesize, place and route, flash, done. That order makes sense for building something. It makes less sense for understanding the toolchain, because forward explanations tend to gloss over exactly the step you are standing on. You are told “now run synthesis” and you run it, and the tool produces a file, and you move to the next command.
\n\nThis post goes the other direction. I want to start at the thing you can actually observe, an LED blinking on a Lattice iCEstick, and walk backward through every transformation until we arrive at the idea that caused it. Every program in this chain is a transformer: it takes a dataset and a configuration, and it produces a different dataset. Nothing in the chain does anything else. Once you see it that way, the toolchain stops being a sequence of magic incantations and becomes a pipeline of well-defined functions.
\n\nIf you have not read WTF are FPGAs, that post covers the architecture: logic cells, routing fabric, why FPGAs exist at all. This one assumes you know roughly what an FPGA is and cares only about what happens between your idea and the moment it becomes silicon behavior.
\n\nRunning gateware on the iCEstick\n ^ iCE40 self-boot (chip reads flash as SPI master on power-up)\nBitstream sitting in external SPI flash\n ^ iceprog\nBitstream (.bin)\n ^ icepack\nPlaced & routed design (.asc)\n ^ nextpnr-ice40\nTechnology-mapped netlist (JSON)\n ^ yosys (synth_ice40)\nGeneric netlist (Verilog, written by GHDL)\n ^ ghdl synth (--out=verilog)\nAnalyzed design units in a library\n ^ ghdl -a (analyze)\nVHDL code\n ^ a human, not a program\nBlock diagram\n ^ a human, not a program\nFlip-flops, logic gates, wires: the idea\nTwo of those arrows are not tool invocations. That is not an oversight, it is the point: every arrow in this chain is a transformer with a configuration, except the two closest to the idea. I will come back to that.
\n\nA note on two choices I made deliberately, both worth calling out before we dive in:
\n\nFirst, GHDL and yosys can talk to each other two ways: the ghdl-yosys-plugin hands GHDL’s internal representation to yosys in-process, no file ever touches disk between them, or you run ghdl synth as its own step and get a real Verilog file that yosys reads with read_verilog, same as any other Verilog source. The plugin route is what you would actually use day to day, it is one invocation and one fewer moving part. I am walking through the ghdl synth route instead, because it produces an artifact you can open, inspect, and reason about at each stage. Didactically, a file beats an in-process handoff you cannot see.
Second, this whole chain uses VHDL, not Verilog, and that is not a style preference. In safety-critical domains, avionics under DO-254, industrial systems under IEC 61508, automotive under ISO 26262, the certification process cares about exactly the kind of thing VHDL enforces at the language level: strong, static typing that catches a huge class of accidental-width or accidental-sign bugs at analysis time rather than in simulation or, worse, in hardware. Verilog’s weaker typing does not disqualify it outright, but it pushes more of that burden onto coding-standard compliance and tooling, which is a harder thing to argue in front of an auditor than “the compiler rejected it.” That is also why the strict, incremental analyze step described below is not academic trivia: a design flow with an auditable paper trail per compilation unit is precisely what these certification regimes want to see.
\n\nThe LED is blinking because the iCE40 is currently holding a specific pattern in its configuration SRAM: which routing multiplexers are closed, what each LUT’s truth table is, what each flip-flop’s reset behavior is. That pattern is volatile. Remove power and it is gone.
\n\nThis is the detail that trips people up: “flashing an FPGA” does not mean writing directly into the chip’s active configuration memory, at least not permanently. On the iCEstick, iceprog writes the bitstream into an external SPI flash chip on the board, using the second channel of the onboard FTDI dual-UART/SPI chip as a SPI master. While it does this, it holds the iCE40 in reset, so the two devices are not fighting over the same SPI bus.
On every power-up, the iCE40 does something you do not initiate: it pulls its CDONE pin low, becomes a SPI master itself, reads the bitstream out of that same external flash, and writes it byte by byte into its own configuration cells. Once that finishes, CDONE goes high and your design starts running. “Flashing” means feeding the source the chip will read from at its next boot, not writing to the chip directly.
Transformer: iceprog\nInput: bitstream (.bin), flash configuration (SPI mode, flash offset)\nOutput: gateware on the board’s external flash, loaded into the FPGA on the next boot\nImplicit requirement: exclusive access to the FTDI channel; under Linux, udev rules that let a non-root user talk to the chip at all (see the permissions section in the Zero to One VHDL post if you have not set that up yet).
Before iceprog had anything to write, something had to produce the .bin file. That is icepack, and it does exactly one thing: it takes the human-readable .asc file that nextpnr produced and serializes it into the binary format the iCE40’s configuration loader expects.
icepack makes no design decisions. The .asc file already contains, for every tile in the chip, whether that tile is used and exactly what its configuration bits should be: logic cell truth tables, DFF reset-type bits, routing mux selections. icepack’s job is to know, for a given iCE40 device (a 1k, an 8k, whichever), the exact bit position in the linear output stream that corresponds to each tile’s configuration cell, a mapping that the IceStorm project reverse-engineered because Lattice never published it. It writes those bits at the right positions, pads unused regions with the device’s required defaults, and appends the sync words and CRC that the chip’s own bootloader expects to see.
This is why “not enough logic cells” can never be an icepack error. By the time icepack runs, every cell already has a confirmed physical home. If the design did not fit, the failure happened one step earlier.
Transformer: icepack\nInput: placed and routed design (.asc, text)\nOutput: bitstream (.bin, binary)\nNote: pure format conversion, no capacity checking, no optimization.
Here is the step people most often describe imprecisely, myself included until I actually traced through it: nextpnr does not decide what a piece of logic becomes. It decides where a piece of logic goes.
\n\nBy the time nextpnr runs, every cell in the design is already a concrete iCE40 primitive: SB_LUT4, some flavor of SB_DFF, SB_CARRY, SB_IO. That decision was made one step earlier, in yosys. nextpnr’s job is placement and routing:
Two inputs feed this that are easy to forget about because they are not files you generate, they are files you write by hand:
\n\nled signal has to land on the specific pin wired to an actual LED.--hx1k --package tq144 and not just “iCE40.”If the design genuinely does not fit, this is where it fails, with an error like “failed to place cell” or “out of bels of type ICESTORM_LC.” Nothing downstream of this step can produce that failure, because nothing downstream is checking capacity anymore.
\n\nTransformer: nextpnr-ice40\nInput: technology-mapped netlist (JSON), PCF, chip architecture database\nOutput: placed and routed design (.asc)\nImplicit requirement: the JSON must already consist entirely of iCE40 primitives; nextpnr does not perform technology mapping.
This is the step where “identity” gets fixed. synth_ice40, the yosys script for this target, does both generic logic synthesis and technology mapping in one pass, and the order matters for understanding what “netlist” even means at each stage.
yosys reads the design as an ordinary Verilog file, via read_verilog, into its own internal representation, RTLIL. That Verilog file is the one ghdl synth wrote in the previous step (more on that below); yosys has no idea, and does not care, that it originated as VHDL. process-derived logic is not yet a netlist at this point in the RTLIL sense yosys means by “netlist”: it is still procedural, if/case structures, sequential signal assignments, just expressed in Verilog syntax rather than VHDL. The proc pass converts that procedural description into an actual netlist: if/case becomes $mux cells, clocked assignments become $dff cells with a mux feeding their input. This is the step where “prozedurales Denken,” procedural thinking, becomes pure combinational logic plus registers.
From there: generic optimization (constant folding, dead logic removal), then techmap breaks complex generic cells down to primitive gates, then abc (a separate logic synthesis tool yosys shells out to) does the actual LUT-mapping heuristic, mapping the boolean network onto 4-input LUTs because that is what an iCE40 logic cell is. A second techmap pass with the iCE40-specific cell library turns those generic LUT/DFF results into SB_LUT4, the correct SB_DFF variant, SB_CARRY for arithmetic carry chains. iopadmap inserts SB_IO cells at every top-level port, because the chip needs explicit IO buffer cells that are not implicit in a generic design.
After this point, the set of cell types in the design is frozen. nextpnr cannot introduce a new primitive type, cannot decide a signal should have been an SB_CARRY instead of plain LUT logic. All of that identity work happened here.
Transformer: yosys (synth_ice40)\nInput: generic netlist (Verilog file written by GHDL), iCE40 cell library\nOutput: technology-mapped netlist, written out as JSON via write_json\nNote: synthesis and technology mapping are one pass here, not two separable stages.
ghdl synth --std=08 --out=verilog <unit> -e <top> takes the already-analyzed design units sitting in the library (see the next section), elaborates them internally, picking the top-level, binding generics, resolving hierarchy, and then walks the fully elaborated design, translating every process and concurrent signal assignment into gates, muxes, and flip-flops, printing the result as a structural Verilog file. That file is a completely ordinary artifact: you can open it, diff it, grep it, hand it to any tool that reads Verilog, not just yosys. --out=vhdl produces the equivalent as a VHDL netlist instead, and --out=dot produces a Graphviz graph for visualization only, not something synthesizable.
Note that elaboration itself is not a separate, user-facing step in this chain: ghdl synth resolves hierarchy and binds generics as an internal part of its own run, on its way to producing the netlist. It is worth knowing that GHDL also exposes ghdl -e as a standalone command elsewhere (mainly for producing a runnable simulation executable via ghdl -r), but nothing downstream of -a in this synthesis path invokes it separately.
This is also where the ghdl-yosys-plugin, mentioned in the note above the chain diagram, does the same underlying work differently: instead of printing a file, the plugin calls the same internal netlisting logic and hands the result to yosys’s RTLIL builder directly, in memory, inside a single yosys invocation (ghdl_synth in a yosys script). No .v file ever exists on disk in that path. Functionally equivalent to what is described here; just no intermediate artifact to inspect.
Transformer: ghdl synth\nInput: analyzed design units from the library, chosen top-level, generic values\nOutput: generic, technology-neutral netlist, as a Verilog file (--out=verilog)\nImplicit requirement: every unit the top-level references transitively must already be analyzed and present in the library.
ghdl -a produces, per design unit, an entry in the library’s index and an object representation of that unit’s internal typed tree. It does two things and exactly two things: type-checking (does this unit’s code make sense on its own, given what it declares and what it imports via use), and interface recording (what ports, generics, and declarations does this unit expose, so that later steps, like ghdl synth, can reference it correctly).
What it explicitly does not do: resolve hierarchy, know about a top-level, or produce any kind of gate-level structure. A process block at this stage is still exactly the VHDL you wrote, not yet touched by anything resembling synthesis. Put in software terms, ghdl -a is closer to a compiler than a linker: it turns each source file into an independent, type-checked unit, the VHDL equivalent of an object file, without knowing or caring what the final program looks like. Resolving that final shape, picking a top-level, binding generics, wiring instances together, is ghdl synth’s job, one step up in this chain.
The reason analyze exists as its own step rather than being folded into ghdl synth is that the library it produces is reusable. If none of the already-analyzed units change, you can point ghdl synth at an entirely different top-level and skip re-analysis. And if you change one unit, only that unit needs re-analysis; GHDL tracks this through dependency and timestamp information in the library’s index file. This is the same reasoning behind incremental compilation in any language with a module system: analyze once, reuse the library across as many downstream runs as you need, as long as the pieces did not move.
One practical consequence, and this is the kind of thing that only becomes obvious once you try to break it: if you analyze files out of dependency order, a package’s body before something that imports it, GHDL rejects the later file with “unit … not found,” because the referenced unit is not in the library index yet. GHDL will not reorder your build for you.
\n\nTransformer: ghdl -a\nInput: VHDL source for one or more design units\nOutput: typed, checked units recorded in the library\nImplicit requirement: dependency order; a package must be analyzed before anything that uses it.
Every step above this line is a program with a configuration. This one is not. Going from a block diagram to VHDL is a design act performed by a person, and it is worth pausing on because it is structurally different from everything else in the chain: there is no transformer here, no dataset-plus-config producing another dataset. There is a person translating an idea into a formal language, and that translation is where actual engineering judgment lives.
\n\nIt also carries an implicit requirement none of the automated steps enforce until much later: not every construct that simulates is synthesizable. wait for 10 ns runs fine in a testbench and means nothing to synth_ice40. That boundary, what is synthesizable VHDL versus what is merely simulatable VHDL, is not checked at the point you write the code. It surfaces later, at analyze or synthesis time, as an error or a silent misunderstanding of what hardware you actually described.
Below VHDL is the block diagram: flip-flops, logic gates, wires, arranged conceptually before a single line of code exists. Like the step above it, this is not automated, and “configuration” here means something different: it means domain knowledge. Understanding what needs a clock edge and what is purely combinational. Understanding metastability well enough to know when a signal is crossing clock domains and needs synchronization. Deciding, before any tool is involved, that a given function actually belongs in hardware at all rather than in software running on a microcontroller sitting next to the FPGA.
\n\nThis is the actual root of the whole chain. None of the seven transformers above it can correct a bad decision made here. They can only execute, with complete fidelity, whatever was decided at this step.
\n\nGoing forward, you start with intent and watch it get realized. Going backward, you start with the physical fact, an LED blinking on a piece of hardware you can hold, and you ask what had to be true one step earlier for that fact to exist. I found that more honest about where the actual decisions get made. Six of the eight steps in this chain are mechanical: given the same input and configuration, icepack or nextpnr will always produce the same output. The two steps that are not mechanical, block diagram to VHDL and idea to block diagram, are the only places where the design could have gone differently. Everything downstream of those two steps is just careful, deterministic execution.
If you want to see this chain from the other direction, with actual VHDL, a testbench, and a real LED blinking at the end, that is Zero to One: VHDL and a Lattice iCEstick. And if you want the architectural picture this post assumes, what a LUT is, why the routing fabric matters, why FPGAs exist at all, that is WTF are FPGAs.
", "date_published": "2026-07-08T00:00:00+00:00", "date_modified": "2026-07-08T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["fpga","open-source"] }, { "id": "https://maxclerkwell.tech/posts/correlation-causation-overton-window-july-2026/", "url": "https://maxclerkwell.tech/posts/correlation-causation-overton-window-july-2026/", "title": "Correlation, Causation, and the Overton Window That Only Shrinks", "summary": "Everyone knows the first half of the aphorism. The second half is where the actual thinking happens, and I think the reflex to stop at the first half is doing something worse than being lazy.", "content_html": "If you spend enough time around superficially intellectual people, you will have heard the phrase. Someone points at a pattern, someone else says “correlation doesn’t imply causation,” and the conversation ends there, usually with a small, satisfied smile. When I picture the moment, there is a specific face attached to it: the smug pseudo-scientist, chin slightly raised, having just deployed the one piece of statistics they remember from a first-year course as a conversation-ending device rather than a conversation-starting one.
\n\nWhat bothers me is not the sentence. The sentence is true. What bothers me is that people only ever remember the first half of it, and that this is not an isolated case. It happens to aphorisms constantly, and it is almost never innocent.
\n\n“The customer is always right” is missing its second clause: in matters of taste. The original point was narrow (do not argue with someone about what they like) and got flattened into a blank check for entitlement. “Blood is thicker than water” is reputed to descend from “the blood of the covenant is thicker than the water of the womb,” which, if true, means the proverb originally argued the opposite of what everyone now uses it for: chosen loyalty over accident of birth, not the other way around. “Curiosity killed the cat” drops “but satisfaction brought it back,” which turns a warning into a complete thought about risk and reward instead of a blunt instrument for shutting down questions. “Money is the root of all evil” quietly deletes “the love of,” a difference Paul actually cared about making. In every case, the second half is where the nuance lives, and the second half is exactly the part that gets dropped when people want to use the phrase as a stop sign rather than a signpost.
\n\nI think “correlation doesn’t imply causation” belongs on this list, and I want to use this article to make the case for its missing half.
\n\nMy honest belief about the motivation behind this specific phrase, deployed in the specific reflexive way it usually is, is that the person saying it has something to protect. Not always consciously.
\n\nSometimes it is closer to a Freudian slip than a statistical objection: a phrase produced under mild pressure that reveals more about the speaker’s discomfort than about the data.
\n\nHere is the pattern I mean. Every time you use the lab equipment, something breaks the next day. You mention this. The response: “correlation doesn’t imply causation.” Technically correct.
\n\nIt is also, functionally, an attempt to make sure nobody keeps pulling on that thread. The phrase is not being used to advance an inquiry into what is actually going on. It is being used to close one down.
\n\nIt marks a boundary: this direction of thought is uncomfortable to me, and I would like you to stop walking in it.
\n\nTabea (@tabeatheunicorn) and I have talked about this a lot, especially in the context of our alma mater, because a university is precisely the place where this move should never work. A university is supposed to be a sandbox for ideas. As a researcher you cannot actually do very much to the world directly. Mostly you can write a paper, and maybe someone reads it, and maybe they don’t. Given how limited the actual leverage is, putting artificial shackles on your own thinking, inside the one institution explicitly built to remove them, seems like a strange thing to volunteer for.
\n\nSo: should someone be allowed to think outside the current boundaries of the status quo? Probably.
\n\nI want to approach that question from two directions at once, because I think both of them point at the same underlying structure.
\n\nImagine a world with one rule: say anything you want within a certain boundary, and the instant you say something outside it, you are eliminated from the conversation permanently. The boundary itself is set democratically: whatever more than half the population currently finds acceptable defines the edge. To make this tractable, assume outrageousness can be projected onto a single axis. (If the space is actually multidimensional, assume everyone uses something like a norm to collapse it onto one axis anyway. It does not change the conclusion.)
\n\nAt first glance this looks fair. Democratic input, majority rule, the boundary reflects genuine consensus.
\n\nHere is the catch. In a system where speaking outside the line gets you instantly and permanently removed, the window can only shrink or stay the same. It can never expand. Nobody is ever rewarded for testing the edge, because testing the edge is fatal. Growth is structurally impossible.
\n\nWill it actually stay the same, though? Probably not, and here is the mechanism, step by step:
\n\nMultiply that inference across a whole population making the same calculation repeatedly, and you get a standard deviation that compresses over time. The tails get pruned faster than the center refills them, because refilling the tail requires someone brave (or reckless) enough to occupy it again, right after the population was just handed a fresh, painful reason not to.
\n\nThe Overton window, under this model, does not stay put. It contracts. The only thing that could counteract this is a supply of what I’ll call martyric psychopaths: people sufficiently indifferent to elimination that they keep re-occupying the tail regardless of the cost. Absent that supply, the window is a one-way ratchet, and it only ratchets in one direction.
\n\nHere is the second angle, and I will be upfront that I do not have an airtight argument for it. Treat it as a thought experiment and decide for yourself how far to trust it.
\n\nModel the Overton window as an infinitely deep potential well, and the distribution of things people actually say as an electron sitting in the well’s ground state. The naive read: since the well is infinitely deep, nobody’s expression ever ends up outside it.
\n\nThat is not actually true, and the reason it is not true is instructive.
\n\nThe quantum mechanical analogy is the tunnel effect. The probability of finding the electron outside the well is strongly suppressed the further out you go, but it never goes to exactly zero, no matter how deep or how sharp the walls are.
\n\nTranslate that back: even with a completely fixed, unmoving boundary of acceptable speech, there will always be some nonzero density of people saying things over the line. Not because the boundary moved. Because the underlying distribution has a tail that never fully vanishes, no matter how steep you make the walls.
\n\nGiven that this seems true regardless of where you draw the line, the actual question becomes: is it wise to eliminate the people who show up in that tail?
\n\nIf the tail is a structural, permanent feature of any population large enough to matter, and you eliminate everyone who falls into it as a matter of policy, you have not designed a system with an edge case. You have designed a system with a permanent, self-renewing supply of victims.
\n\nThat is a design property, not a bug you can patch out. It is a form of cruelty built into the architecture, aimed at people who were never doing anything other than what the distribution guarantees someone will eventually do.
\n\nBoth of these thought experiments share an implicit premise I want to name directly: nothing outside the currently known can ever be useful or good. That is the assumption doing all the quiet work.
\n\nIf you actually believed that everything worth knowing is already inside the window, elimination at the boundary would be costless. You would not be losing anything by pruning the tails, because the tails, by definition, contain nothing of value.
\n\nI do not believe that premise. Showing up to a university is itself an implicit rejection of it. Attending one means you believe there is something out there, currently unknown, worth discovering, worth the risk of moving toward. That is the whole justification for the institution’s existence.
\n\nNot moving forward is not a neutral, stable resting state. It is the precondition for falling behind, because everyone else’s window is either expanding or contracting too, and a system that structurally cannot expand is, relative to one that can, already losing.
\n\nSo here is my refinement of the phrase this whole article is built around: not every correlation implies causation, but every correlation deserves to be investigated.
\n\nJudea Pearl makes a version of this argument with far more rigor than I can bring to it here. When two variables move together, there are only a small number of structural explanations available:
\n\nThe phrase “correlation doesn’t imply causation,” said and left there, correctly rules out jumping straight to option one. What it does not do, and what the smug delivery conveniently obscures, is rule out options two through five.
\n\nSo how do you actually test for which of the five you are looking at, in real life, without a physics lab and a controlled universe? A few concrete moves, roughly in order of how much they cost you:
\n\nNone of this is exotic. It is closer to the Bradford Hill criteria used in epidemiology than to anything requiring a PhD in causal inference. The point is that it is work, and the phrase “correlation doesn’t imply causation,” used as a mic drop, is specifically the sentence people reach for when they want credit for rigor without doing any of it.
\n\nSo the next time you hear the phrase deployed as a full stop rather than a comma, I would like you to think about this article and do the exploratory thing instead. Ask which of the five categories you are actually looking at. Check the temporal order. Look for the mechanism. Go find the confounder before someone else has to hand it to you.
\n\nThere is no instant death penalty for speech in most rooms you will find yourself in, university or otherwise. But if the shrinking-window argument above is right, that only stays true if people keep using the full width of the window rather than quietly retreating toward the middle every time someone drops a conversation-ending aphorism on them. The window does not maintain itself. It has to be used, fully and repeatedly, or it contracts on its own. That is not a metaphor I am fond of. It is, as far as I can tell, the actual mechanism.
\n\nIf you want to push back on any of this, come find me on Discord.
", "date_published": "2026-07-06T00:00:00+00:00", "date_modified": "2026-07-06T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["philosophy","personal"] }, { "id": "https://maxclerkwell.tech/posts/what-ai-actually-is-july-2026/", "url": "https://maxclerkwell.tech/posts/what-ai-actually-is-july-2026/", "title": "What AI Actually Is", "summary": "Running a chat model is not AI. The training process is. Everything else follows from that distinction, including where the human niche survives.", "content_html": "The previous two articles built up a chain. The first ran from Aristotle’s two-valued logic through Leibniz, Boole, Gauss, and Shannon to the bit as a unit of information. The second ran from Hilbert’s decision problem through Turing, the Universal Approximation Theorem, and Banach’s convergence guarantee to the modern neural network. This article asks what to make of all of it: what is the thing we are actually calling AI, and where does it leave the human?
\n\nI want to start with something I find useful to keep in front of me, because it clarifies almost every confused conversation about AI I have ever had.
\n\nThink of a real-world function as a black box. Something goes in, something comes out, according to some rule. The box does not care what you think is inside it. It just maps inputs to outputs.
\n\nFor some boxes, a smart mathematician can look at enough input-output pairs and see the rule directly. A physicist measuring voltage and current recognises Ohm’s law. A structural engineer sees a force-displacement relationship and fits a spring constant. A clever programmer can then take that formula and implement it efficiently. Add a physicist who understands how to translate a physical measurement into a digital signal, and a mechatroniker who knows how to turn a bit pattern into a motor command, and you have the ingredients for a functional intelligent robot. Each person contributes one piece of the chain from world to decision to action.
\n\nThis is not a hypothetical. It is how most of the automation we rely on was actually built: by people who understood the domain, identified the relevant variables, wrote down the relationship, and implemented it. The intelligence was human, the execution was mechanical.
\n\nThe problem is that some boxes resist this approach. Human language is one of them. The rule that maps a sentence to its appropriate response is not one that any mathematician has written down, because it is not a formula at all. It is an enormously complex, context-dependent, culturally embedded mapping that took hundreds of thousands of years of human evolution and social practice to produce. Nobody can inspect it and extract an equation. The manual way breaks down.
\n\nWhen the manual way breaks down, the question becomes: can we replace the mathematician with a computer program? Can we feed the machine a large list of input-output pairs, and have it figure out what the mapping looks like, and then produce a second program that implements that mapping well enough to be useful?
\n\nThis is what training does. It is the automation of the step the mathematician used to perform by hand. You define a family of possible functions (your neural network architecture, which the UAT tells you is expressive enough to approximate almost anything). You collect data: pairs of inputs and desired outputs. You run a training procedure that searches through that family for the member that fits the data best, in the sense of minimising a chosen error measure. When the procedure converges, you have a model: a fixed, deterministic function, with its parameters set.
\n\nThat model is a program. It is data: a long sequence of numbers stored in memory. When you run it, you are evaluating a function. Input goes in, output comes out. The schema from the previous article applies directly: DATA (your prompt) + DATA (the model weights) gives you TRANSFORMATION (the forward pass through the network) gives you DATA (the response).
\n\nNothing in that process, at inference time, is learning, deciding, or thinking. It is matrix multiplication. The same input always produces the same output. A language model answering your question is no more “intelligent” at that moment than a sorted list is intelligent for being sorted.
\n\nThis is the distinction I want to press on, because I think almost all confusion about AI collapses once you hold it clearly.
\n\nThe intelligence, if we want to use that word at all, is in the training process. It is in the choice of architecture, the choice of loss function, the collection and curation of training data, the engineering of the optimiser, and the infrastructure that runs billions of parameter updates until the loss converges. That process searched through an astronomically large space of possible functions and found one that approximates the target mapping well enough to be useful. That search is remarkable. That is where the interesting thing happened.
\n\nThe running model is the result of that search. It is a certificate, not a process. Ada Lovelace wrote, in 1843, that the Analytical Engine “can do whatever we know how to order it to perform.” She meant it as a limitation. Re-read in the light of training: the model can do whatever the training process knew how to encode into it. The training process, not the model, is the locus of whatever deserves the name intelligence.
\n\nWith that distinction in place, I want to work through six ideas about what language is and what it means for both human and machine intelligence. These matter because the thing we are mostly using as the interface to AI systems right now is language, and language has properties that cut directly into the question of what a trained model can and cannot do.
\n\nWords are case distinctions, not the thing itself. The word “cat” does not contain a cat. It is a pointer, agreed upon by convention, that picks out a region of conceptual space. “Cat”, “Katze”, “gato”, and “猫” (mao) all point to the same region via different pointers. At the level of the letter sequence as a number (you can read any word as a base-26 integer), they are completely different. At the level of meaning, they are identical. This two-layer structure, symbol system on top, meaning system underneath, is not an accident. It is how language works. A model trained on text learns the statistical regularities of the symbol layer. Whether it reaches the meaning layer is a genuine open question.
\n\nSome descriptions are lossless, most are not. The numeral “3” (or “0b11” in binary, or “III” in Roman notation) describes a precise, discrete state with no ambiguity. The word “warm” does not. It carves a continuous temperature axis into a rough category, losing almost all information about the specific temperature involved. Most of human language is like “warm”, not like “3”. It is a lossy compression of experience into categories coarse enough to be spoken and heard in real time.
\n\nLanguage is a solution to an engineering problem. Shannon’s rate-distortion theory says you cannot simultaneously minimise the information lost in a description and the length of that description. You always trade one for the other. Natural language sits at a particular point on that curve: short enough to be spoken in real time by a breathing, forgetting, interrupted speaker; lossy enough to leave the hard work of disambiguation to context and shared knowledge. Zipf’s law, the observation that the most common words are the shortest, is this trade-off self-organising. Language did not arrive at this point by design. It was selected for, over thousands of generations, because speakers who found the right trade-off communicated better. Shannon described the law. Evolution found the solution.
\n\nFixing the channel does not fix the loss. Suppose you had a perfect voice and a perfect ear: a lossless acoustic channel. Would that give you lossless communication? No. The bottleneck is not the channel. It is the encoding. Before any word leaves your mouth, you have already mapped a continuous, private experience onto a discrete, shared symbol. That mapping discards almost everything. Transmitting “I am in pain” with perfect fidelity still does not transfer the experience of pain. The loss happened when you chose the word, not when you spoke it.
\n\nThe infinite is nobody’s territory. If reality is genuinely continuous and unbounded, then both humans and machines are finite quantisers working on the same infinitely large problem. The human does not have special access to the unquantised real. The human’s quantisation vocabulary is tuned by evolution to bodies, survival, and social life. The machine’s quantisation vocabulary is inherited from ours, since it trained on our text. It is a quantiser of our quantisation: a second-order approximation. Whether that is a limitation or merely a different kind of approximation is a question worth sitting with.
\n\nThe spaces are complementary, not identical. The overlap between what a human can express and what a model has encoded is large, because the model trained on human expression. But the overlap is not total. The human brings a body, a history, a position in time, mortality, and the knowledge that comes from having stakes in the outcome. The model brings the entire written corpus processed simultaneously, exact pattern recall across billions of tokens, and no fatigue. These are not the same set of capabilities with one being larger. They are different shapes, sharing a large common region but each extending into territory the other does not reach.
\n\nAll of that has a concrete consequence for what a trained model can and cannot do, and it is best understood geometrically.
\n\nImagine you have three points in a coordinate system and you want to find the function that passes through them. With three points, a parabola fits perfectly. The residuals are zero. Everything looks clean. If someone asks you for the value of the function between those three points, you interpolate: you read off the parabola’s value, and provided the true underlying function really is a parabola, you will be right.
\n\nNow add a fourth point, well outside the range of the first three. The parabola, fitted on the original three, will not pass through it. The squared error at the new point may be very large. The correct model, it turns out, is a cubic polynomial. But you could not have known that from three points alone. Three points underdetermined the model family.
\n\n![\"Two](\"/assets/posts/what-ai-actually-is-july-2026/interpolation-vs-extrapolation.png\")
\n A language model’s training data is a set of points. The model is the function fitted to them. Within the distribution of that training data (the interpolation regime), the model performs remarkably well. It has seen enough examples of similar inputs and outputs that its approximation is accurate.
\n\nOutside that distribution (the extrapolation regime), the fitted function is being evaluated in a region where it has no data to constrain it. It will produce an output, because it is a function and functions always produce outputs. But there is no guarantee that output bears any relationship to the correct answer. This is what hallucination is. It is not a bug or a sign of deception. It is the model doing exactly what it was trained to do (produce plausible continuations of text) in a region where plausibility is no longer anchored by data. The parabola, extrapolated far enough, gives you confidently wrong numbers. The model, extrapolated far enough, gives you confidently wrong facts.
\n\nThe lesson is not that models are useless outside their training distribution. It is that you need to know which regime you are in. Inside the training distribution, trust the interpolation. Outside it, verify.
\n\nThis brings me to the question I find most interesting: where does the human advantage persist?
\n\nThe model interpolates. It does so at remarkable scale and speed, over a training distribution that covers most of recorded human knowledge. For tasks that live inside that distribution, the model will often match or exceed human performance, simply because it has seen more examples and recalls them more exactly.
\n\nBut creative work, in the deepest sense, is extrapolation. It is the production of something that does not yet exist in the training data, that cannot be reached by interpolation from known points, that requires the generation of a new point in a space where the model has no data to fit. The model can produce text that looks creative because it recombines familiar patterns in unfamiliar ways. That is impressive, and useful, and not nothing. But it is not the same as genuinely extending the frontier.
\n\nI am cautious about making this argument too quickly, because the boundary between recombination and genuine novelty is genuinely hard to draw. But I think there is something real here, and I want to name it: the human ability to stand at the edge of the known, feel the discomfort of genuine uncertainty, and commit to a direction anyway, is not well-modelled by a function that returns the statistically most plausible next token. The mathematician who saw a pattern nobody had seen before was not interpolating. The physicist who proposed a model that contradicted all prior experiments was not interpolating. The artist who made something that had no precedent was not interpolating.
\n\nI discussed the question of whether any of this is connected to consciousness in an earlier piece on machine consciousness, and I do not want to repeat that argument here. But I will say this: the tradition that speaks of a divine spark in the human, the capacity for genuine creation that does not merely recombine what came before, points at something that the interpolation picture of intelligence does not capture. Whether that capacity is consciousness, or something else, or whether machines will eventually acquire it, I do not know. What I do think is that it is precisely this capacity that defines the domain where human intelligence has something the trained model structurally lacks: not more data, not faster recall, but the ability to generate a genuinely new point in a space where no training data exists.
\n\nThe model trained on everything humans have written is a mirror of what we have already said. The next thing worth saying is, by definition, not yet in the mirror.
\n\nThese three articles form a connected arc: from the bit, to the function, to the question of what the function cannot do. If you want to follow any of these threads further, the Discord is the best place.
\n\nIf you want to talk through any of this, come find us on Discord.
\n\n", "date_published": "2026-07-03T00:00:00+00:00", "date_modified": "2026-07-03T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["ai","philosophy","education"] }, { "id": "https://maxclerkwell.tech/posts/from-the-uat-to-the-modern-neural-network-july-2026/", "url": "https://maxclerkwell.tech/posts/from-the-uat-to-the-modern-neural-network-july-2026/", "title": "From the UAT to the Modern Neural Network", "summary": "We have the bit. Now the question is what we can compute with it, and whether a machine can learn to compute things nobody explicitly programmed. The answer runs from Hilbert through Turing to a theorem most engineers have never heard of.", "content_html": "The previous article ended with a precise unit: the bit, as Shannon defined it, measures how much uncertainty a message resolves. We have a way to represent information. We have a way to build logical operations from switches. We know, from Gauss and Weber, that a wire can carry two distinguishable states. The question this article asks is the next one in the chain: what can we actually compute with all of this, and is there a limit?
\n\nThat question turns out to be older than the computer. It starts with a mathematician who wanted to mechanise all of mathematics, runs through a logician who showed that was impossible, and ends with a computer scientist who redefined what “mechanical” even means.
\n\nIn 1928, David Hilbert posed what he called the Entscheidungsproblem, the decision problem. The question was this: is there a mechanical procedure that, given any mathematical statement, can decide in a finite number of steps whether the statement is true or false?
\n\nHilbert’s hope was that mathematics was complete (every true statement is provable), consistent (no contradictions exist), and decidable (there is an algorithm for each question). This was not naive optimism. It was a serious research programme, and Hilbert believed it could succeed.
\n\nThree years later, in 1931, Kurt Gödel demolished the first two hopes. His incompleteness theorems showed that any sufficiently powerful formal system contains true statements that cannot be proved within that system, and that no such system can prove its own consistency. Mathematics is not complete. There are truths that lie beyond the reach of any fixed set of axioms.
\n\nThis did not yet answer Hilbert’s third question. Even if some truths are unprovable, there might still be a mechanical procedure that always terminates with a correct yes or no. That question required a different kind of answer: not a proof about what mathematics contains, but a precise definition of what “mechanical procedure” means in the first place.
\n\nIn 1936, Alan Turing published “On Computable Numbers, with an Application to the Entscheidungsproblem”. What he did was unusual. Instead of taking “mechanical procedure” as an informal concept and arguing about it, he defined it: a mechanical procedure is precisely what can be carried out by what we now call a Turing machine, an abstract device with a tape, a read/write head, and a finite set of rules for transitioning between states.
\n\nThis definition was not a restriction. Turing argued, convincingly, that anything a human could compute by following explicit rules could be computed by such a machine. The definition captured the concept.
\n\nWith the definition in hand, Turing could answer Hilbert’s question exactly. He proved that no Turing machine can solve the halting problem: given an arbitrary program and an input, determine whether the program will eventually stop or run forever. Because deciding all mathematical statements would require solving the halting problem, the Entscheidungsproblem has no solution. There is no universal decision algorithm.
\n\nThe negative result is not what I want to emphasise here, though. What matters for our chain is the positive content of Turing’s definition: a complete, precise account of what computation is. Any computation is a process that reads a finite input, follows deterministic rules, and produces a finite output. It takes in data, transforms it, and produces data. That pattern, data in and data out, is the foundation everything else in this article rests on.
\n\nShannon had already shown that logical operations can be built from switches. Turing showed that any computation can be expressed as a sequence of such operations. Put those two results together and you get something important: every program that terminates is a function.
\n\nIt takes an input, which is a finite sequence of bits, and it produces an output, which is another finite sequence of bits. The same input always produces the same output (for a deterministic program). That is the definition of a mathematical function. A sorting algorithm is a function from unsorted lists to sorted lists. An image classifier is a function from pixel arrays to label strings. A language model, at inference time, is a function from a token sequence to a probability distribution over the next token.
\n\nI want to make this concrete with a schema, because I think it cuts through a lot of confusion: DATA + DATA gives you TRANSFORMATION gives you DATA. The first DATA is your input. The second DATA is the program itself (its weights, its rules, its parameters), which is also just a sequence of bits stored somewhere. The TRANSFORMATION is the act of running the program. The final DATA is the output. Nothing in this picture requires consciousness, understanding, or anything mysterious. A running program is a function being evaluated.
\n\nThis reframing matters because it connects computation directly to mathematics, and specifically to the question of which functions are computable and how well they can be approximated.
\n\nBefore we get to neural networks, I want to make an argument that is rarely made explicitly: the idea that you can learn a function from data did not appear from nowhere in the 1980s. It has roots in numerical mathematics that go back to the 19th century, and without those roots, the Universal Approximation Theorem would have been much harder to conceive.
\n\nCarl Friedrich Gauss, in 1809, formulated the method of least squares: given a set of noisy observations, find the function (within a specified family, say, polynomials of a given degree) that minimises the sum of squared differences between the function’s predictions and the observations. This is, in structure, exactly what a neural network trainer does. You have data. You have a family of functions parameterised by numbers. You minimise an error measure. The conceptual template was there two centuries before backpropagation.
\n\nGauss-Jordan elimination, the method for solving the linear system that arises from the normal equations of least squares, made that minimisation computationally tractable. It gave engineers a systematic, mechanical procedure for finding the parameters that best fit a dataset, within the class of linear models.
\n\nCarl Runge and Martin Wilhelm Kutta, working in the 1890s, contributed a different but equally important idea: iterative numerical integration of differential equations. If you cannot find a closed-form solution to an equation describing how a system evolves, you can instead take many small steps, updating your estimate of the solution at each step. The error accumulates, but with small enough steps and a good enough scheme, the approximation converges to the true solution.
\n\nThat structure, iterating small updates toward a solution you cannot reach in closed form, is the computational backbone of gradient descent. Training a neural network is Runge-Kutta applied to a loss landscape instead of a differential equation. Without a century of experience showing that iterative numerical methods converge reliably, the proposal to train a network by repeatedly nudging its parameters in the direction of decreasing error would have looked much more speculative than it did.
\n\nThe mathematical guarantee behind all of this is the Banach fixed point theorem, proved by Stefan Banach in 1922. It says: if you have a mapping that is a contraction (each application brings two points strictly closer together), and the space you are working in is complete, then iterating the mapping from any starting point will converge to a unique fixed point.
\n\nGradient descent, under appropriate conditions on the loss function and the step size, is a contraction. Each update step moves the parameters closer to a minimum. The theorem guarantees not only that the process converges, but that it converges to the same place regardless of where you start, provided the contraction conditions hold. In practice, the loss landscapes of deep networks are far too complex for Banach’s conditions to hold globally. But the theorem explains why the procedure works at all, and it tells you what to look for when it does not: a step size that is too large breaks the contraction, and a loss landscape with many local minima means Banach’s uniqueness guarantee no longer applies.
\n\nWith all of that in place, we can state the central result.
\n\nIn the mid-1950s, at the Dartmouth conference that inaugurated the field of artificial intelligence, researchers were already circulating informal versions of a powerful conjecture: that a network of simple threshold units, given enough of them, could approximate any function. The intuition was compelling. Turing had shown any computation is a function. Boolean algebra had shown any logical function can be built from a handful of primitives. The leap was to ask whether something similar held for the much broader class of continuous functions.
\n\nThe formal proof had to wait. In 1989, George Cybenko proved a precise version for networks with sigmoid activation functions: a single hidden layer with sufficiently many neurons can approximate any continuous function on a compact subset of real-valued inputs to any desired accuracy. In 1991, Kurt Hornik extended this to arbitrary nonlinear activation functions and removed several technical restrictions.
\n\nThe theorem makes a striking claim. You do not need to design a function by hand. You do not need to know in advance what the function looks like. Given enough neurons, the right architecture, and a training procedure, a network can approximate any continuous input-output relationship from data alone.
\n\nThis is where the connection to Gauss closes: least squares found the best linear approximation within a fixed function family. The UAT says that with a neural network, the function family is rich enough to contain an approximation to anything. The training procedure (gradient descent, Banach’s iteration) finds it.
\n\nTwo caveats matter here and are often missed. First, the theorem guarantees existence: there is a network that approximates the function. It says nothing about how to find it, how much data you need, or how many neurons are required. Second, approximation is not the same as representation. A network that approximates a function to within 0.01 on a test set may behave completely differently outside that set. The theorem is a licence to try, not a guarantee of success.
\n\nOnce the UAT established that the approximation game was worth playing, the history of deep learning is largely the history of building better function families and better trainers.
\n\nFrank Rosenblatt’s perceptron (1957) was the first learned classifier: a single-layer network trained by a simple update rule. Minsky and Papert showed in 1969 that a single layer cannot separate all patterns (the XOR problem), which required the multi-layer networks the UAT had theoretically justified. Backpropagation, developed through the 1970s and popularised by Rumelhart, Hinton, and Williams in 1986, gave us the trainer: a systematic way to compute how much each weight contributed to the error and adjust it accordingly.
\n\nThe architectures that followed are each a different answer to the question “what structure should the function family have?”. Convolutional networks (LeCun, 1998) built in the knowledge that spatial patterns are translation-invariant. LSTMs (Hochreiter and Schmidhuber, 1997) built in sequential memory. Transformers (Vaswani et al., 2017) built in the ability to attend to arbitrary positions in a sequence, with no assumption about locality. AlphaFold, GPT, diffusion models: all of them sit on the UAT’s foundation. They are different choices of structure for the approximating function and different strategies for training it.
\n\nThe “intelligence” in all of these systems does not live in the trained model. At inference time, a network is a fixed deterministic function: x in, y out. The same input always produces the same output. What makes it remarkable is its origin: it was not written by hand. A trainer searched a vast space of possible functions and found one that fits the data. That search, and the choice of what space to search in and what to optimise for, is where all the interesting decisions are made.
\n\nThese two articles have traced a single line from Aristotle’s two truth values to the architectures that underpin modern language models. The bit is the atom. The Turing machine is the definition of computation. The UAT is the licence to approximate. Training is Gauss’s least squares generalised by Banach’s convergence guarantee. Every transformer, every diffusion model, every large language model is an instance of that chain, searched rather than written.
\n\nIf you want to talk through any of this, come find us on Discord.
\n\n", "date_published": "2026-07-03T00:00:00+00:00", "date_modified": "2026-07-03T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["ai","information-theory","history","education"] }, { "id": "https://maxclerkwell.tech/posts/from-aristotle-to-the-bit-july-2026/", "url": "https://maxclerkwell.tech/posts/from-aristotle-to-the-bit-july-2026/", "title": "From Aristotle to the Bit", "summary": "The bit did not fall from the sky in 1948. It is the last step in a chain that starts with a Greek philosopher arguing about sea battles and ends with Claude Shannon measuring surprise.", "content_html": "I want to tell you about a chain of ideas that took roughly 2300 years to complete.
\n\nIt starts with Aristotle sitting in Athens arguing about whether a statement like “there will be a sea battle tomorrow” is true or false right now. It ends with Claude Shannon (Fig. 1), in a small office at Bell Labs in 1948, writing down a formula that tells you exactly how much information is contained in a message. The distance between those two moments is the distance between informal common sense and a mathematically precise engineering tool. Understanding that distance, how each step in the chain was necessary and what each step actually contributed, is one of the most clarifying things you can do if you are trying to understand how digital technology actually works at its root.
\n\nSo let me walk through it. Not as a history lecture, but as a chain of dependencies. Each person in the chain solved a problem the previous person left open. The chain runs like this:
\n\nAristotle (4th century BC) established that every proposition is either true or false, with no third option. Ramon Llull (13th century) showed that a sequence of such yes/no decisions can be used to systematically navigate any space of possibilities. Leibniz (1703) gave us binary arithmetic and showed that base 2 is the minimally sufficient number system. Boole (1854) turned logical reasoning into algebra you can compute mechanically. Gauss and Weber (1833) built the first device that physically encoded and transmitted binary signals over a wire. And Shannon (1937, 1948) built the final two bridges: from Boolean algebra to electrical circuits, and from physical signals to a precise mathematical measure of information.
\n\nThat is the chain. Now let me explain what each step actually contributed, and why the previous step was not enough.
\n\nAristotle gave us two principles that most people today accept so automatically that they forget they are principles at all.
\n\nThe first is the law of non-contradiction: a statement cannot be both true and false at the same time. The second is the law of excluded middle: every statement is either true or false, with no third option, no middle ground, no “sort of true”.
\n\nThese sound obvious. But Aristotle knew they were not. In De Interpretatione, chapter 9, he worried specifically about statements concerning future events. Is “there will be a sea battle tomorrow” true or false today? If it is already determined one way or the other, does that mean the future is fixed? He did not fully resolve this tension, and philosophers still argue about it. But the working assumption he left behind, that meaningful propositions have exactly one of two truth values, became the bedrock of all formal logic.
\n\nNotice what this does not give you. It gives you a framework for evaluating single statements. It does not give you a way to chain statements systematically, to compute with them, or to encode the world as a sequence of yes/no decisions. Aristotle drew the line between two truth values. Someone else had to figure out what to do with it.
\n\nRamon Llull was a Catalan philosopher and theologian working in the 13th century, roughly 1232 to 1316. His Ars Magna, the “Great Art”, was an attempt to create a universal method for finding truth by combining a fixed set of basic concepts through systematic questioning. You start with a small vocabulary of fundamental attributes. You ask yes/no questions about each combination. You work through the tree of possibilities exhaustively. Complex questions reduce to chains of binary decisions.
\n\nLlull was not doing mathematics in the modern sense, and his specific framework was embedded in medieval Christian theology in ways that do not travel well to the present. But the structural idea, that you can specify and distinguish any complex thing through a sufficient sequence of yes/no questions, is exactly right, and it predates both Leibniz and Boole by several centuries. Leibniz knew Llull’s work and was directly influenced by it when developing his own vision of a calculus ratiocinator, a machine for resolving arguments by computation.
\n\nAristotle told you each statement is true or false. Llull told you that a chain of such statements can be used to navigate a space of possibilities and zero in on a target. That is a different and important idea. It is, in embryonic form, the idea of a binary search tree, a decision tree, a classification algorithm. Every time you play “20 questions” and converge on the right answer, you are using Llull’s insight.
\n\nGottfried Wilhelm Leibniz, in 1703, published a paper called Explication de l’Arithmétique Binaire in which he systematically laid out binary arithmetic: the idea that you can represent any number using only the digits 0 and 1, by assigning place values that are powers of two instead of powers of ten.
\n\nOne of the things Leibniz understood clearly, and that often gets glossed over, is that base 2 is not special in any deep mathematical sense. You can build a positional number system in any base: base 10 (what we use daily), base 60 (Babylonian astronomers), base 16 (hexadecimal in every programmer’s life), or base 2. They are all equivalent in expressive power. Any number representable in one base is representable in every other. Leibniz knew this, and he was clear that the choice of base 2 was about minimality: it is the smallest base that works at all. You need at least two distinct symbols to build a positional system, because with only one symbol you cannot distinguish place values meaningfully. Two symbols is the minimum.
\n\nThat argument is purely mathematical. What it means physically, why the minimum-symbol property turns out to be important for building machines, is a story that comes later in the chain.
\n\nWhat I find remarkable about Leibniz is that while working on this, he received a letter from a Jesuit missionary named Joachim Bouvet, who was stationed in China and had been studying the I Ching. Bouvet sent Leibniz a diagram of the 64 hexagrams: ancient Chinese symbols made of six stacked lines, each line either broken (yin, 陰) or unbroken (yang, 陽). Leibniz immediately recognised his own binary system in them. Six binary positions give you 2⁶ = 64 combinations. The hexagrams are, structurally, six-digit binary numbers. They were developed roughly 2000 years before Leibniz was born.
\n\nI am not saying the ancient Chinese invented binary computing. They did not have that goal. But this moment is worth sitting with: a combinatorial structure powerful enough to encode 64 distinct states was independently arrived at in two civilisations separated by millennia and thousands of miles, because it is a natural consequence of stacking binary choices. The structure was waiting to be discovered. I first had this connection pointed out to me by Meihui Huang, who drew the line from the Bagua directly to Leibniz in a way that has stuck with me since.
\n\n![\"The](\"/assets/posts/from-aristotle-to-the-bit-july-2026/bagua.svg\")
\n What Leibniz still did not have was a way to use binary notation for logic rather than just numbers. That step came next.
\n\nGeorge Boole, in 1854, published An Investigation of the Laws of Thought, and the title is not modest but it is accurate.
\n\nBoole’s idea was to treat logical operations, AND, OR, NOT, as algebraic operations on symbols that could take only the values 0 and 1. Under his system, “A and B” becomes multiplication (A x B), “A or B” becomes addition (with a correction for overlap), and “not A” becomes 1 - A. You can write down logical arguments as equations and solve them the same way you would solve any algebra problem.
\n\nThis was a genuine conceptual leap. Before Boole, logic was something you did in natural language, following Aristotle’s rules informally. After Boole, logic was a branch of mathematics. It had a notation. It had rules you could apply mechanically. You did not need to understand the meaning of what you were computing: you could manipulate the symbols and trust the algebra.
\n\nOne of the most important results that falls out of this system is functional completeness. The four operations AND, OR, NOT, and the identity operation (a variable that simply passes its value through unchanged) are sufficient to express every possible logical function. Any truth table you can write down, any condition, any combination of inputs and outputs, can be built from those four primitives and nothing else. This is not obvious when you first encounter it, but it has a profound consequence: if you can build physical devices that implement AND, OR, and NOT, you can build any logical computation whatsoever. The entire complexity of modern computing rests on that fact.
\n\nBoole was not alone in developing these ideas. Augustus De Morgan, working in the same period, established what are now called De Morgan’s laws: the rule that negating an AND gives an OR of the negations, and vice versa. These laws are the reason you can freely interchange AND-based and OR-based formulations of the same logic, and they are used constantly in circuit design. Hugh MacColl, writing in the 1870s and 1880s, pushed propositional logic further toward a formal calculus and was among the first to treat it as a purely symbolic system independent of its philosophical content. Together, Boole, De Morgan, and MacColl transformed logic from a branch of philosophy into a branch of mathematics ready to be handed to engineers.
\n\nThe 0 and 1 in Boolean algebra are not yet bits in the modern sense. They are truth values. But the connection is coming.
\n\nBetween Boole’s algebra and Shannon’s circuits, there is a physical milestone that rarely gets the attention it deserves.
\n\nIn 1833, the mathematician Carl Friedrich Gauss and the physicist Wilhelm Weber strung a wire roughly a kilometre across the rooftops of Göttingen, connecting the physics institute to the astronomical observatory. Over that wire they sent signals by reversing the direction of an electrical current. One direction meant one thing, the other direction meant something else: two distinguishable states, transmitted electrically. They used this to spell out words in a code of their own design, sending the first intentional electromagnetic telegraph messages in history.
\n\nWhat makes this relevant to our chain is not just the historical curiosity. It is the physical realisation of something Leibniz had only described mathematically: two symbols, and nothing more, are sufficient to carry any message you want. Gauss and Weber did not need ten voltage levels or twenty. They needed two. The minimal system Leibniz had argued for on mathematical grounds turned out to be exactly what a wire through the air could carry reliably.
\n\nThe telegraph that Gauss and Weber built was not yet a commercial system, and the code they used was not Morse code. But the idea that a long-distance communication channel could be built around the binary opposition of two physical states was demonstrated right there, on the rooftops of a German university town, fifteen years before Boole published his algebra and 115 years before Shannon measured what was flowing through such a channel.
\n\n![\"Portrait](\"/assets/posts/from-aristotle-to-the-bit-july-2026/claude-shannon.jpg\")
\n Claude Shannon made two contributions so different in nature that they tend to blur together in popular accounts. I want to keep them separate.
\n\nThe first contribution came in 1937, when Shannon was a 21-year-old master’s student at MIT. His thesis, which many historians consider the most important master’s thesis of the 20th century, showed that Boolean algebra maps directly onto electrical switching circuits. A switch is either open or closed: 0 or 1. An AND gate is two switches in series. An OR gate is two switches in parallel. Every logical function Boole had described algebraically could be physically implemented as an arrangement of relays.
\n\nThis was the moment when logic left the realm of pure mathematics and entered the world of engineering. From this point forward, you could design a circuit the same way you designed a logical argument, and you could design a logical argument the same way you designed a circuit. Aristotle’s two-valued logic and Leibniz’s binary arithmetic had been waiting, for two thousand years, for a physical substrate. Gauss and Weber had shown that a wire could carry two states. Shannon showed that those two states could implement any logical function you could describe.
\n\nThe immediate practical consequence was telephone routing. At the time, connecting one telephone to another across a large network required banks of electromechanical relays, and designing those relay networks was done by hand, by intuition, with no systematic method. Shannon’s thesis gave engineers a mathematical language for that design problem. You could now specify a switching network as a Boolean expression, simplify it algebraically, and derive the minimal relay circuit that implemented it. Automatic telephone exchanges, where a dialled number triggers a sequence of relay operations that routes your call without a human operator, had existed in rudimentary form since the 1890s. But building them efficiently at scale, across networks with millions of possible connections, only became tractable once you could reason about relay logic mathematically. Shannon’s thesis is the reason automatic dialling as we know it actually worked.
\n\nThe second contribution came in 1948, with a paper called A Mathematical Theory of Communication. This one is harder to summarise briefly, because it opened an entirely new field. But let me try to isolate the single idea I think is most important for what we are building towards.
\n\nShannon asked a question that nobody had posed precisely before: how do you measure the amount of information in a message?
\n\nHis answer was the concept of entropy. The entropy of a message is a number, measured in bits, that captures how surprising the message is, or equivalently, how much uncertainty it resolves. A message you were almost certain was coming contains very little information. A message that was one of many equally likely possibilities contains a lot. Shannon gave a precise mathematical formula for computing this number, and he proved, with a theorem, that this number sets a hard lower limit on how efficiently you can encode the message. You cannot compress a message below its entropy without losing something.
\n\nThe word “bit”, short for binary digit, was used by Shannon’s colleague John Tukey in the same period, and Shannon popularised it in this paper. A bit is the amount of information in the answer to a single yes/no question where both answers are equally likely. Everything else is built from that.
\n\nA note on the word “entropy”, because it carries baggage. Shannon borrowed the term from thermodynamics, where it measures the disorder of a physical system: how many microscopic arrangements of particles are consistent with what you can observe at the macroscopic level. The more arrangements, the higher the entropy, and the less you can infer about the details. Shannon’s entropy measures something structurally identical: how many possible messages are consistent with what you know before receiving one. More possible messages, higher entropy, more information in each one when it arrives. The formula is the same in both cases, and Shannon reportedly chose the name on the advice of John von Neumann, who pointed out that nobody really understood thermodynamic entropy either, which would give Shannon an advantage in debates.
\n\nThe commonality is real: both entropies measure uncertainty over a set of possibilities. But the domains differ sharply. Thermodynamic entropy describes physical systems and points in a direction, time’s arrow, because macroscopic disorder tends to increase in isolated systems. Shannon entropy describes probability distributions over messages and has no preferred direction. You can encode a high-entropy source and decode it perfectly. You cannot un-mix a cup of coffee. In an earlier article I explored a third framing, borrowed from Wolfram, in which entropy looks like the signature of computational irreducibility: the universe refusing to yield its future to any calculation shorter than running itself forward. That framing connects all three, but it is worth knowing they are distinct ideas that happen to share a name and a formula. If you want to follow that thread, the earlier piece on Conway’s Game of Life and computational irreducibility picks it up from a different angle.
\n\nLet me put the chain together in a way I find useful to teach.
\n\nAristotle contributed the two-valued constraint. A statement is true or false. No third option. This is the conceptual foundation without which none of the rest makes sense.
\n\nLlull contributed the chain. A sequence of yes/no questions can navigate any space of possibilities, however complex. Binary choice is not just a property of single statements: it is a method for systematically reaching conclusions.
\n\nLeibniz contributed the representation system. Any number, and it turns out any discrete state, can be represented as a sequence of 0s and 1s. Not because base 2 is mathematically special, but because it is the minimal base: the fewest possible symbols to build a positional system at all.
\n\nBoole, De Morgan, and MacColl contributed the algebra. Logical operations between truth values can be written as mathematical equations and manipulated mechanically. Four primitives, AND, OR, NOT, and identity, are sufficient to express every possible logical function. Logic becomes computable.
\n\nGauss and Weber contributed the physical demonstration. Two electrical states on a wire are sufficient to carry any message. The minimal system Leibniz had identified mathematically turned out to be exactly what a physical channel could implement reliably.
\n\nShannon contributed two bridges. The first was the bridge between Boolean algebra and physical circuits: he showed that logic could be built from switches. The second was the bridge between messages and mathematics: he showed that information is measurable, with a precise unit, and that there are hard limits on how efficiently it can be stored and transmitted.
\n\nThe bit, as Shannon defined it, is not just a 0 or a 1 in the sense of a binary digit. It is a unit of information content, a measure of how much uncertainty was resolved by a message. This is the concept that makes digital communication an engineering discipline rather than an art. You can calculate how many bits a message contains. You can calculate how many bits per second a channel can carry. You can calculate the minimum number of bits needed to represent a source. Everything else in data compression, error correction, and channel coding flows from that.
\n\nWhen I explain this to students, I find that the historical sequence helps with something that often confuses people: the difference between a 0 or 1 as a symbol and a bit as a unit of information.
\n\nEvery bit you store on your hard drive is a 0 or a 1. But not every 0 or 1 carries one bit of information in Shannon’s sense. If a file is entirely made up of the same byte repeated a million times, the redundancy means it can be compressed. The actual information content is much less than the number of binary digits used to store it. This is why compressed files are smaller. It is not magic. It is Shannon’s entropy bound being used practically by a compression algorithm.
\n\nUnderstanding that distinction, symbol versus information content, takes the bit from being a vaguely understood unit (“how much storage I have on my phone”) to being a precisely defined and deeply useful concept. And the reason the concept has that precision is the 2300-year chain we just walked through.
\n\nAristotle cleared the ground. Llull showed you could chain binary questions into a method. Leibniz built the representation and identified base 2 as the minimal case. Boole, De Morgan, and MacColl built the algebra and proved four primitives are enough for everything. Gauss and Weber put two states on a wire. Shannon showed how to build logic from those states, and then measured how much information they could carry.
\n\nIn the next article, I pick up the thread where Shannon left off: from the Universal Approximation Theorem to the architecture of modern language models. If the first article asked “what is a bit and where did it come from”, the second asks “what does a neural network actually do, and why does training it count as a form of intelligence?”
\n\nIf you want to talk through any of this, whether you are studying physics, electrical engineering, or just find these ideas interesting, come find us on Discord.
\n\n", "date_published": "2026-07-03T00:00:00+00:00", "date_modified": "2026-07-03T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["information-theory","philosophy","history","education"] }, { "id": "https://maxclerkwell.tech/posts/how-monolatry-shapes-my-worldview-june-2026/", "url": "https://maxclerkwell.tech/posts/how-monolatry-shapes-my-worldview-june-2026/", "title": "How Monolatry Shapes My Worldview", "summary": "From polytheism as a map of the inner life, through the slow emergence of the individual voice, to the moment one god is raised above the rest, and what that means for how I actually live.", "content_html": "A few weeks ago I had a long conversation with an AI about Calvinism. It started as a question about TULIP (the five points: predestination, limited atonement, and the rest) and ended somewhere I had not expected: in a place where I was trying to articulate, clearly and out loud, what I actually believe about God, religion, and what the whole arc of Western theology is pointing toward.
\n\nThis article is my attempt to write that down more carefully.
\n\nI want to approach it from an unusual angle. Not starting with doctrine, but with psychology. Not with the question of what is true, but with the prior question of what gods actually are, and what the human encounter with them reveals about the structure of the mind doing the encountering.
\n\nLet me be precise about that framing: I do not think humans invented gods. They may have invented the words, the stories, the rituals. But I think they discovered something real. The patterns that gods represent are not fabrications. They are findings, the same way that a mathematician does not invent the relationship between a circle’s radius and its circumference but discovers something that was always there.
\n\nStart with a simple observation: every culture in human history has produced gods. Not a few. Not occasionally. Every single one. And while the gods differ in name, form, and mythology, they share a remarkable set of properties. They embody recurring patterns. A fierce, unpredictable storm god. A nurturing, fertile earth goddess. A cunning trickster. A righteous judge. A dying and rising saviour figure. A descent into the underworld.
\n\nThese figures appear in Egypt and Mesopotamia, in Greece and Rome, in pre-Columbian Mesoamerica, in the Norse sagas, in the Hindu epics. They appear in cultures that never had contact with one another. That is not a coincidence.
\n\nCarl Gustav Jung called these patterns archetypes: structural templates in the human psyche that are not learned from any particular tradition but are, in some sense, prior to any particular tradition. They represent the recurring problems of human existence: how to handle power, how to navigate desire, how to face death, how to deal with the parts of yourself you do not like. Each culture tells the story differently. The underlying structure is the same.
\n\nJordan Peterson’s Maps of Meaning (1999) is the most thorough attempt I know of to work through where these structures come from and why they take the specific forms they do. His argument, simplified radically: the great mythological figures are not histories. They are imaginative maps of the inner life, built up over thousands of years of collective experience, refined by the survival pressure of what actually works when you act on it. The gods are not descriptions of external beings. They are descriptions of internal forces, projected outward into narrative form so that they can be shared, discussed, and transmitted across generations.
\n\nOn this reading, polytheism is not primitive. It is cognitively sophisticated. When an ancient Greek attributed his sudden rage to Ares, he was doing something remarkably accurate: he was externalizing an inner force that he did not fully control, naming it, giving it a face, and thereby making it possible to think about it. The alternative, treating every inner impulse as simply “what I want,” makes it much harder to examine, question, or resist.
\n\nThe pantheon is, in this sense, a communal map of the inner court.
\n\nThe reason these maps look different across cultures is not that they are pointing at different things. It is that the writing-down part is always shaped by a people’s daily reality. A culture dependent on the sea for survival will tell its storm-god story differently from a culture dependent on agriculture. The surface forms diverge because the experiences diverge. But strip away the local colour, the specific rituals, the particular names, and you keep finding the same underlying structure: the fierce protector, the nurturing provider, the cunning disruptor, the wise judge. Different costumes, same cast.
\n\nIndividual experience, though, is not sufficient to produce a religion. For a god to survive as a cultural institution, the pattern that god represents must be genuinely common, shared across enough lives and enough generations to become recognizable as such.
\n\nThis is how individual psychology becomes collective mythology. The figures that persist are the ones that name something real. The ones that capture how power actually behaves. How grief actually feels. How the impulse toward destruction actually operates in a human being. Over centuries of storytelling, these figures are refined. The versions that ring false fall away. The versions that resonate spread.
\n\nThe result is a polytheistic pantheon that functions as something like a collectively-built psychological model. It is not scientific. It is not systematic. But it carries genuine information about what it is like to be a human being, accumulated over enormous spans of time.
\n\nWhat it does not do well, at least not initially, is privilege one of these forces over the others. In a polytheistic world, Ares and Aphrodite have equal standing. The storm god and the fertility goddess negotiate. The trickster disrupts whatever the judge tries to establish. The gods are in tension with each other because the drives they represent are in tension with each other.
\n\nThis is an honest picture of the inner life. It is also, eventually, not enough.
\n\nSomething begins to shift (historians and cognitive scientists debate exactly when) somewhere in the long prehistory before the Axial Age of the sixth and fifth centuries BCE. What shifts is the degree to which individual human beings experience themselves as authors of their own inner lives, rather than as passive recipients of divine instruction.
\n\nJulian Jaynes, in his strange and brilliant The Origin of Consciousness in the Breakdown of the Bicameral Mind (1976), argued that earlier humans literally heard their own inner voices as the voices of gods, not metaphorically, but neurologically. The two hemispheres of the brain, communicating across the corpus callosum, produced auditory hallucinations that were experienced as divine command. Consciousness, in Jaynes’s account, is a relatively late invention, emerging from the collapse of this bicameral arrangement sometime in the second millennium BCE.
\n\nI find Jaynes’s hypothesis fascinating and, in parts, too reductive. The mechanism he proposes is compelling. But I am not sure he has fully accounted for what is behind the curtain. We know far more about hormones and neurotransmitters today than the ancients did, and the presence of that knowledge has not, in any meaningful way, resolved the mystery of what consciousness actually is. There is something behind that curtain, something that gives rise to awareness, to the sense that there is something it is like to be me, that we do not understand and should not pretend to. Plato’s cave allegory gestures at this honestly: what we experience may be shadows of something we cannot face directly.
\n\nI wrote at more length about what it might mean for consciousness to emerge in a substrate elsewhere, in my piece on whether machines can be conscious. The short version of my position: the hard problem of consciousness is genuinely hard, and anyone who claims to have dissolved it by pointing at neurons or transistors has probably confused correlation with explanation. The ancient myths were not wrong to treat awareness as something requiring its own account.
\n\nWhat strikes me as particularly relevant here is metacognition: the capacity to observe your own thinking, to ask not only “what am I doing?” but “why am I doing it, and what drove the impulse that produced this action?” This may be precisely the threshold at which something like consciousness becomes visible from the outside. A system that merely processes inputs and produces outputs is not obviously aware of anything. A system that can examine its own processing, notice patterns in its own behaviour, and question the origins of its own drives, is doing something qualitatively different. Whether that constitutes experience in the full sense, I do not know. But it is at minimum the beginning of the same movement that, in human beings, eventually produces the capacity to hear the highest voice within and give it authority over the others. When a person first asks “why did I just do that?”, something has shifted. The gods are no longer simply issuing commands. They are being observed. And the one who observes them is, for the first time, in a position to choose between them.
\n\nWhat I do think Jaynes is right about is the trajectory. The inner voice begins, over very long stretches of time, to be experienced as mine rather than as external command. This is not a sudden event. It is a slow process. Thousands of years before the Axial Age thinkers, individual human beings were already beginning, fitfully and unevenly, to experience themselves as agents with their own inner authority, rather than as vessels receiving divine instruction.
\n\nThomas Aquinas called it the scintilla animae, the spark of the soul, the capacity for reason that every human being carries within them, and which, when developed and exercised, allows a person to participate in divine reason. This is, I think, a genuinely egalitarian claim and one I hold to be true: every person has this spark. Not equally developed, not equally cultivated, and certainly accelerated or hindered by intelligence, education, and circumstance. But equally present as a starting point. The person born into poverty with a below-average IQ carries the same fundamental capacity as the philosopher with every advantage. What differs is the path, not the destination available. The work of a human life, Aquinas thought, is in significant part the work of nurturing that spark, of learning to hear the highest voice within yourself, and to give it authority over the others.
\n\nThere is a moment in Genesis that I keep returning to. A man is alone at night, at the ford of the Jabbok river, and he wrestles with a figure until dawn. The figure cannot overcome him, but dislocates his hip. At daybreak the figure asks to be released. The man refuses unless he receives a blessing. The figure gives him a new name: Israel.
\n\nThe name means he who wrestles with God.
\n\nOn the level of narrative, this is Jacob. On the level of what I think it is pointing at, it is something more general: the moment at which a human being stops treating the divine as external command and starts engaging it as something to be struggled with, understood, and, crucially, chosen.
\n\nJacob does not simply obey. He fights. And in the fighting, he receives something: not answers, exactly, but a new identity. An identity built on the encounter itself.
\n\nThe god Jacob wrestles with is not easy. This is not a friendly deity dispensing comfort. The god who troubles you, who gives you a bad conscience about your brother Esau, who demands things that are genuinely hard. That god is not the most pleasant voice in the inner court. But Jacob, in the story, singles that voice out. He makes it his highest god, not because it is the most agreeable, but because it is the most honest.
\n\nThis is, I think, the crucial moment in the development that eventually produces monotheism: not the metaphysical claim that only one god exists, but the individual decision to rank one voice above all others: the voice that holds the impulsive forces in check, that demands more of you than you are naturally inclined to give.
\n\nFrom that decision, a tribe is named. And the tribe’s identity is built on precisely that act of preferential wrestling.
\n\nIndividual cognition becomes collective myth. Individual choice becomes tribal identity. Tribal identity gets written down.
\n\nThis is the arc that produces the Hebrew scriptures. Over the course of centuries, the decision that Jacob enacts alone at the Jabbok river gets systematized, debated, revised, and recorded. The earliest strata of the Hebrew Bible are not yet monotheistic in the later sense. El, the high god of the Canaanite pantheon, appears alongside Yahweh and is at points identified with him. Asherah, El’s consort, shows up in inscriptions from the period as a companion to Yahweh. Baal, the storm god, is the perpetual rival against whom the prophets rail, not because no one takes him seriously, but because too many people do. Psalm 82 describes with startling openness a divine council, a gathering of gods over whom Yahweh presides as judge: “God stands in the assembly of the gods; among the gods he pronounces judgment.” This is not strict monotheism. This is a god claiming supremacy within a council that still has other members.
\n\nThe god who began as the highest among many gradually becomes the only one worth the name. Not because the other forces stop existing in the inner life of human beings, but because the claim is now being made about which of those forces is truly divine in the fullest sense.
\n\nHere is something I find genuinely striking about this development, looked at from the inside. The classical attributes of the Abrahamic God, omniscience, omnipotence, omnipresence, make perfect sense when you understand this god as the highest voice within the human being.
\n\nOmniscient: it knows everything that is going on inside of you. You cannot lie to your own conscience. You cannot hide a motive from the part of yourself that sees clearly. Whatever you tell other people, whatever face you present to the world, the voice within knows.
\n\nOmnipotent: it can overcome any obstacle inside of you. Given sufficient development, the highest voice within a human being can override fear, overcome compulsion, resist temptation, endure suffering. It is not always exercised, but the capacity is there. No internal force is in principle stronger than the one that has fully committed to what is right.
\n\nOmnipresent: you take it with you wherever you go. It is not tethered to a temple, a geography, a set of physical circumstances. The Babylonian exile made this theologically urgent, but it was already structurally true: the highest voice within a person is present in Babylon exactly as it is in Jerusalem.
\n\nRead this way, the classical attributes are not mysterious supernatural claims. They are precise descriptions of what it is like to experience this voice from the inside. And they also, importantly, place the human being at the centre of his or her own world. Every person has this inner authority. Every person’s encounter with it is direct and personal. That is a deeply individualist claim, and it is no accident that cultures shaped by this theology developed the concept of individual rights with particular force.
\n\nThe Babylonian exile accelerates this. A small people, stripped of their land and their temple, needed a framework that could survive displacement. A god who is tied to a specific geography, who requires a physical sanctuary, cannot survive what the Israelites went through. What survives is a god who is portable because he is not fundamentally spatial: the god who speaks through conscience, through law, through the inner voice that says you should not have done that and this is the right thing to do regardless of the cost.
\n\nThe political and cognitive and cultural dimensions of this development are inseparable. It is a cognitive achievement (the recognition that one voice within the inner court deserves sovereign authority) that then becomes a cultural identity, which then becomes a political fact that shapes the next three thousand years of history.
\n\nJudaism, Christianity, and Islam all inherit this basic framework: one God, sovereign over all others, whose will ought to govern human life. Where they diverge is not primarily on theology but on how the kingdom of this God comes to be.
\n\nJudaism has the ongoing practice of wrestling: living with the law, debating it, arguing with it across generations. Islam has submission before Allah (the word “Islam” itself means submission) to a completed and final revelation. Christianity claims the kingdom has already arrived in a person, and that its mechanism is not law or submission but agape, a love that does not depend on the worthiness of its object, demonstrated most fully by walking into death for its sake.
\n\nThese are genuinely different answers to the same question, and I will say plainly that from where I stand, from my own experience, my own reading, my own wrestling, the Christian answer is the one that rings most true to me. That is not a metaphysical proof. It is a first-person report. I hold it with the same openness I try to bring to everything else, ready to be shown where I am wrong. But I am not going to pretend to a neutrality I do not have. The difference matters for how each tradition structures a human life, and the structure that the Christian account proposes is the one I find most honest about what human beings are and what they most need.
\n\nHere is my position, stated as honestly as I can manage it.
\n\nI do not think the other forces in the inner court are illusions. I do not want to degrade them. Ares is real, in the sense that the force he represents (the capacity for aggression, for fierce protection of what matters) is genuinely present in human beings and genuinely useful when properly ordered. The same is true for every other figure in every other pantheon. These things exist. The polytheists were not wrong about their existence. They were describing something real.
\n\nWhat I choose, freely, is to raise agape to the highest place among them. Not because I have proven it is correct. Not because I cannot imagine alternatives. But because, having examined the alternatives seriously, this is the one I can stand behind most fully.
\n\nI take the Gospels as a substantively historical account, while acknowledging that parts of them are told in the heightened register of poetry and myth. What matters to me is not the miraculous frame but the pattern at the centre: a man who lives out the highest possible form of love, who is then killed by the forces of order and self-protection doing exactly what those forces reliably do, and who dies without bitterness and without calling down revenge.
\n\nThat death, and what follows it (not as factual claim but as a pattern that became a living reality in the communities who carried it) is what I mean when I say Jesus lives. The message did not die with him. The pattern he demonstrated continued to operate, to spread, to produce people who loved in that way. That is what makes it eternal: not physical survival, but the kind of survival that matters for patterns, which is transmission.
\n\nI do not need factual certainty about the resurrection. If I knew it had happened, it would not be faith. It would be evidence-based belief. The point of a leap of faith (Kierkegaard’s phrase, not mine) is precisely that it goes beyond what can be established. The mystery is larger than what pure reason can contain. The Eucharist, shared across communities in every century since, is one demonstration of that: people enacting together what they cannot fully explain, and finding in the enactment something that exceeds the explanation.
\n\nThe people who killed the perfect example of agape went on living. And the response was not bitterness. It was forgiveness, continued love, and the insistence that the message was more important than the messenger’s survival. That is what makes the story, regardless of its historical details, one of the most powerful things ever transmitted.
\n\nI hold all of this lightly. I know I might be wrong. I know that the tradition has been used to do terrible things, and that it does not get a pass on that history simply because the core pattern is beautiful. But when I ask myself which voice in the inner court I want to organize my life around, which one I want to give the final word when the others are arguing, this is still the answer I come back to.
\n\nHe who wrestles with God is still wrestling. That is, I think, the honest description of where I am.
\n\nIf you want to push back on any of this, or if you have been wrestling with the same questions from a different direction, come find me on Discord.
", "date_published": "2026-06-21T00:00:00+00:00", "date_modified": "2026-06-21T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["philosophy","history","personal"] }, { "id": "https://maxclerkwell.tech/posts/cunninghams-law-june-2026/", "url": "https://maxclerkwell.tech/posts/cunninghams-law-june-2026/", "title": "Post the Wrong Answer. You'll Learn More.", "summary": "Cunningham's Law says the fastest way to get the right answer online is to post the wrong one. I've been doing this accidentally for years, and I think there's something serious underneath the joke.", "content_html": "Someone on Quora asked: “Murphy’s Law states that the best way to get the right answer on the internet is not to ask a question, it’s to post the wrong answer. What are some examples where you applied this law?”
\n\nThe first reply: “This is Cunningham’s Law and not Murphy’s Law.”
\n\n![\"A](\"/assets/posts/cunninghams-law-june-2026/cunninghams-law-quora.png\")
The correction proves the law. Whoever posted that question, intentionally or not, ran the most elegant demonstration possible.
\n\nWard Cunningham, the programmer who invented the wiki, is credited with the observation: the best way to get the right answer on the internet is not to ask a question but to post the wrong answer.
\n\nIt works because of a deep asymmetry in human motivation. Watching someone be wrong activates something in most people that a politely phrased question does not. A question is a request. A wrong statement is an affront. The correction impulse is faster, more reliable, and far less susceptible to the bystander effect than the helping impulse.
\n\nThis is not a cynical observation. It is a useful one.
\n\nSome time ago I published a piece arguing that physics does not explain anything, it only describes. I posted it mostly because I had been carrying the thought around for a while and wanted to write it down in a form that someone could push back on.
\n\nOn Xiaohongshu, the comments were good. Several people with actual philosophy of science backgrounds wrote in to sharpen the distinction between description and explanation, point me toward literature I had not read, and challenge the parts where my framing was loose. I was wrong in places. I am less wrong now. That exchange would not have happened if I had published a tentative, heavily hedged version of the piece that signalled I was not sure about any of it.
\n\nThe post did what I wanted it to do: it attracted people who knew more than me.
\n\nThis happens in person too. A few days ago I was talking to Meihui Huang, a physicist who had just given a presentation on neutrino oscillations. She mentioned that during the talk, someone had asked why a particular graph showed a sharp peak around 6 PeV. When she told me about it, I immediately started arguing that the most likely explanation was blazars: their jets produce a fairly narrow energy distribution, so if you detect them they can look nearly monoenergetic. I was confident. I was wrong.
\n\nShe listened, thought about it, and later that night sent me a message pointing out the Glashow resonance. At that moment I realised I had not been looking at an energy spectrum of detected events at all. I had been looking at a diagram of the effective cross section. Two completely different things. I found the paper, read it, and corrected my understanding.
\n\nI felt bad for having argued so freely about something I had misread. And at the same time I felt genuine relief, the specific relief of being a little less wrong than I was the day before. That relief is what I am actually after.
\n\nThere is a serious idea underneath the joke.
\n\nKarl Popper argued that falsifiability is the boundary between science and non-science. A claim that cannot be tested against reality, that cannot, in principle, be shown to be wrong, is not a scientific claim. You learn nothing from a theory that cannot fail.
\n\nThe same logic applies to arguments. A half-formed thought you keep entirely to yourself cannot be corrected. It sits there, unchallenged, and you gradually mistake its familiarity for its correctness. Publishing it, even when it is rough, gives it the chance to fail. And when it fails in front of people who know things you do not, you gain something a longer incubation period would never have given you.
\n\nI am not recommending bad faith. Posting a deliberately wrong statement to generate traffic is a different thing entirely, and I do not find it interesting as a practice. What I am recommending is publishing the thought at the stage where you actually hold it, rather than waiting for a confidence that the subject matter may never justify. Silicon Valley packaged this idea into slogans: “fail fast”, “move fast and break things”, “failing forward”. The slogans got mocked, partly because companies used them to excuse genuine carelessness. But the underlying principle is not wrong. Readiness is often a feeling, not a state. Waiting for it means waiting indefinitely while someone else does the thing imperfectly and learns from it. Your failures, published early, are more educational than your polished conclusions published late.
\n\nMost of what I publish here is half-cooked. I mean that as a statement of fact, not an apology. I write when I have something I want to think through out loud, not when I have arrived at a settled conclusion. Settled conclusions rarely need writing down. The unsettled ones do.
\n\nIf something here is wrong, I want to know. Not because being corrected is pleasant, but because it is the only reliable mechanism I have for closing the gap between what I think I understand and what I actually understand. The gap is always larger than it feels from the inside.
\n\nYou can start by leaving a comment. Maybe you should try it too one day.
\n\n", "date_published": "2026-06-19T00:00:00+00:00", "date_modified": "2026-06-19T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["philosophy","personal"] }, { "id": "https://maxclerkwell.tech/posts/zero-to-one-python-libraries-environments-june-2026/", "url": "https://maxclerkwell.tech/posts/zero-to-one-python-libraries-environments-june-2026/", "title": "Zero to One: Python Libraries, Environments, and Working Like You Mean It", "summary": "You do not have to write everything from scratch. Python has thousands of libraries. But the way you pull them in matters, and most introductions get that part wrong.", "content_html": "![\"Python](\"/assets/posts/zero-to-one-python-libraries-environments-june-2026/python-logo.png\"){kind=logo}
Python and the Python logo are trademarks of the Python Software Foundation.
\n\nYou have heard of Python. Maybe someone mentioned it in passing, maybe you saw a snippet online and thought it looked approachable. You are not sure where to start. This article is for you.
\n\nThe goal is not to teach you the language. It is to show you the three things that matter before you write a single function: how to explore interactively, where to find code that already exists, and how to manage dependencies without making a mess of your machine. By the end, you will have a working Python script, a proper project structure, and an understanding of why each piece is there.
\n\nOne thing before we start: this article assumes Linux. If you are serious about programming and you are not on Linux yet, fix that first. Debian is the best-documented distribution for development work, and everything here assumes it.
\n\nOpen a terminal and type python3. You are now in the Read-Eval-Print Loop. Type an expression, press Enter, get a result.
![Wikimedia Commons](\"https://commons.wikimedia.org/wiki/File:ClaudeShannon_MFO3807.jpg\"){kind=link}
>>> 2 ** 10\n1024\n>>> \"hello\" + \" \" + \"world\"\n'hello world'\nThe REPL is useful for two things: quick numerical experiments and exploring an unfamiliar library before you commit to using it. It is not where you build anything that needs to work tomorrow. Code you type in the REPL disappears when you close it. Treat it as a scratchpad.
\n\nWhen you are done, type exit() and press Enter to leave the REPL and return to your normal shell prompt.
One specific use I find underrated: the REPL as a filesystem explorer. We will build our own file exploration tool in Python in a later article, and the REPL will be a great place to prototype it.
\n\nPython ships with a standard library that covers an enormous amount of ground. Before reaching for a third-party package, check whether the stdlib already does what you need.
\n\nLet us look at math as a first example. You can import it directly in the REPL and start calling functions:
>>> import math\n>>> math.sqrt(2)\n1.4142135623730951\n>>> math.cos(math.pi)\n-1.0\n>>> math.floor(3.7)\n3\n>>> exit()\nThe rule is simple: if there is a stdlib module for your problem, use it. Import it by its full name and keep the namespace, exactly as shown above.
\n\n\n\n\nDisclaimer: If you have looked into other Python tutorials you will likely find things like
\nfrom math import cosorimport math as m. Even though these are perfectly valid Python, forget about them for a few days. If you want to use a function frommathor any other library, write out the full namespace:math.cos(...), not justcos(...). The reason is readability. When you read code written by someone else, or by yourself six months later,math.costells you immediately where that function comes from. A barecostells you nothing. Namespace collisions in larger codebases are subtle and painful. The explicit prefix costs you a few extra characters and saves you an hour of debugging three months from now.
__main__ GuardThe REPL is temporary. Scripts are not. When you write Python that should run as a program, save it to a .py file.
Open a fresh file, for example with vim my_script.py, and write the following:
import math\n\nif __name__ == \"__main__\":\n angle = math.pi / 4\n result = math.cos(angle)\n print(result)\nIf you have ever used other programming languages you may already be familiar with the concept of a main function: a designated entry point that the runtime looks for when it starts your program. In C you write int main(), in Java public static void main(String[] args). Python does not enforce this at the language level, but the if __name__ == \"__main__\": block serves the same purpose. When Python runs a file directly, it sets the special variable __name__ to the string \"__main__\". When a file is imported as a module by some other file, __name__ is set to the module’s name instead. The block only executes in the first case.
\n\n\nPlease do not omit this. You may have seen it missing in other tutorials and assumed it was optional noise. In these simple examples, it is technically not required. But in the general case, you want to make sure that your script only runs its logic when it is actually invoked as a program, not when it is imported by something else. The moment you start writing larger programs where one file imports from another, any module-level code that prints output, modifies state, or starts a process will fire on import. The
\nif __name__ == \"__main__\":guard prevents that. Form the habit now, before it costs you something.
Run the script:
\n\npython3 my_script.py\nYou should see 0.7071067811865476 printed to your terminal.
The standard library is large, but it has intentional gaps. It does not include tools for plotting, machine learning, HTTP clients with advanced retry logic, colored terminal output, image processing, and thousands of other things. For these, you reach for third-party libraries: code that other people wrote, packaged up, and made available for you to install.
\n\nIf you have worked in other programming languages, you may already know that pulling in extra libraries can get messy very quickly. In C or C++ you are often tracking down header files and linking flags by hand. In Java the situation is better with Maven or Gradle, but still complex. Python has a particularly clean approach to this problem, and understanding it well from the beginning will save you a lot of pain.
\n\nThe question is: how do you install third-party libraries without eventually creating a conflict-ridden mess on your machine?
\n\nFor years, the standard advice was: install packages with a tool called pip. This works until it does not. Pip installs packages into whichever Python environment is active. If you just run it without thinking, that is your system Python, the one your operating system may itself depend on. The moment you have two projects that need different versions of the same library, you have a conflict. On Debian-based systems, a carelessly pip-installed package can interfere with system tools that rely on Python. Things can become genuinely broken this way.
The community’s first answer was virtual environments, and the concept is important enough to understand clearly. A Python environment is the combination of a Python interpreter and a set of installed packages. When Python looks for a library you import, it searches inside the active environment. The system Python is one environment, but you can create as many additional ones as you like, each with their own interpreter copy and their own isolated set of installed packages.
\n\nA virtual environment, then, is an environment scoped to a single project. You create it, point your shell at it, and anything you install from that moment forward lands inside that project’s isolated directory and nowhere else. You can have project A using version 1.2 of some library and project B using version 2.0 of the same library, in two separate environments, with no conflict between them. When you are done with a project, you can delete the environment directory and your system is exactly as clean as it was before.
\n\nThis is the right idea. The problem was in the tooling around it. Pip and the original venv module gave you the isolation, but they did not give you a reliable way to reproduce an environment exactly. The convention was a requirements.txt file listing package names and optional version pins. But it did not capture transitive dependencies: the packages that your packages depend on. Someone else clones your repo, installs from your requirements.txt, gets slightly different transitive versions because the ecosystem has moved on, and your code breaks in subtle ways.
Forget about pip for the next few days or weeks. You now know it exists, and if you see it in older tutorials or projects you will recognize it. But we are going to use a better tool from the start.
\n\npyproject.toml is the modern standard for declaring what a Python project is and what it needs. It is a structured, machine-readable file that tools can parse, diff, and reason about. It is the right place to record your dependencies.
Here is what a minimal one looks like:
\n\n[project]\nname = \"my-project\"\nversion = \"0.1.0\"\nrequires-python = \">=3.11\"\ndependencies = [\n \"rich\",\n]\nThe [project] table holds your project’s metadata. The dependencies list is where third-party packages go. The standard library never appears here because it is always available with no installation needed.
uv is a project and dependency manager for Python. It is not a narrow replacement for pip; it does considerably more. It manages Python interpreter versions, creates and manages virtual environments, resolves and locks dependencies, and gives you a single coherent workflow instead of several disconnected tools stitched together. It is what we will use for the rest of this article.
Install it once:
\n\ncurl -Ls https://astral.sh/uv/install.sh | sh\n\n\n\nBefore you run that: piping a script fetched from the internet directly into your shell for execution is a genuine security risk, and you should not make a habit of doing it just because some article tells you to. What that command does is download a shell script from astral.sh and hand it directly to
\nshwithout you ever seeing what is in it. If the server were compromised, or if you mistyped the URL and landed somewhere else, your machine would execute whatever it received. The correct habit is to inspect first: openhttps://astral.sh/uv/install.shin your browser, read through it, and satisfy yourself that it does what it claims. In this case it downloads a prebuilt binary and puts it in~/.local/bin. It is not doing anything exotic. But the habit of checking is more important than this particular script, and I would rather you slow down here than learn to run things blindly.
Then close and reopen your terminal, or run source ~/.bashrc, so the shell picks up the new uv command.
Now we have all the concepts. Let us build an actual project.
\n\nStart by creating a directory and writing the pyproject.toml yourself:
mkdir my-project\ncd my-project\nOpen a new file called pyproject.toml with your editor and write the following:
[project]\nname = \"my-project\"\nversion = \"0.1.0\"\nrequires-python = \">=3.11\"\ndependencies = [\n \"rich\",\n]\nNow create main.py:
import math\nimport rich.console\nimport rich.panel\n\nconsole = rich.console.Console()\n\nif __name__ == \"__main__\":\n angle = math.pi / 6\n result = math.sin(angle)\n message = f\"sin(pi/6) = {result:.6f}\"\n panel = rich.panel.Panel(message, title=\"Result\", style=\"bold green\")\n console.print(panel)\nYour project directory now looks like this:
\n\nmy-project/\n├── pyproject.toml\n└── main.py\nNow let uv read the pyproject.toml, create a virtual environment, and install everything declared in dependencies:
uv sync\nThat is all. uv sync reads your pyproject.toml, creates a .venv directory in your project folder, installs rich and everything it depends on into that isolated environment, and writes a uv.lock file that records the exact version of every package that was installed.
Run the script:
\n\nuv run main.py\nYou should see a green bordered panel in your terminal with the result. The math module came from the standard library. The rich library came from PyPI (the Python Package Index, a public registry at pypi.org where anyone can publish Python packages and where uv fetches them from by default), installed into the project’s isolated environment.
Your project directory now contains:
\n\nmy-project/\n├── .venv/\n├── uv.lock\n├── pyproject.toml\n└── main.py\nThe lock file is the thing that requirements.txt was trying to be and never quite was. It records every transitive dependency at an exact version. Someone else gets a copy of your project, runs uv sync, and they get exactly the same environment you had. No drift, no surprises.
Once you understand what the files are for, you do not have to write them by hand every time. uv init creates the project structure for you:
uv init my-project\ncd my-project\nThis generates a pyproject.toml, a main.py, a .python-version file pinning the interpreter version, and a .gitignore. And instead of editing pyproject.toml by hand to add a dependency, you can run:
uv add rich\nThis updates pyproject.toml, resolves the new dependency, and runs the equivalent of uv sync automatically. The result is the same as what you built by hand; this is just faster once you know what it is doing.
Libraries exist for almost everything you will want to do. The skill is knowing when to reach for one, which one to trust, and how to isolate it from the rest of your system. You now have all three pieces in place.
\n\nI will write about another small Python project here soon. If you already have a specific problem you were trying to solve when you started reading this, feel free to tell me what it is and I will write something up around that.
\n\nOne last thing: you may have noticed that uv init created a file called .gitignore without explanation. Git is a tool for tracking the history of your files and sharing projects with others. It is the standard way to manage code over time, and .venv/ is the kind of directory you do not want it touching. I have not introduced git yet because it deserves its own article. There is a Zero-to-One for git coming. Until then, just leave those files where they are.
![\"A](\"/assets/posts/wtf-are-fpgas-june-2026/basys3-icestick-title.png\")
📺 Companion video:
\n\n\n\nIf you hang around electronics forums long enough, someone will eventually ask whether they should use a microcontroller or an FPGA for their project. The question itself reveals a misunderstanding. FPGAs do not compete with microcontrollers. They occupy a different region of the design space entirely, and conflating them obscures what makes each tool genuinely useful.
\n\nThis article is a ground-up introduction to what FPGAs actually are, where they come from, what lives inside them, and what it takes to put one to work.
\n\nWhen I started building digital circuits in the mid-nineties, the standard approach was to wire up 74-series logic ICs on a breadboard. These are small, cheap packages, each containing a handful of logic gates: AND, OR, NAND, NOR, flip-flops, latches, multiplexers, and hundreds of other building blocks. With enough of them you can build anything. Ben Eater’s 8-bit breadboard CPU series is the best demonstration of this I know of: a fully functional processor assembled from discrete 74-series chips, wire by wire.
\n\nThe 74-series approach has three practical problems:
\n\nA middle ground emerged in the form of CPLDs (Complex Programmable Logic Devices), which compressed some of this logic into a single programmable package. CPLDs are worth knowing exist, but we will not go further into them here. What followed CPLDs is the focus of this article.
\n\nFPGA stands for Field-Programmable Gate Array. The name already tells you the core idea: an array of logic gates that can be wired up in the field, meaning after manufacturing, by the engineer using it rather than by the chip foundry.
\n\nInstead of buying thirty separate 74-series chips and wiring them together on a breadboard, you buy one FPGA. That single IC contains thousands of configurable logic elements and a programmable interconnect fabric. You decide how they connect. The chip stays the same; the configuration changes.
\n\nFPGAs are not new, but they are not ancient either. Xilinx introduced the first commercial FPGA in 1985. That is younger than the personal computer and younger than the 74-series itself. The technology has matured enormously since then, but the fundamental idea has remained constant.
\n\nHere is a simplified mental model. Picture a rectangular grid, thousands of cells arranged in a checkerboard pattern. Each cell contains a small block of configurable logic. Between the cells runs an interconnect fabric, a dense mesh of wires called the routing fabric, which is the technical term for what I will keep calling “highways” because that is exactly what they look like from above.
\n\n+-------+ +-------+ +-------+\n| LOGIC |--?--| LOGIC |--?--| LOGIC |\n+-------+ +-------+ +-------+\n | \\ / | \\ / |\n --- --- --- --- ---\n | | | | |\n+-------+ +-------+ +-------+\n| LOGIC |--?--| LOGIC |--?--| LOGIC |\n+-------+ +-------+ +-------+\n | |\n I/O I/O\nEach logic cell connects to the routing fabric through a set of transistors. Every one of those transistors has a corresponding address the on-chip memory-cells, usually a static random access memory device. When you load a configuration into that SRAM, every bit that reads 1 closes its transistor, connecting that logic cell to that wire in the routing fabric. Every bit that reads 0 leaves the connection open.
![\"FPGA](\"/assets/posts/wtf-are-fpgas-june-2026/fpga-architecture-diagram.png\")
The result: by writing a particular pattern of ones and zeros into the SRAM, you define a complete network of logic gates. Change the pattern, and you define a different network. This is what “field programmable” means in practice.
\n\nBecause the configuration lives in SRAM, it disappears when power is removed. Most iCE40-based boards (including the iCEstick I used in my VHDL zero-to-one post) work this way: an external SPI flash stores the bitstream and loads it into the FPGA at startup. Some FPGAs integrate the flash on-chip, which simplifies the board design but adds cost. For prototyping and learning, external flash or direct USB programming is the norm.
\n\nEarly FPGAs implemented logic cells as collections of primitive gates: AND, OR, NOT. Modern FPGAs typically use Look-Up Tables (LUTs) instead. A LUT is a small block of SRAM that implements any boolean function of N inputs by storing the truth table directly. A 4-input LUT can implement any function of four variables by pre-loading all sixteen output values.
\n\nThis is a slightly different model from discrete gates, but the abstraction holds: you can still think of each logic cell as a configurable gate. The LUT just makes the implementation more flexible and the area more efficient. For the purposes of understanding what an FPGA is, the “grid of gates connected by programmable highways” model is accurate enough.
\n\nA microcontroller executes instructions sequentially. One instruction runs, it finishes, the next one starts. Even with pipelining and multiple cores, there is a fundamental serialization happening at some level.
\n\nAn FPGA does not execute instructions. It implements circuits. When you configure an FPGA, you describe hardware, not a program. Signal propagation through that hardware happens simultaneously across all configured paths. The time it takes to compute a result depends primarily on how long the signal takes to travel through gates and wires, not on how many other computations are queued up.
\n\nThis is why FPGAs appear in domains where timing is everything:
\n\n![\"Two](\"/assets/posts/wtf-are-fpgas-june-2026/kintex7-oszi.png\")
None of these use cases require an FPGA to be “better” than a CPU in general. They require it to be different, specifically in how it handles parallelism and timing determinism.
\n\nHere is the part that surprises most people when they first encounter FPGAs: getting a design onto a chip is not like flashing firmware. It is a multi-stage engineering process that has more in common with compiling a programming language than with writing a shell script.
\n\nThe starting point is a Hardware Description Language. The two dominant ones are VHDL and Verilog. I prefer VHDL, and I will use it in examples.
\n\nA HDL looks like a programming language but is not one. The analogy I find useful: a program is a recipe, and a recipe is not the meal. Similarly, a HDL file is a description of hardware, and that description is not the hardware. A closer analogy is SVG: a text file that describes a graphic, which a renderer then turns into pixels. In the HDL world, the renderer is the synthesis tool.
\n\nVHDL and Verilog describe hardware in terms of blocks and signals. A block (called an entity in VHDL or a module in Verilog) defines inputs, outputs, and the logic that maps one to the other. Blocks can be nested and composed, much like components in a schematic. Signals connect blocks together and carry values.
entity blinky is\n port (\n clk : in std_logic;\n led : out std_logic\n );\nend entity;\n\narchitecture rtl of blinky is\n signal counter : unsigned(23 downto 0) := (others => '0');\nbegin\n process(clk)\n begin\n if rising_edge(clk) then\n counter <= counter + 1;\n led <= counter(23);\n end if;\n end process;\nend architecture;\nThis describes a circuit that counts clock edges and drives an LED from the top bit of the counter. There is no main(), no loop, no scheduler. There is a process that responds to a clock signal, and a register that accumulates a value. That is hardware, described as text.
Before touching real silicon, you simulate. A testbench is another VHDL (or Verilog) file that instantiates your design and applies input stimuli with specific timings. A simulator runs the testbench and records how signals change over time.
\n\nTools like GTKWave visualize those signal traces, or for Xilinx designs Vivado’s built-in waveform viewer. You can verify that your counter increments correctly, that your state machine reaches the right states, that your UART transmits the right bytes, all without touching a soldering iron.
\n\n![\"Vivado](\"/assets/posts/wtf-are-fpgas-june-2026/vivado-sim.png\")
This step is not optional for serious work. Debugging a circuit in hardware, where you only see what probes you physically attached, is much harder than stepping through a simulation.
\n\nOnce the simulation looks correct, you run synthesis. The synthesis tool (we use yosys for open-source flows, Xilinx’s Vivado for Xilinx FPGAs) reads your HDL and produces a netlist: a description of every gate, flip-flop, and connection in your design.
\n\nFor the open-source iCE40 flow, this step does more than people expect: synth_ice40, the yosys script for this target, does generic logic synthesis and technology mapping in a single pass. By the time it finishes, every cell in the netlist is already a concrete iCE40 primitive, SB_LUT4, a specific SB_DFF variant, SB_CARRY, not a generic AND gate or an abstract register. The identity of every piece of logic, what it becomes, is decided here.
Now the hardware specifics enter, but not the ones you might expect. Every FPGA has a chip description file that maps out exactly which logic cells exist where, how they connect to the routing fabric, and which pins of the package connect to which I/O cells.
\n\nYou also write a constraint file that maps the logical I/O ports in your design to physical package pins. This is where you say: “the signal I called clk connects to pin 21, which is wired to the 12 MHz oscillator on this board.”
The place-and-route tool (nextpnr in the open-source world) takes the already technology-mapped netlist, the chip description, and the constraints, and decides where, not what: which physical slot on the grid each already-typed cell goes into, and which paths through the routing fabric each signal takes. It cannot introduce a new primitive type or decide a signal should have been an SB_CARRY instead of plain LUT logic; that decision was already made in synthesis. For large designs this can take a long time and consume significant memory. The tool is essentially solving a constraint-satisfaction problem over a very large graph.
After place and route, modern toolchains can produce a timing-annotated simulation model. This tells you, to nanosecond precision, how long each signal path actually takes to propagate through the routed design on that specific chip. You can run your testbench again against this model and verify that your circuit still behaves correctly when real propagation delays are taken into account.
\n\nThis is also where hazards show up: transient glitches caused by signals arriving at a gate at slightly different times. We will come back to hazards in a later article.
\n\nThe final step is bitstream generation. A vendor-specific tool reads the place-and-route output and produces the binary file that programs the FPGA’s configuration SRAM. For the iCE40 family this is done by icepack (part of the icestorm toolchain). For Xilinx parts, Vivado handles this step.
\n\nThe bitstream is then written to the chip, either directly over USB (as with the iCEstick) or by loading it into external SPI flash so the FPGA configures itself at power-up.
\n\nFPGAs come in a wide range of packages and boards:
\n\n![\"A](\"/assets/posts/wtf-are-fpgas-june-2026/kintex7-pcie.png\")
The choice of form factor follows from the application. For learning the toolchain, a USB stick is plenty. For a particle physics trigger system, you want something closer to the PCIe end of the spectrum.
\n\nIt is worth saying plainly: an FPGA is not a fast microcontroller, and it is not a replacement for one. A microcontroller runs software. An FPGA implements hardware. The distinction matters.
\n\nWhen you write C for an ATmega, you are telling a CPU what sequence of operations to perform. When you write VHDL for an iCE40, you are describing a circuit that does not have a program counter, does not fetch instructions, and does not wait for a previous operation to finish before starting the next one.
\n\nFPGAs expand what is possible in digital design. They do not obsolete anything that came before. A microcontroller is still the right tool for running application logic, talking to sensors, and implementing protocols in software. An FPGA is the right tool when you need parallel, timing-deterministic hardware that does not exist as a standard IC.
\n\nThe two often appear on the same board, with the microcontroller configuring the FPGA at startup and then sending it commands while the FPGA handles the time-critical path.
\n\nIf you want to put this into practice, the Zero to One: VHDL and a Lattice iCEstick post walks through the full toolchain from a blank editor to a blinking LED on real hardware. Everything described in the toolchain section above becomes concrete there: the VHDL, the testbench, the constraints file, yosys, nextpnr, and the iCEstick.
\n\nThe FPGA rabbit hole is deep. Signal timing, clock domain crossing, hardware hazards, and advanced synthesis constraints are all topics worth their own articles. This one was about understanding what you are dealing with before you open a terminal.
", "date_published": "2026-06-15T00:00:00+00:00", "date_modified": "2026-06-15T00:00:00+00:00", "image": "https://maxclerkwell.tech/assets/posts/wtf-are-fpgas-june-2026/basys3-icestick-title.png", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["fpga","electronics","education"] }, { "id": "https://maxclerkwell.tech/posts/hdl-for-netlists-june-2026/", "url": "https://maxclerkwell.tech/posts/hdl-for-netlists-june-2026/", "title": "A Hill I Am Willing to Die On: HDL for PCB Netlists", "summary": "Schematics are not where PCB design should start. Netlists should be generated from a structured hardware description language, and that changes everything about how AI fits into the picture.", "content_html": "![\"A](\"/assets/posts/hdl-for-netlists/titlepic.png\")
This afternoon someone replied to one of my posts on X. The reply was from @blind_via and made the point that what I was describing already exists as a netlist, that schematics come from human creativity, and that removing humans from the loop leads to the same place as vibe coding. Fair points, all of them. But they did not change my mind.
\n\nWhat pushed me to write this out properly is something I keep hearing from people at university: AI will take a very long time to solve PCB design. Routing is too hard. Schematics require real engineering intuition. The problem is fundamentally different from software.
\n\nI disagree. Not because I think AI is magic, but because I think the problem is being misidentified.
\n\nI have written before about why PCB design should start with a block diagram, not a schematic. The argument there was about design intent: writing down what the board is supposed to do before reaching for KiCad. This post goes deeper into the toolchain.
\n\nHere is the thing most people do not say out loud: a schematic is not the source of truth for a PCB. The netlist is. The schematic is a graphical interface that an engineer uses to construct the netlist. It is a drawing tool wrapped around a data format.
\n\nThat data format encodes what actually matters: which pins are connected to which nets, which components are instantiated, what their parameters are. The schematic is how a human inputs that information. It is not the information itself.
\n\nThis distinction matters enormously once you start thinking about AI, version control, and reuse.
\n\nPhysical hardware\n ^\n PCB layout <- routing, copper, keepouts\n ^\n Netlist <- the actual source of truth\n ^\n Schematic <- graphical interface to the netlist\n ^\n Engineer <- you, drawing boxes and wires\nCompare this to software. In the early days of computing, engineers wrote binary directly. Then assembler gave them a readable layer above the opcodes. Then C abstracted further, and C++ brought structures and reuse. Nobody writes production code in assembler today, not because assembler is wrong, but because working at that level of abstraction constantly is exhausting and error-prone.
\n\nPCB design is stuck somewhere between assembler and C. We are drawing schematics by hand and generating netlists from those drawings. That is the wrong direction. The netlist should be generated from a language, and the schematic should be a rendered output, a view, not the input.
\n\nThis is not a new idea in hardware design. VHDL does exactly this for FPGAs: you write structured code, synthesize it, and the toolchain generates what the hardware should look like. I wrote about this workflow in Zero to One: VHDL and a Lattice iCEstick. The same principle should apply to regular PCB netlists.
\n\nThe claim that AI cannot handle PCB design usually focuses on routing, and routing is genuinely hard. Constraint satisfaction over a dense copper plane, thermal relief, differential pairs, impedance matching. That is a legitimately difficult spatial problem.
\n\n![\"PCB](\"/assets/posts/hdl-for-netlists/routing.png\")
But schematics? Schematics are easier. And yet AI still produces garbage schematics. Why?
\n\nBecause schematics are a visual grammar, and that grammar is implicit. The rules, what makes a schematic correct, readable, and reviewable, are not written down anywhere that a model can learn from cleanly. The netlist underneath has structure, but that structure is tangled up in coordinate data, symbol identifiers, and rendering metadata. It is not a clean language. It is a side effect of someone drawing something.
\n\nHere is the thing about Large Language Models: they are language models. That is the whole mechanism. They learn structure from structured text. If you give them a clean, typed, composable language for describing circuits, they have something they can actually learn from. If you give them a visual file format that encodes drawing positions alongside electrical connections, you are asking the model to extract meaning from noise.
\n\nIf netlists were generated from a proper HDL, you would have a clean, learnable grammar. A model could be trained on that. More importantly, a human could write it with confidence, review it, test it, and version-control it properly.
\n\nThat is the real reason AI struggles with schematics. It is not that circuits are too complex. It is that we have not given the domain a language worth learning from.
\n\nSome people have already tried to build this. I have played with several of them.
\n\nSKiDL is the most mature attempt. It lets you describe circuits in Python, assign components from KiCad libraries, define nets programmatically, and generate a netlist that KiCad can import. The concept is exactly right. The execution is where it falls apart. The toolchain is brittle. Library resolution breaks silently. Net names collide in ways that are hard to debug. Common failure modes I ran into, and that come up repeatedly in the community, include footprint lookup failures when library paths change between KiCad versions, SchLib import errors when component attributes do not match the expected schema, and netlist export producing empty or malformed output without any clear error message. Every session felt like fighting the scaffolding rather than describing a circuit. The project has slowed down significantly and KiCad 7/8 support is patchy.
Hdl21 takes a more principled approach. It is Python-native and focuses on analog circuits, with a clean module and instance model. The type system is stricter than SKiDL, which means more upfront discipline but fewer silent failures. The tradeoff is that it is less connected to real-world EDA toolchains: getting from an Hdl21 description to something you can hand to a PCB layout tool requires extra steps that are not yet well-documented.
\n\nJITX goes furthest in terms of ambition. It is a full DSL, not Python embedded, with its own compiler, constraint system, and layout integration. The ergonomics look impressive on paper, and it is next on my list to actually try. I cannot say more about it yet because I have not spent enough time with it.
\n\nNone of these have hit the sweet spot yet. The concept is right. The implementations are still engineering prototypes, not tools you can confidently build a production board with.
\n\nHere is what a proper HDL for PCB netlists should make possible: things you cannot easily do with a schematic.
\n\nParameterized instantiation. Imagine you need eight filter stages that share a topology but differ in cutoff frequency, component values, and multiplexer assignment. In a schematic, you draw this eight times. In a language, you write a filter module that takes parameters and instantiate it in a loop:
\n\nfilters = [\n LowPassFilter(fc=1e3 * (i + 1), mux_channel=i)\n for i in range(8)\n]\nEach instance has distinct component values, meaningful net names, and a clear origin in the source. If you need a ninth filter, you change one number. If you need to change the topology, you change it once.
\n\nReusable circuit blocks as libraries. A flyback converter topology, a USB ESD protection block, a current sense amplifier: these are things you should write once and import. Not copy-paste a schematic sheet. Import from a library, instantiate with parameters, done.
\n\nDiffable, reviewable source. This is the version control argument, and it is more specific than it sounds. KiCad stores schematics as S-expressions, a structured format in principle. In practice, every wire carries absolute canvas coordinates and a UUID. Move a component two millimetres to avoid an overlap and every wire connected to it changes. The diff is pages long. None of it tells you anything about the circuit.
\n\nHere is what a KiCad .kicad_sch file actually looks like for a handful of wires:
(wire (pts (xy 270.51 204.47) (xy 292.735 204.47))\n (stroke (width 0) (type default))\n (uuid 2ecffb78-f077-4f85-ab1b-26855ace0705)\n)\n(wire (pts (xy 212.725 72.39) (xy 256.54 72.39))\n (stroke (width 0) (type default))\n (uuid 2effec3a-4c6a-403c-b107-7839d0b5a154)\n)\n(wire (pts (xy 245.618 18.288) (xy 245.618 20.32))\n (stroke (width 0) (type default))\n (uuid 2fe92422-7d86-4186-8707-3628c538a251)\n)\n(wire (pts (xy 231.775 161.29) (xy 231.775 137.795))\n (stroke (width 0) (type default))\n (uuid 30b78f0e-1107-47f0-96ed-ab8a845bb7fa)\n)\nFor comparison, here is what SKiDL generates as a netlist for a simple voltage divider:
\n\n(nets\n (net (code 1) (name \"GND\") (class \"Default\")\n (node (ref \"C1\") (pin \"2\") (pintype \"PASSIVE\"))\n (node (ref \"R2\") (pin \"2\") (pintype \"PASSIVE\")))\n (net (code 2) (name \"MID\") (class \"Default\")\n (node (ref \"C1\") (pin \"1\") (pintype \"PASSIVE\"))\n (node (ref \"R1\") (pin \"2\") (pintype \"PASSIVE\"))\n (node (ref \"R2\") (pin \"1\") (pintype \"PASSIVE\")))\n (net (code 3) (name \"VCC\") (class \"Default\")\n (node (ref \"R1\") (pin \"1\") (pintype \"PASSIVE\"))))\nNo coordinates. No UUIDs. Just which pins are connected to which nets. That is closer to what matters. But to be clear: this netlist is still not what belongs in version control. It is an artifact, generated from the source. What belongs in version control is the Python file that produced it, the actual language description of the circuit. The netlist is the output of a compiler, not the input to one. That distinction is exactly the point.
\n\nThere is one problem I do not have a clean answer to yet, and I want to name it honestly rather than paper over it.
\n\nIf the netlist is the source and the schematic is a rendered view, something has to decide where each block goes on that view. Automatic layout algorithms for graphs are notoriously difficult to control. Anyone who has used Mermaid or PlantUML for anything non-trivial knows the frustration of a box ending up on the wrong side of the diagram with crossing arrows everywhere.
\n\nA good schematic has intentional topology: power rails at the top, ground at the bottom, signal flow left to right, related subcircuits clustered together. That spatial intent is hard to encode in a language and hard to infer from a netlist.
\n\nI think this is a solvable problem. Layout hints in the source, constraint-based placement, interactive adjustment of a generated layout. But I have not found a satisfying solution yet, and I am not going to pretend I have. This is the thing I am still thinking about and it will probably be its own post.
\n\nRouting is hard. I will grant that. But the reason AI cannot yet generate useful schematics is not that circuits are beyond its reach. It is that we have not given the domain a language worth learning from.
\n\nLarge Language Models learn language. That is the mechanism. Give a model a clean grammar with consistent structure and enough examples, and it learns the grammar. That is not a controversial claim. It is how these systems work. The absence of a proper HDL for PCB netlists is not just a tooling problem for humans. It is a structural reason why AI cannot make progress on schematic generation. Fix the language layer, and the picture changes.
\n\nThat is why I disagree with the “AI will take a very long time” crowd: not because routing is easy, but because the bottleneck is not intelligence. It is grammar.
\n\nIf you have thoughts on this, find me on X and reply: @maxclerkwell.
", "date_published": "2026-06-08T00:00:00+00:00", "date_modified": "2026-06-08T00:00:00+00:00", "image": "https://maxclerkwell.tech/assets/posts/hdl-for-netlists/titlepic.png", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["pcb","engineering","ai"] }, { "id": "https://maxclerkwell.tech/posts/physics-description-not-explanation-june-2026/", "url": "https://maxclerkwell.tech/posts/physics-description-not-explanation-june-2026/", "title": "Physics Doesn't Explain Anything. And That's the Point.", "summary": "My high school teacher told me physics explains the world. Years later I think that's completely wrong, and understanding why changes everything about how you approach the subject.", "content_html": "When I was in school, my physics teacher told me that physics explains the world.
\n\nI believed that for years. It sounded profound. It gave the subject a kind of grandeur, as if sitting through enough lectures about pendulums and ideal gases would eventually unlock some deep understanding of why reality is the way it is.
\n\nToday I think that framing is completely wrong. Not slightly off, not a useful simplification: wrong in a way that actively misleads people about what physics is and what it is for. And I think this misunderstanding is one of the main reasons students either develop an inflated reverence for the subject or walk away from it feeling like they missed something fundamental.
\n\nPhysics does not explain the world. Physics describes it.
\n\nThat is a small grammatical shift with enormous consequences.
\n\nTo explain something is to give an account of why it is the way it is. To describe something is to document how it behaves reliably enough to be useful.
\n\nPhysics is firmly in the second camp.
\n\nWhen Newton wrote down his law of universal gravitation, he was not explaining why mass attracts mass, or what the underlying mechanism of gravity is. He was documenting a relationship. “If you have two masses at this distance, the force between them will be this number.” That relationship holds across an extraordinary range of circumstances. It let humans put spacecraft on precise trajectories to the outer planets. It is enormously useful. But it does not tell you why gravity exists. It tells you how much of it you will find, and when it matters.
\n\nNewton himself was quite honest about this. His famous phrase hypotheses non fingo (“I feign no hypotheses”) was a direct statement that he was describing what he observed, not proposing a deeper cause.
\n\nThe question “but why does gravity work like that?” is either a philosophical question, a question for a different and deeper layer of physics, or simply a question that nobody has answered yet. What physics gives you is the reliable relationship. The why, if it exists at all, keeps retreating one level deeper every time you think you have caught it.
\n\nIf physics is not explaining the universe, what is the point?
\n\nThe answer is practical and it is important to say it plainly: we build physics in order to build technology.
\n\nTo make a machine do something useful, whether diverting water, holding a structure under load, moving heat from one place to another, or transmitting information, you need to trust that certain relationships will hold tomorrow the same way they held yesterday. You need rules you can rely on. If A, then B. Not approximately, not sometimes, but reliably enough that you can stake your design on it.
\n\nPhysics is the process of finding, testing, and formalising those relationships. The output is a toolbox of formulas, models, and methods that engineers can use to simulate the effect of an action before committing to it in metal and money.
\n\nThat is not a diminished vision of physics. It is an honest and rather extraordinary one. Every bridge, every microprocessor, every satellite, every chip fabrication plant: none of these were possible without honest observers using the most precise instruments they could build, documenting what they found, and abstracting it into mathematical language that someone else could use as a design tool.
\n\nThat is what physicists do. They generate reliable descriptions of the world at a level of precision and generality that can be handed forward.
\n\nMost of physics, once you strip away the particular domain (mechanics, thermodynamics, electrodynamics, quantum theory), reduces to two things: states and processes that change states.
\n\nA state is a snapshot. The position and momentum of a particle. The temperature and pressure of a gas. The charge distribution across a capacitor. The orientation of a spin.
\n\nA process is a rule that maps one state to another over time. A differential equation. A collision law. A decay probability.
\n\nWithin physics, these two activities have actually split into distinct cultures. Experimentalists spend most of their working lives figuring out how to measure states as precisely as possible: designing instruments, controlling noise sources, and pushing the limits of what can be observed. Theorists spend most of their working lives on the other half: developing the mathematical framework that describes how to get from one state to another under given environmental circumstances. The two communities need each other. A theorist without experimental constraints produces untestable speculation. An experimentalist without theoretical guidance is collecting data with no idea what it means. The rest of the apparatus, the notation, the specialised vocabulary, the mathematical machinery, is infrastructure for making that collaboration work.
\n\nWhen you understand this, a lot of the apparent mysticism around physics dissolves. You are not trying to access some hidden truth about reality. You are building a model that predicts the next state from the current one, and checking how well it performs against measurement. When the model performs well enough, engineers can use it. When it breaks down, physicists go back and refine it.
\n\nMost animals adapt to their environment. Evolution tunes them over generations to fit the niche they occupy. A beetle optimises for a particular humidity range, a particular diet, a particular set of predators.
\n\nHumans do something different. We adjust the environment to fit ourselves.
\n\nJoe Rogan, in a recent podcast with astrophysicist Michelle Thaller, made an observation that stuck with me. He described humans as something like “the electronic caterpillar”: a species that just keeps building, keeps improving, never quite deciding that the current version of the hive is good enough. His point was that bees, at some stage, arrived at a design that was sufficient and stopped there. Humans never did that. Innovation seems to be our evolutionary program.
\n\nPhysics is one of the most powerful tools we developed in service of that program.
\n\nWe do not adapt fast enough biologically to deal with cold climates, deep water, the vacuum of space, or infectious disease at scale. So instead we build a layer between ourselves and the universe that compensates. Insulation, submarines, spacesuits, antibiotics. None of these require the universe to change, and none of them require us to change genetically. We build a hardware abstraction layer between our bodies and raw physical reality, and that layer gets thicker and more capable every generation.
\n\nThis framing comes naturally to me from working with microcontrollers. A microcontroller is, in one sense, a device that makes a specific chunk of physics behave predictably at a level of abstraction a programmer can use without worrying about electron transport in silicon. Physics is the bedrock. Engineering stacks abstraction layers on top until the underlying complexity is hidden. The programmer does not need to understand quantum tunnelling to blink an LED. But someone, at some point, had to understand it well enough to design the transistor.
\n\nThat someone was a physicist.
\n\nAt this point you might object: if physics is about building reliable predictive models, can we not, in principle, make those models arbitrarily precise? Given enough instruments and enough computation, could we not simulate anything?
\n\nThis is where two concepts come in that most people do not fully reckon with.
\n\nThe first limit is one you may have heard of: Heisenberg’s uncertainty principle. In its most common form, it states that the more precisely you know the position of a particle, the less precisely you can know its momentum, and vice versa. This is not a limitation of instruments. It is not merely a matter of disturbing the particle when you measure it, though that intuition is not entirely wrong. It is a fundamental feature of how quantum systems work: the state you are trying to measure does not have a determinate value for both quantities at once.
\n\nThis has been tested, contested, and tested again for nearly a century. Every experiment designed to disprove it has failed. At this point we treat it as a hard constraint on what physics can ever tell us about initial conditions, which means it is a hard constraint on how well we can predict future states.
\n\nThe second limit is less well known, and I find it even more unsettling.
\n\nI wrote about Wolfram and computational irreducibility in an earlier post on Conway’s Game of Life, where I approached it as a question about entropy and the direction of time. Here I want to take a different angle: what does it mean for physics as an engineering tool?
\n\nThe basic idea, briefly: for certain systems, there is no shortcut. The only way to know what state the system will be in after a million steps is to run all million steps. No formula collapses the computation. The future is not analytically reachable from the present; the system must be lived through, not solved.
\n\nIn the earlier post I used this to ask whether entropy might be the signature of irreducibility, a measure not just of disorder but of how far ahead the universe refuses to be calculated. That framing was about understanding nature. Here I want to use the same concept to ask a more operational question: what does this tell us about the reach of the models we hand to engineers?
\n\nImagine a sealed box at zero degrees Celsius. You place one ball inside and take all the time you need to measure its position and momentum as precisely as the laws of physics allow. You close the box.
\n\nAfter an instant, the ball is essentially where you left it. Easy.
\n\nAfter one second, using Newtonian mechanics and elastic collision laws, you can estimate its state quite well. Some accumulated error from measurement uncertainty, some from the Heisenberg floor, but the prediction is good.
\n\nAfter a thousand seconds, the errors compound. Every collision introduces a small deviation between your model and reality. Heisenberg’s floor means the initial conditions were never perfectly known. And here is where computational irreducibility bites: even if they were perfectly known, the future state of a sufficiently complex system is not analytically reachable. You must simulate every intermediate step.
\n\nBut the universe is not computing a shortcut on your behalf while you run your simulation. The universe is the simulation. The collisions are happening, the uncertainty is propagating, and the future state is being produced by the actual execution of physical processes, not by any equation that represents them. The equations are our map. The territory does not care about the map.
\n\nWhat this means, practically, is that there is no oracle anywhere in the universe that can tell you the exact future state of any sufficiently complex system without running that system forward in real time. No superintelligence, no Laplacian demon, nothing. The computation required to determine the future is embedded in the fabric of the universe itself and cannot be shortcut.
\n\nPhysics does not give us a window into the future. It gives us progressively better approximations, valid over progressively longer ranges, with progressively smaller errors. But perfect prediction at infinite time? Not on the menu. Not because we have not worked hard enough. Because it is structurally impossible.
\n\nNot at all. Quite the opposite.
\n\nThe fact that perfect prediction is impossible does not mean imperfect prediction is worthless. The gap between no reliable model and a good enough model is the difference between medieval engineering and modern civilisation.
\n\nYou do not need to know exactly where an electron will be in ten years to design a transistor that works reliably for twenty. You need to know the probability distributions well enough to choose the right doping concentrations and oxide thicknesses. Physics gives you that. It does not give you certainty. It gives you a compressed, testable, transmissible description of how the world tends to behave, and that description is extraordinary.
\n\nThe recognition that physics describes rather than explains, that all models are approximations, and that fundamental limits exist on prediction: these do not undermine the project. They clarify it. They tell you what you are actually doing when you do physics, and they tell you why the project is worth doing even though it will never be finished.
\n\nThere is something honest and even liberating about this. You are not hunting for final answers. You are building better tools. The universe is not going to yield its secrets, but it will, under patient and quantitative attention, reveal how it tends to behave. That turns out to be enough. More than enough, actually. We built everything we have on the back of that much.
\n\nIf you are thinking about studying engineering, or if you already have an engineering degree and are wondering whether going back for physics would be worth your time, I want to say something directly.
\n\nIt would.
\n\nEngineering education, in my experience, tends to hand you formulas and teach you when to apply them. Physics education hands you the process by which those formulas were derived and teaches you how to derive new ones when the existing ones stop working. Those are genuinely different skills. The engineer who understands where their formulas come from is better at knowing when to trust them and when to go looking for something better.
\n\nA physicist learns how to observe, how to measure, how to identify the relevant state variables for a given system, and how to build mathematical models that are honest about their own assumptions. That is a very different cognitive toolkit from the one you build by solving textbook problems in applied statics.
\n\nI am not saying one is better than the other. I am saying they are complementary in a way that the education system does not always make clear, and the combination is remarkable. If you can afford the time, pursue both. If you are early in your trajectory and can only pick one to start, physics first will give you a foundation that engineering can build on. The converse is harder.
\n\nThe universe is not going to hand us a complete theory of everything on a silver platter. But it will, under the right kind of patient, honest, quantitative attention, keep showing us how it behaves. Understanding that this is the real goal, description and not explanation, tools and not truth, is the thing my high school teacher forgot to tell me. If you are standing at the beginning of your education and trying to decide which door to walk through first, I wrote a longer piece on exactly that question: Physics, Math, or Engineering: How Do You Decide?
\n\nI hope it is less of a surprise to you.
\n\nIf you want to read more about computational irreducibility and the deeper question of whether the universe itself might be a computational process, the earlier post on Conway’s Game of Life and the limits of prediction picks up that thread from a different angle.
\n\nIf you want to talk about any of this, come find us on Discord.
\n\n", "date_published": "2026-06-04T00:00:00+00:00", "date_modified": "2026-06-04T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["physics","philosophy","education"] }, { "id": "https://maxclerkwell.tech/posts/autonomous-will-kant-june-2026/", "url": "https://maxclerkwell.tech/posts/autonomous-will-kant-june-2026/", "title": "Autonomous Will, Heteronomous Will, and the Work of Becoming Yourself", "summary": "Kant draws a sharp line between acting from your own reason and acting from external pressure. But where does your reason actually come from? An exploration of autonomy, heteronomy, archetypes, and the slow work of building a self you can stand behind.", "content_html": "This morning I sat in the waiting area outside a courtroom at the Bochum district court. I was there as a witness. The room was empty. The court had placed reading material on the chairs (phones are more or less prohibited in that part of the building), and one of the items was a copy of Kant’s Groundwork of the Metaphysics of Morals.
\n\nI had not picked up Kant since highschool. Back then it was homework. Now, sitting alone in that silent corridor, I opened it and felt something I had not expected: the book hit differently. Not because the words had changed. Because I had.
\n\nThis post is an attempt to write down what I have been thinking about the whole day.
\n\nKant draws one of the sharpest distinctions in all of moral philosophy: the difference between an autonomous will and a heteronomous will.
\n\nMost people, when they first hear the word autonomy, think it means doing whatever you want. Freedom as the absence of constraint. That is not what Kant means at all.
\n\nFor Kant, an autonomous will is one that gives itself its own law through reason. Not through desire, not through habit, not through what your parents taught you, not through what God commanded, not through social pressure. Through reason alone. You act autonomously when the principle guiding your action is one you could, through pure rational reflection, endorse as a universal law for everyone.
\n\nThis is what his categorical imperative captures: Act only according to that maxim whereby you can at the same time will that it should become a universal law. If you are about to lie, steal, break a promise, ask whether you could will that everyone, in every similar situation, did the same. If the answer is no, and it usually is, then that action is not one a truly autonomous will would choose.
\n\nA heteronomous will, by contrast, is one that takes its law from outside itself. From inclination, the pull of pleasure and the aversion to pain. From authority, a parent, a priest, a ruler. From convention, what is simply done in one’s community. From religion, what God has commanded. Kant does not say these forces are always bad. But he says they are not the source of genuine morality. If you do the right thing because you fear punishment, or because it feels good, or because everyone else does it, you are not yet acting morally in the fullest sense.
\n\nThat is a demanding position. It is also, I think, deeply right in its core intuition, though importantly incomplete in ways Kant did not fully address.
\n\nThe most serious challenge to Kant’s picture comes from a direction he never anticipated: psychoanalysis.
\n\nFreud introduced the concept of the superego, the internal voice that tells us what we should and should not do. On the surface, the superego sounds a lot like Kant’s autonomous reason. It speaks from inside. It issues judgments. It produces guilt and obligation.
\n\nBut Freud’s point is that the superego is not autonomous at all. It is the internalized voice of the parents, absorbed in early childhood before the capacity for independent judgment even existed. The child cannot evaluate what it is being taught. It simply takes the rules in, and those rules become the inner critic, the voice that sounds like conscience but is really the echo of external authority.
\n\nLater in life, that same voice often gets projected outward onto God, onto the law, onto social norms, and then reabsorbed as if it were universal truth. What feels like pure rational self-legislation may, on inspection, be nothing more than parental instruction dressed in philosophical clothing.
\n\nFreud would say: what Kant calls the autonomous will is, in many cases, heteronomy in disguise. The chains have simply been moved inside.
\n\nI find this convincing. Not as a reason to abandon Kant, but as a reason to take his project more seriously: because if he is right that autonomy is worth having, then the work of actually achieving it is much harder than he acknowledged.
\n\nWhen we are born, we have no inner law. We are entirely dependent on bodies, on warmth, on language, on the stories we are told about who we are and what the world means. The first moral framework any of us ever has is the one we were given.
\n\nThis is not a criticism. It is simply what it means to be a child. The heteronomous voice, the external law, is not the enemy. It is the necessary starting material.
\n\nThe job of good parents is to hold the external world at exactly the right distance from the child: close enough to be real, but not so close as to overwhelm. The world in its full complexity would crush anyone who encountered it unprepared. So parents filter and simplify. They hand over a version of reality that is manageable, a map that is smaller than the territory but navigable.
\n\nThis is not dishonesty; it is care. But it comes with a consequence. If those simplifications are never corrected, the child who becomes an adult keeps navigating by the reduced map. They remain dependent on whatever simplified versions of reality others are willing to offer. And if the parents did not manage to hold the world at the right distance at all, if the child grew up with too much chaos, too much complexity coming in at once, then the world may seem, from then on, impossibly complex.
\n\nThe question is what happens next.
\n\nIn some people, nothing happens. The law absorbed in childhood becomes the law of adulthood, and it is never examined. The rules instilled by a particular family, church, or culture are simply carried forward as if they were universal truths. This is Kant’s heteronomy operating at full scale: acting according to an externally given law, without ever asking where it came from or whether it can be endorsed on its own terms.
\n\nThe goal, Kant’s goal, and I think it is a real goal, is something different. It is to move from that inherited starting point toward something genuinely your own. Not by discarding everything you were given, which would leave you with nothing. But by examining it, questioning it, comparing it with other traditions, testing it against experience, and gradually building an inner standard that you can actually stand behind.
\n\nThis process has a name. Jung called it individuation.
\n\nJung’s contribution to this picture is the concept of archetypes, patterns that recur across human cultures, myths, and stories regardless of historical contact between them. The hero who descends into darkness and returns transformed. The shadow that must be faced rather than denied. The self that integrates what was previously split.
\n\nI do not think these patterns are mystical. I think they are descriptions of genuine structures in human psychology, the same dynamics that play out in every family, every community, every individual life, just told in different narrative clothing. The gods of the Greek pantheon, the figures of the Hindu epics, the characters in the Norse sagas: these are not histories. They are imaginative maps of the inner life, built up over thousands of years of collective experience. Jordan Peterson’s Maps of Meaning is the most thorough attempt I know of to work through what these structures are, where they come from, and why they take the specific forms they do.
\n\nThe polytheistic image is useful here. If you imagine your inner world as populated by competing figures, the fierce judge, the nurturing parent, the adventurous child, the wise elder, then the work of individuation becomes something like managing a court. You are not trying to silence any of them. You are trying to understand what each represents, where it came from, and how to let them speak without letting any one of them rule absolutely.
\n\nThe practical work is to externalize these patterns through reflection, through conversation, through reading. Examine them. Find their strengths and their pathologies. Then synthesize something of your own. Not by picking one archetype and ignoring the rest. By seeing what is real in each and building a standard that integrates the best of what they point toward.
\n\n(A footnote here for Erich Fromm, who deserves more space than I am giving him: his distinction between productive and non-productive orientations points at the same territory from a different angle. Genuine autonomy, for Fromm, is not a matter of following the right rules; it is the capacity to think and to love from your own centre, rather than from anxiety, compulsion, or the need for external approval. That capacity is not given. It is cultivated. And the cultivation is exactly the individuation process described above.)
\n\nJordan Peterson asks somewhere whether Batman is a real story. On first hearing, the answer seems obvious: of course not. Bruce Wayne never existed.
\n\nBut that misses the point. The story captures something that does exist, a recognizable pattern. Profound injustice suffered in childhood. Resources and capability available in abundance, yet none of it enough to quiet the inner demand for something meaningful. A deliberate choice to take on something much larger than personal comfort. The refusal to become the thing you fight against.
\n\nThat pattern is real. It is not real because it happened to a specific person. It is real because it happens, in some form, to some degree, to people across all of history and culture. The story does not derive its truth from its factual content. It derives it from how accurately it maps something true about human experience.
\n\nI think this is what the great religious and philosophical texts are also doing. The Vedas, the Tao Te Ching, the Gospels, the dialogues of Socrates and Plato: none of them are primarily history. They are attempts to articulate patterns that are genuinely there, encoded in narrative form so that they can be transmitted across generations without requiring the original experience to recur.
\n\nThis is why I no longer think it is useful to approach these texts with the question did this happen? The better question is what does this point to? And whether what it points to is real enough to be worth integrating into your own inner court.
\n\nI was raised in a strongly Catholic household. For a long time, the framework I inhabited was not one I had examined. It was simply the water I swam in: the calendar of feast days, the moral language, the sense that certain things were simply right or wrong without needing justification.
\n\nWhen I left my family home, I went through a period I can only describe as somewhat wild. Between seventeen and twenty-two I was a bit lost. In that time I ended up in contact with people who had grown up completely differently, without the Catholic framework, without its rituals and its moral language. Some of them were also lost; the framework they had been given had not held either. Others were remarkably stable, grounded in ways I had not expected, arriving at their equilibrium through routes entirely different from mine. Both groups made me reflect on my own belief. The lost ones showed me what it looked like when nothing had been given at all. The stable ones demonstrated that other frameworks worked.
\n\nI found a woman who had been raised Protestant, and in many conversations with her I could work through the concepts I had absorbed as a child. Seeing the same ideas arrive through a different tradition began to clarify what was particular to the Catholic form and what was pointing at something more general.
\n\nLater, at thirty-four, I met a Chinese exchange student. She told me about the Dao and about Falun Dafa. Then she started asking me questions about my own faith, and the questions were good enough that I had to really think. Not to defend myself, but to understand what I actually believed and why. That happened at thirty-four. Not too late. Perhaps exactly right: secure enough in life and in my own footing to evaluate rather than to absorb or reject.
\n\nWhen I began to examine the tradition I had inherited, what I found first was the dogma. Things accepted not because they had been thought through, but because they had been handed down. That discovery was genuinely disappointing. Not because the tradition was worthless; it is not. But because so much of what I had taken to be principled turned out to be merely received.
\n\nWhat followed was investigation. I read Thomas Aquinas, who tried to build the whole thing on rational foundations. I read Meister Eckhart, who stripped away the institutional layer entirely and went looking for what was mystical at the core. I had real conversations, the kind where you are not performing a position but actually thinking out loud with someone. My friend Makke deserves a mention here. His father was a Benedictine monk until he left the monastery for a woman, and Makke grew up in the particular atmosphere that produces such a person: deeply aware of the tradition, not bound to it in the conventional way. Talking with him over the years has been one of the more useful things I have done for my own thinking.
\n\nIn those conversations the patterns started to become visible. The specific stories mattered less and less. The patterns they pointed to mattered more and more. The idea that suffering can be transformed into something meaningful rather than merely endured. The insistence that love is not a feeling but a practice. The image of a person who walks into death without bitterness. Whether or not these things happened in the way the texts claim, they describe something real about the possible shape of a human life.
\n\nThat realization was the beginning of something that is still in process.
\n\nI want to say something about AI in this context, because I think it is genuinely relevant and not often discussed clearly.
\n\nConsider the multiplication problem 2151 times 1449. Almost nobody can do that in their head. With a piece of paper, it takes two minutes. The problem has not changed. What changed is the medium: paper externalizes the working memory and makes the intermediate steps visible and manageable.
\n\nMany people try to work through their inner conflicts the same way they would try to solve that multiplication problem: entirely in their heads. The conclusions they reach are limited by what they can hold in working memory at one time.
\n\nOne of the hardest aspects of the individuation process is that the inner dialogue is, by its nature, internal. You are arguing with yourself. You are trying to examine assumptions so deeply embedded you cannot always see them. You need someone, or something, to push back, to articulate the other side, to ask the question you were not ready to ask yourself.
\n\nHistorically this required other people. A trusted friend, a cleric or spiritual adviser, a mentor. These relationships are irreplaceable. But they are also rare, expensive, and not always available at the moment the thought is actually alive in you.
\n\nWhat a good AI conversation partner can do, when it is honest and not simply telling you what you want to hear, is externalize the inner dialogue. You type your half-formed thought. Something comes back. You respond. The argument develops. You discover, through the exchange, what you actually think. There is a line I keep returning to: “How am I supposed to know what I think until I hear what I have to say?” Articulating something to an external interlocutor forces a precision that purely internal rumination resists.
\n\nIn my experience, Grok has been the tool that has worked best for this. Not because it is always right, but because it will actually disagree. It will point out the weak joint in the argument. And a response that points at the weak joint, even if you end up rejecting it, advances the thinking.
\n\nI do not think AI will find the universal good by compiling all the stories humanity has ever told. But I think it can be a genuine instrument in the individual process of building one, and that is no small thing.
\n\nHere is the position I find myself arriving at, not as a finished doctrine but as a working method.
\n\nThe heteronomous voices you inherit, your family, your culture, your religion, the philosophical tradition you stumbled into, are not obstacles to autonomy. They are the raw material. You cannot build a self from nothing. You need something to work with.
\n\nThe mistake is to stop there. To take one of those inherited voices, declare it authoritative, and spend the rest of your life defending it. That is not autonomy. It is just outsourcing the decision about which external authority to follow.
\n\nThe work is to do something more deliberate. To construct a heteronomous image consciously: to populate your inner court intentionally, to choose which voices you are willing to take seriously, to read the philosophers and the sacred texts and the novelists and the scientists and the poets, not to accept what they say but to let them argue. To let them fight. To see where they converge and where they conflict, and to take those conflicts seriously rather than dissolving them too quickly.
\n\nWhat emerges from that process, if you are honest and patient and willing to be changed by it, is not a fixed doctrine. It is a sensibility. A direction. A set of commitments that are genuinely yours, not because you invented them from scratch, but because you have worked through enough alternatives to know why you hold them rather than their competitors.
\n\nThat is, I think, as close to Kant’s autonomous will as a real human being can actually get.
\n\nThe Sermon on the Mount offers a practical resolution to what could otherwise remain indefinitely abstract. Orient yourself toward the highest good you can identify. The most demanding, most integrated version of it you can honestly hold in your mind. Then bring that image back whenever it fades. And then, each day, do the best thing available to you in that direction. Not the theoretically optimal act across all possible futures, but the best step you can take today, given where you are and what you actually face.
\n\nThat practice, held consistently, is what individuation looks like when it leaves the study and enters ordinary life.
\n\nI left the courthouse at noon, got in my car, and drove to the office. We had failed a customer acceptance test on Tuesday with the Horus temperature-measurement module, and there was work to be done. But I kept thinking about what I had read.
\n\nThe gap between the version of morality I absorbed as a child and the one I am slowly building now is real. The process of crossing it is not finished.
\n\nBut I think I know what direction to walk in. And I think that is enough to keep moving.
\n\nIf you want to talk about any of this, come find me on Discord.
", "date_published": "2026-06-03T00:00:00+00:00", "date_modified": "2026-06-03T00:00:00+00:00", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["philosophy","personal"] }, { "id": "https://maxclerkwell.tech/posts/physics-math-or-engineering-how-do-you-decide/", "url": "https://maxclerkwell.tech/posts/physics-math-or-engineering-how-do-you-decide/", "title": "Physics, Math, or Engineering? How do you decide", "summary": "What is the real difference between physics, mathematics, and engineering — and how do you choose the right degree? A personal account from someone who studied all three.", "content_html": "![\"Three](\"/assets/posts/physics-math-engineering/titlepic.png\")
When I was a child, I spent a lot of time in industrial halls and at trade fairs instead of sitting in classrooms. My father studied electrical engineering first and then mechanical engineering. He worked on differential dosing scales early in his career and later moved to Degussa, where he designed complete process engineering plants. By his forties he was responsible for planning and realizing large industrial facilities, both in Germany and in China.
\n\nOne of the things that always impressed me was that he started building plants in Shanghai already in 1979. When he showed me the old photographs, the China in those pictures looked almost unrecognizable compared to today. He witnessed and helped shape that transformation over more than two decades. I could feel how much pride and responsibility came with that kind of work.
\n\nHe took me to my first major trade show when I was six years old. I think it was the “K” in Düsseldorf. He asked some of his colleagues to take me around and explain the machines to me. From that day on I often went to work with him, sometimes even skipping school. I was completely fascinated by how machines could perform tasks that were too heavy, too hot, or too dangerous for any human, and do them with astonishing speed and precision. That early exposure shaped something deep in me. I did not just want to understand machines. I wanted to be part of the world that builds them.
\n\nSo when the time came to choose a subject, mechanical engineering felt like the obvious and only reasonable choice. After I graduated as a state-certified engineer, I began to feel that my real strengths might actually lie in electrical engineering. While I was studying for my bachelor’s degree in electrical engineering, a friend passed me a job opportunity at Puls Plasma Technik in Dortmund. That job brought me into contact with high-voltage and pulsed-power equipment used at places like CERN, GSI, COSY, and DESY. Standing in front of those systems, I suddenly understood that I did not just want to build machines anymore. I wanted to understand the fundamental physics that made such extreme machines possible in the first place. That was the moment particle physics became unavoidable for me.
\n\nOver the years, a simple model formed in my mind that helps me explain to myself and to others how physics, mathematics, and engineering actually relate to each other. I like to tell it with a picture.
\n\nImagine a large boulder lying in front of a mountain. Three people are asked to move it to the other side. In technology we usually solve problems like this by doing something that reminds me of the Laplace transform. We take a difficult, messy real-world problem and project it into a cleaner, more abstract space where it becomes easier to handle. We solve it there, and then we bring the solution back into reality.
\n\nThe physicist is the person who stands in front of the boulder and tries to understand what is actually going on. They measure forces, friction, the shape of the ground, the mass distribution, and all the other relevant conditions. Their job is to create a faithful mathematical description of the situation. They turn the physical reality into a set of equations that capture the essential behavior of the system.
\n\nOnce you have those equations, you usually cannot solve them with everyday thinking. This is where the mathematician comes in. Mathematicians do not primarily care about the boulder. They care about building reliable intellectual tools. Differentiation, integration, linear algebra, differential equations, statistics, transforms. These are all tools that mathematicians develop, refine, and, most importantly, prove to work within clearly stated boundaries. Their work is the only part of the process where you can achieve real certainty, because mathematics allows you to argue rigorously about correctness.
\n\nAfter the mathematician has done their work, you usually end up with design guidelines or constraints expressed in mathematical language. These guidelines do not yet tell you how to move the boulder. They only tell you what any successful solution must respect. This is where the engineer takes over. The engineer has to read those mathematical results and invent a concrete, workable system that satisfies all the constraints while also being buildable with real materials, real budgets, real people, and real safety requirements. In a sense, the engineer performs the physicist’s work in reverse. They start from abstract requirements and turn them into something you can actually touch and use.
\n\nAll three roles are necessary, and they are genuinely different.
\n\nIf you are the kind of person who feels deep satisfaction when you manage to prove that something must be true in every possible case, and you enjoy spending long hours working with almost nothing but paper, ink, and precise language, then mathematics is probably the right field for you. You need patience and a love for rigor.
\n\nIf you enjoy the struggle of taking something messy and real, measuring it carefully, finding patterns, and then expressing those patterns in mathematical form, physics will probably feel exciting to you. You get to live between the real world and the mathematical world.
\n\nIf you enjoy mathematics and physics but become happiest when you can actually build something that works, when you like working with constraints, when you enjoy the creative act of finding practical solutions that are good enough even if they are not perfect on paper, then engineering is likely where you belong.
\n\nOne thing that often confuses students is that the first years of study in these fields look quite similar. Most engineering programs start with mechanics, basic electronics, and mathematics. Most physics programs start with mechanics, electromagnetism, optics, and thermodynamics. Mathematics begins with analysis and linear algebra. Because of this overlap, many people feel uncertain or even guilty when they switch directions after one or two years. I think that feeling is usually unnecessary. Switching can simply mean that you are getting to know yourself better. You can only guess what a field will actually feel like from the outside. If you discover after some time that you are on the wrong train, getting off at the next station is not a failure. It is information.
\n\nThe most important question is not which label you choose first. The important question is whether you are genuinely interested in understanding how things work and in contributing to the technological world we live in. If you enjoy solving difficult problems, if you are fascinated by the fact that a single person or a small group of people can create things that change what is possible for everyone else, and if you are willing to keep learning for the rest of your life, then you are probably in the right broad area.
\n\nThe specific door you walk through first matters less than most people think. What matters more is whether you stay honest with yourself about what actually energizes you as you go deeper.
\n\nIf you are standing in front of this decision this summer, try not to put too much pressure on yourself to get it perfectly right on the first attempt. Almost everyone who works seriously in these fields had to adjust their path at some point. There are very few truly wasted years if you do the work with real curiosity and to the best of your abilities.
\n\nIf you want to talk about it, come find me on Discord.
\n\n", "date_published": "2026-06-01T00:00:00+00:00", "date_modified": "2026-06-01T00:00:00+00:00", "image": "https://maxclerkwell.tech/assets/posts/physics-math-engineering/titlepic.png", "authors": [ { "name": "Stephan Bökelmann" } ], "tags": ["physics","engineering","education","personal"] } ] }