Active threads

It was a network problem. Problem fixed after global activation of a clash proxy. Thanks a lot!

Starting kernel ... [ 11.131621] Kernel panic - not syncing: panic_on_set_idle set ... [ 11.132177] CPU: 1 PID: 47 Comm: kworker/u8:3 Not tainted 6.1.115-vendor-rk35xx #1 [ 11.132851] Hardware name: PinusCore RK3562 (DT) [ 11.133272] Workqueue: events_unbound async_run_entry_fn [ 11.133760] Call trace: [ 11.133986] dump_backtrace+0xe8/0x124 [ 11.134332] show_stack+0x20/0x30 [ 11.134641] dump_stack_lvl+0x6c/0x88 [ 11.134975] dump_stack+0x18/0x34 [ 11.135283] panic+0x138/0x310 [ 11.135573] rockchip_pmu_set_idle_request+0x114/0x1d8 [ 11.136043] rockchip_pd_power+0x424/0x480 [ 11.136419] rockchip_pd_power_on+0x24/0x38 [ 11.136798] _genpd_power_on+0xbc/0x150 [ 11.137154] genpd_power_on+0x5c/0x14c [ 11.137500] __genpd_dev_pm_attach+0x1ac/0x280 [ 11.137903] genpd_dev_pm_attach+0x68/0x6c [ 11.138281] dev_pm_domain_attach+0x20/0x3c [ 11.138660] platform_probe+0x58/0xc0 [ 11.138992] really_probe+0x1cc/0x390 [ 11.139326] __driver_probe_device+0x140/0x158 [ 11.139729] driver_probe_device+0x44/0x100 [ 11.140108] __device_attach_driver+0x110/0x124 [ 11.140520] bus_for_each_drv+0xa8/0xd4 [ 11.140876] __device_attach_async_helper+0x7c/0xf8 [ 11.141322] async_run_entry_fn+0x6c/0x14c [ 11.141698] process_one_work+0x1b8/0x268 [ 11.142065] worker_thread+0x1e8/0x254 [ 11.142409] kthread+0xc0/0xd0 [ 11.142697] ret_from_fork+0x10/0x20 [ 11.143029] SMP: stopping secondary CPUs [ 11.143382] CPU2: stopping [ 11.143382] CPU3: stopping [ 3382] CPU0: stopping [ 11.143385] CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.1.115-vendor-rk35xx #1 [ 11.143390] Hardware name: PinusCore RK3562 (DT) [ 11.143393] Workqueue: events_unbound deferred_probe_work_func [ 11.143401] Call trace: [ 11.143402] dump_backtrace+0xe8/0x124 [ 11.143408] show_stack+0x20/0x30 [ 11.143413] dump_stack_lvl+0x6c/0x88 [ 11.143418] dump_stack+0x18/0x34 [ 11.143423] local_cpu_stop+0x4c/0x6c [ 11.143428] ipi_handler+0xe0/0x1d0 [ 11.143433] handle_percpu_devid_irq+0x70/0x128 [ 11.143441] harq+0x24/0x30 [ 11.143450] gic_handle_irq+0x8c/0xa8 [ 11.143455] call_on_irq_stack+0x24/0x4c [ 11.143460] do_interrupt_handler+0x78/0xc4 [ 11.143467] el1_interrupt+0x90/0xa0 [ 11.143472] el1h_64_irq_handler+0x18/0x24 [ 11.143478] el1h_64_irq+0x74/0x78 [ 11.143483] rcu_all_qs+0x1c/0x84 [ 11.143489] __cond_resched+0x54/0x5c [ 11.143495] rockchip_dmcfreq_opp_set_rate+0x2a0/0x46c [ 11.143502] rockchip_dmcx1c8 [ 11.143513] devfreq_update_target+0x98/0xd8 [ 11.143517] update_devfreq+0x1c/0x28 [ 11.143521] rockchip_dmcfreq_system_status_notifier+0x1c4/0x200 [ 11.143527] notifier_call_chain+0x74/0x94 [ 11.143534] blocking_notifier_call_chain+0x4c/0x78 [ 11.143541] rockchip_system_status_notifier_call_chain.isra.0+0x28/0x34 [ 11.143547] rockchip_set_system_status+0x68/0xc4 [ 11.143552] rockchip_dmcfreq_probe+0xe34/0xe6c [ 11.143557] platform_probe+0x70/0xc0 [ 11.143562] really_probe+0x1cc/0x390 [ 11.143568] __driver_probe_device+0x140/0x158 [ 11.143575] driver_probe_device+0x44/0x100 11.143581] __device_attach_driver+0x110/0x124 [ 11.143588] bus_for_each_drv+0xa8/0xd4 [ 11.143593] __device_attach+0xf0/0x174 [ 11.143600] device_initial_probe+0x1c/0x28 [ 11.143606] bus_probe_device+0x38/0x9c [ 11.143612] deferred_probe_work_func+0xd8/0xec [ 11.143618] process_one_work [ 11.143631] worker_thread+0x1fc/0x254 [ 11.143636] kthread+0xc0/0xd0 [ 11.143642] ret_from_fork+0x10/0x20 [ 11.143647] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.115-vendor-rk35xx #1 [ 11.143652] Hardware name: PinusCore RK3562 () [ 11.143655] Call trace: [ 11.143656] dump_backtrace+0xe8/0x124 [ 11.143663] show_stack+0x20/0x30 [ 11.143667] dump_stack_lvl+0x6c/0x88 [ 11.143672] dump_stack+0x18/0x34 [ 11.143677] local_cpu_stop+0x4c/0x6c [ 11.143681] ipi_handler+0xe0/0x1d0 [ 11.143686] handle_percpu_devid_irq+0x70/0x128 [ 11.143692] handle_irq_desc+0x28/0x40 [ 11.143697] generic_handle_domain_irq+0x24/0x30 [ 11.143702] gix4c [ 11.143711] do_interrupt_handler+0x78/0xc4 [ 11.143717] el1_interrupt+0x90/0xa0 [ 11.143723] el1h_64_irq_handler+0x18/0x24 [ 11.143728] el1h_64_irq+0x74/0x78 [ 11.143732] arch_local_irq_enable+0xc/0x28 [ 11.143739] cpuidle_enter+0x40/0x58 [ 11.143744] do_idle+0x21c/0x240 [ 11.143749] cpu_startup_entry+0x3c/0x40 [ 11.143754] kernel_init+0x0/0x138 [ 11.143760] arch_post_acpi_subsys_init+0x0/0x28 [ 11.143768] start_kernel+0x710/0x754 [ 11.143774] __primary_switched+0xbc/0xc4 [ 11.143782] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.1.115-vendor-rk35xx #1 [ 11.143787] Hardware name: PinusCore RK3562 (DT) [ 11.143790] Call trace: [ 11.143791] dump_backtrace+0xe8/0x124 [ 11.143797] show_stack+0x20/0x30 [ 11.143802] dump_stack_lvl+0x6c/0x88 [ 11.143807] dump_stack+0x18/0x34 [ 11.143812] local_cpu_stop+0x4c/0x6c [ 11.143816] ipi_handler+0xe0/0x1d0 [ 11.143820] handle_percpu_devid_irq+0x70/0x128 [ 11.143827] handle_irq_desc+0x28/0x40 [ 11.143831] generic_handle_domain_irq+0x24/0x30 [ 11.143836] gic_handle_irq+0x8c/0xa8 [ 11.143840] call_on_irq_stack+0x24/0x4c [ 11.143845] do_interrupt_handler+0x78/0xc4 [ 11.143851] el1_interrupt+0x90/0xa0 [ 11.143856] el1h_64_irq_handler+0x18/0x24 [ 11.143862] el128 [ 11.143872] cpuidle_enter+0x40/0x58 [ 11.143877] do_idle+0x21c/0x240 [ 11.143881] cpu_startup_entry+0x3c/0x40 [ 11.143885] secondary_start_kernel+0x190/0x198 [ 11.143890] __secondary_switched+0xb0/0xb4 I am trying to port Armbian to a custom RK3562 development board. I have applied some patches in the kernel and U-Boot to support RK3562, but the system experiences a kernel crash during boot, with error logs as described above. I have already tried using the device tree file from the Toybrick RK3562 development board, but the problem persists. Can anyone please suggest where the problem might be? I am willing to provide any additional information to assist with troubleshooting. pinuscore-rk3562.dts pinuscore-rk3562.dtsi

