Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hw/xtensa: build fixes for building on 32 bit x86/arm (QEMU-165) #86

Closed

Conversation

greenaddress
Copy link

I tried to build qemu esp32 latest tag/release on a linux 32 bit x86 docker and on a raspberry pi with 32 bit os and it failed with

../hw/xtensa/esp32.c: In function 'esp32_soc_realize':
../hw/xtensa/esp32.c:282:53: error: '%d' directive output may be truncated writing between 1 and 8 bytes into a region of size 2 [-Werror=format-truncation=]
  282 |         snprintf(name, sizeof(name), "esp32.irom.cpu%d", i);
      |                                                     ^~
../hw/xtensa/esp32.c:282:38: note: directive argument in the range [0, 27531842]
  282 |         snprintf(name, sizeof(name), "esp32.irom.cpu%d", i);
      |                                      ^~~~~~~~~~~~~~~~~~
In file included from /usr/include/stdio.h:867,
                 from /qemu/include/qemu/osdep.h:97,
                 from ../hw/xtensa/esp32.c:11:
/usr/include/i386-linux-gnu/bits/stdio2.h:67:10: note: '__builtin___snprintf_chk' output between 16 and 23 bytes into a destination of size 16
   67 |   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   68 |        __bos (__s), __fmt, __va_arg_pack ());
      |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../hw/xtensa/esp32.c:288:53: error: '%d' directive output may be truncated writing between 1 and 8 bytes into a region of size 2 [-Werror=format-truncation=]
  288 |         snprintf(name, sizeof(name), "esp32.drom.cpu%d", i);
      |                                                     ^~
../hw/xtensa/esp32.c:288:38: note: directive argument in the range [0, 27531842]
  288 |         snprintf(name, sizeof(name), "esp32.drom.cpu%d", i);
      |                                      ^~~~~~~~~~~~~~~~~~
In file included from /usr/include/stdio.h:867,
                 from /qemu/include/qemu/osdep.h:97,
                 from ../hw/xtensa/esp32.c:11:
/usr/include/i386-linux-gnu/bits/stdio2.h:67:10: note: '__builtin___snprintf_chk' output between 16 and 23 bytes into a destination of size 16
   67 |   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   68 |        __bos (__s), __fmt, __va_arg_pack ());
      |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
ninja: build stopped: subcommand failed.

This patch fixes it for me, feel free to squash

igrr and others added 30 commits May 22, 2023 14:17
Co-authored-by: Anton Maklakov <anton@espressif.com>
Co-authored-by: Omar Chebib <omar.chebib@espressif.com>
GDB considers window registers as pseudo registers, meaning that they
are calculated by GDB using the values of AR registers and windowbase.
This patch removes the window registers from the total number of
registers that QEMU will send to GDB, making the number of registers
match the one that GDB expects to see.
This commit introduces two environment variables which can be used
to adjust the list of registers sent from QEMU to GDB:
* If QEMU_XTENSA_CORE_REGS_ONLY is set, only non-privileged registers
  will be sent to GDB. This behavior is compatible with Espressif
  builds of GDB up to esp-2021r1.
* If QEMU_XTENSA_COUNT_WINDOW_REGS is set, QEMU will send window
  registers (a0-a15) to GDB. Enable this if you don't have a build of
  GDB which considers a0-a15 to be "raw" registers.
DP83848C PHY emulated by opencores_eth has several vendor-specific
MII registers at 0x10-0x1d. Reading these registers resulted in an
out-of-bounds access to the regs array.
Part of this commit adds bounds checking.
Since the PHYSTS vendor-specific register is accessed by some of the
embedded DP83848C drivers, the rest of the commit adds simple
emulation of this register, setting the bits depending on the link
status.
Co-authored-by: Maksim Naumenko <maksim.naumenko@espressif.com>
This is an SSIPeripheral instance that knows how to respond to read_id
command. It doesn't store any data. It is sufficient for the IDF
driver to decide to turn on the PSRAM cache. Actual data storage in
PSRAM is emulated in DPORT.
Espressif RISC-V CPU has a different has way of treating interrupts, which is
not standard. Thus, this class will override the default RISC-V CPU behavior
to have 31 interrupt lines.
C3 UART overrides ESP32's UART
o-marshmallow and others added 19 commits June 2, 2023 12:29
* Closes espressif#75

These commands are used by when bootstraping the chip. This lets
the `esptool` flash any image to the emulated SPI flash.
… legacy synonym

The xkb official name for the Arabic keyboard layout is 'ara'.
However xkb has for at least the past 15 years also permitted it to
be named via the legacy synonym 'ar'.  In xkeyboard-config 2.39 this
synoynm was removed, which breaks compilation of QEMU:

FAILED: pc-bios/keymaps/ar
/home/fred/qemu-git/src/qemu/build-full/qemu-keymap -f pc-bios/keymaps/ar -l ar
xkbcommon: ERROR: Couldn't find file "symbols/ar" in include paths
xkbcommon: ERROR: 1 include paths searched:
xkbcommon: ERROR: 	/usr/share/X11/xkb
xkbcommon: ERROR: 3 include paths could not be added:
xkbcommon: ERROR: 	/home/fred/.config/xkb
xkbcommon: ERROR: 	/home/fred/.xkb
xkbcommon: ERROR: 	/etc/xkb
xkbcommon: ERROR: Abandoning symbols file "(unnamed)"
xkbcommon: ERROR: Failed to compile xkb_symbols
xkbcommon: ERROR: Failed to compile keymap

The upstream xkeyboard-config change removing the compat
mapping is:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/commit/470ad2cd8fea84d7210377161d86b31999bb5ea6

Make QEMU always ask for the 'ara' xkb layout, which should work on
both older and newer xkeyboard-config.  We leave the QEMU name for
this keyboard layout as 'ar'; it is not the only one where our name
for it deviates from the xkb standard name.

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20230620162024.1132013-1-peter.maydell@linaro.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1709
Implement a first interface for Peripheral-to-Memory and Memory-to-Peripheral
transfers.
Cache entries where incorrectly described, which resulted in wrong values
being returned to the guest programs.
APIs added:
- get key
- get key purpose
Added an internal HMAC implementation using the existing internal SHA APIs
@github-actions github-actions bot changed the title hw/xtensa: build fixes for building on 32 bit x86/arm hw/xtensa: build fixes for building on 32 bit x86/arm (QEMU-165) Sep 20, 2023
@espressif-bot espressif-bot added Status: In Progress work is in progress and removed Status: To Do labels Dec 5, 2023
@igrr
Copy link
Member

igrr commented Dec 7, 2023

Have cherry-picked and released in https://github.com/espressif/qemu/releases/tag/esp-develop-8.1.3-20231206, thanks @greenaddress!

@igrr igrr closed this Dec 7, 2023
@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: Done Issue is done internally and removed Status: In Progress work is in progress labels Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants