Re: [beagleboard] Re: Explanation of PRU Programming in C

[Joseph Heller]

On Tuesday, May 16, 2017 at 3:27:07 AM UTC+2, William Hermans wrote:
>
>
>
> On Wed, Apr 26, 2017 at 1:02 AM, Joseph Heller  > wrote:
>
>> Updated link: http://catch22.eu/beaglebone/beaglebone-pru-c/
>>
>
> I may have mentioned this before, but I think blinking a USR LED would be 
> far more useful. Nothing to hook up, and worry about blowing the pins on 
> the processor, etc. However, then we're talking about involving the L3 
> interconnect, which might be what you did not want to do ?
>
> A point of contention that I have with the article however, is: How does 
> the GPIO bank + DATA_OUT register get into the PRU's _R30 register ? This 
> also has to be dynamic somehow. I can't imagine all registers r0-r31 are 
> each dedicated to a single control register of *something*. Then yes, I do 
> know that some PRU registers are reserved, I just do not know which anymore.
>

I don't know yet either at the moment. The way I use it in the example 
seems to work magically per default. Risk is that is breaks though. An 
explanation would be helpful. 
 

> In another part of the article:
>
>> The issue faced here is that one has to deep-dive into the workings of 
>> the header files, and make the relation to the defined variables in those 
>> header files and the PRU registers defined in the Reference Manual. 
>> Fortunately the header files and the reference manual closely match each 
>> other. *Unfortunately, you have to do the footwork to figure it out for 
>> each common or less common usage of the registers. For instance, here’s a 
>> relevant section of the pru_iep.h header file for the IEP example above:*
>
>
> Then you go on to show some "pictures" from various sources, most notably 
> the applicable registers from the TRM. My point here is, I'm not sure what 
> your point is. This is pretty much standard procedure when working with any 
> hardware on this level. That is, *IF* you really need to know for sure, 
> what you're doing. 
>
So, do not get me wrong, I'm not bashing what you've done there at all. 
> It's a lot more than I've done in demonstrating the PRU's to the public. 
> Mostly due to the fact that I do not know how to use the PRU's very well at 
> all.
>

Okay, I've rephrased that part a bit. Thanks for the feedback.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a0b82fcb-923f-4223-a839-87a3578cbee1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Explanation of PRU Programming in C

[Joseph Heller]

On Tuesday, May 16, 2017 at 1:01:55 AM UTC+2, Clark Sann wrote:
>
> Hi Joseph
>
> Nice writeup. You did a good job of explaining a complex topic...at least 
> it seems complex to me. I have however found a possible error.
>
> Shouldn't you be referring to the DEFAULT_INC value rather than the 
> CMP_INC value in your description?
>

Hi Clark, 

That's a good catch - I've corrected this.

Thanks!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e92ff34b-45f0-4374-ab88-23acc3b7cb43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Sharing some thoughts on quality

[Joseph Heller]

 

I just stumbled upon an issue I had encountered a year ago as well, and would 
like to share some thoughts on this here. All help appreciated, don't get me 
wrong, and I'm sure it will be resolved but I recalled some things missing the 
first time when I had the issue, which still seem to be missing now. It is 
things missing like: are there release notes, is there a bug tracker, 
differentiation between stable and unstable releases, a wiki that's kept 
up-to-date, and what happens if someone crucial is leaving the team? Now that 
got me thinking: could it be that this is the underlying reason for issues like 
these in general? The reason for me to bring it up is that I'm actually 
wondering if spending my time and effort on the Beaglebone is the best 
investment, or that there's alternative solutions. The Beaglebone is known to 
be an SBC with a steep learning curve, but I did not expect to be spending time 
on the issues just mentioned. As an experiment, I have an outstanding order 
which I wonder if that suits me better in the long run if issues occur. So in 
that sense, this is feedback on something that looks to me as the weak spot of 
the Beaglebone. I truly think the board is a very good platform from hardware 
point of view, but it would be a pity if due to the issues mentioned it will 
not survive competition. My guess, and maybe the hard part, is that suggested 
improvements are not easily decided upon and implemented by the community - 
although here's my contribution by starting a discussion and sharing thoughts 
about it. It's more like defining a strategy and improving of the foundation by 
the core team, after which the community can benefit from it either as users or 
participants. Having a less well defined quality standpoint, is in a sense the 
other way round: despite the good intentions, have the community be confronted 
with issues, then try to solve them. Some frustration being vented here as well 
as you might have noted, but I guess that’s all in the game.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/520cc84e-261e-42d9-841d-8621e00807ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: 4.4.x-ti kernel with rproc & uio (r34)

[Joseph Heller]

On Wednesday, July 6, 2016 at 4:56:13 PM UTC+2, RobertCNelson wrote:
>
> Step 3: (uio) 
>
> Edit your device tree: 
>
> nano src/arm/am335x-bonegreen.dts 
>
> Change: 
> /* #include "am33xx-pruss-uio.dtsi" */ -> #include "am33xx-pruss-uio.dtsi" 
> make ; sudo make install 
>
> set blacklist: 
>
> cat /etc/modprobe.d/pruss-blacklist.conf 
>
> blacklist pruss 
> blacklist pruss_intc 
> blacklist pru-rproc 
>
> and reboot.. 
>
 
I managed to get uio working previously, but not anymore with latest image 
(uname -r: 4.4.54-ti-r93). I ended up here from another post. Did something 
change with respect to the above? 

