Re: [beagleboard] Boot on power BB-x15

[Joseph Tarnow]

Sweet thank you! It took me an embarrassingly long time to find J5.. I was 
looking over by J3,4,6, turns out its in the middle between U5, U18. 

It works well!

On Tuesday, February 9, 2021 at 9:18:54 AM UTC-8 RobertCNelson wrote:

> On Tue, Feb 9, 2021 at 11:13 AM Joseph Tarnow
>  wrote:
> >
> > Howdy dudes and dudettes,
> >
> > I have a Beagleboard x15, and I am trying to make it boot on power, so 
> if I lose power the board will start when power resumes. I found this 
> thread, but couldn't make sense of it. Perhaps my google foo is bad, but I 
> couldn't find anything else. Does anyone know how to do this?
>
> Here's a quick answer.. Users debugging with JTAG have the same issue
> as above..
>
> So look at your board, find J5, then proceed to solder the two holes
> together with a wire..
>
> But here's the warning.. If you boot with a blank eMMC and a blank
> microSD, so U-BOOT does NOT LOAD... Given enough time with this
> situation you will destroy the AM57xx and it'll never boot again...
>
> 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/7b14a3e3-e6a1-44db-a894-64b828156129n%40googlegroups.com.

[beagleboard] Boot on power BB-x15

[Joseph Tarnow]

Howdy dudes and dudettes,

I have a Beagleboard x15, and I am trying to make it boot on power, so if I 
lose power the board will start when power resumes. I found this 
 thread, but 
couldn't make sense of it. Perhaps my google foo is bad, but I couldn't 
find anything else. Does anyone know how to do this?

-- 
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/a0bda19e-6928-4295-b44a-401151635d68n%40googlegroups.com.

[beagleboard] Re: External audio codec for BB AI via I2S interface

[Joseph]

Hello,
   Now the codec and driver work well (certainly the configuration can be 
optimized). Below is the corrected part of the dts file and other 
information.
   All the best
Joseph

-
Corrected part of the dts file:
/{
sound {compatible = "simple-audio-card";
simple-audio-card,format = "dsp_a";
simple-audio-card,name = "wm8960-soundcard";
simple-audio-card,bitclock-master = <>;
simple-audio-card,frame-master = <>;
simple-audio-card,convert-rate = <48000>;
simple-audio-card,mclk-fs = <512>;
status = "okay";
simple-audio-card,widgets =
"Line", "Line In",
"Headphone", "Headphone Jack";
simple-audio-card,routing =
"Headphone Jack", "HP_L",
"Headphone Jack", "HP_R",
"LINPUT2", "Line In",
"RINPUT2", "Line In";
simple-audio-card,cpu {
sound-dai = <>;
};
sndcodec: simple-audio-card,codec {
  sound-dai = <>;
};
};
};

 {  
 status = "okay";  
 clock-frequency = <40>;  
 pinctrl-names = "default";  
 pinctrl-0 = <_pins>;  

 wm8960: wm8960@1a{
 status = "ok"; 
 #sound-dai-cells = <0>; 
 compatible = "wlf,wm8960";  
 reg = <0x1a>;
 };
};

 {
#sound-dai-cells = <0>;
status = "okay";
pinctrl-names = "default";  
pinctrl-0 = <_pins>;  
op-mode = <0>;/* MCASP_IIS_MODE */
tdm-slots = <2>;
/* 16 serializers */
serial-dir = </* 0: INACTIVE, 1: TX, 2: RX */
0 0 0 0
0 0 0 0
0 0 1 2   /* axr10 - TX, axr11 – RX */
0 0 0 0 >;
tx-num-evt = <1>;
rx-num-evt = <1>;
};

debian@beaglebone:/var/lib/cloud9$ dmesg | grep -i sound


[0.576402] Advanced Linux Sound Architecture Driver Initialized.
[   49.744107] asoc-simple-card sound: wm8960-hifi <-> 4846.mcasp 
mapping ok

debian@beaglebone:/var/lib/cloud9$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: H5804encode [HDMI 5804.encoder], device 0: HDMI 
5804.encoder snd-soc-dummy-dai-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: wm8960soundcard [wm8960-soundcard], device 0: 
davinci-mcasp.0-wm8960-hifi wm8960-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

alsamixer was used to configure the codec parameters and then the following 
commands were succesfully tested: aplay, arecord, speaker-test, alsaloop. 
Also commands "i2cset -f -y 3 0x1a 0xuu 0xvv" (where uu and vv are 
hexadecimal values) can be used to directly set up some codec registers.


-- 
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/49d36c3b-afea-4161-a943-9b0f3d7ebd73%40googlegroups.com.

[beagleboard] ALSA simple sound card on BB AI via mcasp (i2s)

[Joseph]

Hello,
   Does the latest Linux image for BB AI have the kernel compiled with 
enabled option "Asoc simple sound card support"? I have some problems with 
loading driver for the section \{sound {compatible = "simple-audio-card";  
..., declared in dts file. How can I check that this option is enabled?
   Joseph

-- 
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/2c7559aa-1104-4626-ab91-7d5cd08bc294%40googlegroups.com.

[beagleboard] BeagleBone as USB gamepad HID

[Joseph Foster]

I was wanting to build a homemade gamepad or HOTAS using a BeagleBone Black 
or Pocket. It will be written in C++. I was wondering if there are any 
libraries that will let me use the board as a USB HID client for this 
purpose. Also would I be able to just use a USB A to A to the already 
onboard USB A port, or do I need to wire up to some pins.

-- 
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/86d8c79a-d45f-4bf0-ae93-129f203f22ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Use a Beaglebone as a USB client for HID

[Joseph Foster]

I am wanting to use a Beaglebone (green) as a USB client for HID input as a 
personal project. Can the Beaglebone do this out of the box with certain 
pin setup? If so what libraries can I use to do this? PRU is always an 
option if I have to, but I'd rather not learn in depth the USB protocol at 
this time. If the board can't do this out of box, is there an IC I can use 
to make a custom cape?

-- 
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/2f25f12f-8ae4-45cc-85ca-99b4845a6fc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] prussdrv_open() on new debian kernel

[Joseph Foster]

[sudo] password for debian:
git:/opt/scripts/:[e5c23dc2a45f5c9ace291dd32e7c3d79edc1932d]
eeprom:[A335BNLTGW1ABBGW17052298]
model:[TI_AM335x_BeagleBone_Green_Wireless]
dogtag:[BeagleBoard.org Debian Image 2017-11-26]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2017.11-2-g7b415acfc1]
kernel:[4.14.3-bone5]
nodejs:[v6.12.0]
device-tree-override:[uboot_overlay_addr0=/lib/firmware/am335x-boneblack-nhdmi-overlay.dtb]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/am335x-boneblack-nhdmi-overlay.dtb]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20171120.0-0rcnee1~stretch+20171120]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]



On Saturday, December 2, 2017 at 2:14:58 PM UTC-6, RobertCNelson wrote:
>
> On Sat, Dec 2, 2017 at 2:20 AM, Joseph Foster 
> <joseph.f...@gmail.com > wrote: 
> > When setting config-pin P8.11 pruout, I get bash: 
> > /sys/devices/platform/ocp/ocp*P8_11_pinmux/state: No such file or 
> directory 
> > . Is there a specific overlay I need to use, my custom ones don't seem 
> to 
> > work and the cape-universal-00A0.dtbo overlay locks my beagle into a 
> boot 
> > loop. 
>
> P8_11 should be auto loaded, lets' check out your: 
>
> sudo /opt/scripts/tools/version.sh 
>
> 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/7f3bd6de-abfb-4cd4-bdb3-9115d40900bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] prussdrv_open() on new debian kernel

[Joseph Foster]

When setting config-pin P8.11 pruout, I get bash: 
/sys/devices/platform/ocp/ocp*P8_11_pinmux/state: No such file or directory
. Is there a specific overlay I need to use, my custom ones don't seem to 
work and the cape-universal-00A0.dtbo overlay locks my beagle into a boot 
loop.

On Friday, December 1, 2017 at 9:14:55 PM UTC-6, RobertCNelson wrote:
>
> On Fri, Dec 1, 2017 at 8:59 PM, Joseph Foster 
> <joseph.f...@gmail.com > wrote: 
> > Ok so I am now load and execute on the PRUs, but how do I set the pinmux 
> for 
> > the PRUs. I think it would use the U-Boot Cape Universal but the load 
> > example uses slots. 
>
> you can use config-pin to mux in the pins for the pru... 
>
> 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/c498b97c-b216-43f3-a554-c766c5fef777%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Help resetting signal to reuse prussdrv_pru_send_event(ARM_PRU0_INTERRUPT);

