After the modules are adapted for the revised
USB device stack configuration, and it seems that
it was only necessary for MCUboot, we can finally
remove Kconfig option CONFIG_USB.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Similar to commit 9512ae488a
("boards: remove USB option for nRF based boards")
Also remove not necessary UART_INTERRUPT_DRIVEN and
duplicate CONFIG_USB_UART_CONSOLE.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Checks PAN ID for matching self address / broadcast, then the short /
extended address based on the used address mode.
Only when IEEE802154_HW_FILTER is not advertised by driver.
Signed-off-by: Stancu Florin <niflostancu@gmail.com>
This adds the driver for Omnivision OV2640 image sensor.
The driver provides support for 10 different resolutions in range from
160x120 to 1600x1200 in both JPEG and RGB565 pixel formats. There are
also mutliple configuration options, e.g. hflip, vflip, saturation and
brightness control.
Signed-off-by: Robert Szczepanski <rszczepanski@antmicro.com>
Thumb/ARM interworking causes problems with Zephyr's multiple link build
process when userspace is enabled. When compiling with userspace, the
first link process uses a dummy PROVIDE in the linker script for
z_object_find and z_object_wordlist_foreach. This dummy symbol is
treated as an ARM function call, but one of the calling functions is in
thumb mode. The compiler generates a veneer for thumb functions to call
z_object_wordlist_foreach. On the final link step, z_object_find and
z_object_wordlist_foreach are real functions and get compiled in thumb
mode, thus no veneer is generated in the text section. This means that
the .text size changes between the second and third link steps changing
the start of the devices section. That causes the kobject code to look
in the wrong spot for kernel objects and a crash ensues.
Workaround this for now by only compiling in ARM mode so that no veneer
is needed. Thus the section sizes stay the same during the different
linking steps.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
This macro is referenced by most of the architecture linker scripts, yet
it is only defined in the Metaware toolchain linker header.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
The Cortex-R architecture uses the threads stack to save context.
However, that is a security hole since a userspace thread could
manipulate the stack pointer before performing a system call and cause
the kernel to write to memory that it should not. This test will sanity
check that the Cortex-R svc and isr routines do not write to a userspace
supplied stack.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
The default address for FAULTY_ADDRESS is valid on the qemu_cortex_r5
board, so use a value that is not mapped for that board.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
The Cortex-R platforms may no use XIP which means userspace code with
have read and execute access to some of the RAM so that it can execute
code. However, userspace will not have access the the protected
read/write parts of RAM so it is safe to use the Cortex-M version of
trigger_fault_access for this test.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
QEMU supports the MPU on Cortex-R platforms so enable it for the
qemu_cortex_r5 platform. This allows running the mem_protect kernel
tests.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
Related to github #22290. Getting interrupt during mpu buffer validate
is corrupting index register. Fix applied to ARC is to disable
interrupts during the buffer validate operation.
Signed-off-by: Phil Erwin <phil.erwin@lexmark.com>
When running non-XIP, userspace threads need to be able to read .text in
order to execute code. Cortex-R needs to setup an MPU entry to allow
this, but it must be aligned to a power of 2. The linker scripts for
other archs follow this same pattern of aligning the location counter,
but outside of an input section. The linker ignores this and places the
next input section at the LMA of the end of the previous input section.
Avoid this problem by make RODATA the last ROM section. The MPU_ALIGN
can be moved inside the RODATA input section and correctly pad the
entire ROM section out to a power of 2 boundary.
_image_rom_end_order contains the power of 2 alignment which allow the
soc to set the MPU configuration statically based on the size of the ROM
sections instead of having to do it dynamically.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
Cortex-A/R does not have hardware supported nested interrupts, but it is
easily emulatable using the nesting level stored in the kernel
structure.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
Add functionality based on Cortex-M that enables recovery from a data
abort using zephyr's exception recovery framework. If there is a
registered z_exc_handle for a function, then use its fixup address if
that function aborts.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
With the addition of userspace support, Cortex-R needs to use SVC calls
to handle oops exceptions. Add that support by defining ARCH_EXCEPT to
do a svc call.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
The user thread cannot be trusted so do not use the stack pointer it
passes in. Use the thread's privilege stack when in privileged modes to
make sure a user thread does not trick the svc/isr handlers into writing
to memory it should not.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Also sort the entries alphabetically.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Some display drivers may actually be initialized after LittlevGL
as those drivers and LittlevGL's lvgl_init() all have SYS_INIT()
at APPLICATION and init priority the same as application init
priority. Depending on how the final binary is linked, these
drivers may initialize after lvgl_init() resulting in it not
able to find a display driver. This changes the value of
CONFIG_DISPLAY_INIT_PRIORITY so that the display drivers that
make use of this kconfig are initialized a bit earlier to
ensure that they are actually initialized before lvgl_init().
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Note that the include to subsys has been moved from
under the drivers into subsys, as it is actually
the subsystem's job to make sure the include
directories are correct.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a, simply
build a separate static library for the top level of sensor
drivers. Also, for those that were not building its own
static library, make them do so as majority of sensor
drivers are building their own static libraries.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Instead of putting object files inside libzephyr.a,
simply build a separate static library as most other
driver types are doing this already.
Note that the include to subsys/bluetooth has been
moved from under drivers/bluetooth to subsys/bluetooth,
as it is actually the subsystem's job to make sure
the include directories are correct.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
