search

ARM-software / tf-issues

Issue tracking for the ARM Trusted Firmware project
37 stars 16 forks source link

how about adding OTA service in TF-A #682

Closed JiafeiPan closed 5 years ago

JiafeiPan commented 5 years ago

Anyone has any ideas, thanks.

mcarlini commented 5 years ago

Hi Jiafei,

Can you please elaborate a bit more your request and the use-case you have in mind?

If you are referring to an OverTheAir update of TF-A BL images, how this will affect the usual TF-A boot flow and where the binary blobs would come from (a normal world OS service? a Trusted Service?)?

We are internally evaluating some OS-initiated Firmware update enhancements to the existing FWU service implemented in TF-A as described by TBBR (https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-update.rst), so it would be good to understand any specific requirements you may have.

Thanks Matteo

JiafeiPan commented 5 years ago

Hi, @mcarlini

Thanks for your comments.

Per my understand, FWU in TF-A is used to load, authenticate and execute BL2U and NS_BL2U, then update fip firmware image by using BL2U and NS_BL2U, right?, so here are my questions: 1.Is there any reference code for NS images? 2.We can use this process to update BL1, BL2 and BL31, right? is there any process to make sure the system can be recovered in case of new images fails, for example, recover to previous images? 3.Can we use this process to update non secure world images, for example Linux kernel and root FS image?

What I want to do is unify process for multiple platform to OverTheAir to update system images, at lease support to update uboot, kernel, FS images, of course it will better we can also update TF-A images. And OTA process can recover the systems in case of update failure.

I would like to have more your comments and suggestion, thanks again.

Best Regards, Jiafei.

JiafeiPan commented 5 years ago

Hi, @mcarlini

I have another question, now FWU is supported by BL1, but on some platform, there is no BL1, and even there is no BL2, so how about moving FWU to BL31, or define FWU as a standard service just like PSCI?

pangupta commented 5 years ago

Hi @JiafeiPan,

I am in agreement with you to move FWU to BL31, as it is the resident software which is running in EL3 to be ready to facilitate OTA.

JiafeiPan commented 5 years ago

Hi, @panguapta,

Thanks for your comments, if OTA is a standard service in BL31, we will not need BL31U any more, right?

Best Regards, Jiafei.

soby-mathew commented 5 years ago

Hi @JiafeiPan , We were busy with the release and I didn't see you raise further queries to this issue. I will try to answer the questions you ask

1.Is there any reference code for NS images?

Yes, there is. If you see TF-A-Tests git repo : https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/fwu

You will find NS-BL1U and BL-BL2U over there.

2.We can use this process to update BL1, BL2 and BL31, right? is there any process to make sure the system can be recovered in case of new images fails, for example, recover to previous images?

The firmware update as implemented in TF-A is actually recovery mechanism. Basically, if the authentication of a BL image fails, it initiates the update mechanism which then restores a backup fip as configured by the platform. See here https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl1/bl1_main.c#L136

3.Can we use this process to update non secure world images, for example Linux kernel and root FS image?

As it is implemented currently, the FWU only takes care of updating the FIP which contains BL1, BL2, BL31, BL32 & BL33.

The kernel, rootFS update mechanisms are defined by the BL33 (UEFI/Uboot).

The answers above may still not be sufficient for you make a design decision. Please feel free to ask more questions on this.

soby-mathew commented 5 years ago

Please ask question on TF-A mailing list if required.