Linux/TMDSIDK574: PRP question

Hi VLeshka,

I'm sorry, I'm not sure I understand your question. Are you asking how to determine the indexes for the other PRP interface? If so, you can use your kernel log to determine this. Here is the example I used in the previous post:

root@am57xx-evm:~# dmesg | grep prueth
[ 16.954792] prueth pruss2_eth: port 1: using random MAC addr: 52:12:55:5c:cd:de
[ 17.078129] prueth pruss2_eth: port 2: using random MAC addr: 3e:19:0a:87:76:1a
[ 17.344620] prueth pruss2_eth: TI PRU ethernet (type 0) driver initialized
[ 19.165760] remoteproc remoteproc6: Booting fw image ti-pruss/am57xx-pru0-prueth-fw.elf, size 6212
[ 19.306979] prueth pruss2_eth eth2: Link is Up - 100Mbps/Full - flow control rx/tx
[ 19.369287] remoteproc remoteproc7: Booting fw image ti-pruss/am57xx-pru1-prueth-fw.elf, size 6240

I hope this is helpful to you. If not could you please explain a bit further what you are needing and I will be happy to try to help.

Hi RonB,

Firstly, I want you to dispel my strong doubts about the shutdown GIGETH0 and GIGETH1 (and actuation PRUETH0 and PRUETH1) by changing mux_data.h (the make compiler ignores the modified mux_data.h)
e2e.ti.com/.../2964835

VLeshka VV said:

Part Number: TMDSIDK574

Tool/software: Linux

Hi!

Indexes 6 and 7 should be used for one prp (remoteproc6 and remoteproc7). I didn't understand why exactly 6 and 7, but I followed your advice, and it works fine.
As I understand it, for another prp it is also necessary to have exotic indexes. Please, prompt them.

I think you are asking how does one determine the relationshiop between a remoteproc entry and the corresponding physical resources, right?

You can see it at run-time like this:

root@am65xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc*/name
b034000.pru
b004000.rtu
b238000.pru
b206000.rtu
41000000.r5f
b038000.pru
b006000.rtu
b134000.pru
b104000.rtu
b138000.pru
b106000.rtu
b234000.pru
b204000.rtu

The addresses correlate with those shown in the Technical Reference Manual in Table 2-1 MAIN Domain Memory Map.  So for example:

• b034000.pru -> ICSSG0, PRU0
• b038000.pru -> ICSSG0, PRU1

And to correlate with the remoteproc instance you can list them:

root@am65xx-evm:~# ls -al /sys/kernel/debug/remoteproc/
total 0
drwxr-xr-x   15 root     root             0 Apr  6 01:38 .
drwx------   27 root     root             0 Jan  1  1970 ..
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc0
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc1
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc10
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc11
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc12
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc2
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc3
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc4
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc5
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc6
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc7
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc8
drwxr-xr-x    2 root     root             0 Apr  6 01:38 remoteproc9

We can conclude:

• b034000.pru -> ICSSG0, PRU0 -> remoteproc0
• b038000.pru -> ICSSG0, PRU1 -> remoteproc2

Hi Brad Griffis,

I'm sorry, I'm not sure I understand your answer.

About your words:

"And to correlate with the remoteproc instance you can list them"

I'll clarify: do you mean list in order until some index works?

Brad Griffis,
in more detail:
The cat /sys/kernel/debug/remoteproc/remoteproc*/name
and acording to the table "Table 2-1. L3_MAIN Memory Map" of the AM572x Technical Reference Manual:
58820000.ipu ->
55020000.ipu ->
40800000.dsp ->
41000000.dsp ->
4b567000.pru -> PRU_ICSS1
4b238000.pru -> PRU_ICSS1
4b2b4000.pru -> PRU_ICSS2
4b2b8000.pru -> PRU_ICSS2

Then, the ls -al /sys/kernel/debug/remoteproc/ shows in order:
remoteproc0
remoteproc1
remoteproc2
remoteproc3
remoteproc4
remoteproc5
remoteproc6
remoteproc7

Did you mean that as it appears in the table AM572x Ref, the command "ls -al" displays in the same order?

Yes, they correspond in order. You can cat them individually if you have doubts.

Brad Griffis,

thanks for answer.

And more about PRP question:

When I setup a single prp interface, I have use 2 different firmware files.
Then, I have to setup 2 prp interfaces. But there are only 2 different firmware files in sdk: am57xx-pru0-pruprp-fw.elf and am57xx-pru1-pruprp-fw.elf.

Do I need in 4 different firmware files for 2 prp interfaces?

Brad Griffis,
If I ask the incorrect questions, please let me know.

P.S. I work with AM5728.

VLeshka,

No, you only need 2 firmware files as the same firmware works on 2 different PRU-ICSS, providing the same function. What you are trying to do is similar to what is being done on the AM57xx IDKs and their DTS files, arch/arm/boot/dts/am57xx-idk-common.dtsi should serve as a good reference for you.

I hope this helps address your query. Thanks for the post.

RonB,

thanks for answer.

