- TF-A - lists.trustedfirmware.org

Trusted Firmware-A LTS v2.10.27 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.10.27 is now available. This release contains the following patches: fb0ca7ca1 build(npm): adhere to Husky deprecation notice [1] 17a8aec49 fix(cpus): workaround for Cortex-A76AE erratum 1931427 [2] fc5e6eeee fix(cpus): workaround for Cortex-A76AE erratum 1931435 [3] 918cb2542 fix(cpus): workaround for Cortex-A76AE erratum 1969401 [4] 6f78d7d29 fix(cpus): workaround for Cortex-A76AE erratum 2371140 [5] d5424f6d8 fix(build): set ERRATA_SPECULATIVE_AT after platform.mk [6] 659e46683 fix(cpus): workaround for Cortex-A65 erratum 1179935 [7] 909b29568 fix(cpus): workaround for Cortex-A65 erratum 1227419 [8] 42777038e fix(cpus): workaround for Cortex-A65 erratum 1541130 [9] 948f017ea fix(cpus): workaround for Cortex-A725 erratum 2874943 [10] 5ff59225e fix(cpus): workaround for Cortex-A725 erratum 2936490 [11] d2ab008e2 fix(cpus): workaround for Cortex-A725 erratum 3711914 [12] d0d0d0285 fix(cpus): workaround for Cortex-A725 erratum 3456106 [13] [1] https://review.trustedfirmware.org/q/I763a462b2a0da7852696f874df970810a2b01… [2] https://review.trustedfirmware.org/q/I31566838f894372e5627abda8b0bea1505f11… [3] https://review.trustedfirmware.org/q/I1baba8752f5f2e2ab5c873030e1f00cbb8cf1… [4] https://review.trustedfirmware.org/q/I893452450d430833e6c5a8e33a1e37b708218… [5] https://review.trustedfirmware.org/q/Id65846bebde1a0911ba11956202d0d255d3c8… [6] https://review.trustedfirmware.org/q/I221dab39c417531c5a148886d3e29709ba8b5… [7] https://review.trustedfirmware.org/q/Ie59a4897f849269a590d8fa2d25cceab5f2cb… [8] https://review.trustedfirmware.org/q/I42371e7d53fce3a7e085bf0b348f080fa323f… [9] https://review.trustedfirmware.org/q/I72498f60f8449193ed4b5b2a9e7a08530e786… [10] https://review.trustedfirmware.org/q/I686bbde8756d52afee92097ec05b97138b550… [11] https://review.trustedfirmware.org/q/I9833f8831ba3735a94763791a65be11b95c00… [12] https://review.trustedfirmware.org/q/If3b9d3a0f495b3a172d3e6e5ca7afa8c30aeb… [13] https://review.trustedfirmware.org/q/I10d1e8cb4da19ba4101a5617245ff75866707… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.10.27/change-log.html Thanks, TF-A LTS team

2 weeks, 4 days

1
0
0 0

Email to TF-A

by Prasanth Nair

Email to TF-A

2 weeks, 4 days

1
0
0 0

Trusted Firmware-A LTS v2.8.41 Release Announcement

by svc_openci_enginfra＠arm.com

