Posts by HarryH

HiassofT ,

thank you for the additional explanation to make the current state more clear.

Regards,

Harry

Hi Lotte,

nice, that you found a solution.

If you currently doesn‘t have a dtoverlay=hifiberry … line in your config it seems that the overlay was instead loaded from the HAT EEPROM. Please keep in mind, that in future kernel versions it could be possible that this overlay in the HAT EEPROM will be outdated. Then you will need a matching dtoverlay line for your hifiberry.

Regards,

Harry

Because of this:
Configuring Linux 4.x or higher | HiFiBerry
HiFiBerry sound cards on the Pi5 | HiFiBerry
Changes in HiFiBerry drivers | HiFiBerry

you should ensure that this line is commented out:
dtparam=audio=on
to
dtparam=audio=off or #dtparam=audio=on

I had read that this command
force_eeprom_read=0
is deprecated, you should instead move this 2 lines to the very beginning of the config.txt

dtoverlay=
dtoverlay=hifiberry-dacplushd

The first line prevents it from loading the overlay out of the HAT EEPROM (hifiberry).

I know that some users with RPi5 and a Argon ONE case use successful the hifiberry driver set with their new BLSTR DAC modules. But the driver for dacplushd could have his own bugs.

Okay, this looks like a little bit different constellation. If i'm right, then the remote you using relies on the default remote profiles. Or do you have added an "rc_map.cfg" or "lircd.conf" file manually in the past to get it work?
You can check if one of these files exists in the "/storage/.config" folder.

Hint: Instead of a restore the complete configuration, in your case it would be enough to delete the rc_maps.cfg in /storage/.config. Just for completeness also delete the remaining "/storage/.config/rc_keymaps/argon40.toml".

In this case, I already had on my to-do list to find a working merge solution.

The Addon can't backup files, which are not exists during installation or after the settings menu was closed with OK.
Please be aware: The known switch object in the Addon settings menu isn't able to trigger directly an action! This could be create a gap in your idea and needs additional handling. For example if someone will change/add his own files, after the plugin was installed and is already running. Such edge cases must be taken into account.

I would prefer the way, to add the Argon IR remote to the existing list for coexistence, if that possible. But this depends on how the custom remotes were added.

Like I wrote before, the Addon (depending on the version) currently add only files to the ".config" directory like rc_maps.cfg and lircd.conf. This are 2 different ways to add a custom remote, but the resulting behavior is different.

Please can you provide more details, which file(s) you have restored, to make your remote control working again?

Quote from Reddirt

I had no idea the order in which devices were powered might be an issue. If I understand correctly the RPi5 system will record all necessary EDID info on it's 1st run and save in a permanent file for future boots?

No, it‘s not saved automatically. The command „getedit create“ is the manual process for that, and „getedit delete“ the counterpart.

Explanation:

Since some LE versions, its more important that:

1. the EDID informations are available
2. the EDID information must be correct

Normally the HDMI handshake should be initialized during boot of the RPi. This happens dynamically with every boot process. At this time it‘s important that the HDMI chain is working and not disturbed. Disturbing is possible with bad manufactured/not certified HDMI cables, Micro-HDMI adapter, other HDMI devices …

For example you should ensure, that you switch on the RPi as the last one if your cabling looks like this:
RPi5 -> AVR -> TV

The ideal sequential order to power-on is that:

1. TV (provides EDID data for screen size/frequencies + supported sound channels/formats)
2. AVR (passthrough and/or provides additional EDID data)
3. RPi5

If the AVR is powered-off, the RPi5 can‘t get the EDID information. Some newer AVRs are able to passthrough the EDID information if they are in standby. But there also exists TV, that only provide this information if the TV is switched on.

To get a more robust system against the different power-on scenarios, it‘s possible to grab the EDID data one-time and save it in to the file system with the „getedit create“ command. After that the kernel/KODI will use this saved information at the next boot instead of the dynamical available EDID information. But this implies, that this file must match to your current hardware constellation. On this way it also possible to fake some information, if the extracted EDID block is incomplete or something like that.
If you afterwards make some (conflicting to the EDID file) changes on your hardware/device firmware, then you must update or delete the EDID file again.

Quote from ApexDE

Yes, that was my first test: Fan always on. And it didn't work so i thought the addon in general doesn't work.

I wished, that such issues are reported here, and not silently switched back to an old version. Like the issue above, sometimes I detect that randomly only. And so long I believing all things are fine.

Quote

Can you built in a switch for the Argon remote and the others so it doesn't break the other remotes when installing the plugin without the lock file? I believe one should actively choose to use the Argon remote instead of the formerly used one. You could backupcopy the previously used remote files also?

It's not so easy like it sounds. In my opinion the best way would be, if a dialog were opened during the installation process if a existing configuration has been detected. But it seems that it's currently not supported by KODI for Addons, or I doesn't know the way for.

Because I wanted to force the migration to the modern way with ir-keytables, it was needed to delete the old lircd.conf, which was provided by the version < 0.0.10. Default this file doesn't exist in LE.
I don't have a statistic, which way (lircd vs. keymaps) the most users using with their own remote control configuration, and therefore I'm been unsure which files I should check to make this process bullet proof.

As a simple solution I thought about in the past, to add a switch to create/delete the lock file from menu. But this will not prevent, that your configuration will be overwritten during the first installation of the Addon. To prevent this, I must set the remote control file copy process default to off. It needs a restart of KODI to reload the remote config, as far as I know. But there are also users with the origin Argon IR remote, they need the configuration file from the Addon and may expect that the remote work out of the box, after the Addon is installed successful.

