AM3359: PRU device tree configuration

Looking at those files (am33xx.dtsi and am335x-boneblack.dts) is where I started, because there are all those nodes defined and I just wanted to turn them on.

You are right that those are not defining phandles but they are not defining it neither for wkup_m3@100000 which is defined like that:

wkup_m3: wkup_m3@100000 {
  compatible = "ti,am3352-wkup-m3";
  reg = <0x100000 0x4000>,
  <0x180000 0x2000>;
  reg-names = "umem", "dmem";
  ti,hwmods = "wkup_m3";
  ti,pm-firmware = "am335x-pm-firmware.elf";
};

And after decompiling it looks like that:

wkup_m3@100000 {
  compatible = "ti,am3352-wkup-m3";
  reg = <0x100000 0x4000 0x180000 0x2000>;
  reg-names = "umem", "dmem";
  ti,hwmods = "wkup_m3";
  ti,pm-firmware = "am335x-pm-firmware.elf";
  linux,phandle = <0x2b>;
  phandle = <0x2b>;
};

As you see phandles were added during compilation. What is even worst - I didn't intended to set up this node and it's working (when I load kernel module wkup_m3_rproc, it is in /sys/class/remoteproc/ as remoteproc0).

Hello Marek,

I am not clear on what your issue is.

Are you having trouble using remoteproc commands on the TI prebuilt software that is loaded using ti-processor-sdk-linux-am335x-evm.../bin/create-sdcard.sh?

On the prebuilt software, are you having trouble controlling remoteproc through the sysfs interface as shown in Lab 5 of the PRU Hands-on Labs?

Are you having trouble building the Linux kernel using the beaglebone device tree files in the processor SDK?

Is there a different problem?

Regards, 

Nick

Hello Nick,

I'll try to simplify this:

I have 2 setups:

1) BeagleBone Black using debian with capemanager, dtbo overlays and everything provided by BBB support. (everything works fine here)

2) BeagleBone Black using Yocto with meta-ti layer provided by TI. (/sys/class/remoteproc/ remains empty even after loading required modules).

As I wrote at the beginning, my target system is second one, built using Yocto with meta-ti layer, using TI kernel named "processor-sdk-linux-04.02.00" which i fetch from here

git.ti.com/.../processor-sdk-linux

using commit a75d8e93056181d512f6c818e8627bd4554aaf92. 

So I do not have things like create-sdcard.sh script, the capemanager nor the cape itself. What I have is kernel source with devicetrees like am33xx.dtsi, am335x-bone-common.dtsi etc.

As I wrote in first post those 3 questions at the end, you have answered to 1st one about devicetree node - so thats clear now. On the third you said that pinmux should not be a problem. That leaves me with solving mystery of question 2: After compiling the device tree, PRU nodes doesn't have the phandle parameter (which was present in Debian). If I get it right, without phandles system cannot communicate with that hardware. The phandles are not written by hand in any other node, yet they appear in compiled dtb files, so I guess dtc compiler adds them. As phandles does not appear == I'm doing something wrong with pru node's.

If my reasoning is correct the question should be: How should I modify the pruss_soc_bus@4a326000 node (from am33xx.dtsi) and it's subnodes to get pru working on my build?

Regards,

Marek

Hello Marek,

Debian and TI's Yocto distribution have undocumented differences - that's one of the reasons we don't support Debian on these forums. So just because there is a phandle difference between the distributions does not mean that the phandles are the reason remoteproc isn't working.

Instead, I'd suggest downloading the TI Linux Processor SDK 4.02. Once you get PRU working on that platform, then you can compare and contrast that to the Yocto build to debug.

We highly suggest that you do not modify am33xx.dtsi. Instead, make changes to the last dts file that modifies the field you are interested in (eg am335x-bone-common.dtsi, or am335x-boneblack.dts).

Please see "Modify Device Tree Files to Account for PRU Cape" in the PRU Hands-on labs to add device tree information for the cape, since TI does not currently support device tree overlays. Note that PRU_SW_PATH is ti-processor-sdk-linux-.../example-applications/pru-icss-.../ . Labs 4-6 might have some helpful information if you need a refresher in programming and running PRU through CCS or a Linux environment.

Regards, 

Nick

Hi Nick,

Could you possibly hold this topic open for few more days? I've been sick and didn't make much progress... I'm back now and trying your approach now.

Regards,

Marek

Hi again,

After some time trying to compare my build with procesor sdk as you suggested, I tried instead to set up new yocto environment (on morty) and build boneblack poky distro. That was more convenient way for me.

As it worked, I have found some differences in kernel configuration and fixed them, than I swapped the device tree files and that got me working PRU. The only weird thing is that it seems that node that is breaking PRU now is my UART2 node. When I disable it, my build works fine. Why it's weird in my opinion? because dmesg says there is pinmux conflict, while there should be no conflict at all.

UART2 uses two pins: 

pinctrl-single,pins = <0x150 0x31 0x154 0x1>;

while PRU uses those: 

pinctrl-single,pins = <0xb0 0x5 0xb4 0x5 0xa0 0x5 0xa4 0x5 0xa8 0x5 0xb8 0x4 0xe8 0x4 0x158 0x6 0x15c 0x6 0xe0 0x4 0xe4 0x4 0x38 0x2e 0xec 0x4>;

the message from dmesg is as follows:

[    4.754118] pinctrl-single 44e10800.pinmux: pin PIN43 already requested by 0-0070; cannot claim for 4a300000.pruss
[    4.768417] pinctrl-single 44e10800.pinmux: pin-43 (4a300000.pruss) status -22
[    4.775808] pinctrl-single 44e10800.pinmux: could not request pin 43 (PIN43) from group pru_cape_bone_pins  on device pinctrl-single
[    4.787914] ti-pruss 4a300000.pruss: Error applying setting, reverse things back
[    4.795398] ti-pruss: probe of 4a300000.pruss failed with error -22

PIN43 should be gpio1_11 (as it's 43 = 1*32 + 11) which is on pin named "uart0_txd" according to documentation and it's offset is 974h (TRM Rev. P page 1458) so in device tree it should be seen as 0x174. And that is one of pins of UART0 which is disabled in my device.

What am I missing? Why turning on UART2 makes this weird conflict? Am I counting pins wrong? I have doublechecked it and this looks right way to count it...

Hello Marek,

I would be surprised if UART2 was causing the issue, you're definitely using different pins for PRU and UART. Maybe there is another pinmuxing conflict that exists? Could you post the full device tree file? (maybe of the device tree file when PRU is working, and the file when the PRU gets a pinmux conflict)

Regards,
Nick