Posts by chewitt

Please share the "pastekodi" URL from the working USB install.

Same problem, different bus.

If you use a decent SD card not some prehistoric 2MB one the runtime experience will improve. There is also lots of scope to increase the SD card device speed via device tree if faster speeds prove reliable. That's always a gamble with Android boxes, which is why the card device in the currently experimental device-tree is using slower-but-safe defaults.

NB: I'd rather have dental work done without anaesthetic than engage in supporting emmc installs on Android boxes that we have no boot sources for. Under the legacy kernel it's a major pain in the arse to support but technically do-able. On an upstream kernel where the kernel cannot understand the partition scheme or see any of the partitions on emmc it's an entirely different game.

Quote from ajbathe

I changed KERNEL and SYSTEM of LE11 on raspi4 with the old kernel 5.x, but saw the same behaviour, so I don't guess it's kernel related. Maybe the reason can be in the fact that wpa_supplicant was kicked out and iw is used now? As long as you can't establish a connection via console commands (like above), the way over GUI won't do it, wouldn't it?

If you switched both KERNEL and SYSTEM you swapped Linux 6.1 + iwd (LE11) for Linux 5.10 + wpa_supplicant (LE10) .. which would imply the issue has nothing to do with the entire software stack.

It would be useful it people would state what network card make/model exhibits the problem. Also what router make/model you are using.

The LE11 log shows the wl driver is loaded which should indicate something was seen and probed on the USB bus, but no interfaces for the device show up. The LE10 log has rotated so we don't see driver load, but the wlan0 interface is clearly present.

Google searching doesn't reveal anything for wl under Linux 6.1 other than yet-another-patch but we have the same patch collection as other major distros are using. In short; the driver compiles and is present, but there's some other issue.

Run "pastekodi" and share the URL please

PhoenixBG please update to https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.0.tar and see if that resolves USB ports? - and focus on the t95z-plus dtb not Q200/Q201 comparisons. To get the remote working you need to share a working remote conf or follow the instructions in https://wiki.libreelec.tv/configuration/…ration-advanced and share a listing of keycodes and notes on what keycode represents which remote key; from that I can create a keymap driver and preconfigure it.

I've seen this on my own board, and I think the cause is noise on the UART pins which is interpreted as a keypress (hence it enters u-boot). If you remove the UART cable does it boot normally?

There is no requirement to have the mail headers for a patch, so there's probably some other formatting issue with the patch. Overlays are already supported with Allwinner devices, but you'd need to patch the sources for the git repo that we store the dts files in (the dts files are compiled to .dtbo) to include your extra overlay dts. It's exactly the same process but more abstracted so most users would probably find patching a kernel repo easier.

Comparisons with other distros aren't meaningful as their software stacks are different and this is a software problem. If you can repeatably prove it works with earlier 10.0.x releases and then breaks at a specific release; this would be relevant.

Our crystal ball is broken. You might need to provide some logs.

Mar 11 09:40:16.306338 LibreELEC kernel: EDID block 0 is all zeroes

^ No EDID data on the HDMI connection means kernel cannot figure out what resolutions are available. Normal cause would be a bad cable or bad monitor. I can see various video overrides in the config.txt and cmdline.txt file. I'd suggest you find a spare SD card and start with a clean install first, then share pastekodi again.

<?xml version="1.0" encoding="utf-8" ?>
<advancedsettings version="1.0">
  <!-- enable debug logging -->
  <loglevel hide="false">1</loglevel>
</advancedsettings>

Create /storage/.kodi/userdata/advancedsettings.xml with ^ that content and reboot and Kodi will be in debug mode.

If the drive is macOS formatted (HFS+) then it's read-write under macOS but will be mounted read-only by default under Linux. It is technically possible to fsck the filesystem and force-mount it in read-write mode under Linux; but Linux doesn't officially support that so it won't happen by default in LE and I wouldn't recommend it. As with NTFS drives (different filesystem but same problem) the solution is to reformat the drive to use exFAT which is read-write supported in Windows, Linux and macOS.

Quote from MacUserAtt

Hi.

I'm using a Raspberry Pi 4 with software version 11. I'm running an external USB HDD on it. I can read the drive on my Mac with the standard username and password and copy files to my Mac, unfortunately I can't write to the USB drive, any advice?!

I'd guess the drive is NTFS formatted (default for Windows)? .. macOS only supports read from NTFS drives, not read-write. If you reformat the drive using exFAT it will be read-write in macOS (and Windows, and Linux).

Nothing has changed with Midnight Commander, but the Generic image now runs on the DRM framebuffer (GBM/V4L2) not Xorg; so 90% of the display pipeline did change and that's likely the reason. It's something to investigate, but not a super-high priority.

PROJECT=Allwinner DEVICE=H3 ARCH=arm scripts/clean linux
PROJECT=Allwinner DEVICE=H3 ARCH=arm scripts/unpack linux

I would expect that both folders are functionally the same; PROJECT patches should be applied first, then DEVICE patches. You can check the unpack (and patch) process outside of a build with ^ those commands. It's easier to spot what's included/not-included. Patch files need to be something.patch and are applied in alpha-sort ordering.