Re: [beagleboard] IEP timer on PRUs on the Beaglebone AI and Beaglebone Black

[John Allwine]

I must have inadvertently set the CMP0_RST_CNT_EN bit on the COMPARE_CFG 
register on pr2. After setting that in the setup function, it works on both 
PRUs.

Does anyone know why the SR1.1 section is in the reference manual? Can the PRUs 
be configured to use SR1.1 over SR2.0?
 
> 
> I'm attempting to use the IEP timer on the PRUs on the Beaglebone AI (as 
> wells the BBB), but am a bit confused about the difference between SR1.1 and 
> SR2.0. The technical reference manual for the am572x has two separate 
> sections for the IEP, one for SR1.1 and one for SR2.0. I implemented two 
> different PRU programs that implement the basic programming sequence 
> described in section 30.1.11.2.2.3 (for SR2.0) and section 30.2.11.2.2.3 (for 
> SR1.1):
> 
> SR2.0 program: 
> https://github.com/PocketNC/cloud9-examples/blob/iep_tests/BeagleBone/AI/pru/blinkExternalLEDWithIEPTimer.pru2_0.c
> SR1.1 program: 
> https://github.com/PocketNC/cloud9-examples/blob/iep_tests/BeagleBone/AI/pru/blinkExternalLEDWithIEPTimer.pru1_1.c
> 
> I haven't tested the SR1.1 program on the Beaglebone Black, but I've been 
> debugging programs that seem to initialize the IEP using that method, so I 
> believe it should work on the BBB. The SR1.1 program does not work on any of 
> the prus on the Beaglebone AI. The SR2.0 program only seems to work on pr2_0 
> and pr2_1 on the Beaglebone AI. Why doesn't it work on pr1_0 and pr1_1?
> 
> I'd appreciate any information that could explain the difference between 
> SR1.1 and SR2.0 and the IEP Timers on the PRU with respect to the BBB vs the 
> BBAI. 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/9b02e8f2-b0a2-4799-89c6-62f3b319e7a1%40googlegroups.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/99D6516E-3596-413F-B7C8-A26313D3029B%40allwinedesigns.com.

Re: [beagleboard] new kernel with old .config

[Robert Nelson]

On Wed, Apr 15, 2020 at 5:59 PM pavel havlik  wrote:
>
> Hello
>
> It's not quite clear to me, how to recompile kernel with desired .config file.
> I have .config file from current kernel and I'd like to use it with the newly 
> compiled kernel by means of ./build_kernel.sh script from RobertCNelson in 
> package ti-linux-kernel-dev.
>
> .
> I don't know if I should overwrite ti-linux-kernel-dev/KERNEL/.config or 
> ti-linux-kernel-dev/patches/defconfig.

Well, "./build_kernel.sh" copies ti-linux-kernel-dev/patches/defconfig
->  ti-linux-kernel-dev/KERNEL/.config

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/CAOCHtYjF08OkFABX1jAZWjeR_ZeGPT1huZ%3DqKetTfyvd-4jvWg%40mail.gmail.com.

[beagleboard] new kernel with old .config

[pavel havlik]

Hello

It's not quite clear to me, how to recompile kernel with desired .config 
file.
I have .config file from current kernel and I'd like to use it with the 
newly compiled kernel by means of ./build_kernel.sh script from 
RobertCNelson in package ti-linux-kernel-dev. .
I don't know if I should overwrite ti-linux-kernel-dev/KERNEL/.config or 
ti-linux-kernel-dev/patches/defconfig.

Thank you for any help.

Regards
Pavel

-- 
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/59e03942-42e3-4fa5-bb6a-55fd79c5d1e0%40googlegroups.com.

Re: [beagleboard] beaglebone black with CONFIG_SMP

[Robert Nelson]

