Hello,
I have just notices that the TFM Protected Storage service partition has been changed from PSA ROT to APP ROT.
Just curious, what is a reason?
May it stay PSA ROT?
Thank you in advance,
Andrej Butok
Hello,
The next Technical Forum is planned on Thursday, June 25 at 15:00-16:00 UTC (US time zone).
This is exceptional time zone change because of a public holiday in China that day.
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hi Tamas,
> I do not know whether the this two phase setting of MSP_LIMIT is still in use or not. If not the no need for S_MSP_STACK_SIZE_INIT.
The only place where it's used is the GCC linker file:
__msp_init_stack_size__ = S_MSP_STACK_SIZE_INIT
So for GCC __msp_init_stack_size__ is in 2 times less (0x400) than for Keil and IAR (0x800) "__msp_init_stack_size__ = S_MSP_STACK_SIZE".
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: Tuesday, June 16, 2020 10:17 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE
Hi Andrej,
The BOOT_TFM_SHARED_DATA and the MSP_STACK area are overlapping on purpose. The partitions which are expecting to receive data from bootloader is intended to get their own data during the partition init phase with calling tfm_core_get_boot_data() with the partition's major_type. Then the data will be copied from shared area to partition's memory.
So after all partition's init is executed then the data from the shared buffer is distributed to the owning partitions and resides in their memory. At this point the shared_data area can be overwritten by growing MSP, without destroying shared data.
Originally there was an S_MSP_STACK_SIZE_INIT size which was used to setup the MSP_LIMIT for the init phase to avoid overwriting the shared data area. After the init phase the MSP_LIMIT was set again with its full size S_MSP_STACK_SIZE.
I do not know whether the this two phase setting of MSP_LIMIT is still in use or not. If not the no need for S_MSP_STACK_SIZE_INIT.
+-> +-> +--------------+ <- Shared boot data base, S_MSP_STACK_SIZE
| Shared| | |
M | Data | | |
S | | | |
P | +-> +--------------+ <- S_MSP_STACK_SIZE_INIT
| | |
| | |
| | |
+-> +--------------+ <- Top of MSP
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M
Sent: 16 June 2020 09:52
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE
Hello,
What is a difference between S_MSP_STACK_SIZE_INIT and S_MSP_STACK_SIZE defined in partition\region_defs.h:
#define S_MSP_STACK_SIZE_INIT (0x0000400)
#define S_MSP_STACK_SIZE (0x0000800)
S_MSP_STACK_SIZE_INIT is used only for gcc.
S_MSP_STACK_SIZE is used for armclang and iar.
Guess, it should be used only one definition. So in our platform code we are going to use only S_MSP_STACK_SIZE.
Should you fix it for all platforms in the original TFM?
Thanks,
Andrej Butok
SW Tech Lead
Security & Connectivity, Microcontrollers
NXP Semiconductors
Hi Andrej,
The BOOT_TFM_SHARED_DATA and the MSP_STACK area are overlapping on purpose. The partitions which are expecting to receive data from bootloader is intended to get their own data during the partition init phase with calling tfm_core_get_boot_data() with the partition's major_type. Then the data will be copied from shared area to partition's memory.
So after all partition's init is executed then the data from the shared buffer is distributed to the owning partitions and resides in their memory. At this point the shared_data area can be overwritten by growing MSP, without destroying shared data.
Originally there was an S_MSP_STACK_SIZE_INIT size which was used to setup the MSP_LIMIT for the init phase to avoid overwriting the shared data area. After the init phase the MSP_LIMIT was set again with its full size S_MSP_STACK_SIZE.
I do not know whether the this two phase setting of MSP_LIMIT is still in use or not. If not the no need for S_MSP_STACK_SIZE_INIT.
+-> +-> +--------------+ <- Shared boot data base, S_MSP_STACK_SIZE
| Shared| | |
M | Data | | |
S | | | |
P | +-> +--------------+ <- S_MSP_STACK_SIZE_INIT
| | |
| | |
| | |
+-> +--------------+ <- Top of MSP
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 16 June 2020 09:52
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] S_MSP_STACK_SIZE_INIT vs S_MSP_STACK_SIZE
Hello,
What is a difference between S_MSP_STACK_SIZE_INIT and S_MSP_STACK_SIZE defined in partition\region_defs.h:
#define S_MSP_STACK_SIZE_INIT (0x0000400)
#define S_MSP_STACK_SIZE (0x0000800)
S_MSP_STACK_SIZE_INIT is used only for gcc.
S_MSP_STACK_SIZE is used for armclang and iar.
Guess, it should be used only one definition. So in our platform code we are going to use only S_MSP_STACK_SIZE.
Should you fix it for all platforms in the original TFM?
Thanks,
Andrej Butok
SW Tech Lead
Security & Connectivity, Microcontrollers
NXP Semiconductors
Hello,
What is a difference between S_MSP_STACK_SIZE_INIT and S_MSP_STACK_SIZE defined in partition\region_defs.h:
#define S_MSP_STACK_SIZE_INIT (0x0000400)
#define S_MSP_STACK_SIZE (0x0000800)
S_MSP_STACK_SIZE_INIT is used only for gcc.
S_MSP_STACK_SIZE is used for armclang and iar.
Guess, it should be used only one definition. So in our platform code we are going to use only S_MSP_STACK_SIZE.
Should you fix it for all platforms in the original TFM?
Thanks,
Andrej Butok
SW Tech Lead
Security & Connectivity, Microcontrollers
NXP Semiconductors
Hi,
This design addressing to share the code of the common crypto primitives(SHA256, RSA, later AES) between MCUboot and runtime SPE. The goal is to reduce the flash footprint of SPE.
Design proposal:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4587
Implementation:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4583/
TL;DR:
SPE binary size can be reduced with 10KB. If image encryption will be turned on then ~12-13KB is the gain. Please let us know if you think this improvements would be useful.
@Thomas Törnblom<mailto:thomas.tornblom@iar.com>:
Could you check the porting to IAR toolchain?
BR,
Tamas Ban
Hi Thomas,
My bad, I merged a patch today that broke it. The fix is here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4562. I will merge it once the CI has verified it.
Kind regards,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: 12 June 2020 14:00
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Does FVP_SSE300_MPS2 target build?
I just noticed the merge of the FVP_SSE300_MPS2 support and I'm trying to build, but it fails with:
---
[ 23%] Building C object test/secure_test/CMakeFiles/tfm_secure_tests.dir/suites/ps/secure/psa_ps_s_interface_testsuite.o
C:/Users/thomasto/Projects/tf-m1/trusted-firmware-m/test/suites/ps/secure/psa_ps_s_interface_testsuite.c:46:39: error:
use of undeclared identifier 'PS_MAX_ASSET_SIZE'
static const uint8_t write_asset_data[PS_MAX_ASSET_SIZE] = {0xBF};
...
---
Known issue?
Thomas
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
I just noticed the merge of the FVP_SSE300_MPS2 support and I'm trying
to build, but it fails with:
---
[ 23%] Building C object
test/secure_test/CMakeFiles/tfm_secure_tests.dir/suites/ps/secure/psa_ps_s_interface_testsuite.o
C:/Users/thomasto/Projects/tf-m1/trusted-firmware-m/test/suites/ps/secure/psa_ps_s_interface_testsuite.c:46:39:
error:
use of undeclared identifier 'PS_MAX_ASSET_SIZE'
static const uint8_t write_asset_data[PS_MAX_ASSET_SIZE] = {0xBF};
...
---
Known issue?
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Zephyr uses DT as a means to describe the hardware to the system for things like register address, irq numbers, etc. Instead of the typical runtime usage, it generates code to be used at build time for Cortex-M (and other) devices to address the size cost concern.
On the KConfig side Zephyr uses a python implementation of the KConfig parser to allow portability across host build systems.
- k
> On Jun 12, 2020, at 4:35 AM, Gyorgy Szing via TF-M <tf-m(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> Just some minor additions. In the TF-M build system Kconfig will most likely generate input for cmake scripts, so the compiler may not have a connection to it.
>
> The original intention with DT is capturing configuration data to allow hardware independent binaries (for defining base address of peripherals, boot information, etc..), and is mostly parsed runtime. In the Cortex-M space this might be a bit out-of scope. Most likely it will be used as a “standard” language to define “retargeting” information, and a tool will be developed which runs compile time and which allows access to the retargeting data for cmake. Something like CMSIS zone, but closer to established open-source technologies.
> In multicore systems having bot Cortex-A and M core DT would allow having a consistent solution for both A and M firmware. This is also a reason why cmake is a better build solution for TF-M than CMSIS Build.
>
> /George
>
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
> Sent: 12 June 2020 11:16
> To: Thomas Törnblom <thomas.tornblom(a)iar.com>; tf-m(a)lists.trustedfirmware.org
> Cc: nd <nd(a)arm.com>
> Subject: Re: [TF-M] CMake flags
>
> Hi Thomas,
>
> DT is another very attractive topic. TF-M currently doesn’t include any DT support.
> So maybe there is mixed preprocessing of DT and Kconfig in Zephyr, but Kconfig can be parsed without any compiler.
>
> Best regards,
> Hu Ziji
>
> From: Thomas Törnblom <thomas.tornblom(a)iar.com>
> Sent: Friday, June 12, 2020 5:09 PM
> To: David Hu <David.Hu(a)arm.com>; tf-m(a)lists.trustedfirmware.org
> Cc: nd <nd(a)arm.com>
> Subject: Re: [TF-M] CMake flags
>
> Perhaps I'm mixing dts and Kconfig up.
>
> In Zephyr, dtc is used to generate output that is run through the gcc preprocessor in assembly mode.
>
> The output from dtc looks like:
> ---
> /dts-v1/;
>
> / {
> ��� #address-cells = < 0x1 >;
> ��� #size-cells = < 0x1 >;
> ��� model = "STMicroelectronics STM32F746G DISCOVERY board";
> ��� compatible = "st,stm32f746g-disco", "st,stm32f746";
> ��� chosen {
> ��� ��� zephyr,console = &usart1;
> ��� ��� zephyr,shell-uart = &usart1;
> ��� ��� zephyr,sram = &sram0;
> ��� ��� zephyr,flash = &flash0;
> ��� ��� zephyr,dtcm = &dtcm;
> ��� };
> ...
> ---
>
> Our preprocessor can not be run in assembler mode and it pukes on the "#address-cells" type elements in the file.
>
> If this is not what Kconfig is about, then please ignore my comments.
>
> Thomas
>
> Den 2020-06-12 kl. 09:43, skrev David Hu:
> Hi Thomas,
> �
> I�ve not met such a problem yet. Could you please give more details about the portability issues in Kconfig?
> In our PoC, it firstly parses the Kconfig files and then convert the output Kconfig options into CMake flags. Thus the whole process is not related to any compiler.
> I checked Zephyr previously. It looks like Zephyr has the similar idea as our PoC does.
> �
> Best regards,
> Hu Ziji
> �
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas T�rnblom via TF-M
> Sent: Friday, June 12, 2020 3:36 PM
> To: tf-m(a)lists.trustedfirmware.org
> Subject: Re: [TF-M] CMake flags
> �
> Introducing a dependency on Kconfig may cause portability issues with some toolchains (IAR for instance)
>
> I am working on adding support for the IAR toolchain to Zephyr, and Kconfig is one of the issues I've run into.
>
> At least in Zephyr, the output from Kconfig is run through the C preprocessor and this causes issues with the IAR preprocessor so for now I use gcc for this step.
>
> Thomas
>
> Den 2020-06-12 kl. 07:32, skrev David Hu via TF-M:
> Hi Adrian,
> �
> Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.
> �
> Kconfig can bring some advantages:
> • It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files.
> • Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.
> �
> But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.
> �
> Best regards,
> Hu Ziji
> �
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M
> Sent: Friday, June 12, 2020 12:24 AM
> To: Raef Coles <Raef.Coles(a)arm.com>
> Cc: tf-m(a)lists.trustedfirmware.org
> Subject: [TF-M] CMake flags
> �
> Hi Raef. Thanks for the presentation today.
> �
> If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
> �
> From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
> �
> Adrian
> �
>
> �
> --
>
> Thomas T�rnblom, Product Engineer
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com Website: www.iar.com
> Twitter: www.twitter.com/iarsystems
>
> --
>
> Thomas T�rnblom, Product Engineer
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com Website: www.iar.com
> Twitter: www.twitter.com/iarsystems
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Note that Zephyr has a Cmake function that does this exact thing, if you're interested: https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/extensions.c…
Øyvind Rønningstad
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Friday, June 12, 2020 11:45
To: Raef Coles <Raef.Coles(a)arm.com>; Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Adrian Shaw <Adrian.Shaw(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] CMake flags
Hi Raef,
My current prototype is to parse the options from Kconfig output file and "inject" them into CMake (by set()) in a CMake file running at the beginning of build process.
Kconfig generation is an optional step before build starts, only if you request to change the configuration. Otherwise, build just starts with previous Kconfig output config as normal.
Best regards,
Hu Ziji
-----Original Message-----
From: Raef Coles <Raef.Coles(a)arm.com>
Sent: Friday, June 12, 2020 5:34 PM
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; David Hu <David.Hu(a)arm.com>; Adrian Shaw <Adrian.Shaw(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: CMake flags
I think I'd advocate for using a workflow of generating a cfg.cmake file from the kconfig, instead of a txt file with an associated cmake parser.
I think it'd be advantageous to not have a parser for an arbitrary config file format in the cmake, since the cmake set(CACHE) statements are already fairly user-readable. It would be different if we could only generate something less readable from the kconfig (i.e. xml/json). It would be ideal if we could generate the statements such that:
set(<variable_name> <default_option> CACHE <TYPE> "<docstring> (<valid_option> | <valid_option> | ...)"
I'm not sure if we can do this in Kconfig, but it seems plausible, and imo is the ideal solution since it gives the user of later editing the cmake config (even using a cache editor like ccmake) while documenting which choices are sane.
Raef
________________________________________
From: Gyorgy Szing <Gyorgy.Szing(a)arm.com>
Sent: 12 June 2020 06:56
To: David Hu; Adrian Shaw; Raef Coles; tf-m(a)lists.trustedfirmware.org
Cc: nd; nd
Subject: RE: CMake flags
Hi,
This requirement could be addressed with a user specific metadata file which is processed by the build-system. Implementation wise the easiest would be to include a file like UserCfg.cmake. This file could contain set(<option> CACHE <STRING|BOOL|PATH> "") commands to set the option variables. User experience wise a text file parsed by cmake scripts would be the best. Such a file could contain variable=value lines.
Longer term when Kconfig support is ready, it could cover these options too. Running Kconfig is a an act done less often, and most of the times, the user is expected to save the Kconfig input and output files. Most of the time the build-system would just use the pre-generated config. I imagine a workflow similar to the one used by the Linux Kernel.
Just my two cent's though.
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: 12 June 2020 07:33
To: Adrian Shaw <Adrian.Shaw(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] CMake flags
Hi Adrian,
Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.
Kconfig can bring some advantages:
* It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files.
* Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.
But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M
Sent: Friday, June 12, 2020 12:24 AM
To: Raef Coles <Raef.Coles(a)arm.com<mailto:Raef.Coles@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] CMake flags
Hi Raef. Thanks for the presentation today.
If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
Adrian
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
This requirement could be addressed with a user specific metadata file which is processed by the build-system. Implementation wise the easiest would be to include a file like UserCfg.cmake. This file could contain set(<option> CACHE <STRING|BOOL|PATH> "") commands to set the option variables. User experience wise a text file parsed by cmake scripts would be the best. Such a file could contain variable=value lines.
Longer term when Kconfig support is ready, it could cover these options too. Running Kconfig is a an act done less often, and most of the times, the user is expected to save the Kconfig input and output files. Most of the time the build-system would just use the pre-generated config. I imagine a workflow similar to the one used by the Linux Kernel.
Just my two cent's though.
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: 12 June 2020 07:33
To: Adrian Shaw <Adrian.Shaw(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] CMake flags
Hi Adrian,
Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.
Kconfig can bring some advantages:
* It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files.
* Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.
But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M
Sent: Friday, June 12, 2020 12:24 AM
To: Raef Coles <Raef.Coles(a)arm.com<mailto:Raef.Coles@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] CMake flags
Hi Raef. Thanks for the presentation today.
If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
>From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
Adrian
Hi,
Just some minor additions. In the TF-M build system Kconfig will most likely generate input for cmake scripts, so the compiler may not have a connection to it.
The original intention with DT is capturing configuration data to allow hardware independent binaries (for defining base address of peripherals, boot information, etc..), and is mostly parsed runtime. In the Cortex-M space this might be a bit out-of scope. Most likely it will be used as a "standard" language to define "retargeting" information, and a tool will be developed which runs compile time and which allows access to the retargeting data for cmake. Something like CMSIS zone, but closer to established open-source technologies.
In multicore systems having bot Cortex-A and M core DT would allow having a consistent solution for both A and M firmware. This is also a reason why cmake is a better build solution for TF-M than CMSIS Build.
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: 12 June 2020 11:16
To: Thomas Törnblom <thomas.tornblom(a)iar.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] CMake flags
Hi Thomas,
DT is another very attractive topic. TF-M currently doesn't include any DT support.
So maybe there is mixed preprocessing of DT and Kconfig in Zephyr, but Kconfig can be parsed without any compiler.
Best regards,
Hu Ziji
From: Thomas Törnblom <thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com>>
Sent: Friday, June 12, 2020 5:09 PM
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] CMake flags
Perhaps I'm mixing dts and Kconfig up.
In Zephyr, dtc is used to generate output that is run through the gcc preprocessor in assembly mode.
The output from dtc looks like:
---
/dts-v1/;
/ {
��� #address-cells = < 0x1 >;
��� #size-cells = < 0x1 >;
��� model = "STMicroelectronics STM32F746G DISCOVERY board";
��� compatible = "st,stm32f746g-disco", "st,stm32f746";
��� chosen {
��� ��� zephyr,console = &usart1;
��� ��� zephyr,shell-uart = &usart1;
��� ��� zephyr,sram = &sram0;
��� ��� zephyr,flash = &flash0;
��� ��� zephyr,dtcm = &dtcm;
��� };
...
---
Our preprocessor can not be run in assembler mode and it pukes on the "#address-cells" type elements in the file.
If this is not what Kconfig is about, then please ignore my comments.
Thomas
Den 2020-06-12 kl. 09:43, skrev David Hu:
Hi Thomas,
�
I�ve not met such a problem yet. Could you please give more details about the portability issues in Kconfig?
In our PoC, it firstly parses the Kconfig files and then convert the output Kconfig options into CMake flags. Thus the whole process is not related to any compiler.
I checked Zephyr previously. It looks like Zephyr has the similar idea as our PoC does.
�
Best regards,
Hu Ziji
�
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas T�rnblom via TF-M
Sent: Friday, June 12, 2020 3:36 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] CMake flags
�
Introducing a dependency on Kconfig may cause portability issues with some toolchains (IAR for instance)
I am working on adding support for the IAR toolchain to Zephyr, and Kconfig is one of the issues I've run into.
At least in Zephyr, the output from Kconfig is run through the C preprocessor and this causes issues with the IAR preprocessor so for now I use gcc for this step.
Thomas
Den 2020-06-12 kl. 07:32, skrev David Hu via TF-M:
Hi Adrian,
�
Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.
�
Kconfig can bring some advantages:
* It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files.
* Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.
�
But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.
�
Best regards,
Hu Ziji
�
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M
Sent: Friday, June 12, 2020 12:24 AM
To: Raef Coles <Raef.Coles(a)arm.com><mailto:Raef.Coles@arm.com>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] CMake flags
�
Hi Raef. Thanks for the presentation today.
�
If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
�
>From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
�
Adrian
�
�
--
Thomas T�rnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
--
Thomas T�rnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
Hi Thomas,
I've not met such a problem yet. Could you please give more details about the portability issues in Kconfig?
In our PoC, it firstly parses the Kconfig files and then convert the output Kconfig options into CMake flags. Thus the whole process is not related to any compiler.
I checked Zephyr previously. It looks like Zephyr has the similar idea as our PoC does.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: Friday, June 12, 2020 3:36 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] CMake flags
Introducing a dependency on Kconfig may cause portability issues with some toolchains (IAR for instance)
I am working on adding support for the IAR toolchain to Zephyr, and Kconfig is one of the issues I've run into.
At least in Zephyr, the output from Kconfig is run through the C preprocessor and this causes issues with the IAR preprocessor so for now I use gcc for this step.
Thomas
Den 2020-06-12 kl. 07:32, skrev David Hu via TF-M:
Hi Adrian,
Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.
Kconfig can bring some advantages:
* It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files.
* Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.
But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M
Sent: Friday, June 12, 2020 12:24 AM
To: Raef Coles <Raef.Coles(a)arm.com><mailto:Raef.Coles@arm.com>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] CMake flags
Hi Raef. Thanks for the presentation today.
If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
>From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
Adrian
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
Introducing a dependency on Kconfig may cause portability issues with
some toolchains (IAR for instance)
I am working on adding support for the IAR toolchain to Zephyr, and
Kconfig is one of the issues I've run into.
At least in Zephyr, the output from Kconfig is run through the C
preprocessor and this causes issues with the IAR preprocessor so for now
I use gcc for this step.
Thomas
Den 2020-06-12 kl. 07:32, skrev David Hu via TF-M:
>
> Hi Adrian,
>
> Actually we have been investigating configuration alternatives and
> making some prototypes of Kconfig.
>
> Kconfig can bring some advantages:
>
> * It can setup configuration and check dependency before CMake
> starts and therefore it can help CMake simplify dealing with the
> mutual dependencies. For example, if CPU and arch options can be
> configured in Kconfig, CMake can avoid the workaround to
> re-configure compiler after parsing platform files.
> * Kconfig can collect together the options which are distributed in
> various CMake files. Developers can more easily understand the
> options and their dependencies, compared with searching them all
> around the build system.
>
> But Kconfig may not cover all the flags in command line. Flags such as
> compiler selections, build type and project config file, may vary in
> each build. It can be inconvenient to put them into Kconfig.
>
> Best regards,
>
> Hu Ziji
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of
> *Adrian Shaw via TF-M
> *Sent:* Friday, June 12, 2020 12:24 AM
> *To:* Raef Coles <Raef.Coles(a)arm.com>
> *Cc:* tf-m(a)lists.trustedfirmware.org
> *Subject:* [TF-M] CMake flags
>
> Hi Raef. Thanks for the presentation today.
>
> If I remember correctly, TF-M's CMake has quite a lot of command line
> flags now (the ones that are set with -D). And I think this will grow
> in the future as more options are needed.
>
> From a command line point of view, this is kind of annoying because
> the commands end up being quite long. Do you guys think something like
> Kconfig could help?
>
> Adrian
>
>
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi Adrian,
Actually we have been investigating configuration alternatives and making some prototypes of Kconfig.
Kconfig can bring some advantages:
* It can setup configuration and check dependency before CMake starts and therefore it can help CMake simplify dealing with the mutual dependencies. For example, if CPU and arch options can be configured in Kconfig, CMake can avoid the workaround to re-configure compiler after parsing platform files.
* Kconfig can collect together the options which are distributed in various CMake files. Developers can more easily understand the options and their dependencies, compared with searching them all around the build system.
But Kconfig may not cover all the flags in command line. Flags such as compiler selections, build type and project config file, may vary in each build. It can be inconvenient to put them into Kconfig.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M
Sent: Friday, June 12, 2020 12:24 AM
To: Raef Coles <Raef.Coles(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] CMake flags
Hi Raef. Thanks for the presentation today.
If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
>From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
Adrian
Hi Raef. Thanks for the presentation today.
If I remember correctly, TF-M's CMake has quite a lot of command line flags now (the ones that are set with -D). And I think this will grow in the future as more options are needed.
>From a command line point of view, this is kind of annoying because the commands end up being quite long. Do you guys think something like Kconfig could help?
Adrian
Hello,
Agenda for today's Tech forum:
1. Ongoing MCUboot alignment update.
2. Build system improvements.
Code sharing between bootloader and runtime firmware will be presented on the next call.
Best regards,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Vincze via TF-M
Sent: 05 June 2020 13:03
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M Technical Forum call - June 11
Hi,
I also would like to give a brief update on the status of the ongoing MCUboot alignment work.
David V
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Tamas Ban via TF-M
Sent: 05 June 2020 11:23
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] TF-M Technical Forum call - June 11
Hi Anton,
I would like to give a short presentation about crypto code sharing between bootloader and runtime firmware(SPE).
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: 03 June 2020 21:21
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M Technical Forum call - June 11
Hello,
The next Technical Forum is planned on Thursday, June 11 at 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Here are some local time examples:
Location
Local Time
Time Zone
UTC Offset
Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia)
Thursday, 11 June 2020, 08:00:00
PDT<https://www.timeanddate.com/time/zones/pdt>
UTC-7 hours
Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois)
Thursday, 11 June 2020, 10:00:00
CDT<https://www.timeanddate.com/time/zones/cdt>
UTC-5 hours
Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England)
Thursday, 11 June 2020, 16:00:00
BST<https://www.timeanddate.com/time/zones/bst>
UTC+1 hour
Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality)
Thursday, 11 June 2020, 23:00:00
CST<https://www.timeanddate.com/time/zones/cst-china>
UTC+8 hours
Corresponding UTC (GMT)
Thursday, 11 June 2020, 15:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T1500>
Best regards,
Anton Komlev
Hi All,
Just a heads up that TF-Mv1.1 tag is planned for middle to end of July. Code freeze of TF-M master is aimed around end of June to allow enough time for testing.
Similar to TF-Mv1.0 and previous tags, v1.1 will include all TF-M changes in TF-M master available till code freeze in end of June.
Availability of the tag will be notified via. this mailing list.
Thanks,
Shebu
Technology Manager-TF-M, Arm Ltd.
Hi,
In case you meet the same issue as Thomas.
There are two possible solutions from our experience.
One is:
* Abandon both the duplicated changes.
* Change the change-ID of you patch and then submit
* You end up with a whole new patch without the original histories.
In this way, you lose both the change history and review history.
If you are OK with that, you can quick solve the issue by yourself.
Otherwise, the other solution is to contact Benjamin Copeland <ben.copeland(a)linaro.org<mailto:ben.copeland@linaro.org>> to delete one of the duplicates(usually keep the one with histories).
And push your new patch set after deletion.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: Tuesday, June 9, 2020 10:08 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Gerrit issues
Issue sorted now, thanks to Ben Copeland.
Thomas
Den 2020-06-09 kl. 08:51, skrev Thomas Törnblom via TF-M:
Still having this issue:
---
PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git HEAD:refs/for/master
Enumerating objects: 208, done.
Counting objects: 100% (207/207), done.
Delta compression using up to 4 threads
Compressing objects: 100% (131/131), done.
Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done.
Total 135 (delta 97), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (97/97)
remote: Processing changes: refs: 1, done
To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git
! [remote rejected] HEAD -> refs/for/master (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates)
error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git'
---
Any ideas how to resolve?
I guess starting out with a fresh local repo would work, but I have 11 patches waiting to be reviewed and merged.
A handful of them appears to be duplicated, and I abandoned those that appeared to be old and had merge conflicts. Unfortunately a majority of those had already been reviewed and the new ones aren't. The new ones has also lost their reviewers
So now I'm stuck and I can't update or create new patches.
Thomas
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
Issue sorted now, thanks to Ben Copeland.
Thomas
Den 2020-06-09 kl. 08:51, skrev Thomas Törnblom via TF-M:
> Still having this issue:
> ---
> PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push
> ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git
> HEAD:refs/for/master
> Enumerating objects: 208, done.
> Counting objects: 100% (207/207), done.
> Delta compression using up to 4 threads
> Compressing objects: 100% (131/131), done.
> Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done.
> Total 135 (delta 97), reused 0 (delta 0), pack-reused 0
> remote: Resolving deltas: 100% (97/97)
> remote: Processing changes: refs: 1, done
> To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git
> ! [remote rejected] HEAD -> refs/for/master
> (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates)
> error: failed to push some refs to
> 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git'
> ---
>
> Any ideas how to resolve?
>
> I guess starting out with a fresh local repo would work, but I have 11
> patches waiting to be reviewed and merged.
>
> A handful of them appears to be duplicated, and I abandoned those that
> appeared to be old and had merge conflicts. Unfortunately a majority
> of those had already been reviewed and the new ones aren't. The new
> ones has also lost their reviewers
>
> So now I'm stuck and I can't update or create new patches.
>
> Thomas
> --
>
> *Thomas Törnblom*, /Product Engineer/
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
> Website: www.iar.com <http://www.iar.com>
> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
>
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Still having this issue:
---
PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push
ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git
HEAD:refs/for/master
Enumerating objects: 208, done.
Counting objects: 100% (207/207), done.
Delta compression using up to 4 threads
Compressing objects: 100% (131/131), done.
Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done.
Total 135 (delta 97), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (97/97)
remote: Processing changes: refs: 1, done
To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git
! [remote rejected] HEAD -> refs/for/master
(I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates)
error: failed to push some refs to
'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git'
---
Any ideas how to resolve?
I guess starting out with a fresh local repo would work, but I have 11
patches waiting to be reviewed and merged.
A handful of them appears to be duplicated, and I abandoned those that
appeared to be old and had merge conflicts. Unfortunately a majority of
those had already been reviewed and the new ones aren't. The new ones
has also lost their reviewers
So now I'm stuck and I can't update or create new patches.
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Also the dashboard has been updated for the project to point to new repo :
https://review.trustedfirmware.org/p/TF-M/trusted-firmware-m/+/dashboard/si…
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M
Sent: 08 June 2020 17:11
To: tf-m(a)lists.trustedfirmware.org; Thomas Törnblom <thomas.tornblom(a)iar.com>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M URLs update for code and Gerrit review
Hi Thomas.
I have just prepared a patch which is updating the documentation with references to the new repository address.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4487
Regards,
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 08 June 2020 13:17
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: Re: [TF-M] TF-M URLs update for code and Gerrit review
.../docs/processes/contributing.rst should be updated with the new URL also.
I checked there when I started having issues, but saw no changes there.
Thomas
Den 2020-06-08 kl. 14:10, skrev Thomas Törnblom via TF-M:
Thanks Anton, that explains things.
However now I get some other issues:
---
PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git HEAD:refs/for/master
Enumerating objects: 208, done.
Counting objects: 100% (207/207), done.
Delta compression using up to 4 threads
Compressing objects: 100% (131/131), done.
Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done.
Total 135 (delta 97), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (97/97)
remote: Processing changes: refs: 1, done
To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git
! [remote rejected] HEAD -> refs/for/master (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates)
error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git'
---
Thomas
Den 2020-06-08 kl. 13:43, skrev Anton Komlev via TF-M:
Hello
TF-M code moved to the new location recently with a redirection link from the original URL - for compatibility purpose.
Unfortunately, Gerrit got confused with two namespaces and several patches got messed up last week. To prevent it from happen again, the old TF-M location marked as read-only mirror.
Please use new TF-M URL for your pushing your commits:
ssh://<user-name>@review.trustedfirmware.org:29418/TF-M/trusted-firmware-m
New repo URL:
https://review.trustedfirmware.org/TF-M/trusted-firmware-m
Thanks,
Anton
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
Hi Thomas.
I have just prepared a patch which is updating the documentation with references to the new repository address.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4487
Regards,
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 08 June 2020 13:17
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] TF-M URLs update for code and Gerrit review
.../docs/processes/contributing.rst should be updated with the new URL also.
I checked there when I started having issues, but saw no changes there.
Thomas
Den 2020-06-08 kl. 14:10, skrev Thomas Törnblom via TF-M:
Thanks Anton, that explains things.
However now I get some other issues:
---
PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git HEAD:refs/for/master
Enumerating objects: 208, done.
Counting objects: 100% (207/207), done.
Delta compression using up to 4 threads
Compressing objects: 100% (131/131), done.
Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done.
Total 135 (delta 97), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (97/97)
remote: Processing changes: refs: 1, done
To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git
! [remote rejected] HEAD -> refs/for/master (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates)
error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git'
---
Thomas
Den 2020-06-08 kl. 13:43, skrev Anton Komlev via TF-M:
Hello
TF-M code moved to the new location recently with a redirection link from the original URL – for compatibility purpose.
Unfortunately, Gerrit got confused with two namespaces and several patches got messed up last week. To prevent it from happen again, the old TF-M location marked as read-only mirror.
Please use new TF-M URL for your pushing your commits:
ssh://<user-name>@review.trustedfirmware.org:29418/TF-M/trusted-firmware-m
New repo URL:
https://review.trustedfirmware.org/TF-M/trusted-firmware-m
Thanks,
Anton
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
