Repository navigation
Recognise compute modules in assert_hw_rpi - #19
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 50 minutes. View limit detailsLimit details: You’ve used the included review currently available. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthrough
ChangesRaspberry Pi model detection
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The documented minimum-generation check accepts Compute Module 5, so the stated provisioning path is not blocked. No actionable merge risk is evident. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
A CM4 or CM5 reports "Raspberry Pi Compute Module 4/5" in /proc/device-tree/model. The generic pattern looks for a digit directly after "Raspberry Pi", which such a string never contains, so every compute module fell through to the else branch and the script exited with "NOT RUNNING ON A RECOGNIZED RASPBERRY PI MODEL". Match compute modules before the generic pattern and map them to their generation, which is the question the function is actually asking: a CM5 is a Pi 5 on a different carrier. The original CM carries no number and maps to 1. Verified against the model strings of CM1 through CM5 and of the Pi 1, 4, 5 and 400; none of the previously recognised boards change. A Pi Zero 2 W is still unrecognised, as it was before, and is left alone here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bc4d62c to
a081eef
Compare
assert_hw_rpirejects every Raspberry Pi Compute Module.A CM4 or CM5 reports
Raspberry Pi Compute Module 4 Rev 1.1/Raspberry Pi Compute Module 5 Rev 1.0in/proc/device-tree/model. The generic pattern looks for a digit directly afterRaspberry Pi, which those strings never contain, so they fall through to theelsebranch and the caller exits with:This matches compute modules before the generic pattern and maps them to their generation, which is the question the function is really asking: a CM5 is a Pi 5 on a different carrier, with the same SoC. The original CM carries no number at all and maps to 1.
Checked against the model strings of CM1 through CM5 and of the Pi 1, 4, 5 and 400:
Raspberry Pi Compute Module 5 Rev 1.0Raspberry Pi Compute Module 4 Rev 1.1Raspberry Pi Compute Module 3 Plus Rev 1.0Raspberry Pi Compute Module Rev 1.1Raspberry Pi 5 Model B Rev 1.1Raspberry Pi 4 Model B Rev 1.4Raspberry Pi 400 Rev 1.0Raspberry Pi Model B Plus Rev 1.2No previously recognised board changes. A Pi Zero 2 W is still unrecognised, as it was before; that is a separate question and is left alone here.
Found while provisioning a CM5 with
rpi-texttv, which callsassert_hw_rpi 4and could not get past it.🤖 Generated with Claude Code
Summary by CodeRabbit