在 2022-12-05星期一的 15:05 +0000，Conor Dooley写道： > On Mon, Dec 05, 2022 at 07:03:17PM +0800, Icenowy Zheng wrote: > > 在 2022-12-05星期一的 10:36 +0000，Conor Dooley写道： > > > > You lot all know the situation here a lot more than I do... > > > I don't think "letting" people use the bare "thead,c900-foo" > > > makes > > > much > > > sense as it gives us no chance to deal with quirks down the line. > > > > Well, after rechecking the manual, I found it possible to handle > > quirks > > -- T-Head has a custom "mcpuid" CSR (@ RISC-V CSR 0xFC0), which can > > be > > used to retrieve some identification info of the core, including > > its > > model ID, version, etc; and the T-Head PLIC/CLINT are part of their > > C906 SoC design that there's another "mapbaddr" CSR that could be > > used > > to retrieve the base address of them. > > > > So I think it okay to just use "thead,c900-clint" here, and when > > necessary, try to retrieve mcpuid for dealing with quirks. > > I'm not super sure I follow. What's the relevance of "mapbaddr" here? > We've got a reg property, so I don't think we need "mapbaddr"? Yes, it's not relevant to us here, it's only to prove that PLIC/CLINT is part of C906 "Core Complex". > > For "mcpuid", can you be sure that implementers will not omit setting > that value to something unique? I'd be happier if we were overly > clear > now rather than have some headaches later. Have I missed something? These values are set by T-Head instead of individual SoC implementers as a CPU CSR, and it's not for uniqueness, but it's for identification of the CPU core revision (thus the PLIC/CLINT that come with it). > > > > I don't think that using "thead,openc906-clint", "thead,c900- > > > clint" > > > makes all that much sense either, in case someone does something > > > wacky > > > with the open-source version of the core. > > > > > > That leaves us with either: > > > "vendor,soc-clint", "thead,openc906-clint", "thead,c900-clint" > > > or: > > > "vendor,soc-clint", "thead,c900-clint" > > > right? > > > > > > The first one seems like possibly the better option as you'd > > > kinda > > > expect that, in a perfect word, all of the open-source IP > > > implementations would share quirks etc? >
