Re: [beagleboard] Re: pru + 4.4 kernel?

[William Hermans]

>From my own perspective, it does not matter one single bit. I suscribe to
the beagleboard.org google group, i get all mails from that group. No idea
of sub groups, or whatever. . . .quite honestly I don;t even care. If i
know the answer or can give some clues, I'll answer, or give some clues.  .

On Fri, Dec 16, 2016 at 10:57 PM, Jay Doobie  wrote:

> I also just realized, I posted this in the BBB group, not the BBB wireless
> one.  It is a wireless BBB I just received the other day.
>
> On Friday, December 16, 2016 at 10:52:27 PM UTC-5, Jay Doobie wrote:
>>
>> Thanks, that is really sweet looking!  No matter what I do when I load my
>> DTO it doesn't seem to change the pinmux/ctrl values unfortunately.
>>  Everything in dmesg, journalctl acts as if it worked successfully, but I
>> see no change to the pinmux/ctlr.  Is there a kernel (or bone_capemgr)
>> level of debug?
>>
>> /Jason
>>
>>>
>>> > I have no idea what I did, but I'm back to nothing working and have
>>> been
>>> > unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my
>>> > program), nor am I able to have my DTO configure the pinmux anymore. Is
>>> > there a way to increase debug levels so I can see what is going on
>>> when it
>>> > tries to load my DTO?
>>>
>>> there's a handy script under:
>>>
>>> /opt/scripts/device/bone/
>>>
>>> sudo perl show-pins.pl
>>>
>>> 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/265b9483-7ba4-4ef5-a4bd-20a9cb91d84d%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/CALHSORriL4LwN_ynM4kwEQiz35YMCzquqYMDCBuVwOKGqFmJUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[William Hermans]

Jay,

So keep this in mind, 99% chance, what you've done, you've somehow screwed
up. Don't take this as a negative response please. But more or less a
realistic response. I've done "similar" myself. the whole time, I might be
thinking . .. "I'm going to let x.y.z have it on the groups . . ." only to
find that I totally screwed something up in the process.

Yeah do what I say, and completely 100% document what you do, as you do it.
Trust me, if you do not thank me for that, you will at least thank yourself
for it.

On Fri, Dec 16, 2016 at 8:52 PM, doobie  wrote:

> Thanks, that is really sweet looking!  No matter what I do when I load my
> DTO it doesn't seem to change the pinmux/ctrl values unfortunately.
>  Everything in dmesg, journalctl acts as if it worked successfully, but I
> see no change to the pinmux/ctlr.  Is there a kernel (or bone_capemgr)
> level of debug?
>
> /Jason
>
> On 16 December 2016 at 22:42, Robert Nelson 
> wrote:
>
>> On Fri, Dec 16, 2016 at 9:11 PM, Jay Doobie  wrote:
>> > I have no idea what I did, but I'm back to nothing working and have been
>> > unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my
>> > program), nor am I able to have my DTO configure the pinmux anymore. Is
>> > there a way to increase debug levels so I can see what is going on when
>> it
>> > tries to load my DTO?
>>
>> there's a handy script under:
>>
>> /opt/scripts/device/bone/
>>
>> sudo perl show-pins.pl
>>
>> 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/CAPXoZv97mhYP9eHUY%3DNrjhn6S4_%2BVwe-o_Pe5_XWU0P4G1SytA%
> 40mail.gmail.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/CALHSORq%2BWdanoxiO4fgPW107UfOXczvmBtpkXuJFeZAFbJ8oRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

I also just realized, I posted this in the BBB group, not the BBB wireless 
one.  It is a wireless BBB I just received the other day.

On Friday, December 16, 2016 at 10:52:27 PM UTC-5, Jay Doobie wrote:
>
> Thanks, that is really sweet looking!  No matter what I do when I load my 
> DTO it doesn't seem to change the pinmux/ctrl values unfortunately.   
>  Everything in dmesg, journalctl acts as if it worked successfully, but I 
> see no change to the pinmux/ctlr.  Is there a kernel (or bone_capemgr) 
> level of debug?
>
> /Jason
>
>>
>> > I have no idea what I did, but I'm back to nothing working and have been
>> > unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my
>> > program), nor am I able to have my DTO configure the pinmux anymore. Is
>> > there a way to increase debug levels so I can see what is going on when 
>> it
>> > tries to load my DTO?
>>
>> there's a handy script under:
>>
>> /opt/scripts/device/bone/
>>
>> sudo perl show-pins.pl
>>
>> 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/265b9483-7ba4-4ef5-a4bd-20a9cb91d84d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Barrel Connector on BBBWL not soldered on 5v Pin

[William Hermans]

Thats a case where you make the call.

On Fri, Dec 16, 2016 at 5:12 PM, Gregg Harrington  wrote:

> Is this a case I should RMA it? Or should I just solder it down?
>
> Thanks,
>
> Gregg
>
>
> On Friday, December 16, 2016 at 2:43:52 PM UTC-8, RobertCNelson wrote:
>>
>> On Fri, Dec 16, 2016 at 4:39 PM, Gregg Harrington
>>  wrote:
>> > I just tried to power my BBBWL through the barrel connector and wasn't
>> able
>> > to get it to power, when I looked at the bottom of the board, the
>> connector
>> > isn't soldered to the pad. When I short the pad to the pin, it boots up
>> and
>> > starts drawing power. Is this expected, did I get a weird board.
>>
>> Ah! Now it makes sense why the eeprom never got programmed!!!
>>
>> I bet your board was in the wrong pile at the factory...
>>
>> 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/6ba5eb4e-acfa-482a-88a8-68fecc5c63b4%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/CALHSORpyi2sqCjgCe7fFUz5-ERvsQUww34t6HyUNGVrRAp32wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[doobie]

Thanks, that is really sweet looking!  No matter what I do when I load my
DTO it doesn't seem to change the pinmux/ctrl values unfortunately.
 Everything in dmesg, journalctl acts as if it worked successfully, but I
see no change to the pinmux/ctlr.  Is there a kernel (or bone_capemgr)
level of debug?

/Jason

On 16 December 2016 at 22:42, Robert Nelson  wrote:

> On Fri, Dec 16, 2016 at 9:11 PM, Jay Doobie  wrote:
> > I have no idea what I did, but I'm back to nothing working and have been
> > unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my
> > program), nor am I able to have my DTO configure the pinmux anymore. Is
> > there a way to increase debug levels so I can see what is going on when
> it
> > tries to load my DTO?
>
> there's a handy script under:
>
> /opt/scripts/device/bone/
>
> sudo perl show-pins.pl
>
> 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/CAPXoZv97mhYP9eHUY%3DNrjhn6S4_%2BVwe-o_Pe5_XWU0P4G1SytA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Robert Nelson]

On Fri, Dec 16, 2016 at 9:11 PM, Jay Doobie  wrote:
> I have no idea what I did, but I'm back to nothing working and have been
> unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my
> program), nor am I able to have my DTO configure the pinmux anymore. Is
> there a way to increase debug levels so I can see what is going on when it
> tries to load my DTO?

there's a handy script under:

/opt/scripts/device/bone/

sudo perl show-pins.pl

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/CAOCHtYii9QYWrO%2B9cvkGrCjQyyeH93Ax8%3D6ZEzri8f8QAyb5eg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Help with PIR demo

[Chris Fink]

 

This is my first time using a BeagleBone Black (it's a Rev C), and I 
started out with the "Blink on-board LED 
" and "Blink 
external LED 
" demos, 
both of which worked perfectly. Then I advanced to the PIR Motion Sensor 
demo , and I'm 
quite certain I connected everything just as they said, but I can't seem to 
get it to work. 

At first the LED light turned on right away, and I got a constant 
succession of "Motion Detected" messages. Then I realized that the code 
assumed an active-LOW output from the PIR, but my PIR is active-HIGH 
, 
so I changed the lines 



*if(x.value === 0){  b.digitalWrite(led, 1); 
console.log("Motion Detected");*

to instead be



*if(x.value === 1){  b.digitalWrite(led, 1); 
console.log("Motion Detected");*

In this case the light does *not* come on, and I get a constant succession 
of "No Motion Detected" messages...and the PIR never detects motion, no 
matter how much I move, or how close I am. I even tried a different PIR 
 (also 
active-HIGH), and got the exact same results. I also tried removing the 
pull-up resistor, which also did not work.


Then I found this post...

https://groups.google.com/forum/#!searchin/beagleboard/pir%7Csort:relevance/beagleboard/ydD2Cyi5fJo/QK0jHa53NMgJ

...which makes me think that the demo isn't working because I'm not using 
the *exact* PIR sensor prescribed in the PIR Motion Sensor demo 
. If that is the 
case, where do I purchase that PIR sensor? I cannot find a link to it 
anywhere.


Thanks in advance for the help!



-- 
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/99a587e3-6068-47e6-946e-bc9584f302b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Possible to remove eeprom?

[Robert Nelson]

On Fri, Dec 16, 2016 at 6:29 PM, ferdster  wrote:
> We have a custom board based on a BBB. It has the eeprom on it, but we'd
> like to get rid of it.
>
> Initially, to bring up the board, we programmed the eeprom as a BBB. Now we
> want to remove it. I patched it with:
> https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2016.03/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
>
> Now it boots with an empty eeprom. I thought the patch would be enough, but
> after removing the eeprom from the board, I get nothing at all on the
> console.
>
> Something must be failing very early on in u-boot for it not to print
> anything.

Yeah, your going to have to dig deeper in u-boot, for beaglebone
clone's an eeprom on the i2c bus is expected..

You'll need to disable all those calls..

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/CAOCHtYjow2rJCZfn3-Lv-8ChOgPbyJa1ckznCpYdgAJoxkmw6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

I have no idea what I did, but I'm back to nothing working and have been 
unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my 
program), nor am I able to have my DTO configure the pinmux anymore. Is 
there a way to increase debug levels so I can see what is going on when it 
tries to load my DTO?

/jason 

On Friday, December 16, 2016 at 2:06:07 PM UTC-5, Jay Doobie wrote:
>
> Yeah, of course now the PRU died, which I had working before .time to 
> debug that again :)
>
> On Friday, December 16, 2016 at 2:00:53 PM UTC-5, William Hermans wrote:
>>
>>
>>
>> On Fri, Dec 16, 2016 at 11:55 AM, Jay Doobie  wrote:
>>
>>> Ya know, I figured out what happened, I wish things were a bit better 
>>> documented, what you indicated above about creating the initramfs fixed 
>>> it.  I believe what happened was I modifed the uEnv.txt file and thought it 
>>> took my changes, but it didn't.  I was running still with HDMI enabled and 
>>> that conflicted with my DTS.
>>>
>>> I'll have to reassemble the machine now (I took the board out to put on 
>>> a scope), but the values in the pinmux/pins file look correct now.
>>>
>>> /Jason
>>>
>>
>> Ah, yeah, that'll do it. One thing I always do when working with various 
>> things that take many commands to perform, and may easily be forgotten or 
>> messed up. Is to create a text file of exact steps I've done to achieve my 
>> end goal. Then when it comes to duplicating those steps, it turns into a 
>> copy paste session that usually succeeds. Which also gives me an easy way 
>> of creating a bash script later if needed. What just happened to you, 
>> forgetting ti disable the HDMI pins has happened to me before many times in 
>> the past . . .
>>
>>

