FYI
From: Saheer Babu via Tf-openci <tf-openci(a)lists.trustedfirmware.org>
Date: Wednesday, 10 September 2025 at 15:17
To: tf-openci(a)lists.trustedfirmware.org <tf-openci(a)lists.trustedfirmware.org>
Subject: [Tf-openci] CI infrastructure scheduled maintenance: 12th Sep 2025
Hi all,
We will be performing upgrade of the clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Friday, 12th Sep 2025 at 16:00 GMT+1.
During this maintenance window, both services will be unavailable for approximately 4 hours.
A follow-up email will be sent once the services are fully restored.
Best regards,
Saheer
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.
--
Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org
Hello!
We’d like to add support in TF-A for the PHYTEC phyCORE AM62L. On this
board we need BL1 to read the on-board EEPROM via I2C to set the correct
DRAM timings.
Right now we have it working by editing the TI AM62L files on TI's TF-A
fork and adding the EEPROM and I2C drivers.
Our questions are:
- Should we create a separate board for phyCORE AM62L, or would it make
more sense to include this as an option in the TI AM62L support?
- How much abstraction should we implement for EEPROM and I2C drivers?
Thanks for any advice!
Best regards,
Florijan Plohl
This event has been canceled with a note:
"Hi Cancelling as no topic proposed for this week. Regards, Olivier. "
TF-A Tech Forum
Thursday Sep 4, 2025 ⋅ 5pm – 6pm
Central European Time - Paris
Location
https://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34…https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9355786…
Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-A
Tech ForumTime: May 15, 2025 02:00 PM London Every 2 weeks on Thu,
78 occurrence(s)Please download and import the following iCalendar (.ics)
files to your calendar
system.Weekly: https://linaro-org.zoom.us/meeting/tJcocu6gqDgjEtOkyBhSQauR1sUyFwIcNKLa/ics…
Zoom
Meetinghttps://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34.1Meeting
ID: 935 5786 3987Passcode: 939141---One tap
mobile+12532158782,,93557863987# US (Tacoma)+13017158592,,93557863987# US
(Washington DC)---Dial by your location• +1 253 215 8782 US (Tacoma)• +1
301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1
312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623
US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558
8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128
US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US•
833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US
Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853
5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 935 5786 3987Find
your local number: https://linaro-org.zoom.us/u/adoz9mILli
Guests
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi,
I’m looking for details on the Raspberry Pi 5 (RPi5) platform port in TF-A and to identify a potential platform owner/maintainer.
I can see an RPi5 port attributed to @mariobalanica02@gmail.com<mailto:mariobalanica02@gmail.com>, but [1] doesn’t list a platform owner for this target. I also haven’t found TF-A documentation describing the software stack or the current level of testing for RPi5.
Could someone please point me to: The current platform owner/maintainer, design/bring-up notes around SW stack or testing?
[1] : https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a.git…
Thanks
Manish
Have you ever succeeded in performing a Stage-1 MMU translation using
LPAE (Long Physical Address Extension) on the FVP_Base_RevC-2xAEMvA
platform model running in AArch32 Hyp mode (CONFIG64=0) into any other
Memory but Strongly-Ordered?
My environment is
- FVP_Base_RevC-2xAEMvA booting SW stack from bullet point below
- SW stack from Yocto, 'meta-arm'. I use 'fvp-base-arm32' that builds
bl1, bl2, bl32, bl33, Linux kernel and rootfs.
The only component that works there at PL2 HYP mode is u-boot (bl33).
Whichever attributes I assign there Normal Memory with Inner or Outer
Cacheability, Write-Through, or Write-Back, or Non-cacheable I always
end up with Strongly-Ordered.
To me it looks like it doesn't read the MAIR correctly and/or ignores
the Cachability in HCTR.
I inspected the MMU code thoroughly there, compared with the other
codes for MMU, from trusted-firmware-a, xen, and Linux kernel and it
seems u-boot does it correct. U-boot sets there identity-mapping for
all 4GB with 0GB through 2GB Strongly-Ordered, 3G - 4G Normal Memory,
Cachable Write-Back Write-Allocate, Non-Shareable and the last 1GB
also Strongly-Ordered. Here is a brief execution steps it goes
through:
#1 Sets up the 2M-block at the 2nd level table with attributes.
- sample block descriptor for translating from 0x8000_0000 virt to
phys: 0x8000044d
- bits[1:0] = 0b01 -> valid descriptor, descriptor type: block
- bits[4:2] = 0b011 -> AttrIndx[2:0] points to MAIR0[3] . MAIR0[3] is 0xff
- bits[5] = 0b0 - Non-secure
- bits[7:6] = 0b01 - Access Permission: Read/write
- bits[9:8] = 0b00 -> Shareability: non-shareable
#2 Sets up 1st level table descriptor pointing to the descriptor shown
above. It sets bits[1:0] to 0b11 meaning it is a table descriptor and
valid.
#3 Set control registers as follows
HTCR is: 0x80000500 so
- bits[9:8] = 0b01 -> Inner Cacheability to Normal memory, Outer
Write-Back Write-Allocate Cacheable
- bits[11:10] = 0b01 -> Outer Cacheability to Normal memory, Outer
Write-Back Write-Allocate Cacheable
- bits[13:12] = 0b00 -> Non-shareable
HTTBR is: 0x00000000feff4000 -> points to 1st lavel table set in #2
HMAIR0 is: 0xffeeaa00 -> as shown above AttrIndx[2:0] points to MAIR0
and the four nibble being 0xff. 0xff is Normal memory, Inner
Write-Back Cacheablea, Non-transientb
HMAIR1 is: 0x00000000 - I set it to zero there as not used.
#4 Finally it sets the M and C bits in HSCTLR registers
Inspecting the page tables with amrds the region 3GB through 4GB that
should be Normal and Cachable is Strongly-Ordered
- 0x80000000 | L2 Block | NP:0x0000000080000000 | XN=0, PXN=0,
Contiguous=0, nG=0, AF=1, SH=0x0, AP=0x1, AttrIndx=0x3
- H:0x80000000-0xFEFFFFFF | NP:0x80000000-0xFEFFFFFF |
Strongly-ordered | NA | False | True | True
Least not last are the parameters I pass to the model:
FVP_Base_RevC-2xAEMvA --parameter bp.ve_sysregs.exit_on_shutdown=1
--parameter bp.virtio_net.enabled=1 --parameter
bp.virtio_net.hostbridge.userNetworking=1 --parameter
bp.virtio_net.hostbridge.userNetPorts=8022=22 --parameter
cache_state_modelled=0 --parameter
bp.secureflashloader.fname=/home/ubuntu/yocto/poky/arm32-aem-build/tmp/deploy/images/fvp-base-arm32/bl1-fvp.bin
--parameter bp.flashloader0.fname=/home/ubuntu/yocto/poky/arm32-aem-build/tmp/deploy/images/fvp-base-arm32/fip-fvp.bin
--parameter bp.virtioblockdevice.image_path=/home/ubuntu/yocto/poky/arm32-aem-build/tmp/deploy/images/fvp-base-arm32/core-image-minimal-fvp-base-arm32-20250630100348.rootfs.wic
--parameter cluster0.has_arm_v8-4=1 --parameter
cluster1.has_arm_v8-4=1 --parameter cluster0.cpu0.CONFIG64=0
--parameter cluster0.cpu1.CONFIG64=0 --parameter
cluster0.cpu2.CONFIG64=0 --parameter cluster0.cpu3.CONFIG64=0
--parameter cluster1.cpu0.CONFIG64=0 --parameter
cluster1.cpu1.CONFIG64=0 --parameter cluster1.cpu2.CONFIG64=0
--parameter cluster1.cpu3.CONFIG64=0 --data
cluster0.cpu0=/home/ubuntu/yocto/poky/arm32-aem-build/tmp/deploy/images/fvp-base-arm32/zImage@0x80080000
--data cluster0.cpu0=/home/ubuntu/yocto/poky/arm32-aem-build/tmp/deploy/images/fvp-base-arm32/fvp-base-revc.dtb@0x8fc00000
--parameter 'bp.terminal_0.terminal_command=tmux new-window -n
"%title" "telnet localhost %port"' --parameter
bp.terminal_1.start_telnet=0 --parameter bp.terminal_2.start_telnet=0
--parameter bp.terminal_3.start_telnet=0 --iris-server --iris-port
7102 --iris-allow-remote
And an interrupted (not full for longevity) console log:
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.8(debug):dd37aa5be-dirty
NOTICE: BL1: Built : 20:04:50, Aug 4 2025
NOTICE: BL1: Booting BL2
NOTICE: BL2: v2.8(debug):dd37aa5be-dirty
NOTICE: BL2: Built : 20:04:50, Aug 4 2025
NOTICE: BL1: Booting BL32
WARNING: FCONF: Invalid config id 26
INFO: SP_MIN FCONF: HW_CONFIG address = 0x7f00000
INFO: FCONF: Reading HW_CONFIG firmware configuration file from: 0x7f00000
INFO: FCONF: Reading firmware configuration information for: cpu_timer
INFO: FCONF: Reading firmware configuration information for: uart_config
INFO: FCONF: Reading firmware configuration information for: topology
INFO: FCONF: Reading firmware configuration information for: gicv3_config
NOTICE: SP_MIN: v2.8(debug):dd37aa5be-dirty
NOTICE: SP_MIN: Built : 20:04:50, Aug 4 2025
U-Boot 2022.04 (Aug 06 2025 - 16:41:21 +0000) vexpress_aemv8a fvp aarch32
DRAM: 2 GiB
WARNING: Caches not enabled
Core: 2 devices, 2 uclasses
Flash: 64 MiB
MMC:
Loading Environment from nowhere... OK
In: serial_pl01x
Out: serial_pl01x
Err: serial_pl01x
Net: SMC91111-0
Error: SMC91111-0 address not set.
Hit any key to stop autoboot: 0
fvp32# dcache on
fvp32# run bootcmd
OTE: Dereference aliases by omitting the leading '/', e.g. fdt print ethernet0.
Kernel image @ 0x80080000 [ 0x000000 - 0x687970 ]
## Flattened Device Tree blob at 8fc00000
Booting using the fdt blob at 0x8fc00000
Loading Device Tree to feb8b000, end feb90fff ... OK
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 6.1.57-yocto-standard (oe-user@oe-host)
(arm-poky-linux-gnueabi-gcc (GCC) 12.3.0, GNU ld (GNU Binutils)
2.40.0.20230703) #1 SMP PREEMPT Wed Oct 11 23:03:27 UTC 2023
CPU: ARMv7 Processor [410fd0f0] revision 0 (ARMv7), cr=10c5387d
CPU: div instructions available: patching division code
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
OF: fdt: Machine model: FVP Base RevC
earlycon: pl11 at MMIO 0x1c090000 (options '')
amba 1c1f0000.clcd: deferred probe pending
Poky (Yocto Project Reference Distro) 4.2.4 fvp-base-arm32 /dev/ttyAMA0
fvp-base-arm32 login: root
root@fvp-base-arm32:~# random: crng init done
random: 1 urandom warning(s) missed due to ratelimiting
root@fvp-base-arm32:~#
Is there a chance FVP_Base_RevC-2xAEMvA doesn't support the 1-stage
MMU translation for anything else but Strongly-Ordered?
Thanks,
Marek
Hi,
Relaying an important announcement about the new Rusted Firmware-A project hosted on trustedfirmware.org:
Today, the Trusted Firmware organization proudly unveils Rusted Firmware-A (RF-A) v0.1 \u2014 a ground breaking open-source prototype that reimagines Trusted Firmware-A (TF-A) through the adoption of the Rust programming language.
Developed in close collaboration between Arm and Google, both Diamond members of the Trusted Firmware community, RF-A has been architected from the ground up for the latest Arm® A-class processors. With a security-first approach, RF-A delivers strong memory safety, enhanced reliability, and modern modularity.
Unlike incremental updates, Rusted Firmware-A is a complete redesign \u2014 free from legacy constraints, built to leverage modern hardware, and designed to provide a robust, maintainable, and future-ready firmware foundation. This milestone reflects years of industry learnings, community insights, and deep collaboration between leading software and silicon providers.
Press release - https://www.trustedfirmware.org/news/rf-a-press-release
Technical blog - https://www.trustedfirmware.org/blog/rf-a-blog
Linkedin post - https://www.linkedin.com/posts/trustedfirmware-org_rusted-firmware-a-rf-a-a…
Regards,
Olivier on behalf of Arm RF-A team.