Here 

quote:

Supported Platforms

AM571x, AM572x IDK (Only eth2 and eth3)

it's embarrassing.

Does that add to the problem in my task?

Note that I have to make 2 PRU-PRP interfaces (not-software).

Hello VLeshka,

Ron can answer your question about whether we support HSR/PRP on AM574x. I will comment on your question about firmware.

Please clarify what you mean by "single prp interface". According to our HSR/PRP documentation, our PRP firmware supports DANP. DANP uses two Ethernet ports for PRP. So to run PRP on one ICSS, you would load am57xx-pru0-pruprp-fw.elf into one of the PRUs and am57xx-pru1-pruprp-fw.elf into the other PRU.

Ron's June 25 answer tells you that if you want to have two DANPs on your processor, then you would go to the other ICSS, and load those same two firmwares into the PRUs on the second ICSS.

Regards,

Nick

Nick Saulnier, thanks for answer.

I think, I understood your question.

2 prp interfaces are: the first prp1 uses PRU1ETH0 and PRU1ETH1, the second prp2 uses PRU2ETH0 and PRU2ETH1.

I have prepared for you the 3 questions that collected from the other my questions from this forum. If I solve them, I'll close the topic about 2 ppp interfaces:

1. I have to setup for 2 PRU-PRP in my rootfs partition /media/vl/rootfs:
mkdir /media/vl/rootfs/sys/class
mkdir /media/vl/rootfs/sys/class/remoteproc
for prp1:
mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc4
mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc5
rm /media/vl/rootfs/sys/class/remoteproc/remoteproc4/firmware
echo 'am57xx-pru0-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc4/firmware
rm /media/vl/rootfs/sys/class/remoteproc/remoteproc5firmware
echo 'am57xx-pru1-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc5/firmware
echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc4/state
echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc5/state

for prp2:
mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc6
mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc7
rm /media/vl/rootfs/sys/class/remoteproc/remoteproc6firmware
echo 'am57xx-pru0-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc6/firmware
rm /media/vl/rootfs/sys/class/remoteproc/remoteproc7firmware
echo 'am57xx-pru1-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc7/firmware
echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc6/state
echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc7/state

I have no doubt that this is correct. But I brought it here to make sure. :)

2. I have to setup for 2 PRU-PRP in my boot-setup:

setenv netargs 'setenv bootargs console=${console} root=/dev/nfs nfsroot=${rootpath},${nfsopts} rw ip=dhcp ti_prueth.pruss4_ethtype=${pruss_ethtype} ti_prueth.pruss5_ethtype=${pruss_ethtype} ti_prueth.pruss6_ethtype=${pruss_ethtype} ti_prueth.pruss7_ethtype=${pruss_ethtype}'
setenv pruss_ethtype 2
saveenv
Is it correct?

3. As as answered me, I do not need to edit the file manually:
e2e.ti.com/.../2979515
quote:
If you are not planning to use CPSW PPS, you should not use this DTS file at all, thus no need to manually edit.
Is there something I don't understand ?

VLeshka VV said:

1. I have to setup for 2 PRU-PRP in my rootfs partition /media/vl/rootfs:
mkdir /media/vl/rootfs/sys/class
mkdir /media/vl/rootfs/sys/class/remoteproc
for prp1:
mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc4
mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc5
rm /media/vl/rootfs/sys/class/remoteproc/remoteproc4/firmware
echo 'am57xx-pru0-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc4/firmware
rm /media/vl/rootfs/sys/class/remoteproc/remoteproc5firmware
echo 'am57xx-pru1-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc5/firmware
echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc4/state
echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc5/state

for prp2:
mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc6
mkdir /media/vl/rootfs/sys/class/remoteproc/remoteproc7
rm /media/vl/rootfs/sys/class/remoteproc/remoteproc6firmware
echo 'am57xx-pru0-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc6/firmware
rm /media/vl/rootfs/sys/class/remoteproc/remoteproc7firmware
echo 'am57xx-pru1-pruprp-fw.elf' > /media/vl/rootfs/sys/class/remoteproc/remoteproc7/firmware
echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc6/state
echo 'start' > /media/vl/rootfs/sys/class/remoteproc/remoteproc7/state

