Posts by jernej

Yeah, install2emmc warns you about erasing everything on eMMC. This effectively removes Android from it. I think there is a way to restore it via some tools and images you can download from Tanix site, but don't ask me how.

As you might notice, we don't care about Android Just power it down normally, remove SD card and power it up.

It actually sounds much like bug with LibreComputer Tritium H5 boards, where mmc initialization in SPL (I think) caused early lock up. But this was fixed with https://github.com/LibreELEC/Libr…s-to-20ms.patch so it shouldn't be the issue anymore with that or any other board. You can also try to use another brand or model of SD card, this is also alternative workaround.

Since I don't have that particular variant of TX6, I can only help you try to find the issue. But this is only possible if you're able to provide serial output. At present, I can't rule out SPL, ATF or Crust.

If you have a spare SD card, testing nightly image would be quicker and actually preferred. In short, we can't be sure what kind of modifications you did and thus what impact they have on the system.

rellla this PR should workaround the bug in ATF: https://github.com/LibreELEC/LibreELEC.tv/pull/6975 Please test it. I tested suspend/resume too and it works for me.

unmesh we don't provide repository.zachmorris. Please test with clean image, but before you do, note that there is a bug in boot procedure for Tanix TX6 mentioned above.

You can both wait on PR to be merged and use nightly image afterwards or build image yourself from aforementioned PR.

rellla you're correct, ATF v2.7 doesn't work on Tanix TX6. But that is upstream problem. I'll take a look what can be done.

No, not yet. Hopefully over the weekend.

No, it's not known. I'll test it on my board once I have time.

Due to historical reasons, DEVICE means SoC now, so DEVICE=R40. If you want to make image instead of just update tar file, you should also add UBOOT_SYSTEM=bananapi-m2u.

Note that Bananapi M2U is not really a good choice for media device. R40 doesn't support HEVC, doesn't have power management coprocessor, which means there is no stand-by implemented, and supports only HDMI 1.4. If you want relatively cheap, solid TV box, Tanix TX6 (Allwinner H6) or clones are good choice, at least when looking at Allwinner based devices.

On boards which don't come with IR remote, default IR wake up button is set to RC6 MCE (Windows Media Center remotes) power button, because these are most common. If you want to change that, you have to patch crust config file and rebuild the image (clean at least crust and u-boot packages).

I'm not sure what could be the reason with CEC - does it work for navigating menus? If so, how do you wake it up? It should wake up together with TV, but there will be several seconds delay before you'll see any image.

According to your error message, you're probably running out of memory. If so, you can increase swap partition (if you have it) or limit number of threads to build by prepending build command with something like THREADCOUNT=2. Of course you can experiment with the number of threads, 2 is given just for example.

Screen doesn't flicker for me at all with PAL. Switch to NTSC and see if that helps.

We don't add support wifi chips without mainline driver, even existing such out of tree are slowly removed. However, nothing prevents you to create your own custom image with such driver in it.

Current stable and nightly images doesn't support CVBS at all on H5. After a bit of fixing things around, following image has working CVBS on H5 when overlay is loaded: http://jernej.libreelec.tv/test/pc2-tve/L…gepi-pc2.img.gz

However, image is extremely unstable for me, but I can't figure out if this is somehow related to CVBS or not. Can you give it a try?

XR819 is planned to be supported by mainline kernel driver (no ETA), so it will be supported by LE too. You can try to use above driver by building your own custom image, but you'll hit usual obstacles with such drivers. This is exactly the reason why we decided against including out of tree (non-mainline) wifi kernel drivers.

which wifi is there? We don't support out of tree wifi drivers, which Armbian does.

There are differences in HW and because of that, it's not supported. LTS Wifi and ethernet aren't supported, and wifi won't be (no mainline driver). Bigger issue is PMIC configuration, which prevents boot. In any case, I don't have the board, so there won't be any support for this board unless someone steps in.

Do you have anything connected to HDMI? Anyway, best way for disabling HDMI would be over DT overlay. Do you know how to create one?