Re: Is STM32f429 discovery board fully supported on qemu?

Re: Is STM32f429 discovery board fully supported on qemu?

[Philippe Mathieu-Daudé]

Hi Liviu,

On 2/6/20 3:34 PM, Liviu Ionescu wrote:
>> On 6 Feb 2020, at 11:23, Mohannad Maklad <msala.work@gmail.com> wrote:
>>
>> I'm trying to emulate STM32F429I discovery board using qemu & eclipse IDE.
>>
>> I got the blinky example running with the led turning on and off on the graphics screen but I have tried an example to run the on-board screen and it doesn't seem to be running, Is it supported?
>>
>> Also, many drivers fail when simulated with qemu (sdram, rcc, ...) How can I know exactly what peripherals that are fully supported?
>>
> 
> If you are using the xPack QEMU (formerly GNU MCU Eclipse QEMU), the documentation page is:
> 
> https://xpack.github.io/qemu-arm/

https://xpack.github.io/qemu-arm/#why-xpack-qemu-arm

   "Even more, support for semihosting in the public
   QEMU version was broken, and the verbosity required
   for integration with the QEMU plug-in was missing,
   so it could not be used with the GNU MCU Eclipse
   plug-ins."

Too bad these improvements aren't shared with the whole community.

Note there have been a lot of changes/improvements related to ARM 
semihosting recently in the mainstream QEMU.

https://xpack.github.io/qemu-arm/#supported-boards-and-mcus

   The boards currently supported by the xPack QEMU Arm are:

     Maple – LeafLab Arduino-style STM32 microcontroller board
     NUCLEO-F103RB – ST Nucleo Development Board for STM32 F1 series
     NetduinoGo – Netduino GoBus Development Board with STM32F4
     NetduinoPlus2 – Netduino Development Board with STM32F4
     STM32-E407 – Olimex Development Board for STM32F407ZGT6
     STM32-H103 – Olimex Header Board for STM32F103RBT6
     STM32-P103 – Olimex Prototype Board for STM32F103RBT6
     STM32-P107 – Olimex Prototype Board for STM32F107VCT6
     STM32F4-Discovery – ST Discovery kit for STM32F407/417 lines
     STM32F429I-Discovery – ST Discovery kit for STM32F429/439 lines

Quite a nice list, it shouldn't require a lot of effort to contribute 
these boards to the community IMHO.

Regards,

Phil.

Re: Is STM32f429 discovery board fully supported on qemu?

[Liviu Ionescu]

> On 6 Feb 2020, at 16:42, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> 
> https://xpack.github.io/qemu-arm/#why-xpack-qemu-arm
> 
>  "Even more, support for semihosting in the public
>  QEMU version was broken, and the verbosity required
>  for integration with the QEMU plug-in was missing,
>  so it could not be used with the GNU MCU Eclipse
>  plug-ins."
> 
> Too bad these improvements aren't shared with the whole community.

Unfortunately, at that time (several years ago), there was little interest in anything else but Unix class machines, and we could not agree on a common strategy how to handle the changes required by GNU MCU Eclipse, so I had to make a fork.

> Note there have been a lot of changes/improvements related to ARM semihosting recently in the mainstream QEMU.

Yes. Great!

> Quite a nice list, it shouldn't require a lot of effort to contribute these boards to the community IMHO.

If there is interest, please start a new thread and we can discuss how to contribute them back to the main project.



Regards,

Liviu

Re: Is STM32f429 discovery board fully supported on qemu?

[Liviu Ionescu]

> On 6 Feb 2020, at 16:53, Liviu Ionescu <ilg@livius.net> wrote:
> 
> start a new thread

I mean in qemu-dev.

Regards,

Liviu

Re: Is STM32f429 discovery board fully supported on qemu?