That's the conflict I'm in.

Quote from ApexDE

Why isn't the plugin in the LibreElec repository?

I doesn't have a automatic build process ready and I honestly currently don't know what's all required to make it part of a LE repo.
May be I must extent my test scenarios first, to prevent that I publish a buggy version.

For example, this week I stumbled over the regression, that in version 0.0.13 I introduced throwing of a exception with setting "Fan always on" is enabled. If this setting is set to enabled, the fan isn't running. I thought I have tested, but it seems I didn't.
Version 0.0.12a shouldn't affected by this. And as temporary workaround with version 0.0.13, you can lower the threshold to get the fan running all the time.

Such things shouldn't happend with a Addon in a official repo...

Hi ApexDE ,

like mentioned at multiple places like the change message for 0.0.10 and "Breaking change" in the middle of the post #25 .
You can prevent the Addon from overwriting your remote control settings, if you drop a empty file with the name "argon40_rc.lock" in the ".config" folder.

touch /storage/.config/argon40_rc.lock

There is a undervoltage message remaining in your logical-ape.log:

Quote

Code

Feb 16 23:40:57.414554 LibreELEC kernel: hwmon hwmon0: Undervoltage detected

Which kind of power supply do you use? Do you have a model or part number?

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#power-supply-warnings
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#power-supply

Hi Ajay,

Maybe you just overlooked it. If you are not familiar with technical abbreviation like PSU, please ask.
Da Flex already provided the solution. If you ignore that, you shouldn’t expect additional support.

Quote

Thanks for the log. Replace your PSU

Your Pi doesn‘t get enough energy. The power supply that you currently use seems undersized or defective. That will also trigger other unexpected issues, and could be the reason for the WiFi issues too. So the only solution is to replace the power supply first.

Thank you for that useful information.

I have added the version comments to better show, if something has been changed.

It’s not impossible, but I currently doesn‘t know about changes in the images, which are related to these scripts.
If it‘s working now, I‘m happy and will not touch the scripts. Perhaps only to add some version comments and replacing the deprecated usleep command, no functional change.

For documentation purposes, please can you provide the following informations?

• config.txt
  cat /flash/config.txt
• kernel log
  dmesg | grep -i uart
• ls -la /dev/ttyAMA*
• pinctrl -p get
• Do you know which version of the RemotePi do you have? I read about, that the pcb has a current limiter to prevent damages at RPi pcb. But this can also restrict the current to much for your RPi5 and you are get in trouble, because not enough power.

Do we talk about the same thing? I meant, that I have updated the scripts inside of the 2 codeblocks in Post #17

Quote

I don’t know if it’s due to the board but when I connect the power to the board the pi5 shutdown just after start

Do you have this strange behavior only since you tried the pinctrl version? Have you updated to the current version?

The GPIO15 seems to me to be the more important signal for shutting down. It may be triggered the MCU on the RemotePi pcb before the irwitch.sh script was started. These 2 pins (GPIO14/15) are part of UART0. Depending on your bootloader/EEPROM settings and config.txt, conflicts can occur. But this conflict should also exist if you have not installed the script. Can you check without the scripts, if the shutdown also is initiated automatically?

This information would be important for me to know.

The original intention was, that you repeat this for every gpiochip.

• gpiochip512

  Code

  cat /sys/class/gpio/gpiochip512/ngpio
  cat /sys/class/gpio/gpiochip512/label

• gpiochip544

  Code

  cat /sys/class/gpio/gpiochip544/ngpio
  cat /sys/class/gpio/gpiochip544/label

• gpiochip548

  Code

  cat /sys/class/gpio/gpiochip548/ngpio
  cat /sys/class/gpio/gpiochip548/label

• gpiochip565

  Code

  cat /sys/class/gpio/gpiochip565/ngpio
  cat /sys/class/gpio/gpiochip565/label

• gpiochip571

  Code

  cat /sys/class/gpio/gpiochip571/ngpio
  cat /sys/class/gpio/gpiochip571/label

But I think, that I know the answer. You can check the gpiochip571 and you should get "54" for ngpio and "pinctrl-rp1" for label as the return values.

Quote

I have to do more tests when I get home, but it seems to be ok
Thanks a lot

Have you had time to test more? Are there any problems or is it working?

I was afraid that the pin number was to generic and could be used at the wrong pin. So I have changed the pinctrl script version some minutes ago. Please check the new version.

By the way, I think gpiochip571 should be the correct one for RPi5 with the label "pinctrl-rp1".

GPIOpin=586
GPIOpin1=585

Quote from mokkurkalve

Unfortunately, it did not help. Should I comment out "force_turbo=1" also?

Generated a logfile with that setup, too:

https://paste.libreelec.tv/driven-macaque.log

Edit: As I'am was writing HiassofT posted a possible solution. Please try his image first.

Only for completeness:

If you comment out the line, you can't make wrong. It's not default in LibreELEC. For troubleshooting purposes you can also comment out this line

hdmi_enable_4kp60=1

The first line forces that the ARM cores not going back to a lower frequency and stuck at the highest allowed clock rate. hdmi_enable_4kp60 forces the gpu_clock to 550MHz instead of 500MHz.

If you doesn't depends on Bluetooth for keyboard/headphones or something like that, can you check with this line added ?:
dtoverlay=disable-bt