[Joseph Foster]

I'm trying to reuse the prussdrv_pru_send_event(ARM_PRU0_INTERRUPT); 
function, but I can't reset the register for WBS r31,30

This is my PRU code:
Enter code here...// Origin 0 defines the start of the program in the
// PRU's instruction RAM, entrypoint is for debugging
#define CONST_PRUCFG C4
#define CONST_PRUSHAREDRAM   C28
 
#define PRU0_CTRL0x22000
#define PRU1_CTRL0x24000
 
#define CTPPR0   0x28
 
#define OWN_RAM  0x000
#define OTHER_RAM0x020
#define SHARED_RAM   0x00012000




.origin 0 // offset of the start of the code in PRU memory
.entrypoint START // program entry point, used by debugger only

#define PRU0_R31_VEC_VALID (1<<5)
#define SIGNUM 3 // corresponds to PRU_EVTOUT_0


START:
// initialize loop counter
WBS r31,30 //Wait for signal
MOV R16, SHARED_RAM
lbbo r1,r16,0,8
add r3,r1,r2
sbbo R3, R16, 8, 4
MOV r15,30
clr r31,r15
WBS r31,30 //Wait for signal
MOV R31.b0, PRU0_R31_VEC_VALID | SIGNUM
HALT

And this is the c:
Enter code here...#include 
#include 
#include 
#include 
#include 

#define PRU_SHARED_MEM_ADDR 0x00012000
#define SHM_OFFSET 2048

static int pru_cleanup(void) {
   int rtn = 0;

   /* clear the event (if asserted) */
   if(prussdrv_pru_clear_event(PRU_EVTOUT_0, PRU0_ARM_INTERRUPT)) {
  fprintf(stderr, "prussdrv_pru_clear_event() failed\n");
  rtn = -1;
   }

   /* halt and disable the PRU (if running) */
   if((rtn = prussdrv_pru_disable(0)) != 0) {
  fprintf(stderr, "prussdrv_pru_disable() failed\n");
  rtn = -1;
   }

   /* release the PRU clocks and disable prussdrv module */
   if((rtn = prussdrv_exit()) != 0) {
  fprintf(stderr, "prussdrv_exit() failed\n");
  rtn = -1;
   }

   return rtn;
}

static int pru_setup(const char * const path) {
   int rtn;
   tpruss_intc_initdata intc = PRUSS_INTC_INITDATA;

   if(!path) {
  fprintf(stderr, "pru_setup(): path is NULL\n");
  return -1;
   }

   /* initialize PRU */
   if((rtn = prussdrv_init()) != 0) {
  fprintf(stderr, "prussdrv_init() failed\n");
  return rtn;
   }

   /* open the interrupt */
   if((rtn = prussdrv_open(PRU_EVTOUT_0)) != 0) {
  fprintf(stderr, "prussdrv_open() failed\n");
  return rtn;
   }

   /* initialize interrupt */
   if((rtn = prussdrv_pruintc_init()) != 0) {
  fprintf(stderr, "prussdrv_pruintc_init() failed\n");
  return rtn;
   }

   /* load and run the PRU program */
   if((rtn = prussdrv_exec_program(0, path)) < 0) {
  fprintf(stderr, "prussdrv_exec_program() failed\n");
  return rtn;
   }

   return rtn;
}

volatile int32_t* init_prumem()
{
volatile int32_t* p;
prussdrv_map_prumem(PRUSS0_SHARED_DATARAM, (void**));
return p+SHM_OFFSET;
}

int main()
{
printf("Init PRU..\n");
int ret = pru_setup("PRUTest.bin");
if(ret == -1) return -1;
volatile int* shared_mem = init_prumem();
//usleep(100);
printf("Waiting for message...\n");
shared_mem[0] = 5;
shared_mem[1] = 10;
prussdrv_pru_send_event(ARM_PRU0_INTERRUPT);
int n = prussdrv_pru_wait_event(PRU_EVTOUT_0);
printf("Pru ended. Event: %i\n", n);
printf("Got number %d\n", shared_mem[2]);
pru_cleanup();
return 0;
}

In this example, the c code should never exit because the PRU code should 
be waiting for a second signal, but it does exit. How do I reset the signal 
so that I can reuse the interrupt?

-- 
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/d089cfe7-ae0f-4f5b-a156-22aafe573e39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] prussdrv_open() on new debian kernel

