45ce78adf0
samples: code_relocation_nocopy: update macro for flash size and address
...
In case of the st,stm32-qspi-nor compatible
new property and node definitions will requires new macro
to get the external NOR flash base address and size
Add the config for running the sample on stm32l475 disco kit
Signed-off-by: Francois Ramu <francois.ramu@st.com>
2 weeks ago
5a4326e8ce
samples: appli dev: code reloc running on stm32h7rs target boards
...
Samples to execute code in external memory in Memory mapped mode
on the stm32h7s3l8 nucleo or stm32h7s78 disco kit
Signed-off-by: Francois Ramu <francois.ramu@st.com>
2 weeks ago
11d3b45648
samples: code_relocation_nocopy: update macro for flash size and address
...
In case of the st,stm32-ospi-nor compatible
new property and node definitions will requires new macro
to get the external NOR flash base address and size
Signed-off-by: Francois Ramu <francois.ramu@st.com>
3 weeks ago
95d95dc82c
samples: code_relocation_nocopy: update macro for flash size and address
...
In case of the st,stm32-xspi-nor compatible
new property and node definitions will requires new macro
to get the external NOR flash base address and size
Signed-off-by: Francois Ramu <francois.ramu@st.com>
2 months ago
5c8cf1c18c
tests: fix various test ids and use existing scheme
...
Fix IDs and match them to what we have in the MAINTAINERS file.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
3 months ago
cc28f5072b
samples: code_relocation_nocopy: fix stm32 flash size info
...
Fix typos in stm32 flash sizes value introduced by commit 0e1ffc7beb0e1ffc7beb
3 months ago
0e1ffc7beb
samples: code_relocation_nocopy: update macro to get flash size
...
The flash size is the second part (size) of the first reg value,
not the first part (address) of a nonexistent second reg value.
DT_REG_SIZE get a node's (only) register block size instead
DT_REG_ADDR_BY_IDX .
Signed-off-by: Fabrice DJIATSA <fabrice.djiatsa-ext@st.com>
4 months ago
1f3ffc3111
samples: code relocation for the stm32f746 disco kit
...
Add the configuration for using the external FLASh Memory
and execute the samples/application_development/code_relocation_nocopy/
on the stm32f746g_disco board
Signed-off-by: Francois Ramu <francois.ramu@st.com>
4 months ago
ac3355ab97
samples: code_relocation_nocopy: Add configuration for nRF54H20 DK
...
Add nRF54H20 DK specific entries to allow using the sample on this
board.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
4 months ago
35625c146a
boards: samples: remove CONFIG_BUILD_NO_GAP_FILL=y and similar
...
Gap filling in hex files are now disabled per default, and therefore
there is no reason to explicitly disable gap filling.
It has never been possible to disable gap filling in binary files.
Disabling gap filling would just result in the binary file to be gap
filled with the tool's default value, objcopy=0x00.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
7 months ago
9902eec01b
samples: application_development: use zephyr:code-sample directive
...
Describe the samples using code-sample directive in preparation for
upcoming changes to the Zephyr documentation that will be leveraging
the provided description and metadata.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
11 months ago
2f0dd2c66f
samples: code relocation in external memory of stm32h5 disco kit
...
Define the configuration to run the code_relocation
application on the external memory xspi flash
of the stm32h573i_dk disco kit in XIP
Signed-off-by: Francois Ramu <francois.ramu@st.com>
1 year ago
a9be65bec5
samples: code relocation in external memory of stm32H7 disco kit
...
Define the configuration to run the code_relocation
application on the external memory dual quad flash
of the stm32h745i/stm32h750b disco kits in XIP
Signed-off-by: Francois Ramu <francois.ramu@st.com>
1 year ago
4101948082
samples: code relocation in external memory of stm32 disco kit
...
Define the configuration to run the code_relocation
application on the external memory octo flash
of the stm32u585 or stm32h7b3i disco kit in XIP
Signed-off-by: Francois Ramu <francois.ramu@st.com>
1 year ago
e7a53cf03b
samples: code_relocation_nocopy: add stm32f769i_disco board
...
This board has memory-mapped QSPI flash.
Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>
1 year ago
8dc3f85622
hwmv2: Introduce Hardware model version 2 and convert devices
...
This is a squash of the ``collab-hwm`` branch which converts all
in-tree boards to hardware model version 2 including build system
changes, board updates and soc conversions.
This squash is a combination of the following commits:
ca214745a1 soc: Remove soc_legacy folder and move ARM Kconfig
f12cb0979f1807bcf4d43ec2299c628ea02f4e63f2eb7652ceab509a5ee006ad037f993f9e706859204372d264f82c961a466987b2e30584484e6707ae443d1e3ce3629c64e6fc835d893d29ef2f23ebfd49b1749e1e59b7a3fd69bb0eb2581c4458890f651a4370ad196cfda66d6ec6b1d75ab774cdd59f7aa36e6640fe25709a9cf88f211b4eb21a455dfbfdc76c48a714ecafc67ddbc366c3c78e02c08f96b1b85e249558cc4013b366ce5c0b09bb472432542e816a8a3a9aeab17139a4fe97b9de615fcab94a7752f69b7f3eba827956914362bbd5a62278fd23b6a11ccec4c1067c16d2b8340b01099d81e417bec296672720fada12aa9dfe37ebac1ed32828fe6a5afba7855bca48c17723db1fd4d229a78b2552ebcc96061d96ed854e05d14fa1ae81105543040a182335ae79b3f910b7ad4f32104db555e23a41200d3c670e4e53fc7c6a060b22c2edb89c0a96dcb778be1ee1c4465e6c62137f037a3b52a47277cae6fada3e49d34ebc8424dd3b041cb52939576b43a95ce8f3e6494d550399e92708708c909e06dac41e68dd8f842b40b4d1c04978067c69089e097205b40ad8cfa6fb29c29ed228c688cfd3d6acad30c940ee9e5a10ec805650c8326882cf44be451a9c405a6ff2b536d2535ee6058710b76687602f32ae4918d0cc1dabca65a37ddce659a1393a07f6813ed00f6771317d67988cb0c51ec62b9db15c690101216ce14b4c3ca65dcdc3ef499fcabdd4ad054b5bd7ae8aa992785ceb3c1cdc20fe291c7cde2b95db8975260a47b948799f9f221c24e7869ca38abf2fb5eca3e25730ba569e3466606a09a398dcc8cb8ffc74f82291ff4b55484b7f1996cc5c2fb0c759cb580513aa9e0de7afa1480cf1cf0d719e004beb5c3e6f79a34a3640b7cf50e950e7737cfb548f505494c97a4eaf69f37aa1335caeaea9f7f30bf680db4c81b3433d7e99764ea79d19e7fd4ae6f6a836080549bd169bf8ae1d25f04d522211c2af0de8d5128f401644fbc68cadf7fe431b449094fea63bb632acc1fc1a3316ebdc71c0344f8cf0176fc25f36b920ed0f22520368d9296acfb2bc55063380b71f93394b55e7a4fd2ec101942f1d11477c8b84dd64e3e816c43a7aa2fa4984e1c17ad9a90f53ad57af9aa6529950f0bf05a3a10b614aa45abe735e939ab8f64ca9483ff8dd4df113dd534239b31287d91511e356a2c91e25ab471c231fd939417cff1e6028d4e41b1b2b520f83cbbf7899c64533f7b618668f20ea6e937cf4ff43a1c68e1fea4e3b49014a0f14f344eeab40f3f8f22d10bf79ea518727d5ca80c81ef015635836c1b699338f6f2bf19639a1b5dc981807444e5d07e824852fd081ac8666d425f5715bd38f47a900c6ef25be0c639b8378c2ef907d1d553de2ebc9b8ec0080c2eb7025e50f10ef3d4bd2ba9fdaa1d686c8d4a0ca575ac5cafb87b290730414b30055ab0012bfc15df526225ead19e7df29df0bd7d963d6795a90f9bf43d5540be7065148d8561dc9a8aa17763571e878dae301b8a319e60eef36a0a7c30f28df9a4223feed401abafffc78e5eaa44e586958fff4c31a2b865b2ffc652b5db061a4c66547845e9d95a1f96399e563eb0a628914bc58b67e8de1e781bfcc2ed18f330fc38f9fb9e06f4c384b90b30b9d0f6842e2fab2af1e1737686a4b78b8396b6bb856765299c6277efd46eb41505cbc5c42951a140701a795d28810f9a957e6f6df994e7ee88dfabd56ca447b951593bad5dfa71fad2e863f393f08e714b26734597a762908af0bccd1ceb29fca4768ccaf70ebdb0879adae82580d08c5f0defbae1e46cabce6f2f85133f286642f4e78c61e807896ca46c8abc9fbfed5f48f8cd8b1cc476f6cc57a04c4c14a54ca06c2054e5cff0e0fce1b334264c46a8b947a0e91990417bbdee12719154a437a430fbef93387f9681cf2498b1347abe812561e33786dc47f081914dbbc97349dbda9902ff58e126e1a4e72899f0257c3790c10b1eefaee62088dc34d186a571be3a9e9d360e6b400f9c4fbac27e8b4dd29a9c4380f5fdb2b9de981be056394e8a34804dbf17e19c9731f1bce53d41869d146c4f01427d285e19cf22bebd7298caf243274c2105a2bae84dca54e000afc314e8e3f9a7c2ce6d51ac56d0501c054381a7a4d93b8d9fdab2fcb1245ead4b57a7bd4c143d30670a66ac03a8a85c077998c253a99fcab883b80197c8b7a153b8dc2b911f6402366117af0a8d127452271f17a86841c2a9d993b314531abd4ea2bf70b5256e9fcc318e5cf1d51eab8628f981532f2fee1430ca6a475a9b9b41b91db0271ecbb957e2b20615a90a44454a20c113fbd34e3852a5420ad604de62e2a7b7656f7dcc2eb5eb58e90a2e9aae6e9e4541d3baac2d63b1d21483f6046e6ded90a7bf9fd79dce697c823666a35340989f0a6034b004bd43c48a6d756923d3801216b8db7cc30aaea866427ea292689b3f0eee7ebc727c8903265b2bb529a78ed5197cf636ae06d0c53f3a144e0aa066885238fc205dffc08af56545093abe4ecfa192f1bfd1e8cdc308bf067e6254833275ccdb9a70e5ea218c70cc4bfca52baf9ded1b3bcce64f362a8ae2c51dee5da92e66c35e0d0d1491a4810fa0fca79c4acd18bfaf7546c94b9588aab718c3e30f17424a435a97cb524fdc20fdff622dc2b63912f1e33a2e6c47c37d3db7a788b9a187046b92d41253ee9638cccb4c633242d4acf9230a60d28969a0409e51d3f1b2528df1baf1096e7ca0b1db9c53de9874671e2ba6c01407133ad4a51ca9812f3d54ec76b1fbeca649789e4336b3bdb736493dda5ee4be48e1f5d5bf11cf73df1ac73ed6dcd0fdbe3552e854cff3905a87ea5bc0a706e5d27cdd1edcdd0880f7add89cab6edad8d68c58e0822a6b987093a802096fd4652830f9c5a82527cd9d8cd83af7d0c1cfd9b84d4573c72fe863c37dfacbf9e1108d7b0edbed44a5c2840448c5a9f31273692c035b5d33ef03b84b9910ada00d0e7b9fb2103f89e1f9a533fbc3f92f65b287646b74aaffea54ddcd9d47f1878b1ae42be236b83bd1a9ecc39c26f09ed29d03c970b74acec315cfee6d8676e008b5d939224e357d6232c5f9dcce04da061646f15956a69b880324f77079893e0d11146f92b227bed5d1bb4cd325f95ec20d055676307c7a415d92cd15144f582a63ff71bcbb53c6f412c83eb4fc069715685b19f5b9ef9410612b297707acdcea932bc0a3ae2b22320b4ce17d547c65400d659ec56f9e6dc5977dbbaa6e492854399f248e04815f16834e6c1ee449ef1db4deddf9d2fd3ed43d2902fceb173d716ca1a10b7abc8942869b334f54b614611a5285821b9ec2e04cbad174e24ca0febfc9a32559a2dc4b11e025197edd05be39cf624c410b40bf25e5e71600d7e952bd84a1bc59dc342143b10392d693db2def8ed3abf7d3efe78c579770e1d91315401092efcefc089d9b295a85ba2f56bdcd500314155dfb08819dff756456c16e591f9198dc496f1bafbf9b290f25baa9fbe6bf19144bcfe57c74c86af7eaeb4f852f738bac9789264a954e1722d7e8515b24125246c21ef09396eb2e670c004fd83e3daa98e79a2de60c6dae877ce9cec2b50218c234a65f55916cc6e6be01fa83730326888e5959f1795e06e8663d517d3cc2468f9aeddabccf4f48f014a6e286a3b12e375f826b4db917de9d6e0d27efebc16a7a72728348838439c68231ba9986e9619fde82932e787cb9339f88f1cd4c3465492eadf06b8a8659e170b359133d7256d466429eda1ff441eb3ef82a8255c282204758a8ca93411958a947f446d324cb41153963c74df1c8d518ce5040fef0cef5be52ccc244fc7426eca5e1eba9d8a8f8d92edc72775117d1b2d0b0384b56ac1b77b223d91a077b2ab413b6c2a404f572ba24fcb348c7edf811ad90566d44ef90cf8c860f205defba98a17635c156a2d35cfc47a3a4b37129b4e44a923beba5dd242b2703b9c80d4e64428268c493833ad2b5bc640daa94f2d2b0dbb9d51ee6f7697ac594e4bad6ba5803ba099db8c27545630177cf53d486504cf24dd0672a64cc1565b3d146dd2723314ee1ce24a421952d559f29e12c3d8bd0ffbc1da33be52dfb7b64c29d1827f5b4a9556fd69e5d87a155e4ace1bbe2762460a64fdc3913e769c9c3a09a1109edc296f7bfcdbbe8f0fbb543983073e0f8080197a19f3961616fc8ae55622077738a6289516e4439d83688316e65f09c4862efd5a21dede0f6cd391e864ea2947ec3e416b52f797a227433db339f9a646d3f2d5d0d434bf86c3f5ed8157eecff8ee7a34507614f6f02b56cb96600c55c92af294bfc5e4882524d2a04bce0e9b39d0229c771f23a0570e64b6d3e1764f499f3e79029ae6b1804dfe2c90da5c3d4d46698cb1afbf01589f9897c872f7fb2030c7718643266232c4bdc0c47b64c638a8156ee8ad8a3d33dadeb04fee7371d2ad37a0c222cf85b7169f44b67ac4307dbb65d3715e79cb957d12bd83a2181a135ec3524dbe97e5ead632b90043cc1a30f24bdf0df9000bd2c7972a9a202c2bf447c3e36f2042b9dd58aea10e1898b093286f4a7524d1709cdb378f040cff2c8c90fae8e0c828dcc60ec79f1b0d943584b30fc194024d940e8053c3a8dfd5473b76fef5792b05e7ff202daa8ee66cbc294533b47b2edbbaeebd31d273b257a3f985de0888ec867960a8916ca677ed3abcf4ad19d40ac386683f9242c3c78f248d17f1600a67265e99f8d44317ee400343d17ed783ef549a643aeac552e601d643442f7a387b32519752efcd06263dd71766b0df5526fa07bd94198f6f0726dd7b155a7031804697afa5d2f001e320ec7f7b3c3089dfcddc7eeb724eb6a76f1043cde6cab924cbfb237fdff91803042b7704767b94414e07fa3a3d79ba01d3beca7ce84f4041b988bae5766fbf39c7264a418784421e79ba15f6ffdcb60185d6acb08d3e90e592ffd1eb8a7e3441ada469f2370342433187c10248d96421ddc5e6a65500f3ef21e7baf09ede5bae4a64803b0bd70c8cd52eab9e836f2835cb11ca36d331d2662cc4e09bdd9bc29769353da23ffbacc932b424cea9b140fd52e025943a1c7347686a9debd98799adab07c42f642aacdcdf48637066d3e983bc2a2361e0f32716a1688ff64135fb22859910e5d1122bc319cb19f011725ccac1400f7f6a4f8d8486139085b9eee7e8dafbd638e43ecd12f4155db2390e9d9ba8195cdc8e94b85361c970127fc2394c75373cf2a1cc871428f3f25945c3e480f740fd5847123f76ba9a0587719baa88505060a61ae199584be1c52dc8933942a5b004663b77c2c333e5c14ff98650bcdc268ccf0c8ba92e1fb54fe330772ba3639b2adbc5ed79f5ce6d493aa3a28086a9ca1b2a511d06ce281f09abcdb5364fd7768f173dcb21bbbbd9cbbab426569358f8fe82ba37e9084070d467e7053a5f2808d7ccbbb73e7550e9094afc4da1712cdd535be404b365baaa697ab269ecab3c902a572e3fb0ecfbf42757e0191d03bb4454648976f0ad6ee6b81f5e228ec8834bdb615e8f27fa8de2f8633a903807e0bd2c0724d7f625dc157a8cde534ec99c31b0a21546140a43f01ab6de60c16bcb8b2db228d73073fc26225c6b62d90114fa845af3095c8c3c3be03c02db12907eeb723cb74f9461d068a821de8532ba580c7236eb272ddf1958ed121c3ab0d70959d3b1088baadc18d867b0a9ee6ede7119b48e70ead914d2b955da9c4ac6a20214b57f56d7f3b173be1805b50f6691a188e01a1222c53e97b553f3b181b09f19a2075ab8928b1628cda3a7486870d704bd204789e1068e384307e3dced025df674994b6e173173b30a04cf83b133c207847a12f1e467f4c8d2a15326b5bfc0cfd5e691b4ac9c235741f198c3a761e438e6cad495e34da7c1313717df76392c3969ed8f245d764d8f71bb7b4fe27d23aad080823b860e72e4483decbed94669e3c01af5a7b81e563b4ca376e484adae34412f7fe29be50e2ca9bbbed12c2f4f5ec7ff8fd8d1b9f20030bd34b31ec20d0dcbb602ed6af4631b175003a4de231b911daa9597f6d99644828c8186ab2bd430d88d3ddcc40ccc0204e1dd9972d782a2c2e1406d2d9c62e118e8ba99dc599a939166049c4d94844dfeaf4ffba187f08271214526be24a5cd921d2b97b3c04051fca73a9e75338d87bcc16719335857856f9fe5429d9dc78e402535113e8923b276aee9a4795f8d611b2d82646443959786f12d81670db2e98980430aadac020f66e05140e4551a77d640e0c90131e1c15936b63787a7ae02fc5047f38f7bb223d3cca3580e6a8a0c1647faf22185cee94762ecdc9afcc27e053e4a17018f9188fdcd78fcaa41cb5ddbc413f7f76be3d4bc80f4442fa698ec5fbd67f7d3ef220460a223f284b5c381edcb7397401c7d2ae7a3243a24bec82c690d94f6f9b636209235ab6ee5b18859074c750818f98d3896caa442cff42c42c2df4ca9cb3970f90f713a70ee9ccd3cda715faedc56a543f387147f88c465f5dc5b8c7db2b6efd885dddac5a26ae5c4e7fdef834a12d03ab7830625a0c2ca049127ff3654b76e02f43c0a1bfcf1d9746e621ee43f219b14976891c52b0d39f0e0a973f66f592b64c94bcb4b2ac8fdc7ed6eb0770376250da6d8b92e86a5f8e5daa15ee799cc5f8aa8ce4ac84e203c14c7312265ee04c12ae3bcbcc5321c1dbebcc06c60aedb9e46010ca988adee7d7dc2c9db0cc506675b7c3abb7920734f52bc646ea712b5005bbaa55141a11f026f70ebbd854a3af8c9edefa8fd61bbfb5ba2a4d1980c35
1 year ago
6c95f23d81
samples/code_relocation_nocopy: Increase fake flash size
...
When linking with the 0.16.3 SDK version of picolibc, using long long
cbprintf support pulls in the full floating point printf which is much
larger than the integer-only version. This ends up overflowing the memory
region available for it. Increase the size of that by bumping the start of
the fake region by 8kB.
Signed-off-by: Keith Packard <keithp@keithp.com>
2 years ago
e3ee5c09f2
samples: code_relocation_nocopy: Make linker script more generic
...
Instead of depending on the nRF5340 DK, use a path specific to just
the nRF5340 SoC and get the size of the external flash in this case
from devicetree so that the sample could be easily run on other boards
based on the nRF5340 SoC (after just adding proper overlays).
On the occasion, correct the attributes of the EXTFLASH memory region.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2 years ago
6bd6f4be65
samples: code_relocation_nocopy: Use nrf_qspi_nor driver to init XIP
...
Use the Nordic QSPI NOR flash driver instead of the specific code
for the nRF5340 DK to initialize the external flash chip for XIP.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
2 years ago
2c22e83dfb
include: arch: arm: Remove aarch32 directory
...
This commit follows the parent commit work.
This commit introduces the following major changes.
1. Move all directories and files in 'include/zephyr/arch/arm/aarch32'
to the 'include/zephyr/arch/arm' directory.
2. Change the path string which is influenced by the changement 1.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
2 years ago
9c961571a2
modules: cmsis: move glue code to modules/cmsis
...
The CMSIS module glue code was part of arch/ directory. Move it to
modules/cmsis, and provide a single entry point for it: cmsis_core.h.
This entry header will include the right CMSIS header (M or A/R).
To make this change possible, CMSIS module Kconfig/CMake are declared as
external, allowing us to add a new Zephyr include directory.
All files including CMSIS have been updated.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2 years ago
93b63df762
samples, tests: convert string-based twister lists to YAML lists
...
Twister now supports using YAML lists for all fields that were written
as space-separated lists. Used twister_to_list.py script. Some artifacts
on string length are due to how ruamel dumps content.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2 years ago
0b90fd5adf
samples, tests, boards: Switch main return type from void to int
...
As both C and C++ standards require applications running under an OS to
return 'int', adapt that for Zephyr to align with those standard. This also
eliminates errors when building with clang when not using -ffreestanding,
and reduces the need for compiler flags to silence warnings for both clang
and gcc.
Most of these changes were automated using coccinelle with the following
script:
@@
@@
- void
+ int
main(...) {
...
- return;
+ return 0;
...
}
Approximately 40 files had to be edited by hand as coccinelle was unable to
fix them.
Signed-off-by: Keith Packard <keithp@keithp.com>
2 years ago
a5fd0d184a
init: remove the need for a dummy device pointer in SYS_INIT functions
...
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2 years ago
47271ce8be
treewide: update usage of zephyr_code_relocate
...
Update usage of zephyr_code_relocate to follow new API. The old method
of relocating a file was the following directive:
zephyr_code_relocate(file location)
The new API for zephyr_code_relocate uses the following directive:
zephyr_code_relocate(FILES file LOCATION location)
update in tree usage to follow this model. Also, update the NXP HAL SHA,
as NXP's HAL uses this macro as well.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
3 years ago
792469aae9
yamllint: indentation: fix files in samples/
...
Fix the YAML files indentation for files in samples/.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
3 years ago
ba7d730e9b
tests/samples: use integration_plaforms in more tests/samples
...
integration_platforms help us control what get built/executed in CI and
for each PR submitted. They do not filter out platforms, instead they
just minimize the amount of builds/testing for a particular
tests/sample.
Tests still run on all supported platforms when not in integration mode.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
3 years ago
5eb75b81f7
arm: rename default RAM region from 'SRAM' to 'RAM'
...
It's useful for RAMABLE_REGION to have a uniform name when
CODE_DATA_RELOCATION is supported, because otherwise the build system
needs to be aware of how the region name differs between architectures.
Since architectures tend to prefer one of 'SRAM' or 'RAM' for that
region, prefer to use 'RAM' as the more general term.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
3 years ago
79e6b0e0f6
includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>
...
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
3 years ago
800b086908
samples: code_relocation_nocopy: Update documentation
...
Extra steps for programming the external memory on nRF5340 DK are
no longer needed. Now west is capable of handling this itself.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
3 years ago
788fe5b4bf
samples: code_relocation_nocopy: Fix initialization of external memory
...
Despite the comment it contains, the initialization procedure for
the external memory chip on nRF5340 DK does not enable the High
Performance Mode in the chip, so communication using a frequency
higher than 8 MHz fails and the sample crashes (it works only right
after programming the chip with nrfjprog, which enables the High
Performance Mode, but the chip returns to the Low Power mode after
the board is power-cycled).
This commit fixes the initialization procedure and performs some
additional clean-up.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
3 years ago
e329353f21
samples: code_relocation_nocopy: Disable gap filling
...
... to prevent producing a huge (over 700 MB) hex file for nRF5340 DK.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
3 years ago
6f9f45d034
samples: remove redundant <zephyr/zephyr.h> includes
...
Files including <zephyr/kernel.h> do not have to include
<zephyr/zephyr.h>, a shim to <zephyr/kernel.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
3 years ago
d342e4c4c1
linker: update files with <zephyr/...> include prefix
...
Linker files were not migrated with the new <zephyr/...> prefix. Note
that the conversion has been scripted, refer to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
3 years ago
c7b5b3c419
samples: migrate includes to contain <zephyr/...> prefix
...
In order to bring consistency in-tree, migrate all samples to the use
the new prefix <zephyr/...>. Note that the conversion has been scripted:
```python
from pathlib import Path
import re
EXTENSIONS = ("c", "h", "cpp", "rst")
for p in Path(".").glob("samples/**/*"):
if not p.is_file() or p.suffix and p.suffix[1:] not in EXTENSIONS:
continue
content = ""
with open(p) as f:
for line in f:
m = re.match(r"^(.*)#include <(.*)>(.*)$", line)
if (m and
not m.group(2).startswith("zephyr/") and
(Path(".") / "include" / "zephyr" / m.group(2)).exists()):
content += (
m.group(1) +
"#include <zephyr/" + m.group(2) +">" +
m.group(3) + "\n"
)
else:
content += line
with open(p, "w") as f:
f.write(content)
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
3 years ago
c925b5991a
include: remove unnecessary autoconf.h includes
...
The autoconf.h header is not required because the definitions present in
the file are exposed using the compiler `-imacros` flag.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
3 years ago
117a352b5a
samples: code_relocation_nocopy: use pinctrl for nRF noard
...
The sample relied on `-pin` properties from QSPI node, move to pinctrl.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
3 years ago
ac6060f966
code_relocation: Extend the nocopy sample to nRF5340dk
...
The nRF5340dk is shipping an external QSPI flash that can be used to do
XIP from. Extend the code_relocation nocopy sample to support this
platform so that part of the functions are executed from internal flash
and others from external flash.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
3 years ago
d3203dc70d
code_relocation: Add NOCOPY feature
...
* Use case of interest:
Some platforms are shipping in parallel to the internal FLASH some other
storage / external FLASH (usually a QSPI FLASH) that can be used to
execute (XIP) code from.
The content of this external FLASH can usually be written at flash time
using proper tools (see for example the case of the external FLASH on
the nRF5340DK that can be written at flash time using nrfjprog).
The external FLASH is a nice addition that is extremely useful when a
large application code doesn't entirely fit on the internal FLASH so
that we could want to move part of it in the auxiliary FLASH to XIP the
code from there.
* The problem:
Right now Zephyr doesn't have a formal and generic way to move at build
time part of the code to a different memory region.
* The current status:
Zephyr is indeed shipping a code_relocation feature but that doesn't
entirely match our needs.
When XIP is enabled, the code_relocation feature is used in Zephyr to
move the selected code (that is to copy text section, to initialize data
and zero bss) from FLASH to SRAM at run time and execute code from SRAM.
The relocation is done by a generated snippet of code that is
memcpy()-ing the right content to the destination region also using some
build-time generated portions of linker script to retrieve start and
destination addresses and regions.
* This patch:
This patch is leveraging the code_relocation code and adding a NOCOPY
feature. This feature is using the code_relocation feature to
dynamically build the linker script snippets but entirely skipping the
run-time code relocation so that the code can be XIP-ed from the
destination region.
* Example:
Let's say that we have a big file called `huge_file.c` that we want to
XIP from the external FLASH that is mapped in an EXTFLASH region.
In this case we should enable `CONFIG_XIP` and
`CONFIG_CODE_DATA_RELOCATION` and instruct cmake as follows:
zephyr_code_relocate(src/huge_file.c EXTFLASH_TEXT NOCOPY)
zephyr_code_relocate(src/huge_file.c SRAM_DATA)
this means that:
- The .text section of the `huge_file.c` must reside in the EXTFLASH
memory region and we do not need to copy the section there because we
are going to XIP it (and we assume that the file is going to be placed
in the external FLASH at flash time).
- The .data section of the `huge_file.c` must still reside in the SRAM
memory region.
* TODOs:
It's desirable to have the possibility to relocate libraries and
pre-build files instead of source code files.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
3 years ago
Francois Ramu
Anas Nashif
Etienne Carriere
Fabrice DJIATSA
Andrzej Głąbek
Torsten Rasmussen
Benjamin Cabé
Armin Brauns
Keith Packard
Huifeng Zhang
Gerard Marull-Paretas
Daniel DeGrasse
Fabio Baltieri
Peter Marheine
Carlo Caione