-- 
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/3a5682de-f144-45d7-905a-2e91f46ceab2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Possible to remove eeprom?

[ferdster]

We have a custom board based on a BBB. It has the eeprom on it, but we'd 
like to get rid of it.

Initially, to bring up the board, we programmed the eeprom as a BBB. Now we 
want to remove it. I patched it with:
https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2016.03/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
 


Now it boots with an empty eeprom. I thought the patch would be enough, but 
after removing the eeprom from the board, I get nothing at all on the 
console.

Something must be failing very early on in u-boot for it not to print 
anything.

I believe that the Linux kernel will not need the eeprom and it's only used 
in u-boot to pick which .dtb to load, correct?

Thanks for the help!

-- 
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/0ceecfac-49d8-46d6-8ea7-20b8aaa9d017%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: SRM for BeagleBone Black Wireless

[Gregg Harrington]

I would still love to see the current SRM posted when it's available, but I 
don't think it's done. However, I have reviewed the schematics and found 
that the pins for the power are aligned the same. 





Here pins from the BBB Rev C








Here are the pins for the BBBWL


So 

BBBWL_TP2 = WWW_TP5
BBBWL_TP3 = WWW_TP6
BBBWL_TP4 = WWW_TP7
BBBWL_TP5 = WWW_TP8

Cheers,

Gregg


On Friday, December 16, 2016 at 1:13:44 PM UTC-8, Gregg Harrington wrote:
>
> Hello,
>
> Has the new SRM been published for the BeagleBone Black Wireless? 
> Specifically, I am trying to wire into the TP headers for power management, 
> I noticed the name of the pins has changed and wanted to confirm that they 
> are the same with the SRM. 
>
> If so, could someone link to it?
>
> Thanks,
>
> Gregg
>
>
 

-- 
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/fcf1b62a-872a-4aaa-87e9-a89ca8c48c78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Barrel Connector on BBBWL not soldered on 5v Pin

[Gregg Harrington]

Is this a case I should RMA it? Or should I just solder it down?

Thanks,

Gregg


On Friday, December 16, 2016 at 2:43:52 PM UTC-8, RobertCNelson wrote:
>
> On Fri, Dec 16, 2016 at 4:39 PM, Gregg Harrington 
> > wrote: 
> > I just tried to power my BBBWL through the barrel connector and wasn't 
> able 
> > to get it to power, when I looked at the bottom of the board, the 
> connector 
> > isn't soldered to the pad. When I short the pad to the pin, it boots up 
> and 
> > starts drawing power. Is this expected, did I get a weird board. 
>
> Ah! Now it makes sense why the eeprom never got programmed!!! 
>
> I bet your board was in the wrong pile at the factory... 
>
> 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/6ba5eb4e-acfa-482a-88a8-68fecc5c63b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: v4.9.x-ti now open for testing...

[Robert Nelson]

