Posts by lrusak

Quote from vpeter

Seems I'm still the most knowledgeable man with i.MX6Q U-Boot

Want a cookie?

Why haven't you PR'd your changes yet?

Quote from by-gnome

I guess we can boot all iMX6 targets with one image using boot.scr

I tried this with Wandboard B1 and C1 and it works.

The script I used:

Code

setenv image "/KERNEL"
setenv bootargs "boot=UUID=2511-1511 disk=UUID=3a00fe1a-8c24-42fd-83ae-69c4a2043aa0 quiet console=ttymxc0,115200"
load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${image}
load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${fdtfile}
bootz ${kernel_addr_r} - ${fdt_addr_r}

No one wants to use boot.scr files. If it works for you, awesome, but it doesn't work for the LibreELEC project as a whole.

Quote from vpeter

Users don't need to set any dtb name because all magic is happening automatically in u-boot. U-boot for solidrun check the SoC type and sets one part of the dtb (imx6dl or imx6q). Then it also checks the SoM type (cubox, hummingboard, hummingboard2) and at the end also SoM revision (v15 or nothing). So same image runs on every device from solidrun without knowing what type it is and without setting dtb name. Same thing is happening on u-boot for Wandboard and Udoo. But there is probably just setting SoC type (at least this was true for Udoo when I add support for it).

But maybe mainline u-boot remove or broke all those things

So lrusak: you still think it doesn't matter how u-boot works?

I'm aware of this logic. The problem is that this is only the case for a few platforms within iMX6 u-boot. Other platforms don't operate like this and I would rather leave it generic than change it because of some boards on one platform. So the user has to flash the correct image the first time they install it. It's 50/50 anyways.

We also use extlinux and write the dtb filename to the extlinux.conf file at build time. This doesn't support specifying more than one dtb.

Quote from vpeter

chewitt, you should know that I had better idea years back because I actually know how u-boot works on this SoC. But no one listen. And now I don't care anymore (but it still hurts after all this time).

It doesn't really matter how u-boot works. It was done the way it was because it can be the same for all supported SOCs. Likely this can be improved now to combine a few similar boards but it works well the way it does.

Quote from smp

Vero and other Amlogic boxes default to YCbCr 4:4:4 (4:2:0 for 4K 50/60Hz).

In my build the Intel driver default to RGB full.

It is possible that your TV does not set the correct black level for RGB full.

I can compile a build that will output YCbCr instead of RGB and you can test if it will improve the PQ.

Edit: https://www.dropbox.com/s/w69p…5200150-YCbCr.img.gz?dl=1

Display More

You shouldn't force the colorspace, the Intel driver will select it itself. Is there a reason you are doing it?

Quote from grisu127

I have a Cubox i4 and wanted to test LE 9,8 nightly build.

On the download page I find two images:

-cubox-dl.img.gz

-cubox-q.img.gz

Which one to use? What ist the differnce between this two images? I Could't find any explanation.

Thanks

Display More

Do you have the cubox quad or the dual lite model?

I have two branches.

this one does require the ffmpeg patches Commits · lrusak/xbmc · GitHub

the ffmpeg patches Commits · lrusak/FFmpeg · GitHub

this one does not require the ffmpeg patches (but has only had limited testing and still requires libdrm in ffmpeg) Commits · lrusak/xbmc · GitHub

Quote from smp

Try this - https://www.dropbox.com/s/xdbw…80445-3325d42.img.gz?dl=1

Please make sure if you post builds you post your sources as well!

on a touch screen back is mapped to a long press

back on a touchscreen is just a long press

Could be to do with the fact that there is no default support for NV12 in mesa for etnaviv (last I checked it didn't merge).

I have a patch somewhere to enable YUYV output instead which etnaviv natively supports. This is the only other thing I can think of really.

Quote from rdorsch

lrusak Sorry my question was not how to get it to the storage or image, I do not know how to start it. Can I start it from the kodi UI? can I start it in an ssh session? do I need to write a systemd file and start it before kodi starts? Or something else?

rdorsch you will need to do it from ssh. You will need to stop kodi first

systemctl stop kodi

./kmscube -A -D /dev/dri/card0

or

./kmscube -A -D /dev/dri/card1

rdorsch just build the kmscube package and copy the binary to storage. You don't need to actually include it in the build

Buy a newer system. The NVIDIA GeForce 8300 isn't even supported by nvidia anymore.

EGL rendering is set in settings -> media playback -> video -> DRM prime render method.

And yes, you should be able to get nearly full speed 720p

You will need to use egl rendering for video playback but that will only work at about 15FPS. We cannot reliably do direct to plane rendering on imx6 because of restrictions with the planes.

check if WOL is enabled using ethtool

LibreELEC-Generic.x86_64-9.80-Milhouse-20200220230737-#0220-g85b21f7.tar

see: LibreELEC Testbuilds for x86_64 (Kodi 19.0)

Don't blame the device. It's just really new so you need a very recent version of the linux kernel and other packages to support it