where can I get pasm_2

Hi,

During the weekend I had some free time so, I decided to finally move a little forward with my project:)
I’ve started to write software pwm driver for servo motors. I’ve implemented most of the Linux driver part including PRU management. However, when I started to think how to implement PRU software part I’ve noticed that PRU Software Development Package 1.03 contains only pasm and AM335x TRM states that pasm_2 with option -PRUv2 is used to compile code for PRUs on AM335x. So, the question is where can I get pasm_2? I’ve looked over the TI website and tried to Google but with no success. Will the code generated by pasm work on PRUSS v2 regardless of the fact that it does not support “-PRUv2” flag?

thanks
//\arek Porwisz

Same issue, it's just not released yet. I would have expected it to
come with the sys/bios release scheduled for this month but it hasn't
be released yet.

I've just asked this question on the TI community forums.

Are TI frikin serious?!

Reply from message on TI community forums from TI employee:

"Thanks for the inquiry. The PRUSSv2 PASM for open platform
development is not planned for release at this time.

The PRUSSv2 feature set is only planned to support the Industrial
communications protocols included in the Industrial SDK:
http://www.ti.com/tool/sysbiossdk-ind-sitara"

So basically no pasm for the foreseeable future and the only SDK
support will be to load pre-compiled program supporting certain
protocols.

WHAT THE HECK! I'm starting to feel as though I may have just wasted
money. What's going on?

AGREE

This is NONSENSE, we also selected TI because of the ability to write
own PRUSS programs..

Antti

That’s a bad news:(

Old pasm seems to work on PRUSS v2(at least the basic instructions), however we will loose some of the new features (eg. scratchpad, etc). I was also not able to access GPIO interface(external, not the internal), so I don’t know if the SoC access does not work or this was just a codding error.

2012/1/5 Antti Lukats <antti.lukats@googlemail.com>

Exactly the issue, I was banking on the availability of the
scratchpad :frowning:

I’ve found that I did not clear the PRUSS->CFG.SYSCFG.STANDBY_INIT bit, so after fixing it I am able to access SoC resources.
There is still hope for my project :slight_smile: I can use data ram instead of scratchpad.

2012/1/5 Alistair <alistair.lowe@resonance-systems.com>

Hi Marek,

Can I ask how you're accessing the PRU?

I'm using the "prussdrv.h" driver but perhaps I've missed a step in
setting up the PRU for use on Linux as it doesn't work?

Am failing to open the device.

Would greatly appreciate any help,
Cheers

First of all, you need to enable clock for pruss module. My code is called from the linux driver so I’m doing something like this (removed error checking)

reset = (unsigned int *) ioremap_nocache(RM_PER_RSTCTRL, sizeof(unsigned int));
printk(KERN_INFO “Entering PRUSS reset state.\n”);
*reset=(1<<1);

reg = (unsigned int *) ioremap_nocache(CM_PER_PRUSS_CLKCTRL, sizeof(unsigned int));
*reg = 2;
iounmap(reg);

/* those registers should already have all the bits we need set correctly, however /
/
to make sure nothing goes wrong we set them again. */
reg = (unsigned int *) ioremap_nocache(PM_PER_PWRSTST, sizeof(unsigned int));
*reg = ((3<<23) | (*reg)) ;
iounmap(reg);

reg = (unsigned int *) ioremap_nocache(PM_PER_PWRSTCTRL, sizeof(unsigned int));
*reg = ((3<<5)|(1<<7)|(*reg));
iounmap(reg);

printk(KERN_INFO “Exiting PRUSS reset state.\n”);
*reset=*reset & (~(1<<1));
iounmap(reset);

The registers description can be found in the TRM(I’ve used the same names so ctrl+f should work). As stated in the comment there is no need to change the power registers. If you are trying to access pru from the user space (using some sort of ti provided lib) you may need to modify u-boot to update the pruss clock for you (there are three or four tables with clocks to enable/disable somewhere, but I do not remember in which file). Without it any pru related memory is not accessible.

I’ve created a header file based on the am335x TRM. It contains structure definition describing entire pruss memory (start from pru0 data ram, end with PRU1_iram).
From inside my linux driver i do something like this:
request_mem_region(PRUSS_BASE, sizeof(pruss_mem_t), DRV_NAME) ;
pruss_data = (pruss_mem_t*) ioremap_nocache(PRUSS_BASE, sizeof(pruss_mem_t));
pruss_data->CFG.SYSCFG &= ~ (1<<4);

where PRUSS_BASE is the pruss subsytem memory base from chapter 2.1 of TRM, and pruss_mem_t is the huge (around 250KB) structure based on the 4.3.2 chapter of the TRM. pruss_data->CFG.SYSCFG is the bit mentioned in previous post, without it pru stopped after accessing addresses from the global memory space.

Writing software (memcpy probably also works, but I’m unfamiliar with 8 and 32 bit access stuff, so this for sure is 32 bit access:) ):

for(i=0; i<len; i++)
{
pruss_data->PRU0_iram[i] = data[i];
}

