raspberrypi

Pico 不只适合点灯。官方 pico-sdk 提供 C/C++ 接口，覆盖 PIO、定时器、USB 和多核等能力。 想研究自定义外设时序，可以从 PIO 相关示例往下挖。无线功能则要配合对应的硬件型号。 raspberrypi/pico-sdk t.co

Raspberry Pi Zero 3 Wに期待♪ メモリー4G欲しいけど良くて1Gまでな予感…メモリー高騰が悔やまれるね |･ω･`)とりあえず出たら買う！ linux#7711

Woke up to a broken MAC (wtf did the menu bar go of all things?) AND a broken RaspberryPi camera in need of updates libcamera#364

Raspberry Pi 5の有線LANで時々通信が欠落。EEE（省電力Ethernet）をOFFにしたら改善し、翌朝も欠落なしでした。kernel 6.18.50での話。同様の報告もあるので、心当たりのある方は確認候補に。 linux#7511

Raspberry Zero 3 Wのデバイスツリーファイルから読み取れることの情報をかき集めた。 github.com/raspberrypi/linux/blob/rpi-6.18.y/arch… SoCはBCM2711でPi 4と同じもの(クロックは落とされるかも)。電源ボタンが付きそう。PCIe,SPI Flashの対応。eMMCの可能性。ぐらいが気になるところ。USB-Cかは読み取れない。

Raspberry Pi Zero 3W Specs Leak: Pi 4 Chip, Release Date and Why It Won't Be $15 The Raspberry Pi Zero 3W now has a device tree, and it says the board runs on the BCM2711, the same quad Cortex-A72 chip as the Pi 4. I don't see a way it costs $15 like the Zero 2W, and the reason is the LPDDR4 that chip needs, which Raspberry Pi says has gone up sevenfold in a year. I went through the new .dts files to see what they actually confirm about Zero 3W specs and what's still guesswork (clock, RAM, price, release date). I also pulled published Pi 4 benchmarks to get a rough idea of how fast it could run a small LLM, and whether you should just buy a Zero 2W now. Where the Raspberry Pi Zero 3W leak came from Phoronix covered it too, but bret.dk wrote the detailed breakdown on 27 October 2026. Two device tree source files written by Marta Momotko were merged into Raspberry Pi's own kernel tree, the rpi-6.18.y branch of raspberrypi/linux, through PR #7711 on 25 October 2026. They aren't in mainline Linux, and Raspberry Pi hasn't announced either board. The links below point at the original commits on the martamomotko/linux fork. - Zero 3W: bcm2711-rpi-zero-3-w.dts, commit 1afad193 - Pi 4 Model A: bcm2711-rpi-4-a.dts, commit c17dd5f6 The Zero 3W file is very direct about what it describes: compatible = "raspberrypi,model-zero-3-w", "brcm,bcm2711"; model = "Raspberry Pi Zero 3 W"; Zero 3W specs: confirmed vs. guesswork A device tree describes how the board is wired. It doesn't cover clocks, RAM or price, so I've split what's in the file from what isn't. | | Zero 2W (shipping) | Zero 3W (device tree) | Status | |---|---|---|---| | SoC | RP3A0, 4x Cortex-A53 @ 1GHz | BCM2711, 4x Cortex-A72 | In the DTS | | Clock speed | 1GHz | ? | Not in DTS | | RAM | 512MB LPDDR2 | ? | Device trees don't describe RAM | | Wi-Fi/BT | Yes | Yes, includes bcm283x-rpi-wifi-bt.dtsi | In the DTS | | Storage | microSD | EMMC2 with bus-width = <8>, comment says "eMMC/SD card" | In the DTS, final form unknown | | Bootloader | On SD | SPI flash lines, so an EEPROM bootloader like the Pi 4 | In the DTS | | HDMI | 1x mini | 1x (second controller disabled) | In the DTS | | PCIe | No | &pcie0 enabled | In the DTS; whether it's exposed is unknown | | Camera | 2-lane CSI | 4-lane CSI config | In the DTS | | Power button | No | gpio-keys on GPIO 46 → KEY_POWER | In the DTS | | Price | $15 | ? | Pure speculation | The 8-bit bus width caught my eye. microSD only uses 4 data lines, so an 8-bit bus points to eMMC. Bret thinks it's a leftover and expects microSD on the final board. That could be right, but I'd keep an eye out for an eMMC SKU, because a Zero with soldered storage would make sense for industrial buyers. The Pi 4 Model A file is the boring sibling. It has a disabled Ethernet controller, one HDMI, no analogue audio or composite, microSD only, and antenna-switching lines (ANT_CTRL1/ANT_CTRL2, overlay params ant1, ant2, noant) that look a lot like the CM4's internal/external antenna option. Raspberry Pi Zero 3W release date No date has been announced. A device tree merged into Raspberry Pi's kernel means bring-up work is happening, but that doesn't tell you when boards will ship. Anyone quoting a month is guessing. The Zero 2W launched about five years ago and the last Model A was the 3A+ in 2018, so a refresh is overdue. The $15 Zero 3W problem: LPDDR4 prices The Zero 2W still costs $15 and hasn't gone up during the RAM crunch. Raspberry Pi's own April 2026 pricing post explains why. The LPDDR2 used in the Zero, Zero 2W and Pi 3 comes from stock the company already holds. The LPDDR4 used in the Pi 4 and Pi 5 has seen "a seven-fold increase over the last year". That same post put another $25 on the Pi 4 4GB, $50 on the 8GB, and launched a 3GB Pi 4 at $83.75. The BCM2711 uses LPDDR4, so the Zero 3W lands on the memory whose price went up sevenfold instead of the LPDDR2 Raspberry Pi already has in a warehouse. I'd bet on a 512MB or 1GB base model at a price that makes people angry in the comments. On the HN thread, one commenter points out that an Orange Pi Zero used to cost less than $10 and now sells for a tad over $30. Can the Zero 3W run an LLM? Pi 4 numbers are the ceiling There are no Zero 3W benchmarks because there's no Zero 3W yet. But it uses the same SoC as the Pi 4, and a small, passively cooled board almost certainly won't beat a Pi 4. So published Pi 4 numbers are a reasonable upper bound. The most useful dataset I found is SimeonOnSecurity's Ollama runs on a 2GB Pi 4B. The runs used five prompts, a 140-token output cap, and cold loads: | Model (Pi 4, 2GB) | Generation tok/s | Notes | |---|---|---| | LFM2.5-230M | 12.8 | 383MB peak RSS | | LFM2.5-350M | 8.6 | 516MB peak RSS | | qwen2.5:0.5b | 8.0 | 5/5 prompts | | MiniCPM5-1B (no reasoning) | 5.9 | 883MB peak RSS | | granite4:350m | 4.6 | stable, no swap | | gemma3:1b | 4.0 | heavy swapping, board rebooted | | qwen3.5:0.8b | n/a | didn't finish, board rebooted | For comparison, the Adafruit guide measured gemma3:1b at 9.99 tok/s on an 8GB Pi 5, and SimeonOnSecurity got 11.2 tok/s on its 8GB Pi 5. That's the same model that swapped a 2GB Pi 4 into a reboot at 4.0 tok/s. On the Zero 2W, the pi-llm project got llama.cpp working with SmolLM2-135M at Q4_K_M. It managed 9.5 to 10.9 tok/s generation, needed a mandatory 2GB swapfile, and took about 24 hours to compile on the board. The README warns that larger models may not run at all. What I take from those numbers: 1. RAM matters more than the A72 cores. Gemma 3 1B was already swapping and rebooting a 2GB Pi 4. If the Zero 3W ships with 512MB or 1GB, 1B-class models will be painful or won't load. 2. Models from 230M to 500M are where it'll work. LFM2.5-230M at 12.8 tok/s, or LFM2.5-350M and Qwen2.5-0.5B at around 8 tok/s, on Pi 4 silicon is fine for intent parsing, short summaries or a voice-assistant command layer. I wouldn't chat with it. 3. Over the Zero 2W, you mostly gain model size. The Zero 2W gets about 10 tok/s from a 135M model; Pi 4 silicon with enough RAM should get similar speed from a model about 3x bigger. That's worth having, since the pi-llm README admits its 135M model's responses "can be repetitive or incoherent". If you want a 1B model on a Pi today, buy a Pi 5. Boring answer, but that's what the numbers say. Buy a Zero 2W now or wait for the Zero 3W? My take: - Buy the Zero 2W now if your project is GPIO, sensors, a Pi-hole, a USB gadget, or anything that already runs fine on it. It costs $15, it's in stock, and the price is protected by LPDDR2 stock. A Zero 3W probably won't help a temperature logger. - Wait if you're hitting the 512MB wall, need PCIe or 4-lane CSI, or want a small on-device model. Expect to pay more. - Skip both if you want local LLMs. Get a Pi 5 with at least 4GB. HN commenters also bring up Rockchip boards like the Radxa Zero 3W, though one owner there says its Cortex-A55 cores are only slightly better than the Zero 2W's A53s. If you already have a Zero 2W and want to try a tiny model, don't compile on the board. Build on a faster ARM64 machine or cross-compile, copy the binary over, and add swap first. On a Bookworm-based Raspberry Pi OS image that still uses dphys-swapfile: sudo dphys-swapfile swapoff sudo sed -i 's/^CONF_SWAPSIZE=.*/CONF_SWAPSIZE=2048/' /etc/dphys-swapfile sudo dphys-swapfile setup && sudo dphys-swapfile swapon free -h Then run a model in the SmolLM2-135M class with -t 4, and watch vcgencmd get_throttled while it generates. On a Zero, thermals will start to matter before model quality does. So what's it for? I like the idea of a Pi 4 chip in a Zero footprint, and it's overdue. With LPDDR4 at current prices, though, I doubt it'll be the cheap hacking board people on HN want. My guess is a small, pricier board for camera rigs, PCIe experiments and edge projects that have outgrown 512MB. What would you build with a Zero 3W that the Zero 2W was too slow for? And at what price do you skip it for a Pi 5 or an ESP32? Tell me in the comments. I especially want to hear from people running models on a Zero 2W today. Sources - bret.dk: Raspberry Pi Zero 3 W and Pi 4 Model A on the way? - Zero 3W device tree, commit 1afad193 - Pi 4 Model A device tree, commit c17dd5f6 - raspberrypi/linux PR #7711 - Hacker News discussion - Raspberry Pi: a new 3GB Raspberry Pi 4 for $83.75, and more memory-driven price increases - SimeonOnSecurity: AI models on Raspberry Pi 4 and 5 - Adafruit: Local LLMs on Raspberry Pi - ravijo/pi-llm: llama.cpp on Pi Zero 2W

Sources: the merged pull request linux#7711 and The Register's report: theregister.com #RaspberryPi

Raspberry Zero 3 Wが来るのか。あと4 Model Aも。 linux#7711 Zero 2 Wが買えるのを待ってる状態だったんだけど、様子見した方がいいんだろうか。

Pi 5 RAM Swaps Have Been Firmware-Locked Since 2024. Here's What That Actually Means Raspberry Pi enthusiasts have been quietly upgrading the RAM on Pi 5 boards for a while now. The process involved swapping out the LPDDR4X memory package, and for the technically adventurous, it worked. It stopped working two years ago. The restriction is not new: Pi 5 bootloader EEPROM releases dated 2024-09-23 and later refuse to bring up memory that does not match what the board was provisioned with at the factory, and a board with a swapped chip fails SDRAM initialisation and does not boot. What is new is that the behaviour has finally been documented in public. One naming note: this is Raspberry Pi Ltd, the trading company, not the Raspberry Pi Foundation. Jeff Geerling wrote it up on 21 September 2026, which is why it is being discussed now. His own summary of the timing: "The firmware update that disabled RAM swaps was actually from late 2024, two years ago." Let's break down what the firmware checks, what the changelog does and does not say about it, and what your options actually look like. 💡 Why This Matters Raspberry Pi lists the Pi 5 in 1 GB, 2 GB, 4 GB, 8 GB and 16 GB variants, all LPDDR4X-4267. For users who wanted more RAM than their board shipped with, unofficial chip swaps were an appealing path. It kept older boards in service and gave power users more headroom for workloads like running local AI models, containers, or memory-intensive self-hosted apps. It was also, according to Raspberry Pi, being abused at the other end of the market: the company's position is that resellers were buying cheap low-RAM boards, soldering larger chips of unknown provenance onto them, and selling them as factory 8 GB units. Firmware-level lockdowns change that calculus entirely. When the bootloader refuses to initialise memory that does not match the board's factory provisioning, the board does not boot at all. The reported symptom is the green ACT LED flashing eight times in a repeating pattern, which is the SDRAM failure code. This is not a soft restriction you can work around with a config file tweak. 🔧 What the Firmware Actually Does Modern SBCs rely on their firmware to train and initialize RAM at boot. The firmware contains timing parameters, voltage settings, and compatibility tables specific to the memory chips the manufacturer has validated. When Raspberry Pi updates that firmware to check against an approved list of memory configurations, any chip not on that list can fail initialization entirely or be flagged and rejected. The practical result is that a board that previously booted fine after a RAM swap stops booting. The restriction lives below the OS, so there is no Linux-side fix. One important caveat on sourcing: the rpi-eeprom changelog entry for 2024-09-23 says only "SDRAM performance tuning", "Allow BANKLOW to be configured by SDRAM_BANKLOW parameter" and "Manufacturing test updates". It never mentions a memory check, so the changelog will not tell you this happened. The clearest primary evidence is rpi-eeprom issue 761, filed 15 October 2025 by a user whose Pi 5, sold as 8 GB, failed to boot on every EEPROM release from 2024-09-23 onward and booted fine on 2024-09-10. Raspberry Pi engineers asked for vcgencmd otp_dump, concluded from the OTP provisioning that the board had been modified after manufacture, and said such a board "won't cope with any changes in firmware / otp provisioning and is stuck on a pre-2712D0 firmware release with old/test SDRAM code." A Raspberry Pi engineer has also stated the policy directly on the company forums, in this thread. 🤔 Why Would Raspberry Pi Do This? There are a few plausible reasons, and they are not mutually exclusive. - Stability and support: Unofficial RAM swaps can cause hard-to-diagnose instability. Restricting unsupported configurations reduces support burden. - Supply chain and binning: Memory chips are binned and validated for specific performance envelopes. A chip that works in one context may not meet the timing tolerances Raspberry Pi has tested against. - Revenue protection: Selling higher-RAM SKUs is a meaningful part of the business model. Unofficial upgrades cut into that, particularly now that the Pi 5 is widely available. - Per-part memory tuning: The rpi-eeprom changelog is full of entries adding timings for specific memory configurations, including "Improved SDRAM refresh timings for Pi5 16GB" and a Broadcom SDRAM firmware bump "to support additional memory variants." The bootloader has to know which part is actually fitted. That also explains the part people find hardest to accept: a same-capacity chip pulled from another Pi 5 can still be rejected, because the check is not only about size. This has nothing to do with RP1, the Pi 5's I/O controller, which does not sit on the memory interface at all. None of these reasons are inherently sinister, but the combined effect is a more closed platform than many in the community expected from Raspberry Pi. 🛡️ What This Means for Your Homelab If you are running a Pi 5 with an unofficial RAM upgrade and it is working today, the immediate risk is a firmware update breaking your setup. Here is how to think about it. If your swapped board works today, you are already running old firmware. The only bootloader releases that tolerate a swapped chip are 2024-09-10 and earlier, so a board still running a RAM mod is two years behind on bootloader fixes. There is no release channel that keeps you both current and modded. The real choice is old firmware or a factory memory configuration, and it is worth knowing which one you have picked. To check your current EEPROM version and what update is staged: sudo rpi-eeprom-update The release channel is not set with rpi-eeprom-config. That command edits the bootloader's own configuration, things like BOOT_ORDER. The channel is the FIRMWARE_RELEASE_STATUS variable in /etc/default/rpi-eeprom-update: sudo nano /etc/default/rpi-eeprom-update In the current rpi-eeprom package that variable defaults to default, and latest is the other channel; the older critical, stable and beta names are historical and no longer what the tooling uses. The same file also holds RPI_EEPROM_ALLOW_DOWNGRADE and STRICT_MIN_VER_CHECK, which matter if you ever need to go backwards. Checked against the rpi-eeprom repository on 29 September 2026. Going backwards is getting harder. The 2026-09-23 bootloader release added a manufacture-version check: "If the MFG version of the image to update is less than MFG version in OTP then recovery.bin and self update will both fail to write the eeprom update", with bootloader_allow_mfg_downgrade=1 in config.txt as the documented bypass. On newer boards whose minimum version is burned into OTP, rolling all the way back to a 2024 bootloader is no longer a simple reflash. That change landed six days before this post went up, so treat it as current rather than settled. Consider your upgrade path instead. If you need more RAM for your workload, the official 16 GB Pi 5 is a real option. It costs more than a DIY swap, but it comes with full firmware support and no risk of a future update refusing to initialise your memory. 🧰 Alternatives If You Need More Headroom If the Pi 5 RAM ceiling is genuinely limiting your homelab, here are paths that do not depend on unofficial hardware modifications. - Raspberry Pi 5 16 GB: The official high-RAM option. Full firmware support, no risk from future updates. - Swap space on fast storage: Not a substitute for real RAM, but an NVMe-backed swap partition on a Pi 5 with an M.2 HAT can extend effective memory for workloads that tolerate it. Add a swap file on your NVMe mount point rather than the SD card. - Move the workload: For memory-intensive tasks like running local LLMs, a small x86 mini PC or a used workstation server often makes more sense than pushing a Pi to its limits. - Orange Pi, Rock Pi, or other SBCs: The broader ARM SBC ecosystem has boards with more RAM and less restrictive firmware policies. They come with their own trade-offs around community support and software compatibility. 🔍 The Bigger Picture This situation highlights a tension that has been building in the SBC space. As these boards become more capable and more commercially successful, the platforms inevitably become more controlled. The original Pi was almost impossibly open at the hardware level. The Pi 5 is a far more sophisticated piece of hardware, and sophistication tends to come with tighter firmware control. That does not make the Pi 5 a bad board. It is still one of the most capable and well-supported SBCs you can buy. But it does mean that the "buy a cheap board and hack it into something bigger" model has real limits now. Plan your Pi 5 deployments around the official RAM tiers, and treat any unofficial hardware modification as something that may stop working after a firmware update. ✅ Wrap Up Raspberry Pi's firmware-level RAM lockdown on the Pi 5 closed the door on a useful, if unofficial, upgrade path, and it did so in September 2024. If you have a working unofficial RAM swap today, you are on a two-year-old bootloader and any update will end that. If you are planning a new Pi 5 build that needs more than 8 GB, buy the 16 GB model and skip the uncertainty entirely. Jeff Geerling's 21 September 2026 post is the place to start on the community side. For the primary material, rpi-eeprom issue 761 is where Raspberry Pi engineers describe the check themselves, and the Pi 5 bootloader release notes are worth watching for future changes, with the caveat that this particular behaviour never appeared in them. --- Related from the lab - Why You Shouldn't Power a Raspberry Pi Through Its GPIO Pins - Pironman 5 Max Case Setup - Self-Host Apache Guacamole on a Raspberry Pi 5: Browser Remote Access for Your Homelab --- Originally published at codewithromi.com.

2年間放置していたPwnagotchiをクリーンインストールして使えるようにするまで はじめに 2年ほど放置していたPwnagotchiを、久しぶりに動かすことにした。 古い環境をそのまま直すのではなく、microSDを焼き直してクリーンインストールする。画面を動かして、SSHで入れて、バッテリーで持ち運べる状態に戻すのが今回の目標。 イメージを書き込めばすぐ終わるかと思ったら、USB接続でかなりハマった。最終的にはディスプレイとPiSugarの認識、SSHの鍵認証、PCからのインターネット共有までできたので、その記録を残す。 ! Pwnagotchiは無線ネットワークのセキュリティ検証に使うツール。検証は自分が管理するネットワークか、明確な許可を得た環境で行う。 今回はまず本体を使えるようにするところまでで、deauth・associate・advertiseは無効にしている。 今回の構成 項目 使用したもの 本体 Raspberry Pi Zero 2 W ディスプレイ Waveshare 2.13インチ V3・白黒 バッテリー PiSugar 3 イメージ jayofelony/pwnagotchi v2.9.5.8・64bit SDカードの設定用 NVMe SSDから起動しているRaspberry Pi 5 普段の管理用PC CachyOS・NetworkManager使用 使ったのは、こちらのPwnagotchi。 jayofelony/pwnagotchi Pi 5はSSDから起動しているので、本体のmicroSDスロットが空いている。そこにZero用のカードを挿して、Pi 5へSSH接続して設定した。USBカードリーダーを別に用意せずに済んだ。 Pi 5を使うのはSDカードの準備まで。その後はZeroをCachyOSのPCへUSB接続して管理する。 ! 以下のデバイス名やUSBインターフェース名は今回の実機のもの。特に/dev/mmcblk0を、確認せずに自分の環境へ当てはめないこと。 記事は今回の作業記録で、別のバージョンやディスプレイまで同じ手順で動くことを確認したものではない。 普通のRaspberry Pi OSではなく、専用イメージを使う 最初はZero 2 W向けのRaspberry Pi OS 64bitをSDカードに入れて、そこからPwnagotchiをインストールしようとしていた。 今回はそのルートをやめて、jayofelony版で配布している専用イメージを焼き直した。使用したファイルはこれ。 pwnagotchi-64bit-2.9.5.8.img.xz Releasesから取得できる。ここでは使用した版を固定して書いているので、これから入れる場合はリリースの説明も確認してほしい。 Raspberry Pi Imagerを使う場合はカスタムイメージとして選択する。通常のRaspberry Pi OS用のユーザー名・Wi-Fi・SSH設定を、Imagerのカスタマイズでそのまま上書きしないようにする。 参考：公式Wikiのインストール手順 Pi 5でSDカードの設定をする 最初に起動ディスクとSDカードを区別する Pi 5へSSH接続し、カードを挿した状態で確認する。 lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINTS findmnt / 今回は以下の対応だった。 /dev/mmcblk0 Zero用のSDカード ├─mmcblk0p1 bootfs └─mmcblk0p2 rootfs /dev/nvme0n1 Pi 5の起動用SSD ├─nvme0n1p1 /boot/firmware └─nvme0n1p2 / bootfsとrootfsというラベルはSSD側にもある。ラベルだけで判断せず、デバイス名とマウント先を一緒に見る。 rootfsをマウントする 焼きたてのカードのLinux側を、Pi 5上にマウントした。 sudo mkdir -p /mnt/pwnagotchi sudo mount /dev/mmcblk0p2 /mnt/pwnagotchi ls -la /mnt/pwnagotchi/etc/pwnagotchi/ この時点では、/etc/pwnagotchi/にconfig.tomlはなかった。defaults.tomlもこのディレクトリにはない。 そこで、SDカード側にconfig.tomlを新しく作る。 sudo vi /mnt/pwnagotchi/etc/pwnagotchi/config.toml /mnt/pwnagotchiを付け忘れるとPi 5自身の設定を触ってしまうので注意。 Waveshare V3とPiSugar 3の設定 最初に入れた設定は以下。 /etc/pwnagotchi/config.toml [main] name = "pwnagotchi" lang = "en" [personality] deauth = false associate = false advertise = false [ui.display] enabled = true type = "waveshare_3" rotation = 180 [ui.web] enabled = false [main.plugins.pisugarx] enabled = true lowpower_shutdown = true lowpower_shutdown_level = 10 [main.plugins.grid] enabled = false report = false [main.plugins.auto-update] enabled = false Waveshareの設定は製品の世代で変わる。今回の2.13インチV3ではwaveshare_3を使った。 Web UIはまだ使わないので無効。外部へのレポート送信や自動更新も、初期設定では無効にしておいた。 PiSugarはpisugarxで残量表示と低残量時の終了処理を設定する。ただし、このプラグインを有効にしただけで、電源ボタンによる安全終了まで設定できるわけではなかった。ボタンの話は後半に書く。 I2CとSPIはすでに有効だった SDカードのbootfsにあるconfig.txtを確認すると、今回のイメージには以下が入っていた。 bootfs/config.txt（抜粋） [all] dtparam=i2c1=on dtparam=i2c_arm=on dtparam=spi=on gpu_mem=1 dtoverlay=dwc2 enable_uart=1 同じ行を追加する必要はなかった。すでに書かれている内容を確認してから編集する。 設定後は書き込みを同期し、rootfsとbootfsの両方をアンマウントしてからカードを抜いた。 cd ~ sync sudo umount /mnt/pwnagotchi bootfsが以下へ自動マウントされている場合 sudo umount "/media/$USER/bootfs" lsblk -o NAME,SIZE,MOUNTPOINTS SDカードの両パーティションのマウント先が空になっていれば、Zeroへ移せる。 初回起動。緑LEDは点滅するが、画面は動かない ZeroへSDカードを入れ、PiSugarで電源を入れた。 最初は緑LEDが点滅するだけで、Waveshareの表示が変わらない。画面の設定を間違えたかと思ったが、待っていたら更新された。その後、AUTO表示になった。 後からログを見ると、ディスプレイとバッテリーの初期化は通っていた。 PiSugar3 is connected initializing waveshare v2in13_V3 display PiSugar3 is ready initializing waveshare v3 display done entering auto mode ... 今回のログには、次の警告もあった。 ui.fps is 0, the display will only update for major changes 画面が常に書き換わる設定ではないので、更新が止まって見えるだけでハングしたと決めつけない方がよかった。 なお、AUTOは動作モードの表示。これだけでdeauthなどが有効かどうかは判断できない。設定とログを確認する。今回確認した範囲ではdeauths=0、assocs=0だった。 一番ハマったのはUSB接続 ZeroのUSB接続には、本体のUSB端子を使う。PWR INやPiSugar側の充電端子ではなく、mini HDMI端子に近い方のmicro USB端子。 PC側では以下を確認した。 lsusb ip -br addr nmcli device status journalctl -k --since '5 minutes ago' --no-pager 一度認識しても、通信できるとは限らない 最初はUSB機器の認識でエラーになった。 device descriptor read/64, error -110 その後、次の名前で認識されるようになった。 Raspberry Pi USB Gadget ネットワークインターフェースも現れた。 enp0s20f0u3 ところが、これでもSSHには入れない。さらにホスト側のカーネルログに、こんなエラーが出た。 NETDEV WATCHDOG: ... transmit queue 0 timed out 抜き差しすると、またdevice descriptor read/64, error -110へ戻る。別のUSBポートでも同じエラーになった。 ケーブルや端子を疑うのは自然だけど、ここでは「SSHが無効なのか」「IPアドレスが違うのか」「そもそもUSB通信が止まっているのか」を分けて調べる必要があった。 SSHを有効にする設定をいじっても、USB機器の認識段階で止まっていたら接続できない。 SDカード側でSSHの設定を確認する 一度電源を切り、SDカードをPi 5へ戻して設定を確認した。 強制電源断後の調査では、いきなり書き込み可能にせず、読み取り専用でマウントした。 sudo mount -o ro,noload /dev/mmcblk0p2 /mnt/pwnagotchi noloadはext4のジャーナル再生も抑止するための指定。ただし、未回復の状態を見ることになるので、これを修復完了と考えたり、そのまま書き込み用に使ったりはしない。 サービスの自動起動設定は、Pi 5上からSDカード側を指定して確認できる。 sudo systemctl --root=/mnt/pwnagotchi is-enabled \ ssh.service ssh.socket rpi-usb-gadget-ics.service 結果は以下。 enabled disabled enabled ssh.serviceは有効。サービス方式なので、ssh.socketが無効なだけでは異常ではない。SSHのホスト鍵も存在し、openssh-serverとrpi-usb-gadgetもインストール済みだった。 ただし、enabledは自動起動する設定というだけで、実際に正常起動した証拠ではない。 USBドライバーが固まる報告と症状が一致していた 調べると、Raspberry PiのUSB Gadget側にかなり近い報告があった。 rpi-usb-gadget#31 Linux側の送信タイムアウトに続いて、抜き差し後のUSB認識まで失敗する、という流れが今回と似ている。提案されているのは、固まった状態を検知してg_etherを読み込み直す復旧処理。 ただし、確認時点では未マージのPRだった。今回このパッチを導入したわけではないし、Zero側のカーネルログまで取れていないので、これが原因だと確定したわけでもない。 今回接続できたのは、Zeroを完全に電源オフにしてから、PiSugarで起動し、AUTO表示になった後でPCへUSB接続し直したときだった。PC側の固定IP設定と組み合わせると、pingとSSHの応答が返ってきた。 ! 調査中はSSHもローカルコンソールも使えず、強制電源断が必要になった。稼働中の電源断にはファイルシステム破損のリスクがあるので、通常の終了方法としては勧めない。SSHが使えるようになってからは、OSをシャットダウンして止める。 SSH接続は10.0.0.2ではなかった 古いPwnagotchiの解説で見かけるアドレスを、そのまま使わない方がよかった。 今回のイメージにはrpi-usb-gadgetが入っており、Zero側に以下の接続プロファイルがあった。 USB Gadget (shared) USB Gadget (client) shared側の設定はこうなっていた。 [ipv4] address1=10.12.194.1/28 method=shared そこで、まずPC側を同じサブネットの固定IPにした。 機器 IPアドレス Zero 10.12.194.1/28 PC 10.12.194.2/28 以下はPC側で、新しくSSH専用の接続設定を作る場合の例。enp0s20f0u3は自分のUSBインターフェース名に置き換える。 nmcli connection add type ethernet \ ifname enp0s20f0u3 \ con-name pwnagotchi-usb \ connection.autoconnect yes \ ipv4.method manual \ ipv4.addresses 10.12.194.2/28 \ ipv4.never-default yes \ ipv6.method disabled nmcli connection up pwnagotchi-usb ipv4.never-default yesを付けて、PCの普段のインターネット接続がUSB側へ切り替わらないようにした。 これで、ようやく接続できた。 ping -c 2 10.12.194.1 ssh pi@10.12.194.1 初期ログイン後はpasswdでパスワードを変更しておく。 nmcliに「pwnagotchi」が出ないと思ったら あとで電源を入れ直した際、nmcli deviceの一覧にPwnagotchiがいないように見えた。 実際には、デバイス名がenp0s20f0u3で、接続プロファイル名がpwnagotchi-usbだっただけ。さらに、切り分け中に自動接続を無効にしたままにしていた。 nmcli connection modify pwnagotchi-usb connection.autoconnect yes nmcli connection up pwnagotchi-usb 接続後の該当行はこうなる。 enp0s20f0u3 ethernet 接続済み pwnagotchi-usb USB認識に待ち時間があることと、自動接続の設定は別の話だった。 なお、今回はUSBポートに依存するインターフェース名に設定をひも付けている。挿すポートを変えた場合は、同じ名前で見えているか確認する。 SSHは公開鍵認証にする 毎回パスワードを打つのも面倒なので、PC側にある公開鍵を登録した。 これはZeroの中ではなく、接続元のPCで実行する。 ssh-copy-id -i ~/.ssh/id_ed25519.pub pi@10.12.194.1 今回は既存の鍵があったのでそれを使った。まだ鍵がない場合は、先に用途に合った鍵を作成する。 パスワード認証を使わずに入れるかも確認する。 ssh -o PasswordAuthentication=no \ -o KbdInteractiveAuthentication=no \ pi@10.12.194.1 これで入れれば、通常は次だけでよくなる。 ssh pi@10.12.194.1 秘密鍵のパスフレーズと、Zeroのログインパスワードは別物。秘密鍵にパスフレーズを付けている場合は、必要に応じてSSHエージェントを使う。 PiSugarの電源ボタンも設定した バッテリー残量が画面に出たので、PiSugarはもう設定済みだと思っていた。しかし、pisugarxでの残量表示と、電源ボタンを押したときの安全終了は別だった。 Zeroには公式のPiSugar管理サービスが入っていなかったため、以下のプロジェクトのpisugar-serverとpisugar-poweroffを追加した。使用した版はv2.3.5、アーキテクチャはarm64。 PiSugar/pisugar-power-manager-rs この段階ではまだZero自身にインターネット接続がなかったので、PCでパッケージを取得し、SSHで転送してインストールした。 今回はWeb UIやTCP APIを公開する必要がない。管理サービスはローカルのUnixソケットだけを使う設定にした。 --model 'PiSugar 3' --config /etc/pisugar-server/config.json --uds /tmp/pisugar-server.sock ソフト電源オフに関係する設定は以下。 /etc/pisugar-server/config.json（抜粋） { "soft_poweroff": true, "soft_poweroff_shell": "/usr/bin/systemctl poweroff" } PiSugarの電源ボタンでOSの終了を要求する設定で、カスタムボタンの長押しコールバックとは区別する。 実機ではサービスがPiSugar 3を認識し、ソフト電源オフが有効になっていることをAPIから確認できた。ボタンでの電源オフ・オンも試せた。 給電を切るタイミングは、まだ確認を残している Pwnagotchiのログなどはzram上にあるため、OSの終了処理より先に給電を切りたくない。 今回のローカル設定では、パッケージに付属するpisugar-poweroff.serviceは無効にし、代わりにsystemdの最終シャットダウン段階のフックから公式のpisugar-poweroffバイナリを呼ぶ形にした。再起動では給電を切らず、poweroff・halt時だけ実行する。 これは今回の環境向けに追加した設定で、公式パッケージの標準状態そのままではない。ボタンで停止・起動できたことは確認したが、前回起動のjournalを取得できず、終了処理から給電停止までの順序をログで検証するところは残っている。 そのため、ここでは「安全終了の全手順を検証できた」とまでは書かない。ログ保存設定も追加したが、再起動をまたいで残ることは別途確認が必要だった。 電子ペーパーは電源を切っても表示が残るので、画面が消えたかどうかだけで電源状態を判断しない。 PCのWi-FiをUSB経由で共有する SSHできるようになった時点では、Zeroから外のインターネットには出られなかった。USB内の固定IPで通信できることと、インターネットへ出る経路があることは別。 時計の同期や、必要なツールを取得するためにPCのWi-Fiを共有することにした。 最終的な構成はこれ。 SSHアドレスは変えず、PC側をNetworkManagerの共有モードにし、Zero側にはPCをデフォルトゲートウェイとして設定した。 ! 以下は前の節でSSH接続できた状態からの変更。ネットワークの切り替えでSSHが切れる可能性があるので、元の接続設定をバックアップしてから行う。インターフェース名・接続プロファイル名は環境に合わせる。 自動切り替えを止め、Zero側に固定の接続設定を作る rpi-usb-gadget-ics.serviceは、PCからの共有を検出してZero側の接続モードを切り替えるサービス。今回は固定アドレスで運用するため、この自動切り替えを止めた。USBドライバーのg_ether自体を無効にするわけではない。 以下はZero側で実行する。 sudo systemctl disable --now rpi-usb-gadget-ics.service sudo nmcli connection add type ethernet \ ifname usb0 \ con-name "USB Laptop" \ connection.autoconnect yes \ connection.autoconnect-priority 200 \ ipv4.method manual \ ipv4.addresses 10.12.194.1/28 \ ipv4.gateway 10.12.194.2 \ ipv4.dns "8.8.8.8,1.1.1.1" \ ipv4.never-default no \ ipv4.route-metric 100 \ ipv6.method disabled sudo nmcli connection modify "USB Gadget (shared)" connection.autoconnect no sudo nmcli connection modify "USB Gadget (client)" connection.autoconnect no ここではまだ新しい接続を有効化せず、先にPC側の準備をする。 PC側を共有モードに変更する こちらはCachyOSのPC側で実行する。 nmcli connection modify pwnagotchi-usb \ ipv4.method shared \ ipv4.addresses 10.12.194.2/28 \ ipv4.never-default yes \ ipv6.method disabled nmcli connection up pwnagotchi-usb PC側のnever-defaultは引き続きyes。PC自身は普段どおりWi-Fiをデフォルトルートにする。 また、自分のPCではUFWが有効で、転送はデフォルト拒否だった。全体を無効化せず、ZeroからWi-Fiへ出る通信だけを許可した。 enp0s20f0u3: USB側、wlan0: インターネットへ出るWi-Fi側 sudo ufw route allow \ in on enp0s20f0u3 out on wlan0 \ from 10.12.194.1 to any \ comment 'Pwnagotchi USB internet' これはUFWを使っていた今回の環境向けの設定。他のファイアウォールへそのまま当てはめるものではない。 最後にZero側で新しい接続を有効化する。 sudo nmcli connection up "USB Laptop" Zero側の経路はこうなった。 default via 10.12.194.2 dev usb0 proto static metric 100 自動更新はプラグイン設定以外にもあった ネットへ出す前に確認したところ、config.tomlで自動更新プラグインを無効にしていても、別のauto-update.timerが有効だった。 systemctl cat auto-update.service auto-update.timer 今回はこのタイマーも止めた。 sudo systemctl disable --now auto-update.timer とりあえずネットにつながったからといって、apt upgradeを実行したわけではない。専用イメージの更新は、使っている版の手順を確認して行う。 ネットにつながっても、時計が合わずHTTPSで失敗した 共有後、名前解決はできるようになった。しかしGitHubへHTTPS接続するとエラーになる。 SSL certificate problem: certificate is not yet valid Zeroの時計を確認すると、8月18日のままだった。実際の作業は10月なので、証明書をまだ有効になっていないものと判定していた。 curl -kで証明書チェックを無効にするのではなく、まずPCの現在時刻を使ってZeroの時計を補正し、systemd-timesyncdを再起動した。 その後はNTPの同期も確認できた。 timedatectl show -p NTPSynchronized NTPSynchronized=yes HTTPSも証明書チェックを有効にしたままで通った。 curl -4 -I github.com HTTP/2 200 Debianの配布サイトへのHTTPS接続も200で返ってきた。DNSだけでなく、実際のHTTPS通信まで確認できてようやく共有完了。 今日はここまで 今回できるようになったことは以下。 Waveshare V3への表示 PiSugar 3の認識と残量表示 PCからのUSB接続・SSH公開鍵認証 同じUSBポートでの自動接続 USB経由のインターネット共有と時刻同期 PiSugarのソフト電源オフ設定と、ボタンでの停止・起動の確認 USB不調の根本原因と、PiSugarの終了シーケンスのログ確認はまだ残っている。特にUSBは、今回つながったから今後絶対に固まらない、とまでは言えない。 それでも、PCにつないでssh pi@10.12.194.1で入れるようになると、かなり触りやすくなった。しばらくはこの構成で様子を見ようと思う。 2年ぶりに小さい画面が動いているのを見ると、もう少し早くやればよかったなと思う。今日はここまで。 参考 jayofelony/pwnagotchi インストール手順 USB接続の手順 Pwnagotchiの設定 Raspberry Pi USB Gadget USB endpoint lockupに対する復旧処理の提案 PiSugar Power Manager