xpack-dev-tools/qemu

A fork of the QEMU project, used to build the xPack QEMU ARM

The xPack fork of qemu.git

This is a fork of https://git.qemu.org/git/qemu.git used to keep the customisations required by the xPack distribution.

The original README is available in the separate README.rst file.

Branches

• master: follows the upstream master
• xpack: includes the released code
• xpack-develop: includes work in progress
• xpack-legacy: the code used in the legacy GNU ARM Eclipse releases
• xpack-legacy-develop: development code for the legacy code

Development takes place in the *-develop branches and the code is merged in the corresponding branches during releases.

Eventual pull requests should be done against the *-develop branches.

Changes

Branded greeting

The greeting message was adjusted to read xPack QEMU emulator version... (d999f1e).

Workaround to make the code build on macOS 10.13

Commit 7e3e20d8 from 23 June 2021 added support for clipboard on macOS, but the code requires macOS 10.14.

The topic was discussed on the qemu-develop mailing list.

The workaround was to conditionally compile the clipboard code only when building on macOS newer than 10.13 (f0419314).

qemu's Issues

STM32F0DISCOVERY emulation fails when accessing MSR

Emulating ARM_v6 seems to have a problem, emulation hangs when accessing MSR registers.

-daemonize failes with "operation not permitted"

Description

emulator does not start with -daemonize option

Steps to Reproduce

works:

$ qemu-system-gnuarmeclipse -board STM32F4-Discovery -mcu STM32F407VG -image some/elf/file -S -nographic
QEMU 2.8.0-9 monitor - type 'help' for more information
(qemu)

fails:

$ qemu-system-gnuarmeclipse -board STM32F4-Discovery -mcu STM32F407VG -image some/elf/file -S -nographic -daemonize
qemu: qemu_mutex_unlock: Operation not permitted

Versions

2.8.0-9.2

Additional information

A quick search bings up this patch

How to add devices

The default board only provides a few devices for use, for example STM32F107VC only provides

'/machine/mcu/stm32/RCC', address: 0x40021000, size: 0x0400
'/machine/mcu/stm32/FLASH', address: 0x40022000, size: 0x0400
'/machine/mcu/stm32/PWR', address: 0x40007000, size: 0x0400
'/machine/mcu/stm32/AFIO', address: 0x40010000, size: 0x0400
'/machine/mcu/stm32/EXTI', address: 0x40010400, size: 0x0400
'/machine/mcu/stm32/GPIOA', address: 0x40010800, size: 0x0400
'/machine/mcu/stm32/GPIOB', address: 0x40010C00, size: 0x0400
'/machine/mcu/stm32/GPIOC', address: 0x40011000, size: 0x0400
'/machine/mcu/stm32/GPIOD', address: 0x40011400, size: 0x0400
'/machine/mcu/stm32/GPIOE', address: 0x40011800, size: 0x0400
GDB Server listening on: 'tcp::1234'...

How to add more devices, such as USART, ADC, etc.
I tried -serial and -chardev to no avail

Starting QEMU via multiple links on macOS fails

On macOS, if QEMU is started via more than two links, the program is not able to identify its location and load the internal files:

ilg@wks blinky-rtos % xpm run run-stm32f4discovery-debug-cmake
> qemu-system-gnuarmeclipse --verbose --verbose --board STM32F4-Discovery -d unimp,guest_errors --nographic --image build/stm32f4discovery-debug-cmake/blinky-rtos.elf --semihosting-config enable=on,target=native --semihosting-cmdline test

xPack 64-bit QEMU v2.8.0-11 (qemu-system-gnuarmeclipse).
Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines).
JSON SVD file '(null)' not found.
ilg@wks blinky-rtos % 

The reason is the faulty mechanism to follow links to identify the executable location.

The problem is old, but was revealed after changing xpm to create relative links in .bin, pointing to the install location in xpacks, generally a link itself.

Picture file 'STM32F429I-Discovery.jpg' not found.

