Following PFE QNX Driver Integration manual (Rev. 2.0 19 October 2022) it gives the following information:
Without that patch the QNX image does not load at all, I do not understand why this patch is required and it seems out of place.
Any insight would be appreciated.
Hardware information
Board: s32g274ardb2 (Rev. D)
Revision code: SCH-47440 REV D3 / 700-47440 REV D1
QNX Board Support Package
QNX Neutrino for: BSP_nxp-s32g-evb_br-710_be-710
SVN Revision Number: 941162
Build Number: 31
S32G2 Linux BSP
U-Boot Git tag: bsp34.0-2020.04
Linux kernel (DTB) Git tag: bsp34.0-5.4-rt
Hi,
We might not understand your question, but as stated in the document:
"This change avoids resetting of the already configured clocks".
Meaning, if the patch is not applied, the clocks configuration will be reset.
Please, let us know.
Hi,
Sorry for not stating this before.
We have been using Rev.C boards with BSP 28. And we discovered the issue trying to boot QNX with U-Boot (tags/bsp28.0-2020.04) on Rev.D boards.
Assuming that BSP 28 does not support Rev.D we tried BSP 34.
We also tried applying the same patch to BSP 28 and QNX is working so far on both board revisions.
Can we get more information about what changed between revisions making this patch necessary?
Thanks for your help.
Hi,
Thank you for the information.
Could you provide which PFE QNX Driver version are you working with?
We are seeing that v1.2.0 or lower does not state this modification, making the first appearance in v1.3.0.
Can you confirm if the C board was using a v1.2.0 or lower PFE-QNX driver?
We are not seeing a difference between the chip in rev C and rev D, for which we cannot say if the rev of the board is relevant to this topic.
Please, let us know.
Hi,
We have been using PFE driver version 1.2.0 on Rev.C boards. Which also works on Rev.D boards without problems so far (after applying the patch to U-Boot in order to boot the QNX image).
But I do not see why this is relevant.
We want to know in the end is if it is safe to apply this patch to U-Boot BSP-28, since migrating to BSP-32 at this moment will have a significant impact to our activities.
Thanks for your support.
Hi,
Thanks for your feedback. Our reason to ask was to understand the set-up you are using at this moment.
As you implied before, applying the patch did work on both boards revision using BSP28, for which we might recommend applying it. More information regarding why the patch is needed (aside from the note added on the integration manual) it is not provided.
We recommend opening a ticket on the NXP online service, to see if more information can be provided through that channel.
Still, we will try to push to understand if more information is provided.
Please, let us know.