Hello everybody,
I see no Amlogic builds in
https://test.libreelec.tv/12.0/
Does LE12 not build on Amlogic or is it just a build time issue and building it locally on my machine should work fine?
Thanks
Rainer
Hello everybody,
I see no Amlogic builds in
https://test.libreelec.tv/12.0/
Does LE12 not build on Amlogic or is it just a build time issue and building it locally on my machine should work fine?
Thanks
Rainer
I'm on hiatus at the moment (new job, and building up to an Ironman triathlon) and nobody created the Linux 6.2/6.3/6.4 kernel source to use with AMLGX. Until that happens, ye olde 6.1 kernel conflicts with other patches in the LE tree so builds fail and things are disabled. I have no plan to resume kernel poking until the status of the hardware decoders changes. There is allegedly someone now working on the drivers again, but no code has been shared yet, so I'm keeping myself busy doing fun things.
Thanks for your reply and enjoy the Ironman triathlon
I am most interested in the wifi updates mentioned here
Will they also be added to LE11 eventually? Or is it more likely to see Amlogic in LE12 again?
I've asked that connman/iwd are bumped for LE 11.0.2. There's no guarantee that this resolves issues, but it's likely to improve the status of things for someone somewhere.
Would
and
be enough to apply on LE11?
And
PROJECT=Amlogic DEVICE=AMLGX ARCH=aarch64 UBOOT_SYSTEM=box make image
the right build command?
I just saw the list of kernel patches for Amlogic. The three digits list is very impressive. That a significant part contains FROMGIT-6.2 or FROMGIT-6.3 gives some hope, that eventually that gets more managable. But there are still many patches remaining. Thanks for all the effort you put into extending the life these devices.
The connman/iwd changes are already merged into LE11 branch. NB: I'm not sure what advantage you're expecting with aarch64, but it's not going to noticeably improve anything and you will have to reinstall or remove binary add-ons) as they are not aarch64 compatible; and there will be no replacement binary add-ons in the repo as there are no ARM aarch64 releases for LE11 so the add-ons weren't built/don't exist.
The kernel patchset is ridiculously large but will reduce if I ever find the enthusiasm to rebase it on a newer kernel. I have no plans to do that in the near-term future though.
[...] NB: I'm not sure what advantage you're expecting with aarch64, but it's not going to noticeably improve anything and you will have to reinstall or remove binary add-ons) as they are not aarch64 compatible; and there will be no replacement binary add-ons in the repo as there are no ARM aarch64 releases for LE11 so the add-ons weren't built/don't exist. [...]
I was not sure what the right architecture is and I found quite a few references to aarch64, therefore I build for aarch64. I saw no obvious glitches or issues with it in my very basic tests. But honestly they were limited to the wifi invalid-key issue, I did not even attempt to play any content.
Do I understand you correctly that ARCH=arm is used for the nightly builds and the LE11 releases?
The kernel patchset is ridiculously large but will reduce if I ever find the enthusiasm to rebase it on a newer kernel. I have no plans to do that in the near-term future though.
I think that after you completed the Ironman your enthusiasm for everything will dramatically increase even further
NB: I'm not sure what advantage you're expecting with aarch64, but it's not going to noticeably improve anything and you will have to reinstall or remove binary add-ons) as they are not aarch64 compatible; and there will be no replacement binary add-ons in the repo as there are no ARM aarch64 releases for LE11 so the add-ons weren't built/don't exist.
Hi, is this the same situation for RPI4 12 nightly builds? Are all add-ons binary? I say this because I'm running nightly aswell and add-ons work.
In the past I've run nightly builds for android-tv from kodi repos without problems for basic add-ons.
I'm waiting for next nightly build, which bumps from 6.1 to 6.4 kernel, yay! I'm expecting improvements on kernel video drivers' hardware acceleration.
Do most 12/omega add-ons/plug-ins come natively on 64-bits now?
I heard 12 switches to 64-bits.
BTW, why do nightly builds occasionally take longer hiatus, such as now, 6 days and no build? (Sorry for the question, didn't want to push)
RPi will be a little different from Amlogic (as the codebase is different) but improvements in performance will still be incremental not a huge leap forwards. LE12 will run all 64-bit ARM hardware with 64-bit userspace; including all binary add-ons available at the time. And nightlies are only built when there are new changes to build, and only uploaded if the build is successful, and when the server didn't fill it's disks again (none are guaranteed).
Wow, Amlogic builds are back in LE12. Many thanks.
Boots fine, dmesg output is here
https://bokomoko.de/~rd/Libreelec/2023-08-01-wetek-play-2-dmesg.out
I noticed that it does not see my wlan AP on channel 1. Switching the AP to channel 6 makes the network visible.
In the dmesg output I find
[ 10.369177] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
Can anybody tell if that has something todo with the wifi channels?
[ 10.369177] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
The broadcom driver supports loading a board/implementation-specific (not chipset-specific) tuning firmware (clm_blob) but very few boards have them and thus there is no blob to load in our image and the driver reports this. It should really be a warning not an error, but ISTR the driver uses the generic kernel firmware loading helpers so it's not possible to alter how that's reported without impacting the reporting of all kernel firmware loading which would not be desirable. In short, it's harmless. You might need to configure the wireless regdomain in the LE settings add-on for all channels to be available.
Many thanks for the explanation.
I already configured the wireless regdomain in the LE settings add-on, but channel 1 did not work.
Now I just booted the system again, confirmed that the wireless regdomain is set and I saw channel 1 w/o any issues.
Wetek:~ # iw dev wlan0 scan
BSS c8:d3:a3:5e:9d:48(on wlan0)
last seen: 967.449s [boottime]
TSF: 0 usec (0d, 00:00:00)
freq: 2412
beacon interval: 100 TUs
capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
signal: -68.00 dBm
last seen: 0 ms ago
SSID: DLAN
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
DS Parameter set: channel 1
TIM: DTIM Count 1 DTIM Period 2 Bitmap Control 0x0 Bitmap[0] 0x0
ERP: <no flags>
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK FT/PSK
* Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
BSS Load:
* station count: 4
* channel utilisation: 24/255
* available admission capacity: 0 [*32us]
Supported operating classes:
* current operating class: 81
HT capabilities:
Capabilities: 0x116e
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
RX STBC 1-stream
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-7
HT operation:
* primary channel: 1
* secondary channel offset: no secondary
* STA channel width: 20 MHz
* RIFS: 0
* HT protection: no
* non-GF present: 1
* OBSS non-GF present: 0
* dual beacon: 0
* dual CTS protection: 0
* STBC beacon: 0
* L-SIG TXOP Prot: 0
* PCO active: 0
* PCO phase: 0
Extended capabilities:
* Extended Channel Switching
* QoS Map
* UTF-8 SSID
* Operating Mode Notification
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
Wetek:~ #
Display More
I still experience the invalid-key issue reported in https://github.com/LibreELEC/LibreELEC.tv/issues/7166 though.