casaroli opened a new pull request, #19765:
URL: https://github.com/apache/nuttx/pull/19765
## Summary
QEMU has a machine model with the name `b-l475e-iot01a`. The model includes
the STM32L4x5 core devices, but it does not include the QUADSPI controller. It
also does not include the MX25R6435F flash memory of the board.
The `nsh` configuration sets `CONFIG_B_L475E_IOT01A_MTD_FLASH`. That symbol
selects the QUADSPI driver, the MTD layer, the MX25RXX driver and SMARTFS. The
board start-up code thus starts the QUADSPI driver. On QEMU the code stops with
a panic in `qspi_command()`. The call comes from `stm32_qspi_initialize()` and
then `mx25rxx_initialize()`. The console shows no output before the panic. You
therefore cannot use the `nsh` configuration with QEMU.
This change adds a `qemu` configuration for the same board. The new
configuration is the same as `nsh`, but it does not set
`CONFIG_B_L475E_IOT01A_MTD_FLASH`. It also does not set the symbols that this
symbol selects. The board thus has no external flash memory, and the start-up
code does not touch the QUADSPI controller.
The new configuration starts correctly on QEMU and shows an NSH prompt on
USART1. Use this command:
```
qemu-system-arm -M b-l475e-iot01a -nographic -kernel nuttx
```
This change also adds a section about the new configuration to the board
documentation.
These are the settings that the new `defconfig` does not have. The `nsh`
`defconfig` has all of them:
```
CONFIG_B_L475E_IOT01A_MTD_FLASH=y
CONFIG_B_L475E_IOT01A_MTD_PART=y
CONFIG_B_L475E_IOT01A_MTD_PART_LIST="16,64,128,128"
CONFIG_MTD_SMART_SECTOR_SIZE=512
CONFIG_MX25RXX_SECTOR512=y
CONFIG_NSH_DISABLE_LOSMART=y
CONFIG_STM32_QSPI_FLASH_SIZE=8388608
```
## Impact
- This change adds one new board configuration. It does not change the
source code.
- The `nsh` configuration and the three `spirit-*` configurations stay the
same. Users of these configurations see no change.
- The build process stays the same. The new configuration uses the same
tools and the same procedure as the other configurations of this board.
- The new configuration is for QEMU. Do not use it on the physical board,
because the configuration has no driver for the external flash memory.
- The documentation of the board has one new section.
- There is no effect on the API, on security or on compatibility.
## Testing
Build host:
- macOS 26.5.1 on arm64
- Arm GNU Toolchain 14.2.Rel1, `arm-none-eabi-gcc` 14.2.1 20241119
- QEMU 11.0.3
Target: the QEMU `b-l475e-iot01a` machine. I did not use a physical board,
because this change is only for QEMU.
Base commit: `baea3523742bdfc0123d6246fe6bb24d4c771623`
### Before the change: `b-l475e-iot01a:nsh` on QEMU
```
$ ./tools/configure.sh b-l475e-iot01a:nsh && make olddefconfig && make -j8
$ arm-none-eabi-size nuttx
text data bss dec hex filename
113744 1476 5016 120236 1d5ac nuttx
$ qemu-system-arm -M b-l475e-iot01a -nographic -kernel nuttx
dump_assert_info: Current Version: NuttX 13.0.0 de8ab5d1f3-dirty Aug 10
2026 13:17:00 arm
dump_assert_info: Assertion failed panic: at file: :0 task: AppBringUp
process: Kernel 0x8001199
up_dump_register: R0: 200000e0 R1: 0000001b R2: a0001000 R3: a000100c
up_dump_register: R4: 20002890 R5: 200000e0 R6: 00000000 FP: 00000000
up_dump_register: R8: 00000000 SB: 00000000 SL: 00000000 R11: 00000000
up_dump_register: IP: 00000000 SP: 20002860 LR: 080084cf PC: 080084d4
up_dump_register: xPSR: 01000000 BASEPRI: 00000000 CONTROL: 00000000
up_dump_register: EXC_RETURN: ffffffe9
dump_stackinfo: User Stack:
dump_stackinfo: base: 0x200021a8
dump_stackinfo: size: 00002000
dump_stackinfo: sp: 0x20002860
dump_tasks: PID GROUP PRI POLICY TYPE NPX STATE EVENT SIGMASK
STACKBASE STACKSIZE COMMAND
dump_task: 0 0 0 FIFO Kthread - Ready
0000000000000000 0x20001980 1000 Idle_Task
dump_task: 1 0 240 RR Kthread - Running
0000000000000000 0x200021a8 2000 AppBringUp
```
I removed the register dump lines of the stack from the log above. The `PC`
value `0x080084d4` and the `LR` value `0x080084cf` are both in `qspi_command()`:
```
$ arm-none-eabi-addr2line -f -e nuttx 0x080084d4 0x080084cf 0x08003b15
0x08003edf 0x080087d1
qspi_command
stm32l4_qspi.c:?
qspi_command
stm32l4_qspi.c:?
mx25rxx_command_read.isra.0
mx25rxx.c:?
mx25rxx_initialize
??:?
stm32_qspi_initialize
??:?
```
### After the change: `b-l475e-iot01a:qemu` on QEMU
```
$ make distclean
$ ./tools/configure.sh b-l475e-iot01a:qemu && make olddefconfig && make -j8
$ arm-none-eabi-size nuttx
text data bss dec hex filename
91800 888 5000 97688 17d98 nuttx
$ qemu-system-arm -M b-l475e-iot01a -nographic -kernel nuttx
NuttShell (NSH) NuttX-13.0.0
nsh> uname -a
NuttX 13.0.0 de8ab5d1f3-dirty Aug 10 2026 13:17:31 arm b-l475e-iot01a
nsh> free
total used free maxused maxfree nused nfree name
91384 5728 85656 6520 85232 22 2 Umem
nsh> ls /dev
/dev:
console
null
ttyS0
zero
nsh> ps
TID PID PPID PRI POLICY TYPE NPX STATE EVENT SIGMASK
STACK COMMAND
0 0 0 0 FIFO Kthread - Ready
0000000000000000 0001000 Idle_Task
2 2 0 100 RR Task - Running
0000000000000000 0002000 nsh_main
```
The version strings show `-dirty` because I made the build in a work tree
that also contains the build files.
### Style check
```
$ ./tools/checkpatch.sh -c -u -m -g master..HEAD
Used config files:
1: .codespellrc
✔️ All checks pass.
```
### A known problem in the QEMU USART model
The file `hw/char/stm32l4x5_usart.c` in QEMU does not call
`qemu_chr_fe_accept_input()`. A read of the `RDR` register clears the `RXNE`
flag, but the character device front end does not start to accept data again.
If you send a full command line to the console at one time, the console keeps
only the first character or the first two characters. If a person types the
characters, the console operates correctly, because each character comes after
the guest reads the previous character.
A QEMU trace shows this behaviour. The trace contains only one receive event
for the eight characters of the command `uname -a`, and it contains no overrun
event:
```
$ { sleep 3; printf 'uname -a\n'; sleep 4; } | \
timeout 10 qemu-system-arm -M b-l475e-iot01a -nographic -kernel nuttx \
--trace 'stm32l4x5_usart_*' -D trace.log
$ grep 'usart_rx\|overrun' trace.log
stm32l4x5_usart_rx USART: got character 0x75 from backend
```
This problem is in QEMU. This change is not the cause of the problem. The
new documentation section gives a note about it, because the note helps a
person who tests a NuttX change with a script.
## References
- QEMU machine model:
[`hw/arm/b-l475e-iot01a.c`](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/arm/b-l475e-iot01a.c)
- QEMU USART model:
[`hw/char/stm32l4x5_usart.c`](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/char/stm32l4x5_usart.c)
There are no dependencies. This change needs no change in `nuttx-apps`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
