# Reboot command

**URL:** <https://forums.sifive.com/t/reboot-command/4721>\
**Category:** HiFive Unmatched\
**Created:** [May 28, 2021, 5:02pm UTC](https://forums.sifive.com/t/reboot-command/4721 "2021-05-28T17:02:42Z")\
**Posts on this page:** 12\
**Page:** 2

<div class="post-metadata">

**Author:** ![andersm](https://avatars.discourse-cdn.com/v4/letter/a/eb8c5e/32.png) [@andersm](https://forums.sifive.com/u/andersm)\
**Post date:** [September 3, 2021, 9:32am UTC](https://forums.sifive.com/t/reboot-command/4721/21 "2021-09-03T09:32:38Z")

</div>

It is possible there is a race against the one-second tick. The documentation isn’t entirely clear if the event register must be cleared before a new event can trigger a wakeup. If that is the problem, it should be possible to instead set the RTC alarm some large enough number of seconds into the future.

---

<div class="post-metadata">

**Author:** ![vmedea](https://avatars.discourse-cdn.com/v4/letter/v/3be4f8/32.png) [@vmedea](https://forums.sifive.com/u/vmedea)\
**Post date:** [September 3, 2021, 10:46am UTC](https://forums.sifive.com/t/reboot-command/4721/22 "2021-09-03T10:46:09Z")

</div>

> [@andersm](#):
>
> ```auto
> 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;
> 
> ```

In terms of Linux implementation, based on the above patch, this sequence would be this, right?

```auto
static int da9063_restart_notify(struct notifier_block *this,
                                unsigned long mode, void *cmd)
{
    struct da9063 *da9063 = container_of(this, struct da9063, restart_handler);
    
    regmap_write(da9063->regmap, DA9063_REG_PAGE_CON, 0x00);
    regmap_write(da9063->regmap, DA9063_REG_SEQ_B, 0xdf);
    regmap_write(da9063->regmap, DA9063_BB_REG_ALARM_MO, 0x20);
    regmap_write(da9063->regmap, DA9063_BB_REG_ALARM_Y, 0x80);
    regmap_write(da9063->regmap, DA9063_REG_EVENT_A, 0x4);
    regmap_write(da9063->regmap, DA9063_REG_CONTROL_A, 0x68);
    
    return NOTIFY_DONE;
}
```

Edit: updated according to andersm’s comment below

---

<div class="post-metadata">

**Author:** ![andersm](https://avatars.discourse-cdn.com/v4/letter/a/eb8c5e/32.png) [@andersm](https://forums.sifive.com/u/andersm)\
**Post date:** [September 3, 2021, 11:04am UTC](https://forums.sifive.com/t/reboot-command/4721/23 "2021-09-03T11:04:52Z")

</div>

Use the “BB” register definitions to match the datasheet. The “AD” register map is for an old prerelease chip revision.

```auto
regmap_write(da9063->regmap, DA9063_BB_REG_ALARM_MO, 0x20);
regmap_write(da9063->regmap, DA9063_BB_REG_ALARM_Y, 0x80);

```

---

<div class="post-metadata">

**Author:** ![vmedea](https://avatars.discourse-cdn.com/v4/letter/v/3be4f8/32.png) [@vmedea](https://forums.sifive.com/u/vmedea)\
**Post date:** [September 3, 2021, 1:09pm UTC](https://forums.sifive.com/t/reboot-command/4721/24 "2021-09-03T13:09:20Z")

</div>

Thanks, I’m going to try this and leave it in a reboot loop overnight.

- The [old sequence](https://github.com/carlosedp/riscv-bringup/blob/bbef412a4456acefdf814a9e14a75ce2778992ed/unmatched/patches/kernel-reboot.diff) powers down the board about half of the time on “reboot”. The other half it does reboot.
- The [new sequence](https://forums.sifive.com/t/reboot-command/4721/22) does nothing at all. The system just hangs after `reboot: Restarting system`. I did enable `CONFIG_MFD_DA9063`, and have verified that the code gets run by adding a printk.

---

<div class="post-metadata">

**Author:** ![andersm](https://avatars.discourse-cdn.com/v4/letter/a/eb8c5e/32.png) [@andersm](https://forums.sifive.com/u/andersm)\
**Post date:** [September 3, 2021, 6:20pm UTC](https://forums.sifive.com/t/reboot-command/4721/25 "2021-09-03T18:20:29Z")

</div>

It’s possible the Linux device drivers configure the PMIC registers in some way that stops it from working. Try the following:

- Completely remove power from the board and let it sit for a few minutes to make sure the PMIC is initialized to the OTP settings
- At the U-boot prompt, try the reset sequence a few times
- Boot to Linux
- Use the reset button to restart the board, preserving the PMIC state
- Try the U-boot sequence again

If it stops working only after booting to Linux, either read the driver sources to figure out what they’re doing, or dump the PMIC registers before and after starting the OS, and see which have changed.

---

<div class="post-metadata">

**Author:** ![vmedea](https://avatars.discourse-cdn.com/v4/letter/v/3be4f8/32.png) [@vmedea](https://forums.sifive.com/u/vmedea)\
**Post date:** [September 3, 2021, 9:56pm UTC](https://forums.sifive.com/t/reboot-command/4721/26 "2021-09-03T21:56:12Z")

</div>

Thank you. That helped me figure it out!

It was indeed a matter of the kernel setting a PMIC register that stopped it from working. It was buried pretty deeply: the initialization for the regmap IRQ chip caused all events to be masked. Once found it was straightforward to work around. Adding

```auto
regmap_write(da9063->regmap, DA9063_REG_IRQ_MASK_A, 0x00);

```

makes it work 100% reliably, here 😅 . Here’s the [full patch](https://gist.githubusercontent.com/vmedea/8bed5495bb92efaa704860840e69e3ea/raw/ec07295aea6b2c2c8abed0244eac8c5be5acf0da/0001-Kernel-reboot-hack-for-HiFive-Unmatched.patch).

---

<div class="post-metadata">

**Author:** ![marcus](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.sifive.com/marcus/32/939_2.png) [@marcus](https://forums.sifive.com/u/marcus)\
**Post date:** [September 4, 2021, 5:18am UTC](https://forums.sifive.com/t/reboot-command/4721/27 "2021-09-04T05:18:39Z")

</div>

I put this newest sequence in a reboot loop over night, and by morning it had rebooted 282 times without incident. So I concur that this is 100% (or at least \>99.6% 😄) reliable.

---

<div class="post-metadata">

**Author:** ![alexghiti](https://avatars.discourse-cdn.com/v4/letter/a/b3f665/32.png) [@alexghiti](https://forums.sifive.com/u/alexghiti)\
**Post date:** [September 17, 2021, 5:29am UTC](https://forums.sifive.com/t/reboot-command/4721/28 "2021-09-17T05:29:25Z")

</div>

Hi guys,

I ported your sequence to a u-boot driver and noticed that, although it works reliably, turning off the board within 16seconds after this sequence is not possible since the board would restart. Weirdly, I did not have this issue when launching the sequence from the u-boot shell: by adding a few sleeps between the register writes in my u-boot driver, it finally worked. It seems the behavior I’m facing is described in the thread shared before ([Power Management ICs (PMICs) | Dialog](https://www.dialog-semiconductor.com/products/pmics?post_id=10052#tab-support_tab_content)) and I don’t quite understand why it does not happen all the time.

Anyway, as the “sleeps” solution did not suit me, I digged the datasheet and found a shorter sequence that does not give rise to the issue:

i2c dev 0;  
i2c mw 0x58 0x13 0x4; // Set the WAKE\_UP bit to CONTROL\_F  
i2c mw 0x58 0xe 0x68; // Powerdown

It works reliably for me, if you have a chance to test this, any feedback is welcome.

---

<div class="post-metadata">

**Author:** ![vmedea](https://avatars.discourse-cdn.com/v4/letter/v/3be4f8/32.png) [@vmedea](https://forums.sifive.com/u/vmedea)\
**Post date:** [September 17, 2021, 5:24pm UTC](https://forums.sifive.com/t/reboot-command/4721/29 "2021-09-17T17:24:12Z")

</div>

That’s neat! I ported that sequence to the kernel hack and it seems to work reliably (only tried about ~10 times for now, manually).

```auto
static int da9063_restart_notify(struct notifier_block *this,
                                unsigned long mode, void *cmd)
{
        struct da9063 *da9063 = container_of(this, struct da9063, restart_handler);

        regmap_write(da9063->regmap, DA9063_REG_CONTROL_F, 0x04);
        regmap_write(da9063->regmap, DA9063_REG_CONTROL_A, 0x68);

        return NOTIFY_DONE;
}

```

---

<div class="post-metadata">

**Author:** ![alexghiti](https://avatars.discourse-cdn.com/v4/letter/a/b3f665/32.png) [@alexghiti](https://forums.sifive.com/u/alexghiti)\
**Post date:** [September 21, 2021, 5:40am UTC](https://forums.sifive.com/t/reboot-command/4721/30 "2021-09-21T05:40:41Z")

</div>

I have sent 2 PR to u-boot and linux kernel here:

[https://patchwork.ozlabs.org/project/uboot/patch/20210920154809.1695453-1-alexandre.ghiti@canonical.com/](https://patchwork.ozlabs.org/project/uboot/patch/20210920154809.1695453-1-alexandre.ghiti@canonical.com/)

[https://patchwork.kernel.org/project/linux-riscv/patch/20210921053356.1705833-1-alexandre.ghiti@canonical.com/](https://patchwork.kernel.org/project/linux-riscv/patch/20210921053356.1705833-1-alexandre.ghiti@canonical.com/)

I’ll keep you posted when/if this gets merged.

Thank you guys,

Alex

---

<div class="post-metadata">

**Author:** ![vmedea](https://avatars.discourse-cdn.com/v4/letter/v/3be4f8/32.png) [@vmedea](https://forums.sifive.com/u/vmedea)\
**Post date:** [September 21, 2021, 8:29am UTC](https://forums.sifive.com/t/reboot-command/4721/31 "2021-09-21T08:29:05Z")

</div>

> [@alexghiti](#):
>
> I’ll keep you posted when/if this gets merged.

I hope so!!! I’m slightly worried about prospects for getting the Linux one merged, according to other posts above reset functionality is supposed to go into opensbi, however that has no I2C driver at all at this point:

> [@davidlt](#):
>
> 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.

Seems like quite a lot of work… at least to add proper I2C infrastructure. Another idea would be to add an `fdt_reset_sifive_unmatched.c` that hardcodes the I2C controller register write sequence, but not sure that’s more acceptable 🙂

Maybe SiFive wants to carry the patches in [https://github.com/sifive/meta-sifive](https://github.com/sifive/meta-sifive) for the meantime.

---

<div class="post-metadata">

**Author:** ![alexghiti](https://avatars.discourse-cdn.com/v4/letter/a/b3f665/32.png) [@alexghiti](https://forums.sifive.com/u/alexghiti)\
**Post date:** [September 21, 2021, 8:51am UTC](https://forums.sifive.com/t/reboot-command/4721/32 "2021-09-21T08:51:03Z")

</div>

Those patches are only there to finally have a functional reset on those boards. I’m preparing the proper solution with openSBI i2c driver and Linux using SBI SRST extension, I’ll keep this thread updated 🙂

[Previous page](https://forums.sifive.com/t/reboot-command/4721.md?page=1)
