This is the first mention of DT AFAICT, so we should clarify where it comes from and what the relevant specifications are. Should we wait to use whatever [1] standardizes on? Will we need to be

Ok, What I thought while mentioning this that, if SBI spec mentions that Legacy interfaces should not be implemented" then this statement is also a requirement just "to not implement". But I think

Probably some of them are. At least I know OpenPiton guys are interested because they can just run upstream software stack without worrying too much. As per my understanding, Linux2022 base is the

Yes. Additional clarification for everybody: EBBR is meant for embedded systems as in embedded Linux. The embedded 2022 in RISC-V platform spec is aimed towards the bare metal/micro-controller

ARM has suggested an API for A/B firmware updates on flash devices managed by the secure world: https://armkeil.blob.core.windows.net/developer/Files/pdf/FWU-PSA-A_DEN0118_1.0ALP3.pdf The license

It seems like the watchdog description belongs in a separate specification that either describes the register memory layout, or else as a RISC-V ISA extension that lists the CSRs to control it. The

We can rephrase it to "If the mtime/time increments past the watchdog stage 2 compare value then a system reset shall occur". This leaves open the question of how and when the reset will occur while

We can rephrase it to : " If the mtime/time increments past the watchdog stage 2 compare value then a system reset shall occur"

For comparison sake, here's what SBSA says: ------------------------------------------------------------------------- Watchdog Signal 0 is routed as an SPI or an LPI to the GIC and it is expected this

Atish Patra <atish.patra@...> 於 2021年4月23日 週五 上午7:49寫道： Should we have to define the implementation when the watchdog stage 2 is timeout? How to handle the timeout should be

Atish Patra <atish.patra@...> 於 2021年4月23日 週五 上午7:34寫道： This may fix my concern in the previous reply. Atish, do you mean we will have RISC-V elements in EBBR spec. That is EBBR

My take is that we shouldn't be requiring things that software can easily cope with not having. The watchdog obviously falls into that category. Having a "minimal" platform or having a bucket of

Are dev boards / academic FPGA implementations going to care about being able to brand themselves as Linux-2022 compliant? And should we let the tail wag the dog in defining a platform spec for

As the base specification also targets the dev boards, academia FPGAs at least for Linux 2022, do we need to mandate a watchdog timer. May be put it as strongly recommended and mandate it in Linux

This statement is bit ambiguous given that individual SBI section says legacy ones must not be implemented. Should we reword something like this, Any platform seeking compliance with the base

Yes, I got this point from Rahul's reply. Thanks for this. Abner Atish Patra <Atish.Patra@...> 於 2021年4月22日 週四 上午11:10寫道：

Rahul Pathak <rpathak@...> 於 2021年4月22日 週四 上午10:29寫道： Ok. Ok. I have no problem with this. Just argue that many links to EBBR which create the dependecies with these two specs.

I think the confusion is valid because of the current naming scheme which is just a place holder. Just to clarify the embedded2022 is meant for microcontroller type of hardware where some RTOS or

Hi Sunil, Below is my feedback to this patch after the discussion in another thread, Linux2022 Platform is defined as the baseline requirements for RISC-V platforms, and with "Server Extension" to