No, I've still been meaning to send it. After thinking about this some more
I realized that it didn't actually make sense for the CLINT to decide the
timer frequency and that it should instead be a property of the board
itself. I got a bit sidetracked in the process of making those changes, but
I s
On Fri, 19 Apr 2019 16:05:35 PDT (-0700), alistai...@gmail.com wrote:
On Mon, Apr 15, 2019 at 5:46 PM Jonathan Behrens wrote:
For any chip that has a CLINT, we want the frequency of the time register and
the frequency of the CLINT to match. That frequency, SIFIVE_CLINT_TIMEBASE_FREQ
(=10MHz)
On Mon, Apr 15, 2019 at 5:46 PM Jonathan Behrens wrote:
>
> For any chip that has a CLINT, we want the frequency of the time register and
> the frequency of the CLINT to match. That frequency,
> SIFIVE_CLINT_TIMEBASE_FREQ (=10MHz) is currently defined in
> hw/riscv/sifive_clint.h and so isn't v
For any chip that has a CLINT, we want the frequency of the time register
and the frequency of the CLINT to match. That frequency,
SIFIVE_CLINT_TIMEBASE_FREQ
(=10MHz) is currently defined in hw/riscv/sifive_clint.h and so isn't
visible to target/riscv/cpu.c where the CPURISCVState is first created.
On Fri, Apr 12, 2019 at 12:04 PM Jonathan Behrens wrote:
>
> Currently mcounteren.TM acts as though it is hardwired to zero, even though
> QEMU
> allows it to be set. This change resolves the issue by allowing reads to the
> time and timeh control registers when running in a privileged mode where
Currently mcounteren.TM acts as though it is hardwired to zero, even though
QEMU
allows it to be set. This change resolves the issue by allowing reads to the
time and timeh control registers when running in a privileged mode where
such
accesses are allowed.
Signed-off-by: Jonathan Behrens
---
hw
