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
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
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
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…
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
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