Posts by chewitt

I got bored in my lunch hour so this image has a device-tree for tx9-pro which uses the IR remote from tx3-mini .. if you have the larger Tanix remote with numbers on it those won't work and you'll need to capture the key codes for me. I've also added something for the clock on the front, which might work if it's the same type as the TX3-mini box. If not the same, it might show nothing or garbage.

https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.1-box.img.gz

Again, run "pastekodi" and share the URL so I can see the boot log.

Start with an update to 10.95.1 and check again.

The remote will not work unless:

a) the remote keymap is added to the kernel and a custom device tree created to reference that IR keymap

b) you manually add the keymap, see: https://wiki.libreelec.tv/configuration/…ration-advanced

Normally users need to figure out the keymap first (B), then share it, then I can think about creating a custom device-tree file (A).

It sounds like Kodi is otherwise running .. which means the box is working. Please SSH to the box, run "pastekodi" and share the URL.

The row of four pins next to the socket are for the serial UART .. easy to spot as one has a square marking. It's quite normal for the pin header to be omitted from the board (saves a few pennies).

If not in the audio jack I'd expect the reset to be on the underside of the board, which we don't have a photo for.

echo "blacklist ptp_kvm" > /storage/.config/modprobe.d/ptp_kvm.conf

This might suppress the warning ^ .. otherwise (as you discovered) nVidia GPUs require the Generic-Legacy image.

If you move /storage to exFAT or NTFS volumes the SSH service will fail to start because the SSH daemon will check keys in /storage/.ssh are secured with correct permissions before it runs; and neither of those filesystems support unix permissions causing the check to fail.

Yes, the AV port. This often has a small button at the end of the socket, i.e. unfold a paperclip and poke it right down the hole to press it.

Run "pastekodi" after a clean boot and share the URL

Quote from jim_p

There is no reset button in it, so the toothpick method does not apply to it.

Have a look down the audio/cvbs 3.5mm socket. If there's no obvious button on the underside it's often hidden there.

Quote from frakkin64

I have only worked up the nerve to chainload mainline u-boot on the Vero4K, pretty reluctant to format the eMMC and load that mainline u-boot. And naturally all working from SD cards. It's just not worth it, so far I haven't seen an SD card failure, and I have weekly backups anyways of /storage.

Is that the 4K (S905X) or 4K+ (S905D)? .. I'm still waiting on a positive test report to send it upstream.

Sam did promise to submit the FIP sources for his boards at some point (prob. minus the BL32 bits, but those are optional) .. but then he's also promised to test the 4K (for six months) and send me samples (for two years) so I'm not holding breath. Running your own business is time-consuming

I'm not aware of any upstream Amlogic dtb's that have Realtek WiFi set; which is because most box device-trees are for older devices and the drivers aren't supported so kernel rules say you don't describe unsupported hardware.

If you work with vendor kernel images the Realtek problem is less of a problem because the kernel NEVER changes. That means zero security updates and such .. but also means the WiFi driver you hacked to run stays running. In LE where we track upstream kernels the drivers tend to break with every major kernel bump and novelty of fix-hunting wears off fairly quickly.

You should be able to revert to a legacy kernel image by putting the box in recovery mode, i.e. toothpick method, with the respective installer SD card inserted. The box should search-for and find the bootscripts and set things up again.

The wireless module is top-left on the PCB (below the cut-out). I can't see the model markings on the chip, but the Realtek "Crab" is visible and that explains the lack of WiFi probing on the device. It's an older Realtek chip not supported in the upstream kernel (because if it was, it would probe) and LE does not add Realtek vendor drivers as they're a pain in the rear to maintain over time. They do exist though, and you could always self-build an image with the driver embedded. The BT side of the module is serial (not SDIO) and in some cases there is support for the BT part but not WiFi (as they are different drivers) but for that we need to know the specific chip model as the "compatible" string in device-tree determines which driver and how it loads. The photo isn't high-enough resolution to see the model details, and they're often a bit fuzzy to start with.

NB: Logs from a vendor kernel boot (Android or CE) will probably show more clues about WiFi/BT chip details, although the multi-vendor DHD driver that's used in Amlogic kernels does obscure the info a bit.

EDID is all about HDMI, so it's either the GPU pass-through or something else interferring with the HDMI path.

"docker-compose version" ? .. or set $PATH to include the bin dir so you don't need to ./execute it as a script?

HDMI audio is dependent on the OS seeing the EDID data needed to determine audio properties. Does LE work when booted natively on the hardware (not being forced via UNRAID)? If yes, the problem lies with how UNDRAID handles the pass-though of hardware.

NB: LE does not (and never has, and has no plans to) support being used via Hypervisors so while it might work sometimes, it's not something we seek and there could be other things missing.

The whole point of "pastekodi" is to see whether Kodi is running, which it 100% isn't if the box is still in "textmode" boot, because that stops Kodi from running to give you a local terminal.

If you are able to SSH into the box now? .. Clean install using a different SD card. Connect via Ethernet. Run "pastekodi" and get the URL back.

Quote from frakkin64

Anyways, the point of this meandering is to share that toothpick method can kill eMMC installs depending on whether they use the instaboot partition in a similar way.

LE boot scripts don't touch partitions at all, but if the boot processes aml_autoscript then we're changing the boot flow stored in the u-boot environment to use our scripts, which will "break" legacy distro booting due to them using kernel.img not KERNEL and more. Some of these differences are intentional; partly to align with LE standard namings, but also because we (me) don't want users "updating" from all kinds of unknown legacy images to AMLGX and then showing up with tricky-to-solve support issues. Boot is already "fun" before you factor in large Kodi major version bumps and the Python2 to Python3 change which causes add-on carnage. Forcing clean installs is just a sensible move.

I'm unable to see/access the pic .. imgur.com is overloaded or something.