On Wed, 11 Sept 2024 at 07:27, Jacob Abrams <satur9n...@gmail.com> wrote: > On 9/10/24 02:34, Peter Maydell wrote: > > If we make the .impl and .valid changes, then the result is > > that we permit 16 bit writes to come through to the read > > and write functions. Since we don't make any changes to > > those functions to specially handle size == 2, you get the > > effects of the existing code. If the 16 bit write is aligned > > to a 4-aligned register offset it will match one of the A_* > > cases, and will write 16-bit-value-zero-extended to it. > > If the 16 bit write isn't to a 4-aligned offset it will fall > > into the "default" case and be logged as a GUEST_ERROR. > > > > Did I miss some aspect of what the behaviour change is?
> Ah I see your point now regarding the zero extension writes. Basically you > are saying this patch will have the effect that a 16-bit write to one of the > USART registers such as USART_RTOR via an ARM instruction like STRH would not > be handled correctly because value to be written will be zero extended to > 32-bits before being written. > I do believe this is a valid problem. I will test the behavior on my > STM32L476 and report back the real HW behavior and I suspect the result would > be STRH write to such registers is allowed and unwritten bits are preserved > and not overwritten with zeros. Yeah, the datasheet doesn't say here and so checking the h/w behaviour would be helpful. > I submitted a new patch for just TEACK fix already and will report back on > the real HW test result later and adjust 16-bit read/write code as needed to > behave properly. > > I have also submitted a question to my STM contact regarding the reference > manual and assuming the answer is yes it is in error I will add comments > explaining that to my next patch for the 16-bit read/write handling. Would certainly be interesting to see what STM say. (If the answer is that some of these cases are invalid guest behaviour then we have the option of rather than following the in-practice h/w behaviour exactly instead doing something easy and logging it as a guest-error.) thanks -- PMM