Hello, Trusted Firmware-A LTS version 2.8.41 is now available. This release contains the following patches: 0a85ca29f fix(security): add clrbhb support [1] 7c5bca9b9 fix(cpus): workaround for Cortex-A715 erratum 2409570 [2] 931417cff fix(cpus): workaround for Cortex-A715 erratum 2376701 [3] 368077598 fix(cpus): workaround for Cortex-A715 erratum 3711916 [4] 930fcc0b6 fix(cpus): workaround for Cortex-A76AE erratum 1931427 [5] 34f2ec4d0 fix(cpus): workaround for Cortex-A76AE erratum 1931435 [6] 9ad229ec8 fix(cpus): workaround for Cortex-A76AE erratum 1969401 [7] dccafbf14 fix(cpus): workaround for Cortex-A76AE erratum 2371140 [8] 24191cda2 fix(cpus): workaround for Cortex-A65 erratum 1179935 [9] ec702b29f fix(cpus): workaround for Cortex-A65 erratum 1227419 [10] 1cf89d221 fix(cpus): workaround for Cortex-A65 erratum 1541130 [11] a5b818591 docs(security): add CVE-2024-5660 and CVE-2024-7881 reference links [12] 800a3bda8 fix(security): update Cortex-X4 fix version for CVE-2024-7881 [13] e3eed549b fix(security): update Neoverse-V3/V3AE fix version for CVE-2024-7881 [14] e56910a48 fix(security): update Cortex-X3 fix version for CVE-2024-7881 [15] 76e43568c fix(security): update Neoverse-V2 fix version for CVE-2024-7881 [16] 8776324c8 docs(security): update CVE-2024-7881 affected CPU revisions [17] 990086206 fix(cpus): register ARCH_WORKAROUND_3 for Neoverse V2 [18] ba8c49193 fix(cpus): workaround for Cortex-A710 erratum 3324338 [19] b4cdfa94d fix(cpus): workaround for Cortex-X2 erratum 3324338 [20] d3169c509 fix(cpus): workaround for Cortex-A715 erratum 3456084 [21] bddc18aea fix(cpus): workaround for Cortex-A720 erratum 3456091 [22] [1] https://review.trustedfirmware.org/q/Ie6e56e96378503456a1617d5e5d51bc64c2e0… [2] https://review.trustedfirmware.org/q/Id9429831525b842779d7b7e60f103c93be4ac… [3] https://review.trustedfirmware.org/q/Idcd2a07d269d55534dc5faa59c454d37426f2… [4] https://review.trustedfirmware.org/q/Iad149a2c02a804b3f4f0f2f5b89e866675cb4… [5] https://review.trustedfirmware.org/q/I31566838f894372e5627abda8b0bea1505f11… [6] https://review.trustedfirmware.org/q/I1baba8752f5f2e2ab5c873030e1f00cbb8cf1… [7] https://review.trustedfirmware.org/q/I893452450d430833e6c5a8e33a1e37b708218… [8] https://review.trustedfirmware.org/q/Id65846bebde1a0911ba11956202d0d255d3c8… [9] https://review.trustedfirmware.org/q/Ie59a4897f849269a590d8fa2d25cceab5f2cb… [10] https://review.trustedfirmware.org/q/I42371e7d53fce3a7e085bf0b348f080fa323f… [11] https://review.trustedfirmware.org/q/I72498f60f8449193ed4b5b2a9e7a08530e786… [12] https://review.trustedfirmware.org/q/Ia3c003d5c359f101f230fbd54845f61117456… [13] https://review.trustedfirmware.org/q/Iae84f26fdce96a61fdc942b7595ccf8b9c778… [14] https://review.trustedfirmware.org/q/If3e2989a4b5a5c68dc12e23978b226c73f21b… [15] https://review.trustedfirmware.org/q/Ia1ff75602a0dfa758a223549d92ea87543fa4… [16] https://review.trustedfirmware.org/q/I1ae196fa8ce4579524faba4916f631e7c4db3… [17] https://review.trustedfirmware.org/q/Iad109561a144169fd3805c179a4f8e3bfdd59… [18] https://review.trustedfirmware.org/q/I8c08c26e0b7c268772d75d36d759564a7d67c… [19] https://review.trustedfirmware.org/q/I9325f3715f4fa17bfb7ded9d5c69c59645f65… [20] https://review.trustedfirmware.org/q/Ibbe55a55bd6cf5e159dab92a78ecb55c5a4d7… [21] https://review.trustedfirmware.org/q/Ie3f2b46051539cdebc151c46f80045a7156e0… [22] https://review.trustedfirmware.org/q/Ia22a0d6bb98d1a0edb11d2469beab22c7f7ab… Alternatively, Change Log is available in the documentation section: https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.41/change-log.html Thanks, TF-A LTS team

3 weeks, 1 day

1
0
0 0

ZynqMP regression with NUMA_AWARE_PER_CPU changes with ENABLED_LTO : Linux runtime hang due to EL3 re-entry

by Kummari, Prasad

