[lkml]   [2022]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] riscv: Work to remove kernel dependence on the M-extension

> >>That'd be wonderful, but unfortunately we're trending the other way --
> >>we're at the point where "words in the specification have meaning" is
> >>controversial, so trying to talk about which flavors of the
> >>specification are standard is just meaningless. I obviously hope that
> >>gets sorted out, as we've clearly been pointed straight off a cliff for
> >>a while now, but LMKL isn't the place to have that discussion. We've
> >>all seen this before, nobody needs to be convinced this leads to a mess.
> >>
> >>Until we get to the point where "I wrote 'RISC-V' on that potato I found
> >>in my couch" can be conclusively determined not compliant with the spec,
> >>it's just silly to try and talk about what is.
> >
> >I would argue that codifying the required extensions through kernel source
> The problem here isn't the required extensions, it's that vendors can claim
> to implement an extension on hardware that doesn't exhibit any of the
> behavior the specification expresses that systems with those extensions must
> have. The D1 is a very concrete example of this.

Sounds like someone interested should make a webpage listing available
CPUs that claim RISC-V compatibility but far short of advertised

I'd like to get RISC-V board to play with sometime soon, and some help
in what board to get would be welcome...

Best regards,
People of Russia, stop Putin before his war on Ukraine escalates.
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2022-04-02 12:18    [W:0.043 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site