Posts by HiassofT

    Changing /flash/config.txt entries on RPi is rather safe. Even if you completely mess it up and have a non-booting RPi you can simply put the card in a reader on your PC, clean it up, and have a working setup again.

    If you want to hook up a DAC, GPIO IR receiver and an LCD the bigger problem is that most HATs on RPi don't give you easy access to the unused GPIOs (and sometimes you even don't know which ones are unused). So that typically involves soldering some wires to the GPIO pins on the HAT or RPi.

    I'm regularly using a sound card (the Cirrus Logic Audio Card) and a GPIO IR receiver on RPi. Fortunately the sound card brings out the unused GPIOs to a separate header block.

    A few days ago I tested with a HD44780 compatible VFD, connected via a I2C expander but the I2C pins aren't grought out separately on the card. I added a 40-pin header to the soundcard in my testing setup some time ago (to easily access all signals) so getting to the I2C pins was easy. Without the header I would have needed to solder 5 wires to the pins.

    Changing config.txt was easy though, I2C was already enabled via the sound card overlay, otherwise a simple "dtparam=i2c=on" line would have done it.

    So, don't be afraid of config.txt, most of the changes are simple and hard to mess up.

    so long,

    Hias

    warp2 no problem at all and I certainly don't take it as an insult.

    Actually some of the design decision of OE/LE, like the read-only rootfs without overlayfs and the lack of a package manager, seemed and partly still seem a bit odd to me.

    But I also have to say the approach makes sense for what LE is meant to be - an OS for running kodi that is simple to use for users.

    We use kodi's addon system instead of a separate package manager - that makes it simple for users to install additional stuff, as they only have to deal with a single UI (kodi) and we don't need to add a package manager ourselves and write a GUI for it.

    The root filesystem being read only also means that chances of users messing up the whole system (whoops, I accidentally replaced/deleted libc) are slim. Users can't easily shoot themselves in the foot and we have less support issues.

    OTOH we developers often have to jump through hoops as well to work with the current setup.

    Last year I implemented support for optional kernel module packages (mainly used for DVB drivers) and the lack of overlayfs support (Amlogic kernel is too old and doesn't include that) or a package manager (kodi's addon/dependency system is rather simple) meant we had to put a lot of thought into how we could practically use that. It also involved quite a lot of discussion and design decision as the goal was to have something that's both easy to use for users and support for us devs.

    As we don't have plans (and the resources) to drastically change the OS design of LE it's best you familiarize yourself with the possibilites how you can adapt LE to your needs:

    1. Some things may already be supported and you just need to find/change the right config file
    2. You can create an addon if you want some additional programs / services / ... added to LE
    3. Using docker is an alternative to #2
    4. If none of the above works for you you'll have to adapt the LE source code and build your own version

    so long,

    Hias

    ssh root@libreelec will log you in as full root user. But keep in mind that the root filesystem (/etc, /usr ...) is read-only and can't be changed. /flash is mounted read-only as well, but you can modify the files there after you remount it rw.

    so long,

    Hias

    There's nothing you need to configure, this remote is supported out of the box in LE. Just tested that on RPi3 running LE 8.2.2.

    Keep in mind though that the IR receiver only works with the remote it came with. When you press a button on the remote both the LEDs on the remote and on the IR receiver dongle should flash.

    so long,

    Hias

    i have also problems with lirc. For several version, (last was LE 8.02 with Kodi Krypton 17.3) i have only added "dtoverlay=lirc-rpi" to config.txt and it works "out of the box"on my Raspberry PI3. Now i have installed LE 8.22 and remote doesnt anything...

    Use dtoverlay=gpio-ir instead of dtoverlay=lirc-rpi. Also read the wiki page for details about this.

    so long,

    Hias

    i type ir-keytable, find protocols don't enable,but i don't how to fix it.

    Code
    LibreELEC:~ # ir-keytable
    Found /sys/class/rc/rc0/ (/dev/input/event0) with:        
    Driver sunxi-ir, table rc-empty 
    Supported protocols: rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp        
    Enabled protocols:        
    Name: sunxi-ir        bus: 25, vendor/product: 0001:0001, version: 0x0100        Repeat delay = 500 ms, repeat period = 125 ms

    The sunxi-ir driver doesn't support the raw "lirc" protocol - it's missing in the list of "Supported protocols". This means you can't use lircd, you have to use ir-keytable.

    I suggest you switch to a current LibreELEC version and then follow the guiide in the wiki: infrared_remotes [LibreELEC]


    so long,

    Hias

    Kodi / LibreELEC on RPi doesn't use the vc4 drm driver, AFAIK it uses the (downstream) bcm2708 framebuffer driver and the (also downstream) video core shared memory driver (vcsm) to interface to the GPU.

    Could well be that other downstream drivers are involved, but I leave this to popcornmix to answer, he's the expert in this area, my knowledge about RPi graphics stuff is quite limited.

    so long,

    Hias

    mchehab I managed to get LibreELEC 8.2.2 with upstream 4.14.13 booting on RPi3. The process is a bit tricky/hacky and Kodi won't start - not sure if LibreELEC's Kodi can work at all on upstream kernel, could well be that the graphics layer relies on some downstream kernel changes. popcornmix should be able to tell more.

    The official way to use a different kernel in LE is to fully rebuild it from source, but this shortcut could be enough for a few quick tests:

    I've done this by starting with a plain LE 8.2.2 installation on sdcard - it'd probably be best if you follow the same route, then you can enable ssh and install tvheadend from Kodi. Even if kodi won't work with upstream kernel tvheadend should run and you can test it over the net.

    LE uses an initrd to mount the read-only rootfs (that's the SYSTEM) file on the FAT partition. It's compresses with LZ4 so you'll also need to enable LZ4 squashfs support in the kernel.

    I used this (hacky) script to extract the initramfs from the kernel image (KERNEL file on FAT partition):

    I started that with "./extract-initramfs KERNEL initrd-8.2.2" and copied the initrd-8.2.2 file to the root of the FAT partition. Fortunately there are no kernel modules in the initramfs, so we don't need to change that.

    I then compiled a 32bit (ARCH="arm") upstream kernel using multi_v7_defconfig. I patched the the rpi3 DT so I could use PL011 as serial console and manually enabled CONFIG_SQUASHFS_LZ4. Then I copied zImage and the bcm283*.dtb files to a "upstream" directory on the FAT partition.

    To get the upstream kernel booting I used these additional settings in config.txt - the initramfs entry brings in the previously extracted initrd

    Code
    [PI3]
    kernel=upstream/zImage
    device_tree=upstream/bcm2837-rpi-3-b.dtb
    avoid_warnings=2
    initramfs initrd-8.2.2

    and this cmdline.txt:

    Code
    boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 ssh root=/dev/ram0 console=ttyAMA0,115200 earlycon=pl011,mmio32,0x3f201000

    This is enough to get LE booting, but the initramfs will complain loudly because it doesn't find matching kernel modules in the rootfs (SYSTEM file) - after a minute it will continue booting up, but of course without modules it's a bit meh.

    So I simply installed the modules to a temp directory on my PC, unsquashed the SYSTEM in a fakeroot, copied the modules into the unsquashed rootfs and then ran mksquashfs

    Code
    cd ~/upstream-kernel
    mkdir /tmp/modules
    INSTALL_MOD_PATH=/tmp/modules make modules_install
    cd ~/le-test
    fakeroot
    unsquashfs SYSTEM
    cp -r /tmp/modules/lib/modules/4.14.13-dirty squashfs-root/usr/lib/modules/
    mksquashfs squashfs-root SYSTEM-4.14 -comp lz4

    Then I copied that SYSTEM-4.14 file to the root of the FAT partition, naming it SYSTEM. LE then booted up fine and could load at least some modules.

    Hope I didn't miss an important step, if you have problems or questions just ping me.

    so long,

    Hias

    smp have you tested if you get the same results if recording to a USB HDD instead of sdcard?

    I also noticed that for some unknown reason the LE RPi kernels use the NOOP IO scheduler by default, x86 LE kernel and RPi foundation kernels use the CFQ scheduler.

    You could also try changing the IO scheduler, this can be configured per device. eg:

    Code
    echo cfq > /sys/block/sda/queue/scheduler

    so long,

    Hias

    You seem to have some leftover cruft (in autostart.sh?) where you kill lircd, load the lirc_rpi module and then start lircd with the wrong options. Remove that alltogether.

    Code
    Dec 15 19:37:59 Familyroom sh[382]: mkdir: can't create directory '/var/run/lirc': File exists
    Dec 15 19:37:59 Familyroom sh[382]: killall: lircd: no process killed
    Dec 15 19:37:59 Familyroom kernel: lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
    Dec 15 19:37:59 Familyroom kernel: lirc_rpi: gpio chip not found!
    ...
    Dec 15 19:37:59 Familyroom lircd-0.9.4d[395]: Info: Initial device: /dev/lirc0
    Dec 15 19:37:59 Familyroom lircd-0.9.4d[395]: Notice: 'lirc' written to protocols file /sys/class/rc/rc0/protocols
    Dec 15 19:37:59 Familyroom lircd-0.9.4d[395]: Warning: --uinput is deprecated, check the lircd manpage.

    To get your hauppauge remote working it's probably enough to add the rc-map-name parameter to the dtoverlay line:

    Code
    dtoverlay=gpio-ir,rc-map-name=rc-hauppauge

    An alternative to that is to configure the keymap via /storage/.config/rc_maps.cfg

    Code
    * * hauppauge

    so long,

    Hias

    Lexridge the question in this thread was about an MCE remote on x64, where in-kernel decoding is used, and having Lirc enabled in addition to that will often cause double keypresses.

    You, however, seem to be using a GPIO remote on RPi using the lirc-rpi dtoverlay, which is something completely different.

    I'm not exactly sure what problem you are experiencing. There were no changes between 8.2.1 and 8.2.2 in that area and the dmesg lines you posted should be there both with 8.2.1 and 8.2.2 if you have the "dtoverlay=lirc-rpi" line in config.txt.

    Anyways, if you are using lirc-rpi it's best to switch to gpio-ir and disable Lirc in LE settings. lirc-rpi will be dropped in LE9, gpio-ir is the more modern successor (which doesn't need lircd to work, decoding is performed in the kernel). Read the wiki for details: infrared_remotes [LibreELEC]

    so long,

    Hias