-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
drivers: clock_control: nrf54h: obtain oscillator parameters from BICR #81122
base: main
Are you sure you want to change the base?
Conversation
c4525dc
to
dded562
Compare
9654417
to
b92de2c
Compare
The following west manifest projects have changed revision in this Pull Request:
✅ All manifest checks OK Note: This message is automatically posted and updated by the Manifest GitHub Action. |
Add binding for the Nordic nRF BICR memory. Signed-off-by: Gerard Marull-Paretas <[email protected]>
BICR (Board Information Configuration Registers) are located within the application UICR region (ref. MRAM mapping, table 38). Signed-off-by: Gerard Marull-Paretas <[email protected]>
The real, applicable and trusted values are the ones flashed into BICR. So, drop DT properties that replicate BICR and use runtime reads to BICR instead. Signed-off-by: Gerard Marull-Paretas <[email protected]>
Add a utility function to obtain LFOSC accuracy in PPM from BICR. Signed-off-by: Gerard Marull-Paretas <[email protected]>
The real, applicable and trusted values are the ones flashed into BICR. So, drop DT properties that replicate BICR and use runtime reads to BICR instead. Signed-off-by: Gerard Marull-Paretas <[email protected]>
The real, applicable and trusted values are the ones flashed into BICR. So, drop DT properties that replicate BICR and use runtime reads to BICR instead. Signed-off-by: Gerard Marull-Paretas <[email protected]>
DNM: will likely require reflashing BICR as some parameters were never written there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It pains me to see properties related to specific peripheral instances not be part of the peripherals descriptions themselves, but that is actually how this platform works...
BICR should be taken as the source of truth for certain oscillator-related parameters, such as:
Currently, these were replicated in Devicetree, making it possible to have a non-fully functional system due to mismatches.