-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
Comments
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, 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. |
cc @DerekSnell |
Hi @jman168 , That would be a simple Pull Request if you want to contribute that change. Best regards |
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.
Environment (please complete the following information):
note: Edited MIMXRT1176AVM8A from MIMXRT1171AVM8A (I accidentally typed a 1 instead of a six).
The text was updated successfully, but these errors were encountered: