The cache operations must be quick, optimized and possibly inlined. The
current API is clunky, functions are not inlined and passing parameters
around that are basically always known at compile time.
In this patch we rework the cache functions to allow us to get rid of
useless parameters and make inlining easier.
In particular this changeset is doing three things:
1. `CONFIG_HAS_ARCH_CACHE` is now `CONFIG_ARCH_CACHE` and
`CONFIG_HAS_EXTERNAL_CACHE` is now `CONFIG_EXTERNAL_CACHE`
2. The cache API has been reworked.
3. Comments are added.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The buffer contents returned from arch_gdb_reg_readone is a counted array
of bytes, not a C string. Use memcpy instead of strcpy for the failure
return path to avoid compiler warning about missing NUL termination.
Signed-off-by: Keith Packard <keithp@keithp.com>
Change for loops of the form:
for (i = 0; i < CONFIG_MP_NUM_CPUS; i++)
...
to
unsigned int num_cpus = arch_num_cpus();
for (i = 0; i < num_cpus; i++)
...
We do the call outside of the for loop so that it only happens once,
rather than on every iteration.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Move the FS_BASE MSR code to to the top of __resume to ensure
that %fs relative addressing run in the thread switching hook
works.
Signed-off-by: Keith Packard <keithp@keithp.com>
There seems to be an unresolved dependency chain in some x86 arch
headers, this file needs kernel.h to be included before arch_data/func.
This patch is a workaround, but problem should be fixed properly at some
point.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
Convert the device to be Devicetree based. Adjusted tests and other
areas that were using old Kconfig properties.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The "framebuf" driver was an incomplete driver expecting _clients_ to
implement missing functionality (i.e. init and device definition)
outside of the driver. This pattern of scattering driver code throughout
the tree is not common (if used at all). If certain drivers share
functionality, one can create a common module within the subsystem (see
e.g. ILI9XXX drivers).
The _generic_ framebuffer code was only used to implement the Intel
Multiboot framebuffer driver. This patch centralizes all the scattered
code in the subsystem and adjusts the driver name to "intel_multibootfb"
to make things clear. If there's ever another framebuffer driver that
shares code, it can be split into multiple modules.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
It is frequent to find variable definitions like this:
```c
static const struct device *dev = DEVICE_DT_GET(...)
```
That is, module level variables that are statically initialized with a
device reference. Such value is, in most cases, never changed meaning
the variable can also be declared as const (immutable). This patch
constifies all such cases.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
MISRA C:2012 Rule 14.4 (The controlling expression of an if statement
and the controlling expression of an iteration-statement shall have
essentially Boolean type.)
Use `do { ... } while (false)' instead of `do { ... } while (0)'.
Use comparisons with zero instead of implicitly testing integers.
Use comparisons with NULL instead of implicitly testing pointers.
Use comparisons with NUL instead of implicitly testing plain chars.
This commit is a subset of the original auditable-branch commit:
5d02614e34
Signed-off-by: Simon Hein <SHein@baumer.com>
irq_lock() returns an unsigned integer key.
Generated by spatch using semantic patch
scripts/coccinelle/irq_lock.cocci
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
The EFI console output call return with interrput enabled, it is a
firmware bug. And there was a solution that disabled interrupt it
return right away. But in some case the interrupt could happen
during the efi call context. If an interrupt was handled, a printk
call again will make it re-entried, or a swap might be happens.
This is suggested solution appiled for EFI console output:
1. Skip printk call when it is called in interrupt context.
2. Disable the schedule during the EFI call window.
Signed-off-by: Enjia Mai <enjia.mai@intel.com>
MISRA C:2012 Rule 21.13 (Any value passed to a function in <ctype.h>
shall be representable as an unsigned char or be the value EOF).
Functions in <ctype.h> have undefined behavior if they are called with
any other value. Callers affected by this change are not prepared to
handle EOF anyway. The addition of these casts avoids the issue
and does not result in any performance penalty.
Signed-off-by: Abramo Bagnara <abramo.bagnara@bugseng.com>
Signed-off-by: Simon Hein <SHein@baumer.com>
Logging v1 has been removed and log_strdup wrapper function is no
longer needed. Removing the function and its use in the tree.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
MISRA C:2012 Rule 8.2 (Function types shall be in prototype form with
named parameters.)
Added missing parameter names.
Signed-off-by: Abramo Bagnara <abramo.bagnara@bugseng.com>
The NS16550 UART base address was hardcoded in <soc.h> headers. This
bypasses the console choice defined in Devicetree. Hardcoded hardware
choices must be avoided now that DT is in place.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Assembler 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>
In order to bring consistency in-tree, migrate all arch code to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Where we have access to a bootstrap UEFI environment, it's productive
to use that console as the default printk handler. That avoids the
bringup hassle of trying to configure UART settings blindly, as has
been customary. It also emits nice text to the framebuffer on devices
with no serial port or other debug harness at all.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When "eager FPU sharing" mode is enabled, FPU registers must be
initialised at the time of thread creation because the floating-point
context is always active and no further FPU initialisation is performed
later.
Note that, in case of the "lazy FPU sharing" mode, floating-point
context is inactive by default and the FPU is initialised when the
first floating-point instruction is executed.
Refer to the issue #44902 for more details.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Under QEMU and SeaBIOS, everything gets to be printed
immediately after "Booting from ROM.." as there is no newline.
This prevents parsing QEMU console output for the very first
line where it needs to match from the beginning of the line.
So add a dummy newline here so the next output is at
the beginning of a line.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
In case of EFI, efi_init must be called before initializing early
serial: if that one as X86_SOC_EARLY_SERIAL_PCIDEV defined, its pcie
access will try to initialise pcie mmio access which one will try to
find an ACPI table. At this point, calling ACPI API prior to initialize
EFI will make RSDP looked up already... and since it cannot find it
without EFI being initialized first, ACPI is then broken.
Just moving early serial to initialize after multiboot/efi being setup.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
If such table pointer is present with EFI system table, this will speed
up ACPI initialization later on.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
As for Multiboot, let prep_c be aware of EFI boot.
In the futur, EFI will pass an argument to it.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
In order to mitigate at runtime whether it booted on multiboot or EFI,
let's introduce a dedicated x86 cpu argument structure which holds the
type and the actual pointer delivered by the method (multiboot_info, or
efi_system_table)
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Just a dummy function will do.
When enabled, the code does not need the #ifdef as cmake is handling
this properly already. This was also the wrong CONFIG_ used there
anyway.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Improve code by using DEVICE_DT_GET_ONE instead of device_get_binding,
since the intel_vt_d device instance can be obtained at compile time.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
According to Kconfig guidelines, boolean prompts must not start with
"Enable...". The following command has been used to automate the changes
in this patch:
sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig*
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
When Zephyr runs directly on actual hardware, it will be always
directing MSI messages to BSP (BootStrap Processor). This was fine until
Zephyr could be ran on virtualizor that may NOT run it on BSP.
So directing MSI messages on current processor. If Zephyr runs on actual
hardware, it will be BSP since such setup is always made at boot time by
the BSP. On other use case it will be whatever is relevant at that time.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Depending on whether X2APIC is enabled or not, it will be safer to grab
such ID from the right place.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This will centralize CPUID related accessors. There was no need for it
so far, but this is going to change.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
When XIP is not enabled, z_data_copy() already falls back to an empty
function. No need to ifdef it.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
In fact, in case of VT-D being enabled, it will require to get an
address and data for its own MSI based interrupts which cannot be
remapped (i.e.: will directly go to the relevant APIC).
This is necessary to get the Fault event supported in VT-D.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This will not only be used by MSI remapping but by all relevant
interrupts.
Fix also IRTE settings:
- handle x2apic for destination id
- destination mode is always logical (as for IOAPIC)
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
SHV bit depends on the number of vectors allocated.
If it's facing a multi-vector MSI array, it will set the bit.
If not the bit must be 0.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Refactor to handle this case. This is valid only when MSI multi-vector
feature is enabled.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Carlo Caione