Posts by chewitt

There are some Lakka devs in team chat, so I'll ask if they're doing anything different.

The wl driver is only used with a small handful of really old Broadcom SDIO chips. Newer designs are supported through in-kernel brcmfmac and brcmsmac drivers which are well supported and actively maintained.

Poor WiFI performance on RPi3B (and every other RPi board that I used) is a radio signal issue, not a chip or chip-choice issue. An external antenna connector would solve the issue, but I guess when you're intentionally cost-engineering boards for short-range hobbyist use there are design compromises to make, and perfomance comes second to cost.

It's a simple question with a non-simple answer. If you are playing H264 media the latest version works best. If you are playing HEVC media you will find the lack of hardware decode for HEVC on the RPi3 boards to be a challenge and shouldn't expect 1080p media to play well. Older LE 9.2.6 contains optimisations that (combined with some overclocking) allow most 1080p software decoded HEVC media to play, but those optimisations are not technically possible to include in the current releases and 9.2.6 is ageing so you may find issues with TLS certificates and older/unmaintained add-ons and online media sources may have challenges.

It was either Realtek RTL8189ES or RTL8189FS .. I forget which.

The wl driver has been unmaintained for years so hearing it panics doesn't surprise me. Share the report and a dmesg log in a separate thread.

The H4 should support EFI boot, which opens the door to using efibootmgr which can be installed from one of the tools add-ons in the LE repo (system-tools?). See https://linux.die.net/man/8/efibootmgr or https://wiki.gentoo.org/wiki/Efibootmgr. You would be able to combine efibootmgr with some custom buttons on a remote that configure the EFI boot entry to reboot to.

To confirm: You are saying that PCSX games work fine under Lakka on the same RPi4 hardware, but not under LE?

The upstream kernel does not expose the u-boot environment to userspace so there is no way to modify it to change the next boot behaviour. If you need that capability you are stuck with legacy vendor kernel images.

I usually rip disc's in FLAC for HiFi (AVR) playback with Kodi and then I rip again in 320Kb MP3 for phone/car use. I'm rotating the disks in the NAS roughly every 6-7 years and each rotation seems to cost the same but I end up with double the space I got in the previous one, so there's always space available. My priorities may be different to yours though.

https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz has a 5 second bootdelay set, which should pause boot waiting for input. If you hit enter/space it should enter the u-boot console and you can run commands. There no specific command to run; i'm interested in whether you can provide input or not, or does the board continue to stop/lockup at that point?

As per the wiki article, you need to invoke recovery mode boot on the box (toothpick method or similar) to ensure it looks for LE boot files not CE ones. If that's not the issue, we'd need to see UART logs of early boot to see where things go wrong.

Have you installed an online subtitles (source) add-on?

FLAC

run "dmesg | paste" and share the URL .. WiFi should work on most devices depending on what chip is inside.

no issues with copy/paste here (on macOS)

Second boot from a hung board requires power cycling so it's technically no different from the first boot. The gibberish looks like a buffering issue to me, i.e. rubbish drivers for whatever USB UART cable. Using Windows? .. If using macOS the "Serial" app is the one to use (non-free, but worth it).

The only time I've seen boards boot and get stuck here is on some (but not all) WeTek Hub boards. The current suspicion with them is that noise on the UART connection (perhaps related to dry solder joints) is interpreted by u-boot as keyboard input and thus it drops to the console (although then the console must have some other issue to not be accessible).

I'm going to create a one-off image with the u-boot console compiled out or compile differently to see if that allows the device to boot. That might take a day or two to get around to, but I'll post a link when done.

CE should detect the installed image as "S912.arm" and image to update to as "AMLGX.aarch64" and since they do not match (and you have not manually overriden the update check) the update process should fail with an error message on screen, before erasing the (incorrect) update file and rebooting.

If you manually start trying to rename files on SD cards then it's possible to break stuff in other ingenious/exciting ways

Interesting, it's stopped at the u-boot console prompt. Are you able to run commands at the prompt, or has it locked up?

The better advice would have been to update to an LE12 nightly that has the same fix included. You are now on LE13 so while Kodi database file are currently same-version (we haven't bumped to Kodi P in master branch yet) the LE and Kodi-binary add-ons are numerically bumped to LE13 and will need to be removed and reinstalled if you want to downgrade to the next stable LE release (12.0.1) when it arrives. Note that removal/reinstall doesn't mean you lose settings.

Yes, that process.