Hi,
I am using an iMX8M mini, I have flashed the image with uuu.auto of
L4.14.98_2.0.0_ga_images_MX8MMEVK and I have a Linux image with OP-TEE. Now
I want to use TF-A but I don't know the steps to continue. I am reading
this document (
https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/gui…
and https : //trustedfirmware-a.readthedocs.io/en/latest/plat/imx8m.html
<https://trustedfirmware-a.readthedocs.io/en/latest/plat/imx8m.html>) but I
don't know how to get these files: u-boot.bin, u-boot-nodtb.bin,
u-boot-spl.bin , DTB U-Boot file (for example, fsl-imx8mq-evk.dtb).
Can anyone tell me the steps to follow?
Thanks, best regards
Iñigo.
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)
** CID 353989: Integer handling issues (INCOMPATIBLE_CAST)
________________________________________________________________________________________________________
*** CID 353989: Integer handling issues (INCOMPATIBLE_CAST)
/plat/intel/soc/common/socfpga_psci.c: 138 in socfpga_system_reset()
132
133 extern uint64_t intel_rsu_update_address;
134
135 static void __dead2 socfpga_system_reset(void)
136 {
137 if (intel_rsu_update_address)
>>> CID 353989: Integer handling issues (INCOMPATIBLE_CAST)
>>> Pointer "&intel_rsu_update_address" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness.
138 mailbox_rsu_update((uint32_t *)&intel_rsu_update_address);
139 else
140 mailbox_reset_cold();
141
142 while (1)
143 wfi();
** CID 353988: Integer handling issues (INCOMPATIBLE_CAST)
________________________________________________________________________________________________________
*** CID 353988: Integer handling issues (INCOMPATIBLE_CAST)
/plat/intel/soc/common/socfpga_sip_svc.c: 526 in sip_smc_handler()
520
521 case INTEL_SIP_SMC_RSU_NOTIFY:
522 status = intel_rsu_notify(x1);
523 SMC_RET1(handle, status);
524
525 case INTEL_SIP_SMC_RSU_RETRY_COUNTER:
>>> CID 353988: Integer handling issues (INCOMPATIBLE_CAST)
>>> Pointer "rsu_respbuf" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness.
526 status = intel_rsu_retry_counter((uint32_t *)rsu_respbuf,
527 ARRAY_SIZE(rsu_respbuf), &val);
528 if (status) {
529 SMC_RET1(handle, status);
530 } else {
531 SMC_RET2(handle, status, val);
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…
Hello,
The fip header has reserved fields available for platform specific use.
The fiptool allows these header fields to be filled in using the
--plat-toc-flags.
A call needs to be available in the ATF framework to get these flags
without accessing the FIP file again to get these flags.
We have a solution we've used for ATF for quite some time to access
these flags.
It's finally being upstreamed here:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2839
If there are any other efficient methods to access these flags or a
better proposal please suggest.
Thanks,
Scott
Hi Pankaj,
Would it be possible to provide more information on your platform (what CPU, its revision, number of clusters/CPUs per cluster, etc.)?
Is your platform code publically available?
Regards.
Alexei
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Pankaj Gupta via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 07 February 2020 10:57
To: Olivier Deprez <Olivier.Deprez(a)arm.com>
Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; nd <nd(a)arm.com>
Subject: Re: [TF-A] [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2
Hi,
Please find the comments in-line.
Regards
Pankaj
-----Original Message-----
From: Olivier Deprez <Olivier.Deprez(a)arm.com>
Sent: Wednesday, February 5, 2020 6:54 PM
To: Pankaj Gupta <pankaj.gupta(a)nxp.com>
Cc: nd <nd(a)arm.com>; tf-a(a)lists.trustedfirmware.org
Subject: [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2
>Caution: EXT Email
>Hi Pankaj,
>Can you pls provide a bit more background:
>Which boot stage (BL1/BL2/BL31...) get affected?
BL2
>Is there any crash report to console?
No. But, using the external debugger, it is found that core gets to non-responding.
>Is this an aarch64/or aarch32 platform?
aarch64
>There can be different root causes to this e.g.
>1. a stale translation in TLB, or a dirty cache line remnant from earlier boot stages. If this is the case, it would need invalidating TLB and/or caches on BL entry.
>2. the empty table ptr given by xlat_table_get_empty is pointing nowhere sensible because of this specific platform layout
>There are multiple calls to xlat_clean_dcache_range in this file, do you confirm the crash happen within xlat_tables_map_region?
Yes.
Basis of saying 'yes' is: if this function is commented, the BL2 comes up successfully.
Flow in the code base is :
mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx ->
xlat_tables_map_region-> xlat_table_get_empty //....issue is seen.
>Can you try one or both statements below after the call to xlat_table_get_empty (and uncomment calls to clean_dcache_range):
>
> inv_dcache_range((uintptr_t)subtable, XLAT_TABLE_SIZE);
>
> xlat_arch_tlbi_va((uintptr_t)subtable, ctx->xlat_regime);
> xlat_arch_tlbi_va_sync();
mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx ->
xlat_tables_map_region-> xlat_table_get_empty-> xlat_arch_tlbi_va //issue is resolved.
The root cause of this issue is race condition.
Please correct me if I am wrong.
Another observation:
mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx (Putting console debug logs in this function)->
xlat_tables_map_region-> xlat_table_get_empty //issue is resolved.
Please share your view for this observation as well.
Regards,
Olivier.
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pankaj Gupta via TF-A
Sent: 05 February 2020 11:45
To: tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] Issue with addition of NXP Platform support on TFA v2.2
Hi,
In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()".
The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()".
Due to this addition, my earlier* working platform on TFAv1.5, is hanging here.
If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well.
Code snippet:
static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size) {
if (is_dcache_enabled())
clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2
}
Please share your views on what could I be missing here.
Thanks.
Regards
Pankaj
*Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit.
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
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 Pankaj,
Can you pls provide a bit more background:
Which boot stage (BL1/BL2/BL31...) get affected?
Is there any crash report to console?
Is this an aarch64/or aarch32 platform?
There can be different root causes to this e.g.
1. a stale translation in TLB, or a dirty cache line remnant from earlier boot stages. If this is the case, it would need invalidating TLB and/or caches on BL entry.
2. the empty table ptr given by xlat_table_get_empty is pointing nowhere sensible because of this specific platform layout
There are multiple calls to xlat_clean_dcache_range in this file, do you confirm the crash happen within xlat_tables_map_region?
Can you try one or both statements below after the call to xlat_table_get_empty (and uncomment calls to clean_dcache_range):
inv_dcache_range((uintptr_t)subtable, XLAT_TABLE_SIZE);
xlat_arch_tlbi_va((uintptr_t)subtable, ctx->xlat_regime);
xlat_arch_tlbi_va_sync();
Regards,
Olivier.
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pankaj Gupta via TF-A
Sent: 05 February 2020 11:45
To: tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] Issue with addition of NXP Platform support on TFA v2.2
Hi,
In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()".
The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()".
Due to this addition, my earlier* working platform on TFAv1.5, is hanging here.
If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well.
Code snippet:
static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size) {
if (is_dcache_enabled())
clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2
}
Please share your views on what could I be missing here.
Thanks.
Regards
Pankaj
*Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit.
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Fathi,
Thanks for the below write-up, this is really great news!
> Note: this is in silent mode (links to the build job are currently disabled,
> and will be re-enableb today).
Please go ahead in re-enabling those jobs, so that people can see the results of the build jobs (while we work on propagating back to Gerrit also the results of the LAVA boot jobs).
Thanks
Matteo
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Fathi
> Boudra via TF-A
> Sent: 05 February 2020 12:45
> To: TF-A(a)lists.trustedfirmware.org
> Cc: Ryan Arnold <ryan.arnold(a)linaro.org>
> Subject: [TF-A] CI status update - end to end boot testing on Juno
>
> Hi,
>
> The end-to-end testing prototype is now completed and enabled.
> This encompases an end-to-end testing pipeline whereby TF-A code
> submission to gerrit results in a TF build (based on the code submission)
> being injected into a file system (recovery image) and booted on a Juno
> device in the Linaro TF LAVA instance with the results of the boot test
> available in the LAVA instance.
>
> Here's the explanation of the CI pipeline:
> 1. Trigger - capture gerrit events:
> https://ci.trustedfirmware.org/job/trigger-tf-a-builder/
> All changes made to the trusted-firmware A repository are captured by
> the trigger event and result in a build.
> e.g., triggering commit:
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3100
> Note: this is in silent mode (links to the build job are currently disabled,
> and will be re-enableb today).
> 2. Build Binary Artifacts - Binary artifacts built via:
> https://ci.trustedfirmware.org/job/tf-a-builder/
> e.g., https://ci.trustedfirmware.org/job/tf-a-builder/631/
> (with a link to the accompanying LAVA job and a link to the trigger job in
> gerrit) 3. Recovery/Flash submission to LAVA - Used to flash the binary to the
> board:
> https://ci.trustedfirmware.org/job/post-build-lava/
> 4. LAVA tests results
> e.g., Specific example of the template applied to a specific build
> (631 above)
> https://tf.validation.linaro.org/scheduler/job/895/definition
> Results: https://tf.validation.linaro.org/results/895
> Link to all jobs: https://tf.validation.linaro.org/scheduler/alljobs
>
> Some additional information:
> * tf-a-ci-scripts git repository has been set up and contains the CI scripts for
> TF-A.
> https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/
> * tf-a-job-configs git repository has been set up and contains the Jenkins jobs
> configurations automatically deployed on https://ci.trustedfirmware.org
> Jenkins instance.
> https://git.trustedfirmware.org/ci/tf-a-job-configs.git/
>
> Cheers,
> --
> Fathi Boudra
> Linaro.org | Open source software for ARM SoCs
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()".
The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()".
Due to this addition, my earlier* working platform on TFAv1.5, is hanging here.
If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well.
Code snippet:
static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size)
{
if (is_dcache_enabled())
clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2
}
Please share your views on what could I be missing here.
Thanks.
Regards
Pankaj
*Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit.