jock

@Seth the HDMI disappearing is quite disappointing, since I did not tweak that part in 5.18. Anyway this looks very suspicious to me: [ 2.099836] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes [ 2.100004] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes and maybe is somehow related to EDID or alike

don't know, all my bluetooth chips (AP6330, AP6334 and rtl8703bs) never had distance issues and never had to tweak anything, can stream audio 3 meters away without issues.

I think this is a great idea! Ideally having a repository for debian and/or ubuntu where latest development ffmpeg from LibreELEC repository is built and kept up-to-date would be a huge helper for multimedia advancement in armbian! Something already happens, for example, right now with oibaf repository: oibaf ppa provides latest development mesa packages for current ubuntu distros, thus immediately enabling latest features for both lima and panfrost drivers.

Armbian source code is there for your interest.

Multitool and armbian pristine images are configured to set the led to blink continously (it is useful to understand if the kernel is alive or freezed). Maybe you left an sdcard in the sd card slot with multitool/armbian image on it? Shorting the eMMC clock pin just makes the eMMC undetectable by SoC, so the SoC will continue with other boot options (ie: sdcard), and will go in maskrom mode only if there is not other valid boot option.

Since you did not say what software you installed, what board you have and neither gave any pictures to try recognize anything, I can just tell you to read the appropriate thread:

Probably you misconfigured something 🤷‍♂️

Yes, it can be possibile if the driver is somehow already in mainline kernel; I can't test it though. That's just firmware file missing for some kernel modules when the initramfs is going to be rebuilt. None to be really worried about.

yes, it looks like they are becoming a real problem. multitool was early meant for rk322x devices, which have smaller eMMC and usually the whole compressed backup fits in 4gb, but rk3318 have up to 64gb eMMC and things don't work anymore. Uart is 1.5Mbps, it should talk telling you what's wrong. If it does not give you anything at all you may try to connect a USB Male-to-Male cable to the OTG Usb port of the box and to a computer and see if lsusb shows a rockchip device in maskrom mode.

