OPI5Plus - 32GB version issue

[BOFFBOY]

Hi all,

Just want to share this issue i came across from my recently purchased OPI5+ 32GB version.

I noticed it freezes when transferring .img from micro SD card to eMMC or NVMe drives via the command line.

 

Now the img file are armbian OS and no its not the img file issue.

 

at times I can get it to around 70seconds and it will freeze. hard reboot is required, unable to complete the transfer.

 

I have also tried to reduce the bs=10 speed but still the same.

 

 

Now i have also got the 16GB version and this works fine with no issues...

 

Good chance there is something wrong with this latest hardware..  ? ? 

[Werner]

Tried armbian-install?

[BOFFBOY]

thank you, the issue is the 32GB version seem to have some problems which i am not encountering on the 16GB version although i am using the same methods on both.

 

Will be interesting to see when someone can do some more advance test on it.

[Zaerc]

Isn't /dev/mmcblk1 actually the microSD card, like it is on my OPi5+ machines? 

[BOFFBOY]

mmcblk1 is eMMC.

 

I have also noticed this new 32GB version randomly crashes... never crashed with 16gb version...

 

mainboard version on this is V1.3.1 FYI if anyone interested to know.

[Eddie]

Yes, it crashes. It looks like it’s related to nvme drive activity.
Running 6.8-rc7 atm.

[ghosty]

Hi,

I am having the same issue and I'm in the same scenario as yourself.

