[RPi4B] Argon One Case Shutdown

    There are no objections to it being submitted to the LE repo. The alternative will be to create an "argon40" repo for the add-on (ab)using GitHub free hosting and then have people install the add-on from that repo. The LE repo is easier for users since there's nothing extra to install, but an independent argon40 repo will probably be easier for the maintainer as fixes can be pushed on their own schedule. If there's any intent to support install on RaspiOS too, the independent repo is the right direction.

    Currently I have no plans to support RaspiOS too. There are many reasons that speak against it:

    • with a normal OS the fan control should be enabled system-wide, power button too
    • system-wide solutions are already available: argon1.sh, Argon One Daemon …
    • no spare system to test
    • available time
    • …
    Quote from HarryH

    Currently I have no plans to support RaspiOS too. There are many reasons that speak against it:

    • with a normal OS the fan control should be enabled system-wide, power button too
    • system-wide solutions are already available: argon1.sh, Argon One Daemon …
    • no spare system to test
    • available time
    • …

    True. It's a LE addon. stop.

    And surly no time for other projects is true too.

    If it would be easy and doesn't take so much time to do, just push up the zip in the LE repo would be good for everyone . But I understand you if this is too complicated.

    hello HarryH , i finally made the jump to a Raspi5 and your plugin is working fine on the Argon40 V3 case with M2-NVMe extensionboard too :)

    speaking of NVMe: i am currently using the Raspi5 with a SD-Card. I plan to upgrade to a NVMe SSD. Do you know how what i need to add to config.txt to make it boot from the SSD? The argon scripts don't run on LibreElec i suppose?

    With the official 27W PSU, a current bootloader (>= 2024-02-16) in your RPi5 and 100% compatible NVMe you don't need to change anything, because the autodetection should work and tells the kernel all things regarding the PCIe.

    Since the Argon ONE V3 does not support the PD handshake internally, these settings are necessary to provide enough power and add the NVMe as a boot device:

    If all things work fine and after some days without errors in the kernel log, you could force the PCIe to Gen 3 if you want speed up. But this is alltime out of the current certification for the RPi5 and should observed as a kind of overclocking. Some kind of NVMe seems to need this to (maybe a firmware bug ?):

    • config.txt

      Code
      dtparam=pciex1_gen=3

    Edited 2 times, last by HarryH (June 3, 2024 at 6:01 PM).

    Thanks for the infos HarryH

    so, if i add a NVMe SSD to the Argon case it will be booted by default? (over the microSD being in place?)

    Maybe you built in a option in your addon to check if these settings are active or even to change the boot order in the addon?

    Edited 2 times, last by ApexDE (June 2, 2024 at 3:01 PM).

    Quote from ApexDE

    so, if i add a NVMe SSD to the Argon case it will be booted by default? (over the microSD being in place?)

    I can't answer that with certainty. I don't have a RPi5 myself. But I know that many things have changed in the bootloader and to many users fiddling with outdated parameters. Therefore my recommendation is to start with the only needed settings.

    Because some weeks ago the official M.2 HAT+ (incl. specification) was published and advertised to automatically add the NVMe as boot device if detected, I'm expect that booting from NVMe is now also possible via default. Maybe this works with HAT+ only, and therefore not with the Argon ONE V3.
    However, to persist the boot order like you want, I would prefer to set it via EEPROM.
    EDIT: The advertisement was misleading, the official M.2 HAT+ requires too, to set the boot order in EEPROM like I described above.

    If you need additional settings like PCIE_PROBE=1 or dtparam=pciex1 / dtparam=nvme to get it detected, then it indicates your bootloader is very outdated or your chosen NVMe not compatible.

    Edited 2 times, last by HarryH (June 3, 2024 at 5:51 PM).

    Quote from ApexDE

    hello HarryH , i finally made the jump to a Raspi5 and your plugin is working fine on the Argon40 V3 case with M2-NVMe extensionboard too :)

    I am curious. Did you get Argon's remote control? If so, have you tried the on/off function with your new Pi5?

    Quote from ApexDE

    hello HarryH , i finally made the jump to a Raspi5 and your plugin is working fine on the Argon40 V3 case with M2-NVMe extensionboard too :)

    Does this case have any LEDs that you find annoying?

    Edited once, last by WarpLover: Merged a post created by WarpLover into this post. (June 2, 2024 at 8:09 PM).

    WarpLover

    no, i don't have or use a argon remote.

    The case has ONE green led which lights up when powered on and flashes on sd-card access. I first thought it would annoy me but it turned out that it does not ;) it doesn't shine very light in a dark room, so it is ok for me.

    Hello this is nice work, thank you.

    I have a question however as I'm seeing intermittent problems with shutdown. Maybe I missed some important part on the shutdown and red LED discussion.

    I have an RPI4 with a Argon v2 m2.sata case and I'm using the Argon remote with LE12 booting/running from sata ssd.

    Good case: When I press the remote's power button it brings up Kodi's shutdown/reboot dialog but the shutdown proceeds without dialog confirmation needed. After the tv screen going dark (CEC) the red LED stays on for a few seconds then blinks a few times then turns off. The RPI4 is shut down and can be turned back with the remote power button.

    Bad case: When I press the remote's power button it brings up Kodi's shutdown/reboot dialog and the shutdown does NOT proceed on its own from here. I need to confirm 'Power off system' (OK) with the remote and Kodi will now shut down. After the tv screen going dark (CEC) the red LED will stay on forever and the RPI4 cannot be turned back on with the remote. Also the RPI4 will not react to the power button at the back. I will need to make the device powerless pulling the power supply cable.

    With me this happens intermittently but frequently. I say about 80% good case vs 20% bad case. I have so far not found any hint why the bad case happens.

    Any ideas what log files I should be looking at or what debug settings I should turn on?

    thx R

    The bad case matches to: „Known Issues“ and „Workaround after improperly shutdown“

    GitHub - HungerHa/libreelec_package_argonforty-device: ArgonForty Device Configuration Add-On for LibreELEC
    ArgonForty Device Configuration Add-On for LibreELEC - HungerHa/libreelec_package_argonforty-device
    github.com

    Because the remote control sends „KEY_POWER“ command, sometimes this key is passthrough fast enough, to open the power menu of KODI, before the background service signals the KODI shutdown. But the shutdown should already initiated. KODI 21 takes time…

    If without your confirmation, the system doesn‘t shutdown hard (power cut) after 10+ seconds, then it‘s a „new“ behavior of the MCU firmware to me.

    Do you have the SD card removed? I‘m asking to exclude that the system sometimes was accidentally booted from SD card with the settings/add-ons from there.

    If you enable debug logging you should find Argon40 messages in the kodi.log (kodi.old.log after next boot). If you find an exception message instead of the Argon40 debug messages there, then possibly an bug exists.

    Edited 2 times, last by HarryH (July 29, 2024 at 1:28 PM).

    This is whats confusing me. The symptoms described under known issue is nothing like what I am experiencing.

    Whats described in the known issue is the board powerdown outracing the Kodi shutdown leaving potential inconsistencies - I don't know maybe uncommitted db transactions or maybe filesystems not unmounted cleanly or whatever. But in my bad case Kodi and LE arent shutting down at all using the hardware trigger. I have to use the soft shutdown from Kodi.

    So I think yes its a 'new behaviour'.

    I can’t imagine that the firmware has been corrected by Argon40. Also the shutdown should work, after you has confirmed via power menu. If there is no power cut after you triggered the shutdown via remote control, could also be an indication that the MCU is stuck.

    I know such behavior if there was send some (un)specific I2C messages for example with i2cdump command to the MCU before. If the MCU is stuck, mostly the fan runs permanently and long press (<= 5 seconds) of the power button doesn‘t work, only unplug of the PSU. <- this matches more to your description.

    Do you have some kind of overclocking active? Also other I2C devices/drivers maybe trigger this.

    Edited once, last by HarryH (July 29, 2024 at 8:59 PM).

    Thank you for engaging with me on this first of all.

    No I dont have any overclocking and no third party software installed, very standard, very vanilla: RPI4 model b 4GB ram in argonone.v2.m2.sata case and 256GB sata ssd. Also I have the argon remote.

    Very basic LE installation using ssh starting with SD boot. After that...

    • 'dd' LE12 image to argon.m2.sata drive.
    • remove SD card
    • 2 boots & minimal/network configuration
    • install rpi tools & system tools kodi add-ons
    • boot
    • install 'libreelec_argondevice_1.1.1.zip', default config
    • install media library via shared 'mariadb' on other RPI4 server (advancedsettings.xml)
    • some kodi customization
    • finished

    I have a couple of good case kodi.logs collected with debug log setting on. Now I am waiting for the bad case to happen again to collect another kodi.log. But since then the bad case didn't happen again. :)

    I will report back when it does with any findings from the kodi logs.

    For the parameter „enable_uart=1“ is documented that this locks the clock rate as fixed, but as far as I know this is not true.

    enable_uart=1 NOT fixing core_freq to 250MHz · Issue #4123 · raspberrypi/linux
    Is this the right place for my bug report? I hope so, apologies if that's not the case. I've also posted on the RPi forum (See…
    github.com


    So since beginning I expected that the I2C speed could make trouble too, because of dynamic clocking. Perhaps this is unfounded for the I2C and only the RPi clock-stretching bug is an issue. Until now I couldn‘t verify that case.

    If you can catch a bad case again, please provide the full log, not only snippets. If my suspicion is right, then we will doesn‘t find a difference in the logs, because the issue exists only during transfer of the message at the I2C bus.

    To rule out this possible trouble maker we can try to set the clock rate manually. This will have some restrictions like:

    • higher power consumption, no clock down during idle
    • maybe shortening lifespan of the RPi4, because the clock should be set to 550Mhz to be fast enough for 4K

    By the way: I have also been trying out a different configuration without "enable_uart=1" for several months in order to use a different UART and not restrict dynamic clocking (if it after an kernel/firmware update accidentally works like designed ;)). This works too, if you can live without the integrated bluetooth adapter.

    I doesn‘t have a oscilloscope to see what happens at the I2C bus so I‘m not 💯 sure that could be the solution for the bad case scenario. For the I2C clock stretching bug, maybe slow down the I2C speed helps to mitigate the issue.

    Edited 3 times, last by HarryH (August 1, 2024 at 7:09 PM).