- TF-A - lists.trustedfirmware.org

[PATCHv5 0/3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

v5: - removed vms flag, added fdt (Andrew Jones) - added patch3 to combine secure and non secure pl061. It has to be more easy to review if this changes are in the separate patch. v4: rework patches accodring to Peter Maydells comments: - split patches on gpio-pwr driver and arm-virt integration. - start secure gpio only from virt-6.0. - rework qemu interface for gpio-pwr to use 2 named gpio. - put secure gpio to secure name space. v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down arm-virt: combine code for secure and non secure pl061 hw/arm/Kconfig | 1 + hw/arm/virt.c | 118 +++++++++++++++++++++++++++++++++++------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 175 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 4 months

1
3
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 365287: Control flow issues (MISSING_BREAK) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 334 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 365287: Control flow issues (MISSING_BREAK) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 334 in pm_smc_handler() 328 SMC_RET1(handle, (uint64_t)ret); 329 330 case PM_SET_MAX_LATENCY: 331 ret = pm_set_max_latency(pm_arg[0], pm_arg[1]); 332 SMC_RET1(handle, (uint64_t)ret); 333 >>> CID 365287: Control flow issues (MISSING_BREAK) >>> The case for value "PM_GET_API_VERSION" is not terminated by a 'break' statement. 334 case PM_GET_API_VERSION: 335 /* Check is PM API version already verified */ 336 if (pm_ctx.api_version >= PM_VERSION) { 337 if (!ipi_irq_flag) { 338 /* 339 * Enable IPI IRQ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 4 months

1
0
0 0

Re: [TF-A] Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B

by Manish Pandey2

Hi To understand the interrupt handling in TF-A, i recommend you go through https://trustedfirmware-a.readthedocs.io/en/latest/design/interrupt-framewo… To debug your problem, you need to first check if the timer interrupt is generated as FIQ and check whether it indeed is trapped in EL3 (checking SCR_EL3.FIQ=1). Regarding build errors while adding .S files and your assembly implementation, it will be better if you share your code (may be pushing a patch on https://review.trustedfirmware.org). Thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Ian Burres via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 06 January 2021 17:56 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B I am attempting to route FIQ timer interrupts using the ARM timers (not system timers) to EL3 in order to achieve introspection. I am running TF-A (cross compiled for AArch64/AArch32) on a Raspberry Pi 4B, which uses the Broadcom 2711 chipset. I have written some code, but I am not an embedded software engineer – I’m an IoT pentester. The ARM timers look like this: RPI4_ARM_TIMER_LOAD 0x400 RPI4_ARM_TIMER_VALUE 0x404 ….. RPI4_ARM_TIMER_FREE_COUNTER 0x420 System timers are: RPI4_SYS_TIMER_CLO, RPI4_SYS_TIMER_CS, etc… I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ). I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient. I have 3 UARTs attached with a debug log and screen setup. From what I have read, the Raspberry Pi 4B uses GICv2. TF-A supports EL3 routing when the build option GICV2_GO_FOR_EL3 is enabled, which I have done. >From what I have gathered, the FIQ interrupt has to be written in assembly. So far, I have created a vector table, loaded the vector table, and masked and unmasked interrupts using daifclr, #3 and daifset, #3 instructions, using inline assembly. The timer is initinitialized and handled using C functions. I am using inline assembly, because I am adding code to the TF-A base, and I have not discovered how to add .S files to the build without receiving make errors. I will gladly share the code I have if it helps, but what I am really looking for is if anyone believes I am on the right track or not. Obviously, I am not implementing something correctly since the interrupt is not being handled. Thanks. Thomas Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

4 years, 4 months

2
1
0 0

[PATCHv3] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- v3: added missed include qemu/log.h for qemu_log(.. v2: replace printf with qemu_log (Philippe Mathieu-Daudé) hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 ++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 85 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 115 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..0d0680c9f7 --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,85 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "qemu/log.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + qemu_log_mask(LOG_GUEST_ERROR, + "qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

4 years, 4 months

3
3
0 0

Routing FIQ timer interrupts to EL3 on Raspberry Pi 4B

by Ian Burres

I am attempting to route FIQ timer interrupts using the ARM timers (not system timers) to EL3 in order to achieve introspection. I am running TF-A (cross compiled for AArch64/AArch32) on a Raspberry Pi 4B, which uses the Broadcom 2711 chipset. I have written some code, but I am not an embedded software engineer – I’m an IoT pentester. The ARM timers look like this: RPI4_ARM_TIMER_LOAD 0x400 RPI4_ARM_TIMER_VALUE 0x404 ….. RPI4_ARM_TIMER_FREE_COUNTER 0x420 System timers are: RPI4_SYS_TIMER_CLO, RPI4_SYS_TIMER_CS, etc… I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ). I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient. I have 3 UARTs attached with a debug log and screen setup. >From what I have read, the Raspberry Pi 4B uses GICv2. TF-A supports EL3 routing when the build option GICV2_GO_FOR_EL3 is enabled, which I have done. >From what I have gathered, the FIQ interrupt has to be written in assembly. So far, I have created a vector table, loaded the vector table, and masked and unmasked interrupts using daifclr, #3 and daifset, #3 instructions, using inline assembly. The timer is initinitialized and handled using C functions. I am using inline assembly, because I am adding code to the TF-A base, and I have not discovered how to add .S files to the build without receiving make errors. I will gladly share the code I have if it helps, but what I am really looking for is if anyone believes I am on the right track or not. Obviously, I am not implementing something correctly since the interrupt is not being handled. Thanks. Thomas Sent from Mail for Windows 10

4 years, 4 months

1
0
0 0

[PATCHv2] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- v2: replace printf with qemu_log (Philippe Mathieu-Daudé) hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 +++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 84 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 114 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..f5868653b3 --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,84 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + qemu_log_mask(LOG_GUEST_ERROR, + "qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

4 years, 4 months

1
0
0 0

[PATCH] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

Add secure pl061 for reset/power down machine from the secure world (Arm Trusted Firmware). Use the same gpio 3 and gpio 4 which were used by non acpi variant of linux power control gpios. Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org> --- This patch works together with ATF patch: https://github.com/muvarov/arm-trusted-firmware/commit/dd4401d8eb8e0f3018b3… Previus discussion for reboot issue was here: https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html Regards, Maxim. hw/arm/Kconfig | 1 + hw/arm/virt.c | 24 +++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 83 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 1 + 6 files changed, 113 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig index 0a242e4c5d..13cc42dcc8 100644 --- a/hw/arm/Kconfig +++ b/hw/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_VIRT select PL011 # UART select PL031 # RTC select PL061 # GPIO + select GPIO_PWR select PLATFORM_BUS select SMBIOS select VIRTIO_MMIO diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 96985917d3..eff0345303 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = { [VIRT_RTC] = { 0x09010000, 0x00001000 }, [VIRT_FW_CFG] = { 0x09020000, 0x00000018 }, [VIRT_GPIO] = { 0x09030000, 0x00001000 }, + [VIRT_SECURE_GPIO] = { 0x09031000, 0x00001000 }, [VIRT_SECURE_UART] = { 0x09040000, 0x00001000 }, [VIRT_SMMU] = { 0x09050000, 0x00020000 }, [VIRT_PCDIMM_ACPI] = { 0x09070000, MEMORY_HOTPLUG_IO_LEN }, @@ -189,6 +190,7 @@ static const int a15irqmap[] = { [VIRT_GPIO] = 7, [VIRT_SECURE_UART] = 8, [VIRT_ACPI_GED] = 9, + [VIRT_SECURE_GPIO] = 10, [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */ [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */ @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms) g_free(nodename); } +static void create_gpio_secure(const VirtMachineState *vms) +{ + DeviceState *pl061_dev; + static DeviceState *gpio_pwr_dev; + + hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base; + int irq = vms->irqmap[VIRT_SECURE_GPIO]; + + pl061_dev = sysbus_create_simple("pl061", base, + qdev_get_gpio_in(vms->gic, irq)); + + gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1, + qdev_get_gpio_in(pl061_dev, 3)); + + qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3)); + qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4)); +} + static void create_virtio_devices(const VirtMachineState *vms) { int i; @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine) create_gpio(vms); } + if (vms->secure) { + create_gpio_secure(vms); + } + /* connect powerdown request */ vms->powerdown_notifier.notify = virt_powerdown_req; qemu_register_powerdown_notifier(&vms->powerdown_notifier); diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig index b6fdaa2586..f0e7405f6e 100644 --- a/hw/gpio/Kconfig +++ b/hw/gpio/Kconfig @@ -8,5 +8,8 @@ config PL061 config GPIO_KEY bool +config GPIO_PWR + bool + config SIFIVE_GPIO bool diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c new file mode 100644 index 0000000000..dded12381b --- /dev/null +++ b/hw/gpio/gpio_pwr.c @@ -0,0 +1,83 @@ +/* + * GPIO qemu power controller + * + * Copyright (c) 2020 Linaro Limited + * + * Author: Maxim Uvarov <maxim.uvarov(a)linaro.org> + * + * Virtual gpio driver which can be used on top of pl061 + * to reboot and shutdown qemu virtual machine. One of use + * case is gpio driver for secure world application (ARM + * Trusted Firmware.). + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + * SPDX-License-Identifier: GPL-2.0-or-later + */ + +#include "qemu/osdep.h" +#include "hw/irq.h" +#include "hw/sysbus.h" +#include "sysemu/runstate.h" + +#define TYPE_GPIOPWR "gpio-pwr" +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR) + +struct GPIO_PWR_State { + SysBusDevice parent_obj; + qemu_irq irq; +}; + +static void gpio_pwr_set_irq(void *opaque, int irq, int level) +{ + GPIO_PWR_State *s = (GPIO_PWR_State *)opaque; + + qemu_set_irq(s->irq, 1); + + if (level) { + return; + } + + switch (irq) { + case 3: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN); + break; + case 4: + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET); + break; + default: + printf("qemu; gpio_pwr: unknown interrupt %d lvl %d\n", + irq, level); + } +} + + +static void gpio_pwr_realize(DeviceState *dev, Error **errp) +{ + GPIO_PWR_State *s = GPIOPWR(dev); + SysBusDevice *sbd = SYS_BUS_DEVICE(dev); + + sysbus_init_irq(sbd, &s->irq); + qdev_init_gpio_in(dev, gpio_pwr_set_irq, 8); +} + +static void gpio_pwr_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + + dc->realize = gpio_pwr_realize; +} + +static const TypeInfo gpio_pwr_info = { + .name = TYPE_GPIOPWR, + .parent = TYPE_SYS_BUS_DEVICE, + .instance_size = sizeof(GPIO_PWR_State), + .class_init = gpio_pwr_class_init, +}; + +static void gpio_pwr_register_types(void) +{ + type_register_static(&gpio_pwr_info); +} + +type_init(gpio_pwr_register_types) diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build index 5c0a7d7b95..79568f00ce 100644 --- a/hw/gpio/meson.build +++ b/hw/gpio/meson.build @@ -1,5 +1,6 @@ softmmu_ss.add(when: 'CONFIG_E500', if_true: files('mpc8xxx.c')) softmmu_ss.add(when: 'CONFIG_GPIO_KEY', if_true: files('gpio_key.c')) +softmmu_ss.add(when: 'CONFIG_GPIO_PWR', if_true: files('gpio_pwr.c')) softmmu_ss.add(when: 'CONFIG_MAX7310', if_true: files('max7310.c')) softmmu_ss.add(when: 'CONFIG_PL061', if_true: files('pl061.c')) softmmu_ss.add(when: 'CONFIG_PUV3', if_true: files('puv3_gpio.c')) diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index abf54fab49..77a4523cc7 100644 --- a/include/hw/arm/virt.h +++ b/include/hw/arm/virt.h @@ -81,6 +81,7 @@ enum { VIRT_GPIO, VIRT_SECURE_UART, VIRT_SECURE_MEM, + VIRT_SECURE_GPIO, VIRT_PCDIMM_ACPI, VIRT_ACPI_GED, VIRT_NVDIMM_ACPI, -- 2.17.1

