Hi. Received my Unmatched today and it seems to be working fine, but I’m a bit disappointed that the “reboot” command does not work.
reboot used to work on the Unleashed, but then it broke in the whole OpenSBI kerfuffle. I would have expected this to have been fixed when a new shiny board was released…
Any roadmap for when a firmware supporting reboot will be released?
I connected my Unmatched to a remote power outlet, but that doesn’t help either. If you do poweroff, then power off the outlet, then power back on, the board doesn’t power up. If you do reboot the board hangs on reboot. Doing a power cycle when it is in that state will power it back up, but it isn’t enough to reset the board as it still hangs. In other words, reboot, then power cycle will power on the board, but it won’t reset the board to a working state. So you have to go over and hit RESET. Workarounds appreciated.
Ok, great. So I guess what’s needed now is to put those I2C writes into an sbi_system_reset_device,
and then create a platform_override for the unmatched which registers that reset device from an early_init callback. Should be like an hours work max.
This is not a good way to reboot the board. The correct way is to use the gpio-restart driver with an appropriately-modified FDT, in lieu of proper firmware support for the SBI system reset extension on the board.
But which GPIO (if any) has the reboot function? The Unmatched HW Reference Manual is not available, and the other manuals do not seem to contain a GPIO map, so the only GPIOs we know about are those already in the device tree, which is limited to GPIO 2 (poweroff)…
Yes. The correct approach here will be SBI SRST extension which landed in SBI v0.3 specification. Note that Linux changes to use this new extension is currently not merged and most likely will land in v5.15 kernel.
There are also U-Boot patches for UEFI ResetSystem() support on RISC-V which uses SBI SRST extension. I don’t think it landed yet too, but most likely will sooner than later.
IIRC there are no GPIO for reset. In order to reset you need to talk to PMIC via I2C. There is no I2C driver in OpenSBI too. I believe BeagleV also needs to talk to PMIC via I2C within OpenSBI.
Using SBI SRST does nothing as long as OpenSBI has no reboot functionality for this board, so the problem of finding the “correct” sequence to perform the actual reboot remains regardless if we put the reboot code in Linux or OpenSBI. (As you say there is no I2C driver in OpenSBI, which makes the I2C method more work to implement there. I’ll venture that reboot from OpenSBI doesn’t work on BeagleV either…)
It configures the power sequencer standby mode (PART_DOWN pointer) to be the same as the last step of the SYSTEM power domain sequence, and then enters standby mode. The same 1-second tick alarm trick as before is used to wake the system back up again.
The way the PMIC power sequencer is programmed, this should leave all power supplies enabled (provided I understood the datasheet correctly, and read and decoded the register settings correctly).
The previous command moved the power sequencer all the way back to slot 0, turning off all but the default supplies.
The patch you link to is exactly what I posted on pastebin. It was put there because it was a PoC not meant as a permanent solution. It should probably be updated to use Anders’ new sequence at least.
I and some other folks tried the original patchset without a success, i.e. it wasn’t consistently rebooting the system and seemed to worked randomly (i.e. it just power downs). I believe similar concerns were raised in the DA forums where this didn’t seem reliable.
Did someone tried testing a new command seq in a reboot cycle, let’s say 100 consecutive reboots? (you could setup systemd unit to reboot every 30 seconds after successful boot, increment a counter, or something similar).