- TF-A - lists.trustedfirmware.org

Arm trusted firmware reads wrong fip file from flash on hikey960v2

by David Cerdeira

Greetings, i’m having trouble getting arm trusted firmware to work on hikey960v2 I followed all the steps in this guide https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/…, and the steps in https://optee.readthedocs.io/building/devices/hikey960.html The problem seems to be in reading the fip.bin, or rather the problem is writing the fip file as it seems it is not properly flashed. ATF bl2 fails to find the UUID of the BL2_SCP image in the fip.bin output by the build process, the fip file it reads from flash only has the BL31 and BL33 UUIDs. I tried checking older versions of ATF, as I figured it might be a problem in current versions, but the same problems occurred. At this moment I feel the problem is in the flashing step. I tried moving the partitions in the partition tables, as well as the value of the macro HIKEY960_FIP_BASE present in hikey960_def.h to match what I thought would be the writing position of the file in the partition, but without success. If anyone could give me any idea as to what the problem might be, that’d be great Best regards, David Cerdeira

6 years, 9 months

1
0
0 0

Regression on Poplar eMMC

by Shawn Guo

Hi Tien, We recently found a regression on Poplar eMMC in U-Boot, which seems caused by commit 3d0f30bb544a ("drivers: synopsys: Fix synopsys MMC driver"). For some reason, the setup of FIFO threshold breaks eMMC support in U-Boot [1]. Would you please suggest a sensible fix for this regression? Thanks. Shawn [1] https://discuss.96boards.org/t/uboot-mmc-init-problem/8130/3

6 years, 9 months

2
2
0 0

New console interface porting examples

by Ambroise Vincent