4 years, 4 months

2
1
0 0

Build error with GCC 10.2-2020.11

by Manish Badarkhe

Hi Carlo Alexei created a patch for testing TF-A/TFTF builds with the toolchain GCC 10.2-2020.11 https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/7733 which flagged build errors for plat/amlogic/axg platform, please see below: Build command lines: make CROSS_COMPILE=aarch64-none-elf- PLAT=axg SPD=opteed DEBUG=1 V=1 fiptool all make AML_USE_ATOS=1 CROSS_COMPILE=aarch64-none-elf- PLAT=axg DEBUG=1 V=1 fiptool all plat/amlogic/axg/axg_pm.c: In function 'axg_pwr_domain_off': plat/amlogic/axg/axg_pm.c:124:43: error: array subscript 2 is above array bounds of 'const plat_local_state_t[2]' {aka 'const unsigned char[2]'} [-Werror=array-bounds] 124 | if (target_state->pwr_domain_state[MPIDR_AFFLVL2] == | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ In file included from plat/amlogic/axg/axg_pm.c:14: include/lib/psci/psci.h:270:28: note: while referencing 'pwr_domain_state' 270 | plat_local_state_t pwr_domain_state[PLAT_MAX_PWR_LVL + U(1)]; | ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Makefile:1103: recipe for target '/work/workspace/workspace/tf-worker/trusted_firmware/build/axg/debug/bl31/axg_pm.o' failed make: *** [/work/workspace/workspace/tf-worker/trusted_firmware/build/axg/debug/bl31/axg_pm.o] Error 1 Please help to resolve this issue. Thanks Manish Badarkhe

4 years, 4 months

1
0
0 0

Re: [TF-A] Interrupt about ff-a spec

by Achin Gupta

Hi Feng, On Fri, Dec 18, 2020 at 04:41:37PM +0000, Chen Feng via TF-A wrote: > Hi, > > While reading the Arm Firmware Framework for Armv8-A > https://developer.arm.com/documentation/den0077/latest > > I do not find the API that for a sp to request vIRQ, or do I miss something. > > Is this some private API that is implementing defined FF-A IDs? Is what you have in mind is an ABI that allows SP0 to raise an interrupt in SP1? Could you please provide more information about your use case? cheers, Achin > > > -- > cheers, > feng > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 4 months

3
3
0 0

Re: [TF-A] Does TF-A support to load and run both TEE and SPM_MM?

by Chen Feng

Hi all, I have a similar but different question here :) Why not the tf-a support both smpd and tspd. Since the vendor's teeos that has not support ff-a interface currently. With armv8.4-sel2, is there a choice to disable scr.eel2 with origin vendor's theeos IDs, and enable scr.eel2 with new ff-a services? It seems to need some tlb maintenance, but it seems work. On 2020/11/23 3:27 下午, Achin Gupta via TF-A wrote: > Hi Heyi, > > Happy to discuss the detail but the short answer is no. > > Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE. > > From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it. > > Cheers, > Achin > > On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > > Hi All, > > On some platforms there may be requirements to run both TEE and SPM_MM > instances, such as providing TEE services on server platforms. > > Do TF-A support this scenario? If it doesn't, do it make sense to add > such support? > > Thanks, > > Heyi > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- cheers, feng

