[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Add NRF51 RNG peripheral

From: Steffen Görtz
Subject: Re: [Qemu-devel] [RFC] Add NRF51 RNG peripheral
Date: Tue, 26 Jun 2018 12:37:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

Hi Stefan,>
>> +static void nrf51_rng_timer_expire(void *opaque) {
>> +    Nrf51RNGState *s = NRF51_RNG(opaque);
>> +
>> +    qcrypto_random_bytes(&s->value, 1, NULL);
>> +
>> +    s->state.event_valrdy = 1;
>> +    qemu_set_irq(s->eep_valrdy, 1);
>> +
>> +    if(s->state.interrupt_enabled) {
>> +        qemu_irq_pulse(s->irq);
>> +    }
> Why does eep_valrdy use qemu_set_irq() while s->irq uses
> qemu_irq_pulse()?  I don't see a many other qemu_irq_pulse() instances
> in hw/arm/ so I'm curious why it was necessary.
The "real" ARM armv7m NVIC supports both level and pulsed interrupt
lines from connected devices (see ARM TRM cortex-m 8.3. Level versus
pulse interrupts). Level interrupts require (both in "real" and modeled
devices) some kind of interrupt flag held in the context of the device,
which is reflected in the device interrupt line.

The Nrf51 RNG peripheral does not have a peripheral interrupt status
register neither does it have a interrupt status flag. Furthermore the
nature of the timer expire tick is of a pulsed rather then a stateful

The model of the ARM armv7m NVIC (armv7m_nvic.c) also supports pulsed
interrupts sources, see set_irq_level:

>/* The pending status of an external interrupt is
> * latched on rising edge and exception handler return.
> *
> * Pulsing the IRQ will always run the handler
> * once, and the handler will re-run until the
> * level is low when the handler completes.

I used the pulsed implementation because it was more straightforward to
use in this situation.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]