It's not a Kodi debug log (or crash log) so it doesn't show anything interesting. Clean-boot with debug on and reproduce the issue.
Posts by chewitt
-
-
What kind of USB devices? .. and what LE version?
-
Share the UART output from the failed boots.
-
In my case once the UART pins were resoldered I don't see noise and it boots without getting stuck (the other user forced a pin to 3.3v which had a positive effect). So I didn't need to short eMMC pins on the Hub (but have done that on Play2 and some other boxes before).
There are two more options I can think of:
a) https://github.com/superna9999/li…DMI-Boot-Dongle <= but this requires hardware you don't have (and a little $) and will take a while to arrive if in-stock or you have to order parts from China to self-build.
b) I forget the commands, but it's possible to enter the u-boot console, select the emmc device:partition and then erase a block range on the device to remove u-boot. Once that's done the boot-rom will fail to find u-boot on eMMC and boot the LE board image from an SD card (from where you can dd the factory image).
-
Moved to the RK section
-
The FLIRC case is a great case, and does look/feel fab.
-
Arghh.. I always forget that late model versions run newer silicon. My bad
-
RPi0/1/2/3 are 32-bit SoCs so all past/present/future releases are 32-bit kernel and 32-bit userspace. RPi4/400 are 64-bit SoCs and <= LE 11.x are 64-bit kernel with 32-bit userspace. LE 12.x will use 64-bit kernel and 64-bit userspace. The same is true for other ARM SoC vendors where we have historically and/or still do support a mix of 32-bit and 64-bit SoC hardware. Generic LibreELEC releases have always been 64-bit (OpenELEC dropped i386 support @ after v5.0).
Over time the number of people confused/offended by our lack of publishing specific information on kernel vs. userspace arch is remarkably small, so I wouldn't over think the number of references that need to be made.
-
Amlogic hardware is hardcoded (in silicon) to search for bootable firmware on eMMC, so unless eMMC is erased or electrically disabled to prevent u-boot from being found; the boot rom finds it and runs it. The toopick method applies to vendor u-boot, the (Android) recovery mode scripts are not implemented in upstream u-boot.
I fixed this on my own board by resoldering dry joints on the UART connector. Another user shorted a pin. It's also possible to short eMMC pins to disable it allowing SD boot to the box image and then restore the factory image. I totally understand that not everyone would be comfortable with those options, but from a pure "is it recoverable or not?" perspective, it's recoverable.
-
1) PT works here on HDMI but I didn't test S/PDIF in about 4 years (extracting the AVR to cable it is complicated) so that might be different.
3) Read the big fat warning on AMLGX in public release notes
4) Read the big fat warning on AMLGX in public release notes
5) It's unusual but happens occasionally.. easily recovered from
6) Already explained in the other thread (boot from SD card so emmc is not in-use and run "emmctool w /path/to/dd-backup.tar.gz" to write the dd backup of the factory image back to emmc).
As written in the release notes, AMLGX will not be great for all users. If it works for you that's great. If it doesn't work for you (and it appears that way) then you should have low expectations of any major development work to improve it. I'd like to do more but my coding skills are limited and most of the long-known problems require the attentions of people who write kernel driver code.
-
I don't see a specific board image for that iteration of RockPi so you'll probably need to frankenstein or self-build something.
-
You should think about using an external USB SSD instead of the SD card.
I don't find an SD card slow (with an above average sized media library) or unreliable, and the less stuff dangled off cables the better IMHO.
-
Feel free to submit changes on GitHub .. it's open source like the rest of our codebase.
GitHub - LibreELEC/documentation: The LibreELEC wiki on GitBooks https://libreelec.wikiThe LibreELEC wiki on GitBooks https://libreelec.wiki - GitHub - LibreELEC/documentation: The LibreELEC wiki on GitBooks https://libreelec.wikigithub.com -
IIRC the "toothpick" method should drop you into an Android restore GUI, but I'm fuzzy about it since it's years since I used it.
-
NB: If you install the board image you are overwriting vendor u-boot with vanilla upstream u-boot; which a) has no "hold the power key to switch OS" mode, and b) there is now a single OS installed so nothing to switch between anyway. If you want that functionality you need to use the "box" image and configure it for the WP2 (or Hub, as appropriate) so that you retain vendor u-boot.
https://www.dropbox.com/s/tw6bg3kipc8t…wp2.img.gz?dl=0 <= dd backup of the WP2 factory image
-
Code
touch /storage/.please_resize_me && reboot^ this also works, but note that it's a destructive resize (the /storage partition is removed and recreated)
-
One more question. S905X4 – Is there TBS support? It's clear to me that it's a little different hardware than with and so on.
There is some early/basic activity to upstream core board support for S905X4, but I'd guess another year before there's a useable usptream kernel for devices (and longer before LE support). Your only option will be the vendor kernel, or maybe CE but no ideas whether TBS HW can be supported on their codebase (and this is the wrong forum for that Q).
-
The last kernel patchset I personally tested was merged for 11.0.1 so I can't speak for what issues may have been introduced with bumps others have done to newer kernels for 11.0.3 .. but historically the only issue I've seen on a Hub that caused boot issues is the UART noise problem I've flagged above (which the logs shared seem to point to). I'm not sure why newer u-boot is super-sensitive on the serial line or if anything can be done in u-boot device-tree to workaround that (my u-boot knowledge isn't awesome). I did previously experiment with a tweaked u-boot that basically disables the UART keyboard and (as expected) this sidesteps the problem. That proved the theory; but as the u-boot sources we build from are used with all AMLGX boards it's not possible to patch only the Hub at bulk-compile time.
The following may be useful:
https://www.dropbox.com/s/7wi5vhrgqsle6ug/dtb.img?dl=0 <= ^ these three can be copied to a FAT formatted SD to use with vendor u-boot recovery mode to restore the original factory image.
https://www.dropbox.com/s/v46jogn3rk4i…hub.tar.gz?dl=0 <= this is a dd backup of the factory image on emmc.
