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

mps2_an521: no input to shell from Windows qemu host #30770

Closed
sw opened this issue Dec 16, 2020 · 3 comments · Fixed by #32335
Closed

mps2_an521: no input to shell from Windows qemu host #30770

sw opened this issue Dec 16, 2020 · 3 comments · Fixed by #32335
Assignees
Labels
area: UART Universal Asynchronous Receiver-Transmitter bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@sw
Copy link
Contributor

sw commented Dec 16, 2020

Describe the bug
Trying to run a sample with shell functionality and have it work in an emulated ARM machine on a Windows host.
The sample runs and prints the shell prompt, but no input from keyboard is possible.

To Reproduce
Run in Windows command prompt (cmd):

west init
west update
set "GNUARMEMB_TOOLCHAIN_PATH=%ProgramFiles(x86)%\GNU Arm Embedded Toolchain\9 2020-q2-update"
set ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
cd zephyr
west build -b mps2_an521 -t run samples\subsys\shell\shell_module -- -DQEMU="%ProgramFiles%\qemu\qemu-system-arm.exe"

Expected behavior
I expect to be able to enter shell commands and have them executed.

Impact
Prevents manual use of shell for testing/dev purposes

Logs and console output

C:\work\hydra\qemu\zephyr>west build -b mps2_an521 -t run samples\subsys\shell\shell_module -- -DQEMU="%ProgramFiles%\qemu\qemu-system-arm.exe"
-- west build: generating a build system
Including boilerplate (Zephyr base (cached)): C:/work/hydra/qemu/zephyr/cmake/app/boilerplate.cmake
-- Application: C:/work/hydra/qemu/zephyr/samples/subsys/shell/shell_module
-- Zephyr version: 2.4.99 (C:/work/hydra/qemu/zephyr)
-- Found west (found suitable version "0.8.0", minimum required is "0.7.1")
-- Board: mps2_an521
-- Cache files will be written to: C:\Users\walter\AppData\Local/.cache/zephyr
-- Found dtc: C:/ProgramData/chocolatey/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (C:/Program Files (x86)/GNU Arm Embedded Toolchain/9 2020-q2-update)
-- Found BOARD.dts: C:/work/hydra/qemu/zephyr/boards/arm/mps2_an521/mps2_an521.dts
-- Generated zephyr.dts: C:/work/hydra/qemu/zephyr/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: C:/work/hydra/qemu/zephyr/build/zephyr/include/generated/devicetree_unfixed.h
Parsing C:/work/hydra/qemu/zephyr/samples/subsys/shell/shell_module/Kconfig
Loaded configuration 'C:/work/hydra/qemu/zephyr/build/zephyr/.config'
No change to configuration in 'C:/work/hydra/qemu/zephyr/build/zephyr/.config'
No change to Kconfig header in 'C:/work/hydra/qemu/zephyr/build/zephyr/include/generated/autoconf.h'
-- Configuring done
-- Generating done
-- Build files have been written to: C:/work/hydra/qemu/zephyr/build
-- west build: running target run
[121/126] Linking C executable zephyr\zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       54520 B       224 MB      0.02%
            SRAM:       11536 B        16 MB      0.07%
        IDT_LIST:         200 B         2 KB      9.77%
[125/126] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: cortex-m33
C:\Program Files\qemu\qemu-system-arm.exe: warning: nic lan9118.0 has no peer


uart:~$

Environment (please complete the following information):
Windows 10
QEMU version 5.1.92 (v5.2.0-rc2-11843-gf571c4ffb5-dirty)

Additional context
What's the correct way of specifying the Qemu path? Setting the QEMU_BIN_PATH environment variable doesn't seem to work.

We are using the board mps2_an521 because that seems to be the only emulated board with a Cortex-M33 processor. We would really like to emulate an nRF5340.

@sw sw added the bug The issue is a bug, or the PR is fixing a bug label Dec 16, 2020
@sw
Copy link
Contributor Author

sw commented Dec 17, 2020

cmake/emu/qemu.cmake uses find_program to find QEMU, but doesn't specify the .exe suffix. I suspect that is why setting the QEMU_BIN_PATH env variable doesn't work.

After changing line 17 as follows, setting QEMU_BIN_PATH will work:

  NAMES qemu-system-${QEMU_binary_suffix} qemu-system-${QEMU_binary_suffix}.exe

@sw
Copy link
Contributor Author

sw commented Dec 22, 2020

Serial input is working with board qemu_cortex_m3, so this may be a problem with the uart_cmsdk_apb driver not working properly in qemu

@sw sw changed the title no input to shell from Windows qemu host mps2_an521: no input to shell from Windows qemu host Dec 22, 2020
@nashif
Copy link
Member

nashif commented Jan 5, 2021

FFIW this is not related to Windows.

@nashif nashif added the priority: low Low impact/importance bug label Jan 5, 2021
@nashif nashif added the area: UART Universal Asynchronous Receiver-Transmitter label Jan 12, 2021
@galak galak self-assigned this Feb 13, 2021
galak added a commit to galak/zephyr that referenced this issue Feb 15, 2021
The CMSDK uart interrupts for TX and RX can either be treated as a
signel interrupt line or distinct interrupts for TX & RX.  In the case
that they were distinct we didn't get the ifdef correct based on DTS.

If we have 2 interrupts in DTS we assume they are for TX & RX and thus
build the interrupt support for distinct TX & RX ISRs.

Also, cleanup handling of UART_2..UART_4 to be similar to how
UART_0/UART_1 code is using DT_INST_IRQN(x).

Fixes zephyrproject-rtos#30770
Fixes zephyrproject-rtos#25601

Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
nashif pushed a commit that referenced this issue Feb 15, 2021
The CMSDK uart interrupts for TX and RX can either be treated as a
signel interrupt line or distinct interrupts for TX & RX.  In the case
that they were distinct we didn't get the ifdef correct based on DTS.

If we have 2 interrupts in DTS we assume they are for TX & RX and thus
build the interrupt support for distinct TX & RX ISRs.

Also, cleanup handling of UART_2..UART_4 to be similar to how
UART_0/UART_1 code is using DT_INST_IRQN(x).

Fixes #30770
Fixes #25601

Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
zephyrbot pushed a commit that referenced this issue Apr 7, 2021
The CMSDK uart interrupts for TX and RX can either be treated as a
signel interrupt line or distinct interrupts for TX & RX.  In the case
that they were distinct we didn't get the ifdef correct based on DTS.

If we have 2 interrupts in DTS we assume they are for TX & RX and thus
build the interrupt support for distinct TX & RX ISRs.

Also, cleanup handling of UART_2..UART_4 to be similar to how
UART_0/UART_1 code is using DT_INST_IRQN(x).

Fixes #30770
Fixes #25601

Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
galak added a commit that referenced this issue Apr 8, 2021
The CMSDK uart interrupts for TX and RX can either be treated as a
signel interrupt line or distinct interrupts for TX & RX.  In the case
that they were distinct we didn't get the ifdef correct based on DTS.

If we have 2 interrupts in DTS we assume they are for TX & RX and thus
build the interrupt support for distinct TX & RX ISRs.

Also, cleanup handling of UART_2..UART_4 to be similar to how
UART_0/UART_1 code is using DT_INST_IRQN(x).

Fixes #30770
Fixes #25601

Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: UART Universal Asynchronous Receiver-Transmitter bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants