In our IMX8QXP M4 core application we are using #AF28, #AH30 pads for M40__UART0 function use case.
The current SCU FW does not allow to change MUX setting for these particular pins.
There was an reply from NXP regarding this issue:
in board.c (in the SCFW porting kit)
the SCFW is marking them as owned by
the SCU by default: (void)
rm_set_pad_movable(pt_sc,
SC_P_SCU_GPIO0_00, SC_P_SCU_GPIO0_01,
SC_FALSE);
So you will have to remove/comment the
highlighted part above on the SCFW,
build it and build your image with the
modified SCFW and that should allow
you to configure those pads.
Is there IMX8 Colibri SCFW Porting Kit available somewhere so I can make the changes and rebuild SCFW?
I’m afraid currently there is no SCU FW porting kit or other SCU source code available from NXP for any of the i.MX8 SoCs, hence I don’t see a way to build a customized version of the SCU firmware.
The Colibri iMX8X and NXP’s MEK are HW wise quite different. It will for sure not work to build/use a MEK SCFW on a Colibri. Also A0 and B0 silicon require a different SCFW. (And a lot of other stuff has changed in regards to booting too…)
At least in the current state of the project we do not want to release the SCFW sources.
I rebuilt the SCFW in the version used for the toradex_rocko-4.9.123-2.3.0_8mm_ga_bringup image for Colibri iMX8QXP 2GB WB IT v1.0 A, but with DEBUG_UART commented. With this change the two pins for the M4 UART are made movable.
Could you try to rebuild the image with the SCFW replaced in the meta-fsl-bsp-release layer?
imx/meta-bsp/recipes-bsp/imx-sc-firmware/files/colibri-imx8qxp-scfw-tcm.bin
Hello Max,
updated SCFW firmware binary (colibri-imx8qxp-scfw-tcm.bin) works for us. M4 core can use IMX8 #AF28, #AH30 pads (SODIMM 144,146 pins) for M40__UART0.
As we are moving into Colibri iMX8QXP V1.0B revision we might need the same change for sumo branch.
Thanks for the feedback. Great that it works for you.
It will be trivial to rebuild with the same change for V1.0B. Should we not have an image with this setting as standard by the time you get a V1.0B module please speak up here and I will provide a new binary.
I want to confirm we need a similar change for “Colibri iMX8QXP V1.0B revision”.
This is Colibri SOM UART ports assignment in our custom Carrier Board:
SODIMM 144/146: M4 core Debug UART. SCFW should allow to configure it (“movable”).
SODIMM 33/35: A35 core Debug UART. SCFW should allow to configure it (“movable”).
SODIMM 36/38: SCU Debug UART. SCFW can use it for debug purpose.
It would be nice to have SCU Debug features enabled (”DEBUG_UART“) since it can deliver some valuable information (security, resource management, timing, etc.).
Please let me know if it possible to release the pre-build SCFW image
Here you are. The same change of not using the SCFW debug UART, but for the b0 silicon version.
Note that SODIMM 36/38 is used as UART_B in the Colibri standard, so one cannot grab that for something else by default. With the above change the UARTS on SODIMM 144/146, 33/35, 36/38 are all movable and can thus be used either from the A35 or M4.
Hi Max,
I was busy with our own carrier board bring up (“Colibri iMX8QXP V1.0B revision” based). The updated SCFW works great: M4 core can use SODIMM 144/146 pins for Debug UART.
I think I saw SCFW was printing some boot timing information in the original variant. It would be good to have it. I am wondering if it is still possible to have SCFW DEBUG_UART enabled, but running over SODIMM 36/38 (AB32, AA29) pins?
I am not sure how to make this change request more official, so you can gain some credit. Our company ordered 100+ Colibri iMX8QXP SOMs. I can provide Toradex Sales Engineer contact if needed.
I am wondering if it is still possible to have SCFW DEBUG_UART enabled, but running over SODIMM 36/38 (AB32, AA29) pins?
No, that is not easily possible. The SCFW will reserve the pins for its own use in that case and the M4 will then get back an error when requesting them. Of course one could output some inital stuff and then unregister again but that is not something foreseen in the SW design…
On top of that I believe it would be a bad design decision.
Likely the M4 uses the UART not for log output but with an attached device (Variable speed drive, GPS, sensors…). If such a device that does not react kindly to arbitrary communication we’re in a big mess.