[Joseph Foster]

Ok so I am now load and execute on the PRUs, but how do I set the pinmux 
for the PRUs. I think it would use the U-Boot Cape Universal but the load 
example uses slots.

On Friday, December 1, 2017 at 10:52:30 AM UTC-6, RobertCNelson wrote:
>
> On Thu, Nov 30, 2017 at 11:45 PM, Joseph Foster 
> <joseph.f...@gmail.com > wrote: 
> > Where would the slots file now be located. Its not in the 
> > /sys/devices/platform/bone_capemgr/ directory for me 
>
> Slots file is disabled when using U-Boot Overlays: 
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays 
>
> 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/bae59066-3f03-4257-beb0-dc0281f5bc28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] prussdrv_open() on new debian kernel

[Joseph Foster]

Where would the slots file now be located. Its not in 
the /sys/devices/platform/bone_capemgr/ directory for me

On Thursday, November 30, 2017 at 10:55:35 PM UTC-6, RobertCNelson wrote:
>
>
>
> On Nov 30, 2017 10:33 PM, "Joseph Foster" <joseph.f...@gmail.com 
> > wrote:
>
> How do I upgrade to v4.14.x-bone, the update_kernel.sh only lists TI 
> kernels
>
>
> --bone-kernel --lts-4_14
>
>
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cc62315d-6760-486a-ad24-28b7412047e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] prussdrv_open() on new debian kernel

[Joseph Foster]

How do I upgrade to v4.14.x-bone, the update_kernel.sh only lists TI kernels

On Thursday, November 30, 2017 at 9:57:13 PM UTC-6, RobertCNelson wrote:
>
> On Thu, Nov 30, 2017 at 9:50 PM, Joseph Foster 
> <joseph.f...@gmail.com > wrote: 
> > I'm not sure really what librobotics is, and Debian 9.x (Stretch) would 
> be 
> > preferred. 
>
> Then pick your base: (bone-XYZ.img.xz files) 
>
> https://rcn-ee.net/rootfs/bb.org/testing/2017-11-26/ 
>
> Use etcher.io to create the microSD 
>
> Stretch ships with v4.9.x-ti which uses a new version of pru_remoteproc. 
>
> So either downgrade to v4.4.x-ti with pru_remoteproc that was used 
> with the BeagleBone Blue (and robotics stuff) 
>
> Or upgrade to v4.14.x-bone and utiilze uio_pruss (compabile with all 
> the old 3.8.x pru directions).. 
>
> Then finally configure all the pins how you want: 
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays 
>
> 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/3afe6a3b-d5f3-4afd-a7c8-3c365d9fbbad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] prussdrv_open() on new debian kernel

[Joseph Foster]

I'm not sure really what librobotics is, and Debian 9.x (Stretch) would be 
preferred. 

On Thursday, November 30, 2017 at 9:31:29 PM UTC-6, RobertCNelson wrote:
>
> On Thu, Nov 30, 2017 at 8:54 PM, Joseph Foster 
> <joseph.f...@gmail.com > wrote: 
> > sudo: /opt/scripts/tools/version.sh: command not found 
> > 
> > I'm running 4.4.30-ti-r64 
>
> "confused" ... you said: 
>
> "I've been trying for hours to get PRU working on the latest supported 
> kernel" 
>
> 4.4.30-ti-r64 release … 
> RobertCNelson committed on Nov 4, 2016 (11/4/2016 2:19:40 PM) 
>
> That's from last year.. "definitely not latest"... ;) 
>
> So let's decide on what you really want.. 
>
> OS: Debian 8.x (Jessie) 
> OS: Debian 9.x (Stretch) 
>
> PRU: 
>
> TI's remoteproc (v4.4.x-ti kernel, and used by librobotics') 
> Community: UIO (what we used in 3.8.x and ported to everything else) 
>
> So pick and option from OS and PRU and we'll point you to a new image 
> and kernel.. 
>
> 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/8125e958-bc0c-4080-95d6-9551d08dcba8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] prussdrv_open() on new debian kernel

[Joseph Foster]

sudo: /opt/scripts/tools/version.sh: command not found

I'm running 4.4.30-ti-r64