I can see my edited and compiled dtb did get loaded via uEnv.txt  (and yes, 
I also blacklisted the remoteproc drivers), but still Remoteproc is loaded 
instead of uio. Per guide above, I also wonder if in the second step 3 the 
remoteproc dtsi should be disabled. I did, as in the latest image it seems 
to be enabled by default. My guess is some generic device tree is referring 
to Remoteproc?

Actually, I was making a web page explaining a generic way how to get uio 
working on newer kernels - for everybody to enjoy and quickly jump to 
programming the PRUs with uio instead of struggling to get the driver 
working in the first place, but my enthusiasm plummethed when I noticed the 
way to do it changes so often.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e8769aa2-1f39-4ac6-8115-e8292814f281%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How to use shared memory between PRU and ARM (in C): an example

[Joseph Heller]

Here's an example I'd like to make share: how to use shared memory between 
PRU and ARM using uio_pruss and prussdrv:

http://catch22.eu/beaglebone/beaglebone-pru-ipc/

Feel free to comment here on this forum post. There's also a git repository 
 to download all code 
and/or further improve it. 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/45450e62-a3dd-4de7-b585-7e8e35c2737e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Explanation of PRU Programming in C

[Joseph Heller]

Updated link: http://catch22.eu/beaglebone/beaglebone-pru-c/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/66c4d74d-914b-4729-89c0-68410bdb449f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Explanation of PRU Programming in C

[Joseph Heller]

Thanks for the positive feedback. The TI video does not work on Mac though. 

I've now also included the hello world blink LED in C. 

> On 19 Apr 2017, at 19:38, Greg  wrote:
> 
> Excellent!  I did a couple of projects with PRU and C code, and this type of 
> tutorial is sorely needed.
> 
> I would add a link to this:
> 
> https://training.ti.com/pru-compiler-tips-tricks
> 
> So I wonder how common it is to use a C union and bit selector?
> When I first encountered this in the PRU header files, I didn't even think it 
> was C code!
> In fact, in the information provided by TI in the video and slides, they say 
> it is really warped C code.
> 
> Regards,
> Greg
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/3KjD7ULjD6M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/bb0d76a6-0108-4f8c-a027-5a461c73ec68%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/830480A5-BD30-4277-882F-230B7BB8D387%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Explanation of PRU Programming in C

[Joseph Heller]

Hi guys, after a deep dive, I've found how to program to PRU in C (instead 
of Assembly). Here's my contribution:

http://catch22.eu/omnirobot/beaglebone-pru-c/

Feel free to comment on this forum!

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d177d3ae-06c9-471b-9620-f95f81842232%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Hello William, 

Nice page there William. 

Yes we have the right installation written above for using uio. Documenting 
it on eLinux seems to be the next logical thing also. I'm opting to help 
here, already registered with my account on eLinux, or go for a personal 
page as well. There's a weak spot though. I see the pace at which kernel 
and surroundings changes is quite fast if you take a minute to look back, I 
think therefore the info, once written down, is outdated quite fast as well 
consequently. Take a look at this page for 
instance: http://elinux.org/Ti_AM33XX_PRUSSv2. It still assumes uio, but 
remoteproc now being the preferred/standard. So I think there needs to be a 
tighter link between developer and documentation to keep all in sync. The 
beagle bone project would benefit from this tighter link to my opinion. 
Thinking out loud, also here, a more modular approach on the beagle bone 
software would help. Like to use uio? Use this kernel, install this .deb, 
and your ready to go (ideally). Any changes under the hood are then kept 
inside the .deb that is affected, and documentation (or installed base so 
to speak further down the line) is much easier to maintain / keep up to 
date from user perspective. 

My 2 cents... but again, happy with the help offered!

Regards,
Joseph

On Tuesday, July 19, 2016 at 7:06:36 PM UTC+2, William Hermans wrote:
>
> I think it's pretty well documented here. However you could always write 
> up an eLinux or whatever wiki page . . . I do have my own web page 
> http://www.embeddedhobbyist.com/ with stuff on it that is important to 
> me. But this information for using UIO on TI kernels I feel is largely 
> useless. Because 
>
> The method for enabling either / or will likely change in the future.
> Right now, personally I'm still favoring *bone* kernels, and I know I'm 
> not alone.
> This is really a trivial "fix". Or something that is really easy to 
> remember how to do.
>
> @Robert, any idea on if TI plans on cleaning up the kernel module mess 
> that now "infests" TI kernels ? using something like 50M + memory 
> needlessly . . .
>  
>
>
> On Tue, Jul 19, 2016 at 9:52 AM, Joseph Heller  > wrote:
>
>> Finally, that worked William (&John &Robert)! I did a small check with an 
>> LED and am able to with it on/off now via the PRU and uio. 
>>
>> For your consideration, I wonder how you feel like to document this more 
>> structurally so others can benefit from it? I was offset by some older 
>> posts on the forum. Next thing I just though about is to make more use of 
>> the .deb functionality instead of relying on script or instructions. For 
>> instance uio "conflicts" with remoteproc in reality, but both reside on the 
>> same sd-card image. Otherwise, I also understood the PRU's are not that 
>> much used, so maybe it;s not worth the effort to invest in this.
>>
>> Anyway, thanks again for the help, I'd be glad to inform/post the end 
>> result of my project somewhere once my time-critical part of c code as 
>> transferred to the PRU. 
>>
>> On Monday, July 18, 2016 at 10:30:35 PM UTC+2, William Hermans wrote:
>>
>>> Well, not to mention you installed a *bone* kernel anyhow. So what we're 
>>> talking about is really moot. e.g. a topic for a different discussion.
>>>
>>> So. . . back on topic . . .
>>>
>>> *Download suitable linu image and reboot:*
>>> william@beaglebone:~$ sudo apt-get install linux-image-4.4.14-ti-r34
>>> william@beaglebone:~$ sudo reboot
>>>
>>> *Install git and check your dtc version:*
>>> william@beaglebone:~$ sudo apt-get install git
>>> william@beaglebone:~$ dtc -v
>>> Version: DTC 1.4.1
>>>
>>> *Clone the git into a suitable location:*
>>> william@beaglebone:~$ cd dev
>>> git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder 
>>> dtb-4.4-ti --depth=1 
>>> william@beaglebone:~/dev$ cd dtb-4.4-ti/
>>>
>>> *Edit the needed board file( this will be different for every situation 
>>> )*
>>> william@beaglebone:~/dev/dtb-4.4-ti$ nano 
>>> src/arm/am335x-boneblack-emmc-overlay.dts
>>> change:
>>> /* #include "am33xx-pruss-uio.dtsi" */
>>> to:
>>> #include "am33xx-pruss-uio.dtsi"
>>>
>>> *Build from source, and install the board file:*
>>> william@beaglebone:~/dev/dtb-4.4-ti$ make
>>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
>>>
>>> *Blacklist the remoteproc drivers:*
>>> william@beaglebone:~/dev/dtb-rebuilder$ sudo nano 
>>> /etc/

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Ok thanks Robert, 

