I used the 64bit 2023-12-11 nightly, and everything went pretty smoothly. A couple of minor issues during installation, but up and running now with no issues.
Problems I ran into:
The /boot/octopi.txt file gets moved to /boot/firmware/octopi.txt, so the custom camera resolution / settings were not being used. I fixed that with "sudo ln -s /boot/firmware/octopi.txt /boot/octopi.txt" and a reboot.
Entering the desired hostname into /boot/hostname.txt did not work. Probably the same issue as above, but I didn't bother symlinking it to see -- I just manually edited /etc/hostname.
I experienced multiple issues with 1Wire and my ds18b20 probes. Sometimes they were seen, sometimes they disappeared, sometimes they gave no response or incorrect response (at one point, it told me my enclosure was 635C, lol).
Those 1Wire issues all turned out to be a problem in how the kernel handles the new RP1 chip and its power management modes; the RP1 would sometimes go to L0 sleep during between the 1wire query and response, which lost or corrupted the response. All that was with kernel 6.1.0. The Raspi engineers have fixed it in kernel 6.6.16, but that is currently available only via raspi-update -- no idea when it will be available through apt.
The pi5 gpio has changed. Older mechanisms (including wiringpi, pigpio, rpi.gpio) no longer work. Any scripts (or plugins) using the old wiringpi or pigpiod utilities, or rpi.gpio, are going to need some work before they function on Pi5. I had scripts using pigpiod/pigs for relay control and hardware pwm, and chose to rewrite them using pinctrl (for the relays) and the sysfs interface to hardware PWM.
Other than that, installation went the same as with an Octopi 1.0 image on the pi4. The extra speed of the Pi5 is noticeable. Not during printing, of course, but other operations (timelapses, backups, service restart, reboot, etc.) are much faster.
The symlink should be expected, it all moved as per debian setup.
The RP1 DS18B20 has been worked on for a while now but I haven't followed it so no idea if/of a solution, is the fix hacky and disabling ASPM or is I nice, must go check. I know you were part of the thread.
6.6 will probably go live via apt in a few weeks hopefully, it has just move to rpi-update, normal path and from rpi-update next.
"in the near future (a few weeks perhaps)."
Yes, and I know @guysoft is aware. But among posts from early Pi5 Octoprint adopters, I have seen a bunch that are unaware and having issues setting camera resolution.
is the fix hacky and disabling ASPM
The kernel fix is a little hacky. It replaces simple delays with dummy reads during the delay in order to prevent the bus from falling into low-power state while awaiting a response. That still allows sleep at other times, as opposed to disabling ASPM entirely.
That fixes the initial issue with 1Wire responses, but there is another report that corrupted 1Wire responses are still seen when RP1 activity increases. Ultimately, I think this is going to need a lot more work and may not be entirely resolved for a long time. The hardware team got way ahead of the software team here.
just remember pinctrl is a debug tool
Yeah, but not a lot of other good options right now for a transient shell script to toggle a pin or get its status. The libgpiod folks have talked about a daemon with pipe interface, but I'm not sure that has gone any further than talk. I'm hoping someone will build something similar to Joan's pigpiod/pigs at some point, which will provide transient processes with more "controlled' access than pinctrl.
As you say, there are multiple options for Python (and C). I know there are a number of plugins that use GPIO for fans/lights, and those are going to be broken on Pi5 until updated. Those in "active development" should be easy enough for the authors to fix, once they get their hands on a Pi5. But there will undoubtedly be other plugins that need adoption if they are to be fixed.
I am still happily using the octopi bookworm nightly from December (with normal apt updates) on my pi5, and very thankful for the work creating it! Other than the minor link issues mentioned above, the build has been completely solid for me. The 1Wire and gpio changes on the pi5 are, of course, nothing to do with Octopi -- but something early pi5 adopters need to be aware of regardless of what build they are using.
