Hi Lionel,
On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283
I'm extending the discussion to the TF-A ML, to get people's opinion.
The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long.
There are indeed good reasons for that as flash storage density grows over the years.
Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers.
So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point).
An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib
Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches).
What do ML people think?
Regards,
Olivier.
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 18 October 2019 17:26
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] [RFC] BL2 MTD frameworks
Hello Maintainers,
I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283).
This patch series will add following frameworks:
- a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data.
- a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers.
- a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform.
- a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation.
This patch series also includes:
- a new io_mtd interface to manage a generic access to all these frameworks.
- a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management.
- a complete integration is available based on STM32MP1 platform.
Tests have been performed with the following devices:
SLC NAND:
- Micron MT29F8G08ABACAH4 (ONFI)
- Micron MT29F8G16ABACAH4 (ONFI)
- Toshiba TH58NVG3S0HTAI0 (Non ONFI)
- Toshiba TC58BVG1S3HTAI0 (On die ECC)
SPI NOR:
- Macronix MX25L51245G
- Cypress/Spansion S25FL512
- Micron n25q512ax3
SPI-NAND:
- Micron MT29F2G01ABAGD
Waiting for your comments.
Best regards, Lionel
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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.
Hi Feng,
user-guide.rst references GCC 9.1 and later versions. The code was also tested with GCC 10.0.0.
Regards.
Alexei
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chen Feng via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 24 October 2019 14:32
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] compile toolchain
hi expects，
from the atf2.2 release notes,I can see the tf-a already supported pac bti and mte feature. I want to enable and test it on fvp platform.
I want to know which tool chain to use for compiling code for theses.
Cheers
Feng
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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.
hi expects，
from the atf2.2 release notes,I can see the tf-a already supported pac bti and mte feature. I want to enable and test it on fvp platform.
I want to know which tool chain to use for compiling code for theses.
Cheers
Feng
Hi all,
Trusted Firmware version 2.2 is now available and can be found here:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.2
Please refer to the readme and change log for further information.
Thanks & best regards,
[cid:image001.jpg@01D588EA.577B7090]
Bipin Ravi | Principal Design Engineer
Bipin.Ravi(a)arm.com<mailto:Joshua.Sunil@arm.com> | Skype: Bipin.Ravi.ARM
Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794
5707 Southwest Parkway, Suite 100, Austin, TX 78735
Hello Maintainers,
I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283).
This patch series will add following frameworks:
- a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data.
- a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers.
- a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform.
- a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation.
This patch series also includes:
- a new io_mtd interface to manage a generic access to all these frameworks.
- a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management.
- a complete integration is available based on STM32MP1 platform.
Tests have been performed with the following devices:
SLC NAND:
- Micron MT29F8G08ABACAH4 (ONFI)
- Micron MT29F8G16ABACAH4 (ONFI)
- Toshiba TH58NVG3S0HTAI0 (Non ONFI)
- Toshiba TC58BVG1S3HTAI0 (On die ECC)
SPI NOR:
- Macronix MX25L51245G
- Cypress/Spansion S25FL512
- Micron n25q512ax3
SPI-NAND:
- Micron MT29F2G01ABAGD
Waiting for your comments.
Best regards, Lionel
Hi Hugh,
Ccing the Rockchip maintainers from https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/maint… as neither appear to be subscribed to this mailing list.
Joanna
On 08/10/2019, 21:45, "TF-A on behalf of Hugh Cole-Baker via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Hi folks,
I've been using TF-A with mainline U-Boot recently as firmware & boot
loader for a RK3399 Rockpro64 board. I'm compiling TF-A and U-boot based
on this guide [1], using gcc 8.3.0 from Debian.
TF-A v2.1 works fine for this, but I recently tried to switch to TF-A
latest master and found U-Boot gets stuck with this version.
The symptoms are: U-Boot TPL and SPL print starting messages like this:
U-Boot TPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50)
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50 +0000)
Trying to boot from MMC2
...and then there is no more output when normally U-Boot proper would
start, and go on to load the Linux kernel, etc.
Starting from v2.1, with git bisect I found the first 'bad' commit is:
0aad563c7480 rockchip: Update BL31_BASE to 0x40000
and that commit does change some RK3399-related files so seems likely.
I'm not sure how to debug further, any ideas on why boot is hanging
after that change or how to get more debugging information?
Best regards,
Hugh Cole-Baker
[1] https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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.
Hi Varun,
TF-A v1.4 is rather old codebase, can you provide the exact patchset you cherry-picked on top of it?
e.g. you need the Hercules CPU support patch (a4668c36f1fca75b), but possibly also all which is related to HW_ASSISTED_COHERENCY option?
Also, can you pls provide your build cmd line?
Thanks & Regards,
Olivier.
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 11 October 2019 11:21
To: Varun Wadekar <vwadekar(a)nvidia.com>; Joanna Farley <Joanna.Farley(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com>
Cc: Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org>; nd <nd(a)arm.com>
Subject: Re: [TF-A] Hercules-AE I$ problems
On 10/10/2019 20:46, Varun Wadekar wrote:
> Hello,
>
> First of all, thanks a lot for posting the Hercules-AE patches.
>
> We picked them up and used them internally. Unfortunately, the CPU sees
> garbage in it's I$ when we enable the I cache for the processor. If we
> keep I$ disabled, TF-A boots properly. We are using TF-A v1.4 for
> verification.
>
> We booted Linux kernel v4.14 on the processor and don't see this problem
> there. So, we suspect something going wrong inside TF-A. Have you seen
> this problem internally? Any hints or clues to solve it would be helpful.
>
> Thanks.
Hi Varun,
As indicated in the commit message of the patch, we have not tested the
CPU support internally due to non-availability of FVP for the CPU.
TF-A assumes that I$ will be invalidated when CPU is reset. Perhaps this
is not true for your setup. Could you try adding a `IC IALLU` in the CPU
reset handler prior to I$ enable and see if that improves anything ?
Best Regards
Soby Mathew
>
>
> ------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all
> copies of the original message.
> ------------------------------------------------------------------------
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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.
Hello,
First of all, thanks a lot for posting the Hercules-AE patches.
We picked them up and used them internally. Unfortunately, the CPU sees garbage in it's I$ when we enable the I cache for the processor. If we keep I$ disabled, TF-A boots properly. We are using TF-A v1.4 for verification.
We booted Linux kernel v4.14 on the processor and don't see this problem there. So, we suspect something going wrong inside TF-A. Have you seen this problem internally? Any hints or clues to solve it would be helpful.
Thanks.
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Hi everyone,
This post is to let you know about some changes to the TrustedFirmware.org website and to the TF-A documentation. It briefly covers what's new, what has moved, and what happens to any existing resources you may be using.
First of all, we are making it more obvious where to access the documentation and the Gerrit review system. The front page of trustedfirmware.org has grown new "Documentation" and "Review" menus with links to this content. Dashboard and Wiki items have moved under the Documentation menu.
Secondly, the online version of the documentation has moved to www.trustedfirmware.org/docs/tf-a<http://www.trustedfirmware.org/docs/tf-a>. This is a pre-rendered, HTML copy of the content that is found under the "docs" directory of the TF-A repository. The content here will remain synchronised with the master branch of the repository. Following the v2.2 release, you will also be able to access a static version of the documentation that corresponds to that tag, via a version selection drop-down menu on the site.
The intention behind this change is to make it easier to find the docs, to improve the output quality and to make the content more modular and readable. The new setup has a persistent table of contents (displayed to the left of the page content) and a search feature, making it easier to find what you're looking for and easier to move between documents and topics.
You may be used to viewing the docs through either the git viewer (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/) or through the Github mirror (https://github.com/ARM-software/arm-trusted-firmware/). The landing pages of these sites now contain links to the new content. While you can still use these sites to access other documentation content, you may find that there are some formatting warnings displayed if you do so.
Finally, if you prefer to read a local copy of the documentation on your machine then you can build the same HTML output following the instructions at https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/docs-bui… (or docs/getting_started/docs-build.rst, for the equivalent file in the repository).
As always, let us know if you have any comments or if there are other changes you would like to see.
Thanks,
Paul
Hi folks,
I've been using TF-A with mainline U-Boot recently as firmware & boot
loader for a RK3399 Rockpro64 board. I'm compiling TF-A and U-boot based
on this guide [1], using gcc 8.3.0 from Debian.
TF-A v2.1 works fine for this, but I recently tried to switch to TF-A
latest master and found U-Boot gets stuck with this version.
The symptoms are: U-Boot TPL and SPL print starting messages like this:
U-Boot TPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50)
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50 +0000)
Trying to boot from MMC2
...and then there is no more output when normally U-Boot proper would
start, and go on to load the Linux kernel, etc.
Starting from v2.1, with git bisect I found the first 'bad' commit is:
0aad563c7480 rockchip: Update BL31_BASE to 0x40000
and that commit does change some RK3399-related files so seems likely.
I'm not sure how to debug further, any ideas on why boot is hanging
after that change or how to get more debugging information?
Best regards,
Hugh Cole-Baker
[1] https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip
