Posts by chewitt

It's possible to use "autoscript" files to provide uboot with instructions on what to boot (from) but those files do not exist in current 3.14 kernel images and they are compiled scripts (not just plain text files) so there's a little bit of uncharted work involved. If you don't provide instructions uboot will boot from external media if present.

If the slot is "loose" the easier cure is probably to open the case and ensure the connections to the board are soldered properly and the connector tabs that locate the connector housing in the PCB are either tensioned correctly. Or maybe use a hot glue gun to get things under control.

The real credentials are masked with USERNAME:PASSWORD for security reasons as people post logs to pastebin.com and similar.

Spaces in usernames are always a bad idea.

Rockchip is currently using an older 4.4 kernel codebase and things are in a "basic functional" state; it works and we've learned lots about RK support but it's not perfect and we don't plan on developing it much further. In the near future we will rebase our Rockchip support against the mainline Linux kernel - probably after 4.20/5.0 is released. This will be initially less functional than the 4.4 codebase, but once we start finding and fixing things on mainline we can upstream the fixes directly to the kernel and we don't end up carrying a huge patchset that's at a different state to other hardware platforms. Rockchip video decoding also needs to make the evolutionary leap from using an ffmpeg hwaccel to a proper stateless V4L2 decoder so it's using the same Kodi code-paths as everything else - and that's quite a bit of work. So Rockchip images will not move to Beta for LE 9.0, but the goal is to have everything sorted for LE 10.0 (Kodi v19) latest, or an interim release if possible.

TL/DR; RockPro64 is a nice board but you should not expect the same level of maturity as the Raspberry Pi for a while.

There's nothing wrong with SMB in current images. What is the SMB server?

Intel HDR support in the mainline kernel is still WIP but we're nearing the point where various independent threads of development come together. And once Intel completes HDR support we'll be able to align support for other SoC/GPU types with the same work.

If you can boot another distro from CD do a manual install. Create two EXT4 partitions in a GPT scheme; 1GB labelled BOOT and remaining space labelled STORAGE. Install a bootloader; we use syslinux but GRUB works fine too. Copy the contents of our installer USB to the first partition (BOOT) and crib the bootloader config from syslinux.conf (or extlinux.conf) using BOOT=LABEL=BOOT and DISK=LABEL=STORAGE and then reboot the laptop. If you got the bootloader config correct it will boot.

You can probably use WeTek Play addons since they're based on the same 3.10 kernel codebase.

nadhim You post is (was) completely irrelevant to this thread. It has been deleted.

tune2fs -L STORAGE /dev/mmcblk0p2

^ run that and it should boot normally again

The ability to compile on the target is fine for distro's like Armbian where you're only ever recompiling the kernel or building a couple of esoteric packages you need for a specific use-case. LibreELEC has ~380 packages and requires approx. 20GB disk space and 6GB RAM minimum to compile an RPi image. An educated guess based on CPU alone is 48 hours to compile an RPi image on an overclocked 3B+ and maybe 36 hours on an RK3399 board. In comparison the 7yr old quad-core i7 chip in my MacBook takes 3.5 hours if sources are pre-cached. That level of time difference guarantees only masochists would ever use the capability (project staff never would). It's a moot point though, because the average 2GB RAM limit on most ARM boards ensures you'd never get a successful build. Some of the packages that come later in the build sequence like *lots* of RAM.

@5chatten @The_Coolest I have some openvfd package changes prepared for mainline that need to be tested on the older image - I've set a legacy image build running and will look this evening - then will PR if all is good.

See driver: add openvfd package · chewitt/LibreELEC.tv@248185c · GitHub

caveat: the editable nodes are the square boxes at the top of the RHS content view (actors, titles, etc.). Creating a new line of thumbnails similar to "in progress" requires core code changes, so that's not possible from node editing.

Quote from Kwiboo

Building LibreELEC is mainly done on x86_64 hosts and not on the target devices.

I also think some of the rkbin tools used to generate bootloader/u-boot blobs only exists for x86_64.

^ building LibreELEC is *only* done x86_64 hosts

@Ae3NerdGod .. either tone down your behaviour towards others (quit ranting) or you are banned. Final warning.

You can install the Library node editor addon from the Kodi repo and define a custom node. I'll warn you that it's not the most simple thing to figure out and the best place to ask for help with that is the Kodi forums (where its creator and others more familiar with it hang out).

Presence of something in GitHub means someone booted one once, it does not equal official support (which is a term we want to eliminate to avoid appearances of endorsement for specifc vendors). In the near future we need to rework all the boot stuff so there's a single image for each SOC type and not 10+ device specific images. I'll mention the request to one of the CI team but it might have to wait until we simplify things, so no promises.

Kodi moved archive support to an addon some time ago so you need to install the binary addon for "archive support" (zip) or "rar archive support" (rar) from the LibreELEC binary addon repo; assuming whoever created the C1 image provides a repo for the image (as we have never officially supported the C1 so there's nothing in our repo).