New pi-topOS release — June 2021 (C790 2021-06-11)

:package: June 2021: The latest version of pi-topOS is here!

It’s been a busy few months for us since we did our last OS release back in December 2020.

In this post, I will be discussing the various changes that have been made to pi-topOS since our last OS release (C781 2020-12-22).

All of these changes are available if you update an existing OS, but it is recommended to download the latest OS and install it fresh onto an SD card if you do not have your pi-top already configured for your needs.

:snake: Python SDK

Our Python SDK (software development kit) has received a number of improvements since December.

:rotating_light: API Change: pi-top [4] Miniscreen

In the previous public stable version of pi-topOS (C781 2020-12-22), the pi-top [4]’s miniscreen display was accessed via an oled class. This has been replaced with a miniscreen class to help clarify our terminology and improve usability.

:warning: All content on Further now makes use of this class, so older versions of pi-topOS will require updating.

In addition to this, please note that it is now recommended that you access this (and all other pi-top device functionality) from the Pitop object:

from pitop import Pitop

pitop = Pitop()
miniscreen = pitop.miniscreen

:robot: Machine Learning / Robotics Kit

We have expanded our SDK to include more machine learning-based features such as face detection, emotion tracking and colored ball detection. Robotics Kit also benefits from more advanced navigation/autonomous driving and a new pincer controller.

emotion_detect2 emotion_detect3 emotion_detect4

We are continuing to invest our efforts into expanding the functionality, stability and performance of our SDK to make the learning through play experience with pi-top hardware much more exciting!

:video_game: Web Controller

As mentioned in this post, we have also introduced “web controllers” as part of ‘web labs’ section of the Python SDK - a great way to quickly create interfaces to display information and create virtual controllers, such as a web-based rover controller! Be sure to check out that post if you haven’t seen it yet - they’re really cool!

:stethoscope: Diagnostics

You can now run pi-top support health_check, which provides information about the overall system that can help in diagnosing some issues.

:broom: Miscellaneous

Other notable changes that we’ve made to the SDK are:

  • Most objects can be imported directly with from pitop import
  • Added smooth acceleration mode to servo motor class
  • Added pi-top oled spi command for changing SPI bus
  • Added pixel inversion support to miniscreen (draw black onto white)
  • Added manual page for CLI (“manpage”)
    • Run man pi-top to read the CLI’s manual directly in the terminal
  • Updated luma.core dependency fixes some intermittent GPIO issues
  • Dropped pt-project-files and RPi.GPIO dependencies
  • Improved our documentation

pi-top hardware support

:robot: pi-top [4] Expansion Plate

We have just released an updated version of the firmware for the pi-top [4] expansion plate that offers:

  • Improved synchronisation between DC motors on motion start
  • Improved handling of low servo motor speeds
  • Added a filter for gyroscopic data to improve yaw drift
  • Added a status register

To update your expansion plate firmware, simply make sure that your OS is update and you have your plate connected properly. You should see a notification on the desktop telling you to update - follow the on-screen instructions.

:tv: pi-top [4] miniscreen

We have also added a new feature - the pi-top [4] miniscreen now has screensaver functionality to protect against OLED burn-in. Check out this forum post to learn more about that.

:broom: Miscellaneous

A few other improvements have also been made:

  • Improved pi-top [4] miniscreen performance
  • Increased legacy power-off timeout to 15s to improve shutdown stability for older systems
  • Added custom startup GIF support for pi-top [4] miniscreen
  • Improved battery reporting 100% reliability
  • Improved peripheral auto-initialisation
  • Fixed pi-top [4] miniscreen boot animation for non pi-topOS systems
  • Reduced logging when pi-top [4] minscreen image is updated
  • Reduced logging by default for battery messages

:microscope: Nerdier Stuff

Now onto the more developer-related stuff…

:books: OS Documentation

We have begun an ongoing effort to document pi-topOS - check it out here!

This is in the early stages, but will continue to grow as we work on different areas of the codebase and answer user questions.

:pie: Raspberry Pi Firmware Update Support

We have (finally!) added support for patching Raspberry Pi EEPROM to work with pi-top [4]s. Check out this FAQ post for more information about what is required to make this work. pi-topOS will now also correctly install the updated EEPROM firmware files, allowing you to benefit from the increased performance and functionality of running the latest firmware!

:link: Further Integration

Our integration with pi-top’s learning platform, Further, offers a convenient way to run code on your pi-top device while following tutorial content. We have improved performance of existing functionality, and added support for using key presses on your device as inputs as well as opening GUI windows.

:package: Package Management

We have made good progress in updating how we manage our software. We are aiming to move towards fewer source packages (and therefore fewer GitHub repositories).

pt-os-core contains a number of small software packages that either help to organise our dependencies or provide very specific, limited behaviour. More complicated applications will have their own source package and GitHub repository.

pt-notifications no longer provides; This is now provided by its own package: notify-send-ng.