On Tuesday, November 28, 2017 at 11:50:05 AM UTC-6, RobertCNelson wrote:
>
> Hi Joseph, 
>
> On Mon, Nov 27, 2017 at 10:31 PM,  <joseph.f...@gmail.com > 
> wrote: 
> > I've been trying for hours to get PRU working on the latest supported 
> kernel 
> > on my BBGW and BBG. I've edited the .dtb and when I cat the slots, it 
> says 
> > its loaded, but every time I try to use the PRU, it fails on 
> > prussdrv_open(). Is there something different with the latest supported 
> > debian kernel I'm missing that changes how the PRUs work? When I try to 
> roll 
> > back the kernel, the beagle fails to boot. 
>
> We've recently moved to U-Boot overlays: 
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays 
>
> sudo /opt/scripts/tools/version.sh 
>
> What kernel did you use to use? 
>
> 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/9d6b9bfd-f218-4816-9a62-03944bd96a30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] prussdrv_open() on new debian kernel

[joseph . foster123]

I've been trying for hours to get PRU working on the latest supported 
kernel on my BBGW and BBG. I've edited the .dtb and when I cat the slots, 
it says its loaded, but every time I try to use the PRU, it fails on 
prussdrv_open(). Is there something different with the latest supported 
debian kernel I'm missing that changes how the PRUs work? When I try to 
roll back the kernel, the beagle fails to boot.

-- 
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/dc7b3c3c-a0da-4686-951d-de0f6fa7cbf6%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] 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] Beagle Board X-15 Restore OS

[Joseph]

Thanks so much Robert!  That worked like a charm, and those were easy to 
follow instructions.  
I got the OS restored!

On Monday, November 28, 2016 at 3:18:54 PM UTC-7, RobertCNelson wrote:
>
> On Mon, Nov 28, 2016 at 1:51 PM, Joseph <joseph...@borsight.com 
> > wrote: 
> > I have a Beagle Board X-15. 
> > 
> > I attempted to load Java on it, and ran out of space.  I read blogs, and 
> > followed an attempt to remove Java; but ended up with a beagle board 
> that 
> > only shows a blinking cursor on the terminal screen (and nothing more). 
> > 
> > I would like to load a new image on the Beagle Board X-15, and start 
> over. 
> > I found this page:  https://beagleboard.org/latest-images 
> > 
> > I clicked on the link for the X-15 (to load on my micro-SD card).  But 
> the 
> > link returns a 404 error. 
> > 
> > I'm also not sure how to put the new image on the board, since it 
> doesn't 
> > seem to have a button to hold down (like the beagle bone black does). 
> > 
> > Does anyone have experience with installing a new image on the X-15? 
> > Thanks, 
>
>
> https://rcn-ee.net/rootfs/bb.org/testing/2016-11-27/lxqt-4gb/bbx15-blank-debian-8.6-lxqt-4gb-armhf-2016-11-27-4gb.img.xz
>  
>
> use https://etcher.io/ to write to a microSD.. 
>
> 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/f423cf11-e71b-4775-b149-d2903a0d67be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beagle Board X-15 Restore OS

[Joseph]

I have a Beagle Board X-15.  

I attempted to load Java on it, and ran out of space.  I read blogs, and 
followed an attempt to remove Java; but ended up with a beagle board that 
only shows a blinking cursor on the terminal screen (and nothing more).  

I would like to load a new image on the Beagle Board X-15, and start over. 
 I found this page:  https://beagleboard.org/latest-images

I clicked on the link for the X-15 (to load on my micro-SD card).  But the 
link returns a 404 error.  

I'm also not sure how to put the new image on the board, since it doesn't 
seem to have a button to hold down (like the beagle bone black does). 

Does anyone have experience with installing a new image on the X-15? 
 Thanks,

Joseph 

-- 
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/92d5dd98-e7db-420e-9893-06538c33de17%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 <joseph.h...@gmail.com 
> > wrote:
>
>> Finally, that worked William ( )! 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.co

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 <joseph.h...@gmail.com 
> > wrote:
>
>> Finally, that worked William ( )! 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 ( )! 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 <robert...@gmail.com 
> > wrote:
>
>>
>>
>> On Mon, Jul 18, 2016 at 3:08 PM, Joseph Heller <joseph.h...@gmail.com 
>> > 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_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 <yyr...@gmail.com> 
>> 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 <yyr...@gmail.com> 
>>> 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 <yyr...@gmail.com> 
>>>> 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 Sa

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 <yyr...@gmail.com 
> > 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 <yyr...@gmail.com 
>> > 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 <yyr...@gmail.com 
>>> > 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 <robert...@gmail.com 
>>>> > wrote:
>>>>
>>>>> On Jul 16, 2016 11:57 AM, "Joseph Heller" <joseph.h...@gmail.com 
>>>>> > 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_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 = <_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 = <>;

