code_relocation_nocopy sample for stm32h7b3i_dk ospi mapped NOR - #1
Open
ajhemphill91 wants to merge 12 commits into
Open
code_relocation_nocopy sample for stm32h7b3i_dk ospi mapped NOR#1ajhemphill91 wants to merge 12 commits into
ajhemphill91 wants to merge 12 commits into
Conversation
This CONFIG_STM32_XIP is for enabling the MemoryMapped mode on external octo or quad spi memory. Signed-off-by: Francois Ramu <francois.ramu@st.com>
Enable the MemoryMapped Mode for the stm32 octoFlash driver Configure the Flash in MemoryMapped to use memcopy for writing/reading. TBC for erasing command. Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add a function to check the octospi controller and return true if the octo-SPI NOR is configured in memorymapped mode (else false) Signed-off-by: Francois Ramu <francois.ramu@st.com>
Use the device tree to define the external NOR flash base address Put this as a field of the device configuration structure. Signed-off-by: Francois Ramu <francois.ramu@st.com>
Enable the DCACHE1 in INCR burt mode to allow writing to the external NOR octoFlash when in MemoryMapped mode Signed-off-by: Francois Ramu <francois.ramu@st.com>
Define the Device tree of the b_u585i_iot02a disco kit to access the external NOR octo-flash in MemoryMapped mode for XiP Signed-off-by: Francois Ramu <francois.ramu@st.com>
Add the MPU_REGION_ENTRY for the NOR flash memory with STRONGLY_ORDERED_SHAREABLE attribute Signed-off-by: Francois Ramu <francois.ramu@st.com>
Define the node of the qspi/ospi external NOR flash for the stm32h7x serie Signed-off-by: Francois Ramu <francois.ramu@st.com>
Define the Device tree of the stm32h7b3i_dk disco board to access the external NOR octo-flash in MemoryMapped mode for XiP Set openocd runner for debugging. Signed-off-by: Francois Ramu <francois.ramu@st.com>
Define the Device tree of the stm32h735g_disco board to access the external NOR octo-flash in MemoryMapped mode for XiP Signed-off-by: Francois Ramu <francois.ramu@st.com>
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
from
September 20, 2023 08:38
3f1c537 to
cccc2c6
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
from
October 2, 2023 07:40
cccc2c6 to
fcac3e8
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
16 times, most recently
from
October 31, 2023 15:41
bd2be46 to
ead4df7
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
2 times, most recently
from
November 6, 2023 16:14
dd54d1c to
5a91280
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
from
December 12, 2023 14:58
5a91280 to
045dbbb
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
from
January 23, 2024 14:57
045dbbb to
f6dfcb1
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
3 times, most recently
from
January 24, 2024 12:00
588b336 to
61e3968
Compare
FRASTM
pushed a commit
that referenced
this pull request
Jan 25, 2024
Previously the sample was using some headers that aren't
available to the host, now we can add a `Makefile.host` to
compile the example on a POSIX OS like Linux:
```
# Go to the sample dir
cd ${ZEPHYR_BASE}/samples/posix/uname
# Compile the sample
make -f Makefile.host
# Run the binary
./build/uname
sysname[65]: Linux
nodename[65]: LAPTOP-YC
release[65]: 5.10.16.3-microsoft-standard-WSL2
version[65]: #1 SMP Fri Apr 2 22:23:49 UTC 2021
machine[65]: x86_64
```
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
2 times, most recently
from
January 29, 2024 16:12
00ca393 to
c54eca3
Compare
FRASTM
pushed a commit
that referenced
this pull request
Oct 25, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.
==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68
READ of size 2 at 0x000000ad81c2 thread T6
#0 0x5279b2 (/root/zephyr.exe+0x5279b2)
#1 0x4d697d (/root/zephyr.exe+0x4d697d)
zephyrproject-rtos#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x530192 (/root/zephyr.exe+0x530192)
zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T2 created by T1 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x530192 (/root/zephyr.exe+0x530192)
zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22)
Thread T1 created by T0 here:
#0 0x48c17c (/root/zephyr.exe+0x48c17c)
#1 0x52f36c (/root/zephyr.exe+0x52f36c)
zephyrproject-rtos#2 0x5371dc (/root/zephyr.exe+0x5371dc)
zephyrproject-rtos#3 0x5312a6 (/root/zephyr.exe+0x5312a6)
zephyrproject-rtos#4 0x52ed7b (/root/zephyr.exe+0x52ed7b)
zephyrproject-rtos#5 0x52eddd (/root/zephyr.exe+0x52eddd)
zephyrproject-rtos#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)
==5==ABORTING
Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
FRASTM
pushed a commit
that referenced
this pull request
Nov 13, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.
This causes problems two-fold with checksum calculations:
1. The "config" isn't uninitialized, so, every call returns differnet
values. So, for UDP header checksum would be done and
pkt->chksumdone would be set. But for IPv4 header checksum might be
skipped.
2. Even if we initialize to zero, then network stack gets all zeros
and calculates checksum by itself rendering offload moot.
There is another problem in #1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).
But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.
Upstream PR #: 80882
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
2 times, most recently
from
March 14, 2025 09:45
2ec15cd to
c54eca3
Compare
FRASTM
pushed a commit
that referenced
this pull request
May 21, 2025
Current code does not build on Cortex-M0, seems like it does not like subs: Error: instruction not supported in Thumb16 mode -- `subs r3,#1' Adding a unified assembler language declaration in the snippet seems to fix the problem, also add an M0+ board so this is tested in CI. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
FRASTM
pushed a commit
that referenced
this pull request
Jun 30, 2025
Add possibility to perform crop on all pipes and compose (downscale) on pixel pipes (endpoint #1 and endpoint zephyrproject-rtos#2). Rework the code in order to move the downscale control from the set_fmt into the set_selection (compose). Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
FRASTM
pushed a commit
that referenced
this pull request
Sep 16, 2025
Add support for NV12/NV21, NV16/NV61 and YUV420/YVU420 (semi)planar formats which can be output by the main #1 pipe. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
FRASTM
pushed a commit
that referenced
this pull request
Nov 26, 2025
Map all pins of RT685's Flexcomm #1 peripheral. Needed for opration of Flexcomm #1 in I2S mode or Flexcomm zephyrproject-rtos#3 in I2S mode with shared signals. Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
FRASTM
pushed a commit
that referenced
this pull request
Nov 26, 2025
Add SCK and WS signals to a shared signal set between Flexcomm #1 and Flexcomm zephyrproject-rtos#3 for the mimxrt685_evk/mimxrt685s/cm33. This enables the board to both transmit and receive audio, as the BCK and WS signals produced by the WM8904 codec are only connected to the Flexcomm #1 peripheral. Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
FRASTM
pushed a commit
that referenced
this pull request
Mar 16, 2026
I'm at a loss here. The feature this test case wants to see (on ARMv7M, not ARMv6M) is the ability to take a irq_lock() inside a system call and then see that future system calls from the same thread continue to hold the lock. That's not documented AFAICT. It's also just a terrible idea because either: 1. The obvious denial of service implications if user code is allowed to run in an unpreemptible mode, or: 2. The broken locking promise if this is implemented to release the lock and reacquire it in an attempt to avoid #1. (FWIW: my read of the code is that #1 is the current implementation. But hilariously the test isn't able to tell the difference!) And in any case it's not how any of our other platforms work (or can work, in some cases), making this a non-portable system call API/feature at best. Leave it in place for now out of conservatism, but disable with the new arch_switch() code, whose behavior matches that of other Zephyr userspaces. Signed-off-by: Andy Ross <andyross@google.com>
FRASTM
pushed a commit
that referenced
this pull request
Jul 9, 2026
struct bt_uuid was used for storage instead of struct bt_uuid_any
resulting in overflow when converting BTP UUID to bt_uuid.
==3608402==ERROR: AddressSanitizer: stack-buffer-overflow on address
0xe02f5da2 at pc 0x0805a750 bp 0xe14e2048 sp 0xe14e2038
WRITE of size 2 at 0xe02f5da2 thread T7
#0 0x805a74f in btp2bt_uuid zephyr/tests/bluetooth/tester/src/btp_gatt.c:212
#1 0x805d31c in get_handle_from_uuid zephyr/tests/bluetooth/tester/src/btp_gatt.c:2149
zephyrproject-rtos#2 0x804f12c in cmd_handler zephyr/tests/bluetooth/tester/src/btp.c:122
zephyrproject-rtos#3 0x807c582 in z_thread_entry zephyr/kernel/sys/thread_entry.c:60
zephyrproject-rtos#4 0x807cdd2 in posix_arch_thread_entry zephyr/arch/posix/core/thread.c:124
zephyrproject-rtos#5 0x80ff2bd in nct_thread_starter zephyr/scripts/native_simulator//common/src/nct.c:291
zephyrproject-rtos#6 0xeb1949a3 in asan_thread_start ../../../../../src/libsanitizer/asan/asan_interceptors.cpp:234
zephyrproject-rtos#7 0xeaea5136 (/lib32/libc.so.6+0x8b136) (BuildId: 798ae816ef14b98dc77560340190445fb200634a)
zephyrproject-rtos#8 0xeaf39de7 (/lib32/libc.so.6+0x11fde7) (BuildId: 798ae816ef14b98dc77560340190445fb200634a)
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
FRASTM
pushed a commit
that referenced
this pull request
Aug 20, 2026
z_arm64_sync_exc() demuxes SVC exceptions by the low 8 bits of the SVC immediate (svc #1: IRQ offload, svc zephyrproject-rtos#2: runtime except, svc zephyrproject-rtos#3: system call) without checking which exception level the SVC was taken from. On ARM64, SVC from EL0 and EL1 both report ESR EC 0x15, so hardware does not distinguish them. With CONFIG_USERSPACE=y and CONFIG_IRQ_OFFLOAD=y, any user thread can execute a raw svc #1 with x0/x1 pointing at an arbitrary kernel function and argument; the handler then runs 'blr x1' at EL1, i.e. privilege escalation / arbitrary code execution in kernel mode. The RISC-V port avoids this class of bug by distinguishing ECALLU/ECALLM via mcause. Note that CONFIG_IRQ_OFFLOAD depends on TEST (arch/Kconfig), so this is not reachable in a production build; only test builds that enable irq_offload() are exposed. This distinction matters for backport decisions. Read the saved SPSR from the ESF and route any SVC taken from EL0 to a user-only path that accepts just the system call and runtime-except immediates. The runtime-except entry must stay reachable from EL0 because user threads raise stack-check failures and oopses through it; z_arm64_do_kernel_oops() sanitizes the user-supplied reason, so this is not a privilege boundary. All other EL0 SVCs raise a fatal CPU exception. Kernel-mode SVCs keep their previous behavior, except that svc zephyrproject-rtos#3 from EL1 is no longer dispatched to the syscall handler, which kernel code never uses. Fixes zephyrproject-rtos#116254 Signed-off-by: Hongquan Li <hongquan.li@processmission.com>
FRASTM
pushed a commit
that referenced
this pull request
Aug 20, 2026
Add a regression test for the EL0 SVC gating fix: a user thread executes a raw svc #1 (the IRQ offload entry) with x0 pointing at a kernel-only probe function. With the fix, the SVC raises a fatal CPU exception and the thread is aborted; without it, the offload handler branches to the attacker-controlled address at EL1 and the test fails immediately on the probe check. Covers tests/arch/arm64/svc_el0_gate on qemu_cortex_a53 (UP and SMP) with CONFIG_USERSPACE=y and CONFIG_IRQ_OFFLOAD=y. Signed-off-by: Hongquan Li <hongquan.li@processmission.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is in response to zephyrproject-rtos#62349 and is just a proof-of-concept.
I added the XSPI_RODATA relocation here for the stm32 to test out my personal use-case, which is storing constant read-only data (images) in the external flash. This allows the linker to provide the layout automatically so that the application can refer to the data via pointer and the external loader loads the flash accordingly.
The sample also demonstrates XIP by moving the text for function_in_ext_flash out to 0x90000001 and executing it.
The STM32CubeProgrammer needs to be used to flash when the external memory needs to be updated.
Then confirmed memory contents at 0x9000008e using memory view in STM32CubeProgrammer.
WRT this particular sample, the discrepancy over the custom linkerfile and the memory region defined by the board may become annoying to maintain if many boards define their own memory regions. Here the original linkerfile calls the external flash section EXTFLASH, where the stm32h7b3i_dk now calls it XSPI.