@Vittorio Mori well thanks for testing and wrapping the thing up, now I know that network boot works properly (it's far from being foregone when you have to deal with u-boot)

I have some old notes about compiling ffmpeg, kodi and mpv for mainline. ffmpeg and mpv worked out really well, kodi was bit of hit and miss. If you need a hand with that I may send you those things.

Glad to hear that you solved the issue; I will put this nvram in the armbian firmware repository as well, thanks!

@Gausus You'd better try a specialized memory benchmark application like mbw rather than involving the linux filesystem subsystem and dd to do such kind of benchmarks.

If you have the "upgrade image" (or whatever they call it), probably you may use the Android Tool for windows to restore the firmware. You can find the Android Tool in the rockchip github repositories (maybe rkbin-tools...) That image is not a plain image/dump , but rather made of segments that Android Tool can interpret and upload in the correct places. Sorry for the bad experience 😥

Yes, there is this "little" bug. Actually split could be useful, but I would like to solve the issue at the root and probably use an NTFS or exFAT partition rather than old FAT32 Also because splitting does not play well in the current command line (the last dd is to avoid write cache, I find it more reliable): (pv -n "/dev/$BLK_DEVICE" | pigz | dd of="$BACKUP_PATH" iflag=fullblock oflag=direct bs=512k 2>/dev/null)

@Seth good job! That's a pity and way strange HDMI does not work on 5.18 kernel; nothing actually changed there and there is no real reason for such wrong behaviour. The board is unknown to me, maybe whenever you can just post a dmesg of the mainline kernel; the original device tree or even the original firmware are pretty interesting to understand why the wifi chip (8934, that a new number...) is not detected.

Yes, you can. Actually the choice to remove any Android code from the board is a deliberate choice by me 😝 but has some performance and compatibility reasons, since this way the user is in control of the ddrbin, miniloadloader/SPL and trustos. The explanation is not exactly simple because these three pieces then cause unwanted behaviours, especially the proprietary trustos does not allow rk3318 to run above 1.1GHz. I guess rockchip put an artificial cap because the chip can run fine at 1.3GHz or even overclocked at 1.5GHz. A pro of the proprietary trustos is that it allows DDR frequency scaling, that is not allowed by the opensource trustos, but to overcome this I patched the ddrbin to use ram at 667MHz with great benefits in terms of multimedia and general performance. If you run stock Android you are forced to use the "stock" ddrbin at 300/333 MHz because the rockchip boot always happens from internal flash... so it's a chain of issues and to avoid all of these hassles I prefer to erase Android and start fresh. If you still want to go the "Android" mixed way, @hexdump wrote a document on his github on how to do, but I always forget the bookmark the link... That's still something that should be exclusive for the power user because that belong to the same class of those I explained above are around the corner.

Right! The same redirect can be done pointing to https://forum.armbian.com/topic/7141-csc-armbian-for-rk3288-tv-box-boards-q8/ , thanks!

@Voidbert At the moment, as @fabiobassasaid, there is some interest in expanding compatibility with eMCP boards and also investigating the R29 boards blank HDMI issue. If you open your box maybe you could take a look to which board you have. About the remote, there is no need for a kernel driver, just use the common ir-keytable utilities or lirc...

They are exactly the same, actually I noticed that I didn't upload the u-boot "edge" package but using the "current" u-boot is right the same since the difference is in the kernel package. Hopefully this mess about manual upgrades will end soon on next armbian release cycle or even before when new packages will be rebuilt! 😌

Actually I have no opposition on removing the page. Image links have already been removed, so there is no real reason to keep the page still there. There still are the installation instructions, but it is much better to keep them in one place and this thread is better. I can't do it by myself because I've been locked out by two-factor authentication plugin on wordpress website just now 😛 edit: maybe the page has not been removed for SEO reasons... we should ask @Werner if it is possible to put a 301 Redirect that send the user to the main armbian page or to this forum thread...

The blue led blinking is totally right: it means the kernel is alive and not freezed. multitool is also accessible via ssh via link-local fixed IP address and via DHCP obtained IP address. Of course if it is bootlooping you won't be able to do anything.

Network boot should be already enabled, but with the current setup it engages only when no other boot options lead to a successful boot; ie. when sdcard, internal flash and external USB don't provide a valid booting partition. I really never tried it, but should be brought on via regular PXE/DHCP, I guess a TFTP server is needed. You may try to force u-boot into network boot removing any partition from its sight; a serial adapter though is essential to debug.

I see this in armbian-hardware-optimization: armbian-hardware-optimization:369: echo "" >> /boot/armbianEnv.txt; sed -i '/^$/d;$G' /boot/armbianEnv.txt; sed -i '/^$/d;$G' /boot/armbianEnv.txt armbian-hardware-optimization:372: sed -i '/^$/d' /boot/armbianEnv.txt armbian-hardware-optimization:393: sed -i '/^usbstoragequirks/d' /boot/armbianEnv.txt armbian-hardware-optimization:394: echo "usbstoragequirks=${USBQUIRKS}" >>/boot/armbianEnv.txt And these others in armbian-firstrun: armbian-firstrun:72: # randomize mac in armbianEnv.txt armbian-firstrun:73: if [[ -f /boot/armbianEnv.txt ]]; then armbian-firstrun:75: sed -i "s/^ethaddr=.*/ethaddr=$MACADDR/" /boot/armbianEnv.txt armbian-firstrun:77: sed -i "s/^eth1addr=.*/eth1addr=$MACADDR/" /boot/armbianEnv.txt armbian-hardware-optimization has some other issues IMHO; there is a restoring/setting sound state which takes from 20 to 40 seconds on some of my systems slowing down the whole bootstrap and I'm not a big fan of the "big if switch" where all the optimizations for all the boards are grouped together, but those are other issues not to be discussed here. Anyway, touching armbianEnv.txt on every boot is very risky to me. That file is very important and some boards may not boot at all if it is misconfigured, even worse if corrupted.

@callegar Ok, finally I uploaded all the packages and refreshed images with 5.18.10 kernel. I didn't test them though, so be wise...