[PATCH RFC 2/2] RISC-V: add T-Head vector errata handling

Heiko Stübner heiko at sntech.de
Fri Jun 23 16:26:12 PDT 2023


Am Freitag, 23. Juni 2023, 12:22:35 CEST schrieb Heiko Stübner:
> Am Freitag, 23. Juni 2023, 05:06:44 CEST schrieb Stefan O'Rear:
> > On Thu, Jun 22, 2023, at 4:35 PM, Heiko Stübner wrote:
> > > Am Donnerstag, 22. Juni 2023, 20:58:37 CEST schrieb Stefan O'Rear:
> > >> Are you aware of "3.7. Vector Fixed-Point Fields in fcsr" in
> > >> riscv-v-spec-0.7.1.pdf?
> > >
> > > oh wow, thanks a lot for that pointer, now I understand your concern.
> > >
> > > So in vector-0.7.1 fcsr[10:9] mirrors vxrm and fcsr[8] mirrors vxsat.
> > >
> > >
> > > On a positive note, the T-Head cores seem to not implement the full
> > > vector 0.7.1 specification after all, in the documentation I have [0]
> > > fcsr[31:8] are declared as "0" and uppermost bits are [7:5] for the "frm"
> > > field.
> > 
> > Given that the pdf you linked does not mention any vector CSRs, I am not
> > confident that it provides a complete and accurate description of vector
> > functionality in other registers for the C906 with vector extension.
> > 
> > Assuming that you have access to such a chip, I would be much happier with
> > the proposed "just a comment" approach if our understanding of the behavior
> > were confirmed on hardware (specifically: csr_write(CSR_FCSR, 0x700) should
> > not affect csr_read(CSR_VXRM) or csr_read(CSR_VXSAT)).
> 
> For one, you're right that I should definitly try to confirm this on hardware :-) .

ok, so now I know the documentation is wrong.

	before, vxrm 0x0, vxsat 0x0
writing the 0x700 to fcsr
	after, vxrm 0x3, vxsat 0x1

Essentially the link between the CSRs really is there - oh fun.
So we're back at your original concern - sadly.

I guess I need to figure out how to not have this stuff break
because relying on the fpu parts to handle feels not correct
at first glance.


Heiko





More information about the linux-riscv mailing list