Hello,
My name is Andrei Cherechesu and I'm a Software Engineer at NXP
Semiconductors in the Automotive department, Linux BSP Team.
I would like to tell you have done a great job so far with Xen.
Thus, we have ported and integrated Xen ARM in the Linux BSP for our
boards.
Currently, w
> On Mon, 16 Dec 2019, Julien Grall wrote:
> > On 16/12/2019 23:05, Stefano Stabellini wrote:
> > > On Mon, 16 Dec 2019, Julien Grall wrote:
> > > > On 16/12/2019 18:02, Andrei Cherechesu wrote:
> > > > But even with this patch, RAM in DomU is not
> On Thu, 13 Feb 2020, Andrei Cherechesu wrote:
> > Hello,
> >
> > I used the Xen from Stefano's tree and made the updates to the partial
> > dtb that he specified.
> >
> > > This is mostly likely because Linux is trying to access a region
>
dt_device_set_used_by(dev, DOMID_XEN);
>
> Devices that are marked as "used by Xen" are not exposed to dom0, so you
> shouldn't see the ttyLF0 device come up in Linux at all.
I've checked my Xen UART Driver and that call is there. So ttyLF0 should be
marked for Xen to use.
I don't have any ideas why this happens.
I've attached the driver [0], if you want to take a look.
[0] https://pastebin.com/PuXi50H0
Thanks,
Andrei Cherechesu,
NXP Semiconductors
-> got it�
I started debugging and I found out that it hangs in:
console_init_preirq() -> __putstr(xen_banner()) -> sercon_puts() ->
serial_puts() -> __serial_putc(),
where it spins at line 178:
/* Synchronous finite-capacity transmitter. */
while ( !(n = port->driver->tx_ready(port)) )
cpu_relax();
Which is a bit strange, considering that my serial device is asynchronous,
I think it should not get there. But it gets on that "else" branch because
port->txbuf is actually NULL at line 120 when it performs the check, and
it does not enter the branch for asynchronous transmitters.
Thanks,
Andrei Cherechesu,
NXP Semiconductors
o tried to pass a static IP configuration for DomU in the config file,
and because it automatically enables eth0 at boot time, I no longer get the
oops, but a panic directly.
Thank you very much for your help,
Andrei Cherechesu,
NXP Semiconductors
[[ Sorry. Needed to send another mail because I forgot to add xen-devel lists
to CC. ]]
Hello,
I applied your direct-map patch, Stefano, on top of RELEASE-4.13.0
Xen.
I also took your advice and used the Imagebuilder tool to setup my
u-boot environment. I modified the tool to allow SDCard booti
-Original Message-
From: Julien Grall
Sent: Thursday, February 13, 2020 00:03
To: Stefano Stabellini ; Andrei Cherechesu
Cc: Jorge Pereira ; xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second
stage MMU.
Hello,
I used the Xen
Hi Julien,
Sorry for the slow replies.
On 08/10/2024 23:31, Julien Grall wrote:
> Hi,
>
> On 08/10/2024 20:01, Andrei Cherechesu wrote:
>> Hi Julien,
>>
>> On 04/10/2024 19:24, Julien Grall wrote:
>>>
>>>
>>> On 04/10/2024 16:37, Andrei
Hi Julien,
On 04/10/2024 19:24, Julien Grall wrote:
>
>
> On 04/10/2024 16:37, Andrei Cherechesu wrote:
>> Hi Julien, Stefano,
>
> Hi Andrei,
>
>>
>> On 01/10/2024 13:01, Julien Grall wrote:
>>> Hi Andrei,
>>>
>>> On 30/09/2024 12:
Hi Julien, Stefano,
On 01/10/2024 13:01, Julien Grall wrote:
> Hi Andrei,
>
> On 30/09/2024 12:47, Andrei Cherechesu (OSS) wrote:
>> From: Andrei Cherechesu
>>
>> Add code for NXP S32CC platforms (S32G2, S32G3, S32R45).
>>
>> S32CC platforms use the NXP
Hi Julien,
On 01/10/2024 12:20, Julien Grall wrote:
> Hi Andrei,
>
> On 30/09/2024 12:47, Andrei Cherechesu (OSS) wrote:
>> +static void __init linflex_uart_init_preirq(struct serial_port *port)
>> +{
>> + struct linflex_uart *uart = port->uart;
>> + uin
Hi Julien,
On 01/10/2024 12:35, Julien Grall wrote:
>
>
> On 30/09/2024 12:47, Andrei Cherechesu (OSS) wrote:
>> From: Andrei Cherechesu
>>
>> Introduce the SCMI layer to have some basic degree of awareness
>> about SMC calls that are based on the ARM System Co
Hi Julien,
On 01/10/2024 12:59, Julien Grall wrote:
> Hi Andrei,
>
> On 30/09/2024 12:47, Andrei Cherechesu (OSS) wrote:
>> +/*
>> + * Generic handler for SCMI-SMC requests, currently only forwarding the
>> + * request to FW running at EL3 if it came from Dom0.
Hi Julien,
On 01/10/2024 12:46, Julien Grall wrote:
> Hi,
>
> On 30/09/2024 12:47, Andrei Cherechesu (OSS) wrote:
>> From: Andrei Cherechesu
>>
>> Change the handling of SiP SMC calls to be more generic,
>> instead of directly relying on the `platform_
Hi Julien,
On 03/10/2024 19:07, Julien Grall wrote:
>
>
> On 03/10/2024 16:27, Andrei Cherechesu wrote:
>> Hi Julien,
>
> Hi Andrei,
>
>> On 01/10/2024 12:35, Julien Grall wrote:
>>>
>>>> , the initialization fails silently, as it's n
ainers in CC. I added them now.
>
>> On 7 Mar 2023, at 11:09, Andrei Cherechesu (OSS)
>> wrote:
>>
>> From: Andrei Cherechesu
>>
>> This 2-patch series fixes the parsing of the ARM Generic Timer
>> interrupts from the device tree.
>>
>> I
On 07/03/2023 17:38, Bertrand Marquis wrote:
> Hi Andrei,
>
>> On 7 Mar 2023, at 11:09, Andrei Cherechesu (OSS)
>> wrote:
>>
>> From: Andrei Cherechesu
>>
>> Added support for parsing the ARM generic timer interrupts DT
>> node by the "in
:
>>>>>>
>>>>>>
>>>>>> Hi Michal,
>>>>>>
>>>>>>> On 9 Mar 2023, at 11:05, Michal Orzel wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>&g
Hi Julien,
On 21/03/2023 18:56, Julien Grall wrote:
> Hi Andrei,
>
> I realized this has already been merged. But I would like to point out a
> few things for future series.
>
> On 13/03/2023 13:08, Andrei Cherechesu (OSS) wrote:
>> From: Andrei Cherechesu
>>
&
?
Here are the full logs for the "xl create" command [0] and for DomU's dmesg [1].
Any ideas as to why that might happen, some debugging insights, or maybe some
configuration details I could have overlooked?
Thank you very much for your help once again.
Regards,
Andrei Cherec
On 12/04/2024 11:35, Edgar E. Iglesias wrote:
> On Fri, Apr 12, 2024 at 1:23 AM Stefano Stabellini
> wrote:
>
> -Vikram +Edgar
>
> On Thu, 11 Apr 2024, Andrei Cherechesu wrote:
>>> I've managed to successfully get a DomU up and running with the rootfs
>>&
Hi, Julien, and thank you for the review!
On 11/09/2024 00:55, Julien Grall wrote:
> Hi,
>
> On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
>> From: Andrei Cherechesu
>>
>> The LINFlexD UART is an UART controller available on NXP S32
>> processors family
On 11/09/2024 00:58, Julien Grall wrote:
> Hi,
>
> On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
>> From: Andrei Cherechesu
>>
>> This adds support for early printk debug via the NXP LINFlexD
>> UART controller.
>>
>> Signed-off-by: Andrei Che
Hi Julien, Stefano,
On 11/09/2024 08:19, Stefano Stabellini wrote:
> On Tue, 10 Sep 2024, Julien Grall wrote:
>> Hi,
>>
>> On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
>>> From: Andrei Cherechesu
>>>
>>> Added support for NXP S32CC platf
Hi Julien, Grygorii,
On 11/11/2024 12:33, Julien Grall wrote:
> Hi,
>
> On 01/11/2024 15:22, Grygorii Strashko wrote:
>> Hi
>>
>> I'd be apprcieated if could consider my comments below.
>>
>> On 30.09.24 14:47, Andrei Cherechesu (OSS) wrote:
>>>
Hi Bertrand, Andrew,
On 18/12/2024 17:33, Bertrand Marquis wrote:
> Hi Andrew,
>
>> On 18 Dec 2024, at 16:19, Andrew Cooper wrote:
>>
>> On 18/12/2024 10:11 am, Andrei Cherechesu (OSS) wrote:
>>> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platf
Hi Michal,
Thank you for the review.
On 18/12/2024 16:26, Michal Orzel wrote:
>
> On 18/12/2024 11:11, Andrei Cherechesu (OSS) wrote:
>>
>> From: Andrei Cherechesu
>>
>> Introduce the SCMI-SMC layer to have some basic degree of
>> awareness about SCMI ca
Hi Michal,
On 19/12/2024 10:35, Michal Orzel wrote:
>
> On 18/12/2024 15:58, Andrei Cherechesu wrote:
>>
>> Hi Michal,
>>
>> Thank you for the review.
>>
>> On 18/12/2024 16:26, Michal Orzel wrote:
>>> On 18/12/2024 11:11, Andrei C
Hi,
On 20/12/2024 09:32, Michal Orzel wrote:
>
> On 19/12/2024 12:23, Andrei Cherechesu (OSS) wrote:
>>
>> From: Andrei Cherechesu
>>
>> Targeting: Xen 4.20
>> This v4 version of this patch series finishes the work left to support NXP
>> S32G3 Process
Hi Stefano,
On 26/04/2025 02:35, Stefano Stabellini wrote:
> From: Andrei Cherechesu
>
> Normally, the Imagebuilder would precompute the sizes of the loaded binaries
> and addresses where they are loaded before generating the script, and the
> sizes and addresses that needed to
Hi Stefano,
On 28/04/2025 23:55, Andrei Cherechesu wrote:
> From: Andrei Cherechesu
>
> Normally, the Imagebuilder would precompute the sizes of the loaded
> binaries and addresses where they are loaded before generating the
> script, and the sizes and addresses that needed to
From: Andrei Cherechesu
The LINFlexD UART is an UART controller available on NXP S32
processors family targeting automotive (for example: S32G2, S32G3,
S32R).
S32G3 Reference Manual:
https://www.nxp.com/webapp/Download?colCode=RMS32G3.
Signed-off-by: Andrei Cherechesu
Signed-off-by: Peter van
From: Andrei Cherechesu
Introduce the SCMI layer to have some basic degree of awareness
about SMC calls that are based on the ARM System Control and
Management Interface (SCMI) specification (DEN0056E).
The SCMI specification includes various protocols for managing
system-level resources, such
From: Andrei Cherechesu
Add code for NXP S32CC platforms (S32G2, S32G3, S32R45).
S32CC platforms use the NXP LINFlexD UART driver for
console by default, and rely on Dom0 having access to
SCMI services for system-level resources from firmware
at EL3.
Platform-related quirks will be addressed
From: Andrei Cherechesu
This patch series adds support for NXP Automotive S32CC platform
family, which includes S32G [0] and S32R [1].
First patch adds the driver for the NXP LINFlexD UART, available
on S32V, S32G and S32R automotive processors. The compatibles in
the driver match the ones in
From: Andrei Cherechesu
This adds support for early printk debug via the NXP LINFlexD
UART controller.
Signed-off-by: Andrei Cherechesu
Signed-off-by: Peter van der Perk
Acked-by: Julien Grall
---
xen/arch/arm/Kconfig.debug | 12 ++
xen/arch/arm/arm64/debug-linflex.inc | 58
From: Andrei Cherechesu
Add myself as maintainer for NXP S32CC SoCs Family,
and the S32 Linux Team as relevant reviewers list.
Also add the linflex-uart.c driver to the list of other
UART drivers in the ARM section.
Signed-off-by: Andrei Cherechesu
---
MAINTAINERS | 8
1 file
From: Andrei Cherechesu
Describe the layer which enables SCMI over SMC calls forwarding
to EL3 FW if issued by Dom0. If the SCMI firmware node is not
found in Dom0's DT during initialization, it fails silently
as it's not mandatory.
The SCMI SMCs trapping at EL2 now lets Dom0 perfor
From: Andrei Cherechesu
Change the handling of SiP SMC calls to be more generic,
instead of directly relying on the `platform_smc()` callback
implementation.
Try to handle the SiP SMC first through the `platform_smc()`
callback (if implemented). If not handled, check if the
SCMI layer is
From: Andrei Cherechesu
Signed-off-by: Andrei Cherechesu
---
CHANGELOG.md | 4
1 file changed, 4 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 26e7d8dd2a..66ea505843 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -11,6 +11,10 @@ The format is based on [Keep a
Changelog
From: Andrei Cherechesu
If the "BOOT_CMD" variable is set to "none" inside the config
file, the boot command (i.e. "booti") will not by added to the
generated script, to allow the user to customize the u-boot env
or the device-tree after executing the script comman
From: Andrei Cherechesu
Hello,
Sorry for the late re-submission of patches, but I had some
company internal work to take care of. I managed to include the
changes mentioned by Stefano S. and Ayan K. H. in the discussions
for the first version of patches.
Changes in v2:
- Dropped the patch
From: Andrei Cherechesu
Added support for prepending path to file names in the final generated
u-boot script, for the use-case where we have the files in a separate
folder that can be accessed with a given $LOAD_CMD.
For example, we can have "fatload mmc 0:2" as LOAD_CMD but the
f
From: Andrei Cherechesu
Normally, the script would precompute the sizes of the loaded binaries
and addresses where they are loaded before generating the script,
and the sizes and addresses that needed to be provided to Xen via
/chosen would be hardcoded in the boot script.
Added option via &qu
From: Andrei Cherechesu
Added the "-a" parameter which stands for APPEND_EXTRA_CMDS option,
which enables the user to specify the path to a text file that contains,
on each line, u-boot commands that will be added to the generated script as
"fixups", before the boot command.
From: Andrei Cherechesu
Normally, the script would precompute the sizes of the loaded binaries
and addresses where they are loaded before generating the script,
and the sizes and addresses that needed to be provided to Xen via
/chosen would be hardcoded in the boot script.
Added option via &qu
From: Andrei Cherechesu
Hello,
This the v3 version for the patches which have not yet been commited.
Changes in v3:
- Dropped the [PATCH v2 1/4] from the previous series since it's already
been commited
- For PATCH 1/3: No changes
- For PATCH 2/3: Dropped the "-a" parameter and
From: Andrei Cherechesu
Added the parsing for APPEND_EXTRA_CMDS variable, which enables the
user to specify the path to a text file that contains, on each line,
u-boot commands that will be added to the generated script as
"fixups", before the boot command.
The file specif
From: Andrei Cherechesu
If the "BOOT_CMD" variable is set to "none" inside the config
file, the boot command (i.e. "booti") will not by added to the
generated script, to allow the user to customize the u-boot env
or the device-tree after executing the script comman
From: Andrei Cherechesu
This 2-patch series fixes the parsing of the ARM Generic Timer
interrupts from the device tree.
If the generic timer interrupts order in the DT was different than
the expected order in Xen code, these interrupts would no longer be
correctly parsed and registered by Xen
From: Andrei Cherechesu
Moved implementation for the function which parses the IRQs of a DT
node by the "interrupt-names" property from the SMMU-v3 driver
to the IRQ core code and made it non-static to be used as helper.
Also changed it to receive a "struct dt_device_node*"
From: Andrei Cherechesu
Added support for parsing the ARM generic timer interrupts DT
node by the "interrupt-names" property, if it is available.
If not available, the usual parsing based on the expected
IRQ order is performed.
Also added the "hyp-virt" PPI to the timer P
From: Andrei Cherechesu
This 2-patch series fixes the parsing of the ARM Generic Timer
interrupts from the device tree.
If the generic timer interrupts order in the DT was different than
the expected order in Xen code, these interrupts would no longer be
correctly parsed and registered by Xen
From: Andrei Cherechesu
Moved implementation for the function which parses the IRQs of a DT
node by the "interrupt-names" property from the SMMU-v3 driver
to the IRQ core code and made it non-static to be used as helper.
Also changed it to receive a "struct dt_device_node*"
From: Andrei Cherechesu
Added support for parsing the ARM generic timer interrupts DT
node by the "interrupt-names" property, if it is available.
If not available, the usual parsing based on the expected
IRQ order is performed.
Also changed to treating returning 0 as an error ca
From: Andrei Cherechesu
Added support for parsing the ARM generic timer interrupts DT
node by the "interrupt-names" property, if it is available.
If not available, the usual parsing based on the expected
IRQ order is performed.
Also treated returning 0 as an error case for the
platfo
From: Andrei Cherechesu
Moved implementation for the function which parses the IRQs of a DT
node by the "interrupt-names" property from the SMMU-v3 driver
to the IRQ core code and made it non-static to be used as helper.
Also changed it to receive a "struct dt_device_node*"
From: Andrei Cherechesu
This 2-patch series fixes the parsing of the ARM Generic Timer
interrupts from the device tree.
If the generic timer interrupts order in the DT was different than
the expected order in Xen code, these interrupts would no longer be
correctly parsed and registered by Xen
s fine, and the domain is
reachable via SSH and can continue to process the workload.
We've not been able so far to figure out why this happens, so any help would be
appreciated. If you need other Domain configuration details or any inputs from
our side, let us know.
Thank you,
Andrei Cherechesu
Hello, Julien, Stefano,
Thank you for your replies.
On 21/07/2023 02:25, Stefano Stabellini wrote:
>
> On Thu, 20 Jul 2023, Julien Grall wrote:
>> (+ Juergen)
>>
>> On 19/07/2023 17:13, Andrei Cherechesu (OSS) wrote:
>>> Hello,
>>
>> Hi Andrei,
&g
ch for the support, once again, and we're also looking
forward to the progress on the rust-vmm initiative.
Regards,
Andrei Cherechesu,
NXP Semiconductors
[0] https://github.com/xen-troops/virtio-disk
From: Andrei Cherechesu
Enabled the support for debug through early printk on S32CC
platforms via the NXP LINFlexD UART driver.
Signed-off-by: Andrei Cherechesu
---
xen/arch/arm/Kconfig.debug | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm
From: Andrei Cherechesu
All versions of Cortex-A53 cores are affected by the speculative
AT instruction erratum, as mentioned in the Cortex-A53 Revision r0
SDEN v21 documentation.
Enabled ARM64_WORKAROUND_AT_SPECULATE for all versions of Cortex-A53
cores, to avoid corrupting the TLB if
From: Andrei Cherechesu
This patch series adds support for NXP Automotive S32CC platform
family, which includes S32G [0] and S32R [1].
First patch adds the driver for the NXP LINFlexD UART, available
on S32V, S32G and S32R automotive processors. The compatibles in
the driver match the ones in
From: Andrei Cherechesu
This adds support for early printk debug via the NXP LINFlexD
UART controller.
Signed-off-by: Andrei Cherechesu
Signed-off-by: Peter van der Perk
---
xen/arch/arm/Kconfig.debug | 14 +++
xen/arch/arm/arm64/debug-linflex.inc | 58
From: Andrei Cherechesu
The LINFlexD UART is an UART controller available on NXP S32
processors family targeting automotive (for example: S32G2, S32G3,
S32R).
S32G3 Reference Manual:
https://www.nxp.com/webapp/Download?colCode=RMS32G3.
Signed-off-by: Andrei Cherechesu
Signed-off-by: Peter van
From: Andrei Cherechesu
Added support for NXP S32CC platforms (S32G2, S32G3, S32R45),
which need SCMI over SMC calls forwarded to the firmware
running at EL3 (TF-A). Linux relies on the SCMI Platform
for system services such as clocking, reset, etc.
S32CC platforms use the NXP LINFlexD UART
From: Andrei Cherechesu
This sent patch adds support for dynamically computing the addresses
and sizes for loaded binaries via the boot script generated by
Imagebuilder.
Compared to the v3 version of the patch, this includes Stefano's
suggestions of not adding as many "if" st
From: Andrei Cherechesu
Normally, the Imagebuilder would precompute the sizes of the loaded
binaries and addresses where they are loaded before generating the
script, and the sizes and addresses that needed to be provided to
Xen via /chosen would be hardcoded in the boot script.
Added an option
From: Andrei Cherechesu
Targeting: Xen 4.20
This v3 version of this patch series finishes the work left to support NXP
S32G3 Processors [0], part of the NXP S32CC Family. The LINFlexD UART support
patches have been merged in v2. Platforms using S32G3 Processors are not
affected by the TLBI by VA
From: Andrei Cherechesu
Change the handling of SiP SMC calls to be more generic,
instead of directly relying on the `platform_smc()` callback
implementation.
Try to handle the SiP SMC first through the `platform_smc()`
callback (if implemented). If not handled, check if the
SCMI layer is
From: Andrei Cherechesu
Signed-off-by: Andrei Cherechesu
---
CHANGELOG.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 15f681459f..bda43b1efb 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,9 @@ The format is based on [Keep a
Changelog
From: Andrei Cherechesu
Add myself as maintainer for NXP S32G3 SoCs Family,
and the S32 Linux Team as relevant reviewers list.
Signed-off-by: Andrei Cherechesu
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 34ad49bc39..392f780f76
From: Andrei Cherechesu
Introduce the SCMI-SMC layer to have some basic degree of
awareness about SCMI calls that are based on the ARM System
Control and Management Interface (SCMI) specification (DEN0056E).
The SCMI specification includes various protocols for managing
system-level resources
From: Andrei Cherechesu
Describe the layer which enables SCMI over SMC calls forwarding
to EL3 FW if issued by the Hardware domain. If the SCMI firmware
node is not found in the Host DT during initialization, it fails
silently as it's not mandatory.
The SCMI SMCs trapping at EL2 now lets
From: Andrei Cherechesu
Platforms based on NXP S32G3 processors use the NXP LINFlexD
UART driver for console by default, and rely on Dom0 having
access to SCMI services for system-level resources from
firmware at EL3.
Signed-off-by: Andrei Cherechesu
---
xen/arch/arm/platforms/Kconfig | 8
From: Andrei Cherechesu
Describe the layer which enables SCMI over SMC calls forwarding
to EL3 FW if issued by the Hardware domain. If the SCMI firmware
node is not found in the Host DT during initialization, it fails
silently as it's not mandatory.
The SCMI SMCs trapping at EL2 now lets
From: Andrei Cherechesu
Platforms based on NXP S32G3 processors use the NXP LINFlexD
UART driver for console by default, and rely on Dom0 having
access to SCMI services for system-level resources from
firmware at EL3.
Signed-off-by: Andrei Cherechesu
Reviewed-by: Bertrand Marquis
---
xen
From: Andrei Cherechesu
Targeting: Xen 4.20
This v4 version of this patch series finishes the work left to support NXP
S32G3 Processors [0], part of the NXP S32CC Family. The LINFlexD UART support
patches have been merged in v2. Platforms using S32G3 Processors are not
affected by the TLBI by VA
From: Andrei Cherechesu
Add myself as maintainer for NXP S32G3 SoCs Family,
and the S32 Linux Team as relevant reviewers list.
Signed-off-by: Andrei Cherechesu
Acked-by: Bertrand Marquis
Acked-by: Michal Orzel
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a
From: Andrei Cherechesu
Introduce the SCMI-SMC layer to have some basic degree of
awareness about SCMI calls that are based on the ARM System
Control and Management Interface (SCMI) specification (DEN0056E).
The SCMI specification includes various protocols for managing
system-level resources
From: Andrei Cherechesu
Change the handling of SiP SMC calls to be more generic,
instead of directly relying on the `platform_smc()` callback
implementation.
Try to handle the SiP SMC first through the `platform_smc()`
callback (if implemented). Otherwise, try to handle it as SCMI
message
From: Andrei Cherechesu
Signed-off-by: Andrei Cherechesu
Reviewed-by: Bertrand Marquis
Acked-by: Oleksii Kurochko
---
CHANGELOG.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 15f681459f..bda43b1efb 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
84 matches
Mail list logo