Yes, well, some rationale at least from my side as input. After I've 
checked my options to go for PRU, I found there's both remoteproc and uio. 
At first glance, I did not like the remoteproc implementation as it appears 
to be more of an interrupt based approach. I think this is more towards 
userspace program on the main processor that does not do that much harm, 
but for the PRU being the opportunity to do hard real time stuff (although 
not really interrupt based but polling-wise) a somewhat weird concept 
choice. I've seen an idea to let PRU1 handle the interrupts, and use PRU2 
to interact with PRU1 for the real realtime stuff which does sound like a 
compromise. So my "instinct" for what it's worth was to steer clear of 
remoteproc and use uio. It fitted my application better as well to have 
shared memory both accessible to PRU and userspace. As far as I could tell 
a couple of weeks ago this is not possible with remoteproc. I might be 
wrong though, but this is how I came to the conclusion to go for uio. 

Regards,
Maarten

On Tuesday, July 19, 2016 at 7:05:33 PM UTC+2, RobertCNelson wrote:
>
> Hi Joseph,
>
> On Tue, Jul 19, 2016 at 11:52 AM, Joseph Heller  > wrote:
>
>> Finally, that worked William (&John &Robert)! I did a small check with an 
>> LED and am able to with it on/off now via the PRU and uio. 
>>
>> For your consideration, I wonder how you feel like to document this more 
>> structurally so others can benefit from it? I was offset by some older 
>> posts on the forum. Next thing I just though about is to make more use of 
>> the .deb functionality instead of relying on script or instructions. For 
>> instance uio "conflicts" with remoteproc in reality, but both reside on the 
>> same sd-card image. Otherwise, I also understood the PRU's are not that 
>> much used, so maybe it;s not worth the effort to invest in this.
>>
>> Anyway, thanks again for the help, I'd be glad to inform/post the end 
>> result of my project somewhere once my time-critical part of c code as 
>> transferred to the PRU. 
>>
>
> So i'm hoping, this will only be short term.  I believe everyone at ti, 
> now has a crystal clear idea of what users want from the pruss interface.  
> So hopefully this uio/remoteproc will get fixed..  A couple notes on the 
> script, normally the dtb-rebuilder repo can be found here:
>
> /opt/source/dtb-4.4-ti/
>
> It's just for a few releases, that didn't get cloned properly.
>  
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9ada81cc-b65b-430e-bb6a-291580a892a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Finally, that worked William (&John &Robert)! I did a small check with an 
LED and am able to with it on/off now via the PRU and uio. 

For your consideration, I wonder how you feel like to document this more 
structurally so others can benefit from it? I was offset by some older 
posts on the forum. Next thing I just though about is to make more use of 
the .deb functionality instead of relying on script or instructions. For 
instance uio "conflicts" with remoteproc in reality, but both reside on the 
same sd-card image. Otherwise, I also understood the PRU's are not that 
much used, so maybe it;s not worth the effort to invest in this.

Anyway, thanks again for the help, I'd be glad to inform/post the end 
result of my project somewhere once my time-critical part of c code as 
transferred to the PRU. 

