Dietpi: Rockpi 4 4GB wont boot up after flash.

[twerpyfie]

Creating a bug report/issue

Required Information

• DietPi version |
• Distro version | Buster
• Kernel version |
• SBC device | ROCKPi4-ARMv8
• Power supply used | 5V 3A
• SDcard used | SanDisk ultra 64GB

Additional Information

I cant boot up after a fresh flash to the SD-card
I used Rufus, Win32DiskImager, and Etcher
I dont get a picture when i connect the device to a monitor via HDMI (not with an adapter)
I dont see the device in my router when its connected to my LAN

Steps to reproduce

Flash rockpi4-debian-stretch-desktop on SD-card. Boot up and apt-get update && apt-get upgrade
(i dont know if this is the problem:) Type "y" at the question:

"Step one: upgrade bootloader on SPI Flash
One boot device, SPI Flash, is found, would you like to upgrade bootloader on it?
The installation would cost about seven minutes."

shut down the device

take out SD
flash Dietpi from https://dietpi.com/ to Sd
put it back and nothing works

Expected behaviour

Dietpi should boot up and show up in my router or show something on my monitor

Actual behaviour

The green LED lights up constantly
no picture on monitor, not showing up in router.

Extra details

It worked a few days ago. Then i used rockpi4-debian-stretch-desktop with the SD-card booted up and upgradet the bootloader on SPI Flash. I reflashed Dietpi, nothing works now.

I still can Flash rockpi4-debian-stretch-desktop and it will boot up, but dietpi wont.

[Joulinar]

Did you tried a different SD card already?

[twerpyfie]

Did you tried a different SD card already?

Yes, i tried a 2GB (class unknown)
another SanDisk 64GB ultra
and an Intenso 8GB class 10

I also tried another monitor.

Any ideas how to debug?

I looked into the /var/log, but unfortunately the logs are only stored in RAM by default.

[Joulinar]

well at least you should see some basic thinks on the monitor before DietPi scripts taking place. Strange.

What you can do is the following.

1) try to download the DietPi file again to unsure the old archive was not corrupted
https://dietpi.com/downloads/images/DietPi_ROCKPi4-ARMv8-Buster.7z

if this is still not working

2) download one of the alternative Debian systems like Armbian
https://wiki.radxa.com/Rockpi4/downloads

3) once done try to run some DietPi magic scripts to convert your alternative Debian systems into DietPi
see https://github.com/MichaIng/DietPi/issues/1285#issue-280771944

[twerpyfie]

Hay, so I checked the image before with a hash and it was not corrupt.

But the second tip with ARMbian and the DietPi installation worked great, thanks for this script and thanks for telling me. :D

You made my day!

This worked too with an fresh installed dietpi image:

If the SPI flash already contains a bootable bootloader, you need to disable the SPI flash at boot time by shortcut the SPI1_CLK to GND. Use wire to connect PIN 23 and 25 . Checkout the Pinout .

Check the picture on:

https://wiki.radxa.com/Rockpi4/dev/spi-install

[MichaIng]

@twerpyfie
That is actually a good hint with the SPI flash. Probably something we should add as troubleshoot.txt or README to our download archive?

[twerpyfie]

That is actually a good hint with the SPI flash. Probably something we should add as troubleshoot.txt or README to our download archive?

You could do that. The only problem is that with the cable method, you have to connect the two pins at every startup to suspend the SPI bootloader.

With the other method it is not a clean DietPi anymore. I tried to install Nextcloud after the installscript and the reboot with the DietPi-software command, but there was some problem with the database password.

[Joulinar]

@twerpyfie
I guess you received the following error, correct?

SQLSTATE[HY000] [1698] Access denied for user ¦ 'oc_admin'@'localhost'

This is an external issue with NectCloud 17.0.2 but @MichaIng provided a workaround

sed -i '/download\.nextcloud\.com/s/latest\.tar\.bz2/nextcloud-17.0.1.tar.bz2/' /DietPi/dietpi/dietpi-software

[twerpyfie]

@twerpyfie
I guess you received the following error, correct?

SQLSTATE[HY000] [1698] Access denied for user ¦ 'oc_admin'@'localhost'

This is an external issue with NectCloud 17.0.2 but @MichaIng provided a workaround

sed -i '/download\.nextcloud\.com/s/latest\.tar\.bz2/nextcloud-17.0.1.tar.bz2/' /DietPi/dietpi/dietpi-software

I wanted to check the error message, but all of a sudden the script does not work anymore ... I am haunted by bad luck.

[Joulinar]

what is not working anymore?

[twerpyfie]

what is not working anymore?

I flashed Armbian like the other day. Then i followed the instructions and used the PREP_SYSTEM_FOR_DIETPI.sh to make a DietPi system. Then i got this error:

./PREP_SYSTEM_FOR_DIETPI.sh: line 1226: syntax error near unexpected token rm' ./PREP_SYSTEM_FOR_DIETPI.sh: line 1226: [[ -f '/etc/udev/rules.d/70-persistent-net.rules' ]] rm -v /etc/udev/rules.d/70-persistent-net.rules # Jessie pre-image'

How is it possible that it work one day and the next day it does not work anymore!?

[Joulinar]

I see a Jessie pre-image message. Are you using the correct script?

wget https://raw.githubusercontent.com/MichaIng/DietPi/master/PREP_SYSTEM_FOR_DIETPI.sh -O PREP_SYSTEM_FOR_DIETPI.sh

[MichaIng]

Sorry guys, my fault, syntax fixed: https://github.com/MichaIng/DietPi/pull/3298/commits/7490b4c0afe7c65b0ffb386ceed02f4796aef1aa

[twerpyfie]

I see a Jessie pre-image message. Are you using the correct script?

wget https://raw.githubusercontent.com/MichaIng/DietPi/master/PREP_SYSTEM_FOR_DIETPI.sh -O PREP_SYSTEM_FOR_DIETPI.sh

Yes i did, MichaIng solved the problem.

But I also have something good to report:

The original problem can probably be solved by removing the SPI bootloader. Here is an instruction:
(under "Erase images on SPI device")
https://wiki.radxa.com/Rockpi4/dev/spi-install

One assumption of mine is that it has something to do with MBR and GPT.

I'll test it tomorrow to see if it works. (Unless you need a USB male to USB male cable, because I don't have one).

[MichaIng]

@twerpyfie
Sounds great. Could you open a new issue about this? Basically an SPI bootloader sounds reasonable, but then it must be possible to upgrade it, e.g. writing it back on usual u-boot package upgrades. But yeah... if this inherits that it is only able to boot the current image but not any new flash (with different UUIDs/partitioning/kernel), then it's probably best to skip it completely to always load the bootloader from first partition.