Pi-top [3] RK3399 upgrade

Hi there,

I’m opening this new thread to collect some information about a possible upgrade path to Rockchip’s RK3399. The original Raspberry Pi 3B+ was always feeling sluggish with a poor Wifi strength making the connection unreliable, so this acted as a motivation to start exploring for alternative boards that could fit. The requirement being that it should fit without modifying the case.

The Pi 4 is a natural option, that could fit by unsoldering the misplaced Ethernet and USB ports, still replacing the micro HDMI port is a bit challenging. The good point about this is that it would allow to keep the original OS which is very nice.

Looking for a drop-in replacement, one can find two SBCs that have the same Pi 3 compatibility, the Nano PI M4 and the RockPi 4. The latter have a M.2 slot underneath that will probably be troublesome given the 3 mm clearance in the case, and it’s not clear if it can accept to be powered from the GPIO. The NanoPi M4 can fit in, be powered from the GPIO, comes with Wifi and Bluetooth antennas, the only drawback at this point is that pi-top OS won’t run on it.

Armbian runs just fine in its Debian version, some features are not functional out of the box and will have to be addressed:

  • hub power off after shut down, one have to press the button for a few seconds to force it
  • battery indicator
  • speaker (sound works just fine through bluetooth)
  • GPU 3D acceleration

One warning: the board is quite busy underneath and I managed to rip off one component during the insertion and removals. Its proximity with the stud is certainly asking for some attention. With the IC smashed the board would not boot when powered from GPIO but run just fine when plugged with USB-C. A bit of tricky soldering and some luck brought it back to life…

On the NanoPi the CPU is placed on the other side of the board, some sort of thermal dissipation must be added here. The case can accommodate for a 1.2 mm thick piece of aluminum, with two 17 um layers of graphene sheet to help for the conductivity. Everything fits nicely under the hub, but it’s a bit thick for the NanoPi so only the front screw can be tightened with some flexing of the PCB. Maybe 0.2 mm less in thickness would help. A 1.2 mm shim and a bit of double sided adhesive tape can make the bridge thermal pad contacting the PCB right a the back of the CPU. This one is probably not required as the GPIO pins were conducting the heat toward the bridge quite well during the first trials.

The CPU was idling at 81°C at 2.0 GHz without any cooling, with this arrangement, and back to 1.8 GHz, the CPU is now around 50°C doing light browsing.

1 Like

Next step is to make the hub automatically powering off.

In the device management repository, poweroff/poweroff-v2 file, the hub is probed on idc-1 bus, while on the NanoPi it’s sitting on i2c-2. I still have to plumb this in systemd.

This is really cool! Looking forward to seeing the final result after the software is linked up

Hello again,

Here is a small update after some days playing with the setup.

Armbian was moved to its Ubuntu flavor, where Panfrost is already installed so there is GPU acceleration.

Wifi stopped working after updating, but the (temporary) solution was to hold the firmware package: sudo apt-mark hold armbian-firmware

Sound interfaces are detected correctly, still pulseaudio defaults to the analogue output so one need to switch to hdmi each time the laptop is powered up. For the speaker initialization one has to copy the ptcommon module in the python3 folders, then modify the initialization script to pick up i2c-2 instead of i2c-1, and fire it at startup from rc.local. Volume control from the keyboard works out of the box.

Poweroff was also just a matter of changing the i2c bus in the poweroff script and install the systemd service.

What’s left for the moment is the battery monitor. The pthub2 module is not working for any reason, but ripping out the code to read the battery state from the hub registers works. Anyway a plugin for xfce would need to be developed to display the battery status, which is a bit cumbersome. Maybe displaying it on the desktop with conky is simpler, this needs a bit of thinking. Of course a kernel driver would be the best as it would allow to reuse the existing battery plugin…

Last point so far, switching the cpu scheduler from ondemand to conservative helped to lower the overall heating.

The RK3399 pi-top is quite an enjoyable experience now :smiley:

1 Like