On Monday, July 18, 2016 at 10:30:35 PM UTC+2, William Hermans wrote:
>
> Well, not to mention you installed a *bone* kernel anyhow. So what we're 
> talking about is really moot. e.g. a topic for a different discussion.
>
> So. . . back on topic . . .
>
> *Download suitable linu image and reboot:*
> william@beaglebone:~$ sudo apt-get install linux-image-4.4.14-ti-r34
> william@beaglebone:~$ sudo reboot
>
> *Install git and check your dtc version:*
> william@beaglebone:~$ sudo apt-get install git
> william@beaglebone:~$ dtc -v
> Version: DTC 1.4.1
>
> *Clone the git into a suitable location:*
> william@beaglebone:~$ cd dev
> git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder 
> dtb-4.4-ti --depth=1 
> william@beaglebone:~/dev$ cd dtb-4.4-ti/
>
> *Edit the needed board file( this will be different for every situation )*
> william@beaglebone:~/dev/dtb-4.4-ti$ nano 
> src/arm/am335x-boneblack-emmc-overlay.dts
> change:
> /* #include "am33xx-pruss-uio.dtsi" */
> to:
> #include "am33xx-pruss-uio.dtsi"
>
> *Build from source, and install the board file:*
> william@beaglebone:~/dev/dtb-4.4-ti$ make
> william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
>
> *Blacklist the remoteproc drivers:*
> william@beaglebone:~/dev/dtb-rebuilder$ sudo nano 
> /etc/modprobe.d/pruss-blacklist.conf
> blacklist pruss
> blacklist pruss_intc
> blacklist pru-rproc
> william@beaglebone:~/dev$ sudo reboot
>
> *Test to see if the device tree file loaded successfully:*
> william@beaglebone:~$ lsmod |grep  uio
> uio_pruss   4928  0
> uio_pdrv_genirq     3539  0
> uio 8822  2 uio_pruss,uio_pdrv_genirq
>
> On Mon, Jul 18, 2016 at 1:12 PM, Robert Nelson  > wrote:
>
>>
>>
>> On Mon, Jul 18, 2016 at 3:08 PM, Joseph Heller > > wrote:
>>
>>> small progress here; 
>>> 4.4.x-ti r34 did not result in any good (only remoteproc as far as I 
>>> could tell), no uio. 
>>>
>>> Therefore went for the bone version, non -rt:
>>>
>>> cd /opt/scripts/tools/
>>> sudo git pull
>>> sudo ./update_kernel.sh --bone-kernel --lts-4_4
>>>
>>> which gave me 
>>> kernel 4.4.15-bone11
>>>
>>> and a new dmesg after loading my dtbo: 
>>> [Mon Jul 18 19:44:48 2016] pruss_uio 4a30.pruss: pins are not 
>>> configured from the driver
>>> [Mon Jul 18 19:44:49 2016] bone-pinmux-helper 
>>> ocp:pinctrl_generated_pinmux: could not find pctdev for node 
>>> /ocp/interrupt-controller@4820, deferring probe
>>>
>>
>> ^ looks like you aren't using the dtc compiler for v4.1.x+ targets..
>>
>> Regards,
>>
>> -- 
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgfQYcKT89EihmpdnORK%3D7t9M3zG7gG1SozLtQpaTtQJA%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/CAOCHtYgfQYcKT89EihmpdnORK%3D7t9M3zG7gG1SozLtQpaTtQJA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1a79bfd0-ddcf-4f32-a6af-95635e067fef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

small progress here; 
4.4.x-ti r34 did not result in any good (only remoteproc as far as I could 
tell), no uio. 

Therefore went for the bone version, non -rt:

cd /opt/scripts/tools/
sudo git pull
sudo ./update_kernel.sh --bone-kernel --lts-4_4

which gave me 
kernel 4.4.15-bone11

and a new dmesg after loading my dtbo: 
[Mon Jul 18 19:44:48 2016] pruss_uio 4a30.pruss: pins are not 
configured from the driver
[Mon Jul 18 19:44:49 2016] bone-pinmux-helper ocp:pinctrl_generated_pinmux: 
could not find pctdev for node /ocp/interrupt-controller@4820, 
deferring probe

Probably the pro loader does not work yet because of this, and quits with 
prussdrv_open() 
failed

So I think I need to figure out a bit of my device tree to get the correct 
pinmuxing / overlay file now. 

On Sunday, July 17, 2016 at 6:44:08 PM UTC+2, Joseph Heller wrote:
>
> ok thanks William for the heads-up. Did a check on 4.1.5-ti-r10, so the 
> non-rt version, but no luck yet (but not out of options). Had one failure 
> again truing to apt-get install a 4.1.5 bone15 kernel, so need to try that 
> as well. I missed Robert's remark though earlier in the post to use 
> 4.4.x-ti r34 or later and would like to try that as well. 
>
> ---> So to clarify, best bet is to use 4.4.x-ti r34, the non-rt version, 
> in order to use uio_pruss? 
>
> On Sunday, July 17, 2016 at 2:03:30 AM UTC+2, William Hermans wrote:
>>
>> So apparently you got bit by the rt kernel bug as many have in the past. 
>> So, if you want to use uio_pruss right now with TI's most recently kernel. 
>> You're going to have to opt out of using an rt kernel. Which honestly is 
>> not a huge deal.
>>
>> On Sat, Jul 16, 2016 at 4:58 PM, William Hermans  
>> wrote:
>>
>>> RT kernel strikes again apparently . . .
>>>
>>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo apt-get install 
>>> linux-image-4.4.14-ti-r34
>>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo reboot
>>>
>>> william@beaglebone:~$ uname -r
>>> 4.4.14-ti-r34
>>>
>>> william@beaglebone:~$ cd dev/dtb-4.4-ti/
>>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
>>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo reboot
>>>
>>> william@beaglebone:~$ lsmod |grep  uio
>>> uio_pruss   4928  0
>>> uio_pdrv_genirq 3539  0
>>> uio 8822  2 uio_pruss,uio_pdrv_genirq
>>>
>>>
>>> On Sat, Jul 16, 2016 at 3:18 PM, William Hermans  
>>> wrote:
>>>
>>>> Right, and  . . .
>>>>
>>>> william@beaglebone:~/dev/dtb-4.4-ti$ head /boot/uEnv.txt
>>>> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>>>>
>>>> uname_r=4.4.14-ti-rt-r34
>>>> #uuid=
>>>> #dtb=
>>>>
>>>> ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just 
>>>> works..)
>>>>
>>>> ##BeagleBone Black: HDMI (Audio/Video) disabled:
>>>> dtb=am335x-boneblack-emmc-overlay.dtb
>>>>
>>>>
>>>> On Sat, Jul 16, 2016 at 3:13 PM, William Hermans  
>>>> wrote:
>>>>
>>>>> Robert. 
>>>>>
>>>>> You instructions here: 
>>>>> https://groups.google.com/forum/#!searchin/beagleboard/Robert$20Nelson$20r34%7Csort:date/beagleboard/l59Dx8ygxNg/GhdRzR7IDAAJ
>>>>>  
>>>>> do not work.
>>>>>
>>>>> I do not what to tell you other than I followed you instructions to 
>>>>> the "T" and . . .
>>>>>
>>>>> william@beaglebone:~$ lsmod |grep uio
>>>>> uio_pdrv_genirq 3661  0
>>>>> uio 8776  1 uio_pdrv_genirq
>>>>>
>>>>> william@beaglebone:~$ uname -r
>>>>> 4.4.14-ti-rt-r34
>>>>>
>>>>> william@beaglebone:~$ cat /etc/dogtag
>>>>> BeagleBoard.org Debian Image 2016-05-01
>>>>>
>>>>> william@beaglebone:~/dev/dtb-4.4-ti$ grep "#include" 
>>>>> src/arm/am335x-boneblack-emmc-overlay.dts
>>>>> #include "am33xx.dtsi"
>>>>> #include "am335x-bone-common.dtsi"
>>>>> #include "am33xx-overlay-edma-fix.dtsi"
>>>>> /* #include "am33xx-pruss-rproc.dtsi" */
>>>>> #include "am33xx-pruss-uio.dtsi"
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jul 16, 2016 at 10:22 AM, Robert Nelson  
>>>>> w

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