I2C probing is no longer handled directly in pt-firmware-updater via the pt-i2cdetect command. The command is now called i2cping, and is provided by a new package: i2c-tools-extra, which is derived from the i2c-tools package.

And finally… all pi-top software is now built on GitHub via GitHub Actions, which brings us one step closer to being able to have full build and deploy transparency for all of pi-topOS’s software!


It’s been a busy few months for us on the pi-topOS team! We hope you like the improvements.

We are currently developing a new server application called “web portal”, which is going to allow for some pretty exciting new ways to use your pi-top [4] (or Raspberry Pi) remotely. Keep an eye out for more information about this!

Web Portal will also serve as the backend for some much-needed updates to our desktop applications, giving a unified feel across the OS for the user and simplifying development by standardising their implementations. Expect to see a better OS updater soon!

Special thanks go out to all of the active users here on the forum who are collaborating in this effort. If you aren’t already on this forum, get involved - we want to hear from you!


Thank you for posting this update - after reading this I am considering reloading both of my Pi-Top[4]'s SSD’s to the new version


Thanks for the update, much appreciated for all the interesting info :slight_smile:

@pi-topMIKE quick question about the web portal, will there be the possibility for 3rd party “plugins”/apps, for example, if I want to include a project web GUI for IOT monitoring, like pulling data from InfluxDB to show system stats/sensor data/other information would this be possible, web portal could be a perfect integration for my project with IOT stuff.

Also It defaults to port 80, will there be the option to change the port to something different to suit a user needs?

This is all stuff that we are looking into - we want to make it maximally useful. Once we have achieved our next major release milestone, we should be ready to write up a more comprehensive document about it all.

Right now, to achieve a project web GUI, you can use the SDK’s web controller functionality on another port (default 8070).

As for the matter of port 80, we are discussing scenarios and options. The typical need to change this is usually to resolve conflicting ports with another server, or wanting “security through obscurity”.

In most cases, providing some authentication on the web portal on port 80 will be enough to handle security sufficiently for most users.

Now, if the web portal is able to offer similar functionality to Organizr, then you would be able to use web portal as an all-in-one gateway for multiple servers - this can include custom dashboards for projects started up by the SDK, as well as other services (e.g. VS Code in the browser, System monitoring/metrics/visualisations/health alarms, etc.).

(Organizr allows you to setup “Tabs” that will be loaded all in one webpage, and can even open up two tabs side by side. It also allows for more advanced features, such as tab access control for user accounts and guests!)

All this is to say that other services can be easily added to web portal. This just leaves user preference for not exposing anything on the primary internet traffic port. For most of our users, this will not be desirable. However, it should be relatively straightforward - but we will need to do some additional work, such as ensure that the miniscreen can communicate what address to find web portal on.

1 Like

Hi - I have run into a little issue. I’m booting my pi-top [4] from a USB SSD drive. I ran an update upgrade over the weekend … all seems to have worked, except, after the reboot I am getting a warning message on the Desktop that I haven’t seen before:

Raspberry Pi EEPROM Requires Reconfiguration
Your Raspberry Pi’s board revision requires a reconfiguration to be compatible with pi-top[4]. Please apply the configuration update and reboot.
- Update and Reboot -

Update and Reboot is a button, but it seems to just reboot and has no other impact.
Question: What is the issue and how can I fix it? … I’d rather not do a rebuild as the system is working just fine, but the message persists.


As for why, this is outlined in the docs:

Raspberry Pi 4 boards earlier than the 1.4 PCB revision (All 8GB models have this, and this is now also the default for 2GB and 4GB models) require a modified EEPROM to power off correctly.

These newer boards hold the external reset until it is released by software (SPI bootloader) when the watchdog/soft reset occurs.

This means that the 5V rail on the USB bus will be off until the second stage bootloader has initialised or if halting it will stay off. On previous board revisions, this was not under software controls so 5V would be initialised when the XHCI/VLI automatically initialised, which could happen before halt.

Therefore, it is necessary to update the Raspberry Pi’s internal EEPROM firmware to behave correctly. The following changes are made to the EEPROM:


If this automatic behaviour is not working for you, then you can simply manage this yourself. It would appear as though you have a different partition structure or boot up sequence to other users, so that would explain why you are having this issue.

Ahhh! thx for the quick reply. … mine is indeed an early kickstarter board … I thought I (attempted to) made the changes to the EEPROM as suggested … but I will now confirm. … and report success / fail - tomorrow - it is late here at the bottom of the world. thx again

I too have a Kickstarter Pi-Top[4], when I installed the new release June 2021 (C790 2021-06-11), I received the notification that the Raspberry Pi EEPROM Requires Reconfiguration. I moved the mouse over the Update and Reboot in the bottom right corner of the windows and single clicked on it, the entire window repositions itself to the top right corner of the display and disappears. Nothing happens! No reboot and evidently no update. Waited 10 minutes, performed the reboot was met with the same Warning Message. I guess your Update and Reboot field doesn’t work, after it re-positions itself.

