Messages in this thread |  | | Date | Sat, 2 Apr 2022 12:18:01 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH] riscv: Work to remove kernel dependence on the M-extension |
| |
Hi!
> >>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 claims?
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, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates. [unhandled content-type:application/pgp-signature] |  |