I've you've created LE images before you understand the build process. Just create a Generic-Legacy image so everything compiles normally and sources are downloaded. Then change the PKG_VERSION in packages/graphics/mesa/package.mk to reference the older release (set PKG_SHA256="" so it's not used) and respin the image. I'd expect mesa to simply rebuild with the older version as its compile/build process is stable (so probably hasn't changed). If that works, go test.
Posts by chewitt
-
-
Do I simply use the LibreELEC SD creator, select the img.gz file, write to the SD, then put into the device and boot? Or do I need to make changes after I have written the image?
Correct. No changes needed. All I can say is, current images boot/run/work here for me, and project stats (active installs) show that Odroid C2 boards are the most-used device with the AMLGX image. UART log showing early boot is the way forwards, as it will show exactly what is or isn't happening. NB: The same image boots from SD or eMMC.
-
No idea what's the issue, but leave it for a while until old add-ons are replaced by new ones and it will sort itself out. It somehow that doesn't work, run "systemctl stop kodi && rm -rf /storage/.kodi/addons/* && systemctl start kodi" to clear the binaries (but not the add-on configs and settings which are stored separately in /storage/.kodi/userdata/addon_data) then reinstall the add-ons again and you'll be up and running quickly. It's no more than a 5 mins job unless you over-think it.
-
CE have been trying to make 3D work properly for years (copying the same OSMC patches). If you're one of those people who thinks in code; good luck with the endeavour. If you're not (and people who show up here looking for patches usualy aren't) I'd skip ahead to the bit where you get a cheap RPi3 (not RPi4) and waste time watching movies instead
-
This image contains the patch from drm-tip (which was no issue to backport onto the LE kernel sources) and the channel allocation reorder patch that was suggested with RPi recently: https://chewitt.libreelec.tv/testing/LibreE…_64-12.80.0.tar
Let me know if the issue is resolved and/or whether the 4.0 > 5.1 workaround is required?
-
I plug power in, the red light turns on, no blue light, and after a few seconds the network jack lights start to blink.
That comment ^ suggests the board is booting, because network LEDs blink because code tells them to, not magic. If you add "ssh" to boot params in extlinux.conf it will force the SSH daemon to start, allowing you to login over the network with an Ethernet cable connected to see what's happening. If you add "video=HDMI-A-1:1920x1080M@60" to boot params it will force the kernel to output 1080@60 on the HDMI connector, in case there's something odd with HDMI cables and the monitor. It's not a cure-all for an HDMI issue, but you'll have a screen to look at, maybe. Perhaps connect to a proper TV instead of a monitor?
FWIW, I dug out my C2 board here and it boots fine using the image in my test share.
-
The mainline u-boot default boot method is extlinux.conf. Petitboot doesn't support extlinux.conf and HK devs have resisted the idea of adding support for some reason (more customers are forced to run BSP based images which keeps them inside the HK ecosystem perhaps?). Fortunately this dumbfcuk decision is easily solved by flicking the SPI boot switch to the right so Petitboot (which resides in SPI) is completely removed from the equation. Then LE boots fine from SD/USB and eMMC.
-
Those are the correct images (so u-boot is included). You cannot update from LE9.x using those files as the image name is not the same as the legacy one; and if you manually override/workaround that it will fail in later steps because I intentionally changed the boot filenames to force people into a clean install: to avoid the accumulated cruft from old installs, and prevent add-on issues that cause problems with the Python2 > Python3 change since Kodi 19.
See if https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz boots for you (it does for me). Please ensure the boot partition of the SD card is readable, i.e. prove you have correctly written the SD card and not just put the file on an SD card or direct-wrote the compressed image to the hardware (needs to be uncompressed). Do not rename files in the root folder of the SD card as done with some legacy images else it will break boot.
I don't have any links to UART guides: As a rule people with UART cables have figured out how to use them. If you have one? there's probably some instructions on the Hardkernel wiki.
-
There are no objections to it being submitted to the LE repo. The alternative will be to create an "argon40" repo for the add-on (ab)using GitHub free hosting and then have people install the add-on from that repo. The LE repo is easier for users since there's nothing extra to install, but an independent argon40 repo will probably be easier for the maintainer as fixes can be pushed on their own schedule. If there's any intent to support install on RaspiOS too, the independent repo is the right direction.
-
I added the GitBook app link to the wiki homepage: If you think there is documentation missing .. feel free to add it.
-
I've recently tested LE12 images booting from SD card and an eMMC module without problems. Are you using the "odroid-c2" image with upstream u-boot, or the "box" image? .. the latter has no u-boot so won't boot the board. If that's not the issue I'll need to see UART logs. NB: LE proactively disables the flashing blue LED activity indicator, but it will still flash at the start of boot until the disable script fires and stops it, which is usually around the time Kodi starts.
-
Would it affect importing/updating a large library or is that mostly network bound?
If you added content it makes negligible difference as most time is spent querying internet sources. If you didn't then it will complete faster as the small file read/write is improved. Overall, as said before, you're not missing anything.
-
Just write the LE image to the SSD and then power it on. The RPi firmware supports boot from nvme.
-
Follow https://wiki.libreelec.tv/configuration/…ration-advanced to configure any remote.
I don't have the code knowledge to implement a software-decode path for 10-bit H264, so given the general lack of development on the decoders it's rather unlikely to happen - although I will ask the Pi devs (who have done the work on ffmpeg side). IIRC the 10-bit H264 format is not supported in Amlogic silicon so software fallback is the only option (and hence the legacy images do that).
-
See https://github.com/chewitt/LibreE…a9db6d4f8041b46
Skip the first patch hunk with VERSION changes if on LE12 as I'm on LE13/master branch and GCC things are different. The rest should be the same as the kernels are currently the same in both branches.
You should be able to just respin the image to pick-up the changes.
-
I made a mistake and tried to upload Armbian to the internal memory. I don't see anything on TV at the moment. The uart connection reports a similar header as in this post.
You have erased (overwritten) u-boot on the internal storage. Android recovery files won't work as there is no u-boot to provide the recovery app, and imaging recovery.img to an SD card won't work as it contains u-boot for emmc, not u-boot for SD/USB.
Create a USB or SD from https://test.libreelec.tv/12.0/Amlogic/w…etek-hub.img.gz and see if the device boots to LE?
If yes, download this backup-file and transfer it to /storage over SSH, then run "emmctool w /storage/backup-hub.tar.gz" and it will expand and restore a raw emmc (dd) backup of the original Android OS to the box. You should then be able to boot the LE12 "box" image .. or have another go at ruining things with Armbian, as you like.
If the device boots but gets stuck at u-boot, you found the issue that resulted in "wetek-hub" (booting upstream u-boot) images being discontinued. The box sees noise on the UART and boots to console. If you have the UART connected you should be able to access the console and run the commands in here: https://github.com/LibreELEC/Libr…_autoscript.src (or one of the other bootscripts in that folder) to boot into LE. If using a USB stick you might need to run "usb start" first.
-
-
The maximum MTU size supported on RPi boards is 1500, hence the "Invalid argument" error.
See https://github.com/raspberrypi/linux/issues/5561 and https://github.com/raspberrypi/linux/pull/5534 and an earlier refused PR trying to add the same (not something I'd recommend trying) https://github.com/raspberrypi/linux/pull/5419.
It might be possible to get Jumbo frames with an external USB-C NIC, but I couldn't recommend one, and IMHO there's no real need for Jumbo frames on RPi hardware. RPi 0/1/2/3 are too slow to really benefit and RPi4/5 are already fast enough that the benefit will be negligible under real-world usage (the only real difference will be under un-real lab tests).