On Fri, Dec 16, 2016 at 4:31 PM, roboknight  wrote:
> I checked the script you posted to me.  That's pretty much what I'm doing,
> except I'm trying to create a
> HID function device with:
>
> mkdir g1/function/hid.0
>
> Which does "create" the device.  I then have to provide some kind of HID
> report descriptor, which I do
> based on one that has worked for me before, but somehow, when I perform the
> final step, I get a crash
> when libcomposite tries to call the f_hid.c (the function file which I
> believe is contained in usb_f_hid driver).
> Following the crash, it appears that it isn't getting an endpoint back from
> usb_ep_autoconfig ... and I don't
> know at this point, why that would be the case.
>
> The other drivers, I believe, do seem to work, or at least I was able to
> originally (before I needed to use the
> OTG port as a device port) connect to the beaglebone black (that's the board
> I'm using, btw) over the regular
> USB-IP interface.  So when I wasn't able to configure the HID interface
> properly, I became confused.
>
> I had a script that looked like this:
> ---
> modprobe libcomposite
> cd /sys/kernel/config/usb_gadget
>
>
> mkdir g1
>
>
> cd g1
>
>
> echo 0x1234 > idVendor
> echo 0x5678 > idProduct
>
>
> echo 0x0100 > bcdDevice
> echo 0x0200 > bcdUSB
>
>
> mkdir -p strings/0x409
>
>
> echo "0123456789" > strings/0x409/serialnumber
> echo "Manufacturer Inc." > strings/0x409/manufacturer
> echo "My HID Dev" > strings/0x409/product
>
>
> mkdir -p functions/hid.0
>
>
> echo "Config 1: MY HID Cfg" > configs/c.1/strings/0x409/configuration
> echo 250 > configs/c.1/MaxPower
>
>
> echo 1 > functions/hid.0/protocol
> echo 1 > functions/hid.0/subclass
> echo 9 > functions/hid.0/report_length
>
>
> cat ~/my_hid_desc.bin > functions/hid.0/report_desc
>
>
> ln -s functions/hid.0 configs/c.1
>
>
> ls /sys/class/udc > UDC
>
>
>
> 
> At the last, it fails:
>
> udc musb-hdrc.0.auto: registering UDC driver [g1]
> configfs-gadget gadget: adding 'hid'/dc77eb7c to config 'c'/dc7298a8
> Unable to handle kernel NULL pointer dereference at virtual address 0002
> pgd = dab9
> [0002] *pgd=9ab55831, *pte=, *ppte=
> Internal error: Oops: 17 [#1] PREEMPT THUMB2
> Modules linked in: usb_f_hid libcomposite gadgetfs musb_dsps musb_hdrc
> phy_am335x udc_core phy_am335x_control phy_generic ... other drivers ...
> CPU: 0 PID: 1247 Comm: ls Not tainted 4.9.0-rc6-armv7-devel-r62 #5
> Hardware name: Generic AM33XX (Flattened Device Tree)
> task: da82b900 task.stack: dc6a6000
> PC is at alloc_ep_req_0x1b/0x58 [libcomposite]
> LR is at 0x0
>
> And the stack dump continues.

no change: 4.9.0-bone3

I'm still figuring out usb configfs, so no pointers yet. ;)

[   23.696925] Unable to handle kernel NULL pointer dereference at
virtual address 0002
[   23.705155] pgd = da914000
[   23.707872] [0002] *pgd=9c60b831, *pte=, *ppte=
[   23.714215] Internal error: Oops: 17 [#1] THUMB2
[   23.718851] Modules linked in: usb_f_hid libcomposite
cpufreq_powersave cpufreq_conservative cpufreq_ondemand
cpufreq_userspace snd_soc_hdmi_codec nls_ascii nls_cp437
snd_soc_simple_card snd_soc_simple_card_utils omap_sham omap_aes
crypto_engine snd_soc_davinci_mcasp snd_soc_omap snd_soc_edma omap_rng
snd_soc_core rng_core tilcdc snd_pcm_dmaengine tps65217_charger
snd_pcm evdev snd_seq snd_seq_device snd_timer snd tda998x soundcore
omap_wdt uio_pdrv_genirq uio leds_gpio cpufreq_dt
[   23.761803] CPU: 0 PID: 1159 Comm: ls Not tainted 4.9.0-bone3 #1
[   23.767831] Hardware name: Generic AM33XX (Flattened Device Tree)
[   23.773947] task: db4440c0 task.stack: db70e000
[   23.778583] PC is at alloc_ep_req+0x1b/0x58 [libcomposite]
[   23.784088] LR is at 0x0
[   23.786629] pc : []lr : [<>]psr: 6033
[   23.786629] sp : db70fde0  ip :   fp : db70ab1c
[   23.798154] r10: db70aac4  r9 : db70aac4  r8 : db09d7d4
[   23.803396] r7 : db70aaa8  r6 : dc31c488  r5 : 0009  r4 : da907800
[   23.809948] r3 :   r2 :   r1 : 0001  r0 : da907800
[   23.816501] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb
Segment none
[   23.823838] Control: 50c5387d  Table: 9a914019  DAC: 0051
[   23.829605] Process ls (pid: 1159, stack limit = 0xdb70e210)
[   23.835285] Stack: (0xdb70fde0 to 0xdb71)
[   23.839662] fde0: db09d77c bf950188  bf94f5e5 db70ab24
db70aaa8 dc5b8f00 0001
[   23.847876] fe00: db09d77c db70aaa8 bf94f579 bf941ad8 db09d7d4
bf93ce23  db70aaa8
[   23.856089] fe20: db010e8c db010de0 db70aaa8 db010e8c db010de0
db010c00 db09d7d4 bf93fca9
[   23.864302] fe40: 0055 db010e54  dc31d1b8 024000c0
db557000 db010de0 
[   23.872515] fe60: c0eabee4 dc5b8900 c0eabed8 db480f00 dc5b8ed8
c05a933d db010de0 db557000
[   23.880728] fe80:  c05a9499  db010c00 0011
dc5b8900 db010d90 fff0
[   23.888941] fea0: 0051 bf93ff9d 000

Re: [beagleboard] Barrel Connector on BBBWL not soldered on 5v Pin

[Robert Nelson]

On Fri, Dec 16, 2016 at 4:39 PM, Gregg Harrington
 wrote:
> I just tried to power my BBBWL through the barrel connector and wasn't able
> to get it to power, when I looked at the bottom of the board, the connector
> isn't soldered to the pad. When I short the pad to the pin, it boots up and
> starts drawing power. Is this expected, did I get a weird board.

Ah! Now it makes sense why the eeprom never got programmed!!!

I bet your board was in the wrong pile at the factory...

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

[beagleboard] Barrel Connector on BBBWL not soldered on 5v Pin

[Gregg Harrington]

I just tried to power my BBBWL through the barrel connector and wasn't able 
to get it to power, when I looked at the bottom of the board, the connector 
isn't soldered to the pad. When I short the pad to the pin, it boots up and 
starts drawing power. Is this expected, did I get a weird board. 

Thanks,

Gregg

-- 
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/c877681a-4df5-4642-9b70-4fcacff94090%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: v4.9.x-ti now open for testing...

[roboknight]

I checked the script you posted to me.  That's pretty much what I'm doing, 
except I'm trying to create a
HID function device with:

mkdir g1/function/hid.0

Which does "create" the device.  I then have to provide some kind of HID 
report descriptor, which I do
based on one that has worked for me before, but somehow, when I perform the 
final step, I get a crash
when libcomposite tries to call the f_hid.c (the function file which I 
believe is contained in usb_f_hid driver).
Following the crash, it appears that it isn't getting an endpoint back from 
usb_ep_autoconfig ... and I don't
know at this point, why that would be the case.

The other drivers, I believe, do seem to work, or at least I was able to 
originally (before I needed to use the
OTG port as a device port) connect to the beaglebone black (that's the 
board I'm using, btw) over the regular
USB-IP interface.  So when I wasn't able to configure the HID interface 
properly, I became confused.

I had a script that looked like this:
---
modprobe libcomposite
cd /sys/kernel/config/usb_gadget


mkdir g1


cd g1


echo 0x1234 > idVendor
echo 0x5678 > idProduct


echo 0x0100 > bcdDevice
echo 0x0200 > bcdUSB


mkdir -p strings/0x409


echo "0123456789" > strings/0x409/serialnumber
echo "Manufacturer Inc." > strings/0x409/manufacturer
echo "My HID Dev" > strings/0x409/product


mkdir -p functions/hid.0


echo "Config 1: MY HID Cfg" > configs/c.1/strings/0x409/configuration
echo 250 > configs/c.1/MaxPower


echo 1 > functions/hid.0/protocol
echo 1 > functions/hid.0/subclass
echo 9 > functions/hid.0/report_length


cat ~/my_hid_desc.bin > functions/hid.0/report_desc


ln -s functions/hid.0 configs/c.1


ls /sys/class/udc > UDC




At the last, it fails:

udc musb-hdrc.0.auto: registering UDC driver [g1]
configfs-gadget gadget: adding 'hid'/dc77eb7c to config 'c'/dc7298a8
Unable to handle kernel NULL pointer dereference at virtual address 0002
pgd = dab9
[0002] *pgd=9ab55831, *pte=, *ppte=
Internal error: Oops: 17 [#1] PREEMPT THUMB2
Modules linked in: usb_f_hid libcomposite gadgetfs musb_dsps musb_hdrc 
phy_am335x udc_core phy_am335x_control phy_generic ... other drivers ...
CPU: 0 PID: 1247 Comm: ls Not tainted 4.9.0-rc6-armv7-devel-r62 #5
Hardware name: Generic AM33XX (Flattened Device Tree)
task: da82b900 task.stack: dc6a6000
PC is at alloc_ep_req_0x1b/0x58 [libcomposite]
LR is at 0x0

And the stack dump continues.

On Monday, October 31, 2016 at 5:47:06 PM UTC-4, RobertCNelson wrote:
>
> Hey Everyone, 
>
> Over the weekend, TI imported and tagged there first v4.9.x branch: 
>
>
> http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.9.y
>  
>
> I've added our patchset, overlays are broken past the first i2c 
> address:  (havn't tried with a board plugged in) 
>
> debian@beaglebone:~$ dmesg | grep bone 
> [2.101727] bone_capemgr bone_capemgr: Baseboard: 
> 'A335BNLT,00C0,2516BBBK2626' 
> [2.101753] bone_capemgr bone_capemgr: 
> compatible-baseboard=ti,beaglebone-black - #slots=4 
> [2.101796] bone_capemgr bone_capemgr: Failed to add slot #1 
> [2.126911] bone_capemgr bone_capemgr: Baseboard: 
> 'A335BNLT,00C0,2516BBBK2626' 
> [2.126940] bone_capemgr bone_capemgr: 
> compatible-baseboard=ti,beaglebone-black - #slots=4 
> [2.126971] bone_capemgr bone_capemgr: Failed to add slot #1 
> [2.360973] bone_capemgr bone_capemgr: Baseboard: 
> 'A335BNLT,00C0,2516BBBK2626' 
> [2.361012] bone_capemgr bone_capemgr: 
> compatible-baseboard=ti,beaglebone-black - #slots=4 
>
> cpufreq is broken, this should be fixed pretty soon.. 
>
> HDMI-Audio: this is new and went mainline in v4.9.x-rc, fingers 
> crossed, it should work so please test. ;)  ( i finally have a lcd 
> monitor (with audio) that i can finally test with. .;) ) 
>
> pru: nothing yet.. 
>
> eqep: needs porting.. 
>
> Kernel should hit the apt repo in a day or two, i'll reply to this 
> message when ready... 
>
> cd /opt/scripts/tools/ 
> git pull 
> sudo ./update_kernel.sh --ti-channel --lts-4_9 
>
> (no rt yet) 
>
> SRC is here: 
>
> https://github.com/beagleboard/linux/tree/4.9 
>
> https://github.com/beagleboard/linux/commits/4.9 
>
> The best way to build it is via yakbuild: 
>
> git clone https://github.com/RobertCNelson/yakbuild 
> cd ./yakbuild/ 
> cp recipe.sh.v4.9.x.sample recipe.sh 
> ./build_kernel.sh 
>
> While the dtb's can be built/tested via dtb-rebuilder 
>
> #this is one line.. 
> git clone -b 4.9-ti https://github.com/RobertCNelson/dtb-rebuilder/ 
> cd ./dtb-rebuilder/ 
> make 
>
> status 
> v4.4.x-ti - still supported and on-going working 
> v4.1.x-ti - maintenance-only please upgrade to v4.4.x-ti 
> v3.14.x-ti - maintenance (really eol) 
> v3.8.13-bone - maintenance, probably never EOL... (i see another gcc6 
> patch coming on the horizon). ;) 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com

Re: [beagleboard] Debian 7.9 - kernel upgrade to 4.4 - can't flash eMMC from SD

[Grzegorz G]

Great!

Thank you very much :)

Regards
Grzegorz

-- 
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/c7769f4b-a18b-4aac-9de1-aaf22ce16bd0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: v4.9.x-ti now open for testing...

[Robert Nelson]

On Fri, Dec 16, 2016 at 4:07 PM, roboknight  wrote:
>
>
> On Friday, December 16, 2016 at 4:44:33 PM UTC-5, RobertCNelson wrote:
>>
>> On Fri, Dec 16, 2016 at 3:38 PM, roboknight  wrote:
>> > I read through this thread and noted that the PRU isn't working yet?  I
>> > ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,
>> > and was able to get the PRU working with the old UIO driver.  I was
>> > hoping
>> > at some point to switch to the new remoteproc driver, but
>> > reading through this thread, it seems as its not ready?  I know this
>> > thread
>> > is about a month old now, but is my understanding accurate?
>> > Or have things progressed to a working state?  If my understanding is
>> > accurate, how much more work does the remoteproc driver require?
>>
>> Correct only, uio_pruss as it's mostly upstream, and with a quick hack
>> we have a version that is compatible with 3.8.13 kernel's..
>
>
> I take it that's why my uio_pruss works in 4.9... At least I haven't had any
> problems... yet.

Yeah you shouldn't have any problems, the one nice thing about uio, it
let's you handle everything. ;)


>> The remoteproc driver isn't upstream, TI will rebase it from v4.4.x-ti
>> and port it to v4.9.x-ti when they feel like it. ;)
>>
>> >
>> > I've even tested the old driver with my code and without any changes, it
>> > was
>> > performing like a champ.  My only problem now is I haven't been
>> > able to get the USB gadget interface to work.  Everything seems to go
>> > fine
>> > up until I attempt:
>> >
>> > ls /sys/class/udc > UDC  # enable my gadget
>> >
>> > At this point, I get a crash around line 620 in f_hid.c in
>> > usb/gadget/function .  At least the crash is in alloc_ep_req.  It says,
>> > if
>> > I'm reading it right, that the in_ep is NULL, which I don't think it is
>> > supposed to be or can't be.  So I'm not sure what I'm doing wrong that
>> > I'm
>> > getting a NULL endpoint, but I thought maybe I hadn't configured the
>> > kernel
>> > quite right for USB.  So now that TI has a more "official" 4.9 release,
>> > maybe things work there?
>>
>> Double check with v4.9.0, i've been also messing around with the usb
>> gadget configfs interface:
>>
>>
>> https://github.com/RobertCNelson/boot-scripts/blob/master/boot/omap3_beagle.sh#L44-L90
>>
>> hopefully we drop the old g_multi version that we use on the bone..
>>
>
> I am not sure what's going on here, but I'll check this out.  Either I'm not
> doing something with configfs properly, or I've screwed up the kernel
> config.
> I did note that when I look at my dmesg, I see musb-hdrc.1.auto showing up
> as a "host" driver and musb-hdrc.0.auto showing up under /sys/class/udc.
> I didn't know if the musb-hdrc.0.auto under /sys/class/udc means that its an
> "available" udc, or if it is the "device" udc, or if things are screwing up
> altogether.
> Thanks for the script pointer.

On the beagle xM, we just have one musb port, thus "musb-hdrc.0.auto"..

On the BeagleBone,

usb0 = peripheral
usb1 = host

So use "musb-hdrc.0.auto"

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

Re: [beagleboard] Debian 7.9 - kernel upgrade to 4.4 - can't flash eMMC from SD

[Robert Nelson]

On Fri, Dec 16, 2016 at 2:23 PM, Grzegorz G  wrote:
> I gave a second chance to TI kernel to flash eMMC from SD and it was
> successful - cylon leds then all leds on and auto power off. So now I have
> working wheezy with 4.4.39-ti-r75 kernel.
>
> I've looked to jessie debian images and I saw that there is TI kernel used -
> I guess this is the right direction to follow that kernel now and in the
> future?

the v4.4.x-ti is the default, but the "bone" is slightly more
optimized for the am335x (being a single core)

v4.4.x-bone is now fixed:

https://github.com/RobertCNelson/bb-kernel/commit/435900739ae38e7761d519cc81c3f5a15b849762

and pushed out as 4.4.39-bone15/4.4.39-bone-rt-r15, it'll be in the
apt repo sometime this weekend..

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/CAOCHtYj1SWt2XdAFFbOof3%3DTpniADRS8e34P5m_%2BDe-0srMO%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: v4.9.x-ti now open for testing...

[roboknight]

On Friday, December 16, 2016 at 4:44:33 PM UTC-5, RobertCNelson wrote:
>
> On Fri, Dec 16, 2016 at 3:38 PM, roboknight  > wrote: 
> > I read through this thread and noted that the PRU isn't working yet?  I 
> > ended up compiling a 4.9.0-rc6 kernel, although not the ti variant, 
> > and was able to get the PRU working with the old UIO driver.  I was 
> hoping 
> > at some point to switch to the new remoteproc driver, but 
> > reading through this thread, it seems as its not ready?  I know this 
> thread 
> > is about a month old now, but is my understanding accurate? 
> > Or have things progressed to a working state?  If my understanding is 
> > accurate, how much more work does the remoteproc driver require? 
>
> Correct only, uio_pruss as it's mostly upstream, and with a quick hack 
> we have a version that is compatible with 3.8.13 kernel's.. 
>

I take it that's why my uio_pruss works in 4.9... At least I haven't had 
any problems... yet.
 

>
> The remoteproc driver isn't upstream, TI will rebase it from v4.4.x-ti 
> and port it to v4.9.x-ti when they feel like it. ;) 
>
> > 
> > I've even tested the old driver with my code and without any changes, it 
> was 
> > performing like a champ.  My only problem now is I haven't been 
> > able to get the USB gadget interface to work.  Everything seems to go 
> fine 
> > up until I attempt: 
> > 
> > ls /sys/class/udc > UDC  # enable my gadget 
> > 
> > At this point, I get a crash around line 620 in f_hid.c in 
> > usb/gadget/function .  At least the crash is in alloc_ep_req.  It says, 
> if 
> > I'm reading it right, that the in_ep is NULL, which I don't think it is 
> > supposed to be or can't be.  So I'm not sure what I'm doing wrong that 
> I'm 
> > getting a NULL endpoint, but I thought maybe I hadn't configured the 
> kernel 
> > quite right for USB.  So now that TI has a more "official" 4.9 release, 
> > maybe things work there? 
>
> Double check with v4.9.0, i've been also messing around with the usb 
> gadget configfs interface: 
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/boot/omap3_beagle.sh#L44-L90
>  
>
> hopefully we drop the old g_multi version that we use on the bone.. 
>
>
I am not sure what's going on here, but I'll check this out.  Either I'm 
not doing something with configfs properly, or I've screwed up the kernel 
config.
I did note that when I look at my dmesg, I see musb-hdrc.1.auto showing up 
as a "host" driver and musb-hdrc.0.auto showing up under /sys/class/udc.
I didn't know if the musb-hdrc.0.auto under /sys/class/udc means that its 
an "available" udc, or if it is the "device" udc, or if things are screwing 
up altogether.
Thanks for the script pointer. 

