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

IMXRT11XX ARM PLL not always valid #69316

Open
jman168 opened this issue Feb 22, 2024 · 4 comments
Open

IMXRT11XX ARM PLL not always valid #69316

jman168 opened this issue Feb 22, 2024 · 4 comments
Assignees
Labels
Enhancement Changes/Updates/Additions to existing features platform: NXP NXP

Comments

@jman168
Copy link

jman168 commented Feb 22, 2024

Describe the bug
In the soc_rt11xx.c file the ARM PLL is set to 984MHz which for the MIMXRT1176DVMAA in the NXP EVK is fine, however for the other parts such as the MIMXRT1176AVM8A they only support a core clock of up to 800Mhz and will not function properly if above this. Currently there is no way to set this clock without editing the soc_rt11xx.c file to my knowledge.

To Reproduce
Compile a program for rt1176 and upload to a bard with a MIMXRT1176AVM8A. Specifically in my case the enet1g peripheral would not work unless the core clock was set to ~700Mhz.

Expected behavior
It should work just as it does on the NXP EVK with a MIMXRT1176DVMAA.

Impact
If the clock is not fixed in some way peripherals do not work as expected and the processor is technically operating in unqualified conditions.

Logs and console output
Not really applicable here, all I can say is if the clock isn't set right it doesn't work. It will boot and seem to work fine but weird things won't work such as Ethernet getting random errors.

This is the piece of code in question which is causing the issue. You can see that I changed the loopDivider to 116 which results in a ARM PLL of 696Mhz fixing the issue.
Screenshot from 2024-02-22 00-22-59

Environment (please complete the following information):

  • OS: Linux
  • Zephyr SDK
  • Commit SHA: b6d9b3f

note: Edited MIMXRT1176AVM8A from MIMXRT1171AVM8A (I accidentally typed a 1 instead of a six).

@jman168 jman168 added the bug The issue is a bug, or the PR is fixing a bug label Feb 22, 2024
@nashif nashif added the priority: low Low impact/importance bug label Feb 27, 2024
@decsny
Copy link
Member

decsny commented Mar 6, 2024

Technically, the RT1171 is not supported in the upstream. However, this is because we generally expect it to be somewhat easy to port to the other SOCs in the series if we include the superset part such as RT1176 in upstream. Therefore, this is still an issue I think is important, but I believe the fix is to rework the clocking of the parts to be able to configure things like the PLLs in the devicetree. Which, we (NXP) are actively working on internally, a scheme for describing our clock trees in DT. When that is ready, it will be able to address your issue because someone porting the RT1171 can now describe the PLL in DT.

There is currently no timeline for the clock description rework but it is recognized by our team as one of the more important broader things to add to the NXP enablement in zephyr.

So, since RT1171 is technically not supported in the upstream, and I believe the solution for your problem is the clock tree description in DT which is an enhancement we are working on, I'm going to convert this to an enhancement label, so it does not add to the bug count for release purposes.

If you would like to have support to configure this sooner than the clocking rework, I advise you to submit a PR with new kconfigs in the SOC definition folder to expand control over the configuration of the arm pll.

@decsny decsny added Enhancement Changes/Updates/Additions to existing features and removed bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug labels Mar 6, 2024
@jman168
Copy link
Author

jman168 commented Mar 7, 2024

@decsny, I just realized I made a typo, my bad, I meant the MIMXRT1176AVM8A. The issue I was having was that when clocking the CM7 at 1Ghz Ethernet would start behaving strangely (missing all but a few packets and the packets it did get were just gibberish). However I could upload this same program to the MIMXRT1176DVMAA (EVK) and it would work fine. If I clocked the MIMXRT1176AVM8A to 700Mhz instead however everything worked great. Technically the MIMXRT1176DVMAA and MIMXRT1176AVM8A support different max clock rates (the MIMXRT1176AVM8A does not support 1Ghz) so I suspect this is the issue.

I do think however that a way to define clock trees in device tree is the right solution to this regardless. But I thought just for the record I'd correct myself to what I meant. In the meantime It might be good to put this in the documentation for the RT1176 support somewhere just in case somebody else tries something like this? It took me way longer than I care to admit to fix this issue. From all the Zephyr documentation I've read it would seem as though all RT1176 variants are fully supported, but it seems as thought this is not fully true, granted I might have just missed something in which case that's on me.

@decsny
Copy link
Member

decsny commented Mar 7, 2024

cc @DerekSnell

@DerekSnell
Copy link
Contributor

Hi @jman168 ,
Declan already shared NXP is working on a long-term goal to have clocks configured by devicetree. But in the short-term, there is another solution to make this easier for you to modify. Declan listed this enhancement Make NXP SOC clock init functions weak. If clock_init() were declared as weak, then your app or custom board can easily override the clock config.

That would be a simple Pull Request if you want to contribute that change. Best regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Changes/Updates/Additions to existing features platform: NXP NXP
Projects
None yet
Development

No branches or pull requests

6 participants