AI-64

giuliomoro

AndyCap I got it to the point it hung the board!

"promising"! Did you change any addresses in it?

AndyCap

I did but probably incorrectly, just a minute I will power it up and have a look at the changes.

AndyCap

I would not trust any of this in any way:

root@AI64:~/development/prudebug# git diff
diff --git a/prudbg.c b/prudbg.c
index c0477fe..ba98f66 100644
--- a/prudbg.c
+++ b/prudbg.c
@@ -144,6 +144,25 @@ struct pdb_tag {
                        }
                }
        },
+       {
+               .processor      = "XJ721E",
+               .short_name     = "XJ721E",
+               .pruss_address  = 0xb00a000,
+               .pruss_len      = 0x80000,
+               .num_of_pruss   = 2,
+               .offsets        = {
+                       {
+                               .pruss_inst     = 0xD000,
+                               .pruss_data     = 0x0000,
+                               .pruss_ctrl     = 0x8800
+                       },
+                       {
+                               .pruss_inst     = 0xE000,
+                               .pruss_data     = 0x0800,
+                               .pruss_ctrl     = 0x9000
+                       }
+               }
+       },
        {       // end marker
                .processor      = "NONE",
                .short_name     = "NONE",
diff --git a/prudbg.h b/prudbg.h
index ab4d03f..e52679f 100644
--- a/prudbg.h
+++ b/prudbg.h
@@ -19,6 +19,7 @@
 #define AM335x                 1
 #define AM57x1                 2
 #define AM57x2                 3
+#define XJ721E      4
 
 // general settings
 #define MAX_CMD_LEN            25

giuliomoro

AndyCap I would not trust any of this in any way:

Thanks, very useful

AndyCap + .pruss_address = 0xb00a000,

almost: https://github.com/giuliomoro/prudebug/commit/91575afcc59683d92eb4649037d4725cf8160b44#diff-e70ae9717707fb6756c0bc71b3e1446eff37ce168243ae764d7955d3e7ef996fR150

🙂

giuliomoro

giuliomoro SCHED_FIFO doesn't work. Not even something as simple as sudo chrt --fifo 50 python3

This is now fixed on Linux BeagleBone 5.10.120-ti-arm64-r53 #1bullseye SMP Tue Jul 12 19:27:52 UTC 2022 aarch64 GNU/Linux

Usual apt-get update && apt-get upgrade and rebuilding dtbs after reboot and rebooting again will get you that.

AndyCap

Apart from the major error 🙂

So how far have you got with all this?

I'm spending a bit of time struggling with how to easily get stuff running on the C66 and C7, the available TI stuff/documentation to me is beyond hopelessness.

It seems the only real example is the Vision apps stuff which is Byzantine to say the least.

I'm, guessing if you are a bulk customer you must get access to another level, for the hobby bumbler though it is all a bit undocumented (on the linux side).

giuliomoro

AndyCap Maybe you are missing the pinmux in the dts?

I have your changes from here and I understand those are pins for PRU1 on PRUSS0. I will try your example next.

AndyCap So how far have you got with all this?

Pretty far ... I have good feelings that all is good except getting the mcasp I/Os to actually work ... I think I am talking to the McASP peripheral just right from the PRU, because it's not hanging and it is waiting for a valid clock to come in. Given how I couldn't get P9.25 to do what it was supposed to, I hooked up a BBB as an external 12MHz clock source for the codec's MCLK (that's what I wanted the PRU GPOs for). In response the codec is generating the correct BCLK and WCLK but the McASP seems not to be receiving any of that and when I set the McASP to generate the frameclock from the codec's bitclock, it doesn't do that either. There may be some internal pinmuxing in the mcasp that needs further setting ... I'll check the McASP section in the manual.

giuliomoro

AndyCap I have managed to run stuff on the PRUs, today I am going to look at getting some gpio output from one of them...

did this work for you? I got code running on it but I don't get any GPO from PRUs today (though I can verify via prudebug that my loop writing to R30 is running). Yesterday I did get some output (I think), though, so I am confused what I am doing wrong today.

giuliomoro

AndyCap So I took the cape off and it starts working, can I probe through the headers on the cape or will that not work?

All the P8 pins are straight through with nothing connected to them on the cape (except P8.24), there should be no reason why the cape affects their behaviour, except the different form factor of the header that will behave slightly differently to your probe's tip. To ensure I have a reliable connection, I am using a pin-to-socket jumper wire, with the wire's pin into the header and the probe stuck into the wire's socket.