> > 
> > At any rate, I needed both the USB gadget interface and the PRU to work 
> and 
> > eventually am hoping to migrate my code toward remoteproc so I don't 
> have 
> > the current issues (I needed various components that didn't seem to be 
> all 
> > in one place until 4.9). 
>
> 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/a63fe148-9e86-4d93-b015-d102b4a2af8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: v4.9.x-ti now open for testing...

[Robert Nelson]

On Fri, Dec 16, 2016 at 3:38 PM, roboknight  wrote:
> I read through this thread and noted that the PRU isn't working yet?  I
> ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,
> and was able to get the PRU working with the old UIO driver.  I was hoping
> at some point to switch to the new remoteproc driver, but
> reading through this thread, it seems as its not ready?  I know this thread
> is about a month old now, but is my understanding accurate?
> Or have things progressed to a working state?  If my understanding is
> accurate, how much more work does the remoteproc driver require?

Correct only, uio_pruss as it's mostly upstream, and with a quick hack
we have a version that is compatible with 3.8.13 kernel's..

The remoteproc driver isn't upstream, TI will rebase it from v4.4.x-ti
and port it to v4.9.x-ti when they feel like it. ;)

>
> I've even tested the old driver with my code and without any changes, it was
> performing like a champ.  My only problem now is I haven't been
> able to get the USB gadget interface to work.  Everything seems to go fine
> up until I attempt:
>
> ls /sys/class/udc > UDC  # enable my gadget
>
> At this point, I get a crash around line 620 in f_hid.c in
> usb/gadget/function .  At least the crash is in alloc_ep_req.  It says, if
> I'm reading it right, that the in_ep is NULL, which I don't think it is
> supposed to be or can't be.  So I'm not sure what I'm doing wrong that I'm
> getting a NULL endpoint, but I thought maybe I hadn't configured the kernel
> quite right for USB.  So now that TI has a more "official" 4.9 release,
> maybe things work there?

Double check with v4.9.0, i've been also messing around with the usb
gadget configfs interface:

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/omap3_beagle.sh#L44-L90

hopefully we drop the old g_multi version that we use on the bone..

>
> At any rate, I needed both the USB gadget interface and the PRU to work and
> eventually am hoping to migrate my code toward remoteproc so I don't have
> the current issues (I needed various components that didn't seem to be all
> in one place until 4.9).

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-F%2BCiM_2tvJKhH%3DtYic%2B6vUk1Dcp0uMT7%2BbjfPcv6ig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: v4.9.x-ti now open for testing...

[roboknight]

I read through this thread and noted that the PRU isn't working yet?  I 
ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,
and was able to get the PRU working with the old UIO driver.  I was hoping 
at some point to switch to the new remoteproc driver, but
reading through this thread, it seems as its not ready?  I know this thread 
is about a month old now, but is my understanding accurate?  
Or have things progressed to a working state?  If my understanding is 
accurate, how much more work does the remoteproc driver require?  

I've even tested the old driver with my code and without any changes, it 
was performing like a champ.  My only problem now is I haven't been
able to get the USB gadget interface to work.  Everything seems to go fine 
up until I attempt:

ls /sys/class/udc > UDC  # enable my gadget

At this point, I get a crash around line 620 in f_hid.c in 
usb/gadget/function .  At least the crash is in alloc_ep_req.  It says, if 
I'm reading it right, that the in_ep is NULL, which I don't think it is 
supposed to be or can't be.  So I'm not sure what I'm doing wrong that I'm 
getting a NULL endpoint, but I thought maybe I hadn't configured the kernel 
quite right for USB.  So now that TI has a more "official" 4.9 release, 
maybe things work there?

At any rate, I needed both the USB gadget interface and the PRU to work and 
eventually am hoping to migrate my code toward remoteproc so I don't have 
the current issues (I needed various components that didn't seem to be all 
in one place until 4.9).

On Monday, October 31, 2016 at 5:47:06 PM UTC-4, RobertCNelson wrote:
>
> Hey Everyone, 
>
> Over the weekend, TI imported and tagged there first v4.9.x branch: 
>
>
> http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.9.y
>  
>
> I've added our patchset, overlays are broken past the first i2c 
> address:  (havn't tried with a board plugged in) 
>
> debian@beaglebone:~$ dmesg | grep bone 
> [2.101727] bone_capemgr bone_capemgr: Baseboard: 
> 'A335BNLT,00C0,2516BBBK2626' 
> [2.101753] bone_capemgr bone_capemgr: 
> compatible-baseboard=ti,beaglebone-black - #slots=4 
> [2.101796] bone_capemgr bone_capemgr: Failed to add slot #1 
> [2.126911] bone_capemgr bone_capemgr: Baseboard: 
> 'A335BNLT,00C0,2516BBBK2626' 
> [2.126940] bone_capemgr bone_capemgr: 
> compatible-baseboard=ti,beaglebone-black - #slots=4 
> [2.126971] bone_capemgr bone_capemgr: Failed to add slot #1 
> [2.360973] bone_capemgr bone_capemgr: Baseboard: 
> 'A335BNLT,00C0,2516BBBK2626' 
> [2.361012] bone_capemgr bone_capemgr: 
> compatible-baseboard=ti,beaglebone-black - #slots=4 
>
> cpufreq is broken, this should be fixed pretty soon.. 
>
> HDMI-Audio: this is new and went mainline in v4.9.x-rc, fingers 
> crossed, it should work so please test. ;)  ( i finally have a lcd 
> monitor (with audio) that i can finally test with. .;) ) 
>
> pru: nothing yet.. 
>
> eqep: needs porting.. 
>
> Kernel should hit the apt repo in a day or two, i'll reply to this 
> message when ready... 
>
> cd /opt/scripts/tools/ 
> git pull 
> sudo ./update_kernel.sh --ti-channel --lts-4_9 
>
> (no rt yet) 
>
> SRC is here: 
>
> https://github.com/beagleboard/linux/tree/4.9 
>
> https://github.com/beagleboard/linux/commits/4.9 
>
> The best way to build it is via yakbuild: 
>
> git clone https://github.com/RobertCNelson/yakbuild 
> cd ./yakbuild/ 
> cp recipe.sh.v4.9.x.sample recipe.sh 
> ./build_kernel.sh 
>
> While the dtb's can be built/tested via dtb-rebuilder 
>
> #this is one line.. 
> git clone -b 4.9-ti https://github.com/RobertCNelson/dtb-rebuilder/ 
> cd ./dtb-rebuilder/ 
> make 
>
> status 
> v4.4.x-ti - still supported and on-going working 
> v4.1.x-ti - maintenance-only please upgrade to v4.4.x-ti 
> v3.14.x-ti - maintenance (really eol) 
> v3.8.13-bone - maintenance, probably never EOL... (i see another gcc6 
> patch coming on the horizon). ;) 
>
> 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/dd7687f5-90ce-4470-b2a4-1544f389b323%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] SRM for BeagleBone Black Wireless

