J784S4XEVM: Changes in SDK 10 Linux affecting trace

Please be aware, that assigned TI resource is out of office for the rest of this week, a delay in response may occur.

Regards,

kb

Hello,

It seems something has either mux'ed away the external trace clock or shut it off in the code flow you are using.  You should attach and verify the settings of the clock and pins.

Use the addresses found in the external trace file:  /cfs-file/__key/communityserver-discussions-components-files/791/J784S4_5F00_offchip_5F00_trace.cmm for example the trace clock source is here: ZAXI:0x68208C and the trace clock itself is here: ZAXI:0x0011C0C8.

Linux in some boot flows might use a DT or DT overlay which sets up to support an external daughter card.   In flows which provisioning for that board it will change the mux away from your control. 

Taking back the SOC level mux is easy as long as nothing is 're-asking' for it.  What is a little harder to deal with on the EVM is there is a GPIO expander which has a hardware 'FET MUX' which routes the physical signals to a expansion header instead of to the trace header.  to fix this you need to alter the DT which is controlling the FET mux.  If you find the below you can fix it.  The DT or an override can make it confusing to know if you changed the correct one.  What I do here, is use TRACE32's Linux awareness and you can see in the in-memory DT which is in use.   This will let you check to see if your fix was in the right place.  You can rebuild the DTS and place the file in the filesystem or you can hack and probably binary edit it before it gets consumed.  I used to hit this issue when using vision sdk packages.  Of course its possible some driver at run time made a change with a direct I2C write to the expander (which you could also do via the command line) but that would be cheating as this shared resource instance should be coordinated through DT.

                exp2: gpio@22 {

                                compatible = "ti,tca6424";

                                reg = <0x22>;

                                gpio-controller;

                                #gpio-cells = <2>;

                                p09 {

                                                /* P11 - MCASP/TRACE_MUX_S0 */

                                                gpio-hog;

                                                gpios = <9 GPIO_ACTIVE_HIGH>;

                                                output-low;

                                                line-name = "MCASP/TRACE_MUX_S0";

                                };

Hello Lucas,

Glad that you are now able to use offchip trace again with DT changes. The visibility which offchip trace provides can transform otherwise nearly impossible issues into something tractable. You might look at the ~somewhat recent CTL application note.  It provides a good way to analyzer big trace beyond the default valuable reports https://www2.lauterbach.com/pdf/app_ctl.pdf .

As to your question about documentation.  I am not sure as I've not worked recently in that area.  Can you provide a link to what looks suspicious?

Hello Richard,

In your first response, you wrote
/* P11 - MCASP/TRACE_MUX_S0 */
gpio-hog;
gpios = <9 GPIO_ACTIVE_HIGH>;

Where are P11 and 9 coming from? Why are they off by 2?

Also, the lines I removed from k3-j784s4-evm.dts were the following:

		p13-hog {
			/* P13 - CANUART_MUX_SEL0 */
			gpio-hog;
			gpios = <13 GPIO_ACTIVE_HIGH>;
			output-high;
			line-name = "CANUART_MUX_SEL0";
		};

		p15-hog {
			/* P15 - CANUART_MUX1_SEL1 */
			gpio-hog;
			gpios = <15 GPIO_ACTIVE_HIGH>;
			output-high;
			line-name = "CANUART_MUX1_SEL1";
		};

Why 13 and 15, when in the schematics (PROC141E2(001)_SCH.pdf) they are 15 and 17?

Regards,

Lucas

Hello Lucas,

Right, in my message I talked about the need for a DT change to P11 (TRACE_MUX_S0) to select trace at the MUX.  There are multiple J7 EVM boards which have trace and run Linux.  The fix I described was cut and pasted from my notes for a different J7 EVM where I ran into the same issue. All the J7 boards I've used with external trace use the DIP switch + GPIO expander pattern however the expander assignment is not exactly the same across boards.  Probably it would have been slightly smoother if I noted that detail with the example but happily you were able to retarget it for your EVM.  Thanks for feeding back the details.