New Turingpi RK1

Requests
1

It would be great if DietPi runs on a RK1 from Touring pi. It seems to be the same Chip as the 5b from Radxa, but my first test doesn’t work and I think the CPU is not the only thing what needs a driver.
Is there a probability that this version comes?

1 Like
2

We don’t have the possibility to add support for each and every device, especially if they are not that common.

3

I searched for a plain Debian image for the board and it seems that there ia nothing available beside Ubuntu.
Otherwise you could convert a Debian to DietPi via this description: Supported hardware - DietPi.com Docs

4

OK, that’s what I thought, but because the RK1 and the Touringpi look to me like more common as some other (especially future looking) I hoped that it could be in planning.
For the Convention from a Debian, is this also possible with Ubuntu-server?

5

simple answer: No

6

Now that shipments of the TuringPi RK1 have been delivered to customers, so, the user base is growing.

I’m gonna try running the script mentioned here above, and report back how it goes.

1 Like
7

I propose first to search a Debian image (or e.g. an Armbian image). Ubuntu conversion will unfortunately not work.
My new search did not find any convertable Debian based image. :frowning:

8

Came here looking for DietPi for the RK1 as well. While checking the specs I noticed that the RK1 uses the same chipset as the NanoPC T6, which Dietpi already supports. Unsure if this can be used to leverage some of the work, just making people aware of that.

1 Like
9

Managed to get DietPi up and running on the Turing RK1.

EDIT - A note of caution to others before proceeding: While I have managed to get DietPi installed on each of my RK1’s, I’ve had some settings change unexpectedly and had to do some troubleshooting. Not quite smooth sailing just yet, but it’s promising.

I converted a pre-built Debian 12 Bullseye image built/provided by @soxrok2212 on the TuringPi Discord by following the DietPi instructions for converting a Debian system into DietPi.

Typed out some steps below for those who may stumble across this post. Hopefully becomes easier as the board gets better support.

Steps

  1. Download the pre-built Debian image from the link above, and extract the img file.
  2. Flash the image to the Turing RK1 via Turing Pi 2 Web UI, TPI CLI, or other means.
  3. Identify the IP of the RK1 node and SSH into it using the credentials user:user.
  4. Type ip a and take note of the adapter name for Ethernet and WiFi.
    a. My Ethernet adapter was not name eth0, but instead end0.
    b. Further the IP Address range I’m using is different than the DietPi defaults, so I had to make some edits at the end.
    c. Copy/record these settings / values for later reference.
  5. Prerequisites are already present, run the following to start the conversion to DietPi:
    sudo bash -c "$(curl -sSfL 'https://raw.githubusercontent.com/MichaIng/DietPi/master/.build/images/dietpi-installer')"
  6. Select the relevant options for your installation:
    a. I elected for the Beta version of DietPi
    b. I entered my name at the next prompt.
    c. I entered “Turing-RK1” for the device (you can change this)
    d. Select the last option for “Generic Device” (You can press ‘End’ on your keyboard to jump to the last item)
    e. Select whether or not you are using WiFi (I selected no, since I’m using Ethernet plugged into the Turing Pi 2 BMC)
    f. Select the Debian version (I selected Trixie - It upgraded Bullseye seemingly without issue)
  7. When the script finishes running, you’ll need to edit some of the network settings before rebooting. Edit - In case it’s relevant, I used a static IP configuration and I had to modify both the IP address and default gateway in the files below to get this to work.
    a. sudo nano /boot/dietpi.txt and edit the values for your Ethernet and/or WiFi. Press ctrl+x to exit. Press y to confirm saving changes (or n if you wish to discard).
    b. sudo nano /etc/network/interfaces and again edit the values for your network interfaces. Importantly, I had to change eth0 to end0. I also commented out the WiFi section since I am not using it. Once changes are made, again press ctrl+x to exit and y to confirm saving changes (or n if you wish to discard).
    c. I don’t know whether or not all of the above is required, but it took a few attempts to get it to work on the initial node, and repeating this process on the other nodes had consistent results.
  8. Reboot the RK1, when it comes back up you should be able to login with the default credentials of root:dietpi and go through the first time boot setup.

Additional Note: After getting this up and running, there was an update available for DietPi, so I ran dietpi-update. Upon reboot it was not accessible via SSH. I was able to use picocom from the Turing Pi 2 BMC to update the configuration and get the RK1’s back on the network. More details in the replies below.

