- TF-A - lists.trustedfirmware.org

TF-A Tech Forum Agenda @ Thr 28th January 2021 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 28th January 2021 16:00 – 17:00 (GMT). Agenda: * TF-A: Automotive Enhance (AE) Architecture Support Requirements Discussion * Presented by Manish Pandy and Manish Badarkhe * A discussion on the needs for the Automotive Enhance (AE) space and how TF-A can support that with CPU and GIC capabilities. The goal is to follow-up the recent email to the TF-A mailing list and try and understand project needs in this space by talking to the project community. 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: 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 on the TF-A mailing list. 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, 9 months

1
0
0 0

Re: [TF-A] Gather GIC changes required for safety critical machines

by Varun Wadekar

<Cc alias> I guess, something went wrong when I clicked "Reply all" the first time. Manish, can you also talk about the tasks that Arm is willing to work on? Then we can ask for volunteers for the remaining ones. I'm sure, NVIDIA will contribute as this topic is close to our heart. -Varun From: Manish Pandey2 <Manish.Pandey2(a)arm.com> Sent: Monday, January 25, 2021 8:05 AM To: Varun Wadekar <vwadekar(a)nvidia.com> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com>; Robin Randhawa <Robin.Randhawa(a)ARM.com>; Ed Doxat <Ed.Doxat(a)arm.com>; Joanna Farley <joannafarley(a)icloud.com>; Manish Badarkhe <Manish.Badarkhe(a)arm.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com>; Doug Richmond <Doug.Richmond(a)arm.com> Subject: Re: Gather GIC changes required for safety critical machines External email: Use caution opening links or attachments ++ Other Arm folks Just realized that Varun has reduced the recipients(guess that was intentional) ________________________________ From: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Sent: 25 January 2021 10:15 To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: Re: Gather GIC changes required for safety critical machines Hi Varun, We are trying to do both, based on interest from community we will prioritize these tasks. The reason why we can't do all the asks (mentioned in the list) ourselves is, currently we do not have "use cases/platforms" to test all the features, so we would rely on wider community to understand the requirements and work together to develop/test those features. Thanks Manish ________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: 22 January 2021 17:46 To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: RE: Gather GIC changes required for safety critical machines HI Manish, Thanks for starting this discussion. The list captures all the functionalities that are useful and interesting to us. Trying to understand the ask - are you trying to get feedback to allow you to prioritize the feature list? Or are you asking for the community to rate importance of these requirements? I am afraid, if there isn't enough interest the list might be trimmed which would be an absolute shame. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Manish Pandey2 via TF-A Sent: Friday, January 22, 2021 8:02 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>> Subject: [TF-A] Gather GIC changes required for safety critical machines External email: Use caution opening links or attachments Hi, GIC600-AE is variant of GIC for safety critical machines, though its TRM is publicly available from quite some time but currently we do not have support in TF-A. Purpose of this email is to kick start discussions around various possible GIC requirements as far as safety critical machines are concerned. We have created following list of requirements based on inputs we got so far, changes are either adding new AE features or enhancements to existing drivers. GIC-600AE feature requirement: - Inject and detect RAS errors using Fault management unit(FMU) - Validating feature parity with GIC600 - Running GIC IP in Dual core Lock-step(DCLS) mode. GIC/RAS driver enhancements: - Read trace and PMU records - Keep RAS error records alive across a reset - Disable GICR frames of fused-off cores - Support for message signalled interrupts - Saving/Restoring additional GIC registers during PM events Feel free to add any additional requirements. If there is enough community interest during the next Tech-forum meeting(28th Jan) we would like to go through these requirements in more detail. Thanks Manish IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 9 months

1
0
0 0

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

by Maxim Uvarov

v9: - cosmetic changes (move if from patch2 to patch3, rename function name and define). v8: - use gpio 0 and 1, align dtb with kernel gpio-restart, gpio-poweroff, change define names, trigger on upper front. (Peter Maydell). v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch 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/886965bddb0624bdf851… Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 111 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 ++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 167 insertions(+), 21 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 9 months

2
4
0 0

Gather GIC changes required for safety critical machines

by Manish Pandey2

Hi, GIC600-AE is variant of GIC for safety critical machines, though its TRM is publicly available from quite some time but currently we do not have support in TF-A. Purpose of this email is to kick start discussions around various possible GIC requirements as far as safety critical machines are concerned. We have created following list of requirements based on inputs we got so far, changes are either adding new AE features or enhancements to existing drivers. GIC-600AE feature requirement: - Inject and detect RAS errors using Fault management unit(FMU) - Validating feature parity with GIC600 - Running GIC IP in Dual core Lock-step(DCLS) mode. GIC/RAS driver enhancements: - Read trace and PMU records - Keep RAS error records alive across a reset - Disable GICR frames of fused-off cores - Support for message signalled interrupts - Saving/Restoring additional GIC registers during PM events Feel free to add any additional requirements. If there is enough community interest during the next Tech-forum meeting(28th Jan) we would like to go through these requirements in more detail. Thanks Manish

4 years, 9 months

1
0
0 0

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

by Maxim Uvarov

v8: - use gpio 0 and 1, align dtb with kernel gpio-restart, gpio-poweroff, change define names, trigger on upper front. (Peter Maydell). v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch 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/886965bddb0624bdf851… Maxim Uvarov (3): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 111 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 ++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 167 insertions(+), 21 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 9 months

3
9
0 0

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

by Maxim Uvarov

v7: - same as v6, but resplit patches: patch 2 no function changes and refactor gpio setup for virt platfrom and patch 3 adds secure gpio. v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch 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/7556d07e87f755c602cd… 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: refactor gpios creation arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 117 ++++++++++++++++++++++++++++++++++-------- hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 2 + 6 files changed, 174 insertions(+), 20 deletions(-) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 9 months

2
8
0 0

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

by Maxim Uvarov

v6: - 64k align gpio memory region (Andrew Jones) - adjusted memory region to map this address in the corresponding atf patch 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/7556d07e87f755c602cd… 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, 9 months

2
4
0 0

[PATCHv4 0/2] arm-virt: add secure pl061 for reset/power down

by Maxim Uvarov

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 (2): hw: gpio: implement gpio-pwr driver for qemu reset/poweroff arm-virt: add secure pl061 for reset/power down hw/arm/Kconfig | 1 + hw/arm/virt.c | 40 +++++++++++++++++++++++++ hw/gpio/Kconfig | 3 ++ hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++++++++++++++++++++ hw/gpio/meson.build | 1 + include/hw/arm/virt.h | 3 ++ 6 files changed, 118 insertions(+) create mode 100644 hw/gpio/gpio_pwr.c -- 2.17.1

4 years, 9 months

4
14
0 0

Cancelled event with note: TF-A Tech Forum @ Thu 14 Jan 2021 16:00 - 17:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "Cancelled - see the mail from Joanna for more details" 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 14 Jan 2021 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, 9 months

1
0
0 0

CANCELLED: TF-A Tech Forum Agenda @ Thr 14th January 2021 16:00-1700 GMT

by Joanna Farley

Apologies for the late notice I am cancelling this weeks TF-A Tech forum tomorrow as the subject I had hoped to get presented is not ready and I don’t have any alternative for this slot. I will look to have something for the next session on 28th January. Apologies for the late notice. Cancellations of the calendar invite will come from trustedformware.org as I don’t own the invite so it may not appear in your calendars until that is sent out. Thanks Joanna

4 years, 9 months

1
0
0 0

[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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A