__overlay__ {

pinctrl_generated_pinmux {

  compatible = "bone-pinmux-helper";

   pinctrl-names = "default";

   pinctrl-0 = <_generated>;

   status = "okay";

};

};

};


fragment@2 {

target = <>; 

__overlay__ { 

status = "okay"; 

pinctrl-names = "default";

pinctrl-0 = <_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 <joseph.h...@gmail.com 
> > 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
>> ---
>> You received this message because you are subscribed to the Google Group

[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.

[beagleboard] Free eBook copies of Packt's latest title Learning BeagleBone available for review

[Sandy Joseph]

Hi all,

My name is Sandy Joseph and I work for Packt.

I am pleased to let you all know that we have recently published a book 
titled, Learning BeagleBone 
https://www.packtpub.com/hardware-and-creative/learning-beaglebone
Comprising of just 206 pages,this book is ideal for new BeagleBone owners 
who are looking to quickly get their microboard up and running.


https://lh4.googleusercontent.com/-Qrc1w1tLKHQ/VQbbRIdJglI/Dug/OPT7sCR6tdU/s1600/Learning%2BBeagleBone.png













In case anyone is interested in checking out this title and posting a 
review on amazon.com and any other site of your choice within 12 days, 
please write to me at san...@packtpub.com. I'll be glad to provide you with 
a free eBook for your perusal. 

I look forward to your response and thanks for your time reading this mail.

Regards,
Sandy Joseph

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [BeagleBone] Timer error in capture mode

[joseph . thibodeau]

Hi David, Yogev,

If you either of you happen to have code for enabling Timer4 I'd much 
appreciate taking a look. I have mux'd Timer4 to the expansion header and 
I've written '1' to the TCLR ST bit, but so far no dice.

Many thanks,

Joseph

On Wednesday, August 14, 2013 3:04:42 PM UTC-4, Yogev Vaknin wrote:

 Hi,

 can you post the code ? i'm tring to do the same thing on beaglebone and i 
 have same problem.

 i think my muxing is fine since i do :
 echo 12  /sys/kernel/debug/omap_mux/gpmc_advn_ale 
 that should be same as  (IEN | MODE2)

 thanks

 On Monday, September 24, 2012 8:24:48 AM UTC+2, David wrote:


 Hi all,

 I have tested the DMTimer in the BeagleBone in free mode and compare mode 
 (with direct access to the registers) and all was fine (counter was fine 
 and interrupt was generated in compare mode).
 However, I have been trying to make the DMTimer work in capture mode and 
 I did not succeed at all. The dedicated input trigger seems not to work (no 
 interrupt is raised, and no values are loaded into the TCAR registers). I 
 have tried with TIMER4 (and TIMER7 later) pin in the BeagleBone.

 What I need is saving the current timer value into the TCAR registers 
 when a change/pulse in the timer dedicated input is detected.

 This is my configuration:

 Multiplex:
 Configure dedicated pin as TIMER4 peripheral (Should not be required as 
 this is the default configuration of BeagleBone)

 Interrupts: (I suppose this should be fine, as interrupt triggers in 
 compare mode)
 Set register INTC_ILR92 to 0 (max priority)
 Set bit 92%32 on INTC_MIR3 to 1 to enable interrupt

 DMTimer module:
 Disable timer: set TCLR to 0
 Re-load 0 in overflow: set TLDR to 0
 Clear initial count: set TCRR to 0
 Enable interrupt: set TIMER_IRQ_CAPTURE to IRQENABLE_SET -- value = 
 (12)
 Enable timer: set TIMER_START | TIMER_AUTORELOAD | TIMER_CAPTURE_RISING 
 to TCLR -- value = 1 | (11) | (18)
 Clear any pending associated interrupt.

 As a fallback solution I am now reading the free running timer value from 
 a GPIO interrupt handler that detects the change; however I would need the 
 most accurate timer value possible.

 Does anyone have an idea about what I am doing wrong?

 Thanks in advance.



-- 
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.
For more options, visit https://groups.google.com/d/optout.