aspeed: spi driver: fmc wdt2

[Joel Stanley]

On Tue, 26 Apr 2022 at 14:09, 张健 <zhangjian.3032 at bytedance.com> wrote:
>
> Hi Guys;
>
> I would like implement the flash toggle function in ast2600.
> That function about ast2400/2500 implement at linux/aspeed_wdt.c at aspeed-master-v5.15 · AspeedTech-BMC/linux (github.com)
>
> Here is my design, just an idea. I would like to see your suggestions. Thanks.
>
> There are some differences between ast2600 and ast2500/2400. For the ast2600 SoC abr function, there is a set of registers named `FMC_WDT2` in FMC(SPI).
> FMC_WDT2 is not a full function WDT, thus, I can't use aspeed_wdt driver to do that.

Yes. There is a similar device embedded in the secure boot controller
for eMMC boot (SECA0..A8). The FMC register is better documented, but
the layout is the same.

> In ast2400/2500 used a sysfs attr `access_cs0`, can make cs0->cs1 and cs1->cs0.
> For cs0->cs1, ast2400/2500 use the wdt2's self timer, cs1->cs0, use `access_cs0` to set the `flash indicate` bit.
> But ast2600 without the FMC_WDT2 timer driver to trigger `cs0`->`cs1`, thus, I would like to add 2 sysfs attrs in spi driver.
> Because ast2600 supports single image abr mode, i'd like to use primary/backup instead of cs0/1.

Does the ast2400/ast2500 method cs0/cs1 method work on 2600 too? If
so, should we enable the boot switch sysfs files for 2600 too?

Regarding the abr mode, could we create a piece of shared code that is
used by both the FMC and SEC. It would be called by the respective
drivers to register the sysfs files, with a pointer to the appropriate
registers.

> attr1 "access_backup": (only appears in primary and compatible is "aspeed,ast2600-fmc")
> store: The parameter is the timeout time for fmc_wdt2, if written, timer will be enabled, if timeout, will reboot from backup.
> show: the time left in fmc_wdt2 timer. 0 means timer is not enabled.
>
> attr2 "access_primary”: (only appears in backup, and compatible is "aspeed,ast2600-fmc")
> store: Non-zero values indicate access to primary, 0 indicate access to backup
> show: 0: next reboot will boot from backup, 1 : will boot from primary.

I think this makes sense. I'd suggest coding it up and putting it on
the list. As Cédric mentioned, adding support to Qemu would be useful
for testing too.

A separate concern is adding support to u-boot, so u-boot can pat the
watchdog in early boot (and when sitting at the u-boot prompt).

Thanks for sending your proposal along.

Cheers,

Joel