In MacOS, execute the following command:
qemu-system-gnuarmeclipse -d unimp,guest_errors -board STM32F429I-Discovery -image build/*.elf
The error message is "Picture file 'stm32f429i-discovery.jpg' not found."

But I executed the following command and succeeded:
~/Library/xPacks/qemu-arm/2.8.0-8/bin/qemu-system-gnuarmeclipse -d unimp,guest_errors -board STM32F429I-Discovery -image build/*.elf

I don't know what caused this. Does anyone know how to solve this problem?

rom: requested regions overlap

Description

I am running in the exactly the same bug as described here.
In one version of the linker script it works in qemu and not on the board and in the other version it is the other way around.

Explanation and possible fix described in the last comment

Versions

• qemu 2.8.0-12.1
• Debian Stretch

Boards do not use the capabilities RAM size, but 128.

I looks like the change to pass a custom memory size affected the default behaviour, and boards like F1 report 128 kB instead of 20 kB.

Accessing GPIO on STM32F1 fails

ilg-archived/qemu#69

Add support for STM32F407VGTx

Keil STM32F4xx_DFP v2.15.0 changed the STM32F4-Discovery definition and now it uses STM32F407VGTx as mounted device.

Add support for it, same as STM32F407VG.

The same issue for STM32F429ZITx.

How do I use xsvd-js to add new registers to qemu-arm-xpack?

I used xsvd-js to make a lot of .c & .h file, but I don't know how to use them to add new registers to qemu-arm-xpack.

Add STM32F051-Discovery

This is an alias of the STM32F0-DISCOVERY board, used by recent CMSIS packages.

stm32f407 uart input/output

Prerequisites

Check the support page

In case you encounter problems while using the xPack QEMU Arm, please
read carefully the support page.

Discuss the problem in the forums

If you still could not find a solution, if you have interesting use cases,
if you have custom configurations, and generally if you have any
experience that you want to share with others,
use the xPacks forums.

If the forum discussions concluded that you identified a bug, or you have a
pertinent suggestion how to enhance xPack QEMU Arm, continue and register
an issue.

Note: This project is dedicated to building the xPack QEMU Arm and only
issues related to these topics should be registered here; for functional
issues please use the separate
xpack-dev-tools/qemu
project.

Description

[Description of the bug or feature]

Steps to Reproduce

1. [First Step]
2. [Second Step]
3. [and so on...]

Expected behaviour: [What you expected to happen]

Actual behaviour: [What actually happened]

Versions

• QEMU package version
• operating system and version
• toolchain version
• the detailed and complete list of steps to reproduce the bug (mandatory)

Please understand that without being able to reproduce the bug we cannot
identify your problem.

To be allowed to enter issues, you need first to login to GitHub.

Note: the text should respect the markdown syntax; preview the message
before posting and correct if it does not look as expected, especially
inline code or other quoted text.

---

Note: Remove unnecessary text after reading, before entering your ticket.

Application level simulation for STM32F4

Greetings,

I am looking for a way to do application level simulation of an STM32F4 project. The goal is to compile and run the application on the desktop. The key IO being simulated and the rest stubbed out to harmless values. For this application, UART, GPIO, ADC, SPI, and I2C are the critical peripherals which talk to the outside world. Some using DMA.

Most of the QEMU implementations for STM32 platform seems focused on unit tests. This QEMU fork appears to be the most advanced in supporting the STM32F4 boards along with Andre @beckus's (https://github.com/beckus/qemu_stm32).

I suspect this is due to accurate emulation being difficult. That is to say, developing these peripherals and simulating their behavior with QEMU is difficult.

Since my constraints do not necessarily require strict emulation (though it would be nice) and merely simulation, I wonder what the fine developers of this fork might recommend. How would you approach this problem?

Cheers,
Joe

The graphical LEDs on STM32F0DISCOVERY are not visible

The LEDs are correctly implemented, they show messages in the console, but the graphical images are not visible.