[Gregg Harrington]

Hello,

Has the new SRM been published for the BeagleBone Black Wireless? 
Specifically, I am trying to wire into the TP headers for power management, 
I noticed the name of the pins has changed and wanted to confirm that they 
are the same with the SRM. 

If so, could someone link to it?

Thanks,

Gregg

-- 
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/b0e6da41-7e22-42e6-8eba-c145cf6a76e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian 7.9 - kernel upgrade to 4.4 - can't flash eMMC from SD

[Grzegorz G]

I gave a second chance to TI kernel to flash eMMC from SD and it was 
successful - cylon leds then all leds on and auto power off. So now I have 
working wheezy with 4.4.39-ti-r75 kernel.

I've looked to jessie debian images and I saw that there is TI kernel used 
- I guess this is the right direction to follow that kernel now and in the 
future?

Regards
Grzegorz

-- 
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/6bd435fa-ced0-4654-9c81-c3d8b061d3e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian 7.9 - kernel upgrade to 4.4 - can't flash eMMC from SD

[Robert Nelson]

On Fri, Dec 16, 2016 at 1:56 PM, Grzegorz G  wrote:
> I did test with TI Kernel:
>
> cd /opt/scripts/tools/
> git pull
> ./update_kernel.sh --ti-channel --lts-4_4
>
> flash eMMC from SD proces started: few cylon led sequence and now all leds
> are on.
>
> What's main difference betwen bone and TI kernel? I saw in dmesg log that
> bone kernel not support omap-shim (whatever it is).

It's a kernel configuration regression in wheezy (which doesn't get
tested anymore)..  I've got a version of v4.4.x-bone that works, just
minimizing the config down to the actual breakage..

bone = upstream base + our stuff
ti = upstream base + ti tree + our stuff

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/CAOCHtYgsh-7Ox%3DA2OL-Tcha%2BwpQeYZUUQuqRoYFwN7K6VhbQMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian 7.9 - kernel upgrade to 4.4 - can't flash eMMC from SD

[Grzegorz G]

I did test with TI Kernel:

cd /opt/scripts/tools/
git pull
./update_kernel.sh --ti-channel --lts-4_4

flash eMMC from SD proces started: few cylon led sequence and now all leds 
are on.

What's main difference betwen bone and TI kernel? I saw in dmesg log that 
bone kernel not support omap-shim (whatever it is).

Regards
Grzegorz

-- 
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/fe39030d-c002-465c-be8f-beaccc1b51fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Fix the driver signage of the Windows 64bit package

[da66en]

In particular, the RNDIS driver signage is no longer valid.  It needs the 
SHA2 signature.  I got it to work by signing it myself with my keys, not a 
good solution for most people.

-- 
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/63897ffd-b401-4db0-9ca8-c8ee8161890b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

Yeah, of course now the PRU died, which I had working before .time to 
debug that again :)

On Friday, December 16, 2016 at 2:00:53 PM UTC-5, William Hermans wrote:
>
>
>
> On Fri, Dec 16, 2016 at 11:55 AM, Jay Doobie  > wrote:
>
>> Ya know, I figured out what happened, I wish things were a bit better 
>> documented, what you indicated above about creating the initramfs fixed 
>> it.  I believe what happened was I modifed the uEnv.txt file and thought it 
>> took my changes, but it didn't.  I was running still with HDMI enabled and 
>> that conflicted with my DTS.
>>
>> I'll have to reassemble the machine now (I took the board out to put on a 
>> scope), but the values in the pinmux/pins file look correct now.
>>
>> /Jason
>>
>
> Ah, yeah, that'll do it. One thing I always do when working with various 
> things that take many commands to perform, and may easily be forgotten or 
> messed up. Is to create a text file of exact steps I've done to achieve my 
> end goal. Then when it comes to duplicating those steps, it turns into a 
> copy paste session that usually succeeds. Which also gives me an easy way 
> of creating a bash script later if needed. What just happened to you, 
> forgetting ti disable the HDMI pins has happened to me before many times in 
> the past . . .
>
>

-- 
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/a4b08be3-d062-465d-842a-0e0bea2c5967%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[William Hermans]

On Fri, Dec 16, 2016 at 11:55 AM, Jay Doobie  wrote:

> Ya know, I figured out what happened, I wish things were a bit better
> documented, what you indicated above about creating the initramfs fixed
> it.  I believe what happened was I modifed the uEnv.txt file and thought it
> took my changes, but it didn't.  I was running still with HDMI enabled and
> that conflicted with my DTS.
>
> I'll have to reassemble the machine now (I took the board out to put on a
> scope), but the values in the pinmux/pins file look correct now.
>
> /Jason
>

Ah, yeah, that'll do it. One thing I always do when working with various
things that take many commands to perform, and may easily be forgotten or
messed up. Is to create a text file of exact steps I've done to achieve my
end goal. Then when it comes to duplicating those steps, it turns into a
copy paste session that usually succeeds. Which also gives me an easy way
of creating a bash script later if needed. What just happened to you,
forgetting ti disable the HDMI pins has happened to me before many times in
the past . . .

-- 
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/CALHSORoQMN0aGhDSqgTfxD%2BjFDnSEMVw%3DOfLXVhzGSj_doPr8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

Ya know, I figured out what happened, I wish things were a bit better 
documented, what you indicated above about creating the initramfs fixed it. 
 I believe what happened was I modifed the uEnv.txt file and thought it 
took my changes, but it didn't.  I was running still with HDMI enabled and 
that conflicted with my DTS.

I'll have to reassemble the machine now (I took the board out to put on a 
scope), but the values in the pinmux/pins file look correct now.

/Jason

On Friday, December 16, 2016 at 1:52:11 PM UTC-5, William Hermans wrote:
>
> Jay, 
>
> Ok, so can you describe in more detail what the problem is ? Also pasting 
> the output of the commands you're running to test your overlay may help too.
>
> On Fri, Dec 16, 2016 at 11:45 AM, Jay Doobie  > wrote:
>
>> I was grepping /sys/kernel/debug/pinctrl/44e10800.pinmux/pins for 994 -B 
>> 4 -A4 
>>
>> and loading my overlay manually: "echo openpegasus > 
>> /sys/devices/platform/bone_capemgr/slots"
>>
>> According to dmesg it seems like it accepts my overlay without error.
>>
>> I'll keep the above in mind when I try to load it by default on boot.
>>
>> /Jason
>>
>> On Friday, December 16, 2016 at 1:41:28 PM UTC-5, William Hermans wrote:
>>>
>>> So whatever way that works for you, is the right way. But yes, in my own 
 opinion loading from uEnv.txt is the proper way. As the pin configurations 
 take place the quickest possible after a boot. 


1. So you need the overlay in /lib/firmware of course.
2. Then you need to add the overlay to the 
cape_enable=bone_capemgr.enable_partno= line in uEnv.txt
3. Finally you'll need to update the initramfs

 To update the initramfs You need to:

 william@beaglebone:~$ cd /opt/scripts/
 william@beaglebone:/opt/scripts$ git pull /* So you need to sudo 
 apt-get install git - If not already installed */

 william@beaglebone:/opt/scripts$ cd tools/developers/

 william@beaglebone:/opt/scripts/tools/developers$ sudo 
 ./update_initrd.sh

 william@beaglebone:/opt/scripts/tools/developers$ sudo reboot

 Then your custom overlay will be "injected" into the initramfs, and 
 properly load at boot.

>>>
>>>
>>> On Fri, Dec 16, 2016 at 11:39 AM, William Hermans  
>>> wrote:
>>>
 Jay,

 If by "updating" you mean your overlay isn't loading at boot. That 
 would be because the overlay is not in the initramfs. Which is needed for 
 the latest images. I actually posted on the groups about this a few days 
 go, so I'll find my post and copy paste the procedure here.

 If this is not what you mean, post back and describe in more detail 
 what you mean by "updating".

 On Fri, Dec 16, 2016 at 11:23 AM, Jay Doobie  wrote:

