...Z_THREAD_STACK_BUFFER.
This is currently a symbolic change as Z_THREAD_STACK_BUFFER
is simply an alias to Z_KERNEL_STACK_BUFFER without userspace,
and Xtensa does not support userspace at the moment.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
In commit c75e6cfcb9
("soc: intel_adsp_ace1x: Added IPC/IDC implementation")
definition for INTEL_ADSP_IPC_DONE was modified for ace1x platforms.
This change was not correct as the new definition was also used to
program the IDA register.
Co-authored-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
1) HDA logging seems to be using some padding like '\x00'. Such
string can print well on a terminal but corrupt the string match.
And this can cause false failure if RunID matching is affected.
Remove such padding before checking RunID.
An affected RunID example:
'7aa9ba3c6db12\x00\...\x00\x00\x00\x00d0c7fcf382a4af40ec6'
Expected:
'7aa9ba3c6db12d0c7fcf382a4af40ec6'
2) Use non-displayable chars for live connection check. Otherwise
the log output will have subtle garbage like extra spaces which
locate randomly.
This solution comes from the PR #50071, the author is smrtos.
Signed-off-by: Ming Shao <ming.shao@intel.com>
Signed-off-by: Enjia Mai <enjia.mai@intel.com>
Remove the remote service logic in the FW loader, now
the FW loader is a pure FW loader as it used to be.
Signed-off-by: Enjia Mai <enjia.mai@intel.com>
Spilt the cavs server and FW loader, to make the cavstool.py
a pure FW loader and runner as it used to be. The reasons is
try to keep the FW loader won't be affected by the client-
server-based HW service as possible, and more easy to debug.
After splitting them, the service program spawns another
process to run the FW loader. The advantage is no matter when
the FW loader is stuck, the service can detect and stop it,
then continue to next test.
Fixes#47652.
Signed-off-by: Enjia Mai <enjia.mai@intel.com>
Copy cavstool.py to remote-fw-service.py in order to track changes
for following splitting work of cavstool.py.
Signed-off-by: Enjia Mai <enjia.mai@intel.com>
If the target is built without CONFIG_PM this stack is not
used and does not need to be defined.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The tool has caused some hard to detect failures when used
concurrently with the SOF Linux driver to observe logs. This
has been rootcaused to the code to handle and send IPC messages
that has been active even in logs-only mode. In vast majority
of cases, the SOF kernel driver is faster to act and handles
the IPC interrupts. But occasionally the cavstool.py timing was
just right and it managed to ack a message before Linux driver.
Fix the problem by not handling IPC messages when the tool
is run in logs-only mode.
Reported-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Interrupt vectors level 5 and 6 are not available in ACE. Just remove
them from the linker script.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
In ace15_mtpm the debug exception vector address is mapped to INTLEVEL4
and not INTLEVEL 6. This can be checked in the core-isa header:
"""
define XCHAL_DEBUG_VECTOR_VADDR XCHAL_INTLEVEL4_VECTOR_VADDR
"""
in
modules/hal/xtensa/zephyr/soc/intel_ace15_mtpm/xtensa/config/core-isa.h
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
In normal operation the clock for peripheral devices is derived from
the PLL clock.
During sleep, the xmc4xxx can switch its system clock source (f_sys)
from the PLL clock to an f_ofi clock. Switching to the f_ofi clock
is the default behaviour which breaks UART comms.
Use the PLL clock source during sleep instead to fix the issue.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
1. Add USB_STACK_USE_DEDICATED_RAM=1 define that is
used by the SDK USB driver
2. Delete unused "config USB_DEDICATED_MEMORY"
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
1. Move the defines from usb_dc_mcux.h to usb_device_config.h
and fsl_os_abstraction.h. These headers are used by
the SDK USB driver. usb_dc_mcux.h header file is not longer
needed and hence deleted.
2. Delete the Zephyr implementation of the usb_device_struct
driver and use the one implemented inside the SDK USB
driver. This requires updating the references to
usb_device_struct inside the USB driver
3. Move defines and structures used by the driver
out of the header file that is included by the SDK and
into the MCUX USB driver.
4. Use end point defines provided by Zephyr instead of adding
them locally.
5. Add a Kconfig to set the thread stack size
6. Move code to enable interrupts back to usb_attach function.
Interrupts should be enabled after the init is successful,
else we see errors of the ISR getting called before the
init is complete causing Faults
6. Update west.yml to update the NXP HAL to get the updated
SDK USB driver.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
Now that timer drivers are enabled based on devicetree
we need to remove any cases of them getting enabled by
Kconfig.defconfig* files as this can lead to errors.
Signed-off-by: Kumar Gala <galak@kernel.org>
Instead of deciding based on SoC version, add information to Kconfig and
get it from there on code.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Instead of deciding to init based on SoC version, define that
information in Kconfig and use it from there.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Instead of using SoC version to decide to power on or not, add this
information to Kconfig and get it from there.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Instead of using SoC versions, define the information about base and
extended ports on Kconfig, and use this information from there.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Instead of using version of the SoC, declare on Kconfig the need for it,
and use this information to decide upon enabling the code or not.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
error: assignment to 'void *' from 'unsigned int' makes pointer from int
| lpsheader->lp_restore_vector = (uint32_t) &dsp_restore_vector;
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
ARC processors are highly configurable, so ARC toolchain supports
big amount of mcpu options for all that HW configurations.
As difference in many configurations among the same processor
family usually doesn't affect Zephyr code we don't want
to create Kconfig option for each possible CPU configuration
(just to map Kconfig option to correspondent mcpu value
in 'cmake/gcc-m-cpu.cmake').
Instead we prefer being able to set proper mcpu value
individually for any ARC SoC and using 'cmake/gcc-m-cpu.cmake'
just for reasonable defaults.
To apply SoC-related changes for build-options on early stages of building
'tune_build_ops.cmake' should be created in appropriate SoC directory.
Example:
./soc/arc/snps_qemu/tune_build_ops.cmake
File content:
set(GCC_ARC_TUNED_CPU hs4xd)
Signed-off-by: Nikolay Agishev <agishev@synopsys.com>
The Xtensa arch has historically had state/user register accessor
macros with bare three-byte symbol names. I think this might have
been in the original Cadence-contributed arch integration, but I'm not
sure. In any case they also exist in the same names in vendor
HAL/toolchain code and are causing collisions. We never should have
had these symbols exposed in our header.
Put them under an XTENSA_ prefix to decollide.
Signed-off-by: Andy Ross <andyross@google.com>
The enet1g peripheral was missing in device tree for nxp rt11xx.
With this commit, the peripheral can be operated like the enet peripheral
with the eth_mcux (kinetis-ethernet) driver at 10/100 Mbit (no gigabit).
Signed-off-by: Nils Larsen <nils.larsen@posteo.de>
According to RM, there are 2 pins that need a 3 bit mask for daisy chain,
changed it accordingly.
(E.g. IOMUXC_UART4_IPP_UART_RXD_MUX_SELECT_INPUT for imx6sx)
Signed-off-by: Antonio Tessarolo <anthonytexdev@gmail.com>
Fix NXP MPU configuration for k6x flash region. The previous flash MPU
setting was based around the assumption that the user was executing from
the flash region at 0x0000_0000–0x07FF_FFFF, which may not be case if the
user selects to execute from SRAM, such as running from sram_l
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
This patch adds a clock control driver for GD32 platforms. It is
important to note that the driver is only able to handle peripheral
clocks, but not "system clocks" (e.g. PLL settings, SYS_CK, etc.). On
some similar platforms (STM32) this task is embedded in the same clock
driver, performed at init time but with no options to do any
manipulation at runtime via the API calls. The clock control API as-is
is really orthogonal to "system clocks", and it is arguably a bad idea
to embed system clock init code in a clock control driver. It can be
done at SoC level still using Devicetree as a source of hardware
description/initial configuration.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