On Wed, Apr 15, 2020 at 4:08 PM pavel havlik  wrote:
>
> Hello
>
> I have following kernel on my BeagleBone black:
>
> Linux beaglebone 4.19.94-ti-r37 #1buster SMP PREEMPT Fri Mar 13 20:56:28 UTC 
> 2020 armv7l GNU/Linux
>
> Why is it compiled as SMP (CONFIG_SMP) when Sitara ARM Cortex-A8 has only one 
> core?

Correct, SMP is enabled in the default shipping kernel.

As that kernel is also what we ship by default for the BeagleBoard-X15
and BeagleBone-AI which are a dual core Cortex-A15's..

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/CAOCHtYg_qXUVpeJzM-c2aawx_6DJ8%3D864r06jebsppT1%2BjRh0A%40mail.gmail.com.

[beagleboard] Re: segmentation fault PRU

[hellobaranch]

Thanks! I will definitely study your links

среда, 15 апреля 2020 г., 21:15:31 UTC+3 пользователь Dennis Bieber написал:
>
> o/~Talking to myself in publico/~ 
>
> On Wed, 15 Apr 2020 10:20:13 -0400, in 
> gmane.comp.hardware.beagleboard.user 
> Dennis Lee Bieber  > 
> wrote: 
>
> >Which edition of the book? Probably first edition since page 525 
> in my 
> >2nd edition has a figure 11-11 about GMail Security Settings. The PRU is 
> >covered in chapter 15, starting at page 673. 
> > 
>
> Note that first edition has a copyright in 2015. That is Debian 
> 7.x 
> timeframe -- AKA Wheezy while... 
>
> > 
> >>dogtag:[BeagleBoard.org Debian Image 2018-10-07] 
> > 
> >That's a somewhat old image... 
> > 
>
> ...that is Debian 9.5 -- AKA Stretch. 
>
> There have been a number of significant changes since the first 
> edition 
> book came out. 
>
> Debian is phasing out sys-v init for systemd 
>
> UIO PRU access phased out for remoteproc by default. Refer to 
> http://catch22.eu/beaglebone/beaglebone-pru-uio/ for candidate 
> instructions 
> on enabling UIO (though those instructions are based upon ONE Debian 8.x 
> -- 
> Jessie image -- Implication is that images newer than 8.6 only function 
> with remoteproc unless one changes the OS kernel). Similar instructions at 
> https://github.com/sbarral/prusst 
>
> Consider 
>
> https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/05/14/coding-for-the-beaglebone-pru-with-c-in-2019
>  
> which is based on Debian 9.5 -- using remoteproc, or 
>
> http://ianrrees.github.io/2016/11/20/getting-started-with-beaglebone-pru-programming-the-new-way.html
>  
>
>
> OTOH, it may be something as simple as needing to run using sudo 
> (as 
> mentioned about halfway down http://exploringbeaglebone.com/chapter15/ [a 
> lot of the commentary on that page applies to first edition based upon the 
> date stamps -- a big jump from June 2016 to March 2019 when the 2nd 
> edition 
> came out]) 
>
>
>
> -- 
> Dennis L Bieber 
>
>

-- 
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/eace29c6-fe9b-41fa-80b4-58b27dd9e3a1%40googlegroups.com.

[beagleboard] beaglebone black with CONFIG_SMP

[pavel havlik]

Hello

I have following kernel on my BeagleBone black:

Linux beaglebone 4.19.94-ti-r37 #1buster SMP PREEMPT Fri Mar 13 20:56:28 
UTC 2020 armv7l GNU/Linux

Why is it compiled as SMP (CONFIG_SMP) when Sitara ARM Cortex-A8 has only 
one core?

Thank you
Ragards
Pavel

-- 
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/443b3024-f034-4ef6-8e52-061a9b171f9d%40googlegroups.com.

[beagleboard] IEP timer on PRUs on the Beaglebone AI and Beaglebone Black

[john]

I'm attempting to use the IEP timer on the PRUs on the Beaglebone AI (as 
wells the BBB), but am a bit confused about the difference between SR1.1 
and SR2.0. The technical reference manual for the am572x 
 has two separate sections 
