Posts by chewitt

One of the RK kernel team suggests it could be a DMA controller issue.

If you labelled your USB stick 'Storage' did you also change the label for the SD card second partition? (which by default is also Storage). If you end up with 2x 'Storage' I'd guess the SD card will be probed for and mounted first.

Have you tested with a mainline kernel? Nothing found — Yandex.Disk contains Armbian images for GXM using 4.18 which would be easier to work with for development and tinkering purposes. If you're capable of writing network drivers the lack of device-tree for the T95Z shouldn't faze you too much.

RK kernel team don't have much documentation on that chip; mostly a comment that it's compatible with the RTL8211F part so the only difference might be power or a crystal oscillator. I didn't hear back from AML team.

It's not impossible or particularly difficult, but we already have 4-5 different collections of brmfmac firmware and instead of tacking another on to the build system for the Generic x86_64 image it's about time we consolidated them and came up with a sensible build-time and userspace method for supporting device/board specific nvram configs; because we currently assume devices that use the same brcmfmac chip can use the same nvrman config and that's not the case (and I suspect this is why we have accumulated multiple firmware collections over time). That work gets a little easier once we have more devices on a common Linux 4.18/4.19 kernel codebase (as the kernel-firmware repo provides the latest or common firmware, but no nvram configs) so I wasn't planning to look at it until after LE9.0. If will probably be done for LE9.2 once we start to shift some of our Android-oriented hardware groups off legacy BSP kernels, which is always a good time for package spring cleaning.

NB: in the Bluez move from hciattach to btattach the codebase is still fresh and I already found a number of cases where brcmfmac device ID's aren't mapped so devices either don't prompt for firmware or the filenames (as documented in all the howto guides you find in Google) need to be adjusted.

In summary.. if you have a homebrew solution that's working please stick with it for a while, and we'll catch you up sometime later in the year.

If you want it use SMB1 set Kodi smbclient version min/max to SMB1 so it cannot connect using SMB2 or higher, because the default protocol version is SMB2 or SMB3 (I forget which) and if enabled, it will connect and fail, there is no dynamic step-down to SMB1. Yes this is complicated. No it's not our fault. Either way, the sooner you start using authenticated connections the sooner you won't have to reconfigure Kodi again once some other MS change is pushed down.

1. Yes, assuming you have an IR sensor that the Harmony can be programmed for. If not, get a 'flirc' receiver.

2. There are ways but we avoid discussing how to bypass geoblocking in this forum because basically it's a form of piracy

3. Sure (did you Google?) but beware of piracy laden crapware repos, not good for boxes and we'll refuse all support if you install them.

4. Go back to Windows, it won't run under LE

5. Yes, but it will require the current LE alpha release and one of the Netflix addons from the Kodinerds repo

The one reference to that PHY that I found on Google was on schematics for the Rock64 (a Rockchip device) but marked optional, and TL Lim who makes that board says he has no memory of looking at ZTE parts. I've asked internal to Amlogic as well, but if it's only been used in a handful of devices I wouldn't be too hopeful.

It might be possible to capture and then force the EDID via kernel boot params. The raw EDID data and override location is probably under the /sys/kernel path somewhere, but I have no idea what the specific steps are for a Rockchip 4.4 kernel.

The normal complaint about slow Ethernet on recent/mainline kernel is solved by disabling eee in device tree or from userspace via ethtool.

See linux/meson-gxbb-odroidc2.dts at master · torvalds/linux · GitHub .. although that dts is for mainline kernel so that binding might not exist in the older BSP kernels.

I can ask contacts, but replies to random Q's (vs. things we're working on) are never quick.

because it's a "code doesn't exist" issue, not something that can be reconfigured after spotting a problem in a log file

Android only due to the locked bootloader.

An 802.11n device with dual antenna supporting 5GHz modes and a well written driver will outperform the latest 80211.ac hardware with a crap driver. And 802.11n hardware might not make use of the full 802.11ac featureset, but it's fully compatible with 'ac' routers. And if you want your media to play reliably you'll run an Ethernet cable, because ultimately all wireless leads to disappointment

Last time I looked on eBay there were still plenty of 'Virgin' branded WNDA3200 adapters (which use ath9k) going cheap. I bought a couple for £4/each but that was a while ago. Use wikidevi to find other brands/models.

3B+ is considerably better than B3 for radio things. The next alpha release will have some BT firmware improvements for the RPi3B+ that reduce interference with wireless (which is usually active at the same time even if you're using Ethernet) which might help.

Logs won't make a difference, it's just something that's not currently supported. Hopefully that changes over time with more development.

I have the 65" version of the same LG panel and a similar AVR and a legion of test boxes/devices to experiment with. The short answer to the question is "the box you are seeking does not exist" .. and on that basis I'd go pick up a cheap S905D box with GB ethernet (avoid the S905D devices with 100-BaseT PHYs). It'll be fairly cheap so when you chuck it out in 24 months time to get a newer (still not meeting that spec, but more advanced in some way) device you're not left writhing in angst about how much it cost you.

NB: Nothing truly supports HDR on Linux right now, but Amlogic is the leading "least worst" option at the current moment

The LE staff have a generally low opinion on Realtek wireless devices. The hardware is probably reasonable, and performance on Windows is probably great because that's where they invest all the Engineering time. Their Linux drivers are an afterthought, and we're fed up with they way they breed chipsets and new drivers that rehash the same greatest-hits compilation of hacks over and over.

Find something that uses the ath9k driver, which is in-kernel and much higher quality code.

The moral of your story is buy a USB wireless dongle that has a decent chipset and in-kernel driver, not some piece of realtek crap.

LibreELEC is intended for dedicated HTPC devices so Kodi (on LibreELEC) runs full-screen and outputs to the primary display device (whatever that is) and there is no GUI support for running with multiple-monitors (or laptop screen + HDMI output). It can be done from the command line, but that's more advanced. Another option for a laptop could be forcing the display output in the BIOS.

If you want GUI multi-monitor support, use Windows or a conventional distro like Ubuntu.