ok thanks William for the heads-up. Did a check on 4.1.5-ti-r10, so the 
non-rt version, but no luck yet (but not out of options). Had one failure 
again truing to apt-get install a 4.1.5 bone15 kernel, so need to try that 
as well. I missed Robert's remark though earlier in the post to use 
4.4.x-ti r34 or later and would like to try that as well. 

---> So to clarify, best bet is to use 4.4.x-ti r34, the non-rt version, in 
order to use uio_pruss? 

On Sunday, July 17, 2016 at 2:03:30 AM UTC+2, William Hermans wrote:
>
> So apparently you got bit by the rt kernel bug as many have in the past. 
> So, if you want to use uio_pruss right now with TI's most recently kernel. 
> You're going to have to opt out of using an rt kernel. Which honestly is 
> not a huge deal.
>
> On Sat, Jul 16, 2016 at 4:58 PM, William Hermans  > wrote:
>
>> RT kernel strikes again apparently . . .
>>
>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo apt-get install 
>> linux-image-4.4.14-ti-r34
>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo reboot
>>
>> william@beaglebone:~$ uname -r
>> 4.4.14-ti-r34
>>
>> william@beaglebone:~$ cd dev/dtb-4.4-ti/
>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo reboot
>>
>> william@beaglebone:~$ lsmod |grep  uio
>> uio_pruss   4928  0
>> uio_pdrv_genirq 3539  0
>> uio 8822  2 uio_pruss,uio_pdrv_genirq
>>
>>
>> On Sat, Jul 16, 2016 at 3:18 PM, William Hermans > > wrote:
>>
>>> Right, and  . . .
>>>
>>> william@beaglebone:~/dev/dtb-4.4-ti$ head /boot/uEnv.txt
>>> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>>>
>>> uname_r=4.4.14-ti-rt-r34
>>> #uuid=
>>> #dtb=
>>>
>>> ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)
>>>
>>> ##BeagleBone Black: HDMI (Audio/Video) disabled:
>>> dtb=am335x-boneblack-emmc-overlay.dtb
>>>
>>>
>>> On Sat, Jul 16, 2016 at 3:13 PM, William Hermans >> > wrote:
>>>
>>>> Robert. 
>>>>
>>>> You instructions here: 
>>>> https://groups.google.com/forum/#!searchin/beagleboard/Robert$20Nelson$20r34%7Csort:date/beagleboard/l59Dx8ygxNg/GhdRzR7IDAAJ
>>>>  
>>>> do not work.
>>>>
>>>> I do not what to tell you other than I followed you instructions to the 
>>>> "T" and . . .
>>>>
>>>> william@beaglebone:~$ lsmod |grep uio
>>>> uio_pdrv_genirq 3661  0
>>>> uio 8776  1 uio_pdrv_genirq
>>>>
>>>> william@beaglebone:~$ uname -r
>>>> 4.4.14-ti-rt-r34
>>>>
>>>> william@beaglebone:~$ cat /etc/dogtag
>>>> BeagleBoard.org Debian Image 2016-05-01
>>>>
>>>> william@beaglebone:~/dev/dtb-4.4-ti$ grep "#include" 
>>>> src/arm/am335x-boneblack-emmc-overlay.dts
>>>> #include "am33xx.dtsi"
>>>> #include "am335x-bone-common.dtsi"
>>>> #include "am33xx-overlay-edma-fix.dtsi"
>>>> /* #include "am33xx-pruss-rproc.dtsi" */
>>>> #include "am33xx-pruss-uio.dtsi"
>>>>
>>>>
>>>>
>>>> On Sat, Jul 16, 2016 at 10:22 AM, Robert Nelson >>> > wrote:
>>>>
>>>>> On Jul 16, 2016 11:57 AM, "Joseph Heller" >>>> > wrote:
>>>>> >
>>>>> > Hi William, thanks for the support, some input got me further at 
>>>>> least. This is how far I got today: I now have the uio driver more or 
>>>>> less 
>>>>> enabled on 4.1.5-ti-rt-r10 via my DTS file: 
>>>>>
>>>>> I thought i was very explicit in my email, 4.4.x-ti r34 or later. For 
>>>>> that specific kernel you are using, you'll be discovering the uoi patch 
>>>>> in 
>>>>> r34. 😉
>>>>>
>>>>> Regards,
>>>>>
>>>>> -- 
>>>>> For more options, visit http://beagleboard.org/discuss
>>>>> --- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "BeagleBoard" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to beagleboard...@googlegroups.com .
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYhcEYd2tgc_s3aD%2Bdvz19y24miWqNCrxpahGsw5vryZuA%40mail.gmail.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/beagleboard/CAOCHtYhcEYd2tgc_s3aD%2Bdvz19y24miWqNCrxpahGsw5vryZuA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1b434a2b-3149-4077-b9da-40e3a92380bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Hi William, thanks for the support, some input got me further at least. 
This is how far I got today: I now have the uio driver more or less enabled 
on 4.1.5-ti-rt-r10 via my DTS file: 

