talraash

You don't need it now. And why you just don't use dd, base busybox utility, and any text editor to change dtb in uEnv.txt/extlinux.conf And if you talk about DT from stock adroid, it probably unusable with other kernel(mainline in armbian) without huge editing.

like with ssd most interesting param for us in sd it's random i/o speed. It can variable in one products line and it can be lower with time.

Just write image, change dtb x96-max-rmii and run box with reset button in av.

No... wired network work with dtb from 5.2.1

ok... in a few hours, then I will edit this post. upd Same behavior as before wired network work only with g12a-x96-max-rmii DT.

Yep... i have 2 different models with 100mb h96max2 and x96max in both case netwok work with meson-g12a-x96-max-rmii.dtb

Rewrite it. Use armbian as example. Write correct memory/bus addresses etc. You can find specific help in google just type "Device tree"

You can't use dtb from android as is...

lol... just compile from sources (RK legacy or mainline) u-boot and kernel and install/compile package what you want. or use image from rk topick)

@Gossamer Don't use " " (space) in folder path.

High performance soc with flat metal heat sink... what a genius R&D)

different ram clock maybe, or some other options in DT.

I finally “killed” my last tv box on s905x. How does s905x2 feel like in linux? According to synthetic tests, should the power of new soc be sufficient for sw video decoding up to 1080p? Does it make sense to pay a little extra and get boxes on the new soc?

It's just chromium fork with minor tweaks... Use instruction for chromium.

audio subsystem via rca don't work in mainline. Use hdmi audio or usb audio card.

Not always. If you break the u-boot being in nand there may be problems. If the u-boot in nand is broken, it was possible to restore the operation of the box only by closing the nand contacts and writing the correct u-boot or full image.

Is it necessary? Firefox work fine with multimedia, next build of chromium may also be fine. Chromium is very resource intensive at compile time(one build with compiliting time ~3 hours need 16 threads cpu ~ 32Gb ram and ~100 gb storage on ssd).

Not sure. Rather, the problem is in different compilation flags. Half a year ago, the situation was reversed, in favor of chromium. Looks like chromium use hardlocked gpu acceleration options and video decoding use sw opengl. I tested versions only from repositories, and it is not known who compilated them and how. Test video from balbes150 smooth. My own sample h264 720p and 1080p looks ok too. As before but now it work out of box(no need run video with flags --vo --sws-scaler manually)

Some curious observations. All test on latest 5.75 bionic desktop image screen resolution 1080p(generic s905x tv box)

I didn't try, but dpms may work... https://wiki.archlinux.org/index.php/Display_Power_Management_Signaling

@Reddwarf It's vpu job... https://dri.freedesktop.org/docs/drm/gpu/meson.html But without properly work v4lm2m, with software decoding we don't have hw scaling, and default scaling algorithm very heavy I mention early that if you play video which does not match with display resolution use --sws-scaler=fast-bilinear it give a huge performance boost P.S. Sorry for russian only, but that message was mainly for balbes150

(ver 5.44 =<) For mainline just use regular method via xorg parametrs, or if you use desktop standart xfce4 instrumments in settings.

I think the question is more correct to ask in the main branch of armbian. But H6 still has very basic support. http://linux-sunxi.org/Linux_mainlining_effort BSP kernel it's junk in most case) and not for end user.

You soc maximum 1.2GHz by amlogic blob...