The sysfs is built dynamically at boot up. You should not need to manually create these directories, as the kernel and driver will create and populate the as the drivers come up. The most important information you need to provide is what firmware you want loaded. This information is contained in the DT Node for the given PRUSS. Here is an example from the am57xxj-idi-common.dtsi file provided with the SDK:

        /* Dual-MAC Ethernet application node on PRU-ICSS2 */
        pruss2_eth: pruss2_eth {
                compatible = "ti,am57-prueth";
                prus = <&pru2_0>, <&pru2_1>;
                firmware-name = "ti-pruss/am57xx-pru0-prueth-fw.elf",
                                "ti-pruss/am57xx-pru1-prueth-fw.elf";
                sram = <&ocmcram1>;
                interrupt-parent = <&pruss2_intc>;

The firmware need to be placed in the appropriate place under lib/firmware, in the ti-pruss subdirectory for this example. You can investigate this further by looking at the filesystems that come with the SDK.

VLeshka VV said:

2. I have to setup for 2 PRU-PRP in my boot-setup:

setenv netargs 'setenv bootargs console=${console} root=/dev/nfs nfsroot=${rootpath},${nfsopts} rw ip=dhcp ti_prueth.pruss4_ethtype=${pruss_ethtype} ti_prueth.pruss5_ethtype=${pruss_ethtype} ti_prueth.pruss6_ethtype=${pruss_ethtype} ti_prueth.pruss7_ethtype=${pruss_ethtype}'
setenv pruss_ethtype 2
saveenv
Is it correct?

I would refer to the documentation for a better example of this:

http://software-dl.ti.com/processor-sdk-linux/esd/docs/05_01_00_11/linux/Industrial_Protocols_HSR_PRP.html#testing-hsr-prp-firmware-offload

You only need pruss1 and pruss2.

VLeshka VV said:

3. As as answered me, I do not need to edit the file manually:
e2e.ti.com/.../2979515
quote:
If you are not planning to use CPSW PPS, you should not use this DTS file at all, thus no need to manually edit.
Is there something I don't understand ?

Correct, you do not need to use that file at all. You will probably be using an adapted version of the AM574x-idk.dts file and all of it's include files. 

I hope this addresses your questions. Thank you.

RonB, thanks for answer!

So, I'll try to make things right (if I'm right in my guess).
The pruss1_eth associates to the PRU1ETH0 and PRU1ETH1.
The pruss2_eth associates to the PRU2ETH0 and PRU2ETH1

And from your software-dl.ti.com/.../Industrial_Protocols_HSR_PRP.html
quote from 4.2.3.12.1. Testing HSR/PRP Firmware Offload:
Remarks:
...
3.On AM572x IDK, only PRU-ICSS2 is supported. Hence only prueth.pruss2_type takes effect.

Does this mean that pruss1_eth is impossible?

VLeshka VV said:

So, I'll try to make things right (if I'm right in my guess).
The pruss1_eth associates to the PRU1ETH0 and PRU1ETH1.
The pruss2_eth associates to the PRU2ETH0 and PRU2ETH1

Yes, and they will likely enumerate in Linux to ethx to ethy depending on the number of interfaces you have.

VLeshka VV said:

3.On AM572x IDK, only PRU-ICSS2 is supported. Hence only prueth.pruss2_type takes effect.

Does this mean that pruss1_eth is impossible?

No. The SoC (AM574x) supports using 4 PRU Eth ports, but the board has a limitation to support only two PRU Eth ports. The AM571x IDK actually enables 4 PRU eth ports and should serve as a good Linux model for how to do this on AM572x/4x.

I hope this helps you.

I have verify your words:
The sysfs is built dynamically at boot up. You should not need to manually create these directories, as the kernel and driver will create and populate the as the drivers come up.

At default flash-card (default uboot and default rootfs):
I have made only the commands in boot setup:
setenv netargs 'setenv bootargs console=${console} root=/dev/nfs nfsroot=${rootpath},${nfsopts} rw ip=dhcp ti_prueth.pruss1_ethtype=${pruss_ethtype} ti_prueth.pruss2_ethtype=${pruss_ethtype}'
setenv pruss_ethtype 2
saveenv

And then there are no any directories in rootfs in /sys.

Am I missing something?

Sorry.

I have look the /sys in rootfs, when I mount the flash-card into the ubuntu. The "show hidden files" is on.

If I boot the IDK, there are /sys/*.* is exists (ls /sys).

But I just off the power of IDK, and directories /sys should not have been deleted.

Why directories /sys are not shown in ubuntu?

Sysfs (/sys) is a pseudo file system for viewing/controlling drivers from user space.  It never physically existed on the card in the first place.

Another question that may seem trivial to you:

how do I add a modified dts(i) file to the sdk?

I changed the dts file (for example, am57xx-idk-common.dtsi), then build the disk image with the command:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf - zImage

But the compiler does not see any changes in the dts file:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CHK scripts/mod/devicetable-offsets.h
CHK include/generated/compile.h
CHK kernel/config_data.h
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready

Or should I make a dtb file to put it in the boot partition?

If you run "make zImage" it will build the zImage.  If you want to build a dtb you would run something like "make am574x-idk.dtb".  (I shortened these commands by leaving out ARCH, etc.)

Note that we provide a "top level makefile" in the SDK, i.e. up two levels from where you're currently building in the Linux directory.  From that top-level makefile you can call "make linux" and it will build all AM57xx dtb files plus the kernel and modules.  In this case "make linux" is literally all you need to type.  The SDK already knows the location of the toolchain, the correct ARCH to specify, etc.  If you look at the underlying makefile you will see if is specifying those when it calls down to build linux.

Is this still related to your PRP question?  It is difficult for others to find answers to their questions when it's buried in some other thread, so I'd like to ask that anything not directly related to the PRP question please go into other threads.