> Hi TJF: is there some place I can find more info on the DT's across 
> kernels?  I'm using 4.4.30-ti-r64.  I have access to the PRU, and I think 
> my DT isn't updating anything (even though it seems to install properly). 
>  
> My DT can be seen here:
>
>
> https://github.com/doobie42/OpenPegasus/blob/master/dto/openpegasus-00A0.dtsi
>
> Thanks,
> Jason
>
> On Friday, December 16, 2016 at 11:06:35 AM UTC-5, TJF wrote:
>>
>> Hello Jay!
>>
>> You need not adapt the device tree when you use a bone kernel. (The 
>> device tree fixup is for TI kernels only.)
>>
>> Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:
>>>
>>> I figured out what happened, it wasn't am335x-boneblack.dts, but 
>>> am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I 
>>> don't see it doing what it should be doing.  Need to grab a copy of 
>>> prudebug and see if I can debug what the PRU is trying to do vs. is 
>>> doing.
>>>
>>
>> PRU software is independant from the kernel. Once the driver is 
>> loaded accordingly, all should work. (Exept the PWM outputs of the 
>> eHRPWM 
>> modules in the PWMSS subsystems.)
>>
>> 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/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%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.

Re: [beagleboard] Re: pru + 4.4 kernel?

[William Hermans]

Jay,

Ok, so can you describe in more detail what the problem is ? Also pasting
the output of the commands you're running to test your overlay may help too.

On Fri, Dec 16, 2016 at 11:45 AM, Jay Doobie  wrote:

> I was grepping /sys/kernel/debug/pinctrl/44e10800.pinmux/pins for 994 -B
> 4 -A4
>
> and loading my overlay manually: "echo openpegasus >
> /sys/devices/platform/bone_capemgr/slots"
>
> According to dmesg it seems like it accepts my overlay without error.
>
> I'll keep the above in mind when I try to load it by default on boot.
>
> /Jason
>
> On Friday, December 16, 2016 at 1:41:28 PM UTC-5, William Hermans wrote:
>>
>> So whatever way that works for you, is the right way. But yes, in my own
>>> opinion loading from uEnv.txt is the proper way. As the pin configurations
>>> take place the quickest possible after a boot.
>>>
>>>
>>>1. So you need the overlay in /lib/firmware of course.
>>>2. Then you need to add the overlay to the
>>>cape_enable=bone_capemgr.enable_partno= line in uEnv.txt
>>>3. Finally you'll need to update the initramfs
>>>
>>> To update the initramfs You need to:
>>>
>>> william@beaglebone:~$ cd /opt/scripts/
>>> william@beaglebone:/opt/scripts$ git pull /* So you need to sudo
>>> apt-get install git - If not already installed */
>>>
>>> william@beaglebone:/opt/scripts$ cd tools/developers/
>>>
>>> william@beaglebone:/opt/scripts/tools/developers$ sudo
>>> ./update_initrd.sh
>>>
>>> william@beaglebone:/opt/scripts/tools/developers$ sudo reboot
>>>
>>> Then your custom overlay will be "injected" into the initramfs, and
>>> properly load at boot.
>>>
>>
>>
>> On Fri, Dec 16, 2016 at 11:39 AM, William Hermans 
>> wrote:
>>
>>> Jay,
>>>
>>> If by "updating" you mean your overlay isn't loading at boot. That would
>>> be because the overlay is not in the initramfs. Which is needed for the
>>> latest images. I actually posted on the groups about this a few days go, so
>>> I'll find my post and copy paste the procedure here.
>>>
>>> If this is not what you mean, post back and describe in more detail what
>>> you mean by "updating".
>>>
>>> On Fri, Dec 16, 2016 at 11:23 AM, Jay Doobie  wrote:
>>>
 Hi TJF: is there some place I can find more info on the DT's across
 kernels?  I'm using 4.4.30-ti-r64.  I have access to the PRU, and I think
 my DT isn't updating anything (even though it seems to install properly).
 My DT can be seen here:

 https://github.com/doobie42/OpenPegasus/blob/master/dto/open
 pegasus-00A0.dtsi

 Thanks,
 Jason

 On Friday, December 16, 2016 at 11:06:35 AM UTC-5, TJF wrote:
>
> Hello Jay!
>
> You need not adapt the device tree when you use a bone kernel. (The
> device tree fixup is for TI kernels only.)
>
> Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:
>>
>> I figured out what happened, it wasn't am335x-boneblack.dts, but
>> am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU,
>> but I don't see it doing what it should be doing.  Need to grab a copy of
>> prudebug and see if I can debug what the PRU is trying to do vs. is 
>> doing.
>>
>
> PRU software is independant from the kernel. Once the driver is loaded
> accordingly, all should work. (Exept the PWM outputs of the eHRPWM modules
> in the PWMSS subsystems.)
>
> 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/ms
 gid/beagleboard/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%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/255d6cdc-7ba5-4d31-9f81-dbb1c96bba9a%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 

Re: [beagleboard] Debian 7.9 - kernel upgrade to 4.4 - can't flash eMMC from SD

[Robert Nelson]

On Fri, Dec 16, 2016 at 12:39 PM, Robert Nelson  wrote:
> On Fri, Dec 16, 2016 at 9:53 AM, Grzegorz G  wrote:
>> Used debian image:
>> https://debian.beagleboard.org/images/bone-debian-7.9-lxde-4gb-armhf-2015-11-12-4gb.img.xz
>>
>> I booted it from SD Card and then i did:
>>
>> cd /opt/scripts/tools/
>> git pull
>> ./update_kernel.sh --bone-kernel --lts-4_4
>>
>> reboot
>>
>> For now system starts from SD Card fine, but when I try flash eMMC with SD
>> content nothing happend - all leds for a second lights up then no cylon
>> light.
>> I have uncommented flash cmdline in /boot/uEnv.txt.
>>
>> If I call flash script manually after system up from SD it starts flashing
>> eMMC but after reboot system wont start from eMMC.
>>
>
> It looks like the device nodes:
>
> /dev/mmcblk0p1
>
> are not automaticlly being created in 4.4.39-bone14

okay, 4.1.x get's passed that:

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

I'll start comparing 4.1.36-bone24 vs 4.4.39-bone14

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/CAOCHtYhbmb_pn4QS_7kFxwdmFsn9KLtmpL1kUG_zzV%3DB_yeGCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

I was grepping /sys/kernel/debug/pinctrl/44e10800.pinmux/pins for 994 -B 4 
-A4 

and loading my overlay manually: "echo openpegasus > 
/sys/devices/platform/bone_capemgr/slots"

According to dmesg it seems like it accepts my overlay without error.

I'll keep the above in mind when I try to load it by default on boot.

/Jason

On Friday, December 16, 2016 at 1:41:28 PM UTC-5, William Hermans wrote:
>
> So whatever way that works for you, is the right way. But yes, in my own 
>> opinion loading from uEnv.txt is the proper way. As the pin configurations 
>> take place the quickest possible after a boot. 
>>
>>
>>1. So you need the overlay in /lib/firmware of course.
>>2. Then you need to add the overlay to the 
>>cape_enable=bone_capemgr.enable_partno= line in uEnv.txt
>>3. Finally you'll need to update the initramfs
>>
>> To update the initramfs You need to:
>>
>> william@beaglebone:~$ cd /opt/scripts/
>> william@beaglebone:/opt/scripts$ git pull /* So you need to sudo apt-get 
>> install git - If not already installed */
>>
>> william@beaglebone:/opt/scripts$ cd tools/developers/
>>
>> william@beaglebone:/opt/scripts/tools/developers$ sudo ./update_initrd.sh
>>
>> william@beaglebone:/opt/scripts/tools/developers$ sudo reboot
>>
>> Then your custom overlay will be "injected" into the initramfs, and 
>> properly load at boot.
>>
>
>
> On Fri, Dec 16, 2016 at 11:39 AM, William Hermans  > wrote:
>
>> Jay,
>>
>> If by "updating" you mean your overlay isn't loading at boot. That would 
>> be because the overlay is not in the initramfs. Which is needed for the 
>> latest images. I actually posted on the groups about this a few days go, so 
>> I'll find my post and copy paste the procedure here.
>>
>> If this is not what you mean, post back and describe in more detail what 
>> you mean by "updating".
>>
>> On Fri, Dec 16, 2016 at 11:23 AM, Jay Doobie > > wrote:
>>
>>> Hi TJF: is there some place I can find more info on the DT's across 
>>> kernels?  I'm using 4.4.30-ti-r64.  I have access to the PRU, and I think 
>>> my DT isn't updating anything (even though it seems to install properly).  
>>> My DT can be seen here:
>>>
>>>
>>> https://github.com/doobie42/OpenPegasus/blob/master/dto/openpegasus-00A0.dtsi
>>>
>>> Thanks,
>>> Jason
>>>
>>> On Friday, December 16, 2016 at 11:06:35 AM UTC-5, TJF wrote:

 Hello Jay!

 You need not adapt the device tree when you use a bone kernel. (The 
 device tree fixup is for TI kernels only.)

 Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:
>
> I figured out what happened, it wasn't am335x-boneblack.dts, but 
> am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I 
> don't see it doing what it should be doing.  Need to grab a copy of 
> prudebug and see if I can debug what the PRU is trying to do vs. is doing.
>

 PRU software is independant from the kernel. Once the driver is loaded 
 accordingly, all should work. (Exept the PWM outputs of the eHRPWM modules 
 in the PWMSS subsystems.)

 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/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%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/255d6cdc-7ba5-4d31-9f81-dbb1c96bba9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[William Hermans]

>
> So whatever way that works for you, is the right way. But yes, in my own
> opinion loading from uEnv.txt is the proper way. As the pin configurations
> take place the quickest possible after a boot.
>
>
>1. So you need the overlay in /lib/firmware of course.
>2. Then you need to add the overlay to the cape_enable=bone_capemgr.
>enable_partno= line in uEnv.txt
>3. Finally you'll need to update the initramfs
>
> To update the initramfs You need to:
>
> william@beaglebone:~$ cd /opt/scripts/
> william@beaglebone:/opt/scripts$ git pull /* So you need to sudo apt-get
> install git - If not already installed */
>
> william@beaglebone:/opt/scripts$ cd tools/developers/
>
> william@beaglebone:/opt/scripts/tools/developers$ sudo ./update_initrd.sh
>
> william@beaglebone:/opt/scripts/tools/developers$ sudo reboot
>
> Then your custom overlay will be "injected" into the initramfs, and
> properly load at boot.
>