for the IEP, one for SR1.1 and one for SR2.0. I implemented two different 
PRU programs that implement the basic programming sequence described in 
section 30.1.11.2.2.3 (for SR2.0) and section 30.2.11.2.2.3 (for SR1.1):

SR2.0 program: 
https://github.com/PocketNC/cloud9-examples/blob/iep_tests/BeagleBone/AI/pru/blinkExternalLEDWithIEPTimer.pru2_0.c
SR1.1 program: 
https://github.com/PocketNC/cloud9-examples/blob/iep_tests/BeagleBone/AI/pru/blinkExternalLEDWithIEPTimer.pru1_1.c

I haven't tested the SR1.1 program on the Beaglebone Black, but I've been 
debugging programs that seem to initialize the IEP using that method, so I 
believe it should work on the BBB. The SR1.1 program does not work on any 
of the prus on the Beaglebone AI. The SR2.0 program only seems to work on 
pr2_0 and pr2_1 on the Beaglebone AI. Why doesn't it work on pr1_0 and 
pr1_1?

I'd appreciate any information that could explain the difference between 
SR1.1 and SR2.0 and the IEP Timers on the PRU with respect to the BBB vs 
the BBAI. 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/9b02e8f2-b0a2-4799-89c6-62f3b319e7a1%40googlegroups.com.

[beagleboard] Re: segmentation fault PRU

[Dennis Lee Bieber]

o/~ Talking to myself in public o/~

On Wed, 15 Apr 2020 10:20:13 -0400, in gmane.comp.hardware.beagleboard.user
Dennis Lee Bieber 
wrote:

>   Which edition of the book? Probably first edition since page 525 in my
>2nd edition has a figure 11-11 about GMail Security Settings. The PRU is
>covered in chapter 15, starting at page 673.
>

Note that first edition has a copyright in 2015. That is Debian 7.x
timeframe -- AKA Wheezy while...

>
>>dogtag:[BeagleBoard.org Debian Image 2018-10-07]
>
>   That's a somewhat old image...
>

... that is Debian 9.5 -- AKA Stretch.

There have been a number of significant changes since the first edition
book came out.

Debian is phasing out sys-v init for systemd

UIO PRU access phased out for remoteproc by default. Refer to
http://catch22.eu/beaglebone/beaglebone-pru-uio/ for candidate instructions
on enabling UIO (though those instructions are based upon ONE Debian 8.x --
Jessie image -- Implication is that images newer than 8.6 only function
with remoteproc unless one changes the OS kernel). Similar instructions at
https://github.com/sbarral/prusst

Consider
https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/05/14/coding-for-the-beaglebone-pru-with-c-in-2019
which is based on Debian 9.5 -- using remoteproc, or
http://ianrrees.github.io/2016/11/20/getting-started-with-beaglebone-pru-programming-the-new-way.html


OTOH, it may be something as simple as needing to run using sudo (as
mentioned about halfway down http://exploringbeaglebone.com/chapter15/ [a
lot of the commentary on that page applies to first edition based upon the
date stamps -- a big jump from June 2016 to March 2019 when the 2nd edition
came out])



-- 
Dennis L Bieber

-- 
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/6lfe9ftb3e78aea2qgmqje77q35dss8bc0%404ax.com.

Re: [beagleboard] Install FreeBSD on beaglebone black

['Mark Lazarewicz' via BeagleBoard]

