On Mon, 2021-02-01 at 21:59 -0800, Greg Favor wrote:

The following tries to capture and summarize what was discussed in
today's meeting wrt what may be called the Embedded platform spec
(versus the Linux platform spec).  I know I have missed some things
and gotten some things a bit wrong, so feel free to correct and add
on to this.  I also threw in a couple of narrower,
detailed questions.

Thanks Greg.

The point of this is to start email discussion and filling out of
this high-level summary without waiting til the next meeting -
especially from the people that are more knowledgeable about embedded
systems and what can be standardized and what would be of value to
standardize.  Hopefully, since this spec is limited in what can be
usefully standardized, this can be pushed forward in parallel with
the bigger efforts towards fleshing out the framework for the Linux-
2020/2022 platform spec(s) - especially by people interested in this
spec.  (Put differently, we can't afford to only make progress at the
rate of one hour a week.  And we need to parallelize the two platform
efforts.  Then the biweekly meetings can be sync-up points and
discussion of key issues.  And hopefully the basics of a draft
Embedded platform spec won't take all that long either.)

 * Don't call it a "bare metal" or "non-Linux" spec, just "embedded"
(to span a range of hardware/software environments)
   

Why do we want to include bare-metal ? There won't be any software
compatibility between bare-metal software applications. Why do they
need to comply with a specification that is not useful to them ?

 * Practically speaking any Embedded platform spec is primarily of
forward-looking value - for new designs to conform to
    - Focus on Embedded-2022 spec
    - No Embedded-2020 spec (since there is limited compatibility
across today's systems)
      

Agreed. There is no standard implementation between existing platforms.

 * Can only standardize a limited set of basics (given the wide
variety and needs of embedded systems):
    - Require RVM22 (with no turning of any optional items into
required items)
       + Feedback to RVM22 definition group about any needed finer-
granularity arch extension breakdowns?
          * E.g. mul without div?
          * E.g. just parts of S-mode if S-mode supported?
          * Wrt the many WARL options in M-mode and S-mode Priv
specs, any required values?
           

Do we need break the spec RVM22 in individual ISA chunks ?
RVM22 can just say RV32I/RV64I is mandatory. Every other extension is
optional.

 
    - Require "CLIC and/or PLIC"
       + CLIC from Fast Interrupts TG; need to create a "standard"
PLIC spec
      

We need to standardize PLIC for Linux-2022 platform specification as
well.

   
    - Require CLINT (or rough equivalent)
       + Or require "CLINT or CLIC" if CLIC includes CLINT
functionality (for timer and s/w interrupts)?
       + Need to create a "standard" CLINT spec
         
    - EABI and/or other ABIs as options?  Maybe not of value.
      
    - Minimum PMP config (if optionally implemented)
       + This is an example of the above item about WARL options in
the Priv spec
         
    - ???
Greg

--
Regards,
Atish