Hardware issues with Rock64

[grobbs]

According to an Armbian forum post about Rock64:

Rock64 has many hardware problems, that is the reason why we don't support it anymore.

I'm disappointed to see that Rock64 went from supported to unsupported. Armbian has been my go-to image.

What is the future of the board? Is Pine64 addressing the issues?

Are there any other Linux distributions with accelerated hardware support (GPU, etc.)?

[Rocklobster]

According to an Armbian forum post about Rock64:

Rock64 has many hardware problems, that is the reason why we don't support it anymore.

I'm disappointed to see that Rock64 went from supported to unsupported. Armbian has been my go-to image.

What is the future of the board? Is Pine64 addressing the issues?

Are there any other Linux distributions with accelerated hardware support (GPU, etc.)?

That is worrying and well spotted. Like yourself it's my Distro of choice too. Looks like we may well be left with an expensive door stop eventually. That will not bode well for the manufacturer. I wonder would a representative like to comment on this.

[grobbs]

That is worrying and well spotted. Like yourself it's my Distro of choice too. Looks like we may well be left with an expensive door stop eventually. That will not bode well for the manufacturer. I wonder would a representative like to comment on this.

I'm hoping to hear from Pine64 on this, too. Do they read the forums?

[as365n4]

The Rock64 is still alive and well, don't let you missguide you by the folks at Armbian.
Three of the most popular Distros still support the Board.

Arch --> https://archlinuxarm.org/platforms/armv8...hip/rock64

Manjaro --> https://gitlab.manjaro.org/manjaro-arm/a...-installer

Debian --> https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/

Even though Debians installer might be broken somewhat, but you can still use Vanilla Debian by following these guides for instance.
https://www.kulesz.me/post/140-debian-de...4-install/
https://github.com/as365n4/Debian_on_Roc...Rock64.pdf

[Rocklobster]

It was hard enough to find a stable Distro at the start that supported the Rock64. I do understand that this was a tinkerer's board but I don't want to spend the rest of my life trying to get an OS installed and working properly.

It can clearly be seen that posts on the Rock64 are down to a trickle so either everyone is happy with their setup or they have walked away. I'm thinking the latter. It's a pity if they have as its been a very stable board for me running Armbian for the last couple of years.

[as365n4]

Everyone is playing with their new shiny toys, aka PinePhone and PinebookPro. All the subs releated to bare boards have kinda died down a bit or getting just drowned by the noise of the other two. ;-)

Nothing to worry about.

And Arch is very stable, rock solid and very easy to install as described on their website, nothing special or fancy about it.

Debian needs tinkering a bit, as their Installer is a work in progress or do-it-your-self from scratch.

[kanelxake]

Oh, I fully understand armbian in this regard.

I have 4 4GB rock64. None of them has a serial number, either printed on them, or set in the efuse. In fact the efuse is empty. This results in stuff like this:

https://forum.armbian.com/topic/14653-ro...wo-boards/

This was not such an issue before uboot got proper efuse-support, because before that the MAC was set random at first boot. However, with any new enough uboot (and I think we are talking a release at least 1-2 year old) and the more of the proper hardware that is brought up in mainline expose more problems like this in the rock64.

For me this shows very much by downloading the buster minimal image from https://github.com/ayufan-rock64/linux-b...ag/0.10.12 to an SD card and use the same card to boot all 4 boards .



uboot will for all 4 boards report:

Code:

cpuid#=300bf2fc000000008c79f4fe00000000
ethaddr=a2:f5:47:18:b2:e3

And Linux will report:

Code:

root@rock64:~#  xxd /sys/bus/nvmem/devices/rockchip-efuse0/nvmem
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................

The last one should not be all 0.
The same if I boot Fedora 33 on it.

Also my boards have problems to reboot from time to time, or rather sometimes they do not come up afterwards.
There has also been unstable eth and USB.
For a community project like armbian having to deal with this kind of support is not sustainable.

[t4_4t]