On Fri, Dec 16, 2016 at 11:39 AM, William Hermans  wrote:

> Jay,
>
> If by "updating" you mean your overlay isn't loading at boot. That would
> be because the overlay is not in the initramfs. Which is needed for the
> latest images. I actually posted on the groups about this a few days go, so
> I'll find my post and copy paste the procedure here.
>
> If this is not what you mean, post back and describe in more detail what
> you mean by "updating".
>
> On Fri, Dec 16, 2016 at 11:23 AM, Jay Doobie  wrote:
>
>> Hi TJF: is there some place I can find more info on the DT's across
>> kernels?  I'm using 4.4.30-ti-r64.  I have access to the PRU, and I think
>> my DT isn't updating anything (even though it seems to install properly).
>> My DT can be seen here:
>>
>> https://github.com/doobie42/OpenPegasus/blob/master/dto/open
>> pegasus-00A0.dtsi
>>
>> Thanks,
>> Jason
>>
>> On Friday, December 16, 2016 at 11:06:35 AM UTC-5, TJF wrote:
>>>
>>> Hello Jay!
>>>
>>> You need not adapt the device tree when you use a bone kernel. (The
>>> device tree fixup is for TI kernels only.)
>>>
>>> Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:

 I figured out what happened, it wasn't am335x-boneblack.dts, but
 am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but
 I don't see it doing what it should be doing.  Need to grab a copy of
 prudebug and see if I can debug what the PRU is trying to do vs. is doing.

>>>
>>> PRU software is independant from the kernel. Once the driver is loaded
>>> accordingly, all should work. (Exept the PWM outputs of the eHRPWM modules
>>> in the PWMSS subsystems.)
>>>
>>> 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/ms
>> gid/beagleboard/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%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/CALHSORrA1HUCuchZryO-aMdH9RfwfhzrTUbtg4%3D%3DATWaD-CQUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian 7.9 - kernel upgrade to 4.4 - can't flash eMMC from SD

[Robert Nelson]

On Fri, Dec 16, 2016 at 9:53 AM, Grzegorz G  wrote:
> Used debian image:
> https://debian.beagleboard.org/images/bone-debian-7.9-lxde-4gb-armhf-2015-11-12-4gb.img.xz
>
> I booted it from SD Card and then i did:
>
> cd /opt/scripts/tools/
> git pull
> ./update_kernel.sh --bone-kernel --lts-4_4
>
> reboot
>
> For now system starts from SD Card fine, but when I try flash eMMC with SD
> content nothing happend - all leds for a second lights up then no cylon
> light.
> I have uncommented flash cmdline in /boot/uEnv.txt.
>
> If I call flash script manually after system up from SD it starts flashing
> eMMC but after reboot system wont start from eMMC.
>

It looks like the device nodes:

/dev/mmcblk0p1

are not automaticlly being created in 4.4.39-bone14

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/CAOCHtYie_DayDtxJEQru%2B4yAqzbLCJOMPqOKadzRS_EgZOkFCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[William Hermans]

Jay,

If by "updating" you mean your overlay isn't loading at boot. That would be
because the overlay is not in the initramfs. Which is needed for the latest
images. I actually posted on the groups about this a few days go, so I'll
find my post and copy paste the procedure here.

If this is not what you mean, post back and describe in more detail what
you mean by "updating".

On Fri, Dec 16, 2016 at 11:23 AM, Jay Doobie  wrote:

> Hi TJF: is there some place I can find more info on the DT's across
> kernels?  I'm using 4.4.30-ti-r64.  I have access to the PRU, and I think
> my DT isn't updating anything (even though it seems to install properly).
> My DT can be seen here:
>
> https://github.com/doobie42/OpenPegasus/blob/master/dto/
> openpegasus-00A0.dtsi
>
> Thanks,
> Jason
>
> On Friday, December 16, 2016 at 11:06:35 AM UTC-5, TJF wrote:
>>
>> Hello Jay!
>>
>> You need not adapt the device tree when you use a bone kernel. (The
>> device tree fixup is for TI kernels only.)
>>
>> Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:
>>>
>>> I figured out what happened, it wasn't am335x-boneblack.dts, but
>>> am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I
>>> don't see it doing what it should be doing.  Need to grab a copy of
>>> prudebug and see if I can debug what the PRU is trying to do vs. is doing.
>>>
>>
>> PRU software is independant from the kernel. Once the driver is loaded
>> accordingly, all should work. (Exept the PWM outputs of the eHRPWM modules
>> in the PWMSS subsystems.)
>>
>> 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/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%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/CALHSORoMy5xVvnnNeetbXk3ODW6YsCjzph%2BVpXWatOTXGitbeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU rpmsg issues with IOT 2016-11-06

[Benoit Perron]

Thank you so very much! Everything working fine now!

Took awhile to realize that the resource_table_0.h file was also modified!

So I guess I will not have to download the whole >2GB Platform_sdk again 
and just use the pru-software-support-package !

Thank you again!

On Friday, December 16, 2016 at 7:36:17 AM UTC-5, Greg wrote:
>
> You are very close!!!
>
> One thing to try right away is to:
>
> rmmod pru_rproc
>
> and then 
>
> modprobe pru_rproc
>
> I don't think you are removing pru_rproc before re-probing it.
> In my latest Debian image this works, and you don't need to do the bind in 
> addition to this.
> Of course the bind should work as well.
>
> Now, based on the dates you show, you may be using the old Remoteproc 
> framework which uses the mailboxes.
> Look in your code for the PRUs and see if you see the numbers like 58 or 
> 59.
> The new system flags should be like 18 or 19.
>
> If you have the old mailboxes you can convert your code easily enough.  In 
> fact, it will probably be simplified.
> Get the latest PRU Support package and look at the examples directory:
>
> https://git.ti.com/pru-software-support-package
>
> I'm pretty sure if you have the old mailboxes code you will get the 
> behavior you are observing.
>
> Regards,
> Greg
>

-- 
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/bddbbd99-de24-4129-a662-641825ace112%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

Hi TJF: is there some place I can find more info on the DT's across 
kernels?  I'm using 4.4.30-ti-r64.  I have access to the PRU, and I think 
my DT isn't updating anything (even though it seems to install properly). 
 My DT can be seen here:

https://github.com/doobie42/OpenPegasus/blob/master/dto/openpegasus-00A0.dtsi

Thanks,
Jason

On Friday, December 16, 2016 at 11:06:35 AM UTC-5, TJF wrote:
>
> Hello Jay!
>
> You need not adapt the device tree when you use a bone kernel. (The device 
> tree fixup is for TI kernels only.)
>
> Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:
>>
>> I figured out what happened, it wasn't am335x-boneblack.dts, but 
>> am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I 
>> don't see it doing what it should be doing.  Need to grab a copy of 
>> prudebug and see if I can debug what the PRU is trying to do vs. is doing.
>>
>
> PRU software is independant from the kernel. Once the driver is loaded 
> accordingly, all should work. (Exept the PWM outputs of the eHRPWM modules 
> in the PWMSS subsystems.)
>
> 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/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Fwd: CHANGES FOR CODE COMPOSER STUDIO (CCS)

[John Syne]

I thought this might be interesting to developers on this list.

Regards,
John




> Begin forwarded message:
> 
> From: myRegisteredSoftware 
> Subject: CHANGES FOR CODE COMPOSER STUDIO (CCS)
> Date: December 15, 2016 at 2:31:53 PM PST
> To: undisclosed-recipients:;
> 
> CHANGES FOR CODE COMPOSER STUDIO (CCS)
>
>  
> As a long-term Code Composer Studio IDE customer we value your dedication. 
> Thank you for being a loyal customer. TI has great news regarding Code 
> Composer Studio (CCS); effective today Texas Instruments will no longer 
> charge for CCS licenses.
>  
> Going forward this means:
> 
> You can upgrade simply by going to www.ti.com/ccstudio 
>  to download the latest CCSv7, install it and use 
> it.
> You no longer need to use the myRegistered Software portal to manage licenses.
> For questions see FAQ: http://www.ti.com/lsds/ti/tools-software/ccs-faq.page 
> 
> For additional questions, please contact ccs_license_file_h...@list.ti.com 
> 
>  
> Texas Instruments, Inc.
> 

-- 
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/3E856299-9E6C-42F4-8678-E6CBBF8693C0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[TJF]

Hello Jay!

You need not adapt the device tree when you use a bone kernel. (The device 
tree fixup is for TI kernels only.)

Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:
>
> I figured out what happened, it wasn't am335x-boneblack.dts, but 
> am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I 
> don't see it doing what it should be doing.  Need to grab a copy of 
> prudebug and see if I can debug what the PRU is trying to do vs. is doing.
>

PRU software is independant from the kernel. Once the driver is loaded 
accordingly, all should work. (Exept the PWM outputs of the eHRPWM modules 
in the PWMSS subsystems.)

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/e3d7c862-9b69-4165-b852-472f9a3bf9ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Debian 7.9 - kernel upgrade to 4.4 - can't flash eMMC from SD

[Grzegorz G]

Used debian image:
https://debian.beagleboard.org/images/bone-debian-7.9-lxde-4gb-armhf-2015-11-12-4gb.img.xz

I booted it from SD Card and then i did:

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

reboot

For now system starts from SD Card fine, but when I try flash eMMC with SD 
content nothing happend - all leds for a second lights up then no cylon 
light.
I have uncommented flash cmdline in /boot/uEnv.txt.

If I call flash script manually after system up from SD it starts flashing 
eMMC but after reboot system wont start from eMMC.

Regards
Grzegorz

-- 
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/c17c8ca4-b427-4812-bac3-4ea0390dc90b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU rpmsg issues with IOT 2016-11-06

[Benoit Perron]

Firstly:  Thank you very much for your quick reply! So much stuff to keep 
track of!
Zerothly: Your ADC article is simply Amazing! I wish i'd found it sooner!

I am indeed using mailboxes in my PRU code, compiled with ti-cgt-pru_2.1.2 
from code samples in the processor sdk pru-icss-4.0.2 package.

