Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32F7 update drivers version to CUBE V1.15.0 #11711

Merged

Conversation

jeromecoutant
Copy link
Collaborator

Description

ST Cube drivers version is updated from V1.10.0 to V1.15.0,
which is the latest official version from:
https://www.st.com/en/embedded-software/stm32cubef7.html

ST CI tests OK

Pull request type

[ ] Fix
[ ] Refactor
[x] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

Release Notes

@ARMmbed/team-st-mcd

@ciarmcom
Copy link
Member

@jeromecoutant, thank you for your changes.
@ARMmbed/mbed-os-maintainers @ARMmbed/mbed-os-crypto please review.

@0xc0170
Copy link
Contributor

0xc0170 commented Oct 21, 2019

What is changed in 4c6031b ?
Does it need a review @ARMmbed/mbed-os-crypto team?

@jeromecoutant
Copy link
Collaborator Author

What is changed in 4c6031b ?
Does it need a review @ARMmbed/mbed-os-crypto team?

ST CRYPTO HAL API has changed for STM32F7 family,
so I had to differentiate functions per family in order to not break other targets.

See #10422

@0xc0170
Copy link
Contributor

0xc0170 commented Oct 21, 2019

👍

This is pending crypto team review

@@ -0,0 +1,364 @@
/*
* Hardware aes implementation for STM32F4 STM32F7 and STM32L4 families
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would a newer version of this aes_alt.c file work for both TARGET_STM32F4 and TARGET_STM32L4? It seems silly to have two different nearly identical copies of the same file in different places in the Mbed OS tree. I'd prefer we use ifdefs to handle the minor differences between these targets as needed. Same goes for other files added by this PR that are nearly the same as existing files.

Also, please ensure it is very clear which version of the ST SDK these files are from, for easier maintenance.

@@ -0,0 +1,503 @@
/**
* \file aes_alt.h
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is very similar to features/mbedtls/targets/TARGET_STM/TARGET_STM32L4/aes_alt.h. It looks like L4 is just an older copy of aes.h from Mbed TLS (XTS is missing, for example, so the file is quite old). Can we move that L4 file so it is picked up and used for both targets instead of adding duplication?

@@ -0,0 +1,307 @@
/*
* aes_alt.h AES block cipher
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is identical to features/mbedtls/targets/TARGET_STM/TARGET_STM32F4/aes_alt.h. Can you think of a way to use a single file for both targets? That'd be far more maintainable. Thanks.


/* Process unlocked */
__HAL_UNLOCK(hcryp);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to __HAL_UNLOCK(hcryp); when status != HAL_OK? If not, why not?

Same goes HAL_CRYP_AESCTR_Decrypt() and other similar functions.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ST_INTERNAL_REF 75115


default:
hcryp->ErrorCode |= HAL_CRYP_ERROR_NOT_SUPPORTED;
return HAL_ERROR;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to __HAL_UNLOCK(hcryp); before returning here?

@0xc0170
Copy link
Contributor

0xc0170 commented Oct 25, 2019

This also will require rebase to resolve a conflict

@jeromecoutant jeromecoutant force-pushed the PULL_REQUEST_CUBE_UPDATE_F7_V1.15.0 branch from ed62c8c to a246164 Compare October 31, 2019 16:52
@jeromecoutant
Copy link
Collaborator Author

@Patater
Thanks for the review for mbedtls part.
I am waiting for some internal feedback for this...
So as current mbedtls tests are OK with this current version, are you OK to approve this PR?
I promise to push updates soon :-)

@0xc0170
Rebase and conflicts solved

@0xc0170 0xc0170 requested a review from Patater November 4, 2019 14:52
@0xc0170
Copy link
Contributor

0xc0170 commented Nov 4, 2019

Restarted CI

@mbed-ci
Copy link

mbed-ci commented Nov 4, 2019

Test run: SUCCESS

Summary: 12 of 12 test jobs passed
Build number : 1
Build artifacts

@0xc0170
Copy link
Contributor

0xc0170 commented Nov 5, 2019

@Patater
Thanks for the review for mbedtls part.
I am waiting for some internal feedback for this...
So as current mbedtls tests are OK with this current version, are you OK to approve this PR?
I promise to push updates soon :-)

@Patater Please review

@Patater
Copy link
Contributor

Patater commented Nov 5, 2019

There are no Mbed TLS tests that do multithreading in Mbed OS, unfortunately, so we can't depend on them to catch these sorts of issues. Passing tests doesn't mean the code is good enough for merge into Mbed OS. The issues found in review need resolution.

@jeromecoutant
Copy link
Collaborator Author

The issues found in review need resolution

I agree, but in a second step.
Issues you pointed are from driver files. You can't bock all other feature :-(

@0xc0170
Copy link
Contributor

0xc0170 commented Nov 5, 2019

Issues you pointed are from driver files. You can't bock all other feature :-(

If that is the case, these requested changes could go into a new issue (I can see internal ticket was pasted here) and this proceed, @Patater ? We are talking about device/stm32f7xx_hal_cryp.c file

@jeromecoutant
Copy link
Collaborator Author

@jeromecoutant
Copy link
Collaborator Author

@Patater I tried to patch the driver file before ST owner feedback.
Please review
Thx

@Patater
Copy link
Contributor

Patater commented Nov 6, 2019

OK, thanks. So, is this still V1.15.0 or is it now V1.15.1?

@jeromecoutant
Copy link
Collaborator Author

OK, thanks. So, is this still V1.15.0 or is it now V1.15.1?

I am not responsible for ST Cube drive delivery :-)

@0xc0170
Copy link
Contributor

0xc0170 commented Nov 7, 2019

CI started

@mbed-ci
Copy link

mbed-ci commented Nov 7, 2019

Test run: SUCCESS

Summary: 12 of 12 test jobs passed
Build number : 2
Build artifacts

@0xc0170 0xc0170 merged commit 383cf19 into ARMmbed:master Nov 7, 2019
@jeromecoutant jeromecoutant deleted the PULL_REQUEST_CUBE_UPDATE_F7_V1.15.0 branch November 7, 2019 11:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants