OpenPlotter 4 roadmap

[xavierlh1]

I run OP V4 on RPI5 with a dAISy hat and try to keep things as simple as possible as I'm a newbie.  For performance and logging reasons I added an NVME board to run the OS from an SSD.  However, again as I'm a newbie, I try to backup my install using the cloning function to create an image on an SD card in case things go south as they often do.

My problem is that setting OPrescue=1 in /boot/firmware/config.txt appears to override the boot order so that I can no longer boot from the clone I create on SD cards (unless I suspect if I remove the SSD which is what I'm trying to avoid for practical reasons).

Is this a "real" issue, or did I just screw up somewhere?

At this point, I now longer have a means to check where the system boots from…!  The only option I can think of is to physically remove the SSD.
I was able to disconnect the NVME board before reboot - Don't know whether I can reconnect w/o taking the box apart - and doing so was able to confirm that I booted from the SD card.  When check sudo raspi-config - Advanced - Boot order, I get the message "Current EEPROM version 2025-02-12 or newer not found - abordting. Try updating the rpi-eeprom APT package."
Following https://commandmasters.com/commands/rpi-...ate-linux/, sudo rpi-eeprom-update provides
BOOTLOADER: up to date
CURRENT: Wed Feb 12 10:51:52 AM UTC 2025 (…..)
LATEST: Wed Jun 5 03:42:49 PM UTC 2024 (……..)
RELEASE : default (/lib/firmware/raspberry pi/bootloader-2712/default_
Use raspi-config to change the release
Looking online I found https://commandmasters.com/commands/rpi-...ate-linux/
Reading through it I ran sudo rpi-eprom-update -r to try and get back to the previous version and it seemed to work - i.e. the next boot was from the SD card.

I don't have clear evidence that this is the result of the OPrescue=1 update, it certainly seems so.  I'll stay away from it until I hear more...

---

I run OP V4 on RPI5 with a dAISy hat and try to keep things as simple as possible as I'm a newbie.  For performance and logging reasons I added an NVME board to run the OS from an SSD.  However, again as I'm a newbie, I try to backup my install using the cloning function to create an image on an SD card in case things go south as they often do.

My problem is that setting OPrescue=1 in /boot/firmware/config.txt appears to override the boot order so that I can no longer boot from the clone I create on SD cards (unless I suspect if I remove the SSD which is what I'm trying to avoid for practical reasons).

Is this a "real" issue, or did I just screw up somewhere?

At this point, I now longer have a means to check where the system boots from…!  The only option I can think of is to physically remove the SSD.
I was able to disconnect the NVME board before reboot - Don't know whether I can reconnect w/o taking the box apart - and doing so was able to confirm that I booted from the SD card.  When check sudo raspi-config - Advanced - Boot order, I get the message "Current EEPROM version 2025-02-12 or newer not found - abordting. Try updating the rpi-eeprom APT package."
Following https://commandmasters.com/commands/rpi-...ate-linux/, sudo rpi-eeprom-update provides
BOOTLOADER: up to date
CURRENT: Wed Feb 12 10:51:52 AM UTC 2025 (…..)
LATEST: Wed Jun 5 03:42:49 PM UTC 2024 (……..)
RELEASE : default (/lib/firmware/raspberry pi/bootloader-2712/default_
Use raspi-config to change the release
Looking online I found https://commandmasters.com/commands/rpi-...ate-linux/
Reading through it I ran sudo rpi-eprom-update -r to try and get back to the previous version and it seemed to work - i.e. the next boot was from the SD card.

I don't have clear evidence that this is the result of the OPrescue=1 update, it certainly seems so.  I'll stay away from it until I hear more...

Although now my SSD is no longer accessible... :-(  I'll keep digging

Inconclusive.  ribbon cable wasn't properly seated.  Once fixed, system still booted from the SSD even though the Boot Order is B1 - SD card boot first.
sudo rpi-eeprom-update give the same results as above.
Used raspi-config to reset the bootloader to the default configuration.
Still booting from SD card with Boot Order option B1, although sudo rpi-eeprom-update now reports:
BOOTLOADER: up to date
      CURRENT: Wed Jun  5 03:42:49 PM UTC 2024 (…..)
         LATEST: Wed Jun  5 03:42:49 PM UTC 2024 (……..)
     RELEASE : default (/lib/firmware/raspberrypi/bootloader-2712/default)
Use raspi-config to change the release

Tried running raspi-config Option 8 Update but got an error.  System says to try apt-get update or with --fix-missing.  Running sudo apt-get update only got me a bunch of failures.

I'm hoping someone can get me on a straighter path...

At this point I can boot from an SD card imaged directly, but not if the SD card is a clone from my SSD.  This is not critical enough to keep me from proceeding with my project.  So, I'll abandon this path.  Early on I was able to clone my SSD install to an SD card and boot from the SD card.  I was hoping this would give me a way to recover from failures without having to remove the SSD.

[dnoiseux]

Hello, forgive me if I am not posting in the right thread but I can't a I2C 4.x thread.

Are there any plans to support the INA226 I2C voltage and current sensor?

Thanks

Dan

[jroon]

I run OP V4 on RPI5 with a dAISy hat and try to keep things as simple as possible as I'm a newbie.  For performance and logging reasons I added an NVME board to run the OS from an SSD.  However, again as I'm a newbie, I try to backup my install using the cloning function to create an image on an SD card in case things go south as they often do.

My problem is that setting OPrescue=1 in /boot/firmware/config.txt appears to override the boot order so that I can no longer boot from the clone I create on SD cards (unless I suspect if I remove the SSD which is what I'm trying to avoid for practical reasons).

Is this a "real" issue, or did I just screw up somewhere?

At this point, I now longer have a means to check where the system boots from…!  The only option I can think of is to physically remove the SSD.
I was able to disconnect the NVME board before reboot - Don't know whether I can reconnect w/o taking the box apart - and doing so was able to confirm that I booted from the SD card.  When check sudo raspi-config - Advanced - Boot order, I get the message "Current EEPROM version 2025-02-12 or newer not found - abordting. Try updating the rpi-eeprom APT package."
Following https://commandmasters.com/commands/rpi-...ate-linux/, sudo rpi-eeprom-update provides
BOOTLOADER: up to date
CURRENT: Wed Feb 12 10:51:52 AM UTC 2025 (…..)
LATEST: Wed Jun 5 03:42:49 PM UTC 2024 (……..)
RELEASE : default (/lib/firmware/raspberry pi/bootloader-2712/default_
Use raspi-config to change the release
Looking online I found https://commandmasters.com/commands/rpi-...ate-linux/
Reading through it I ran sudo rpi-eprom-update -r to try and get back to the previous version and it seemed to work - i.e. the next boot was from the SD card.

I don't have clear evidence that this is the result of the OPrescue=1 update, it certainly seems so.  I'll stay away from it until I hear more...

---

I run OP V4 on RPI5 with a dAISy hat and try to keep things as simple as possible as I'm a newbie.  For performance and logging reasons I added an NVME board to run the OS from an SSD.  However, again as I'm a newbie, I try to backup my install using the cloning function to create an image on an SD card in case things go south as they often do.

My problem is that setting OPrescue=1 in /boot/firmware/config.txt appears to override the boot order so that I can no longer boot from the clone I create on SD cards (unless I suspect if I remove the SSD which is what I'm trying to avoid for practical reasons).

Is this a "real" issue, or did I just screw up somewhere?

At this point, I now longer have a means to check where the system boots from…!  The only option I can think of is to physically remove the SSD.
I was able to disconnect the NVME board before reboot - Don't know whether I can reconnect w/o taking the box apart - and doing so was able to confirm that I booted from the SD card.  When check sudo raspi-config - Advanced - Boot order, I get the message "Current EEPROM version 2025-02-12 or newer not found - abordting. Try updating the rpi-eeprom APT package."
Following https://commandmasters.com/commands/rpi-...ate-linux/, sudo rpi-eeprom-update provides
BOOTLOADER: up to date
CURRENT: Wed Feb 12 10:51:52 AM UTC 2025 (…..)
LATEST: Wed Jun 5 03:42:49 PM UTC 2024 (……..)
RELEASE : default (/lib/firmware/raspberry pi/bootloader-2712/default_
Use raspi-config to change the release
Looking online I found https://commandmasters.com/commands/rpi-...ate-linux/
Reading through it I ran sudo rpi-eprom-update -r to try and get back to the previous version and it seemed to work - i.e. the next boot was from the SD card.

I don't have clear evidence that this is the result of the OPrescue=1 update, it certainly seems so.  I'll stay away from it until I hear more...

Although now my SSD is no longer accessible... :-(  I'll keep digging

Inconclusive.  ribbon cable wasn't properly seated.  Once fixed, system still booted from the SSD even though the Boot Order is B1 - SD card boot first.
sudo rpi-eeprom-update give the same results as above.
Used raspi-config to reset the bootloader to the default configuration.
Still booting from SD card with Boot Order option B1, although sudo rpi-eeprom-update now reports:
BOOTLOADER: up to date
      CURRENT: Wed Jun  5 03:42:49 PM UTC 2024 (…..)
         LATEST: Wed Jun  5 03:42:49 PM UTC 2024 (……..)
     RELEASE : default (/lib/firmware/raspberrypi/bootloader-2712/default)
Use raspi-config to change the release

Tried running raspi-config Option 8 Update but got an error.  System says to try apt-get update or with --fix-missing.  Running sudo apt-get update only got me a bunch of failures.

I'm hoping someone can get me on a straighter path...

At this point I can boot from an SD card imaged directly, but not if the SD card is a clone from my SSD.  This is not critical enough to keep me from proceeding with my project.  So, I'll abandon this path.  Early on I was able to clone my SSD install to an SD card and boot from the SD card.  I was hoping this would give me a way to recover from failures without having to remove the SSD.

A very late reply, but I ran into something similar this weekend. After messing around and googling I found out that you have to select the option to assign new UUID's to the partitions of the clone. If you don't the system gets confused between the two clones and boots from NVME even if you select the boot order to start with SD card. With a different UUID I was able to boot into SD again. Hope this helps.