offending code is within kodi
What about if you would show this code to make analysis easier? And if the code is in Kodi open issue there?
Posts by vpeter
-
-
racko, this adapter has one chip on it - can you read what is it?
-
this patch are for another kernel of linux I think.
Sure, but the idea was to support both versions at the same time - yours supports only b.
-
You could use this patch to support A and B variant at the same time: Bluetooth: btrtl: Add RTL8761B Bluetooth device · CoreELEC/[email protected] · GitHub
-
I dont know how
Add it to your command?
-
-
Ah, touch device restart is not something I think off.
-
You can took parts from here too if you want: Kernel NFS server by vpeter4 · Pull Request #250 · CoreELEC/CoreELEC · GitHub
-
What exactly is hardcoded? Because It should set correct device based on it's name with using evtest program.
-
There is an option in addon to update the driver itself from Sundtek.
-
So basically all the big words for last 2 years were way to much optimistic.
-
I wonder what "improvements" have been hacked into the latest Khadas bootloader.
Maybe related to this: init/Kconfig: increase INIT_ENV_ARG_LIMIT as otherwise maybe the limi… · CoreELEC/[email protected] · GitHub
-
Why haven't you PR'd your changes yet?
Because you refused the changes I proposed on Slack. And I don't bother doing same thing twice.
Want a cookie?
Yes please. Can I send you an address?
-
Because I was bored today I looked this issue just for fun. Like Gentoo Wiki link I posted.
After examining how U-Boot works with extlinux.conf I noticed that there is a tag named FDTDIR which specifies the directory where FDT files are located. The actual filename is set by U-Boot and allows booting similar devices from same image. The requirement is that all dtb files must be in some folder pointed by FDTDIR tag.
So there is no need to use 2 (or more) images and follows LE way of using modern extlinux.conf
Seems I'm still the most knowledgeable man with i.MX6Q U-Boot
CodeLABEL LibreELEC LINUX /KERNEL FDTDIR / APPEND boot=UUID=2812-4128 disk=UUID=0ed065e2-54e6-47ca-95e5-47a652053a43 quiet console=ttymxc0,115200 console=tty0Code
Display MoreU-Boot SPL 2020.10 (Dec 28 2020 - 09:41:54 +0100) WDT: Not found! Trying to boot from MMC1 U-Boot 2020.10 (Dec 28 2020 - 09:41:54 +0100) CPU: Freescale i.MX6Q rev1.2 1200 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 25C Reset cause: POR Board: MX6 Cubox-i DRAM: 2 GiB MMC: FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Card did not respond to voltage select! Net: Could not get PHY for FEC0: addr 0 No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 161 bytes read in 21 ms (6.8 KiB/s) 1: LibreELEC Retrieving file: /KERNEL 11815896 bytes read in 568 ms (19.8 MiB/s) append: boot=UUID=2812-4128 disk=UUID=0ed065e2-54e6-47ca-95e5-47a652053a43 quiet console=ttymxc0,115200 console=tty0 Retrieving file: /imx6q-cubox-i.dtb 37891 bytes read in 19 ms (1.9 MiB/s) ## Flattened Device Tree blob at 18000000 Booting using the fdt blob at 0x18000000 Loading Device Tree to 1fff3000, end 1ffff402 ... OK Starting kernel ... -
I can only think: OMG. You should just say "I don't know how to do this generic for ALL devices including iMX6". Because I really doubt that there are technical incapacity.
And why do you have to set dtb file anyway? Leave this to u-boot. Like this: Cubox-i - Gentoo Wiki I don't see file specified there.
Anyway, I just had to to point on a stupid thing taking years. And it seems situation will just be like that forever. Good job!
-
I'm interested to know what happens when users with a quad board don't change the dtb name and boot using the dual dtb? (or should the defaults be switched to quad?). Also, looking at the device-tree files in the kernel, didn't we (you) also used to ship an image for the Hummingboard devices?
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?
-
lrusak, you are still talking nonsense
And doesn't care for users to make theirs live easier. And this post is proof: user doesn't need to know if he have dual or quad soc in his device. At least for i.MX6.chewitt, sorry but my i.MX6 days are past (and ruined thanks to LE). And you seem to have expert just few posts above.
-
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).