I think that is to be expected and working as designed (assuming I understand you correctly). At least I experience the same from my regular Intel-based laptop. When it is merely screen-blanking I can get back in via a keyboard press or mouse movement. But when the system is properly suspended a press of the power key is required. Back in the day, I had a PS/2-keyboard from Siemens Nixdorf that had a power button integrated. That one was able to wake up the attached machine. It worked like a power button on the computer itself. Similar to the one you see above. The power button is the one above the numpad, next to the Siemens logo. If I am not mistaken, mine was also labeled with a power symbol while the one I found on the net is blank. Maybe somebody still makes keyboards with such a button, I don't know. I agree it would be useful. Maybe you can use wake-on lan to achieve a similar result and wake up your machine from your phone or even repurpose one of those Internet-enabled Amazon dash buttons. Heck, come to think of it, I should really go ahead and do that myself. My power button is in an inconvenient place and I still have a couple of those dash buttons that I meant to use for IoT but never did. Edit: Looks like I am mistaken and it should be possible to wake up from suspend via USB. I'd love to learn how to enable that myself.

check the logs. /var/log, ~/.Xsession-errors, etc.

Armbian is Debian or Ubuntu with focus into hardware support. https://docs.armbian.com/#what-is-armbian Many operating systems in this segment are derived or use Armbian kernel (development & support) maintained by our team and surrounding community. I do agree with your findings, but this is expected in this world. Achieving and keeping full functionality on custom hardware is hard without substantiation investments or big enough crowd of volunteers / random people that knows special stuff. Both is limited. ALSA is a complex part of engineering that I only understand to some small degree. For most people, including me - is hard to comment. I hope your findings are valuable for someone that knows where to look. Isn't always like this? Sadly, in most cases, problems are solved by investing time for research - code / structure complexity is often extreme, also for people that live source code. Welcome to Armbian forum!