/dts-v1/;

/plugin/;


/ { compatible = "ti,beaglebone", "ti,beaglebone-black";

part-number = "OMNI-ROBOT";

version = "00A0";   



fragment@0 {

target = <&am33xx_pinmux>;

__overlay__ {

pinctrl_generated: RNS_Generated_Pins {

pinctrl-single,pins = <

0x078 0x07 /* P9_12 OUTPUT | MODE7 */ 

0x048 0x07 /* P9_14 OUTPUT | MODE7 */

0x04c 0x07 /* P9_16 OUTPUT | MODE7 */

0x084 0x07 /* P8_20 OUTPUT | MODE7 */ 

0x014 0x07 /* P8_22 OUTPUT | MODE7 */

0x004 0x07 /* P8_24 OUTPUT | MODE7 */

0x07c 0x07 /* P8_26 OUTPUT | MODE7 */


0x018 0x37 /* P8_3 INPUT | MODE7 */

0x01c 0x37 /* P8_4 INPUT | MODE7 */

0x008 0x37 /* P8_5 INPUT | MODE7 */

0x00c 0x37 /* P8_6 INPUT | MODE7 */

0x034 0x37 /* P8_11 INPUT | MODE7 */

0x030 0x37 /* P8_12 INPUT | MODE7 */


0x1ac 0x07 /* P9_25 OUTPUT | MODE7 */

0x1a4 0x07 /* P9_27 OUTPUT | MODE7 */

0x19c 0x07 /* P9_28 OUTPUT | MODE7 */

0x194 0x07 /* P9_29 OUTPUT | MODE7 */

0x198 0x07 /* P9_30 OUTPUT | MODE7 */

0x190 0x07 /* P9_31 OUTPUT | MODE7 */

>;

};


pru_pru_pins: pinmux_pru_pru_pins {

pinctrl-single,pins = <

0x0a4 0x25 /* P8_46 OUTPUT | MODE 5 */

>;

};

};

};


fragment@1 {

target = <&ocp>;

__overlay__ {

pinctrl_generated_pinmux {

  compatible = "bone-pinmux-helper";

   pinctrl-names = "default";

   pinctrl-0 = <&pinctrl_generated>;

   status = "okay";

};

};

};


fragment@2 {

target = <&pruss>; 

__overlay__ { 

status = "okay"; 

pinctrl-names = "default";

pinctrl-0 = <&pru_pru_pins>;

}; 

}; 


};


I've some issue now do correct pinmuxing AND have my loader program not 
fail which it currently here: 

 prussdrv_init();  
 if (prussdrv_open(PRU_EVTOUT_0) == -1) {  
  printf("prussdrv_open() failed\n");  
  return 1;  
 }  


With this example dts above I'm setting p8_46 to mode 0x25 successfully, 
but I find this in my dmesg now (and guess it's not good): 

pruss_uio 4a30.pruss: No children


Which still needs some work to figure out. Might give one of the later 
kernels a try, or something else. I think I'm nearly there though. 

Thanks - Joseph. 

On Saturday, July 16, 2016 at 6:40:37 PM UTC+2, William Hermans wrote:
>
> I was going to look into this yesterday, but did not for personal reasons. 
> Anyway, no idea whom you're speaking to( I do not see all posts on this 
> group ), but it does not matter what Robert demonstrated. From the 
> information given fro Robert's post. It's clear to at least me that 
> uio_pruss is supposed to have zero issues working, it just needs to be 
> "hooked up".
>
> So, unless this person you're speaking to can show you exactly how to set 
> up uio_pruss on the newer TI kernels . . . Then just ignore that person, as 
> he / she has no idea what they're talking about.
>
> I should have time today to test this myself and it won't take all day. 
> Maybe an hour.
>
> On Sat, Jul 16, 2016 at 1:18 AM, Joseph Heller  > wrote:
>
>> That sound like choosing either:
>>
>> "Robert didn’t use overlays"
>> or
>> "all you need to do is load the PRU overlay file to get uio_pruss working"
>>
>> Not done here yet with trying both options, but took me a day so far 
>> stretching my patience in reality.
>>
>> --> Is there a kernel or preferably an image that's working right away 
>> with uio_pruss?
>>
>> I see some discussion in another post with Robert explains that ti 
>> started working on remoteproc somewhere around 4.1 kernels. So I hope 
>> actually to save time with an off-the-shelve alternative around that period 
>> with uio being the standard, so question here is if there's an advice along 
>> that path?
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>>

