In ARM builds with support for user mode, i.e. with
CONFIG_USERSPACE=y, we need to align the beginning
of the heap space, to respect the ARM MPU region
alignment requirements.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
USED_RAM_END_ADDR is not used when Kconfig option
CONFIG_NEWLIB_LIBC_ALIGNED_HEAP_SIZE is defined,
therefore, we do not need to define the macro in
that specific case.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
* when -mcpu is given, e.g. -mcpu=em4_dmips,-mnorm,-mdiv_em
etc. are already given, no need to duplicate
* use zephyr_compiler_options to replace zephyr_cc_option
zephyr_cc_option will do compile option check first then add
the checked options into option list. It's too strict that makes
options like -mfpu, -mmpy-option cannot be added.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
The first word is used as a pointer, meaning it is 64 bits on 64-bit
systems. To reserve it, it has to be either a pointer, a long, or an
intptr_t. Not an int nor an u32_t.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The conditional CONFIG_RISCV32 was misspelled in is_rodata() resulting
in the test failing all strings that are in RODATA section.
Additionally, it was using wrong section names for riscv.
Fixes#17065
Signed-off-by: David Leach <david.leach@nxp.com>
While fixing the ASSERT expressions in mem_domain.c to use
%lx instead of %x for uintptr_t variables, commit
f32330b22c has overlooked
one ASSERT expression specific to ARMv8-M. This causes
printk compilation warnings for ARMv8-M builds, so we
provide a fix here.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
The string returned by bt_uuid_str() is not in ROM so log_strdup()
must be used on it. This also eliminates the following kind of warning
messages: "<err> log: argument 3 in log message "%s: start_handle
0x%04x end_handle 0x%04x type %s" missing log_strdup()."
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add board support for 96Boards Avenger96 board from Arrow Electronics
based on STM32MP157A MPU from ST Microelectronics. This board is one
of the consumer editions boards of the 96Boards family following the
Extented CE form factor. More information about this board can be found
in 96Boards website: https://www.96boards.org/product/avenger96/
By default Zephyr console output is available via RAM console, but it
can also be changed to UART7 exposed as UART0 on 40 pin LS header.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Updated MEC1501 HAL headers. Add interrupt routing defines for timers.
Fix eSPI virtual wire source access. Add new headers for Port80
capture and TFDP.
Signed-off-by: Scott Worley <scott.worley@microchip.com>
Assert if the UART device is NULL to help with debugging whenever
there's an issue locating the correct UART instance.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Use Device Tree,and in particular a new 'bt-c2h-uart' to select which
UART is being used to communicate with an external BLE Host when acting
as a Controller.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Unfortunately this seems to have introduced spurious failures on (at
least) qemu_x86 and qemu_xtensa.
The change limits the timeslice tolerance to +/- 1ms, which isn't
necessarily correct when the tick rate is less than 1ms (though it
will probably work on deterministic hardware as long as the system is
hitting the target at exactly the right tick), and isn't even
theoretically achievable on emulation environments where timing
granularity is limited by the host scheduling quantum.
What this needs to do is check the deadline is off by at most one
tick, and trust the platform integration to have set the tick rate
appropriately.
(I do worry that the earlier version of the test was trying to set the
limit at half the TICKLESS_IDLE_THRESHOLD, though -- that seems weird,
and hints that maybe the test is trying to do something more
elaborate?)
Fixes#17063.
This reverts commit 62c71dc4d8.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Clear Linux exports to all users a list of "aggressive" compiler and
linker flags. Zephyr's CMake build system will either warn or fail
because of these. Add one magic command that solves the issue.
More background information at https://superuser.com/a/1452523/111302
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Folks found the use of @rststar/@endrststar non-intuitive (wanted to use
@rststart). The "star" was there indicating the doxygen comment lines
had a leading asterisk that needed to be stripped, but since our
commenting convention is to use the leading asterisk on continuation
lines, the leading asterisk is always there. So, change the doxygen
alias to the more expected @rst/@endrst.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Because CMake explicitly deduplicates arguments, it is not possible
to use toolchain_cc_imacros() multiple times as the later "-imacros"
are stripped away, leaving the associated file arguments dangling.
The documented workaround in the CMake manual involves some "SHELL:..."
construct but that doesn't get through zephyr_compile_options()
undammaged.
Let's simply remove this issue altogether by replacing "-imacros x.h"
with the joined form "--imacros=x.h" instead. Both gcc and clang
support this syntax.
FYI, this joined form is also available for other arguments such as:
-include x.h --> --include=x.h
-A foo --> --assert=foo
-D foo --> --define-macro=foo
-U foo --> --undefine-macro=foo
Etc.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Currently, the free block bitmap is roughly 4 times larger than it
needs to, wasting memory.
Let's assume maxsz = 128, minsz = 8 and n_max = 40.
Z_MPOOL_LVLS(128, 8) returns 3. The block size for level #0 is 128,
the block size for level #1 is 128/4 = 32, and the block size for
level #2 is 32/4 = 8. Hence levels 0, 1, and 2 for a total of 3 levels.
So far so good.
Now let's look at Z_MPOOL_LBIT_WORDS(). We get:
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 0) = ((40 << 0) + 31) / 32 = 2
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 1) = ((40 << 2) + 31) / 32 = 5
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 2) = ((40 << 4) + 31) / 32 = 20
None of those are < 2 so Z_MPOOL_LBIT_WORDS() takes the results from
Z_MPOOL_LBIT_WORDS_UNCLAMPED().
Finally, let's look at _MPOOL_BITS_SIZE(. It sums all possible levels
with Z_MPOOL_LBIT_BYTES() which is:
#define Z_MPOOL_LBIT_BYTES(maxsz, minsz, l, n_max) \
(Z_MPOOL_LVLS((maxsz), (minsz)) >= (l) ? \
4 * Z_MPOOL_LBIT_WORDS((n_max), l) : 0)
Or given what we already have:
Z_MPOOL_LBIT_BYTES(128, 8, 0, 40) = (3 >= 0) ? 4 * 2 : 0 = 8
Z_MPOOL_LBIT_BYTES(128, 8, 1, 40) = (3 >= 1) ? 4 * 5 : 0 = 20
Z_MPOOL_LBIT_BYTES(128, 8, 2, 40) = (3 >= 2) ? 4 * 20 : 0 = 80
Z_MPOOL_LBIT_BYTES(128, 8, 3, 40) = (3 >= 3) ? 4 * ??
Wait... we're missing this one:
Z_MPOOL_LBIT_WORDS_UNCLAMPED(40, 3) = ((40 << 6) + 31) / 32 = 80
then:
Z_MPOOL_LBIT_BYTES(128, 8, 3, 40) = (3 >= 3) ? 4 * 80 : 0 = 320
Further levels yeld (3 >= 4), (3 >= 5), etc. so they're all false and
produce 0.
So this means that we're statically allocating 428 bytes to the bitmap
when clearly only the first 3 Z_MPOOL_LBIT_BYTES() results for the
corresponding 3 levels that we have should be summed e.g. only
108 bytes.
Here the code logic gets confused between level numbers and the number
levels, hence the extra allocation which happens to be exponential.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The free block bitmap uses either extra memory specified by a pointer
in struct sys_mem_pool_lvl or the space occupied by that pointer
directly if the bitmap length is small enough to fit it.
But the test is wrong. the inline bitmap should be used if the number
of required bits is smaller or _equal_ to the pointer size. Not doing so
would wrongly bounce the free block bitmap to extra memory when the
number of blocks is exactly 32, which is in disagreement with
Z_MPOOL_LBIT_WORDS() that correctly returns 0 in that case.
In theory that mean that this bug would causes an overflow of the free
block bitmap whenever one level has exactly 32 blocks. But right now
there is a separate bug fixed separately that over-sizes the extra block
bitmap mitigating this bug.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
When splitting the pointer from the flag, ~SYS_SFLIST_FLAGS_MASK remains
a 32-bit value because of the lack of an L qualifier. Let's qualify it
with UL so the top half of 64-bit pointers is not truncated.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
We had no system call coverage for k_thread_suspend
and k_thread_resume.
Some unnecessary cleanup tasks in the test case have
been removed.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The block_fits() predicate was borked. It would check that a block
fits within the bounds of the whole heap. But that's not enough:
because of alignment changes between levels the sub-blocks may be
adjusted forward. It needs to fit inside the PARENT block that it was
split from.
What could happen at runtime is that the last subblocks of a
misaligned parent block would overlap memory from subsequent blocks,
or even run off the end of the heap. That's bad.
Change the API of block_fits() a little so it can extract the parent
region and do this properly.
Fixes#15279. Passes test introduced in #16728 to demonstrate what
seems like the same issue.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
We didn't have code coverage for this function anywhere
except indirectly through some network tests; exercise it
in the suite of userspace tests.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Address a coverage gap in kernel/userspace.
Unfortunately, in the process of fixing this, a bug was
discovered, see #17023.
This test is user mode specific, filter the testcase
on whether userspace is available instead of ifdefing
the code.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We had plenty of coverage for k_cycle_get(), but not its
32-bit variant. Run a case in user mode so that the system
call handler gets covered.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Print a friendlier error message on ValueError, but don't throw away
the stack trace.
Move another call to log.die().
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Follow along with changes made in west flash/debug/etc to make it
easier to see the output steps visually.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Having common log handlers now lets us improve our logging output so
that info messages are prefixed with the runner they came from, and
doing something similar with the high level steps as we go, like this:
-- west <command>: using runners
-- runners.RUNNER_NAME: doing something
<output from RUNNER_NAME subprocesses go here>
-- runners.RUNNER_NAME: all done, bye
We can also colorize the west output to make it stand out better from
subprocesses, using the same output formatting style that west
commands like west list do.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
I've had some requests to be able to use code in the runners package
without having west installed.
It turns out to be pretty easy to make this happen, as west is
currently only used for west.log and some trivial helper methods:
- To replace west log, use the standard logging module
- Add an appropriate handler for each runner's logger in
run_common.py which delegates to west.log, to keep
output working as expected.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
Move modem_receiver.h to the driver directory. No other users in the
tree and it is a private header.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move internal and architecture specific headers from include/drivers to
subfolder for timer:
include/drivers/timer
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move internal and architecture specific headers from include/drivers to
subfolder for interrupt_controller:
include/drivers/interrupt_controller/
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
