Posts by chewitt

It sounds like the HTPC device is running in a different IP subnet to the NAS and there are no routing rules (or gateway) to handle routing data between the two subnets; hence the "no route to host" message. If you added a WIFI router to an existing network (a hunch) it will be easier to configure it as a wireless bridge so it simply provides a wireless extension to the existing network instead of creating a second (routed) network for wireless devices. If you use it as a router (which will also result in NAT being used) you will need to configure routing rules (either manually on each host or pushed via DHCP) so devices in each subnet know how to route data to each other.

Can you give me the URL generated by "lspci | paste" .. and I'll see if I can find the ID's in kernel code to create a patch.

What kind of log entry are you expecting to see?

cp /usr/share/kodi/system/keymaps/keyboard.xml /storage/.kodi/userdata/keymaps/keyboard.xml
nano /storage/.kodi/userdata/keymaps/keyboard.xml
<make changes>
systemctl restart kodi

Copy the default keymap ^ and edit things. Also see HOW-TO:Modify keymaps - Official Kodi Wiki

LePotato is a nice board (similar, but better designed than C2) but it has core weakness of all S905X devices; only 10/100 Ethernet. The better option would be an S905D device with GB Ethernet, but beware that some also ship with 10/100. Odroid N1 was cancelled. N2 will be along in a bit (but no ideas on it) and the H1 that HK have just announced probably isn't cheap but will have the advantage of being x86_64 and thus less exotic to support compared to ARM hardware. NUC's are good too.

NB: If it works, don't fix it

@Ae3NerdGod any further comment like that and you are banned. We do not tolerate that kind of language and behaviour in this forum.

SO .. basics. What card are you trying to use? .. and what GPU's models are physically present in the box?

It's not clear which device you do want to use, but assuming it's the AMD card the following will blacklist the nVidia driver module and prevent it from being loaded at boot time; at which time only the AMD card should be usable and xorg.conf(s) shouldn't come into play.

echo "blacklist nvidia" > /storage/.config/modprobe.d/nvidia.conf
reboot

Looks like the device ID exists in both drivers (bcma and wl) so whichever one happens to be loaded by the kernel first (roll dice) tries to claim the device. We should probably patch out the device ID to prevent that.

Quote from Tidav7578

I wonder if there's a workaround or if there's a working addon somewhere.

It only works on LE 9.0 images. Update.

what does "lsmod" show?

Oct 19 23:54:25 kernel: bcma: bus0: Found chip with id 0x4360, rev 0x03 and package 0x01
Oct 19 23:54:25 kernel: bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x2B, class 0x0)
Oct 19 23:54:25 kernel: bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x2A, class 0x0)
Oct 19 23:54:25 kernel: bcma: bus0: Core 2 found: ARM CR4 (manuf 0x4BF, id 0x83E, rev 0x02, class 0x0)
Oct 19 23:54:25 kernel: bcma: bus0: Core 3 found: PCIe Gen2 (manuf 0x4BF, id 0x83C, rev 0x01, class 0x0)
Oct 19 23:54:25 kernel: bcma: bus0: Core 4 found: USB 2.0 Device (manuf 0x4BF, id 0x81A, rev 0x11, class 0x0)
Oct 19 23:54:25 kernel: bcma: Unsupported SPROM revision: 11
Oct 19 23:54:25 kernel: bcma: bus0: Invalid SPROM read from the PCIe card, trying to use fallback SPROM
Oct 19 23:54:25 kernel: bcma: bus0: Using fallback SPROM failed (err -2)
Oct 19 23:54:25 kernel: bcma: bus0: No SPROM available
Oct 19 23:54:25 kernel: bcma: bus0: Bus registered

^ looks like the card is trying to use the in-kernel brcmfmac driver instead of the vendor wl driver, so perhaps blacklist it and reboot:

echo "blacklist brcmfmac" > /storage/.config/modprobe.d/brcmfmac.conf
reboot

sorted?

только английский пожалуйста

It's not sure it's possible to damage the CM1 unless you've opened the case and done anti-static nastiness. There's an element of timing and sequence to the flashing process though. It's a bit fiddly.

CM1 is fine for audio only. If it's works, no need to fix it.

If you share the log we can see if there's an obvious problem. If you don't share the log .. we are not clairvoyant. It's entirely your choice.

There is no need to unsquash/squash. Just create /storage/.config/xorg.conf with whatever content you require for your GPU and it will be used in preference to the any of the embedded conf files on next boot.

AMD supports GBM (Generic Buffer Management) which facilitates the future V4L2 pipeline same as every other GPU/SoC vendor. nVidia has decided to follow their own "standard" that nobody else uses. Team Kodi are done with supporting proprietary standards due to all the extra code spaghetti and support work it entails so AMD (and basically all other current vendors except nVidia) are fine and support for nVidia in Kodi will almost certainly die off. We see it as nVidia's responsibility to start following standards, not our responsibility to rewrite everything around nVidia.

Provide Log File [LibreELEC.wiki]