These two tests are hitting a stack overflow on x86_64 (not entirely
surprisingly), but can't just increase stack size because there is an
assert in the CMSIS compatibility layer that stacks be under 512
bytes. Just disable for now.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This builds with a host compiler, not one from the SDK, and so no
newlib library is available. There is work to enable newlib detection
at and above the cmake level. This patch can be reverted when that
lands.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There is actually nothing wrong with this test code idiom. But it's
tickling a qemu emulator bug with the hpet driver and x86_64[1]. The
rapidly spinning calls to k_uptime_get_32() need to disable
interrupts, read timer hardware state and enable them. Something goes
wrong in qemu with this process and the timer interrupt gets lost.
The counter blows right past the comparator without delivering its
interrupt, and thus the interrupt won't be delivered until the counter
is next reset in idle after exit from the busy loop, which is
obviously too late to interrupt the timeslicing thread.
Just replace the loops with a single call to k_busy_wait(). The
resulting code ends up being much simpler anyway. An added bonus is
that we can remove the special case handling for native_posix (which
was an entirely unrelated thing, but with a similar symptom).
[1] But oddly not the same emulated hardware running with the same
driver under the same qemu binary when used with a 32 bit kernel.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This architecture doesn't support stack canaries. In fact the gcc
-fstack-protect features don't seem to be working at all. I'm
guessing it's an x32 ABI mismatch?
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This is intended to be a value set by the platform to adjust the size
of stacks created by tests. This test was setting it explicitly, and
failing to honor it when creating its own stacks.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
No MPU support there yet. This test should really be predicated on a
kconfig variable, not architecture.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When tickless was disabled, this inverted test would never fire the
first interrupt and the timer would be silent. Just remove it.
There's no harm in unconditionally enabling a single timer interrupt
at boot.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The call to _arch_switch is a giant screaming sign inviting optimizer
bugs. The code that appears before is what happened long ago when we
were switched out, but the version that EXECUTED just now is actually
in a different thread. So the assignment to _current before the
switch actually assigned OUR thread (the "new_thread" of the old
context!) to _current.
But obviously the optimizer looks at that code and assumes that the
_current which got assigned to the thread we were switching to long
ago is still correct, and used it when retrieving the swap return
value.
Obviously the real bug here is that the _arch_switch() in question
lacked a memory clobber (and it's getting one).
But we can remove two lines, remove code from inside the interrupt
lock and make the implementation more robust by moving the read to
after the irq_unlock() (which generally also has a memory clobber).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This patch adds a x86_64 architecture and qemu_x86_64 board to Zephyr.
Only the basic architecture support needed to run 64 bit code is
added; no drivers are added, though a low-level console exists and is
wired to printk().
The support is built on top of a "X86 underkernel" layer, which can be
built in isolation as a unit test on a Linux host.
Limitations:
+ Right now the SDK lacks an x86_64 toolchain. The build will fall
back to a host toolchain if it finds no cross compiler defined,
which is tested to work on gcc 8.2.1 right now.
+ No x87/SSE/AVX usage is allowed. This is a stronger limitation than
other architectures where the instructions work from one thread even
if the context switch code doesn't support it. We are passing
-no-sse to prevent gcc from automatically generating SSE
instructions for non-floating-point purposes, which has the side
effect of changing the ABI. Future work to handle the FPU registers
will need to be combined with an "application" ABI distinct from the
kernel one (or just to require USERSPACE).
+ Paging is enabled (it has to be in long mode), but is a 1:1 mapping
of all memory. No MMU/USERSPACE support yet.
+ We are building with -mno-red-zone for stack size reasons, but this
is a valuable optimization. Enabling it requires automatic stack
switching, which requires a TSS, which means it has to happen after
MMU support.
+ The OS runs in 64 bit mode, but for compatibility reasons is
compiled to the 32 bit "X32" ABI. So while the full 64 bit
registers and instruction set are available, C pointers are 32 bits
long and Zephyr is constrained to run in the bottom 4G of memory.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Host toolchains don't tend to provide an x32 libgcc. But we don't
actually need one for existing code. This is fragile, but better to
work for all but obscure cases than break outright.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
It's worth using custom timing information on a few systems to save
cycles or gain precision. But make the use of k_cycle_get_32() a
proper default instead of hardcoding all the platforms and failing to
build on new ones. On Xtensa and RISC-V (and now x86_64) the cycle
informatoin from that call is a very fast wrapper around the native
counters anyway -- all you would save would be the function call
overhead.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These files were relying on _thread_essential_set() from
kernel_internal.h, but not including it directly. New architectures
won't transitively include things the same way.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
I was half way through typing up my own one of these when I realized
there was one already in the tree. Move it to a shared header.
(FWIW: I really doubt that most architectures actually benefit from
their own versions of these tools -- GCC's optimizer is really good,
and custom assembly defeats optimization and factorizations of the
expressions in context.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The HPET default is to deliver events on the same INTIn as the legacy
PIT IRQ, and in fact our code requires that because it uses the
"legacy routing" option. So this isn't really a configurable and has
to be set correctly. Do it right in the kconfig default instead of
forcing boards to set it.
(No, I have no idea where "20" came from either.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This was apparently intended to allow for per-arch linker includes,
but no such includes ever existed. All it does is senselessly throw
an error on unrecognized architectures. Yank.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These files were using z_thread_malloc() without including
kernel_internal.h. On existing architectures that works due to
transitive includes, but x86_64 has a thinner include layer and
doesn't do it for us. Include the files required for the APIs we use.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Fix the QSPI and hyperflash nodes to be proper SPI children and expose
the address range for direct access as part of the controller's reg
region.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We need to refactor how we determine CONFIG_FLASH_{SIZE,BASE_ADDRESS}
for when we have a QSPI that is memory mapped. "zephyr,flash" is going
to point the actual flash component that will be on a SPI bus and thus
the device node's reg property tells us which CS on the SPI bus its on,
not the memory mapped address/size of the flash.
So we make a few assumptions to handle this case:
1. If the #size-cells for the flash node is 0, we assume its a QSPI
memory mapped flash
2. That the QSPI memory mapped node (parent of what "zephyr,flash" is
point to, will contain a reg propery where the second reg pair will
be the memory mapped region for the flash.
We move handling of CONFIG_FLASH_{SIZE,BASE_ADDRESS} into flash.extract
so its all in one place.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Make the documentation page a little bit more interesting with top-level
navigation grid highlighting the most important sections with a brief
description.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add Accelerometer mouse by using fxos8700 accelerometer and using data
to control USB HID mouse.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
move development model from the wiki to the main documentation to keep
it in sync and updated all the time and to get proper reviews.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The CIAA and QFAB variants of the nRF52832 were missing in Kconfig,
although present in Device Tree. Add the relevant Kconfig entries in
order to be able to select them.
Fixes#12417
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
When used suitable config overlay, qemu_cortex_m3 with Ethernet
support can be started with just usual "make run".
An example of such overlay is included with samples/net/echo_server,
can be built and run with:
make BOARD=qemu_cortex_m3 \
CONF_FILE="prj.conf overlay-qemu_cortex_m3_eth.conf" run
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Add support for the TRNG device contained in the i.MX RT SoCs. It uses
the existing MCUX driver, and mostly consists in adding the Kconfig and
DTS entries.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Instead of getting the base address from the MCUX headers, use the base
address from the device tree.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
The original implementation of gpio functions access registers
directly. Using LL library can add a set of unifying access
functions for all series of stm32 for avoiding accessing low level
code, and improve readability.
Signed-off-by: Song Qiang <songqiang1304521@gmail.com>
All series STM32 have mostly the same GPIO architecture
and can share the same code for GPIO manipulation.
Functions of the external interrupt line control are also the same.
This patch extracts common code from them and put them into the 'common'
folder.
Functions of control GPIO of these series scattered in
soc/arm/st_stm32/stm32xx/ folders contain these functions:
stm32_gpio_flags_to_conf(), stm32_gpio_configure(), stm32_gpio_set(),
stm32_gpio_get, stm32_gpio_enable_int().
This patch merges them into the gpio_stm32.c file.
Signed-off-by: Song Qiang <songqiang1304521@gmail.com>
Connecting to a non-open port causes connect() to hang forever.
This patch releases connect() to return error to the caller.
Signed-off-by: Björn Stenberg <bjorn@haxx.se>
Adds documentation-commentary to some infrastructure used by the LL.
It is a long-term effort to better document the LL.
Notably ticker and mayfly require more documentation; this will be
done later.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Added macro that generates simple report descriptor for mouse.
This improves the readability of hid-mouse sample.
Signed-off-by: Marcin Szymczyk <Marcin.Szymczyk@nordicsemi.no>
It may happen that panic occured while logger backend
was formatting output data. In that case output buffer
could get corrupted as logger assumes that processing
happens in one context only (panic is the only exception).
Added log output buffer flushing on entering panic state.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
* i2c, spi, gpio are not tested, remove them now.
* fix the license issue in openocd.cfg
* fix the shell related setting
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
1. optimize the baudrate calulation
2. For arc iot soc, the interval val is 4
3. before write any regs, the clk of uart must be enabled
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
The initial support of iotdk which is a board based on Synopsys
ARC IoT SoC.
In this commit, it includes
* processor support
* UART driver
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
The mimxrt1020_evk and mimxrt1060_evk boards had invalid jlink device
names. Debugging via 'ninja debug' now works on these boards.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>