Aside from the above image, if you’re a bit more hands on with building custom images, you can try the Collabora’s Debian Image Recipe for RK3588 boards. You’d need to make a new target for the RK1.

Hope this is helpful!

2 Likes
10

Adding to the above - After converting Debian into DietPi, I wanted to move the OS to the NVME, however:

  1. The Turing Pi 2 UI and tpi utility only flash the eMMC modules on the RK1. Another method is needed to flash the NVME drives.
  2. My Turing Pi 2 is assembled, in a case, and the NVME drives are under the BMC. I didn’t want to disassemble everything just to flash the drives.
  3. DietPi lets you move the user storage to another device, but not the full image.

Someone may come along with a more simple/obvious solution to this, but here is what I did:

  1. Get DietPi set up on the RK1 according to my post above, go through the first boot configuration, reboot once more for good measure.
  2. SSH as root into the target RK1
  3. Confirm the drive paths with lsblk
    a. The eMMC module is /dev/mmcblk0 and the NVME drive is /dev/nvme0n1.
    b. While this is likely consistent across RK1s on a Turing PI 2 BMC, be sure to confirm the values on your own instance.
    4.Using dd, copy the contents of the eMMC device to the target NVME dd if=/dev/mmcblk0 of=/dev/nvme0n1 bs=1M status=progress
  4. When the operation finishes, check the UUID of each device. They should (currently) be the same since we copied drive-to-drive with dd. However, this can cause conflict/confusion when trying to reliably boot from the correct device.
    a. blkid /dev/nvme0n1p3
    b. blkid /dev/mmcblk0p3
  5. Generate a new UUID for the NVME
    a. Unmount the NVME umount /dev/nvme0n1p3
    b. Find and repair any disk errors: e2fsck -f /dev/nvme0n1p3
    c. Press y to confirm.
    d. Generate a new UUID: tune2fs -U random /dev/nvme0n1p3
    e. Press y to confirm.
  6. Identity the new UUID for the device: blkid /dev/nvme0n1p3
    a. Record the New UUID for Reference

While the Turing RK1, when attached to the Turing Pi 2 uses the NVME device as first boot priority, the UUIDs referenced in configuration files are still for the eMMC device. Further, since we copied everything from the eMMC to the NVME, these configuration files exist in both places, and we need to make certain we edit the correct ones on the NVME!

  1. Remount the NVME drive so we can edit correct files: mount /dev/nvme0n1p3 /mnt

  2. If prompted, reload the system daemon to refresh changes: systemctl daemon-reload

  3. Edit the configuration files:
    a. Edit the kernel cmdline file used by u-boot: nano /mnt/etc/kernel/cmdline
    Note the /mnt/ in front of the path, this is because we are editing the files on the NVME and not currently running system drive (eMMC). Replace the original UUID with the newly generated UUID. Only replace this value.
    Press ctrl+x to exit nano and press y to confirm saving changes.
    b. Next edit fstab so the correct drive / root partition is mounted: nano /mnt/etc/fstab
    Again, only swap out the UUID.
    Press ctrl+x to exit nano and press y to confirm saving changes.
    c. Finally, edit extlinux.conf. Normally we’d run u-boot-update to automatically update this file, however running that will only update the value on the running system (eMMC), so we’ll do it manually: nano /mnt/boot/extlinux/extlinux.conf
    Once more, only swap out the UUID. (will likely be in 2 locations)
    Press ctrl+x to exit nano and press y to confirm saving changes.

  4. Almost done. Unmount the NVME drive: umount /mnt

  5. Power down the RK1: poweroff

At this point, if you power back on and ssh into your device, you should see the root partition active on the NVME: lsblk

You may be tempted to format the eMMC at this point, however the TuringPi documentation notes:

While you can boot off an external block device instead of included eMMC, the bootloader must still be flashed to eMMC because RK3588 SoM does not boot off devices like this and the bootloader is what handles this part of the boot process. Currently, the easiest way to put a bootloader is to flash the image onto eMMC too, but we should have “just bootloader” images for this purpose in the future

Leaving DietPi on here will work, however I personally want a minimal u-boot image on the eMMC. Fortunately, @CFSWorks on the TuringPi Discord has u-boot for the RK1 as part of their project for installing Alpine Linux on the RK1. You could build it from the available source, or conveniently, download an apk they’ve compiled and provided.

