Igor

OK. Merged manually.

Don't know. Never tried.

TV support is built into the kernel. You need to enable it in FEX file. https://github.com/armbian/build/blob/master/config/kernel/linux-sun8i-default.config#L2798

Now this must work on a stable build.

There is no need to rebuild images. Upgrade, yes.

The main repository was updated to 5.60 at this moment.

https://docs.armbian.com/Process_Contribute/

There will be an update to 5.60 in a few hours. Then this will work OOB.

HD videos play out of the box. I never tried to play 4 at once ... Not sure if this will help, but you can experiment with adding cma=memory into /boot/armbianEnv.txt

No, this board is not officially supported and nobody cares about the situation. https://www.armbian.com/download/?device_support=No+official+support+(CSC) Technically it is per board property, defined here: https://github.com/armbian/build/blob/master/config/boards/renegade.conf#L10-L11

On modern kernel, a resolution is autodetected. Ubuntu and Debian share exact same kernel and u-boot which means there is no diff at this level.

Thanks! A side note. It works on 32bit systems only.

Lower your expectations. (modern) kernel for this board is still months away. Provided images are good only for testing, experimenting and development.

Perhaps this way? https://it-explain.com/orangepi-4g-iot-review-single-board-computer-for-iot-with-lte/ Untested.

Mine is dead for an unknown reason.

True. Will be fixed upon next upgrade which I am working virtually round the clock. In case you can wait, use nightly automated build. It should work and it should be safe on this board.

Console only.

Type dmesg and you will see times in front of boot log entries. Not the most proper way but you see if something is wrong right away. This is better. There is a delay in u-boot as well, especially if you have some USB devices which are scanned, there is some boot delay by a purpose that you can break booting and get into u-boot prompt. CPU. You mean in the log? ### mmc0:59b4 info: cid: 1b534d303030303010915c060100fa93 csd: 400e00325b590000775d7f800a4000a3 scr: 0235800300000000 date: 10/2015 name: 00000 type: SD preferred_erase_size: 4194304 fwrev: 0x0 hwrev: 0x1 oemid: 0x534d manfid: 0x00001b serial: 0x915c0601 uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=00000 MODALIAS=mmc:block erase_size: 512

I am running storage services and TVheadend and so far it never hanged. Now it's almost two weeks since the last kernel upgrades so I need to wait a little longer. Logs: http://ix.io/1mVr

Since I don't have the exact data for eMMC that is found on Lime (check here if there are any tests https://forum.armbian.com/topic/954-sd-card-performance/) I can't tell. Generally speaking, eMMC is way faster in small files and little faster in sequential r/w operations. And it's more reliable than SD cards. It's normal speed. You can compare your results to https://github.com/armbian/testings/blob/master/table.md. The fastest SD card used in those tests is A1 Samsung 32G.

Lime has it build on the board, on Banana you have to make one. We do. Providing support is usually possible only if we see logs and "armbianmonitor -u" is a collection of them. If you keep them for yourself don't expect any help or hints. http://ix.io/1kQc 16s http://ix.io/1lhu 7s

There is a problem at a kernel change, more precisely if/when initrd is regenerated. update-initramfs: Generating /boot/initrd.img-4.18.8-odroidc2 I: The initramfs will attempt to resume from /dev/zram4 I: (UUID=368b4521-07d1-43df-803d-159c60c5c833) I: Set the RESUME variable to override this. update-initramfs: Converting to u-boot format This leads to boot delay: Ideas on how to fix it best?

Nice idea, but until I am the only one maintaining whole data on the website, there is less than zero possibility for this kind of expansion. Maintainers. Maintainers. Maintainers. Then we can talk about.

It looks like SD card corruption on a quick look. By replacing the card? DEV channel is for experimenting only. It works on some boards, while it can be broken for others. Its extremely hard to keep stable builds supported, while for DEV there is absolutely no way to support. No time/people.

Only CLI images. We don't need the desktop for now. CLI_BETA_TARGET="bionic,stretch:dev"