Up until now I have not experienced any problems with this Pi-Top[4]. I have read the Knowledge Base concerning the EEPROM. Typed in the WAKE_ON_GPIO=0 & POWER_OFF_ON_HALT=1 using a terminal window and rebooted - same Warning Message appears.

“If this automatic behaviour is not working for you, then you can simply manage this yourself.” What do I need to enter to get rid of the Warning Message on start-up or reboot?

@nannerbm60 I’m intrigued, where is the “bottom of the world”? :grin:

I have a Kickstarter version and another pi of the same model and both are fine both are v1.1. I don’t get this issue at all.

Both of them have been updated prior to the new OS update with the RPi EPROM updates to boot from USB first and fall back to SD if no bootable USB HDD is not detected.

@Korbendallaz and @nannerbm60 can you guys try running pi-top support health-check there is a part that checks the EPROM firmware and if it’s up to date. When you run it, it should be somewhere at the beginning of the health check. I’m not at home so can’t show you a screenshot of where to look.

@pi-topMIKE is the health check script a Python script or something else. It gives some nice info and some would be perfect for 1 of my projects. Just wondering how ya done it. If it’s Python, where is the file located, would be nice to have a peek at the code to help with a couple things :slight_smile:

Started my Pi-Top[4] received the same display as yesterday:

When I click on the Update and Reboot, the alert window jumps up to the top of the display and disappears immediately and nothing happens.

Ran the pi-top support health_check and took a screen capture of the EEPROM area of the report:


I was trying to create a file of the output, but everything I tried failed with “Error on [Errno 25] Inappropriate ioctl for device”.

Looks like the boot loader EEPROM has an update available, you can update the boot loader via micro SD card, if ya have a spare SD card you can make a boot loader flash on an SD card via raspberry pi imager think it’s under misc.

There is different options you can choose and see if that helps.

When you start it up with the boot loader flashed it takes only a few seconds, a green screen means success or fast flashing of one of the LEDs

Australia … not quite the bottom

I believe I have found (and “fixed”) the problem. I have slapped my forehead and awarded myself a gold star. … I think this might be @Korbendallaz’s problem

To check I was updating the EEPROM correctly, I googled pi-top EEPROM update and returned

even though mine isn’t DIY - I simply copy pasted the commands for laziness … on the small pi-top screen … and therefore operated on the old: pieeprom-2020-09-03.bin … did the GPIO and power off on halt and rebooted. … I will now rebuild - It is clearly got the system into a “state” … however, now, by clicking the “I” in the warning message - the message clears.

Mine is up and working but rough

You might want to edit that knowledgebase reference to reflect a generux pieeprom-YYY-DD-MM.bin format.

Successfully updated the EEPROM it is now at Thu 29 Apr 2021 04:11:25 PM UTC (1619712685)

Booted the Pi-Top[4] - same message appeared informing me the EEPROM requires reconfiguration. Still unable to click on Update and Reboot to get it updated.

Reference the uploaded image the EEPROM current date is the same as Latest.

I go back to my first message - What needs to be updated and how do I update it? Why bother displaying a warning message with an option that can’t be used. Why not just update it with the other updates?? I don’t understand.

Can’t wait to try updating my other Pi-Top[4] system.

It isnt a solution, but you can remove the message blocking the top of the screen by moving the mouse over the read exclamation mark (LHS of message box) and click once top dismiss … pi-top continues as before

I’m in the same spot … are you running the operating system from a USB SSD or SD Card (I use a solid state drive)?

hey @nannerbm60 & @Korbendallaz !

Sorry to hear about the issues… sometimes clicking the notification button won’t trigger the associated action, and will just dismiss the message; you need to move the cursor to the button and wait until it gets into an “activated state”, where the button changes it’s color, like in the picture:

Also, clicking in any other area of the notification will dismiss it.

Based on the images you posted, I think the message keeps showing up because even though you have the latest EEPROM (Thu 29 Apr 20201 ...), the configuration is wrong: WAKE_ON_GPIO should be 0 and POWER_OFF_ON_HALT should be 1.

If clicking the notification still doesn’t do anything for you guys, you can run the commands that the button triggers directly in your terminal:

sudo /usr/lib/pt-system-tools/pt-eeprom -f
sudo reboot

The first command will patch the EEPROM with the correct values, and the second one will reboot your pi-top to apply the changes.

1 Like

@pi-topJorge Waited 20 minutes for Warning Message to do something, it will look like your image when I hover my mouse over the Update and Reboot. I click it and the warning message repositions itself to the top right corner of the display (relatively the same position as System Update would be). I performed the steps you recommends , reference image:

The WAKE_ON_GPIO is a 0, but I don't see a POWER_OFF_ON_HALT` anywhere in this image. I use a 500 GB SSD instead of an SD card.

I rebooted the Pi-Top[4] and the warning message has reappeared. Ran pi-top support health_check reference image:

Notice WAKE_ON_GPIO is back to a 1.

I have updated the EEPROM page of the knowledge base to reflect the current state of pi-topOS EEPROM handling, and the commands that people use to update (thanks @nannerbm60).