On your local machine:

  1. Make yourself a working directory and open a terminal in that location.
  2. Download the u-boot apk: https://alpine-rk1.cfs.works/packages/main/aarch64/u-boot-turing-2024.04-r0.apk
  3. Open it with an archive utility and extract the following files into your working directory:
    a. idbloader.img
    b. u-boot.itb
  4. Create an .img file we’ll use later to flash the RK1: touch turing-rk1-uboot-only.img
  5. You should now have the idbloader.img, u-boot.itb, and turing-rk1-uboot-only.img in your working directory. From there, use dd to create our combined image:
    a. dd if=idbloader.img of=turing-rk1-uboot-only.img bs=512 seek=64
    b. dd if=u-boot.itb of=turing-rk1-uboot-only.img bs=512 seek=16384
  6. The resulting .img file can be used to flash the RK1 device through the Web UI or tpi utility.
  7. Once generated, this .img can be used “as is” to flash the other nodes after moving them to NVME.
1 Like
11

I remember that I once used a way to copy dietpi on an CM4, where I only needed to set the OS in read-only, then copy the drive over to a SSD and afterwards make that the primary drive…
Sadly I don’t find that instructions anymore and didn’t got it the last time in my own to work…

For the first post, thanks a lot for your patience, safely my setup is not seen at my dhcp, so maybe I have a misconfigured tp2 or my whole setup is broken… I have no idea :pensive:

12

I overlooked a feature while setting things up initially, but it will likely help in troubleshooting what’s going on and possibly improve flashing to NVME. And that’s using picocom to monitor the boot process and access the nodes from the Turing Pi 2.

To check out what’s going on with DHCP or potentially what is going wrong:

  1. Connect to the Turing Pi 2 BMC UI: http://turingpi.local (Default credentials root:turing)
    a. On the Power tab, ensure power to the RK1 Node is off.
  2. SSH into your BMC ssh root@<Turing Pi 2 IP]> (Default credentials root:turing)
  3. Use picocom to get an interactive console on the target node: picocom /dev/ttySX -b 115200 (replace /dev/ttySX with the correct value for your target node, they don’t map as you’d expect):
    a. Node 1: /dev/ttyS2
    b. Node 2: /dev/ttyS1
    c. Node 3: /dev/ttyS4
    d. Node 4: /dev/ttyS5
  4. Back in the Turing Pi 2 Web UI, power on the target RK1 node. You should start seeing activity on your terminal.
    a. If you get to a login screen, you should be able to interact and make edits as needed.
    b. If you do not reach a login screen, hopefully the messages displayed on the screen will provide enough information as to what needs to be edited. Instructions for this in the next section.
  5. To exit picocom press ctrl+a followed by ctrl+x

If you identity an issue that requires editing, but the boot process doesn’t make it to the login prompt for you to make any chances, you can put the RK1 into MSD (mass storage device) mode.

Still SSH’d to the Turing Pi 2 BMC:

  1. Type tpi advanced msd -n X where ‘X’ is the node you want to put into MSD mode. It should return ok after a few seconds.
  2. There should now be a device present on /dev/sda
    a. You can run ls /dev/sda to see if it exists.
    b. If not, run modprobe rockusb and then check again.
  3. Once the device exists, mount it so we can access the configuration files we need to edit:
    a. Make a directory for the mount point: mkdir /mnt/rk1
    b. Mount the 3rd partition: mount /dev/sda3 /mnt/rk1
  4. cd into /mnt/rk1 and now you can browse / edit configuration files. The BMC has the vi editor installed for you to make changes.
  5. Once you’ve made the changes, unmount, return the device to normal, and reboot:
    a. umount /mnt/rk1
    b. tpi advanced normal --node X (Replace X with the number of your target node)
    b. tpi power off -n X (Replace X with the number of your target node)
    c. tpi power on -n X (Replace X with the number of your target node)

If it’s helpful: For my network config in /boot/dietpi.txt, I used static settings. In addition to using a static IP and setting the address, I also had to modify the gateway value, as that differed from the default config.

AUTO_SETUP_NET_USESTATIC=1
AUTO_SETUP_NET_STATIC_IP=192.168.1.164
AUTO_SETUP_NET_STATIC_MASK=255.255.255.0
AUTO_SETUP_NET_STATIC_GATEWAY=192.168.1.1

In /etc/network/interfaces, I un-commented the ‘allow-hotplug’ line, changed eth0 to end0 in two places, and modified the IP address & Gateway to match my local settings:

# Ethernet
allow-hotplug end0
iface end0 inet dhcp
address 192.168.1.164
netmask 255.255.255.0
gateway 192.168.1.1

