On Tue, 7 Apr 2020 at 10:09, Cameron Esfahani wrote:
>
> I'm not burying anything. This patch is stand alone and all the tests do
> work. They work with or without Cedric's nee Andrew's patch. But, if some
> derivative of that patch is eventually implemented, something needs to be
> done
On Fri, 10 Apr 2020, at 21:56, Peter Maydell wrote:
> On Fri, 10 Apr 2020 at 04:42, Andrew Jeffery wrote:
> > IIRC Phil wanted to enable sub-word accesses to the sample value
> > registers but I didn't want to spread logic dealing with different access
> > widths through the model. We already
On Fri, 10 Apr 2020 at 04:42, Andrew Jeffery wrote:
> IIRC Phil wanted to enable sub-word accesses to the sample value
> registers but I didn't want to spread logic dealing with different access
> widths through the model. We already had a mechanism to describe the
> model's supported access
On Tue, 7 Apr 2020, at 18:20, Peter Maydell wrote:
> On Tue, 7 Apr 2020 at 09:45, Joel Stanley wrote:
> > On Tue, 7 Apr 2020 at 08:41, Peter Maydell wrote:
> > > Do you have a link to this patch, please? I had a quick search through
> > > my mailing list articles but couldn't see anything
I'm not burying anything. This patch is stand alone and all the tests do work.
They work with or without Cedric's nee Andrew's patch. But, if some
derivative of that patch is eventually implemented, something needs to be done
for this NRF51 gpio qtest to work.
There are two possibilities
On Tue, 7 Apr 2020 at 09:45, Joel Stanley wrote:
> On Tue, 7 Apr 2020 at 08:41, Peter Maydell wrote:
> > Do you have a link to this patch, please? I had a quick search through
> > my mailing list articles but couldn't see anything obviously relevant.
>
> There is a reference in this thread:
>
>
On Tue, 7 Apr 2020 at 08:41, Peter Maydell wrote:
>
> On Mon, 6 Apr 2020 at 23:55, Cameron Esfahani wrote:
> >
> > NRF51_GPIO_REG_CNF_END doesn't actually refer to the start of the last
> > valid CNF register: it's referring to the last byte of the last valid
> > CNF register.
> >
> > This
Hi Cameron,
On 4/7/20 12:55 AM, Cameron Esfahani wrote:
NRF51_GPIO_REG_CNF_END doesn't actually refer to the start of the last
valid CNF register: it's referring to the last byte of the last valid
CNF register.
This hasn't been a problem up to now, as current implementation in
memory.c turns
On Mon, 6 Apr 2020 at 23:55, Cameron Esfahani wrote:
>
> NRF51_GPIO_REG_CNF_END doesn't actually refer to the start of the last
> valid CNF register: it's referring to the last byte of the last valid
> CNF register.
>
> This hasn't been a problem up to now, as current implementation in
> memory.c
On 4/7/20 12:55 AM, Cameron Esfahani wrote:
> NRF51_GPIO_REG_CNF_END doesn't actually refer to the start of the last
> valid CNF register: it's referring to the last byte of the last valid
> CNF register.
>
> This hasn't been a problem up to now, as current implementation in
> memory.c turns an
NRF51_GPIO_REG_CNF_END doesn't actually refer to the start of the last
valid CNF register: it's referring to the last byte of the last valid
CNF register.
This hasn't been a problem up to now, as current implementation in
memory.c turns an unaligned 4-byte read from 0x77f to a single byte read
11 matches
Mail list logo