Hi Andrew
Virtual have improved as well as the quirky USB driver issues. The low end JTAG 
are around $100.A dual boot window/ Linux is also a great way bro repurpose any 
old Intel Box) laptop you can scrounge.
Also C66x stand-alone board's are quite cheap if you want to pick up DSP.
I have an omap l138x board I bought while working on a high end motor 
controller. That product used Green Hills on the ARM and had its own messaging 
systems between ARM and DSP quite an amazing Product. Images for DSP & ARM 
could be dragged and dropped via NFS. The control theory stuff on the DSP was 
way out of my league PhD types designed it. DSP Ran DSP Bios at a very fast 
clock rate. The PRU s were used as more on-board peripherals. It supported JTAG 
debug CCS and greenhill probe with the GHS source level debugger.What's sad is 
once the parrellel processing was working. A serial Port dump of shared RAM via 
a PRU UART provided debug info. It really gets hard to debug something in 
realtime beyond board bring up on these multicore Soc using JTAG.
Hopefully they port TI RTOS SDK to BBAI 
Good luck

Sent from Yahoo Mail on Android 
 
  On Tue, Apr 14, 2020 at 4:18 PM, Andrew Reilly wrote: 
  Hi Mark,
Re: JTAG + code composer right to the DSP:
That does seem to be the main support path that TI is providing at the moment, 
but runs foul of two impediments for me: JTAG emulator dongles tend to the 
expensive side, for home hacking activities, and Code Composer for macOS 
doesn't support the DSPs.  Which is weird, IMO, because the stand-alone C66x 
toolchain is available for macOS, and seems to work fine.  I suspect that the 
issue probably boils down to emulators that work with the DSPs don't have 
drivers for macOS, and without that CCS isn't much help.
If it became absolutely the only option, I could move to a Windows system, but 
until it does, I'd prefer not to.  I seem to have developed an allergy to it, 
over the years :-)
The other option that I'm pursuing is getting the Linux version up, in some 
kind of virtual machine, but I thought that I was doing pretty well with the 
self-hosted BBAI tools, so far.  At least for tinkering.
Cheers,
Andrew Reilly
M: +61-4-0982-4272

On 15 Apr 2020, at 00:04 , 'Mark Lazarewicz' via BeagleBoard 
 wrote:
Hello Andrew
# On the other hand, the reason that I have the #BBAI is to play with some DSP 
on the C66x cores, 

Why not use JTAG + code composer right to the DSP You obviously wouldn't have 
the Unix to DSP part for a product but you could play with DSP and sort out 
rest later

Sent from Yahoo Mail on Android 
 
  On Mon, Apr 13, 2020 at 5:00 PM, Andrew Reilly wrote: 
  FreeBSD isn't what runs on the Apple Mac as such.  The Mac kernel, "Darwin", 
is derived from the CMU Mach microkernel research, with a BSD-derived kernel 
running as a single-server, rather than a multi-server configuration (like 
minix or QNX).  In the CMU days, before NeXT, that was based on the original 
4.2BSD distribution, but I believe that it's been spruced up a bit in the macOS 
days with (at least) FreeBSD's virtual memory subsystem and network stack, and 
a chunk of NetBSD-derived other pieces.  The device drivers still live outside 
BSD, in Mach "DriverKit" land, which is why they're C++.  The user-land is 
mostly FreeBSD, and has had several refreshes over the years.
FreeBSD itself doesn't have a microkernel: it's old-school unikernel all the 
way down to the hardware, and the device drivers live in /usr/src/sys/modules 
or there-abouts.  Sure, there almost certainly aren't as many useful-for 
beaglebone drivers in there.  The OS was x86 and x86_64 only for a significant 
chunk of its life.  People who wanted BSD-on-toaster were shown where to find 
NetBSD.  I'm not entirely sure why that's changed, but my guess is that people 
wanted "big iron" OS to run on their big-iron Sparc, Power and now Arm systems.
Why would you want to do that?  I can only speak for myself, but it's more a 
case of not ever changing what wasn't broken: I've been running BSD since about 
1986 or so.  If you say that it's possible to get FreeBSD to boot on my 
beaglebone-AI, then I might just give it a go!  On the other hand, the reason 
that I have the BBAI is to play with some DSP on the C66x cores, and the 
interface drivers seem kernel-version fragile, and all of the TI tools are 
clearly set up for Linux, so perhaps I'll just sit tight for now.  I'm still 
trying to come to terms with a system that doesn't install the source and 
headers by default, which doesn't do "netstat" properly, which has all of these 
system-* commands, and which seems to bork it's USB-audio stack when left open 
but unused for long periods.  Tracking down slow ephemerons or heisenbugs is 
about the least fun part of programming, IMO.
I'm currently trying to wrap my head around the OpenCL-ness of the DSP access.  
I was expecting something in DSPBios with a mailbox system to the host, and 
perhaps that's there under the covers, but all of the 