[Alex Bennée]

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> Hi Liviu,
>
> On 2/6/20 3:34 PM, Liviu Ionescu wrote:
>>> On 6 Feb 2020, at 11:23, Mohannad Maklad <msala.work@gmail.com> wrote:
>>>
>>> I'm trying to emulate STM32F429I discovery board using qemu & eclipse IDE.
>>>
>>> I got the blinky example running with the led turning on and off on the graphics screen but I have tried an example to run the on-board screen and it doesn't seem to be running, Is it supported?
>>>
>>> Also, many drivers fail when simulated with qemu (sdram, rcc, ...) How can I know exactly what peripherals that are fully supported?
>>>
>> If you are using the xPack QEMU (formerly GNU MCU Eclipse QEMU), the
>> documentation page is:
>> https://xpack.github.io/qemu-arm/
>
> https://xpack.github.io/qemu-arm/#why-xpack-qemu-arm
>
>   "Even more, support for semihosting in the public
>   QEMU version was broken, and the verbosity required
>   for integration with the QEMU plug-in was missing,
>   so it could not be used with the GNU MCU Eclipse
>   plug-ins."
>
> Too bad these improvements aren't shared with the whole community.
>
> Note there have been a lot of changes/improvements related to ARM
> semihosting recently in the mainstream QEMU.

As far as I can tell from a quick glance over:

  git diff v2.8.0..xpack/xpack -- target-arm/

The changes fall into:

  * more cortex-m profile CPUs

  However of the ones we implement in master are more complete
  definitions (cortex_m0/3/4/7/33).

  * tweaks to semihosting fd handling

  This is superseded by the cleanups Peter did for semihosting 2.0
  support

  * a suspect hack for semihosting exit

  I think this is trying to ensure graphics are updated before the exit.
  Arguably we could make fixes to make a semihosting triggered exit more
  uniform (avoiding lots of places forgetting to call gdb_exit and other
  pre-exit handlers). The is probably overlap with things like pvpanic
  and virtio exit code support.

  * extending gdbstub for m-profile

  I think these are mostly status registers fields rather than
  additional system registers which should already be exported by our
  gdbstub.

  * changes to nvic handling for debug states

  I'm not sure I fully follow what is going on here. The larger diff
  seems to import an additional copy of the nvic emulation.

I've not looked at the wider diff as it is quite big. However as far as
I can tell the gdbstub "verbosity" support is basically a bunch of
printf's.

>
> https://xpack.github.io/qemu-arm/#supported-boards-and-mcus
>
>   The boards currently supported by the xPack QEMU Arm are:
>
>     Maple – LeafLab Arduino-style STM32 microcontroller board
>     NUCLEO-F103RB – ST Nucleo Development Board for STM32 F1 series
>     NetduinoGo – Netduino GoBus Development Board with STM32F4
>     NetduinoPlus2 – Netduino Development Board with STM32F4
>     STM32-E407 – Olimex Development Board for STM32F407ZGT6
>     STM32-H103 – Olimex Header Board for STM32F103RBT6
>     STM32-P103 – Olimex Prototype Board for STM32F103RBT6
>     STM32-P107 – Olimex Prototype Board for STM32F107VCT6
>     STM32F4-Discovery – ST Discovery kit for STM32F407/417 lines
>     STM32F429I-Discovery – ST Discovery kit for STM32F429/439 lines
>
> Quite a nice list, it shouldn't require a lot of effort to contribute
> these boards to the community IMHO.

It really depends on if:

  - there is an active maintainer to look after it
  - there is actual demand for it's usage

We should be cautious about importing 3rd party boards because it adds
to QEMUs attack surface and overall maintenance burden.

That said m-profile has been a subject of a lot of work recently.
Linaro's focus has mostly been on providing modern M-profile boards with
interesting architectural features to build on (TrustZone being the big
one). Your work on AVR/Arduino is also interesting because there are a
lot of Arduino's out there so I can see a good use case for supporting
it in QEMU. Random development boards that may have a very limited use
case is less compelling.

However if any of the existing embedded dev houses that already support
QEMU want to reduce their 3rd diff by up-streaming and supporting their
favourite pet board I don't see many objections would be raised.

--
Alex Bennée

Re: Is STM32f429 discovery board fully supported on qemu?

[Liviu Ionescu]

> On 6 Feb 2020, at 18:18, Alex Bennée <alex.bennee@linaro.org> wrote:
> 
>  - there is an active maintainer to look after it

I plan to update xPack QEMU Arm to the latest master, but this will not happen in the first half of the year, most realistically by the end of it.

As it is now, the limited functionality is enough to run my µOS++ tests, which do not require any peripherals, the SysTick and a few LEDs are enough.


Regards,

Liviu