eraser215 - self build - joys of doing distribution maintenance.
grab the cubox image from here:
eraser215 - self build - joys of doing distribution maintenance.
grab the cubox image from here:
eraser215 i recently tested master on my cubox-i4pro - works
Hi adam.h.
Closed pull requests good to look at too.
- https://github.com/LibreELEC/LibreELEC.tv/pulls
In answer to your question.
Kodi - https://github.com/LibreELEC/LibreELEC.tv/pull/6291
Kernel - (in tomorrows nightly) https://github.com/LibreELEC/LibreELEC.tv/pull/6210
Intel stuff - https://github.com/LibreELEC/LibreELEC.tv/pull/6302
Mesa - https://github.com/LibreELEC/LibreELEC.tv/pull/6288
Nightlies does not have the wip HDR patches - if that is a consideration.
Otherwise nightlies are kept current with Intel+Mesa, with Kodi and Kernel regularly (no real rule around this - usually a draft kernel PR in place for the kernel)
You can check the history of both of these
You will be able to use modprobe once the .ko file is included in the modules directory - after the https://github.com/LibreELEC/LibreELEC.tv/pull/6312 request is added to the build. I believe that you will still need the “echo” during boot to enable the readings, via either systemd or autostart.sh
For the moment. Just use “insmod jc42.ko” (/storage is fine)
Compiled up:
build.LibreELEC-Generic.x86_64-10.0-devel/build/linux-5.10.76/drivers/hwmon/jc42.ko
Grab it from here.
If all works right… share the output and howto, and I’ll raise a PR for the module addition.
What version of LE10 are you running? Please confirm (ideally 10.0.2) and I will try an get a test jc42 for you.
nuc11:~ # uname -a
Linux nuc11 5.17.0-rc8 #1 SMP Fri Mar 18 09:21:50 UTC 2022 x86_64 GNU/Linux
nuc11:~ # cat /etc/release
Generic.x86_64-devel-20220318085355-518a13c
nuc11:~ # head .kodi/temp/kodi.log
Hi SandVP
A quick check here and jc42 is not adding to sensors on NUC11PAHi7
nuc11:~ # i2cdetect -l
i2c-0 i2c i915 gmbus dpa I2C adapter
i2c-1 i2c i915 gmbus dpb I2C adapter
i2c-2 i2c i915 gmbus dpc I2C adapter
i2c-3 i2c i915 gmbus tc1 I2C adapter
i2c-4 i2c i915 gmbus tc2 I2C adapter
i2c-5 i2c i915 gmbus tc3 I2C adapter
i2c-6 i2c i915 gmbus tc4 I2C adapter
i2c-7 i2c i915 gmbus tc5 I2C adapter
i2c-8 i2c i915 gmbus tc6 I2C adapter
i2c-9 i2c AUX USBC1/DDI TC1/PHY TC1 I2C adapter
i2c-10 i2c AUX USBC2/DDI TC2/PHY TC2 I2C adapter
i2c-11 i2c AUX USBC3/DDI TC3/PHY TC3 I2C adapter
i2c-12 i2c AUX USBC4/DDI TC4/PHY TC4 I2C adapter
i2c-13 i2c Synopsys DesignWare I2C adapter I2C adapter
i2c-14 smbus SMBus I801 adapter at efa0 SMBus adapter
nuc11:~ # i2cdetect -y 14
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 -- -- -- -- 35 UU UU -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- 4a 4b -- -- -- --
50: UU -- 52 -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
nuc11:~ # insmod http://LibreELEC.tv/build.LibreELEC-Generic.x86_64-11.0-devel/build/linux-5.17-rc8/drivers/hwmon/jc42.ko
nuc11:~ # sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +36.0°C (high = +100.0°C, crit = +100.0°C)
Core 0: +30.0°C (high = +100.0°C, crit = +100.0°C)
Core 1: +32.0°C (high = +100.0°C, crit = +100.0°C)
Core 2: +32.0°C (high = +100.0°C, crit = +100.0°C)
Core 3: +33.0°C (high = +100.0°C, crit = +100.0°C)
acpitz-acpi-0
Adapter: ACPI interface
temp1: -263.2°C
temp2: +37.0°C (crit = +119.0°C)
iwlwifi_1-virtual-0
Adapter: Virtual device
temp1: N/A
nvme-pci-0100
Adapter: PCI adapter
Composite: +32.9°C (low = -0.1°C, high = +69.8°C)
(crit = +84.8°C)
Correct. 5.12 at a minimum and really 5.15 for good function. There are also a lot of Intel patches in nighties over the last 12 months.
Hi Mettbrot I haven’t had an out of sync screen for a while now. I have connected the nuc11 via the AVR too. I am running my dev branch image - but nightly Generic is pretty similar for the purposes of the Intel packages.
Hi debarr Matrix was moved to Python3 - more info here - https://kodi.wiki/view/General_i…ion_to_Python_3
Hi succo - the nightlies use GBM (not x11) - you will need to use a (wl or x11) image - which has some nvidia support - this is not compiled as a nightly - so you will need to compile your own.
Looking at the R&D we have now undertaken - I think the sentence could be written something like:
using samba to serve files from kernel ntfs3 …… whereas using samba to serve files from ext4 ….. In earlier kernel versions …. using ntfs-3g, samba was able to serve files from the ntfs external drive … (without issue) …..
I’m not sure that we have validated anything else yet? What does
(or similar) show from a performance perspective? From each of the file system types?
Hi beredim - looks like it was added in 5.13-rc1 - https://lkml.org/lkml/2021/4/27/526
Any reason why you would want to run the PN50 with LE10 versus the nightlies? I know I had to run 5.12+ to get a good experience with the Intel TGL. Naming patch files is done via git-format-patch. And the numbering is not really formalised in the Linux patches - whilst the Kodi patches are “999.* - patches backported from upstream”? I’m probably not in favour of backporting that patch into the libreelec-10.0 branch as a patch. Was the patch backported in into the 5.10.x series? (Could be an option to bump the kernel to 5.10.x) From a testing perspective - any patch in default should,be tested against all of the other architectures.)
An alternative option for you could be to backport the couple of 5.15 commits from HEAD into your development branch and run with your community image. The planned release schedule of 10.0.x is definitely not fast and furious
At some stage there will be a kernel bump for Generic (but probably not till 10.2 and would probably be a backport of something from nightlies). But none planned for 10.0.x at this time.
mo123 as someone in the last 18 months who has learnt the ropes on what is required to maintain the packages for a distribution (and the occasional other bits and pieces) a challenging - but rewarding investment of time. As you you will have seen in my Kernel / u-boot PRs started out getting a build system together and the list of tests… then a lot of test / update. Even a patch into 5.17-rc6 to fix the Qualcomm build issue.. For packages spending time testing pre-releases, discussing, fixes to and testing upstream, so that we can use the released versions. For the RK - happy to test against RK3308, RK3399pro, RK3568, RK3388 - though only have the 3308 on my desk at the moment… might be an excuse to get the others back on my desk.
Can you believe that I have not yet been offered a Samba bugzilla account or got any feedback from them after 3 attempts?
Also, the Samba 4.16 inclusion in LE11 must have taken a back seat in favour of more pressing matters.
on my work list … not forgotten but kernel 5.16.11 and gcc / glib and binutils trumped it. ETA on 4.16 in nightlies would be mid/late march at this stage. Waiting till 4.13 goes EOL and I push the final 4.13 into LE11/LE10 - then can drop 4.16 in. There is still compile error (probably I need to update the patch - but only did the basics on the PR to get it unpacking and compiling as my WIP)
offbeat - message from the PR - so looking like the addons, etc.
==
crashes are skin related (estuary mod v2), I contacted author.
_Originally posted by @polojoe in https://github.com/LibreELEC/Libr…ent-1045970954_
Included in media-driver 22.2.1 now - https://github.com/LibreELEC/LibreELEC.tv/pull/6242