Posts by LuRu

    1. mount -o remount, rw / flash

    2. I copy the file sun50i-h6-spi-spidev1.dtbo to the directory /flash/overlays

    3. I edit the file /flash/extlinux/extlinux.conf and in the line FDTOVERLAYS I add the parameter /overlays/sun50i-h6-spi-spidev1.dtbo

    4. mount -o remount, ro / flash

    5. reboot

    Note:

    My extlinux.conf file looks like this:

    Code
    LABEL LibreELEC
    LINUX / KERNEL
    FDT /sun50i-h6-orangepi-3.dtb
    FDTOVERLAYS /overlays/sun50i-h6-i2c0.dtbo /overlays/sun50i-h6-spi-spidev1.dtbo
    APPEND boot = UUID = 0908-1419 disk = UUID = 8cd4f88f-17df-48ce-bec6-cca1eb844534 quiet console = ttyS0,115200 console = tty1

    sun50i-h6-spi-spidev1.dtbo.zip

    Above all - thank you for your patience with me.

    In the meantime, I tried a modified overlay (with the string "dh, dhcom-board") on H6. But unfortunately, without success. So CONFIG_SPI_SPIDEV is probably not the only problem.

    Note:

    1) If I do image bulding myself, can I create an image (where CONFIG_SPI_SPIDEV will be allowed) for H3 as well?

    2) In the future - is it possible to enable CONFIG_SPI_SPIDEV for H3 in the official version? It's a pretty common thing to connect a display to Kodi, so why can't it be with a spi interface?

    Not everyone will be able to build a WiFi version.

    Not sure what problem you see with compatibles - all 5.10 versions I checked have same compatible array.

    I did not say the opposite. I probably wrote it somehow confused, I'm sorry.

    So once again. I used the string "ge, achc" as the first attempt and it didn't work (in LibreELEC). I wanted to verify that it works at least in Armbian. But it didn't work. That's why I looked at what Linux is in Armbian. There is 5.15.43. So I looked in the appropriate spidev.c file and there I found that the compatible array does not contain the string "ge, achc". So I used the string "dh, dhcom-board", which is found in both versions. Then I tried it in both Armbian and LibreELEC. It worked in Armbian, it didn't work in LibreELEC.

    I just noticed that CONFIG_SPI_SPIDEV is not even enabled for 32-bit AW SoCs, but it is for 64-bit. So it should work on H6, but not on H3.

    How do I understand that? This means that for H3 there is no chance for it to work in LibreELEC (in Armbian it works!).

    I'll try to see if it really works at least on H6.

    Thank you very much for your answer. I hope we are going in the right direction, but unfortunately, I still don't have a /dev/spidevX.X device.

    I fixed the overlay - see the attachment, but the result is none. I tried to use the same file in Armbian and it works there.

    Can you please think about what else needs to be done?

    Note:

    As a first attempt, I used the string "ge, achc", but it didn't work in Armbian either. I immediately found out why. I have in Armbian 5.15.43 Linux version and there are compatible strings a little different - "ge, achc" is not there. So I used "dh, dhcom-board" and it is in both version 5.10.76 (my LibreELEC) and version 5.15.43.

    Then it started working in Armbian, but not in LibreELEC.


    Edit:

    I noticed that Linux 5.10.X lacks (as opposed to Linux 5.15.43) the following structure:

    Could it be the problem?


    sun8i-h3-spi-spidev0.dts.zip

    I intend to add support for displays with the spi interface to my OLEDproc add-on.

    I've spent many hours on failed attempts, and now I really don't know what to do next.

    I work with Orange Pi 3 (H6) and Orange Pi PC (H3) boards. Unfortunately, I was not successful with any of them. No /dev/spidevX.X interface appears (I use the ls /dev/sp* command to check).

    At first I tried it with Armbian and I was successful there. I then copied the overlay files (which it worked with in Armbian) to LibreELEC,

    but in LibreELEC these files do not work. There is probably something else here, but I can't find it. Can you help me please ?

    Note:

    1. I'm working on version 10.0.2

    2. In Armbian I used these overlay files: overlays.zip

    I just received an ordered display so I can start working on it. But it is already clear that it will be a little more complicated than I expected. As for the display with the SSD1322 chip, I would do that anyway - all SPI displays that are supported by the luma.oled library should be added.

    I hope it works out.

    Thanks for trying, so far I have very little feedback. I have (since June 6) ordered the same display. The only difference is that the connection terminals are on the shorter side of the display. When I get it, I will try to solve the SPI interface in the add-on.

    I just published a new project esp-OLEDproc - remote OLED display for Kodi media center.

    I didn't make any pictures, but if you look in the OLEDproc add-on, it looks almost the same.

    I think it's a pretty revolutionary thing - connecting a display to Kodi has probably never been easier.

    To try it out, follow these steps:

    1. Get some module with ESP8266 (preferably about Wemos D1 mini) and some OLED display 128x64 (preferably with chip SSD1306). At Aliexpress, both together (1.3-inch display) can be purchased for less than $ 6 (including postage).

    2. Connect both modules and upload the firmware to the ESP8266.

    3. After switching on, a new SSID will appear in the network menu - something like esp-oledproc-xxxxxx. Connect to it and type 192.168.4.1 in the address bar of the browser.

    4. A page will appear asking for a password - enter admin. Go to the Network settings menu.

    5. Press the Scan button. In the found networks, select the one in which your Kodi is located and fill in the IP address and other necessary parameters. Confirm by clicking the Save button and the yellow bar "You have uncommited changes ...".

    6. A summary of parameters appears. After checking it, press the "Save & Reboot" button.

    7. After the restart, the device should already connect to your network. If you have not disabled the clock display (in Display Settings), there should be a clock on the display (sometimes another restart requires it - eg by switching it off and on).

    8. Install the XBMC LCDproc add-on in Kodi. However, it must be a modified version to support UTF-8. You can download it from the GitHub above.

    9. In the option settings, turn on "Use remote LCDproc" and fill in the same address as in point 5.

    10. On the Behaviour tab, turn on "Use alternate charset" and select UTF-8 encoding.

    That's all, it should work. I remind you that the XBMC LCDproc add-on (what is actually to be displayed) is configured using the LCD.xml file. However, you will find this in the relevant documentation.

    Maybe someone will be interested, I've been working on it for tens of hours.

    Thank you for your response, but I need clarification. Which GitHub repository specifically do you mean? I'm not sure I understand well (unfortunately my English is terrible, but at my age it won't get any better).

    Do you mean any of my own repositories or do you mean the LibreELEC repository or some completely different one?

    Note:

    I created a PR for GitHub repository herrnst/script.xbmc.lcdproc, where I summarized the changes needed to add UTF-8 encoding support.

    I also created a PR for GitHub repository rm-hull/luma.oled, where I added support for displays with the SH1107 chip.

    I just finished one little project. The work took me several weeks, but I believe it was worth it.

    There are many OLED graphic displays on the market that are cheaper and look better than traditional (character) LCD displays.

    I was sorry that so far these displays could not be used as a display for the Kodi multimedia center.

    That is why I set myself the task of remedying this shortcoming. I am presenting the result of my work to you today.

    The core of the solution is a new add-on called OLEDproc. As the name suggests, it is similar to the LCDproc add-on (which is used to control LCD character displays).

    It is therefore clear that the OLEDproc add-on also needs the XBMC LCDproc add-on (which is the data source) for its work.

    However, the XBMC LCDproc add-on needs one small modification to work properly with OLEDproc - adding UTF-8 encoding support.

    The modified add-on is part of the attached SW package. At the same time, I asked the author of the add-on to include the modifications in the repository version. However, the author has not yet responded.

    OLEDproc also depends on script.module.luma, script.module.smbus2, and script.module.cbor2.

    I also created these add-ons and they are also part of the attached SW package.

    In the current version, OLEDproc only supports I2C displays. It may not be difficult to support SPI displays. However, I do not have any at my disposal.

    I tried the add-on with LibreELEC 10.0.2.

    I tried two SBCs: RPi4B (4GB) and Orange Pi PC (1GB). The tests were successful on both SBCs, the add-on worked as expected.

    I tried two displays:

    One with the SH1106 chip (I can't give a specific link, the seller no longer offers the product)

    and one with SH1107 chip (eg https://www.aliexpress.com/item/4000547865501.html).

    In the case of RPi4B, the I2C interface must be enabled by adding rows

    Code
    dtparam=i2c1=on
    dtparam=i2c_arm=on

    to the config.txt file.

    In the case of OPi PC, the file sun8i-h3-i2c0.dtbo should be stored in the /overlays directory and the line FDTOVERLAYS /overlays/sun8i-h3-i2c0.dtbo should be added to the extlinux.conf file.

    I'm hoping someone will be interested.

    SW package

    For several days now I have been trying in vain to compile LibreELEC for Allwinner H6.

    I use commands:

    Code
    git checkout libreelec-10.0
    PROJECT=Allwinner ARCH=arm DEVICE=H6 make image

    Compilation always ends with an error:

    Am I doing something wrong?

    After a few days of daily use, I can confirm the previous conclusions.

    There are no system freezes. Only occasionally Kodi crashes (LibreELEC lives during the crash - it responds to a ping) and this happens always and only during IPTV playback. First the image stops and after a few seconds Kodi restarts.

    The significant factor is definitely the CPU regulator voltage range and not the wifi power supply.

    I made two new versions:

    V2 is without changing the CPU regulator voltage range and

    V3, on the other hand, contains only a change in the CPU regulator voltage range.

    First I tried V2. It ran for about half an hour and there was a system freeze.

    Then I used the V3 version. So far, it runs smoothly for about 2 hours. This looks promising, but we'll see in two or three days.

    Here is the contents of the V3 patch: