(07-23-2021, 05:41 PM)renze Wrote: Some debugging later I've figured out why reset wasn't working: I built my u-boot in such a way that it contained SCP coprocessor firmware. Apparently that firmware can cause that a reboot of Linux doesn't trigger the reset line at all.

Building u-boot without the SCP firmware solves the problem.

(07-23-2021, 05:41 PM)renze Wrote: Another note: instead of doing the diode modification the reset problem can also be fixed by removing the resistors between the inverters (U54/U55) and the reset lines of the SoPine modules. By doing that you effectively disable the reset circuit (causing the reset button to do nothing at all), but in return the boards will always reset correctly and you solve the design mistake (the inverter drives directly against the SoC itself, which tries to pull the reset line low for rebooting but can't as the inverter keeps the line high). The resistors are in a row between the chips and the SoPine modules.

(07-28-2021, 03:20 AM)dsimic Wrote: Sounds good, but have you actually tested this hardware fix?  This is probably another way to quickly fix the Clusterboard reboot issue, but as you've already described, this fix also renders the reset button inoperable, which may not be desired.  Have you checked whether this fix prevents the RTC backup batteries from being discharged when the Clusterboard is powered on?  Also, please keep in mind that this fix doesn't prevent the batteries from becoming charged by the VCC_RTC outputs of the AXP803 PMICs on installed SOPine modules.  That power path should always be disabled by adding a Schottky barrier diode, regardless of any further modifications, if the RTC backup batteries will be installed.

As a note, I've spent some time debugging some RTC-related issues and journal corruption (see this issue for further information), so having the RTC backup batteries installed would be highly advisable.