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?
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?
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.
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.
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.
Display MoreVero 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
You shouldn't force the colorspace, the Intel driver will select it itself. Is there a reason you are doing it?
Display MoreI 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
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
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.
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