Posts by Forage

Great to hear, thanks guys.

I assume "Additional DVB drivers are not present" still goes for LE11 for the RPi builds as well? Not meant as a reproach, just something that would be good to know.

Quote from Microka

I'm disappointed it hasn't been resolved yet.

What effort have you made to get it closer to a resolution?

Quote from HiassofT

Forage that was the output of rpi-eeprom-update, not rpi-eeprom-config.

But as the output shows that your bootloader eeprom is up to date I'd say everything is fine on your side

Sorry, I misread:

LibreELEC:~ # rpi-eeprom-config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0

Yes, all is fine now because I manually updated the firmware. As mentioned above I'm not the only one who has the problem so it might be worth getting it fixed.

Quote from HiassofT

.Are you booting from USB? Please also post the output of rpi-eeprom-config, if self updates are disabled this would explain the issue when trying to update with USB boot.

The output of just rpi-eeprom-config is:

LibreELEC:~ # rpi-eeprom-update
BOOTLOADER: up to date
   CURRENT: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
    LATEST: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
   RELEASE: default (/usr/lib/kernel-overlays/base/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

I'm booting from a USB stick yes, should that make a difference?

Quote from frakkin64

The LE app only touches a file /storage/.rpi_flash_firmware with the contents of the switches selected, at reboot when this file exists LE starts a target for flashing firmware. However this only installs from the critical channel, so that's going to be the January 25th EEPROM you see with "rpi-eeprom-update". It sounds like that part is all working correctly, but perhaps the command run during the target has an issue, do you have a screen grab?

Maybe you can run this via ssh and see if there is any error? It will just stage the eeprom updates (same as rpi-eeprom-update -a):

USE_FLASHROM=0 /usr/bin/.rpi-eeprom-update.real -A bootloader -A vl805

You should see the same output as rpi-eeprom-update -a, and if you can check for the existence of the flag file /storage/.rpi_flash_firmware after toggling in the LE app the contents should have one or both of these set to yes:

BOOTLOADER=yes

VL805=yes

Display More

This is all working nicely yes. What I see during the reboot is exactly what I included in the previous post. So the "/storage/.rpi_flash_firmware" file is created when enabling the options in the settings and it does trigger "rpi-eeprom-update -a" to be run at boot. The text is shown, but the subsequent automatic reboot does nothing. So either "rpi-eeprom-update -a" is not able to stage the files in the "/flash" partition during boot, unlike when doing it manually, or the RPi has trouble dealing with the files during the automatic reboot.

There is no "/flash", not before nor after toggling the switch. Where should it be located exactly?

"rpi-eeprom-update -b" gives me "/boot", but nothing changes in that folder.

Oddly enough though "rpi-eeprom-update -l" gives me "/lib/firmware/raspberrypi/bootloader/default/pieeprom-2021-04-29.bin", not the expected "2022-01-25" version that shows in the settings. That version of the bin is nowhere to be found, not in critical, beta or stable. So it looks like it keeps staging the current version.

It would be good to confirm this if I know where the files are placed and if I can somehow capture the messages on the screen during boot.

EDIT

I double checked my build and the new files are included in the tar's SYSTEM file at "/usr/lib/kernel-overlays/base/lib/firmware/raspberrypi/bootloader/critical/", but not after flashing it in "/lib/firmware/raspberrypi/bootloader/critical/".

My gods, I feel like an idiot...the journal pointed out to me that I've been connecting to the wrong RPi...

I managed to take a photo of the messages after ten attempts. It's basically the same message as the output of performing "rpi-eeprom-update -a" manually.

*** INSTALLING EEPROM UPDATES ***

BOOTLOADER: update available
   CURRENT: Thu Apr 29 16:11:25 UTC 2021 (1619712685)
    LATEST: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
   RELEASE: default (/usr/lib/kernel-overlays/base/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1
   CURRENT: Thu Apr 29 16:11:25 UTC 2021 (1619712685)
    UPDATE: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
    BOOTFS: /flash

EEPROM updates pending. Please reboot to apply the update.
To cancel a pending update run "sudo rpi-eeprom-update -r".

The contents of the /flash partition does not change when toggling the setting. This message tells me that it actually happens when performing the reboot. But the subsequent reboot does not manage to actually perform the update.

Staging the update manually through ssh, followed by a reboot, does update the firmware. I've got the latest up and running now. But this means the update through the settings is broken somehow.

Please let me know if/how I can perform additional analysis to get this fixed for others.

Quote from frakkin64

Did you install the firmware? It's not automatic. You have to open the LE Settings app, go to firmware, and at the bottom there is 2 toggles to install the firmware on next reboot.

I usually just jump into ssh and run "rpi-eeprom-update -a" and reboot. LE is tracking the "critical" channel, not "stable" or "beta".

Yes, that is what i meant with "switching on the update setting". Than at boot it does show some firmware messages, but nothing gets applied.

Hi,

I made a 10.0.2 build for my RPi 4 yesterday which includes updated firmware for the device.

When switching on the update setting and rebooting the RPi LE does make an attempt to update the firmware, but after the boot finishes the old version is still present.

The messages during the logo display during boot are disappearing too fast to be able to read them. Same when shutting down for that matter.

I don't have the impression that any of the log share logs include those messages already.

What could be preventing the firmware from being updated and is there a way to log those boot/shutdown messages or pause the screen?

Unless you build your own: RE: DVB drivers for nightly build

Quote from CvH

I guess upstreaming (to the linux kernel) this patch is likely not doable ?

Doable yes I suppose, but I don't think that's up to me.

Like smp I simply took the required sources from GitHub - tbsdtv/linux_media: TBS linux open source drivers. It should be TBS upstreaming their work in that repository to the kernel, but for some raison they don't.

Quote from smp

Does it turn off then there is no signal from antenna?

Yeah, right away when I disconnect the cable. So all good I suppose. Maybe I can dig up some Tvheadend setting that can put the device in some suspend state when I'm not watching anything.

smp the patch works, thanks, I updated the patch in the initial post accordingly.

With the constant amount of light the green led is emitting I'm tempted to remove that bit again though

It only turns off very briefly when I stop watching a channel and than right back on again. Is this supposed to happen? The tuner is also constantly warm, or almost hot (as with LE 9), even when I'm not watching TV. Is this the case with your 5520SE as well?

Quote from polo_joe

Hi, could you please provide a test build, I have no build environment here.

Here you can find the build I'm using myself:

LibreELEC-RPi4.arm-10.0-devel-20210913174257-beaa0c7.img

It's based on 10.0 stable.

Do note that it contains one more patch for libcec, to revert commit #ef8bc8e to fix issue #326.

Quote from smp

I don't know if it works on 5580 but on 5520SE I enabled the green lock LED with this:

Diff

diff --git a/drivers/media/dvb-frontends/si2183.c b/drivers/media/dvb-frontends/si2183.c
index 4b5bc34..bbe3e96 100644
--- a/drivers/media/dvb-frontends/si2183.c
+++ b/drivers/media/dvb-frontends/si2183.c
@@ -1091,6 +1091,12 @@ static int si2183_init(struct dvb_frontend *fe)
       return ret;
    }
 
+    // set pins
+    memcpy(cmd.args, "\x12\x8\x0", 3);
+    cmd.wlen = 3;
+    cmd.rlen = 3;
+    si2183_cmd_execute(client, &cmd);
+
    dev->fw_loaded = true;
 warm:
    dev->active_fe |= (1 << fe->id);

Display More

Cheers, will give that a try. I didn't even notice the additional led until now

Due to the absence of the CrazyCat drivers for DVB devices like TBS's in LE10 for the Rapsberry Pi 4 for the time being one needs to add them manually by compiling LE.

Here's a patch for the TBS5580 : linux-tbs5580.patch.txt. It's heavily inspired by the patch for the TBS5520SE by smp as both devices are almost identical.

1. Rename the file to remove the ".txt"
2. Place the file in one of the following folders, depending on you preference

   
   

   • projects/RPi/devices/RPi4/patches/linux/
   • packages/linux/patches/raspberrypi/
3. Add CONFIG_DVB_USB_TBS5580=m after CONFIG_DVB_USB_TECHNISAT_USB2=m to one of the following files, depending on the arch for which you are building
   • projects/RPi/devices/RPi4/linux/linux.arm.conf
   • projects/RPi/devices/RPi4/linux/linux.aarch64.conf
4. Build your LE image

Enjoy.

Quote from sronayette

"DVB driver not present...". I am not sure what DVB is, but I have seen it somewhere... and I have a tuner card on my RPI4, and I am running TV headend server to watch TV. Does it mean I will not be able to do it with LE10.0?

It will probably not work in that case.

Quote from CvH

tx fixed

Not yet, the new graphic drivers interfere with the dvb drivers and its getting complicated very quick if we add them at this point.

Later LE versions (LE11) will likely include it again.

Thanks, bummer. With LE's current track record, two years from 8.0 to 9.0 and another two and a half years to 10.0, I'll be going back to 9.2 for the time being in that case.

LibreELEC (Matrix) 10.0.0 - LibreELEC

Quote

[...] settings in config.txt can longer be used to work around [...]

"can longer" > "can no longer" (...even though hdmi_mode and hdmi_group were still needed and work fine in my case)

Also, the dvb drivers are also missing in the RPi 4 build. It might be good to mention this in the article as well.

On that same subject, will they be added again in the near future?

Despite the GDPR, it should never have been enabled in the first place. It's a shame that sharing personal information with a third party without consent first requires a law to be stopped.