[beagleboard] Where to find release notes of the images (and kernel)?

[Joseph Heller]

Could not find the answer yet, so posting it here: 

Where to find release notes of the beaglebone images (and kernel)? Assuming 
they are somewhere, are they?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3d6c395c-faa0-4f54-8258-55ed7653aa21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

That sound like choosing either:

"Robert didn’t use overlays" 
or 
"all you need to do is load the PRU overlay file to get uio_pruss working"

Not done here yet with trying both options, but took me a day so far stretching 
my patience in reality.

--> Is there a kernel or preferably an image that's working right away with 
uio_pruss? 

I see some discussion in another post with Robert explains that ti started 
working on remoteproc somewhere around 4.1 kernels. So I hope actually to save 
time with an off-the-shelve alternative around that period with uio being the 
standard, so question here is if there's an advice along that path?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8024d3c1-9ce9-41e0-bb82-4bd16a8eb1b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Did not get uio driver up and running yet, is this still an issue on the 
4.4 kernel? I did not see a confirmation reading this 
 
post either. Tried both loading via device tree (uio_pruss_enable) or plain 
insmod uio_pruss. 

I wonder if using a 4.1 kernel a safer bet in that respect?

On Wednesday, July 13, 2016 at 10:19:11 PM UTC+2, William Hermans wrote:
>
> By the way, TI's most recent kernels are purportedly supposed to use 
> either remoteproc, or uio_pruss. I say purportedly because I have not 
> personally experimented with that yet, but Robert made a post not long ago 
> about this. So it sounds like right off the bat, all you need to do is load 
> the PRU overlay file to get uio_pruss working. Or a slightly more involved 
> process to get remoteproc working.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a8f3c97d-28f9-4e0f-8c5f-fb5dbd1503cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Sorry for any confusion, but I'd like to use uio 

On Thursday, July 14, 2016 at 7:50:58 PM UTC+2, john3909 wrote:

> Overlay for Remoteproc doesn’t work so you must follow Roberts 
> instructions to select between rproc or uio:
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e3e5b4bf-74a2-44e0-8e30-16b7d545afdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

On Thursday, July 14, 2016 at 8:18:37 PM UTC+2, William Hermans wrote:
>
> Well, I used apt-get install. I traced back the command entered when 
>> examining .bash_history:
>> *# sudo apt-get install linux-image-4.1.15-bone-rt-r18 *
>
>
> So you say it just failed, and when you examined the second stage uEnv.txt 
> file the uname_r variable had not changed to reflect the upgrade ? What 
> kind of power supply are you using, and how  much do you have running on 
> the board ?
>
> Anyway, using APT is the correct way to install a kernel on Debian. 
> Period. Not just for this hardware, but in general. So I would say that you 
> just experienced a glitch that is not usually that happens when upgrading. 
> But when I tell you that I've not experienced this myself in 3.5 years of 
> using this board . . . that's not entirely accurate. I've experienced a few 
> glitches here, and there. I just never dug into what happened. Instead I 
> just tried again, and it worked . . . So maybe nothing is 100% perfect, but 
> it does work if you keep at it.
>
> Heres a tip though. Whenever flashing a new image, or doing anythign like 
> upgrading the kernel. Disconnect, and / or turn off everything non 
> essential. Peripheral wise. ethernet, and eMMC should be fine, but passed 
> that turn every thing else off.
>

Thanks William, 

I dod not expext a failre either doing apt upgrade / installs of kernels 
either. Not sure about the uEnv.txt. My /boot directory shows:

bash-4.3$ ls -la
total 33192
drwxr-xr-x.  4 root root4096 Jul 11 18:04 .
drwxr-xr-x. 21 root root4096 Jan 24 23:38 ..
-rw-r--r--.  1 root root  134233 Jan 12  2016 config-4.1.15-bone-rt-r18
-rw-r--r--.  1 root root  154972 Jan 21 21:22 config-4.1.15-ti-rt-r43
drwxr-xr-x.  4 root root4096 Jul 11 18:03 dtbs
-rw-r--r--.  1 root root 4245828 Jul 11 18:04 initrd.img-4.1.15-bone-rt-r18
-rw-r--r--.  1 root root 4177318 Jun 20 12:12 initrd.img-4.1.15-ti-rt-r43
-rw-r--r--.  1 root root 4096241 Jun 15 19:26 
initrd.img-4.1.15-ti-rt-r43.old-dkms
-rw-r--r--.  1 root root 492 Jan 25 00:41 SOC.sh
-rw-r--r--.  1 root root 3034732 Jan 12  2016 System.map-4.1.15-bone-rt-r18
-rw-r--r--.  1 root root 3371694 Jan 21 21:22 System.map-4.1.15-ti-rt-r43
drwxr-xr-x.  2 root root4096 Jan 24 23:38 uboot
-rw-r--r--.  1 root root1652 Jul 11 18:04 uEnv.txt
-rwxr-xr-x.  1 root root 6932296 Jan 12  2016 vmlinuz-4.1.15-bone-rt-r18
-rwxr-xr-x.  1 root root 7800752 Jan 21 21:22 vmlinuz-4.1.15-ti-rt-r43
 
So uEnv.txt seems to be updated at the time by the apt-get install, and 
both the old and new kernel are available. Start of uEnv.txt is:

bash-4.3$ sudo head uEnv.txt 
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.1.15-bone-rt-r18
#uuid=
#dtb=

##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)

##BeagleBone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb


But, you mentioned something else, that got me thinking: after backing up 
the sd card and writing a new image to the sd-card, it failed first pass 
(no booting BBG whatsever I tried). Flashed the image again, and then my 
BBG booted. So now I start to suspect my sd card actually. Time for new sd 
card to make sure. I'll be watching the power supply as well; I'm using a 
6600 mAh Lipoly with an Adafruit 500mA Power charge and adapter (if 
interested: first glimpse of my project page here 
). I'm not 100% 
convinced on the power supply as well with occasional drops during booting. 
So maybe I'l go for micro-usb power supply for "mission critical" changes 
to the image to ensure correct upgrades and only use the battery when 
testing the entire setup with stepper drivers and motors. T
Thanks for your suggestions. 

Will check john3909's remarks later as well and see if I get the PRU's 
working with uio/prussdrv.h and the selected kernel. 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/03ba76ad-1d89-4c0d-877c-23f52b6dcdc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

On Wednesday, July 13, 2016 at 10:19:11 PM UTC+2, William Hermans wrote:
>
> By the way, TI's most recent kernels are purportedly supposed to use 
> either remoteproc, or uio_pruss. I say purportedly because I have not 
> personally experimented with that yet, but Robert made a post not long ago 
> about this. So it sounds like right off the bat, all you need to do is load 
> the PRU overlay file to get uio_pruss working. Or a slightly more involved 
> process to get remoteproc working.
>

Thanks for pointing that out! I think you are referring to this post I 
think: 
http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2Fl59Dx8ygxNg%2FGvIzOJSzDAAJ
 
? Need to check in detail what Robert mentioned in the post. I would have 
no problem reporting back if this leads to success, which might be 
something to materialize somewhere in the wiki and would be glad to help. I 
guess I was looking in the wrong spot trying to find info on the kernel 
(e.g. here  and the wiki and getting 
started guide referred in it), did not realize I had to search in the 
Forum. 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8d99efed-6eca-4689-bee4-3972df472c7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

On Wednesday, July 13, 2016 at 10:11:56 PM UTC+2, William Hermans wrote:
>
> The traditional Debian way, you use APT. Something like . . .
>
> *william@beaglebone:~/dev$ apt-cache search linux-image | grep 4.1.15-bone*
> linux-image-4.1.15-bone-rt-r17 - Linux kernel, version 4.1.15-bone-rt-r17
> linux-image-4.1.15-bone-rt-r18 - Linux kernel, version 4.1.15-bone-rt-r18
> linux-image-4.1.15-bone17 - Linux kernel, version 4.1.15-bone17
> linux-image-4.1.15-bone18 - Linux kernel, version 4.1.15-bone18
>
> *william@beaglebone:~/dev$ sudo apt-get install 
> linux-image-4.1.15-bone-rt-r18*
>

Well, I used apt-get install. I traced back the command entered when 
examining .bash_history:
*# sudo apt-get install linux-image-4.1.15-bone-rt-r18 *

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c473954b-b97c-45ed-8a1d-a7347b23dc7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Ok guys, here is my first question on how to change to another kernel 
version. I'm using a BBG for my omni-robot project, and started opting for 
using the PRU's to generate accurate variable frequency PWM signals for my 
stepper motors (my c code was still showing the occasional delays in 
frequency pulses due to the non-realtime nature of the kernel). At the 
time, I was using linux-image-4.1.15-bone-rt-r18. I'm not yet convinced to 
use the remoteproc driver to handle the PRU's, and would like to use the 
uio driver instead. It boils down to two questions in the end: 

1) is it possible to install another kernel image, and how is this done 
exactly? Unfortunately I managed to get my image on the sd-card unbootable 
when installing another kernel (bone-kernel instead of ti-kernel). I guess 
that uEnv.txt is not correctly updated when switching kernels. Actually I 
forgot to install the kernel headers in the same pass, and this lead to a 
series of upgrade errors maybe causing the booting issue. I might be able 
to restore my image somehow if possible, although I still can use the data 
by just inserting the SD card in my PC. 

That let me wonder secondly, I now downloaded a more recent sd-card image 
(bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img with 4.4.9-ti-r25 
kernel), but what does this image exactly contain? In the end I'm looking 
for a kernel version supporting PRU uio drivers enabling me to use the 
prussdrv.h in my c files. I understood that the bone-kernel is to be used 
instead of the ti-kernel, although when now having a quick peek into what 
drivers are actually loaded I see to my surprise uio_pdrv_genirq, so I 
guess the naming convention of "ti" kernels was changed somewhere in the 
past, although not entirely sure if this was correct in the first place.  

I made a dump of available kernels of this release, and shows a huge amount 
of kernels, which more or less show some understandable (but also less 
understandable) variations. There's for instance 
linux-image-4.4.9-ti-rt-r25
but also 
linux-image-4.4.9-bone-rt-r10
as well as
linux-image-4.4.9-armv7-rt-x7
and more flavours combinations. 

Here's my guess when reading some forum posts:
ti: (with remoteproc instead of uio PRU driver?)
bone: (with uio instead of remoteproc PRU driver?)
dbg: (meaning debug?)
rt: (meaning soft realtime?)

2) The "ti" version seems to be dropped starting the 4.5.0 series kernel, 
so I guess remoteproc was dropped in the end with newer kernels altogether?

So I think I'm fine with the new downloaded image but feels a bit fuzzy 
hit& miss if this is the correct one. Anyone some hints or tips where to 
find some more details on the kernel versioning?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e1904f5a-63b2-45fd-985e-2cb96c86fcb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.