[AMD Official Use Only - AMD Internal Distribution Only] Hello Maintainers, We are observing a reproducible runtime regression on the ZynqMP (Cortex-A53) platform after enabling LTO (ENABLED_LTO=1) and merging the changes from the topic NUMA_AWARE_PER_CPU into our integration branch (https://github.com/ARM-software/arm-trusted-firmware/commit/7303319b3823e9e…). Summary of the issue 1. Baseline behavior * Platform: ZynqMP (Cortex-A53) * Configuration: ENABLED_LTO=1 * Without NUMA_AWARE_PER_CPU: Linux boots and runs stably * After merging NUMA_AWARE_PER_CPU, Linux boots but hangs during runtime * During the hang, CPUs are observed to unexpectedly re-enter EL3 * Re-entry into EL3 should not occur during normal Linux runtime execution and strongly suggests corruption or mismanagement of PSCI and/or per-CPU state(arm-trusted-firmware/lib/per_cpu/aarch64/per_cpu_asm.S at master * ARM-software/arm-trusted-firmware<https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/per_cp…>) * Reverting the NUMA_AWARE_PER_CPU changes restores stable Linux execution * The issue is reproducible only when NUMA_AWARE_PER_CPU is present * This clearly identifies NUMA_AWARE_PER_CPU as the regression source 2. Suspect with LTO * With NUMA_AWARE_PER_CPU enabled, LTO breaks the per-CPU base calculation * BL31 contains hand-written assembly that relies on linker-script symbols (e.g., per-CPU section boundaries) * Under LTO, symbol placement and retention are no longer guaranteed in the same way, leading to incorrect per-CPU base computation * This results in corrupted per-CPU data and subsequent erroneous PSCI suspend behavior (EL3 re-entry) 3. CPU idle dependency * The following kernel configuration options are enabled: * CONFIG_CPU_IDLE=y * CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y * CONFIG_CPU_IDLE_GOV_MENU=y * CONFIG_DT_IDLE_STATES=y * This further suggests the issue is triggered during CPU idle / suspend-resume paths, where correct per-CPU state handling is critical Based on the above: * This is specific to NUMA_AWARE_PER_CPU combined with LTO * The failure mode points to per-CPU base calculation and PSCI state corruption * Reverting NUMA_AWARE_PER_CPU fully restores stability on ZynqMP We wanted to report this issue upstream and seek guidance on: * Whether NUMA_AWARE_PER_CPU is expected to be LTO-safe on platforms relying on linker-defined per-CPU sections * Or if additional constraints / fixes are required for platforms like ZynqMP We are happy to provide further logs, configuration details, or help to fixes. Regards, Prasad Kummari

3 weeks, 2 days

2
7
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jan 8, 2026 5pm - 6pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Cancelling as no topic this week." TF-A Tech Forum Thursday Jan 8, 2026 ⋅ 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 qwandor(a)google.com praan(a)google.com jeremimiller(a)google.com jagdish.gediya(a)linaro.org 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

3 weeks, 2 days

1
0
0 0

Invitation: TF-A Tech Forum Jan 22nd 10.00am -Part II Scaling Hafnium... @ Thu Jan 22, 2026 11am - 12pm (GMT+1) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

TF-A Tech Forum Jan 22nd 10.00am -Part II Scaling Hafnium for advanced mobile OS architectures Thursday Jan 22, 2026 ⋅ 11am – 12pm 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… Hi, As follow up to the last session on Nov 13th 2025 [1], a new TF-A Tech Forum session with the topic'Scaling Hafnium for advanced mobile OS architectures' will be held on Jan 22nd 2026 10.00am. Regards,Olivier. [1] https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Scaling Hafnium for advanced mobile OS architectures - Presented by Jack Suann PDF Presentation Video Recording (Access Password: *PIs1^BD) Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-A Tech ForumJoin 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 View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NmFoYTlsdXBjYjZj… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NmFoYTlsdXBjYjZj… Your attendance is optional. ~~//~~ 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

3 weeks, 2 days

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. 1 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 1 of 1 defect(s) ** CID 501137: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /common/runtime_svc.c: 261 in handler_sync_exception() _____________________________________________________________________________________________ *** CID 501137: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /common/runtime_svc.c: 261 in handler_sync_exception() 255 /* advance the PC to continue after the instruction */ 256 write_ctx_reg(state, CTX_ELR_EL3, read_ctx_reg(state, CTX_ELR_EL3) + 4); 257 } /* otherwise return to the trapping instruction (repeating it) */ 258 return; 259 /* If FFH Support then try to handle lower EL EA exceptions. */ 260 } else if ((exc_class == EC_IABORT_LOWER_EL || exc_class == EC_DABORT_LOWER_EL) >>> CID 501137: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "state->ctx_regs[0U /* 0U >> 3U */] | (8UL /* 1UL << 3 */)" is always 1/true regardless of the values of its operand. This occurs as the logical second operand of "&&". 261 && (read_ctx_reg(state, CTX_SCR_EL3) | SCR_EA_BIT)) { 262 #if FFH_SUPPORT 263 /* 264 * Check for Uncontainable error type. If so, route to the 265 * platform fatal error handler rather than the generic EA one. 266 */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

3 weeks, 4 days

1
0
0 0

Re: Questions about Chain-of-Trust and RSE Connectivity

by Olivier Deprez

+ TF-A list ________________________________ From: Olivier Deprez Sent: 05 January 2026 15:11 To: Taehoon Kim <gth1919(a)adtek.co.kr> Cc: Raef Coles <Raef.Coles(a)arm.com>; Jackson Cooper-Driver <Jackson.Cooper-Driver(a)arm.com>; Nishant Sharma <Nishant.Sharma(a)arm.com>; Rohit Mathew <Rohit.Mathew(a)arm.com>; Manish Pandey2 <Manish.Pandey2(a)arm.com>; Manish Badarkhe <Manish.Badarkhe(a)arm.com> Subject: Questions about Chain-of-Trust and RSE Connectivity Hi Taehoon Kim, We seem to experience an issue with the mailing list where messages are not properly dispatched. I reproduced your initial email sent Dec 18th 2025 below and Cced relevant folks just in case. Regards, Olivier. ____________________________________________________________ Hello, I'm firmware developer for RD-V3-R1 chipset. I have developed our firmware based on Neoverse Reference Platform RD-INFRA-2025.07.03, but I have also kept an eye on the code to ensure we remain in step with the latest release. While inquiring on the TF-M forum to update the TF-M code, I also developed a query regarding the TF-A section. Re: Several Questions related to RSE Provisioning - TF-M - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.…> This link includes that RSE API codes are removed in the SotA TF-A codes. I check this in the TF-A commit. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/46314 I was already aware that this API was not used outside of test code. However, I would like to know the reason why that code was removed, beyond the simple fact that it was not being used. Is it possible that Chain-of-Trust is established in whole firmware stack from RSE ROM to AP BL33 bootloader, without RSE assist? If possible, what does TF-A rely upon as the basis for trust in establishing the Root of Trust? Our team believed that CoT was established on the premise of the RSE API, and was therefore designing to ensure the trustworthiness of the entire firmware using that code. However, we recognise that to use the latest version of the code, we must abandon that belief and design in a different manner. Before the new version of RD-INFRA is released, we intend to resolve this internally as a team. Should you feel the scope of the question extends beyond what is typically addressed in the forum, please do not hesitate to let us know. Thank you for reading this mail. Best Regard, Taehoon Kim

3 weeks, 4 days

3
2
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. 2 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 1 of 1 defect(s) ** CID 500810: Incorrect expression (SIZEOF_MISMATCH) /contrib/libeventlog/src/event_log.c: 394 in event_log_write_specid_event() _____________________________________________________________________________________________ *** CID 500810: Incorrect expression (SIZEOF_MISMATCH) /contrib/libeventlog/src/event_log.c: 394 in event_log_write_specid_event() 388 } 389 390 /* TCG_EfiSpecIdEvent.VendorInfo */ 391 if (vendor_info_size > 0) { 392 vendor_info_ptr = 393 (tcg_vendor_info_t >>> CID 500810: Incorrect expression (SIZEOF_MISMATCH) >>> Adding "4UL /* sizeof (id_event_algorithm_size_t) */ * algo_count" to pointer "spec_id_ptr->digest_size" of type "id_event_algorithm_size_t *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 4 bytes, of the pointed-to type, "id_event_algorithm_size_t". Most likely, the multiplication by "sizeof (id_event_algorithm_size_t)" in this expression is extraneous and should be eliminated. 394 *)(spec_id_ptr->digest_size + 395 sizeof(id_event_algorithm_size_t) * 396 algo_count); 397 398 vendor_info_ptr->vendor_info_size = vendor_info_size; 399 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/arm-software-arm-trusted-firmware?tab=ov…

1 month, 2 weeks

1
0
0 0

Questions about Chain-of-Trust and RSE Connectivity

by 김태훈

Hello, I'm firmware developer for RD-V3-R1 chipset. I have developed our firmware based on Neoverse Reference Platform RD-INFRA-2025.07.03, but I have also kept an eye on the code to ensure we remain in step with the latest release.  While inquiring on the TF-M forum to update the TF-M code, I also developed a query regarding the TF-A section. Re: Several Questions related to RSE Provisioning - TF-M - lists.trustedfirmware.org This link includes that RSE API codes are removed in the SotA TF-A codes. I check this in the TF-A commit. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/46314 I was already aware that this API was not used outside of test code. However, I would like to know the reason why that code was removed, beyond the simple fact that it was not being used. Is it possible that Chain-of-Trust is established in whole firmware stack from RSE ROM to AP BL33 bootloader, without RSE assist? If possible, what does TF-A rely upon as the basis for trust in establishing the Root of Trust?  Our team believed that CoT was established on the premise of the RSE API, and was therefore designing to ensure the trustworthiness of the entire firmware using that code. However, we recognise that to use the latest version of the code, we must abandon that belief and design in a different manner. Before the new version of RD-INFRA is released, we intend to resolve this internally as a team. Should you feel the scope of the question extends beyond what is typically addressed in the forum, please do not hesitate to let us know. Thank you for reading this mail. Best Regard, Taehoon Kim

1 month, 2 weeks

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A