Sorry to bump an old thread. I am having the exact same issue here with that predefined build. I tried building moonlight-qt from source after installing ffmpeg-rockchip, I still cant get hardware decoding working... I am on a pure Wayland setup. Anyone have any tips to get this to work? What needs to be changed in the qt.pro files?

What does the following command show? sudo fdtoverlay -v -i /sys/firmware/fdt -o /dev/null /path/to/your_overlay.dtbo panel-simple-dsi ... Expected bpc in {6,8} but got: 0 So possibly the default with the older kernel was by accident correct and now you should define it. And it seems that you use an overlay meant for the 5a on a 5c?

Can you try if any of the H3 images from libre-elec would get you video acceleration? https://libreelec.tv/downloads/allwinner/ i once tried the orange pi pc image in my orange pi zero lts (h3) and it worked

hello "I need the MiniLoaderAll.bin for RK229Q-221P-V1.3 (2020.10.10). do you have it

That issue was just dealt with by disabling cruft instead. If you want to test a newer uboot with a reenabled cruft you will again need to go into building and testing, followed by a PR.

@Nick A 👍

@laibsch It seems that if you set the pixel clock or refresh rate too high that you can shorten its lifespan. But when you use extreme values and the display doesn't have any protection in rare cases you can even damage it. A bigger chance is driver instability or a distorted display.

close investigation it seems to use grub, not bootp, card written does not show any activity of green led even after 10 minutes from powerup. Do you have some of the magic twanger needed to boot a pi? Thank you, gene1934

adding COMPRESS_OUTPUTIMAGE to your call will compress your image. $ ./compile.sh build BOARD=rockpi-s BRANCH=current BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=trixie COMPRESS_OUTPUTIMAGE=xz [...] $ ls -lh output/images/*.xz -rw-rw-r-- 1 user root 342M Aug 15 01:03 output/images/Armbian-unofficial_25.11.0-trunk_Rockpi-s_trixie_current_6.12.41_minimal.img.xz

Bookworm is going to remain as an armbian-build option, right?

@mdidis do non secure boot images show any output. The one posted is an android uboot output.

It seems to me that Gnome is installed by tasksel because you didnt deselect it. I mean that gnome is selected by default.

I tried this patch https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3/blob/main/patches/1.5GB_OPZ3_fix.patch , ported to your u-boot (hardcoded 1.5gb), same result. Will try warpme or that sicxnull build, still wondering if I am on a red herring, I'll keep poking around and testing stuff. I'll post as I find things that work/don't work, hopefully this will help someone else too. And no worries, I'm sure your busy. You've helped a lot and helped me get a foundation. Thank you 💯 Log for notes:

Do you perhaps know how we could integrate this into Armbian? I don't know much about Gnome internals - came this far: https://github.com/armbian/build/blob/main/config/desktop/common/environments/gnome/debian/postinst

I was thinking the same. Must soldering the TTY cosolle so can getting the Uboot messages. The eMMC is the flash dead and have one Armbian on the SD-Card for jump starting the USB-SSD but the device used is only the USB-SDD i the demesg and it shall writing other devices if not booting one the USB-SSD and its the right one then HA is current and on the SD-Card is not updated. Shall i rewriting the bootloader on the USB-SSD but it shall being updated for some mouths ago ?

I second btrfs. I second-guess running bittorrent off SD cards.

@dale there’s a new patch to fix boards without external 32k clock. I haven’t tested it yet. https://github.com/warpme/minimyth2/commit/728a14a73924e349fe88fb4def7e5f50a79aed5c

I'm not sure what you're asking. I'm requesting information because I am seeing information stating that there is a working linux kernel that exists, but I don't know how to bridge that into a form where that kernel could be built or compiled into an image. Can what is on that github page be input into the build process? I've looked at what it takes to build Armbian from source and I understand the instructions when the board being built fits the categories in the instructions, but I'm not sure if that github kernel is useable or can be applied in that buidl process.

I see that the reported problem was raised in another topic:

There is certainly nothing planned. In general most of the open source community has moved away from working on amlogic based devices as the support from amlogic if lacking (and given the arm cpu space where all arm cpu vendors don't really support main line linux very much, amlogic is significantly even less supportive). So these days around armbian in particular most developers choose to invest there volunteer time in Rockchip cpus (and more recently some in allwinner cpus). But this is open source and community driven. So anyone is welcome to pitch in and do the heavy lifting to support it if they want. That is how most boards get support, is that someone with an interest volunteers to do the work.