As far as I know, '0.9.16: gitlab-ci-linux-build-163' is the last version of 'u-boot' with the correct implementation of 'efuse' support.
The so-called 'main-line' ' u-boot', does not have the 'efuse' support function correctly implemented.
(* It may be more accurate to say that the'efuse'support feature itself has been removed.)

Try the following image,
https://github.com/ayufan-rock64/linux-b...m64.img.xz

If this still gives the same result, your claim (In fact the efuse is empty) is correct.
On the other hand, if you get a reasonable value, it's just a 'u-boot' problem.

---

For reference, below is an example of my execution.
From the same board, I get a completely different reaction.
And one of the outputs is the same value you got.

@ buster-minimal-rock64-0.10.12-1184-arm64.img.xz

Code:

u-boot:
cpuid # = 300bf2fc000000008c79f4fe00000000

buster:
# xxd / sys / bus / nvmem / devices / rockchip-efuse0 / nvmem
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................

@ buster-minimal-rock64-0.9.16-1163-arm64.img.xz

Code:

u-boot:
cpuid # = 55524b50303930303800000000xxxxxx

buster:
# xxd / sys / bus / nvmem / devices / rockchip-efuse0 / nvmem
00000000: 524b 3382 00fe 2155 524b 5030 3930 3038 RK3 ...! URKP09008
00000010: 0000 0000 xxxx xxxx xxxx xxxx 0000 0000 ................

* 'xxxx' is hidden for security reasons.

[kanelxake]

As far as I know, '0.9.16: gitlab-ci-linux-build-163' is the last version of 'u-boot' with the correct implementation of 'efuse' support.
The so-called 'main-line' ' u-boot', does not have the 'efuse' support function correctly implemented.
(* It may be more accurate to say that the'efuse'support feature itself has been removed.)

Try the following image,
https://github.com/ayufan-rock64/linux-b...m64.img.xz

If this still gives the same result, your claim (In fact the efuse is empty) is correct.
On the other hand, if you get a reasonable value, it's just a 'u-boot' problem.

This might be true. I do not have the time today to test, but will do it to make sure it is not my card that is messed up.
However this also shows the heart of the problem here:
How many forks of uboot and the kernel should a project like armbian need to package? Really one for every manufacturer with incompatible patches? And knowing the gotchas when users "uses the wrong version"?
If neither Rockchip nor pine64 can make the card properly working in mainline versions of critical parts of the plumbing like uboot and the kernel then why should armbian - a community project - push resources into trying to support this uniq flavor of hardware it?
So I can understand why they still package it, but also why they do not want take time trying to figure out users problems with it.

I also do not understand why the ' around mainline. Mainline is mainline. everything else is a fork until it becomes its own viable project with its own name that succeeds in becoming a contender or even surpassing the original. See for example MySQL and MariaDB, OpenOffice and LibreOffice. Or for that matter the Linux and Android kernel.
The vendors forks of uboot are code drops and not viable projects in its self, and their patches should really be up-streamed into mainline projects if they want community projects like Armbian to actually be able to fully support it, and not having to try to figure out if the user have a software bug, another gotcha with using "the wrong fork" or an actual hardware problem.

[as365n4]

There is no need to defend Armbian, from my experience and others had similar encounters with them.

If a user turns up at their forum with a problem, first thing they yell at them --> "read the wiki" even if it does not cover the issue in question remotely.
Next they tell them "you have a problem you need to pay for the support" because support costs money and time and they have neither.
And if the user still dares to come back and ask for help they get told we don't have the hardware to reproduce the probelm and by the way that patch that would be needed to fix the issue breaks our setup so we don't care about your problem and will not apply the suggested patch even it would help a majority of users.

See all in all not very user friendly atmosphere overthere. Sorry to say that.
Other Distros are doing much better in this regard, especially the guys at Arch Linux Arm or Manjaro which seem to be the Prime Distros for Pine64 products.

Regarding the reboot issue on Rock64, this appears to be a software problem as I get on Debian every now and then that something calling for device /dev/ttyAM0 gets stuck in a loop and therefore the boot process can not finish. A simple press on the reset button fixes the problem, but this only helps if you have direct acces or be able to interrupt power remotely as this will cancel the loop as well.