I also have 2 OPi 5+ one with 16GB RAM and the other 32GB RAM. The 32GB version crashes as soon as the NVMe usage becomes intense. I have tested with different NVMe drives (both are 2TB size so... Not sure if it isn't some limitation on that side) and if I connect it through USB it works without a glitch.

 

I'm starting to suspect something's badly soldered or installed physically.

 

Did you manage to solve your issue?

[BOFFBOY]

yep, something is wrong with the 32GB version... i have tested with a few NVMe's still the same result...

 

I will test this one the non Plus version (Orange Pi 5B 32GB)

Edited May 5 by BOFFBOY

[Victor Pecherskiy]

Hi all,

 

I'm having issues with 32GB version of Orange Pi 5 Plus as well (kernel panic).

It can be easily reproduced by running 

sudo memtester 30G

After a few seconds it crashes.

At the same time it works well on 16GB version of Orange Pi 5 Plus. I tried also installing Ubuntu 24.04 LTS and it works well.

[Victor Pecherskiy]

Tested with Armbian_24.2.3_Orangepi5-plus_bookworm_legacy_5.10.160_minimal and Armbian_24.2.4_Orangepi5-plus_jammy_vendor_6.1.43_kde-neon-amazingfated_desktop - the server version kernel panics, the desktop version freezes.

Edited May 6 by Victor Pecherskiy

[royk]

@Victor Pecherskiy To rule out if it's a hardware or software problem have you tried an "original" image from orange pi?

[Victor Pecherskiy]

@royk, have not tried yet, hope to try soon. Since Ubuntu by Joshua Riek seems to work well, it seems to be a software problem.

[Werner]

40 minutes ago, Victor Pecherskiy said:

Since Ubuntu by Joshua Riek seems to work well, it seems to be a software problem.

Which is kind of odd since both Armbian and Joshua's work are very close kernel-wise.

[royk]

@Victor Pecherskiy Then it seems like a software problem, unfortunately I don't have a 32GB to test it with. And what if you copy the dtb from Joshua Riek's image to your Armbian installation?

 

This is a difference I found but not sure if it's possible to be the cause:

https://github.com/Joshua-Riek/linux-rockchip/commit/fdf8d484eccb0949664b78b16e0a275e75c52e0d

Edited Monday at 06:46 PM by royk

[lanefu]

does Armbian image use same DDR blobs as Joshua's?

[royk]

@lanefu

Armbian

DDR_BLOB='rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.15.bin'
BL31_BLOB='rk35/rk3588_bl31_v1.44.elf'

 

Joshua Riek

u-boot-rockchip_platforms += orangepi_5
orangepi_5_ddr := rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.11.bin
orangepi_5_bl31 := rk3588_bl31_v1.38.elf
orangepi_5_pkg := orangepi-5

 

Xunlong Orange Pi

if [[ ${BOARDFAMILY} == "rockchip-rk3588" ]]; then
		local rkbin_url="https://github.com/orangepi-xunlong/rk-rootfs-build/raw/rkbin/rk35"
		wget -qnc -P ${EXTER}/cache/sources/rkbin-tools/rk35/ ${rkbin_url}/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.15.bin
		wget -qnc -P ${EXTER}/cache/sources/rkbin-tools/rk35/ ${rkbin_url}/rk3588_bl31_v1.44.elf

 

@Victor Pecherskiy So to rule out that the newer DDR blob is the problem you could try an Orange Pi image.

Edited Tuesday at 02:00 PM by royk

[Victor Pecherskiy]

Hi all,

 

On 5/6/2024 at 7:17 PM, royk said:

And what if you copy the dtb from Joshua Riek's image to your Armbian installation?

@royk, I tried to replace rk3588-orangepi-5-plus.dtb file but it doesn't boot at all.

 

3 hours ago, royk said:

So to rule out that the newer DDR blob is the problem you could try an Orange Pi image.

 

Something really strange is happening. Yesterday I tried the following official Orange Pi images on eMMC:
 

Orangepi5plus_1.0.8_ubuntu_jammy_server_linux6.1.43
Orangepi5plus_1.0.8_debian_bookworm_server_linux6.1.43
Orangepi5plus_1.0.8_debian_bookworm_server_linux5.10.160

They seemed to work well, at least did not crash after starting of memtester.

Today I tried Joshua Riek's image loaded from SD card, it crashes also, tried 3 times. After that I flashed the same image to eMMC and it seems to work.

And after flashing it to eMMC the image booted from SD card started working again

 

I'm still trying to figure out the condition when it crashes and when it doesn't.

Edited Tuesday at 05:29 PM by Victor Pecherskiy

[Victor Pecherskiy]

@BOFFBOY, @eddie, @ghosty could you try to run

sudo memtester 30G

(or 20G if you don't have enough free memory) ?

Edited Tuesday at 04:49 PM by Victor Pecherskiy

[Eddie]

[mention=210507]BOFFBOY[/mention], [mention=10316]eddie[/mention], [mention=211994]ghosty[/mention] could you try to run

sudo memtester 30G

(or 20G if you don't have enough free memory) ?

Crashed.

[Charlie Romer]

I just want to jump in here as I started running into these issues while upgrading my homelab server running DietPi from a 16GB to 32GB unit (or at least hoping to but thats on pause for now haha). As a test I just installed a fresh copy of 

Orangepi5plus_1.0.8_debian_bookworm_server_linux6.1.43

and ran 

sudo memtester 30G

and it resulted in a panic. I also tried the same command starting at 8G (fine), 10G (fine) and then 11G and it panic'd.  A fresh install and only running

sudo memtester 11G

resulted in a panic too. 

 

 

The only unique aspect that I can add about my setup is that I did run the SPI bootloader update to be able to boot from NVME (however the only storage drive attached is an the boot SD card). I can also install to eMMC as well if that would be helpful.

 

I managed to capture a slow mo video of the start of the panic and have posted a screenshot of the start of the panic here in case it's useful in any way. 

 

This is all a bit over my head but I'd be happy to help if there's anything I test and report back on if someone doesn't mind walking me through things. 

 

[SteeMan]

@Charlie Romer  This site is for Armbian issues not DietPi issues.  You need to direct your question to DietPi forums as we can't help you here.

[Charlie Romer]

Oh you misunderstand - I am here because I originally started with DietPi - now I just want to figure out why this thing kernel panics at all on whatever OS. This forum seems to be the only place currently discussing it and y'all seemed like you needed help... 

[SteeMan]

42 minutes ago, Charlie Romer said:

As a test I just installed a fresh copy of 

Orangepi5plus_1.0.8_debian_bookworm_server_linux6.1.43

That is not an Armbian build.  If that is what you have installed it isn't relevant to discussions here.

[Charlie Romer]

That was a suggested troubleshooting step from a previous post - installing official orange pi images and running memtester to see if it would also panic... 

On 5/7/2024 at 12:43 PM, Victor Pecherskiy said:

So to rule out that the newer DDR blob is the problem you could try an Orange Pi image.

So thats what I just did (as others seem to have done in previous posts as well)... Unless I completely misunderstood the conversation taking place I don't think I'm out of line here. If anyone wants my help (little that it may be I do at least have the hardware in hand) let me know otherwise I can just sit back watch.

Edited Thursday at 07:53 PM by Charlie Romer
clarification

[SteeMan]

@Charlie Romer  Thanks for the explaination.  And thanks for the help.  But since you aren't running Armbian, this won't help your DietPi situation.  Often users come here to get help with DietPi thinking that because it is forked from Armbian that we can help them, but we can't.

[Charlie Romer]

Nope - been around long enough to know each distro has it's own crap to figure out. I do eventually hope to see fixes applied downstream in DietPi whenever someone figures out what's going on but right now I'm just a person trying to help the community of OPi5+ folks with no agenda towards DietPi. If the 32GB model only works with Armbian so be it but right now it seems to have this issue (or related issues) across all of the OSes that I've tried/read. 

 

FWIW same issue on 

Armbian_24.2.3_Orangepi5-plus_bookworm_legacy_5.10.160_minimal

But I think this was already known

[Igor]

1 hour ago, Charlie Romer said:

Nope - been around long enough to know each distro has it's own crap to figure out.

 

You might insult many people if you compare Armbian with Dietpi. They download Armbian (firmware is binary copy), run BASH script to re-brand, add their script junk and sell as "supported". When bug is found they say "oh, this trash Armbian", when someone say compliment, they take it. This is how piracy works in open source. Compliment and recognition of work is everything. They contribute nothing to Armbian, nor its possible to take anything. Where we would, as community, progress, if we would just steal and pretend?

 

1 hour ago, Charlie Romer said:

But I think this was already known

Board manufacturer is responsible to fix this problem. They know how and where change is needed. But ... they compete with OS we made with us.  Are you sure, you are long enough around to see it all?

[Charlie Romer]

Ok well this has gone poorly with you guys... I really dont care about what OS I'm playing with - DietPi can apparently go **** themselves - cool, I'm not them - I'm just a dude who happened to be using it this morning but now I'm not... This seemed to be a discussion about kernel panics happening on the OPi5+ 32GB which I have and am experiencing no matter which OS I install and run a memtest on. They happen on Armbian too and you guys have a forum post that relates to my problem. Thus I am here.

 

In terms of your beef with DietPi - would it make y'all feel better if I edit my posts and I started with Armbian all along? For the purposes of this discussion the originating reason why I came here really shouldn't matter if the result is the same on either OS. I honestly have no clue about your beef with DietPi (most of my experience comes from either raspbian or with non arm OSes - and OS politics is not my jam) and you've given me a negative vibe about them so I'll probably leave but at the moment I dont have a good vibe from Armbian either by how I'm being treated here. 

 

I came in with a good attitude offering up what I can in terms of help (and trying to follow the previous steps outlined in this thread). Can we get back on track talking about the issue at hand or am I just not going to get anywhere with you guys?

 

 

[Igor]

7 minutes ago, Charlie Romer said:

Thus I am here.

 

Welcome!

 

Remember that this is forum, not a professional technical support service that waits on problems. We are on the same side. Problems takes years to be resolved as there is nobody behind. They don't invest, you don't invest, we can't invest into support service you might with or expect.

 

6 minutes ago, Charlie Romer said:

They happen on Armbian too

 

We didn't produce this hardware and manufacturer doesn't work with us. They almost literally throw hardware like bone to a dog. Armbian ultra small team have to deal with other things then this hardware / 3rd party (copy of) OS clients problems.

 

16 minutes ago, Charlie Romer said:

I honestly have no clue about your beef

Now you know. You came from a project that has bad reputation, you are using hardware from manufacturer that does not support open source software. They are not alone. More makers are abusing community to generate software, support and sales. But some genuine help and there our focus goes. Sometimes we made wrong judgements ...

 

If you mentioned RPi. They are far from being modest example, but they are returning about 2M USD annually back to community. Here small dealers, who have no affection and understanding how non profit community works, are competing how well they will abuse this community. The more the more they will profit - that is why there is so much bad vibes here. Some are doing everything to optimise this abuse. Not talking just about Armbian, but developers community at large. No need to mention, that Dietpi is not a part of this game. They don't suffer as nobody never took anything from them in past 10 years.
 

13 minutes ago, Charlie Romer said:

I'll probably leave but at the moment I dont have a good vibe from Armbian either by how I'm being treated here. 

What did you expect? Truth or fake happiness and prompt resolving of your problem? With our private money and in private time? "Case number 125323". Perhaps weeks of research is needed. Not just trolling on forums?

 

I believe you didn't know nothing about this and it feels me bad that I have to tell you this. But this is your problem too and I hope now you see why. If open source developers are not happy, you will not move them with anything. Just trying to draw you a bigger picture. Raspbian / RaspberryPi has IMO 20-30 full time engineers for supporting clients and they have classes easier job then we do. We have not a single one.

[Charlie Romer]

 

2 minutes ago, Igor said:

We are on the same side.

This is what I've been trying to say the whole time... I know many distros are small projects with no full time developers. I saw in this thread that it looked like you guys could use some help and given how new this board is I wasn't expecting anyone to just solve something for me. I wanted to jump in and help if and where I could. 

What did you expect? Truth or fake happiness and prompt resolving of your problem?

The opposite literally. I figured that if I have the ability to help and hardware in hand that I should help (or at least offer to be a guinea pig) - I wasn't and haven't been looking for someone to solve this thing for me but literally offering my assistance as I happen to have the hardware and wanted to give back if I could. This whole conversation has felt like I've been gaslit by people who assume everyone posting for the first time on this forum must be demanding fixes for everything right now. That may be many (or even most) folks but it's not a great feeling when all you're doing is trying to offer help.