[PATCH 0/4] reboot SiFive Unmatched via PMIC

[Anup Patel]

On Sat, Sep 25, 2021 at 6:40 AM Bin Meng <bmeng.cn at gmail.com> wrote:
>
> On Fri, Sep 24, 2021 at 7:34 PM Nikita Shubin <nikita.shubin at maquefel.me> wrote:
> >
> > From: Nikita Shubin <n.shubin at yadro.com>
> >
> > This series introduce rebooting via i2c PMIC, currently on
> > SiFive Unmatched board.
> >
> > teseted via Linux with reset extension and direct ecall from
> > u-boot.
> >
> > With this it becomes possible to reboot/shutdown the board
> > if Linux or u-boot is accompanied with OpenSBI reset extension.
> >
> > "gpio-poweroff" is required to be removed from u-boot dts file, as
> > it overrides fdt_reset_da9063.
> >
> > fdt_reset_da9063 is loaded if "dlg,da9063" is present in device tree.
> >
> > Moreover it's look like we require a convenient "sleep" functionality,
> > currently i've implemented sleep via CSR_MCYCLE, assuming we don't normally
> > communicate with device while operational only on start/shutdown.
> >
> > ```
> > static inline void wait_cycles(unsigned long cycles)
> > {
> >         csr_write(CSR_MCYCLE, 0);
> >         while (cycles > csr_read_num(CSR_MCYCLE));
> > }
> > ```
> >
> > The original sequence was discovered by Alexandre Ghiti posted a patch on
> > linux-riscv mail-lists.
> >
> > https://patchwork.kernel.org/project/linux-riscv/patch/20210921053356.1705833-1-alexandre.ghiti@canonical.com/
> >
> > These magick numbers are readed as:
> > - select PAGE0
> > - set WAKE_UP bit in CONTROL_A reg
> > - mask setting POWER1, POWER domain and STANDBY, and poweroff SYSTEM domain
> >
> > Nikita Shubin (4):
> >   lib: utils/i2c: Add generic I2C configuration library
> >   lib: utils/gpio: Add simple FDT based I2C framework
> >   lib: utils/gpio: Add minimal SiFive I2C driver
> >   lib: utils/reset: Add generic da9063 reset driver
> >
>
> It looks like we will end up having lots of reset drivers in OpenSBI
> in the future, no surprise, as this is what the spec requires, sigh.
>
> Alexandre Ghiti has posted U-Boot patches to reset Unmatched via PMIC as well.
> http://patchwork.ozlabs.org/project/uboot/patch/20210924084231.3311216-5-alexandre.ghiti@canonical.com/

This diversity with reset drivers is not a problem just for OpenSBI
but it applies to all OSes (Linux, FreeBSD, VxWorks, ....),
Bootloaders (U-Boot, EDK2, Coreboot, ....), and Hypervisors
(Xvisor, Xen, Bao, ....).

Just imagine, each hypervisor having its own reset mechanism
for Guest/VM and suddenly we start having hypervisor specific
reset drivers in various OSes and Bootloaders.

Even more critical issue is TEE where we can't let non-secure
domains directly reset the system without the secure domain
knowing about it.

With SBI SRST extension the above issues are handled
as follows:
1) The diversity in platform specific resets is restricted to
M-mode runtime firmware (OpenSBI)
2) All hypervisors provide SBI SRST to Guest/VM as the
standard reset mechanism
3) Reset requests from TEE non-secure domains come to
M-mode runtime firmware (OpenSBI) which can then
notify the TEE secure domain to take necessary action.
Also, reset request from the TEE secure domain will
directly reset the system.

Point#3 above has been already implemented in OpenSBI
domains.

We have been discussing SBI SRST for almost 2 years now.

We also had extensive discussion about this at LPC 2020.
https://linuxplumbersconf.org/event/7/contributions/810/attachments/631/1144/RISCV_EBBR_lpc2020.pdf

Regards,
Anup

>
> Regards,
> Bin
>
> --
> opensbi mailing list
> opensbi at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/opensbi