Werner

split. tvboxes are unsupported, regardless of any similarity.

moved

Feel free to share them here. So anyone else who might run into this issue can find the solution.

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

He's alright, just facing other challenges in life at the moment. Had a chat with him recently.

As expected. Mainline Linux support for rk35xx soc family is still under heavy development. There is a good overview what should work and what does not:https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

Since we host these sources ourselves, you can directly pr against them:https://github.com/armbian/linux-rockchip

look around for topics mentioning h313 which seems to be the soc of your box. Btw. if you box is advertized having more than 2G of memory: congrats, you have been scammed. https://www.allwinnertech.com/uploads/pdf/2020040917181739.pdf

There is no ftp available. http/https only.

Exactly. Kernel support for this board might not be good enough (yet) or even might work just fine but if the hw doesn't cut it, it might be just a big waste of time.

How to get debug serial logs: https://debug.armbian.de

Ideally you'd provide debug serial logs so everyone can get an idea of what happens inside.

I don't think this will increase verbosity even higher. 7 is max https://www.kernel.org/doc/html/v6.12/admin-guide/kernel-parameters.html

moved Like most cheap sbcs this board does not have any kind of standard like uefi, therefore generic images will not work. Check images from here: https://github.com/armbian/community/releases/ Board is community supported, therefore its status is unknown to the Armbian team. Images may work, maybe not.

I'd start reading the existing script on how the first login works behind the scenes: https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-firstlogin

moved

Regressions happen all the time and not uncommon at all. Some get fixed upstream, some fix itself, some we have to find a fix. One of thousands of great ideas we'd love it implement but simply can't due to lack of (human) resources. This is why we highly appreciate community involvement.

I am not 100% certain but I think one of these images are installed (and upgraded) on my boards spi/nvme where I confirmed emmc working: http://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepi5-plus_noble_vendor_6.1.84_kde-neon-kisak_desktop.img.xz http://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepi5-plus_noble_vendor_6.1.99_kde-neon_desktop.img.xz

Hi, the manual way of enabling/disabling overlays is checking their availability in /boot/dtb/<family>/overlay and edit /boot/armbianEnv.txt. In your case it seems that a new overlays needs to be written. You can decompile an existing one that is similar using the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } dtc utility. Once you created a new dts file you can use code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } armbian-add-overlay <filename>.dts to compile and enable it. What exact values are necessary to achieve your particular case I don't know. I guess for that you have to dig through the datasheets of both your board and the SoC it is built around.

moved

I just put a random emmc module on my 5+ with vendor kernel and got detected as /dev/mmcblk0. So...cannot reproduce

I do.

vendor is just a name for one of our three main branches besides current and edge. The vendor name refers to the fact that this kernel is built from rockchip sdk sources (which is Linux 6.1.y but HEAVILY modified) with a bunch of our own patches on top. Though this branch is mainly for rk35xx devices. No idea how much work for rk32xx or rk33xx devices was made there.

Sometimes armbian-config is unreliable when adding overlays, therefore I suggested to check manually as well.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.