Zameero "arm" is 64-bit kernel and 32-bit userspace for compatibilty with add-ons that need software widevine (DRM) support, and aarch64 is 64-bit kernel and 64-bit userspace which means no widevine support (as only 32-bit libs are sourceable). Also, mainline Linux will report the actual RAM installed, not what u-boot reports, and while you could hardware-hack fake values I doubt most box vendors are that clever. I also doubt it's imposssible to replace u-boot as I haven't seen truly locked bootloaders yet, only ones with more complex/customised boot environments. You cannot "replace emmc with nand" on boxes, but you can replace the bootloader - if - you have the fip sources for the box; the fip sources are semi-standardised around Amlogic reference devices but cheap box vendors frequently deviate from the reference design with slower/lower spec memory and then you need the files specific to that box to compile a replacement bootloader. This is one reason why we have subzero interest in fiddling with u-boot for box devices where 99.999% of the time we don't have (and won't ever get) the fip sources.
miwenka Userspace manual tweaking of kernel drivers is not needed (and thus that stuff doesn't exist) in mainline. If you connect to a not-YUV-capable screen, e.g. RGB-only monitor, the DRM driver outputs RGB. So what's the actual problem you have?
phlp11 no idea what the issue is, but I will push a bump to Linux 5.7-rc kernels later in the week and this may improve things .. or not. LE master branch is some way behind my own branches now, it needs to catch up a little.