I will look at the package you references and gie it a whirl!

Am I correct in assuming that this is the way of the future ie: everyone 
will not fall-back to UIO and leave me and my code stranded?
To have everything started automatically at boot time I guess I will have 
to create another systemd service right?
 

On Friday, December 16, 2016 at 7:36:17 AM UTC-5, Greg wrote:
>
> You are very close!!!
>
> One thing to try right away is to:
>
> rmmod pru_rproc
>
> and then 
>
> modprobe pru_rproc
>
> I don't think you are removing pru_rproc before re-probing it.
> In my latest Debian image this works, and you don't need to do the bind in 
> addition to this.
> Of course the bind should work as well.
>
> Now, based on the dates you show, you may be using the old Remoteproc 
> framework which uses the mailboxes.
> Look in your code for the PRUs and see if you see the numbers like 58 or 
> 59.
> The new system flags should be like 18 or 19.
>
> If you have the old mailboxes you can convert your code easily enough.  In 
> fact, it will probably be simplified.
> Get the latest PRU Support package and look at the examples directory:
>
> https://git.ti.com/pru-software-support-package
>
> I'm pretty sure if you have the old mailboxes code you will get the 
> behavior you are observing.
>
> Regards,
> Greg
>

-- 
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/50a9cb6a-bdc4-4f80-91a7-92b35bdef818%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Ubuntu on the Beagle

[lorrianemayfield via BeagleBoard]

On Fri, 12/16/16, Heinz Hummel  wrote:

 Subject: Re: [beagleboard] Re: Ubuntu on the Beagle
 To: beagleboard@googlegroups.com
 Date: Friday, December 16, 2016, 8:02 AM
 
 I have the feeling, in
 Ubuntu forums people expect a (somewhat high) minimum level
 of knowledge, elsewhere you will not be taken
 seriously.
 
 I
 mean Debian forums of course...
 
 
 
 
 -- 
 
 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/CAHptrU4XBmm7EB5F7PDPy%2BuM7btEZQsG0a6xC2jF7R%2BQtKoBsQ%40mail.gmail.com.
 
 For more options, visit https://groups.google.com/d/optout.
 stetica maioresciana a avut un adversar si in persoana lui Constantin 
Dobrogeanu-Gherea  sustinator al artei cu tendinta   iar din punct de vedere 
politic adept al social-democratiei. Ideile sale se fac cunoscute prin paginile 
revistei Contemporanul .

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

[beagleboard] Re: PRU rpmsg issues with IOT 2016-11-06

[Greg]

You are very close!!!

One thing to try right away is to:

rmmod pru_rproc

and then 

modprobe pru_rproc

I don't think you are removing pru_rproc before re-probing it.
In my latest Debian image this works, and you don't need to do the bind in 
addition to this.
Of course the bind should work as well.

Now, based on the dates you show, you may be using the old Remoteproc 
framework which uses the mailboxes.
Look in your code for the PRUs and see if you see the numbers like 58 or 59.
The new system flags should be like 18 or 19.

If you have the old mailboxes you can convert your code easily enough.  In 
fact, it will probably be simplified.
Get the latest PRU Support package and look at the examples directory:

https://git.ti.com/pru-software-support-package

I'm pretty sure if you have the old mailboxes code you will get the 
behavior you are observing.

Regards,
Greg

-- 
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/90d8ff96-4172-4c96-89d5-f23f279d9c21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU rpmsg issues with IOT 2016-11-06

[Benoit Perron]

Hello,

I have been developping something for a while now. I started on a BBB rev 
A, migrated to rev C and have now switched to BBG (no need for HDMI.

For the OS, I have migrated from angstrom to Debian 7, to 8, kernel 3.X to 
4.4. Now I need advice on choosing a version.

I am running a bunch of code (mostly python) in user-space, some web 
services, external SPI, I2C and CANBus peripherals and also running code on 
PRU0. When I started all this, UIO_PRUSS looked like the most popular way 
of doing things out there byt remote-proc looked like the future so I chose 
it.

Everything was all when and good until I switch my base image from 
2016-04-21 to the latest 2016-11-06 IOT image. I am trying to get the 
latest @stable@ and @standard@ version before releasing my project. (Am I 
justified in doing this?) Now it appears that remote proc is not enabled by 
default. 
I had to follow the steps from Greg here: https://github.com/Greg-R/pruadc1 
(ref 
taken from this thread: 
https://groups.google.com/forum/#!topic/beagleboard/tQW4ZLcncF8 )to 
reenable-it. Even then, my /dev/rpmsg_pru30 device file just will not be 
created!

here is my boot dmesg:
[4.785011]  remoteproc1: 4a334000.pru0 is available
[4.785035]  remoteproc1: Note: remoteproc is still under development 
and considered experimental.
[4.785045]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed.
[4.785341]  remoteproc1: Direct firmware load for am335x-pru0-fw failed 
with error -2
[4.785360]  remoteproc1: failed to load am335x-pru0-fw
[4.824044] pru-rproc 4a334000.pru0: booting the PRU core manually
[4.824075]  remoteproc1: powering up 4a334000.pru0
[4.824182]  remoteproc1: Direct firmware load for am335x-pru0-fw failed 
with error -2
[4.824199]  remoteproc1: request_firmware failed: -2
[4.829423] pru-rproc 4a334000.pru0: rproc_boot failed
[4.928466]  remoteproc1: releasing 4a334000.pru0
[4.928634] pru-rproc: probe of 4a334000.pru0 failed with error -2
[4.929025]  remoteproc1: 4a338000.pru1 is available
[4.929038]  remoteproc1: Note: remoteproc is still under development 
and considered experimental.
[4.929047]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed.
[4.929318]  remoteproc1: Direct firmware load for am335x-pru1-fw failed 
with error -2
[4.929337]  remoteproc1: failed to load am335x-pru1-fw
[4.939607] pru-rproc 4a338000.pru1: booting the PRU core manually
[4.939637]  remoteproc1: powering up 4a338000.pru1
[4.939736]  remoteproc1: Direct firmware load for am335x-pru1-fw failed 
with error -2
[4.939750]  remoteproc1: request_firmware failed: -2
[4.944962] pru-rproc 4a338000.pru1: rproc_boot failed
[5.052392]  remoteproc1: releasing 4a338000.pru1
[5.052550] pru-rproc: probe of 4a338000.pru1 failed with error -2

lsmod after boot:
Module  Size  Used by
spidev  8860  0 
c_can_platform  7581  0 
c_can  12220  1 c_can_platform
can_dev14358  1 c_can
spi_omap2_mcspi12952  0 
pwm_tiehrpwm5883  0 
pwm_tiecap  4571  0 
tieqep  9981  0 
omap_aes_driver23889  0 
omap_sham  26513  0 
omap_rng5544  0 
rng_core9066  1 omap_rng
evdev  13511  1 
uio_pdrv_genirq 3923  0 
uio10524  1 uio_pdrv_genirq
8021q  22979  0 
garp7049  1 8021q
mrp 8903  1 8021q
stp 2430  1 garp
llc 5903  2 stp,garp
usb_f_acm   8361  1 
u_serial   13753  3 usb_f_acm
usb_f_rndis25865  1 
g_multi 6010  0 
usb_f_mass_storage 49849  2 g_multi
u_ether14413  2 usb_f_rndis,g_multi
libcomposite   53554  4 
usb_f_acm,usb_f_rndis,g_multi,usb_f_mass_storage
pru_rproc  15431  0 
pruss_intc  8603  1 pru_rproc
pruss  12026  1 pru_rproc


I manually load the rpmsg module with modprobe rpmsg_pru. I then see 2 new 
modules loaded:
rpmsg_pru   5543  0 
virtio_rpmsg_bus   16076  1 rpmsg_pru

I then bind the PRU:
echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/bind

dmesg shows the following:
[  312.954382]  remoteproc1: 4a334000.pru0 is available
[  312.95]  remoteproc1: Note: remoteproc is still under development 
and considered experimental.
[  312.954471]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed.
[  312.971682]  remoteproc1: powering up 4a334000.pru0
[  312.971775]  remoteproc1: Booting fw image am335x-pru0-fw, size 86724
[  312.972162] ti-pruss 4a30.pruss: configured system_events = 
0x1000 intr_channels = 0x0001 host_intr = 0x0001
[  312.981283]  remoteproc1: re

[beagleboard] Re: How to set time automatically at power up?

[Chris Green]

Robert Nelson  wrote:
> On Thu, Dec 15, 2016 at 10:57 AM, Chris Green  wrote:
> > Robert Nelson  wrote:
> >> On Thu, Dec 15, 2016 at 10:14 AM, Chris Green  wrote:
> >> > I run a headless BBB on my boat.  I need it to have the right time so
> >> > that information it sends is correctly time stamped.
> >> >
> >> > How can I get it to power up with the right time and date?  I have
> >> > installed ntp/ntpd to keep the time correct once up and running but it
> >> > doesn't initialise the time and date.  What's the way to do this?
> >>
> >> Debian Wheezy or Jessie?
> >>
> > It's Wheezy.
> >
> >
> >> In wheezy, setup a job to run at startup, check for connection and
> >> just run "ntpdate pool.ntp.org"
> >>
> > OK, thanks, that seems straightforward.
> >
> >
> >> In Jessie, there's a systemd
> >>
> >> sudo systemctl enable systemd-timesyncd.service || true
> >>
> >> both cases rely on a active internet connection...
> >>
> > Of course, yes.  If the internet isn't reliable is it worth running
> > 'ntpdate' at intervals using cron so that if there isn't a connection
> > at startup it will get set when the internet does appear?
> 
> In that case, something like this would just work better:
> 
> https://www.sparkfun.com/products/12708
> 
> You can find them cheaper elsewhere..
> 
OK, thanks again, that might be my next add-on for the BBB.

-- 
Chris Green
·

-- 
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/ifocid-t4h.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.