When exiting Stop mode, if system clock is MSI, MSI oscillator is
selected as wakeup from stop clock; otherwise HSI16 oscillator is
selected.
It is otherwise reconfigured as MSI just after, but it slightly
increases the wake-up time and power consumption.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
When userspace enabled, the zephyr data region should start from
_app_smem_start instead of __kernel_ram_start.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
This patch mainly moves mpu related code from
arch/arm64/core/cortex_r/mpu/ to arch/arm64/core/cortex_r/ and moves
the mpu header files from include/arch/arm64/cortex_r/mpu/ to
include/arch/arm64/cortex_r/
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
Code removed:
- IT8XXX2 doesn't support soc level software interrupt hence remove
them.
- To use common macro to access csr (control status register).
- To remove CONFIG_RISCV_HAS_PLIC related code. IT8XXX2 uses its own
interrupt controller code.
- To remove ite_write and ite_read. We don't use them anymore.
Code changed:
- Return true from arch_irq_is_enabled() when external interrupt-enable
bit, and SOC's IER are both true.
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
A few HAS_HW_NRF_* Kconfig options for peripherals available in nRF5340
are not selected. Fix it.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Fixes: #38591, #38207, #37861
The commit 65a2de84a9 aligned the data
linker symbol for sections and regions.
The data region symbol start has been placed outside the sections thus
being defined as the address of the region before alignment of the first
section in the data region, usually the `datas` section.
The symbol defining the start address of the data section is after
section alignment.
In most cases the address of the data region start and datas section
start will be identical, but not always.
The data region symbol is a new linker symbol and existing code has
been depending on the old data section start symbol.
Thus, the update to the use of the data region start symbol instead of
data ram start symbol thus results in a different address when the
section is aligned to a different address.
To ensure the original behavior in all cases, the data region start
address is now moved inside the data section.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Following the migration of the clock source configuration in DTS (commit
2691541ad2), HSI is always used as wake-up source on STM32LX. It is
reconfigured as MSI just after, but it slightly increase the wake-up
time and power consumption.
It happens as the file defining STM32_SYSCLK_SRC_MSI is not included.
Fix that.
Fixes#38807
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Similarly to what was done on stm32g0, disable DBGMCU clock
after operation to avoid conflict with openocd.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
If clock is not enabled write access on that registers are no-op.
Disable clock after operation to avoid conflicts with openocd which
can also access this clock when flashing.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
During review of #38681, switching from HAL to LL,
involuntarily enable DBGMCU clock instead of DMA clock.
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
On some STM32 boards, for unclear reason,
RTT feature is working with realtime update only when
* one of the DMA is clocked
and sometimes also
* one of the DBGMCU bit STOP/STANDBY/SLEEP is set
Fixes#34324
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
It happens that CM7 wakeups CM4, before CM4 goes to sleep.
Thus when CM4 goes to sleep,
there no more wakeup from CM7. And CM4 hangs.
For a simple synchronisation implementation,
CM4 doesn't go to sleep any more,
instead it waits (active wait) for CM7 to take HSEM
(meaning that clock configuration is finished).
Fixes#38069
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
On STM32L0, there are some hardfault when DBGMCU bit Sleep, Stop
or Standby are enabled. See #37119
For unclear reason, enabling DMA clock fixes this issue.
(similarly than #38561, DMA clock comes with DBGMCU bits)
Signed-off-by: Alexandre Bourdiol <alexandre.bourdiol@st.com>
Call __reset instead of directly calling __initialize from the common
RISC-V privileged SoC vectors __start. This allows injection of SoC
specific reset code just after setting up the machine trap vector.
RISC-V privilege SoCs without the need for custom reset code can set
CONFIG_INCLUDE_RESET_VECTOR=y to include a __reset stub which simply
calls __initialize.
Fixes: #38396
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
CONFIG_PM_DEVICE was a de-facto requirement when enabling CONFIG_PM=y
since some device, i.e. UART, used the PM device hooks to block
suspension process while the device was busy finishing transmission.
This has now been fixed using constraints, so CONFIG_PM=y can be enabled
without further requirements.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
TI Hal has its own constraint API that is used by its drivers. These
constraints need to be correlated with Zephyr constraints to be
constraints set in the HAL be visible on Zephyr and vice-versa.
Fixes#38362
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
In commit "pm: Fix weak linkage symbols" (PR #35274),
PM SoC hooks were converted to __weak to avoid clash with
new definition of these symbols in subsys/pm/power.c.
G0 power implementation was implemented in parallel
with this change and missed the update.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Older binutils, like the (nine-year-old!) 2.23 version that powers
many Cadence XCC toolchains, happen not to support the "~" operator to
perform bitwise negation. And they generate an absolutely hilarious
series of inscrutable error messages when they try to tell you this
fairly simple fact.
Just fold it into the constant.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Low power modes entry on stm32wb depends on requests coming from both
cores, with no consideration of the fact that C2 is booted or not.
By default, set C2 power mode to shutdown at C1 start up.
If required, it will be updated by C2.
In case C2 is not started, this will allow C1 to enter any power mode
with no dependency on C2.
Fixes#38173
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Setting this bit will wake up CPU if it is in low power mode
and an interrupt is pending.
Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>
This patch adds support for SiFive Freedom U740 SoC.
First version is minimum only using UART, SPI and L2-LIM area.
Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
This patch adds support for SiFive Freedom U540 SoC.
First version is minimum only using UART, SPI and DDR memory area.
Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
The free run timer will be used to count before entering hibernate
mode. Move the related registers to the head file for accessing.
Signed-off-by: Tim Lin <tim2.lin@ite.corp-partner.google.com>
This feature got written twice for two different purposes (to inform
the SOF app of which CPUs are running, and to predicate the delivery
of IPIs to the cores ready to receive the interrupt). Use only one.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On pre-2.5 cAVS, the initial IDC interrupt to start the other core is
handled by software in the firmware ROM. That means that it has to be
unmasked for the mechanism to work (with 2.5, the interrupt is handled
by hardware regardless of what the masking state in the interrupt
controller is).
Similarly, the Xtensa Region Protection Option entries have already
been set by ROM code when we arrive in enable_l1_cache(), so we can
skip that part on older machines. Also removed because trying to
rewrite those entries was causing inexplicable hangs on cAVS 1.5,
plausibly because the region had active cache lines.
(This patch is separate for easier review in a long evolving PR.
Technically it represents a bisection problem as the "New IDC Driver"
patch before this was a regression. Seems like a safe enough thing to
handle if you land on this.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Fix various bugs with the new IDC layer that show up in edge cases
where code relies on correct timing of IPIs (unsurprisingly there is a
lot of code that recovers anyway even if the IPI doesn't arrive
promptly). Leaving this as a separate patch because the prior code in
the PR has already been reviewed and it "mostly" worked:
The unmasking of the L2 interrupt bit (remember there are three layers
of masking of the IDC interrupt) was always operating on CPU0 at CPU
startup because the code had been copied blindly. Unmask the CPU
we're actually launching. It turns out cAVS 2.x re-masks this on CPU
launch automatically.
The global init code to unmask all these interrupts at startup had the
same bug, even though it turned out to be needless (the initialization
state has it unmasked until it turns it back off). Do it right
anyway. Similarly add code to clear out existing interrupt latch
state by ACKing all IDC interrupts at startup. Seems needless, but
behavior isn't documented so let's be safe.
Flag CPU0 as always "active" for the purposes of IPIs. Forgot to do
this earlier, oops.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The alignment on .bss was coming out wrong. The ". = ALIGN(4096);"
statement was being ignored, somewhat inexplicably. This resulted in
the bss symbols being assigned corret-seeming, non-overlapping
addresses. But it overlapped the page-sized padding at the end of
.data.
As it turns out, the rimage format (not the linker or Zephyr) requires
page-sized sections to copy, and the bootloader code does that copy by
writing to the CACHED mapping of the memory (.bss is, like .data,
uncached/coherent by default). So at runtime the CPU was running in a
context where the cache was populated with "booby trap" data at the
start of .bss. True .bss access would hit the memory uncached and see
the "correct" value, but at arbitrary times during execution lines
would be flushed out of L1 cache on top of it.
Oops. This was found by accident, actually, as routine changes to the
linker script to correctly support the case where KERNEL_COHERENCE=n
(i.e. put everything in the cached mapping and nothing in uncached)
suddenly hit rimage failures because of the overlap.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add a SOC API to allow for application control over deep idle power
states. Note that the hardware idle entry happens out of the WAITI
instruction, so the application has to be responsibile for ensuring
the CPU to be halted actually reaches idle deterministically. Lots of
warnings in the docs to this effect.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There is a hardware startup state where power gating can be "enabled"
even though the core is actually launchable via an IDC interrupt (in
fact that's the hardware default). In that state, the CPU will launch
correctly but then unexpectedly shut itself off then it enters the
idle thread.
Don't rely on initialization state, always set the power and clock
gating bits (to disable gating) immediately before CPU launch.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add a struct-based interrupt masking API to match the existing shim
and IDC register interfaces. The existing interrupt controller code
isn't using it yet.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On cAVS 2.5, there is an inherent race with the IDC interrupt. It's
used for routine IPIs during OS operation, but also for launching a
power-gated core. Recent changes moved the unmasking of the IDC
interrupt earlier, which made it possible for early OS scheduler
behavior (e.g. adding the main thread to the run queue) to
accidentally launch the other cores into LP-SRAM that had not been
initialized.
Instead of treating this with initialization ordering, keep and
maintain a list of active CPUs and check them at runtime to be sure we
never try to IPI a CPU that isn't running yet. We're going to need
this feature when we add live core offlining anyway.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Use the built-in IDC handling and not IPM (which is limited to two
CPUs). Declare two cpus for now, Zephyr tests are having problems
with more at the moment (that isn't a CI configuration, so we may have
work to do).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The original interface for the intra-DSP communication hardware on
these devices was buried inside a Zephyr IPM implementation.
Unfortunately IPM is a two-endpoint point-to-point communication
layer, it can't represent the idea of devices with more than 2 cores.
And our usage (to push a no-argument/no-response scheduler IPI) was
sort of an abuse of that metaphor anyway.
Add a new IDC interface at the SOC layer, borrowing the C struct
convention already used for the DSP shim registers.
Augment with extensive documentation, extracted via a ton of
experimentation on cAVS 2.5 hardware.
Note that this leaves the previous driver in place for the cavs_v15
and intel_s1000 devices. In principle they should use it too (the
hardware registers are identical), but this hasn't been validated yet.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Earlier platforms were relying on the system ROM to have done this
correctly, but with CAVS 2.5 we launch the CPU into our own code
directly. So we need to do those steps manually. And there's also a
new one on this hardware, which has software power control over the
cache SRAM.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Hardware defaults for the secondary CPUs have the S32C1I instruction
set to be atomic only with respect to the local L1 cache, which is
basically useless on a multiprocessor platform. The CPU0 boot path
sets this manually, so we need to duplicate that here.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On MP cores that don't come through the core entry point
(e.g. TGL/v2.5) we reach C code with hardware defaults for the RPO/TLB
settings. Set these up correctly on entry.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This hardware works a little differently. The cores will start up
immediately on receipt of an IDC interrupt (they don't need the host
to be involved), but they don't have a ROM. They start executing at
the start of the LP-SRAM block always. Copy over a tiny trampoline
for them that jumps to the existing multiprocessor startup path.
Also set the PS WOE bit to enable register windows in the startup
path. This isn't the hardware default, and where the ROM would do
that for us before here we need to make sure it's on.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This reverts commit ee7773fb46.
Unfortunately this mechanism doesn't seem to actually work on the SDK
linker. The emitted sections, when passed a symbol name as the "start
address" just appear wherever the "." variable was pointing (in this
case, into the cached region). That breaks the kernel coherence
layer, obviously.
Revert for now, which will regress the XCC build fix pending a proper
root cause.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
