sminder Posted December 23, 2023 Posted December 23, 2023 I've got Orange Pi 5 Plus board with 16 Gb of RAM, 256 Gb of eMMC, Realtek RTL8852BE-CG wireless module. SD card is Samsung EVO Plus 32Gb. I tried to run Armbian images on this board (from the SD-card I've mentioned before) but it was absolutely failed. I tried 5 images: Armbian_23.11.1_Orangepi5-plus_jammy_legacy_5.10.160_gnome-amazingfated_desktop.img.xz Armbian_23.11.1_Orangepi5-plus_bookworm_legacy_5.10.160.img.xz Armbian_23.11.1_Orangepi5_jammy_legacy_5.10.160_gnome-amazingfated_desktop.img.xz Armbian_23.11.1_Orangepi5-plus_bookworm_edge_6.7.0-rc1.img.xz Armbian_23.11.1_Orangepi5-plus_jammy_edge_6.7.0-rc1.img.xz which I downloaded from your website but the result the same: tons of errors, a lot of dumps, no even chance to see a desktop. Also I should say the official images of Ubuntu and Debian works fine so I guess it's not a hardware issue. There is UART log when I tried to start Armbian_23.11.1_Orangepi5-plus_jammy_legacy_5.10.160_gnome-amazingfated_desktop.img.xz image putty.log Could anyone tell me what the problem is? 0 Quote
Werner Posted December 23, 2023 Posted December 23, 2023 I think @NicoD tested the 16G model with those images and made videos. Right? 0 Quote
Igor Posted December 23, 2023 Posted December 23, 2023 2 hours ago, sminder said: it's not a hardware issue. It is. - Armbian works perfectly well on 1st class hardware such as x86, ampere aarch64, raspberry pi, ... - Armbian also works well on our test devices https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results - Armbian boots normally on 16Gb Orangepi Plus 5 https://paste.armbian.com/quzavajida (Armbian_23.11.1_Orangepi5-plus_bookworm_legacy_5.10.160.img.xz) It is certainly a hardware issue without even looking into the logs. What is then? Vendors often change memory chips (sometimes without telling anyone) so only their images works with a new batch of boards until we waste insane amount of time to figure that and fix = huge blow for our personal time / finances ... A change of memory chips is enough that things crashes, different (broken) wireless driver (i didn't look into logs) is used, something odd is attached to USB / HDMI ports ... Try bare hardware, different SD card, different power supply, make a photo of PCB (revision, memory chip numbers, ...). 2 hours ago, sminder said: official images of Ubuntu and Debian Where do you think they took (stole as they didn't tell you where they got it) software, that looks the same as Armbian, from? 2 hours ago, sminder said: I tried 5 images FYI. All images are assembled the same way and builds are now even reproducible. Its highly unlikely that one image will boot and the other wont. 0 Quote
Tony3 Posted December 23, 2023 Posted December 23, 2023 Probably stupid remark, but why entering 154? 77) es_VE.UTF-8 154) Skip generating locales Please enter your choice:154 0 Quote
Igor Posted December 23, 2023 Posted December 23, 2023 28 minutes ago, Tony3 said: Probably stupid remark, but why entering 154? No idea. its a part of stock Debian timezone & locales generation. Here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=tzdata;dist=unstable https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=locales;dist=unstable 0 Quote
ricardo_brz Posted December 23, 2023 Posted December 23, 2023 Quote why entering 154? I use 154! I understand it will use C.UTF-8 as locale. That's what I've been using forever, and it just works... 1 Quote
sminder Posted December 24, 2023 Author Posted December 24, 2023 (edited) 15 часов назад, Tony3 сказал: Probably stupid remark, but why entering 154? Actually it doesn't matter - I tried another one with the same results. Will it help if I post the hardware info (chips name e.t.c) to find out the problem? Edited December 24, 2023 by sminder 0 Quote
Tony3 Posted December 24, 2023 Posted December 24, 2023 (edited) have you thought about using another SD card? Maybe SD card corrupetd? this is the other common thing between all your tries. Edited December 24, 2023 by Tony3 0 Quote
sminder Posted December 24, 2023 Author Posted December 24, 2023 (edited) No, I haven't, but I will. The reason I didn't change the SD-card is this card works pretty well with another boards and another OS. Edited December 24, 2023 by sminder 0 Quote
hste Posted December 24, 2023 Posted December 24, 2023 A log from the image from orangepi that boots to compare with the one that fails. Check if the dtb files are different and what is changed from the armbian dtb. If different try to swap to the one working from orangepi 0 Quote
Tony3 Posted December 24, 2023 Posted December 24, 2023 I had similar issues in the past with a bad SD card 0 Quote
sminder Posted December 24, 2023 Author Posted December 24, 2023 (edited) I tried two another SD cards, even super-speed Samsung Pro, but result the same - tons of errors. I copied rk3588-orangepi-5-plus.dtb file from Debian image to Armbian image (they are obviously different because of size) but result the same - tons of errors. I attached the boot log of Orange Pi Debian image. orpi5+_debian_good_boot_log.txt Edited December 24, 2023 by sminder 0 Quote
ricardo_brz Posted December 25, 2023 Posted December 25, 2023 did you also check the power supply? Another thing I noticed was that among your trial you used: On 12/23/2023 at 12:38 PM, sminder said: Armbian_23.11.1_Orangepi5_jammy_legacy_5.10.160_gnome-amazingfated_desktop.img.xz Maybe you have installed this at some point and it kinda breaks the process and you need to reinstall the "plus" one again to fix it? 1 Quote
Spooky Posted December 28, 2023 Posted December 28, 2023 The user here has different DDR and BL31 blob being used in u-boot. The recent RKBIN blobs have a warning in the release about this. I assume the user installed the bootloader to the SPI FLASH using the official OrangePi distro which has these newer RKBIN blobs. Updating RKBIN for Armbian should address this. But I worry as miss-matched RKBIN blobs could introduce this issue to existing installs. Anyone have any thoughts? 0 Quote
prahal Posted December 30, 2023 Posted December 30, 2023 On 12/28/2023 at 6:12 PM, Spooky said: The user here has different DDR and BL31 blob being used in u-boot. @Spooky I see the same `DR V1.13 25cee80c4f cym 23/08/11-09:31:58` For the putty log from Armbian_23.11.1_Orangepi5-plus_jammy_legacy_5.10.160_gnome-amazingfated_desktop.img.xz and Orange Pi Debian images. The ATF differs BL31: - Orange Pi Debian: `NOTICE: BL31: v2.3():v2.3-639-g87bcc5dfe:derrick.huang NOTICE: BL31: Built : 18:06:16, Sep 9 2023` - Armbian_23.11.1_Orangepi5-plus_jammy_legacy_5.10.160_gnome-amazingfated_desktop.img.xz : `NOTICE: BL31: v2.3():v2.3-405-gb52c2eadd:derrick.huang NOTICE: BL31: Built : 11:23:47, Aug 15 2022` Maybe trying building the armbian u-boot with the newer v2.3-639-g87bcc5dfe:derrick.huang ATF would tell? 0 Quote
RonC Posted December 31, 2023 Posted December 31, 2023 I got Armbian_23.11.1_Orangepi5_bookworm_legacy_5.10.160.img to work on mine, but Jammy failed. Bookworm is super bare-bones though, with no networking to install anything. I'm looking in to that. Ron 0 Quote
Solution sminder Posted January 1 Author Solution Posted January 1 Happy New Year guys! Fortunately I fixed a problem and start Armbian on my board. In short: the main problem was in SPI flash memory. More details: I wanted to install Android on my board, and it was unsuccessful (I tried to boot if from SD-card) and I decided to install it on the inner eMMC memory. So I followed the instructions "2.9. How to burn Android image into eMMC" from the official Orange Pi manual. One thing that helps to start Android from eMMC is clearing SPI-flash memory. I did it and Android started successfuly. But after that I can't start any other images from SD-card - after power on Android always starts first. So I decided to repair SPI-flash. I folowed the last post from here Maskrom / erase SPI and SD-cards start booting. So I decided to theck state of booting Armbian image after that and... it's alive! I can boot Armbian_23.11.1_Orangepi5-plus_bookworm_legacy_5.10.160.img.xz image without a problem! Here is a log of Armbian boot: armbian_boot_log.txt 0 Quote
sminder Posted January 1 Author Posted January 1 Update: the image Armbian_23.11.1_Orangepi5-plus_bookworm_edge_6.7.0-rc1.img.xz also works fine, even with a desktop. 0 Quote
BOFFBOY Posted January 17 Posted January 17 Armbian_23.11.1_Orangepi5-plus_jammy_legacy_5.10.160_gnome-amazingfated_desktop.img also works perfectly... except for the xrdp audio issue. 0 Quote
MakKou86 Posted January 17 Posted January 17 (edited) Hi. I had a problem when loading the "Armbian_23.11.1_Orangepi5-plus_jammy_legacy_5.10.160_gnome-amazingfated_desktop" image for the first time. Board - Orange Pi 5 Plus with 16 Gb of RAM, 256 Gb of eMMC. SD card - SanDisk Ultra microSDHC 32 ГБ. During the first boot, after entering the password, root asks you to select a shell (bash zsh). But, so that I do not enter or write, he asks me to re-select it. What could be the problem? The problem was solved by replacing the keyboard. The upper part stopped working. Edited January 17 by MakKou86 0 Quote
BOFFBOY Posted January 17 Posted January 17 select 1 and then enter your name and select timezone... simple just follow the screen.. its either y or n 0 Quote
ozacas Posted February 4 Posted February 4 Hi all, FWIW I had made a custom image (based on Ubuntu 24.04, edge kernel 6.8.0rc1) for orange pi 5 plus. Booted successfully from SD card, copy to EMMC using armbian-config and NVME support (although not used for booting). Working nicely - most things working, except for GPU accel and other bits. Oddly, poweroff does not - it reboots. Details of the opi5+ can be found at https://paste.armbian.com/ovoyijijic 0 Quote
Marco Schirrmeister Posted February 4 Posted February 4 If you want poweroff working, then you need to apply the following patch. https://lore.kernel.org/lkml/pqvmguq77qbxmuxsushrz4ykxtmvkugirbxnckmbfk47gx2u5n@cz2kllnjr6ba/T/ Just out of curiosity, do you see a kernel irq "hym8563" process with high cpu usage? 10% give or take. I would assume yes, because in interrupt output from your paste board has high numbers. 48: 19767 39 36 42 18 16 16 2850824 GICv3 355 Level fec80000.i2c 49: 3291 7 5 7 4 2 3 475101 rockchip_gpio_irq 8 Level hym8563 0 Quote
ozacas Posted February 5 Posted February 5 Not quite ten percent, but certainly active around the 5-6% range as reported by top(1) - see attached piccie. Thanks for the poweroff patch, i'll patch my kernel tree and see how it goes. cheers 0 Quote
Marco Schirrmeister Posted February 5 Posted February 5 That looks about right. Load around 1 and the hym8563 changes for me between 5-10%. Here is the patch I created for the OPi5+ and apply during my image builds. Tested with 6.8-rc1, rc2 and rc3 with bookworm and trixie. I hope that this things make it sooner than later in the mainline kernel. builder@dumpster /m/t/t/n/build (main)# cat userpatches/kernel/rockchip-rk3588-edge/1000-arm64-dts-fix-rtc-add-poweroff-support-Orange-Pi-5-Plus.patch From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: John Doe <john.doe@somewhere.on.planet> Date: Mon, 29 Jan 2024 12:51:13 +0100 Subject: Patching kernel rockchip-rk3588 files arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts Signed-off-by: John Doe <john.doe@somewhere.on.planet> --- arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts index 88bfce6237db..70cc6bd5a0af 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts @@ -462,11 +462,11 @@ &pcie3x4 { }; &pinctrl { hym8563 { hym8563_int: hym8563-int { - rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; + rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>; }; }; leds { blue_led_pin: blue-led { @@ -572,10 +572,12 @@ pmic@0 { pinctrl-names = "default"; pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>, <&rk806_dvs2_null>, <&rk806_dvs3_null>; spi-max-frequency = <1000000>; + system-power-controller; + vcc1-supply = <&vcc5v0_sys>; vcc2-supply = <&vcc5v0_sys>; vcc3-supply = <&vcc5v0_sys>; vcc4-supply = <&vcc5v0_sys>; vcc5-supply = <&vcc5v0_sys>; @@ -592,11 +594,11 @@ pmic@0 { gpio-controller; #gpio-cells = <2>; rk806_dvs1_null: dvs1-null-pins { - pins = "gpio_pwrctrl2"; + pins = "gpio_pwrctrl1"; function = "pin_fun0"; }; rk806_dvs2_null: dvs2-null-pins { pins = "gpio_pwrctrl2"; -- Created with Armbian build tools https://github.com/armbian/build 0 Quote
ozacas Posted February 5 Posted February 5 Builds cleanly. No issues rebooting into the revised kernel - but for me poweroff doesnt turn off the red LED on the front panel. Not sure whether this is expected. cheers Andrew 0 Quote
Marco Schirrmeister Posted February 5 Posted February 5 I think that is normal. Same for me, fut fan should stop and if you measure the power on the outlet, you will see it is not drawing anything. I don't remember how it behaves on the Rock-5b. But I can power it on another day and check. 0 Quote
ozacas Posted February 6 Posted February 6 passively cooled for me, just the aluminium case. Hate fans 😁 No worries about the LED just wasnt what I expected would happen. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.