Posts by chewitt

I don't think you can do this in LE, but it may be possible in the Raspberry Pi OS which supports multi-display output.

Linux support is all about what chipset is used in the card, and whether that chipset has (PCI) drivers available. You need to start by telling us what the chipset is .. else we can only guess and then the answer is "maybe it works, maybe it doesn't" .. the other option is to boot LE from a USB stick and see for yourself.

The obvious Q is .. do you actually have 4K60 media (other than test media)? .. If the answer is 'no' then don't worry about something that you don't need. Most people do not need 4K60 modes. NB: Some TVs only support 4K60 on specific ports .. no idea about the C1 but it might be worth experimenting with different ports and seeing if needs to be enabled in menus on the TV side.

systemctl stop kodi
systemctl stop eventlircd
ir-keytable -p nec -t

^ run the above commands over SSH to put the IR receiver in raw/test mode, then press remote keys one at a time starting top-left and going across then top-down on the factory remote until you have all keys recorded. It would be super helpful if you copy/pasted the keys into a text file and appended notes on what the keys look like; most are obvious, some might need a description. From this I can create a keymap that should get the remote working out of box. NB: I can see the older amremote keyfile in some remote keymap repos, but this document codes for more keys than the remotes I see in vendor pics have, and the codes generated by the upstream kernel are likely different, so best to get them fresh in the right format.

I'll make a guess at the LED setting. I suspect it's orange-red in off/standby and blue when on?

The dts is still inheriting something to do with Broadcom SDIO chips from somewhere, hence it's not probing for the Realtek WiFi chip. I will have a look and see what I can find.

NB: I don't see any mention of BT on the vendor specs, so is this a USB device that you added?

date -d "@$(( $(busybox date +%s) - 86400 * 14 ))" +%d/%m/%Y

^ from https://stackoverflow.com/questions/4852…-date-x-day-ago .. not tested but I think should work.

The issue is not whether you can install LE on it (maybe) but whether it runs any good once it's installed. Old laptops are generally slower, noisier, with worse media support, and use more power than an older Raspberry Pi2/3 board. Experimenting is $free though

Flirc requires the USB ports to be powered. Once you turn the board off, the USB is not powered so you cannot turn on again. Apart from that the flirc receiver is awesome.

bertiera please install (or update to) https://chewitt.libreelec.tv/testing/LibreE…85.0-box.img.gz for testing. I've added a device tree specifically for the box (meson-gxl-s905l-venz-v10.dtb) which should get WiFI working at least.

Does the box have power LEDs or power buttons on the case?

Is there an IR remote for the box? If yes, what keymap is used?

Looks interesting and makes sense for industrial users. If it's an official RPi Foundation created module? we can probably get a sample sent to HiassofT who has my Slice3 box in his collection since last summer now. That said, there are now only ~45 Slice boxes showing in stats (down from ~100 pre-Covid) so it's probably not high on the to-do list.

RPi has no native IR capability so needs an additional device with independent power and IR receiver that can control the main power to the board, either by being inline to the normal power connector or through driving power input pins on the 40-pin connector. It is not possible to use a GPIO receiver because the GPIO pins on the 40-pin connector need power before they can receive anything.

Our normal response would be that the 2GB RPi4 is the minimum RPi4, but that's considering 4K support which you probably don't/won't need in a space constrained RV installation. It has newer/better/more-efficient design and considerably more CPU grunt which is always a good thing. It also allows you to run LE10/LE11 so is more future proof (we already dropped support for Pi0W) and you'll have native HEVC hardware decoding. As long as it's not a crazy price it would definitely be an improvement. Then again, so would an RPi3B+ which you might be able to pick up cheaper/easier somewhere. Not as future proof, slower, and similarly 1GB RAM constrained but still a worthy bump.

Some of their containers are deliberately missing from the 'repo' list but I'm not aware that's one of them. There's no harm in trying to use it .. if it doesn't work just rm the container.

I don't maintain Rockchip stuff, but I add boards and such to Amlogic frequently, so:

https://github.com/chewitt/linux/commits/amlogic-5.18.y <= my kernel sources

https://github.com/chewitt/u-boot/commits/amlogic-2022.01 <= my u-boot sources

https://github.com/chewitt/LibreELEC.tv/commits/amlogic <= my LE sources

There are lots of previous examples of devices being added in GitHub.

It will either fix the issue or it won't .. so easy to test and try

LE patches generally follow <package>-<number>-description.patch but it depends on who created them and where they are used, e.g. for Amlogic kernel stuff I'm generating patches using "git format-patch" so things are number sequenced; other maintainers bundle patches together into large sets (which I don't like, but each to their own). Regardless of the naming convention the build-system applies patches in alphanumeric sequence.

If you intention is to submit the patches to our git repo; be advised that we will not accept/merge them unless we can see the same patches on a kernel and/or u-boot mailing list with acks from maintainers, i.e. we will accept a backport of an upstream accepted patch, we will not accept an orphan patch that only exists in LE (else we will never get to drop the patch in a future kernel/u-boot bump).

a) Patch upstream kernel sources to include the dts and build the dtb

b) Patch upstream u-boot sources in include the dts with a u-boot config file

c) Generate patches for the kernel and u-boot changes; ensure those patches apply on-top of existing LE package patches

d) Add patches to the 'patches' folders of either the packages or under projects/Rockchip/devices/RK3399/patches/(linux|u-boot)

e) Modify scripts/uboot_helper to add a device using the kernel dtb and u-boot config file

f) Build the image

There aren't really instructions for this anywhere; GitHub commits serve as 'prior art' and there's a deliberate low-bar requirement for some initiative and general understanding of how distro image building and build-systems work.

There is no recovery script; it should prompt the box to re-read the u-boot scripts (s905_autoscript etc.) which will load the LE kernel file and dtb into memory and boot them. I'd need to see UART (serial console) output to understand where it goes wrong - it's always worked for me and others in the past. WeTek did ship UART cables with the box but I'd expect most folks to have chucked it out by now? - The wetek-play2 image boots the device from SD card using upstream u-boot; but only if the eMMC has been erased (removing vendor u-boot) first, and the best way to do that is booting the device from the box image (catch 22).

Hard to say without seeing a proper debug log file, but the reason why we have written "DO NOT UPDATE, CLEAN INSTALL" all over the LE10 release notes is that add-ons cause issues due to the Python 2 to 3 changes. If you're comfortable at the command-line I'd stop Kodi and rename /storage/.kodi to /storage/.kodi-old and then restart Kodi. You now have clean instance and can clean install add-ons so they work and stop/move-stuff/restart bits of Kodi content to manually restore the essentials like thumbs, sources, databases, add-on settings, etc.