Hi, An update on the new console API (https://github.com/ARM-software/tf-issues/issues/692): You will find patches below for the platforms that haven't done the migration to the new interface yet, in order to give them something to test and potentially adapt if it doesn't work as intended. The commits are independent from each other and can be easily cherry-picked. Tegra: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192/ Zynqmp: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1193/ Uniphier: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1194/ Qemu: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1195/ Warp7: a very small patch to look at, removing a soon to be deleted legacy file from the platform makefile: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1191/ As you know, the old interface is going to be removed at the end of June by https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/842/ Regards

6 years, 9 months

2
1
0 0

GitHub integration branch deleted

by John Tsichritzis

Hello everyone, As you already know, Trusted Firmware-A has migrated to trustedfirmware.org. Our GitHub repository is still kept active as a read-only mirror of the project. However, as of today, the integration branch has been deleted from GitHub. As a reminder, you can find the TF-A repository here: https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a as well as all the other projects hosted under trustedfirmware.org: https://review.trustedfirmware.org/admin/repos We are looking forward to your contributions! Thank you! Kind regards, John -- [cid:part3.A7D3BC4B.2D1B928D@arm.com] <https://www.arm.com/> John Tsichritzis | Graduate Software Engineer Email : john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com> 110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom

6 years, 10 months

1
0
0 0

Documentation Changes in Review

by Paul Beesley

Hi, I'd like to make you aware of a set of patches that are currently in review under the "pb/sphinx-doc" topic. These patches do some preparatory work on our documentation so that the reStructured Text (RST) documents can be rendered using a tool called Sphinx (http://www.sphinx-doc.org). This tool will allow us, going forward, to investigate additional output formats and publishing options for the documentation. The aim of these specific patches is to: 1) Prepare the documentation for building with the Sphinx application 2) Improve the general formatting and naming of the documents 3) Organise the documents into a sensible structure 4) Maintain compatibility with existing renderers You can find the first patch in the chain on our Gerrit review system, here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1041 . Follow the "Relation Chain" to see all of the related patches in the series. Please note that documentation for upstream platforms is modified by these patches as part of the reformatting. These changes should all be minor but platform maintainers may wish to give them a quick review, especially this one: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1046 . As always, any feedback on these changes is welcome and there will always be the opportunity to make further changes beyond the scope of these patches. Best Regards, Paul

6 years, 10 months

1
0
0 0

Removal of deprecated console interface

by Ambroise Vincent

Hi, A reminder that the legacy console API is going to be removed. The date is currently set to the end of June. An issue was raised here: https://github.com/ARM-software/tf-issues/issues/692 as an early warning, and listing the affected platforms. The patch can be found here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/842/ Please let us know if you have any issues porting the change to your platform. Regards

6 years, 10 months

1
0
0 0

Re: [TF-A] [LPC] Bootloader miniconf

by Matteo Carlini

Hi Marek, Thanks for raising the topic across the communities. The question is probably how many people from the various projects are going to attend Plumbers this year in Lisbon, so to create some critical mass. The TF.org project is planning a significant presence at the Open Source Firmware Conference happening the week before in California (https://osfc.io/), sponsoring the event and submitting few engineering topics. This is another great opportunity to meet and chat on Boot/Firmware topics as well. Having a boot miniconf the week after in Europe may be a natural extension, but I'm wondering if people would be willing to travel and attend two similar events in a row... Thanks, Matteo [Arm & TrustedFirmware.org] > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > Vasut via TF-A > Sent: 29 April 2019 14:39 > To: Marek Vasut <marek.vasut(a)gmail.com> > Cc: u-boot-custodians(a)lists.denx.de; tf-a(a)lists.trustedfirmware.org; > coreboot(a)coreboot.org > Subject: [TF-A] [LPC] Bootloader miniconf > > Hi, > > I was pondering whether it would make sense to organize a bootloader > miniconf at Linux Plumbers [1]. The Linux kernel is what we often start, the > bootloader projects generally do similar things, hence I think being able to > meet face-to-face and discuss how to make things better/nicer would be > beneficial. > > Feel free to expand the CC list to other interested parties. > > Thoughts ? > > [1] https://www.linuxplumbersconf.org/ > > -- > Best regards, > Marek Vasut > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 10 months

2
1
0 0

[LPC] Bootloader miniconf

by Marek Vasut

Hi, I was pondering whether it would make sense to organize a bootloader miniconf at Linux Plumbers [1]. The Linux kernel is what we often start, the bootloader projects generally do similar things, hence I think being able to meet face-to-face and discuss how to make things better/nicer would be beneficial. Feel free to expand the CC list to other interested parties. Thoughts ? [1] https://www.linuxplumbersconf.org/ -- Best regards, Marek Vasut

6 years, 10 months

1
0
0 0

Mbed TLS: Remove weak heap implementation

by Ambroise Vincent

The shared Mbed TLS heap feature has a default implementation (weak function) that will soon be removed: plat_get_mbedtls_heap(). This is part of the general effort to avoid using weak functions in generic code. As a result, the implementation of this function becomes mandatory when supporting Trusted Board Boot. The corresponding patch can be found here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/841 The fact that the implementation of plat_get_mbedtls_heap() becomes mandatory will break compatibility with platforms not implementing a strong version of the function. Upstream platforms are taken care of in the above patch. Downstream platforms will break, but it is easy to fix. 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.

6 years, 11 months

1
0
0 0

Re: [TF-A] [RFC 0/2] psci: Add core wakeup operation

by Soby Mathew

Hi Abel, Thanks for the RFC. On the face of it, this is a new PSCI command that would need further discussion involving Architecture and Kernel teams. Just to summarize my understanding: Currently any interrupt targeted to a suspended core can wake it up, but it seems that this mechanism is broken on i.MX8MQ and hence you need an explicit command to wake it. This assumes that one CPU is always ON within the system ready to poke the suspended CPU back to life. This assumption is not true always as it is legal for all the CPUs to be in suspend state at the same time. Adding the kernel team for their input. JFYI, We do not intend to review patches via the mailing list and patches should be pushed as mentioned here: https://github.com/ARM-software/arm-trusted-firmware/blob/master/contributi… Currently the project is in github but we expect to migrate to trustedfirmware.org in April. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Abel Vesa > via TF-A > Sent: 27 March 2019 12:16 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] [RFC 0/2] psci: Add core wakeup operation > > This is more like a workaround for platforms like i.MX8MQ that have an issue > related to the wake_request GIC signal integration. > > See E11171 here: > https://www.nxp.com/docs/en/errata/IMX8MDQLQ_0N14W.pdf > > The workaround mentioned in the document has the dissadvantage of waking > up all the sleeping cores instead of just one. > > This patchset adds another psci op for core 'poking' (waking up). > On i.MX8MQ, the plat specific implementation writes the corresponding bits in > GPC to wake up independently each core. > > Abel Vesa (2): > psci: Add cpu wake operation > plat: imx8mq: Trigger SW power up per core > > include/lib/psci/psci.h | 3 +++ > lib/psci/psci_main.c | 17 +++++++++++++++++ > lib/psci/psci_setup.c | 2 ++ > plat/imx/imx8m/imx8mq/gpc.c | 7 +++++++ > plat/imx/imx8m/imx8mq/imx8mq_psci.c | 8 ++++++++ > plat/imx/imx8m/include/gpc.h | 2 ++ > 6 files changed, 39 insertions(+) > > -- > 2.7.4 > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 11 months

2
1
0 0

[RFC 0/2] psci: Add core wakeup operation

by Abel Vesa

This is more like a workaround for platforms like i.MX8MQ that have an issue related to the wake_request GIC signal integration. See E11171 here: https://www.nxp.com/docs/en/errata/IMX8MDQLQ_0N14W.pdf The workaround mentioned in the document has the dissadvantage of waking up all the sleeping cores instead of just one. This patchset adds another psci op for core 'poking' (waking up). On i.MX8MQ, the plat specific implementation writes the corresponding bits in GPC to wake up independently each core. Abel Vesa (2): psci: Add cpu wake operation plat: imx8mq: Trigger SW power up per core include/lib/psci/psci.h | 3 +++ lib/psci/psci_main.c | 17 +++++++++++++++++ lib/psci/psci_setup.c | 2 ++ plat/imx/imx8m/imx8mq/gpc.c | 7 +++++++ plat/imx/imx8m/imx8mq/imx8mq_psci.c | 8 ++++++++ plat/imx/imx8m/include/gpc.h | 2 ++ 6 files changed, 39 insertions(+) -- 2.7.4

6 years, 11 months

1
2
0 0

Re: [Tf-a] Test email

by Joanna Farley

Test reply. On 06/02/2019, 12:55, "TF-A on behalf of John Tsichritzis via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Dear all, This is a test email. Please ignore it and sorry for the inconvenience. Kind regards, John -- [cid:part1.F2AC7E65.FED3DCD0@arm.com] <https://www.arm.com/> John Tsichritzis | Graduate Software Engineer Email : john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com> 110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

7 years, 1 month

1
0
0 0

Test email

by John Tsichritzis

Dear all, This is a test email. Please ignore it and sorry for the inconvenience. Kind regards, John -- [cid:part1.F2AC7E65.FED3DCD0@arm.com] <https://www.arm.com/> John Tsichritzis | Graduate Software Engineer Email : john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com> 110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom

7 years, 1 month

1
1
0 0

Re: [Tf-a] New build system based on Kconfig/Kbuild

by Soby Mathew

> Has CMAKE been considered ? CMAKE should work equally well on > windows(visual studio and Cygwin) and linux. You can create a new build > system around CMAKE while keeping the current Makefile system alive, and > deprecate it later, once the CMAKE based build system is stable. > > -Raghu Thanks for the suggestion. Does CMAKE support configuration system as well ? Another factor to consider is the familiarity of the build system with the community, and we think Kbuild would rank high on that. Best Regards Soby Mathew 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.

7 years, 3 months

2
2
0 0

Re: [Tf-a] New build system based on Kconfig/Kbuild

by Raghupathy Krishnamurthy

Has CMAKE been considered ? CMAKE should work equally well on windows(visual studio and Cygwin) and linux. You can create a new build system around CMAKE while keeping the current Makefile system alive, and deprecate it later, once the CMAKE based build system is stable. -Raghu On Dec 13, 2018, at 04:00 AM, tf-a-request(a)lists.trustedfirmware.org wrote: Send TF-A mailing list submissions to tf-a(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.trustedfirmware.org/mailman/listinfo/tf-a or, via email, send a message with subject or body 'help' to tf-a-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-a-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-A digest..." Today's Topics: 1. New build system based on Kconfig/Kbuild (Antonio Nino Diaz) 2. Re: New build system based on Kconfig/Kbuild (Antonio Nino Diaz) ---------------------------------------------------------------------- Message: 1 Date: Wed, 12 Dec 2018 15:50:15 +0000 From: Antonio Nino Diaz <Antonio.NinoDiaz(a)arm.com> To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [Tf-a] New build system based on Kconfig/Kbuild Message-ID: <DB6PR0801MB1943C8DAE7D0574D1C6E15BD89A70(a)DB6PR0801MB1943.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" Hello, One of the biggest issues that the current codebase of TF-A has is the build system. It is unfit for the amount of options and dependencies of said options, and adding new features is now an effort of trying to add the new feature while not breaking the rest of the code. There is another problem. When the firmware is compiled with, say, OPTION=1, if it is recompiled with OPTION=0 without cleaning first, nothing will be rebuilt. We have had several discussions about this internally and we have decided to migrate to Kbuild/Kconfig, the build system used by the Linux kernel. There are already some projects using it, like U-Boot or Zephyr RTOS. We are starting the work related to this migration, and our intention is to migrate upstream platforms to this new build system. However, this change means that: - All non-upstream platforms will break until they update their makefiles. - Compilation under Windows won't be possible anymore without Cygwin or MinGW. We're open to comments. Regards, Antonio 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. ------------------------------ Message: 2 Date: Wed, 12 Dec 2018 15:54:30 +0000 From: Antonio Nino Diaz <Antonio.NinoDiaz(a)arm.com> To: Antonio Nino Diaz <Antonio.NinoDiaz(a)arm.com>, "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [Tf-a] New build system based on Kconfig/Kbuild Message-ID: <DB6PR0801MB1943F0BC699C1B37A8787C2889A70(a)DB6PR0801MB1943.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Please, ignore the confidentiality notice. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Nino Diaz via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 12 December 2018 15:50:24 To: tf-a(a)lists.trustedfirmware.org Subject: [Tf-a] New build system based on Kconfig/Kbuild Hello, One of the biggest issues that the current codebase of TF-A has is the build system. It is unfit for the amount of options and dependencies of said options, and adding new features is now an effort of trying to add the new feature while not breaking the rest of the code. There is another problem. When the firmware is compiled with, say, OPTION=1, if it is recompiled with OPTION=0 without cleaning first, nothing will be rebuilt. We have had several discussions about this internally and we have decided to migrate to Kbuild/Kconfig, the build system used by the Linux kernel. There are already some projects using it, like U-Boot or Zephyr RTOS. We are starting the work related to this migration, and our intention is to migrate upstream platforms to this new build system. However, this change means that: - All non-upstream platforms will break until they update their makefiles. - Compilation under Windows won't be possible anymore without Cygwin or MinGW. We're open to comments. Regards, Antonio 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-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a ------------------------------ Subject: Digest Footer TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a ------------------------------ End of TF-A Digest, Vol 1, Issue 1 **********************************

7 years, 3 months

1
0
0 0

Re: [Tf-a] New build system based on Kconfig/Kbuild

by Antonio Nino Diaz

Please, ignore the confidentiality notice. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Nino Diaz via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 12 December 2018 15:50:24 To: tf-a(a)lists.trustedfirmware.org Subject: [Tf-a] New build system based on Kconfig/Kbuild Hello, One of the biggest issues that the current codebase of TF-A has is the build system. It is unfit for the amount of options and dependencies of said options, and adding new features is now an effort of trying to add the new feature while not breaking the rest of the code. There is another problem. When the firmware is compiled with, say, OPTION=1, if it is recompiled with OPTION=0 without cleaning first, nothing will be rebuilt. We have had several discussions about this internally and we have decided to migrate to Kbuild/Kconfig, the build system used by the Linux kernel. There are already some projects using it, like U-Boot or Zephyr RTOS. We are starting the work related to this migration, and our intention is to migrate upstream platforms to this new build system. However, this change means that: - All non-upstream platforms will break until they update their makefiles. - Compilation under Windows won't be possible anymore without Cygwin or MinGW. We're open to comments. Regards, Antonio 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-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

7 years, 3 months

1
0
0 0

New build system based on Kconfig/Kbuild

by Antonio Nino Diaz

Hello, One of the biggest issues that the current codebase of TF-A has is the build system. It is unfit for the amount of options and dependencies of said options, and adding new features is now an effort of trying to add the new feature while not breaking the rest of the code. There is another problem. When the firmware is compiled with, say, OPTION=1, if it is recompiled with OPTION=0 without cleaning first, nothing will be rebuilt. We have had several discussions about this internally and we have decided to migrate to Kbuild/Kconfig, the build system used by the Linux kernel. There are already some projects using it, like U-Boot or Zephyr RTOS. We are starting the work related to this migration, and our intention is to migrate upstream platforms to this new build system. However, this change means that: - All non-upstream platforms will break until they update their makefiles. - Compilation under Windows won't be possible anymore without Cygwin or MinGW. We're open to comments. Regards, Antonio 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.

7 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A