4 years, 4 months

2
3
0 0

Interrupt about ff-a spec

by Chen Feng

Hi, While reading the Arm Firmware Framework for Armv8-A https://developer.arm.com/documentation/den0077/latest I do not find the API that for a sp to request vIRQ, or do I miss something. Is this some private API that is implementing defined FF-A IDs? -- cheers, feng

4 years, 5 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 17th December 2020 16:00-1700 GMT: Introduction to the Trusted Services project

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 17th December 2020 16:00 – 17:00 (GMT). As well as being posted to the TF-A mailing list this has been cross posted to OPTEE mailing list. For OPTEE attendees the Zoom call details are included below. Agenda: * An introduction to the Trusted Services project * Presented by Julian Hall * Summary * The Trusted Services project is a new trustedfirmware.org project that provides a home for security related service components that can run in the different isolated processing environments available on Arm Cortex-A. The project attempts to promote reuse and standardization to enable a consistent set of services to be provided by firmware, independent of which isolation technology is used. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. This is the last TF-A Tech Forum session until January 2021. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

4 years, 5 months

1
0
0 0

Re: [TF-A] Question about validity period of X509 certificate

by Andrej Butok

Hello Masato Fukumori, To check a "validity period" of a X 509 certificate, you must be sure that your system date & time is set, correct and not changed. Do you have a reliable way to achieve this? Best regards, Andrej Butok From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of fukumori.masato--- via TF-A Sent: Thursday, December 10, 2020 2:23 PM To: 'tf-a(a)lists.trustedfirmware.org' <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Question about validity period of X509 certificate Hello. I have a question about checking the X 509 certificate with tf-a. My understanding is that tf-a does not check the "validity period" of the X 509 certificate. I 'm not sure why tf-a doesn't check. Does anyone know this background? Best Regards, Masato Fukumori