Your settings will likely be different but hopefully that guidance helps.

I remember that I once used a way to copy dietpi on an CM4, where I only needed to set the OS in read-only, then copy the drive over to a SSD and afterwards make that the primary drive…
Sadly I don’t find that instructions anymore and didn’t got it the last time in my own to work…

May have been the blog post Moving a running DietPi system to a USB stick/disk or an onboard eMMC. I tried it and encountered the scenario they describe losing SSH access:

Read only vs. read/write file system:
If you set the file system to read only, an access via SSH is not possible after the reboot, i.e. in this case you need access to the local console (via keyboard and monitor).

Now that I’m familiar with using picocom, that would be a suitable workaround.

Also noted on the page:

Alternatively, you might keep the system set to read/write and do the copying in this state. Due to the fact that this might lead to an inconsistent file state (e.g. if a different user or process writes files in parallel to the dd command below), this should only be done if you are sure that no other users/processes use the file system during the copying process.

I did attempt while the system was still write-enabled since it’s a fresh install with no other users, but the system didn’t come back up. I also experienced this with my method as well. I was only trying on Node 3… … … physically removing and re-seating the node fixed the issue. Didn’t click that this original method may have actually worked fine.

1 Like
13

Interesting: After running dietpi-upgrade from 9.6.0 - 9.6.1 my ethernet adapter changed from end0 to eth0. So I had to use picocom on the Turing Pi 2 to login to each node and edit /etc/network/interfaces to be eth0.

EDIT: I did a fresh install of Debian and converted it directly to DietPi 9.6.1. It kept the end0 adapter name. So it might be something that changes after running dietpi-update and not anything version specific.

1 Like
14

Just re-looked at the blog post on moving an existing DietPi system to an external drive, and realize it’s basically the same method as what I’m doing (using dd to copy things over), except in the example blog, you remove the SD card before rebooting, which gets rid of the conflicting UUIDs. Since we’re moving from MMC to NVME and the MMC isn’t removable, I think the additional edits are required. And I don’t believe there is a way to change the boot order on the RK1 (at least when it’s attached to the Turing Pi 2 BMC).

1 Like
15

Thanks for the tip with picocom.
Sadly, it wants a user and password, but I didn’t find anything and all my tries didn’t work.
Did you have a recommendation? Because everything I find is, in the setup should you configure the login, but the installation is not the “normal” once with this image.

16

If it’s for the initial Debian image, the default credentials are:
Username: user
Password: user

If it’s after converting to DietPi, it should be:
Username: root
Password: dietpi

Need to login as root on the first boot of DietPi. After going through the first time boot setup, you can use the dietpi user.

Username: dietpi
Password: dietpi

Editing to Add
The default user & password for the TuringPi BMC
Username: root
Password: turing

Depending on which credential you were asking about, you can double check in dietpi.txt as you can specify the initial root & dietpi password in there as well.

17

What I found interesting, when I flashed the node while it is powered off, it won’t work, and I’ve got an error like:
platform a40000000.pcie: deferred probe pending: rockchip-dw-pcie: missing PHY
when I flashed it while the node was powered on, it worked. IDK if that’s related, but I think so. Then it worked, I just head a problem with the first boot, but after all it worked. THANKS A LOT!
The movement to a SSD I couldn’t try, since I have no SSD lying around, but that should work as on other devices (I hope so)

1 Like
18

@gregordinary the first one (a 8gb version) works fine, but the second one does say, after changing to diet pi, that there is no Ethernet-Adapter detected.
I figured out that the end0 was down, and could reactivate it, but I have no idea why this happens.

19

And now with another node, I have the problem that it hung after flashing the Debian image on:

random: crng init done

I temporarily connected a mouse to the USB-Port and changed it to the node. Then I could use it and reboot, and thereafter, the boot continued. IDK if it generated the randomness on the first boot with the mouse and then needed a reboot, or if it’s only the second boot that worked.
But just for others who maybe run also into this problem.

1 Like
20

Interesting behavior with the crng, I haven’t encountered that at all.

The Ethernet adapter has been tricky, initially it’s end0 but after any dietpi-upgrade it will revert to eth0. Subsequent upgrades have been fine and it’s stayed as eth0 and stayed active.

So far all 4 of my nodes have been running stable, the main hurdle for me now is getting a newer kernel with some additional video acceleration and NPU functionality (for better support on Jellyfin and Frigate NVR).