Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add PPR support #5

Closed
wants to merge 32 commits into from
Closed

Conversation

gmarull
Copy link

@gmarull gmarull commented Feb 1, 2024

Testing:

# app, with PPR boot + ppr
rm -rf build_*
west build -b nrf54h20pdk_nrf54h20_cpuapp samples/hello_world -d build_app -S nordic-ppr
west build -b nrf54h20pdk_nrf54h20_cpuppr samples/hello_world -d build_ppr
west flash -d build_ppr && west flash -d build_app

anangl and others added 20 commits January 31, 2024 18:22
Add a set of bindings that will be used in the nRF54H20 SoC definition.
Extend the existing GPIOTE binding with properties needed for this SoC.
Also do a tiny clean-up in the bindings added recently for nRF54L15
(HFXO and LFXO).

Signed-off-by: Grzegorz Swiderski <[email protected]>
Signed-off-by: Gerard Marull-Paretas <[email protected]>
Signed-off-by: Andrzej Głąbek <[email protected]>
Add definition of the nRF54H20 SoC revision EngA with its Application,
Radio, and Peripheral Processor (PPR) cores and basic peripherals:
GRTC, GPIOs, GPIOTE, and UARTs.

Signed-off-by: Grzegorz Swiderski <[email protected]>
Signed-off-by: Gerard Marull-Paretas <[email protected]>
Signed-off-by: Andrzej Głąbek <[email protected]>
... to cover missing __ICACHE_PRESENT and __DCACHE_PRESENT symbols that
should be defined in MDK files.

Signed-off-by: Andrzej Głąbek <[email protected]>
Move code that prepares `NRFX_CONFIG_GRTC_*` definitions based on
information from devicetree from the nRF54L15 nrfx_config header
to the global one, so that the code can be used by nRF54H20, too.

The checks that validate owned-channels and child-owned-channels
DT properties are moved to the nrf_grtc_timer driver so that
the global nrfx_config is not polluted unnecessarily.

The default values in nrfx_config_nrf54l15_enga_application.h
are restored to those from the corresponding template file.

Signed-off-by: Andrzej Głąbek <[email protected]>
Add nrfx and Kconfig related infrastructure plus SoC initialization
code to allow building for nRF54H20 targets (Application and Radio
cores).

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Signed-off-by: Andrzej Głąbek <[email protected]>
This CMake variable contains a path to a CMSIS-SVD file from nRF MDK,
which describes the selected Nordic SoC.

Initially, this will be used as an argument to nrf-regtool.

Signed-off-by: Grzegorz Swiderski <[email protected]>
nrf-regtool is a Python utility from Nordic Semiconductor, which is used
for generating binary files with register values for given peripherals.
It sources the descriptions of peripheral registers from CMSIS-SVD files
(typically ones bundled with nRF MDK).

For some peripherals, such as UICR, nrf-regtool supports parsing values
from devicetree as well, based on the bindings already found in Zephyr.

Currently, this tool is not submitted as a script to Zephyr, but it can
be installed from PyPI.

Having nrf-regtool installed is recommended when working with nRF54H20.
Booting the Application or Radiocore CPU requires flashing not only its
firmware, but also its respective UICR instance. On this SoC, the UICR
is used to assign ownership of global hardware resources, including
memory and peripherals, to individual cores. The Zephyr build system can
call nrf-regtool to generate the UICR based on devicetree, to reflect
the boot-time hardware configuration required for a given application.
The generated `uicr.hex` is then merged with `zephyr.hex`, so that they
can be flashed together using west.

The build system integration takes the form of a CMake package, which
includes a version check and reusable components; over time, some of
these components can be reused by sysbuild. This package is located in
the `hal_nordic` module, because it depends on the `SOC_SVD_FILE` CMake
variable, which is defined there as well.

Signed-off-by: Grzegorz Swiderski <[email protected]>
…4H20

On nRF54H20, only the new shim can be used and the enhanced poll out
cannot be enabled since there is no DPPI support for this SoC yet.

Signed-off-by: Andrzej Głąbek <[email protected]>
Extend Kconfig definitions and nrfx_config translations so that UARTE
instances that are available in nRF54H20 can be used.

Signed-off-by: Andrzej Głąbek <[email protected]>
... in the related parts, so that the driver can be used on nRF54H20
where the clock control is not present yet.

Signed-off-by: Andrzej Głąbek <[email protected]>
Different set of IRQ lines need to be used for this SoC and the CLOCK
IRQ is not to be installed in the vector table.

Signed-off-by: Andrzej Głąbek <[email protected]>
... so that there is no need to include that header individually
for every added board based on an nRF SoC.

