Reboot command

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?


1 Like

Ya, this requires physical access to the board. :expressionless:

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. :slight_smile:

FWIW, I believe I used a “shutdown -r now” and that worked, at least once, on the Unmatched - maybe worth a shot

shutdown -r now doesn’t work. It gets to the stage of declaring “Restarting system” then we get:

[30286.664011] rcu: INFO: rcu_sched self-detected stall on CPU
[30286.668815] rcu:     0-....: (5250 ticks this GP) idle=b92/1/0x4000000000000002 softirq=94187/94187 fqs=2626
[30286.678455]  (t=5254 jiffies g=185245 q=57)
[30286.682625] Task dump for CPU 0:
[30286.685838] task:systemd-shutdow state:R  running task     stack:    0 pid:    1 ppid:     0 flags:0x00000008
[30286.695740] Call Trace:
[30286.698172] [<ffffffe0000052a4>] walk_stackframe+0x0/0xaa
[30349.675908] rcu: INFO: rcu_sched self-detected stall on CPU
[30349.680707] rcu:     0-....: (20995 ticks this GP) idle=b92/1/0x4000000000000002 softirq=94187/94187 fqs=10401
[30349.690523]  (t=21007 jiffies g=185245 q=57)
1 Like

Works for me with the Open Embedded supplied with the machine, but not with Ubuntu.

Reset is currently not implemented in the firmware and software stack.

1 Like

This command seems to work pretty reliably from the U-Boot prompt:

i2c dev 0;i2c mw 0x58 0x00 0x00;i2c mw 0x58 0x4a 0x20;i2c mw 0x58 0x4b 0x80;i2c mw 0x58 0x06 0x4;i2c mw 0x58 0x0e 0x60;

It places the PMIC in hibernate mode, and uses its one-second tick alarm to immediately wake back up again. By replacing the last write with

i2c mw 0x58 0x13 0x2;

the board will perform a full power cycle instead. I found the tick alarm sequence in this thread on Dialog’s support forums.


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.

1 Like

I made a small kernel patch that adds Anders’ sequence to the PMIC driver, to make the reboot command in linux work at least.

Note that CONFIG_MFD_DA9063 must be enabled in the kernel config for this to work.


Hey @marcus could you submit the patch as a PR to meta-sifive repository?

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…)

Please reference the HiFive Unmatched schematics and pp4 is the GPIO function list. Unfortunately, no GPIO is dedicated for system reset.

1 Like

This sequence may be better than what I originally posted:

i2c dev 0;i2c mw 0x58 0x00 0x00;i2c mw 0x58 0x96 0xdf;i2c mw 0x58 0x4a 0x20;i2c mw 0x58 0x4b 0x80;i2c mw 0x58 0x06 0x4;i2c mw 0x58 0x0e 0x68;

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.

Here is a patch for Linux that basically executes similar I2C writes at the end of the shutdown routine. I guess that’s the best thing you can do at this point: riscv-bringup/kernel-reboot.diff at bbef412a4456acefdf814a9e14a75ce2778992ed · carlosedp/riscv-bringup · GitHub
(Not sure what the initial patch in this thread did since the pastbin expired… don’t pastebin patches please).

1 Like

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).