GPIO state in qemu

GPIO state in qemu

[Joel Stanley]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

At the osfc hackathon today James and I were talking about Qemu's new
support for modelling GPIOs. Here's some documentation on how it can be
used.

To set a pin's state in the monitor:

qom-set gpio gpioA0 true

To do the equivalent in code:

object_property_set_bool(OBJECT(&s->gpio), true, "gpioA0", &error_abort);

Thanks Rashmica for writing the model and Cedric for the tips.

Cheers,

Joel

[-- Attachment #2: Type: text/html, Size: 858 bytes --]

Re: GPIO state in qemu

[James Feist]

On 9/6/19 11:05 AM, Joel Stanley wrote:
> At the osfc hackathon today James and I were talking about Qemu's new 
> support for modelling GPIOs. Here's some documentation on how it can be 
> used.
> 
> To set a pin's state in the monitor:
> 
> qom-set gpio gpioA0 true
> 
> To do the equivalent in code:
> 
> object_property_set_bool(OBJECT(&s->gpio), true, "gpioA0", &error_abort);

I'm trying to use object_property_set_bool in hw/arm/aspeed.c in an 
i2c_init block and I'm noticing by the time uboot is reached that the 
registers are reset back to the default. If I use qom-set it seems to 
work correctly. Where is the correct place to put the 
object_property_set_bool so that it doesn't get reset by the time it's 
ready to be read? Does AspeedBoardConfig need a gpio_init as well as an 
i2c_init?

Thanks,

-James



> 
> Thanks Rashmica for writing the model and Cedric for the tips.
> 
> Cheers,
> 
> Joel
> 
> 

Re: GPIO state in qemu

[Cédric Le Goater]

On 09/09/2019 18:20, James Feist wrote:
> On 9/6/19 11:05 AM, Joel Stanley wrote:
>> At the osfc hackathon today James and I were talking about Qemu's new support for modelling GPIOs. Here's some documentation on how it can be used.
>>
>> To set a pin's state in the monitor:
>>
>> qom-set gpio gpioA0 true
>>
>> To do the equivalent in code:
>>
>> object_property_set_bool(OBJECT(&s->gpio), true, "gpioA0", &error_abort);
> 
> I'm trying to use object_property_set_bool in hw/arm/aspeed.c in an i2c_init block and I'm noticing by the time uboot is reached that the registers are reset back to the default. 

These routines are called before the machine and devices are reseted.

> If I use qom-set it seems to work correctly. 

The machine has been reseted.

> Where is the correct place to put the object_property_set_bool so that it doesn't get reset by the time it's ready to be read? Does AspeedBoardConfig need a gpio_init as well as an i2c_init?
 
we would need to change the default reset value in the reset handler
of the GPIO device model : aspeed_gpio_reset(). We don't have a way 
to set default values yet, all 0s for now.

Rashmica,

Would it be complex to add a set of default values with which we 
could memset the ->sets array in the reset handler() like we do 
for SCU ? 

Having a different set of default values per machine would require 
a second set of properties under AspeedGPIOState and some slight 
rework of aspeed_gpio_get/set_pin.

Didn't you have a patch for reset tolerant values some time ago ? 
 
Thanks,

C.

Re: GPIO state in qemu

[Rashmica Gupta]

On Mon, 2019-09-09 at 19:02 +0200, Cédric Le Goater wrote:
> On 09/09/2019 18:20, James Feist wrote:
> > On 9/6/19 11:05 AM, Joel Stanley wrote:
> > > At the osfc hackathon today James and I were talking about Qemu's
> > > new support for modelling GPIOs. Here's some documentation on how
> > > it can be used.
> > > 
> > > To set a pin's state in the monitor:
> > > 
> > > qom-set gpio gpioA0 true
> > > 
> > > To do the equivalent in code:
> > > 
> > > object_property_set_bool(OBJECT(&s->gpio), true, "gpioA0",
> > > &error_abort);
> > 
> > I'm trying to use object_property_set_bool in hw/arm/aspeed.c in an
> > i2c_init block and I'm noticing by the time uboot is reached that
> > the registers are reset back to the default. 
> 
> These routines are called before the machine and devices are reseted.
> 
> > If I use qom-set it seems to work correctly. 
> 
> The machine has been reseted.
> 
> > Where is the correct place to put the object_property_set_bool so
> > that it doesn't get reset by the time it's ready to be read? Does
> > AspeedBoardConfig need a gpio_init as well as an i2c_init?
>  
> we would need to change the default reset value in the reset handler
> of the GPIO device model : aspeed_gpio_reset(). We don't have a way 
> to set default values yet, all 0s for now.
> 
> Rashmica,
> 
> Would it be complex to add a set of default values with which we 
> could memset the ->sets array in the reset handler() like we do 
> for SCU ? 
>

I think it should be pretty straightforward. Do we want one statically
defined set of default values per SoC version?

> Having a different set of default values per machine would require 
> a second set of properties under AspeedGPIOState and some slight 
> rework of aspeed_gpio_get/set_pin.
> 

Why would it require rework of get/set pin?

> Didn't you have a patch for reset tolerant values some time ago ? 
>  

Yes, but it was a bit hacky and I didn't have a good way to test it. We
need to share a property with the wdt and differentiate between a SoC
reset, full system reset and a full wdt reset. Iirc we only use the
reset tolerant values for a SoC reset? I assume we would want to set
the default values for all three types of reset?



> Thanks,
> 
> C.

Re: GPIO state in qemu

[Cédric Le Goater]

On 11/09/2019 03:12, Rashmica Gupta wrote:
> On Mon, 2019-09-09 at 19:02 +0200, Cédric Le Goater wrote:
>> On 09/09/2019 18:20, James Feist wrote:
>>> On 9/6/19 11:05 AM, Joel Stanley wrote:
>>>> At the osfc hackathon today James and I were talking about Qemu's
>>>> new support for modelling GPIOs. Here's some documentation on how
>>>> it can be used.
>>>>
>>>> To set a pin's state in the monitor:
>>>>
>>>> qom-set gpio gpioA0 true
>>>>
>>>> To do the equivalent in code:
>>>>
>>>> object_property_set_bool(OBJECT(&s->gpio), true, "gpioA0",
>>>> &error_abort);
>>>
>>> I'm trying to use object_property_set_bool in hw/arm/aspeed.c in an
>>> i2c_init block and I'm noticing by the time uboot is reached that
>>> the registers are reset back to the default. 
>>
>> These routines are called before the machine and devices are reseted.
>>
>>> If I use qom-set it seems to work correctly. 
>>
>> The machine has been reseted.
>>
>>> Where is the correct place to put the object_property_set_bool so
>>> that it doesn't get reset by the time it's ready to be read? Does
>>> AspeedBoardConfig need a gpio_init as well as an i2c_init?
>>  
>> we would need to change the default reset value in the reset handler
>> of the GPIO device model : aspeed_gpio_reset(). We don't have a way 
>> to set default values yet, all 0s for now.
>>
>> Rashmica,
>>
>> Would it be complex to add a set of default values with which we 
>> could memset the ->sets array in the reset handler() like we do 
>> for SCU ? 
>>
> 
> I think it should be pretty straightforward. Do we want one statically
> defined set of default values per SoC version?

yes, to start with, like we do in SCU. 

But we would need a property for the specific needs of a board, which 
value would override the default SoC reset values. 

>> Having a different set of default values per machine would require 
>> a second set of properties under AspeedGPIOState and some slight 
>> rework of aspeed_gpio_get/set_pin.
> 
> Why would it require rework of get/set pin?

because we would only need the logic to set the value and the helper 
aspeed_gpio_update() does more. 

C.