code_relocation_nocopy sample for stm32h7b3i_dk ospi mapped NOR #1
Conversation
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
This CONFIG_STM32_XIP is for enabling the MemoryMapped mode on external octo or quad spi memory. Signed-off-by: Francois Ramu <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Enable the DCACHE1 in INCR burt mode to allow writing to the external NOR octoFlash when in MemoryMapped mode Signed-off-by: Francois Ramu <[email protected]>
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 <[email protected]>
Add the MPU_REGION_ENTRY for the NOR flash memory with STRONGLY_ORDERED_SHAREABLE attribute Signed-off-by: Francois Ramu <[email protected]>
Define the node of the qspi/ospi external NOR flash for the stm32h7x serie Signed-off-by: Francois Ramu <[email protected]>
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 <[email protected]>
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 <[email protected]>
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
from
3f1c537 to
cccc2c6
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
from
cccc2c6 to
fcac3e8
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
16 times, most recently
from
bd2be46 to
ead4df7
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
2 times, most recently
from
dd54d1c to
5a91280
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
from
5a91280 to
045dbbb
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
from
045dbbb to
f6dfcb1
Compare
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
3 times, most recently
from
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 <[email protected]>
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
2 times, most recently
from
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 <[email protected]>
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 <[email protected]>
FRASTM
force-pushed
the
stm32h7_ospi_memmap
branch
2 times, most recently
from
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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.