Starting:
pruss_data->PRU0_control.CONTROL |= PRU_CTRL_PRU_ENABLE;

where: PRU0_control is the PRU0 Control at PRUSS_BASE + 0x0002_2000 TRM:4.5.4, PRU_CTRL_PRU_ENABLE = 0x02 (bit 1 - enable TRM: Table 4-26), PRU0_iram - PRUSS_BASE + 0x0003_4000.

Note that this is linux driver code, so you can not access the PRUSS_BASE+ address directly, you have to remap the memory. In my case I remap entire PRUSS memory (pruss_data = (pruss_mem_t*) ioremap_nocache(PRUSS_BASE, sizeof(pruss_mem_t)):wink: so all the offsets stay the same, only the base address changes. From pru assembler there is no memory mapping, so you can access other subsystems directly.

Best regards,
Marek

2012/1/6 Alistair <alistair.lowe@resonance-systems.com>

Before you copy the code into pru instruction ran you should also initialize the CONTROL register.

pruss_data->PRU0_control.CONTROL = PRU_CONTROL_INITIAL;

where PRU_CONTROL_INITIAL = 0x00000008 /* 0x0000 base address, no step, instruction ctr en, no sleep, halted, reset */
It was late when I wrote the instructions yesterday and i overlooked the line in my code.

2012/1/6 Marek Porwisz <marek.porwisz@gmail.com>

The software at https://gforge.ti.com/gf/project/pru_sw/ might be of some use. I’m working on trying to get a PRUv2 assembler out there (officially unsupported – but is it official support we really care about?). Give me a couple weeks and come down on me after that if it doesn’t happen.

I've been exploring this software however I can't confirm the presence
of the kernel uio_pru driver in the cloud9 build, even though it does
appear to be present in the kernel at the following link:
https://github.com/beagleboard/linux/blob/master/drivers/uio/uio_pruss.c

Any ideas? Is it simply not getting built into the kernel or am I
missing something?

If it exists as a module I should just be able to perform modprobe
'uio_pru' or confirm that the driver is loaded with 'cat /sys/class/
uio/uio0/maps/map0/addr' however there's no uio provision.

I tried to play with the patches from TI package. They are not ready
for the am33xx processors, and out of the box can be used with daVinci
da850 evm board. I think the driver itself should work with beaglebone
without major changes, but the board part needs to be added to the
board support code. I started to work on porting the code, but this is
not my top priority and it can take me a while to finish.

j.

Also thanks for the information Marek, will look into it.

Cheers

The software at https://gforge.ti.com/gf/project/pru_sw/ might be of
some use. I'm working on trying to get a PRUv2 assembler out there
(officially unsupported -- but is it official support we really care
about?). Give me a couple weeks and come down on me after that if it
doesn't happen.

[ This is becoming an old thread, so let's keep it alive :slight_smile: ]

Jason, any news? Thus far I've been able to do my proof-of-concept with the old pasm, but I'll be starting with the serious work rsn and would like all the nifty new features of version 2!

--- Bas

I had the same reaction to this… but I just saw on the TI forums that pasm_2 might be released in March:

http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/163158.aspx#602529

I hope this turns out to be true … everyone might want to keep the pressure up on this. If it turns out I can’t write my own software for the PRU, then it means that I can’t use the AM335x and I’ll probably get fired.

Hi PRUSS enthousiasts,

have a look here:

https://github.com/beagleboard/am335x_pru_package

Cheers,

Bas

Bummer, it looks like all support of the really interesting parts (scratchpad & mac) has been removed (or disabled) :frowning:
Silicon problems, or aren't we allowed to use these features???

-- Bas

The previous version of pasm that I had identifies itself:

PRU Assembler Version 0.76
Copyright © 2005-2010 by Texas Instruments Inc.

This version is:

PRU Assembler Version 0.79
Copyright © 2005-2011 by Texas Instruments Inc.

It’s help doesn’t mention the -PRUv2 command line switch the TRM refers to for the am335x.

I’d suggest the pasm linked isn’t the PASM v2 we’re waiting for!!

While i’m replying, big “thanks” to pomarek above, your code helped heaps getting the PRU working from a kernel driver.

Rob.

The previous version of pasm that I had identifies itself:

PRU Assembler Version 0.76
Copyright © 2005-2010 by Texas Instruments Inc.

This version is:

PRU Assembler Version 0.79
Copyright © 2005-2011 by Texas Instruments Inc.

It’s help doesn’t mention the -PRUv2 command line switch the TRM refers to for the am335x.

I’d suggest the pasm linked isn’t the PASM v2 we’re waiting for!!

While i’m replying, big “thanks” to pomarek above, your code helped heaps getting the PRU working from a kernel driver.

Rob.

The command line switch has been removed, I was told.
The new instructions (from the rev.C manual) are present in the assembler, but I haven’t been able to use all of them (due to lack of time and missing documentation).

But be assured, this is a PRUSS v2 version, although it might not the one we were expecting / hoping for.

– Bas