[beagleboard] Re: segmentation fault PRU

[Dennis Lee Bieber]

On Tue, 14 Apr 2020 12:24:32 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
hellobaranch-re5jqeeqqe8avxtiumw...@public.gmane.org wrote:

>Hello! I'm trying to use PRU for PWM with am335x_pru_package 
>( https://github.com/beagleboard/am335x_pru_package ). I use code from a 
>book Derek Molloy (Listing 13.6, page 525; if you need code i can send 

Which edition of the book? Probably first edition since page 525 in my
2nd edition has a figure 11-11 about GMail Security Settings. The PRU is
covered in chapter 15, starting at page 673.


>dogtag:[BeagleBoard.org Debian Image 2018-10-07]

That's a somewhat old image...

>bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>2018.09-2-g0b54a51eee]:[location: dd MBR]
>kernel:[4.14.71-ti-r80]
>nodejs:[v6.14.4]

dogtag:[BeagleBoard.org Debian Image 2019-08-03]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
2019.04-2-gbb4af0f50f]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2019.04-2-gbb4af0f50f]:[location: dd MBR]
kernel:[4.14.108-ti-r113]
nodejs:[v6.17.0]

(Note: booting from SD card)

>uboot_overlay_options:[enable_uboot_overlays=1]
>uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
>uboot_overlay_options:[enable_uboot_cape_universal=1]
>pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
>]
>pkg:[bb-cape-overlays]:[4.4.20180928.0-0rcnee0~stretch+20180928]
>pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
>pkg:[kmod]:[23-2rcnee1~stretch+20171005]
>pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
>pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
>groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
>plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
>admin spi tisdk weston-launch xenomai]
>cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>net.ifnames=0 quiet]
>dmesg | grep pinctrl-single
>[1.119780] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
>568
>dmesg | grep gpio-of-helper
>[1.131811] gpio-of-helper ocp:cape-universal: ready
>
>END

Might be significant that nothing lists the PRUs in that... Compare...

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M
net.ifnames=0 rng_core.default_quality=100 quiet]
dmesg | grep remote
[1.306197] remoteproc remoteproc0: wkup_m3 is available
[1.394863] remoteproc remoteproc0: powering up wkup_m3
[1.394979] remoteproc remoteproc0: Booting fw image
am335x-pm-firmware.elf, size 217168
[1.399441] remoteproc remoteproc0: remote processor wkup_m3 is now up
[   25.652003] remoteproc remoteproc1: 4a334000.pru is available
[   25.659497] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pru
[   25.622919] pruss 4a30.pruss: creating PRU cores and other child
platform devices
[   25.652003] remoteproc remoteproc1: 4a334000.pru is available
[   25.652130] pru-rproc 4a334000.pru: PRU rproc node
/ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
[   25.659497] remoteproc remoteproc2: 4a338000.pru is available
[   25.659623] pru-rproc 4a338000.pru: PRU rproc node
/ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully
dmesg | grep pinctrl-single
[0.949560] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size
568
dmesg | grep gpio-of-helper
[0.962136] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

NOTE: I've never used the PRUs (I really need to go through the Molloy
books [BBB and R-Pi]), so don't have any idea what dummy process is running
on the PRUs above. Secondary note: not shown but I appear to have also
turned off the HDMI or that is inherent in the IoT image.


-- 
Dennis L Bieber

-- 
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/b05e9fhaa60ovo0s98rfgrno3ouimirfi6%404ax.com.