giuliomoro got code running on it but I don't get any GPO from PRUs today (though I can verify via prudebug that my loop writing to R30 is running). Yesterday I did get some output (I think), though, so I am confused what I am doing wrong today.

Turns out I had an error in the dtb which made the whole of pinmux_dummy fail to load. Confusingly, I2C5 on P9.19/P9.20 was still working (because that's handled through the driver).

OK so I can get some PRU gpios, that's relieving. Now to see whether this fixes all my mcasp issues.

AndyCap

Yep I got Pru gpio output: https://forum.beagleboard.org/t/ai64-pru-basics-very

Maybe you are missing the pinmux in the dts?

AndyCap

Ok, I also tried and as you say no pru gpio output (using probe on cape header), I then tried the different prus incase something had got shifted around no success.

So I took the cape off and it starts working, can I probe through the headers on the cape or will that not work?

giuliomoro

AndyCap So this is weird, I'm not getting any pru action on:

those are PRUSS0 - PRU1 pins, so you'd need to run the code on that device instead of PRUSS0-PRU0

giuliomoro . Now to see whether this fixes all my mcasp issues.

it doesn't. :-( I'll try a device tree for ALSA to see if that makes it work and then work backwards from there.

AndyCap

Good news about the dtb.

Weird about my probing, I will attach the cape again and attach the oscilloscope instead of the logic analyser, maybe there is a voltage drop that I need to adjust for...

AndyCap

So this is weird, I'm not getting any pru action on:

&P8_41_pruout_pin		/* Bela Multiplexer PRU */
&P8_42_pruout_pin		/* Bela Multiplexer PRU */
&P8_43_pruout_pin		/* Bela Multiplexer PRU */
&P8_44_pruout_pin		/* Bela Multiplexer PRU */
&P8_45_pruout_pin		/* Bela Multiplexer PRU */
&P8_46_pruout_pin		/* Bela Multiplexer PRU */

Everything is fine on P8_16 if I use that

&P8_16_pruout_pin

if I remap P8_45 to gpio, that works.

But I get nothing from them using pruout and R30.

Did you have to disable anything else to get those pins working with the pru?

AndyCap

giuliomoro those are PRUSS0 - PRU1 pins, so you'd need to run the code on that device instead of PRUSS0-PRU0

Ah, that will be why they are not working then!

giuliomoro it doesn't. :-( I'll try a device tree for ALSA to see if that makes it work and then work backwards from there.

Good luck.

giuliomoro

btw I am stuck waiting for proper documentation or help from TI

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1119157/tda4vm-mcasp-configuration-on-linux-via-device-tree

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1119141/tda4vm-issues-with-mcasp-documentation

AndyCap

Thanks for the info, 6 days and counting!

giuliomoro

haven't gotten a real answer yet and possibly never will.

I was told

Will be hard for TI to respond to McASP related questions. Anything McASP related comes from back when Infotainment systems were the main market for Jacinto devices.
As a disclaimer, I am not a McASP expert, so all I can do is link the relevant dts file and documentation I have found for the EVM boards from TI
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts?h=ti-linux-5.10.y
https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/08_02_00_03/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Audio.html

I had previously spotted this sound in the dts:

	sound0: sound@0 {
		compatible = "ti,j721e-cpb-audio";
		model = "j721e-cpb";

		ti,cpb-mcasp = <&mcasp10>;
		ti,cpb-codec = <&pcm3168a_1>;

		clocks = <&k3_clks 184 1>,
			 <&k3_clks 184 2>, <&k3_clks 184 4>,
			 <&k3_clks 157 371>,
			 <&k3_clks 157 400>, <&k3_clks 157 401>;
		clock-names = "cpb-mcasp-auxclk",
			      "cpb-mcasp-auxclk-48000", "cpb-mcasp-auxclk-44100",
			      "cpb-codec-scki",
			      "cpb-codec-scki-48000", "cpb-codec-scki-44100";
	};

I guess those clocks may tell us something about what clocks the mcasp is using, but I find it ridiculous that one has to read kernel source because the technical reference manual is lacking information that it makes reference to ...

jarm

Hi giuliomoro @AndyCap, any news on this topic?

AndyCap

Yep, not looking good.

I had also found TI stuff from Jason Kridner on one of the chats before about this and directly asked the question here: https://forum.beagleboard.org/t/ai64-mcasp/32395 but didn't get an answer.

For me the AI64 has gone the same way as the AI32, not enough info of how to get anything to work, at least it doesn't melt though!

There may be all these cores and functionality but how do you use it, the documentation is woeful. Even CCS doesn't seem to know much about this processor, I'm think you have to be a mass purchaser to get any help.

« Previous Page Next Page »