Signed-off-by: Andrzej Głąbek <[email protected]>
On some new SoCs, the erase option is not required, so introduce a new
option that doesn't set any erase mode.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Add a new operation that allows erasing pages.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Add basic support to flash application and/or radio core for nRF54H
series. Note that features like merged hexes present in nRF53 series is
not supported. Flashing other cores like PPR/VPR is not supported yet.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Add targets that allows building for the Application and Radio cores
in the nRF54H20 SoC on the nRF54H20 PDK board.

Signed-off-by: Grzegorz Swiderski <[email protected]>
Signed-off-by: Gerard Marull-Paretas <[email protected]>
Signed-off-by: Andrzej Głąbek <[email protected]>
Similar to nRF54L15, the MDK files in HAL for this SoC are not
compatible with C++98, so currently the test cannot be performed
on this SoC.

Signed-off-by: Andrzej Głąbek <[email protected]>
Use names that are more explicit: execution-memory and source-memory.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Add a custom driver that takes care of loading and launching RISC-V VPR
cores found on the new nRF54 SoCs.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
So that we only need to enable cpuppr_ram3x_region and cpuppr_vpr to
enable PPR.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
@gmarull gmarull mentioned this pull request Feb 1, 2024
@gmarull gmarull force-pushed the ppr-support branch 2 times, most recently from 4cd5030 to 01571d8 Compare February 1, 2024 10:58
@gmarull gmarull force-pushed the ppr-support branch 6 times, most recently from 2ea0036 to 21e3a25 Compare February 1, 2024 13:27
The core is named "VPR".

Signed-off-by: Gerard Marull-Paretas <[email protected]>
To specify the CPU bus width.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
It is now a required property.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Add nrfx configuration file and CMake injected definitions to make the
nrfx HAL work for nRF54H PPR core.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
# Copyright (c) 2024 Nordic Semiconductor ASA
# SPDX-License-Identifier: Apache-2.0

config RISCV_CORE_NORDIC_VPR
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note for future: we should think of moving core-dependent code to arch/riscv/cores, or soc/common since we could potentially have independent socs running the same riscv cores. not likely the case for VPR though.

Comment on lines +8 to +26
void arch_irq_enable(unsigned int irq)
{
nrf_vpr_clic_int_enable_set(NRF_VPRCLIC, irq, true);
}

void arch_irq_disable(unsigned int irq)
{
nrf_vpr_clic_int_enable_set(NRF_VPRCLIC, irq, false);
}

void arch_irq_priority_set(unsigned int irq, unsigned int prio)
{
nrf_vpr_clic_int_priority_set(NRF_VPRCLIC, irq, prio);
}

int arch_irq_is_enabled(unsigned int irq)
{
return nrf_vpr_clic_int_enable_check(NRF_VPRCLIC, irq);
}
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for future: we should have a generic CLIC driver, but things are still a bit messy in riscv.

dt_chosen_partition_addr_int|hex allow obtaining the absolute address of
a partition, which is the result of the grandparent node address plus
the partition node address.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Because both, RISC-V and ARM cores share the same pinctrl driver. The
top level common folder will disappear with the introduction of HWMv2,
where multi-arch SoCs will be well supported.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Because RISC-V cores also need to include this file, so it is no longer
ARM specific.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Add initial support for the VPR RISC-V core found in the new nRF54 SoCs.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Add support for the nRF54H PPR (Peripheral Processor), based on the VPR
RISC-V core.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
Add a board that allows to build for the nRF54H20 PPR RISC-V core.

Signed-off-by: Gerard Marull-Paretas <[email protected]>
@anangl
Copy link
Owner

anangl commented Feb 2, 2024

Integrated into zephyrproject-rtos#68043.

@anangl anangl closed this Feb 2, 2024
@gmarull gmarull deleted the ppr-support branch February 2, 2024 12:08
anangl pushed a commit that referenced this pull request Nov 4, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.

==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68

READ of size 2 at 0x000000ad81c2 thread T6
    #0 0x5279b2  (/root/zephyr.exe+0x5279b2)
    #1 0x4d697d  (/root/zephyr.exe+0x4d697d)
    #2 0x7ffff60e5daa  (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    #1 0x530192  (/root/zephyr.exe+0x530192)
    #2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T2 created by T1 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    #1 0x530192  (/root/zephyr.exe+0x530192)
    #2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T1 created by T0 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    #1 0x52f36c  (/root/zephyr.exe+0x52f36c)
    #2 0x5371dc  (/root/zephyr.exe+0x5371dc)
    #3 0x5312a6  (/root/zephyr.exe+0x5312a6)
    #4 0x52ed7b  (/root/zephyr.exe+0x52ed7b)
    #5 0x52eddd  (/root/zephyr.exe+0x52eddd)
    #6 0x7ffff6083c89  (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

==5==ABORTING

Signed-off-by: Sungwoo Kim <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants