Posts by chewitt

Works fine for me

I think it was a "timing" problem more than anything else. Not long after Slice launched (late) RPi2 came along, and the lack of CM2 card meant the specs looked weak, and then RPi3 arrived to drive nails further into the coffin. CM3 eventually caught up, but that was some time later again and by that point the day-jobs of the "Five" had also multiplied via Pi success and the company they'd formed hadn't sold enough product volume to really be viable. These days the Pi Foundation owns the IP/designs, but while I think having them create/release an "official" HTPC box would be good for their own sales it would also put them into competition with their ecosystem in a negative way.. but I should ask Gordon anyway

Our release archive is here: https://archive.libreelec.tv but if it fails on the 8.2.5 release with 304.xx drivers I'd guess even older releases will fail too since they're just using older versions of the same driver. FWIW, most Raspberry Pi devices will outperform that box with ease.

I'll phrase it in different terms: It's a known and deliberate design choice to show the password in clear. Users are working with an on-screen keyboard and IR remote which encourages mistakes. If you want to set the passwork "privately" accept the defaults on-screen then access the device over SSH to set the password (passwd) without being observed. You can also setup key-authentication to avoid passwords completely.

Quote from Xenon

I'm using WiFi.

^ WiFi in all RPi devices is a bit horrible. I'd make the other half happy, by stopping using it and run an Ethernet cable. If you must use WiFi setup a router in Bridge mode so the Pi sees an "always on" Etthernet connection and set Kodi to "wait for network" on start. Get a flirc.tv - Your TV - PC Remote Companion device so you can use any decent IR remote instead of CEC (which normally works well, but depends on the specific TV and its firmware). Then as zomboided has suggested, separate the tuners (head end) from the playback client to reduce load on the local system.

OpenELEC never offered the option to change the default root/openelec credential, hence you can't remember setting one

I'll update the wiki article to make it clear that you need to enable SSH first, then open an SSH connection to the box to run the commands.

Kodi support for CHD was removed between Helix (v15) and Jarvis (v16) and the first LE releases are Jarvis based, so no. It was still possible to hack support back in, but the only device using is was the mk1 AppleTV and that ran badly on Jarvis so I never released the images.

The is the last-known CHD driver repo GitHub - dbason/crystalhd: Broadcom Crystal HD Hardware Decoder (BCM70012/70015) driver on Ubuntu .. it's not very active these days.

To expand on the move. Anyone with a GitHub account can submit changes to the repository to add/remove content. GitBooks is largely based on the same "markdown" standard as GitHub pages, so fairly simple for people to work with. I did not migrate the entire wiki as some data is now rather out of date (most of the Pi stuff was a bit 2016) but there are still lots of opportunities to add content.

Anything in a Mega share controlled by one person is a "personal archive" not a "public repository" so we should avoid sticky links. Put the content in GitHub or similar and you have version control, the ability for others to contribute changes and new device content, and you can share the ownership and long-term management of the repo with others (less work for you, and others). If you restructure the repo using device-tree names or something similarly programmatic (but still simple for users to follow) instead of the multi-level A-Z format it becomes possible and easy to consume the content within distros which can make it easier for users.

bl33.bin comes from mainline u-boot, see LibreELEC.tv/install at amlogic · chewitt/LibreELEC.tv · GitHub

NB: In testing I've been able to boot GT-King Pro using the LE images for N2 and VIM3, the DRAM timings appear to be close enough to work, at least on the device I have. No progress on figuring out why mainline u-boot cannot see 4GB RAM, despite the Beelink devs trying to guide me on changes to the DRAM timings in acs.bin. Since 2GB is more than enough for LE use solving that is not a big priority tho.

amlogic-boot-fip/gtking at beelink · chewitt/amlogic-boot-fip · GitHub

^ These are the FIP files that I am using, which can be used to sign a mainline u-boot image. I built mainline u-boot using the VIM3 defconfig and the signing recipe from the N2. You can use the same process to write u-boot to eMMC as any other Amlogic device.

I haven't figured out the root cause and I don't have the code-level skills needed to, but I was able to build and boot mainline u-boot on a GT-King Pro and this works without the lock-ups; which points the finger at something in the vendor u-boot code; which we have incomplete sources and no git history for (to understand how Beelink modified it). The GT-King Pro also has an RS232 port on the rear of the box which makes the UART based processs of disrupting then erasing vendor u-boot less complex, but this is a million miles from a "solution" for users - it's fiddly as hell and GT-King (non-Pro) and GS-King-X need dismantling and soldering of UART pins to their boards to get equivalent access.

Netflix 4K requires Widevine L1 certification for the device. You can use Android or AppleTV, or a very select number of proprietary Linux based devices that are certified. Kodi on Linux (e.g. LE) fakes an L3 cert which can normally get 1080p, but nothing more.

LE has capabilities for expanding software function (Docker, etc.) but it is not even remotely designed to be a secure router OS and any $20 dedicated router will outperform and provide a better administration experience. From experience - if you want a router, get a router.

"You can't always get what you want" .. Mick Jagger

Statefull support for seek/skip is proving to be a challenge. No particular progress, which is frustrating.

GT-King/Pro/GS-King-X all have an issue with deadlocks under load that hasn't been figured out. I don't do code so have no clue where the problem really lies but suspicions are on the block subsystem - or in regulators - beelink wouldn't be the first vendor to share schematics that don't match the boards they produced. I've reported the problem upstream without much success (will redo on 5.10-rc1 shortly). FWIW, I don't see deadlock issues on other devices (VIMs, etc.) and overall I consider the mainline kernel to be very stable (not feature compelte, but stable within the features present. I only see deadlocks when experimenting with things that I expect to cause deadlocks.

It's a while since I looked inside a Slice box (and mine is 3500 miles away) but I suspect you're right, it's probably too tight to use the adaptor. Probably not the hardest problem to solve with a 3D printer tho

davo22 indeed blasphemy is possible Gumstix Introduces CM4 to CM3 Adapter, Carrier Boards for Raspberry Pi Compute Module 4 .. but add $30 to the cost of the CM4 module and things are starting to get expensive, and you're still misssing proper Ethernet and other things that IMHO make an RPi4 more long-term attractive. Slice also needs drivers/hardware support that means it's not quite the simple swap that you'd want.