4 years, 5 months

2
4
0 0

Question about validity period of X509 certificate

by fukumori.masato＠fujitsu.com

Hello. I have a question about checking the X 509 certificate with tf-a. My understanding is that tf-a does not check the "validity period" of the X 509 certificate. I 'm not sure why tf-a doesn't check. Does anyone know this background? Best Regards, Masato Fukumori

4 years, 5 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8192/plat_pm.c: 301 in plat_validate_power_state() ________________________________________________________________________________________________________ *** CID 364146: Control flow issues (DEADCODE) /plat/mediatek/mt8192/plat_pm.c: 301 in plat_validate_power_state() 295 { 296 unsigned int pstate = psci_get_pstate_type(power_state); 297 unsigned int aff_lvl = psci_get_pstate_pwrlvl(power_state); 298 unsigned int cpu = plat_my_core_pos(); 299 300 if (aff_lvl > PLAT_MAX_PWR_LVL) { >>> CID 364146: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return -2;". 301 return PSCI_E_INVALID_PARAMS; 302 } 303 304 if (pstate == PSTATE_TYPE_STANDBY) { 305 req_state->pwr_domain_state[0] = PLAT_MAX_RET_STATE; 306 } else { ** CID 364145: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 42 in ptp3_init() ________________________________________________________________________________________________________ *** CID 364145: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 42 in ptp3_init() 36 * API 37 ************************************************/ 38 void ptp3_init(unsigned int core) 39 { 40 unsigned int _core; 41 >>> CID 364145: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core >= 0U". 42 if (core >= PTP3_CFG1_CPU_START_ID) { 43 if (core < NR_PTP3_CFG1_CPU) { 44 /* update ptp3_cfg1 */ 45 ptp3_write( 46 ptp3_cfg1[core][PTP3_CFG_ADDR], 47 ptp3_cfg1[core][PTP3_CFG_VALUE]); ** CID 364144: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 76 in ptp3_deinit() ________________________________________________________________________________________________________ *** CID 364144: Integer handling issues (NO_EFFECT) /plat/mediatek/mt8192/drivers/ptp3/mtk_ptp3_main.c: 76 in ptp3_deinit() 70 } 71 } 72 } 73 74 void ptp3_deinit(unsigned int core) 75 { >>> CID 364144: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core >= 0U". 76 if (core >= PTP3_CFG1_CPU_START_ID) { 77 if (core < NR_PTP3_CFG1_CPU) { 78 /* update ptp3_cfg1 */ 79 ptp3_write( 80 ptp3_cfg1[core][PTP3_CFG_ADDR], 81 ptp3_cfg1[core][PTP3_CFG_VALUE] & 82 ~PTP3_CFG1_MASK); 83 } 84 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 5 months

1
0
0 0

Cancelled event: TF-A Tech Forum @ Thu 31 Dec 2020 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 31 Dec 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 5 months

1
0
0 0

Cancelled event: TF-A Tech Forum @ Thu 3 Dec 2020 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 3 Dec 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 5 months

1
0
0 0

Re: [TF-A] Does TF-A support to load and run both TEE and SPM_MM?

by Achin Gupta

Hi Heyi, Happy to discuss the detail but the short answer is no. Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE. From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it. Cheers, Achin On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi All, On some platforms there may be requirements to run both TEE and SPM_MM instances, such as providing TEE services on server platforms. Do TF-A support this scenario? If it doesn't, do it make sense to add such support? Thanks, Heyi -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 5 months

3
7
0 0

Re: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

Apologies, I need to cancel this weeks TF-A Tech Forum session on 3rd December due to clashing events for Arm attendees. Next meeting will be 17th December which will be the last session of 2020. 31st December session is also cancelled with the first 2021 session being 14th January 2021. Thanks Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 3 December 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

4 years, 5 months

1
0
0 0

Does TF-A support to load and run both TEE and SPM_MM?

by Heyi Guo

Hi All, On some platforms there may be requirements to run both TEE and SPM_MM instances, such as providing TEE services on server platforms. Do TF-A support this scenario? If it doesn't, do it make sense to add such support? Thanks, Heyi

4 years, 5 months

1
0
0 0

Re: [TF-A] [PATCH] plat/qemu/qemu_sbsa: Include libraries for Cortex-A72

by Jens Wiklander

Hi Tanmay, Please upload the patch at https://review.trustedfirmware.org/, for details see https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.html Thanks, Jens On Thu, Nov 19, 2020 at 7:28 PM Tanmay Jagdale <tanmay.jagdale(a)linaro.org> wrote: > > Include libraries needed to emulate Cortex-A72 in sbsa-ref target of Qemu. > > Signed-off-by: Tanmay Jagdale <tanmay.jagdale(a)linaro.org> > --- > plat/qemu/qemu_sbsa/platform.mk | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/plat/qemu/qemu_sbsa/platform.mk b/plat/qemu/qemu_sbsa/platform.mk > index 1a4a2db02..a8036f622 100644 > --- a/plat/qemu/qemu_sbsa/platform.mk > +++ b/plat/qemu/qemu_sbsa/platform.mk > @@ -43,7 +43,8 @@ BL1_SOURCES += drivers/io/io_semihosting.c \ > > BL1_SOURCES += lib/cpus/aarch64/aem_generic.S \ > lib/cpus/aarch64/cortex_a53.S \ > - lib/cpus/aarch64/cortex_a57.S > + lib/cpus/aarch64/cortex_a57.S \ > + lib/cpus/aarch64/cortex_a72.S > > BL2_SOURCES += drivers/io/io_semihosting.c \ > drivers/io/io_storage.c \ > @@ -72,6 +73,7 @@ QEMU_GIC_SOURCES := ${GICV3_SOURCES} \ > BL31_SOURCES += lib/cpus/aarch64/aem_generic.S \ > lib/cpus/aarch64/cortex_a53.S \ > lib/cpus/aarch64/cortex_a57.S \ > + lib/cpus/aarch64/cortex_a72.S \ > lib/semihosting/semihosting.c \ > lib/semihosting/${ARCH}/semihosting_call.S \ > plat/common/plat_psci_common.c \ > -- > 2.29.2 >

4 years, 5 months

2
1
0 0

Hafnium / TF-A v2.4 first tagged release is available

by Olivier Deprez

Hi All, Following the announcement of the Trusted Firmware-A/Trusted Firmware-A-tests v2.4 release: We are pleased to announce the first tagged release of Hafnium [1] implementing the SPMC according to the FF-A v1.0 specification [2]. As a reminder, Hafnium has been transferred to trustedfirmware.org back in May 2020 to become the reference open source S-EL2 firmware, under an Arm/Google co-maintainership. Contributions are open to partners in trustedfirmware.org The Secure Partition Manager documentation is available at [3] Please also refer to the change log at [4] The companion TF-A test suite permits the validation of FF-A ABIs and NWd/SWd communication by the use of bare-metal S-EL1 secure partitions. Thanks to all who contributed to make it happen. Regards, Olivier. [1] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.4 [2] https://developer.arm.com/documentation/den0077/latest [3] https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit… [4] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Manish Badarkhe via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 November 2020 14:35 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

4 years, 6 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 19th November 2020 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 19th November 2020 16:00 – 17:00 (GMT). Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from BST. A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Trace-based Code Coverage Tooling for Firmware Projects * Presented by Basil Eljuse & Saul Romero * Summary * TF-A has adopted a code coverage system to measure the effectiveness of the various runtime testing performed and this is achieved without doing code instrumentation. This presentation is an overview of that approach which has applicability beyond the TF-A project. * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

4 years, 6 months

1
0
0 0

Trusted Firmware-A & Trusted Firmware-A-tests version 2.4 is now available

by Manish Badarkhe

Hi All, Trusted Firmware-A and Trusted Firmware-A-tests version 2.4 is now available and can be found here: Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.4 Trusted Firmware-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.4 Please refer to the change log of Trusted Firmware-A and Trusted Firmware-A-tests for further information here: Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/v2.4/change-log.html Trusted Firmware-A-tests: https://trustedfirmware-a-tests.readthedocs.io/en/v2.4/change-log.html Thanks Manish Badarkhe

4 years, 6 months

1
0
0 0

atf-a with optee-os for firefly-rk3399

by Piotr Lobacz

Hi All, i've been trying for a couple of days to load current optee together with atf from the github, with no luck. For that i have been using manuals (https://trustedfirmware-a.readthedocs.io/en/latest/plat/rockchip.html , http://opensource.rock-chips.com/wiki_ATF ) for rockchip and what i have succeded is to run very old atf tag 1.3 with optee blob from rockchip which i suspect is also very old. And if i try to use any newer atf >= 1.4 than i suspect that it does not load, because i do not see any LOGS from it, no matter that LOG_LEVEL was set to 50... Can anybody help me solving this issue or point me to some solution? Thanks in advance. BR Piotr Łobacz [https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com> Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND KRS: 0000674406, NIP: 9581679801, REGON: 367090912 www.softgent.com Sąd Rejonowy Gdańsk-Północ w Gdańsku, VII Wydział Gospodarczy Krajowego Rejestru Sądowego KRS 0000674406, Kapitał zakładowy: 25 000,00 zł wpłacony w całości.

4 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A