Re: [beagleboard] No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

[William Hermans]

A bit of additional information that I left out unintentionally. I think
the debian image I am using is the first iamge where uboot overlay loading
is enabled. So, if you decided to use uboot overlays you may have to go
with a newer image.

The kernel im using is: *uname_r=4.4.55-ti-r94*

And the image I used is:
*bone-debian-8.7-console-armhf-2017-04-02-1gb.img.xz*

Anything after this date I'm assuming has uboot overlay loading enabled.
This is indeed a testing image, but so far aside from capemgr not working
from the command line, and capmgr slots file not reporting what has been
loaded. It seems to be very solid. I'm seriously considering putting this
image to work in the field on 30ish live production systems. I'm that happy
with it.

On Wed, Apr 26, 2017 at 8:39 PM, William Hermans  wrote:

> So, there is another *possible* work around that you could try. Keep in
> mind that I have not tested this myself. But config-pin can load overlays
> too. So it is possible that you could do something like this:
>
> config-pin overlay 
>
> Then your overlay would have to exist in /lib/firmware, as I seem to
> recall that config-pin for some reason does not handle pathing well, or at
> all. Still, I kind of via that as a hack as well, and it is possible that
> if universala conflicts with any overlays you want to use. That you'll
> receive an "file already exists" error. One trick I could think of there is
> create  a "blank" universala overlay file, or maybe just copy the contents
> of your existing overlay into a new universala, then compile it and replace
> the old one with your new one. . . . again, in my own mind, a HUGELY
> undesirable hack.
>
> Anyway. I commend Charles S. for the time he's spent on Universal IO, and
> I love the concept. But I kept running into problems using it in production
> systems. So I had to stop using it. It was constantly fighting me when all
> I really needed to do was get something done. The result I wound up with,
> was not using it . . . which is really unfortunate, but I mostly view it as
> a learning tool anyway. I learned a lot by reading through Charles'
> config-pin script, and overlays he created.
>
> You and I both are using similar kernels, I think the kernel I'm using is
> slightly newer, which also leaves me to believe that perhaps you're one
> image behind the one I'm currently testing on. I've found some issues with
> capemgr, that are minor if you know how to work around those issues, and
> you're very familiar with the beaglebone system in general. But .
> ..relaying this information would take a tremendous amount of effort for
> both of us . . .
>
> So my advice to you, for now would be to try and completely disable
> Universal IO, and load your overlays via uboot. Robert has made a couple of
> posts in the last week or so to a link on the elinux site that has
> instructions on how to do so. However, if you read the uEnv.txt file, you
> may be able to figure this out on your own. One thing I do not know for
> sure however, is how enabling specific board files the old way works when
> you're using uboot overlay loading. However, I do think there is a new
> method, commented out for disabling the eMMC too.
>
>
>
>
> On Wed, Apr 26, 2017 at 8:50 AM, ThomasL  wrote:
>
>> Edit: This was wrong. Using the config-pin scripts we got everything
>> working even at higher frequencies (30MHz). We are going to have a look at
>> the overlays later.
>> Op woensdag 26 april 2017 11:25:21 UTC+2 schreef ThomasL:
>>>
>>>
>>> Also, we presume that when using the cape-universala with pin config we
>>> are doing the toggles trough software with the bone-pinmux-helper instead
>>> of connecting register 30 to the output pads. We only get a toggle speed of
>>> around 2MHz which should be way higher if it was the PRU controlling the
>>> pin directly.
>>>
>>>
>>> --
>> 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/d58b6891-5393-4a23-bf64-0636f03e0433%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/CALHSORqveprGOYaQzmHhRb24%2Bz-q9fPGz9C48RUr_-1Bpi6bwA%40mail.gmail.com.
For more options, visit https:

Re: [beagleboard] No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

[William Hermans]

So, there is another *possible* work around that you could try. Keep in
mind that I have not tested this myself. But config-pin can load overlays
too. So it is possible that you could do something like this:

config-pin overlay 

Then your overlay would have to exist in /lib/firmware, as I seem to recall
that config-pin for some reason does not handle pathing well, or at all.
Still, I kind of via that as a hack as well, and it is possible that if
universala conflicts with any overlays you want to use. That you'll receive
an "file already exists" error. One trick I could think of there is create
a "blank" universala overlay file, or maybe just copy the contents of your
existing overlay into a new universala, then compile it and replace the old
one with your new one. . . . again, in my own mind, a HUGELY undesirable
hack.

Anyway. I commend Charles S. for the time he's spent on Universal IO, and I
love the concept. But I kept running into problems using it in production
systems. So I had to stop using it. It was constantly fighting me when all
I really needed to do was get something done. The result I wound up with,
was not using it . . . which is really unfortunate, but I mostly view it as
a learning tool anyway. I learned a lot by reading through Charles'
config-pin script, and overlays he created.

You and I both are using similar kernels, I think the kernel I'm using is
slightly newer, which also leaves me to believe that perhaps you're one
image behind the one I'm currently testing on. I've found some issues with
capemgr, that are minor if you know how to work around those issues, and
you're very familiar with the beaglebone system in general. But .
..relaying this information would take a tremendous amount of effort for
both of us . . .

So my advice to you, for now would be to try and completely disable
Universal IO, and load your overlays via uboot. Robert has made a couple of
posts in the last week or so to a link on the elinux site that has
instructions on how to do so. However, if you read the uEnv.txt file, you
may be able to figure this out on your own. One thing I do not know for
sure however, is how enabling specific board files the old way works when
you're using uboot overlay loading. However, I do think there is a new
method, commented out for disabling the eMMC too.




On Wed, Apr 26, 2017 at 8:50 AM, ThomasL  wrote:

> Edit: This was wrong. Using the config-pin scripts we got everything
> working even at higher frequencies (30MHz). We are going to have a look at
> the overlays later.
> Op woensdag 26 april 2017 11:25:21 UTC+2 schreef ThomasL:
>>
>>
>> Also, we presume that when using the cape-universala with pin config we
>> are doing the toggles trough software with the bone-pinmux-helper instead
>> of connecting register 30 to the output pads. We only get a toggle speed of
>> around 2MHz which should be way higher if it was the PRU controlling the
>> pin directly.
>>
>>
>> --
> 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/d58b6891-5393-4a23-bf64-0636f03e0433%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/CALHSORre7UBAGZMXn7J3np4znS_oJk0auM-J8EvLH-sEo5RaFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 2017-04-02-1gb.img capemgr bug

[Robert Nelson]

On Wed, Apr 26, 2017 at 10:03 PM, William Hermans  wrote:
> Ok so uboot overlay loading works on UART1:
>
> root@wgd:~# ls /dev |grep ttyO[0-4]
> ttyO0
> ttyO1
>
> So apparently the part of capemgr that works from the command line seems to
> be broken. This board I'm testing is an Alpha prototype whcih needs serial
> debug brought out over to the top of the cape, so I can not unfortunately
> give serial debug output. uEnv.txt line on a working uboot overlay load:
>
> ###Additional custom capes
> uboot_overlay_addr4=/lib/firmware/wph-i2c-00A0.dtbo
> uboot_overlay_addr5=/lib/firmware/BB-ADC-00A0.dtbo
> uboot_overlay_addr6=/lib/firmware/BB-W1-P8.26-00A0.dtbo
> uboot_overlay_addr7=/lib/firmware/BB-UART1-00A0.dtbo
>
> The first cape is nothing special that could possibly interfere with
> capemgr. It just enables I2C-1 bus, and loads the ds3232 RTC driver, for a
> ds3232 on I2C-2 bus.

Yeah, i don't want to go down that road.. to have u-boot's
cape-manager tell the kernel's cape-manager what pin's are available.
It would be a great GSOC project ;)

So what's i'm doing:

if u-boot overlays loads something that's just a normal *.dtb you can
use the kernel's cape-manager.  But if it loads anything custom..  i
disable the kernel's cape-manager..

So any of these combinations:

enable_uboot_overlays=1
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1

kernel cape-manager is enabled..

With any of these combinations:

#disable_uboot_overlay_adc=1
uboot_overlay_addr0=/lib/firmware/.dtbo
uboot_overlay_addr1=/lib/firmware/.dtbo
uboot_overlay_addr2=/lib/firmware/.dtbo
uboot_overlay_addr3=/lib/firmware/.dtbo
uboot_overlay_addr4=/lib/firmware/.dtbo
uboot_overlay_addr5=/lib/firmware/.dtbo
uboot_overlay_addr6=/lib/firmware/.dtbo
uboot_overlay_addr7=/lib/firmware/.dtbo
dtb_overlay=/lib/firmware/.dtbo
#enable_uboot_cape_universal=1

kernel cape-manager get's disabled..

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

Re: [beagleboard] 2017-04-02-1gb.img capemgr bug

[William Hermans]

Ok so uboot overlay loading works on UART1:

root@wgd:~# ls /dev |grep ttyO[0-4]
ttyO0
ttyO1

So apparently the part of capemgr that works from the command line seems to
be broken. This board I'm testing is an Alpha prototype whcih needs serial
debug brought out over to the top of the cape, so I can not unfortunately
give serial debug output. uEnv.txt line on a working uboot overlay load:

###Additional custom capes
uboot_overlay_addr4=/lib/firmware/wph-i2c-00A0.dtbo
uboot_overlay_addr5=/lib/firmware/BB-ADC-00A0.dtbo
uboot_overlay_addr6=/lib/firmware/BB-W1-P8.26-00A0.dtbo
uboot_overlay_addr7=/lib/firmware/BB-UART1-00A0.dtbo

The first cape is nothing special that could possibly interfere with
capemgr. It just enables I2C-1 bus, and loads the ds3232 RTC driver, for a
ds3232 on I2C-2 bus.


On Wed, Apr 26, 2017 at 7:54 PM, William Hermans  wrote:

> By the way, Universal IO is disabled on both boards.
>
> On Wed, Apr 26, 2017 at 7:52 PM, William Hermans 
> wrote:
>
>> So the image I'm using on two separate boards:
>> bone-debian-8.7-console-armhf-2017-04-02-1gb.img
>>
>> One board has uboot capes enabled, and they do function. The other board
>> is not using uboot overlays, but seems odd at times.
>>
>> So on both board inserting an overlay as such: root@wgd:~# echo BB-UART1
>> > /sys/devices/platform/bone_capemgr/slots
>>
>> Causes the terminal session to hang directly after the command is issued.
>> The board is still operational, however after reiitializing an ssh session:
>>
>> root@wgd:~# cat  /sys/devices/platform/bone_capemgr/slots
>>  0: ---l--  -1
>>  1: --  -1
>>  2: ---l--  -1
>>  3: ---l--  -1
>>  4: --O---  -1
>>
>> root@wgd:~# dmesg | tail
>> [   18.436962] net eth0: initializing cpsw version 1.12 (0)
>> [   18.436993] net eth0: initialized cpsw ale version 1.4
>> [   18.437003] net eth0: ALE Table size 1024
>> [   18.445166] net eth0: phy found : id is : 0x7c0f1
>> [   18.462196] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> [  121.758813] cpsw 4a10.ethernet eth0: Link is Up - 100Mbps/Full -
>> flow control rx/tx
>> [  121.758944] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>> [346482.260850] bone_capemgr bone_capemgr: part_number 'BB-UART1',
>> version 'N/A'
>> [346482.260892] bone_capemgr bone_capemgr: slot #4: override
>> [346482.260910] bone_capemgr bone_capemgr: slot #4: auto loading handled
>> by U-Boot
>>
>> root@wgd:~# ls /dev |grep ttyO[0-4]
>> ttyO0
>>
>> The cape is definitely not loading. The output from these commands here
>> is from the board that is loading overlays via uboot, but I am willing( I
>> have not checked yet ) the output would be identical on the board that does
>> not have uboot overlays enabled. Curiously, I did try the old method of
>> loading the overlay form uEnv.txt, and the overlay did not load correctly
>> then either.
>>
>> One thing of note which may *possibly* be the culprit. Is that I do not
>> have a board file for either of these loaded specifically. However on at
>> least the uboot overlay board I have hdmi video and audio both disabled
>> through the new uboot way. I have not checked if any of those pins conflict
>> with that overlay or not, because I have not looked.
>>
>> I'll make another post following this one to see how this overlay behaves
>> when i attempt to load via uboot overlays.
>>
>>
>> --
>> 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/1c0c6094-2b0a-4724-a434-1c6d043e608c%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/CALHSORqYnW-vsC5M613hKsCiBb0USLX%3D2S8JNjLWWJAb0g15eQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 2017-04-02-1gb.img capemgr bug

[William Hermans]

By the way, Universal IO is disabled on both boards.

On Wed, Apr 26, 2017 at 7:52 PM, William Hermans  wrote:

> So the image I'm using on two separate boards:
> bone-debian-8.7-console-armhf-2017-04-02-1gb.img
>
> One board has uboot capes enabled, and they do function. The other board
> is not using uboot overlays, but seems odd at times.
>
> So on both board inserting an overlay as such: root@wgd:~# echo BB-UART1
> > /sys/devices/platform/bone_capemgr/slots
>
> Causes the terminal session to hang directly after the command is issued.
> The board is still operational, however after reiitializing an ssh session:
>
> root@wgd:~# cat  /sys/devices/platform/bone_capemgr/slots
>  0: ---l--  -1
>  1: --  -1
>  2: ---l--  -1
>  3: ---l--  -1
>  4: --O---  -1
>
> root@wgd:~# dmesg | tail
> [   18.436962] net eth0: initializing cpsw version 1.12 (0)
> [   18.436993] net eth0: initialized cpsw ale version 1.4
> [   18.437003] net eth0: ALE Table size 1024
> [   18.445166] net eth0: phy found : id is : 0x7c0f1
> [   18.462196] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [  121.758813] cpsw 4a10.ethernet eth0: Link is Up - 100Mbps/Full -
> flow control rx/tx
> [  121.758944] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [346482.260850] bone_capemgr bone_capemgr: part_number 'BB-UART1', version
> 'N/A'
> [346482.260892] bone_capemgr bone_capemgr: slot #4: override
> [346482.260910] bone_capemgr bone_capemgr: slot #4: auto loading handled
> by U-Boot
>
> root@wgd:~# ls /dev |grep ttyO[0-4]
> ttyO0
>
> The cape is definitely not loading. The output from these commands here is
> from the board that is loading overlays via uboot, but I am willing( I have
> not checked yet ) the output would be identical on the board that does not
> have uboot overlays enabled. Curiously, I did try the old method of loading
> the overlay form uEnv.txt, and the overlay did not load correctly then
> either.
>
> One thing of note which may *possibly* be the culprit. Is that I do not
> have a board file for either of these loaded specifically. However on at
> least the uboot overlay board I have hdmi video and audio both disabled
> through the new uboot way. I have not checked if any of those pins conflict
> with that overlay or not, because I have not looked.
>
> I'll make another post following this one to see how this overlay behaves
> when i attempt to load via uboot overlays.
>
>
> --
> 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/1c0c6094-2b0a-4724-a434-1c6d043e608c%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/CALHSORpXDAQn9ZMB0PpRpsScXL-WTFNNZf8O360zjw1S%2BCNKtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] 2017-04-02-1gb.img capemgr bug

[William Hermans]

So the image I'm using on two separate boards: 
bone-debian-8.7-console-armhf-2017-04-02-1gb.img

One board has uboot capes enabled, and they do function. The other board is 
not using uboot overlays, but seems odd at times.

So on both board inserting an overlay as such: root@wgd:~# echo BB-UART1 > 
/sys/devices/platform/bone_capemgr/slots

Causes the terminal session to hang directly after the command is issued. 
The board is still operational, however after reiitializing an ssh session:

root@wgd:~# cat  /sys/devices/platform/bone_capemgr/slots
 0: ---l--  -1
 1: --  -1
 2: ---l--  -1
 3: ---l--  -1
 4: --O---  -1

root@wgd:~# dmesg | tail
[   18.436962] net eth0: initializing cpsw version 1.12 (0)
[   18.436993] net eth0: initialized cpsw ale version 1.4
[   18.437003] net eth0: ALE Table size 1024
[   18.445166] net eth0: phy found : id is : 0x7c0f1
[   18.462196] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  121.758813] cpsw 4a10.ethernet eth0: Link is Up - 100Mbps/Full - 
flow control rx/tx
[  121.758944] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[346482.260850] bone_capemgr bone_capemgr: part_number 'BB-UART1', version 
'N/A'
[346482.260892] bone_capemgr bone_capemgr: slot #4: override
[346482.260910] bone_capemgr bone_capemgr: slot #4: auto loading handled by 
U-Boot

root@wgd:~# ls /dev |grep ttyO[0-4]
ttyO0

The cape is definitely not loading. The output from these commands here is 
from the board that is loading overlays via uboot, but I am willing( I have 
not checked yet ) the output would be identical on the board that does not 
have uboot overlays enabled. Curiously, I did try the old method of loading 
the overlay form uEnv.txt, and the overlay did not load correctly then 
either.

One thing of note which may *possibly* be the culprit. Is that I do not 
have a board file for either of these loaded specifically. However on at 
least the uboot overlay board I have hdmi video and audio both disabled 
through the new uboot way. I have not checked if any of those pins conflict 
with that overlay or not, because I have not looked.

I'll make another post following this one to see how this overlay behaves 
when i attempt to load via uboot overlays.


-- 
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/1c0c6094-2b0a-4724-a434-1c6d043e608c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: 12v. What amperage?

[JStrawson]

The LiPo charger and sitara together draw a hair under 1A. I've been using 
1A 12V power supplies from amazon for a while now with success, although I 
have had some cheap 1A powers supplies from ebay break over time. 

Best,
James

On Sunday, April 2, 2017 at 5:08:37 AM UTC-7, Glenn Miller wrote:
>
> What amperage am I looking for in a 12v power supply?
>
> Thanks.
>

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

Re: [beagleboard] Re: Reboot instead of shutdown

[William Hermans]

On Wed, Apr 26, 2017 at 8:31 AM, ithinu  wrote:

> The board is connected to a 5V power supply, to a USB hub and via Ethernet
> to a router. It has no capes.
>
> uname -a
> Linux beaglebone 4.4.39-ti-r75 #1 SMP Thu Dec 15 22:16:11 UTC 2016 armv7l
> GNU/Linux
>
> The command
>
>   sudo systemctl poweroff
>
> reboots it just like
>
>   shutdown -P now
>
> However, if the board is disconnected from the USB hub (still connected to
> the power supply), both of the above commands shut the unit down as
> expected. I checked this several times: connecting even a running unit to
> USB makes it unable to shutdown. However, if powered from USB (power supply
> disconnected) the board shuts down again without a problem.
>
> I tested this several times and it seems, that the only combination where
> the board can not shut down is when connected to both the power supply and
> USB at once. Which is ok as of me, as I do not need the USB connection any
> more.
>
> There is an old thread (the kernel must obviously have been different)
> where a similar problem is reported by several people:
> https://groups.google.com/forum/#!msg/beagleboard/qw5zlS4F4p4/chu0J3VXKgAJ
>

Without looking at the post, no it's probably not the same issue. Because
if that is the topic I think it is. It would cause the boards to not boot.
In either case I think the fix will be the same. You may need to do surgery
on your USB hub, and remove the power back into the host aspect of the hub.
e.g. it sounds very much like your getting backfeed power over the USB from
your hub. On some boards( I've only heard of this with ODROID boards ),
this can be caused by HDMI as well.

Short story, you're using a powered hub, and you need to keep that hub from
sending power back into the host.

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

[beagleboard] X applications not working over usb

[BDD]

I cannot run X-apps on my BBBs when they are connected to my computer over 
the USB.  But the X-apps work just fine when the BBBs are connected to my 
computer over the LAN.  Why?  My older BBBs work just fine in either 
connection mode, but the newer ones (purchase in the past year) fail when 
connected on the USB (but work on the LAN).  All BBBs are running debian, 
and all are version C.

I connect to windows machines (Windows 7 & 10 give the same result) using 
Putty and Xming -- and I use the same settings whether I'm connected via 
LAN or USB.  The only thing I change is the IP.  (I use the default BBB IP 
when connected to the USB and the "assigned" IP when connected to the LAN.)

Since the bad behavior is a function of how new the BBB is, I conclude that 
something in the debian system has changed from 2 years ago to 1 year ago.  
(I only noticed this recently when I started attaching all my BBBS to 
laptops via USB.  That's when I noticed the new ones fail and the older 
ones worked.)

The particular software I'm running on the BBBs is gnuplot.

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/1f83a215-fc71-4982-a994-50906d212a0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU and CPU driven by different oscillators?

[flairyparagon]

Graham is right. The oscillator used for the processor is the 24MHz crystal 
oscillator (Y2 in schematic), whereas, the one used by the ethernet 
controller or the IEP timer is 25MHz crystal oscillator (Y3 in schematic).



On Tuesday, April 25, 2017 at 5:09:50 PM UTC-7, Justin Pearson wrote:
>
> How can I find out whether the PRU and CPU are driven by the same 
> oscillator? Specifically, a colleague told me that the IEP timer (which I'm 
> reading with the PRU) is driven by a 24 MHz oscillator that's PLL'd so the 
> timer increments at 200 MHz, whereas the CPU is driven by a 25 MHz 
> oscillator PLL'd so that the CPU runs at 1 GHz.
>
> It seems to me that if they're driven by different oscillators, then they 
> could drift apart over time. 
>
> Page 1177 of the TRM (spruh73n.pdf) mentions a 32-kHz crystal oscillator, 
> but I don't see how that's related.
>
> Also, are these oscillators within the Sitara SoC, or somewhere else on 
> the BBB? The SRM just references 24.576 MHz oscillator (pg 70 of e14 
> BBB_SRM_rev 0.9.pdf), and I'm not sure how that's related to the 24/25 MHz 
> oscillators my colleague mentioned.
>
> Thanks for your 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/0042ccf8-a5ff-415d-80b4-557b9fdba8ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone black ssh problem

[Greg]

A highly recommended accessory is a USB to serial adapter cable.  It will 
need to be the 3.3volt version, like this example:
https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A/ref=sr_1_4?ie=UTF8&qid=1493243765&sr=8-4&keywords=3.3v+serial+to+usb

There is a 6-pin header on the Beagle Bone which you can plug this adapter 
cable into.  The other end is USB, and then you will need a terminal 
program on the computer.
I use a Linux terminal emulator called screen.

When you connect in this way, you will have full access to the file system 
and you can fix whatever it is that got changed.  This method bypasses the 
complex networking stuff like USB or Ethernet.

Another very practical approach is to use the Micro-sd memory cards and do 
not flash to the onboard flash drive.
Be sure to get a ruggedized card and it will be more reliable.  I'm done 
with the cheap cards, they will waste your time.
When you get to the point where your software is solid, you can flash to 
the onboard drive.  This will be the ultimate reliability.

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/dbc44cf8-dc88-441f-acfc-ae99c0b3acb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Robert Nelson]

On Wed, Apr 26, 2017 at 12:17 PM, Rasmus Olesen
 wrote:
>  Hi Robert
>
> I could have sworn that space was a typo in the message.
>
> anyway, now it boots and this is what I get from
> dmesg | grep bone
>
>
>
> ubuntu@arm:~$ dmesg | grep bone
> [2.374724] bone_capemgr bone_capemgr: Baseboard:
> 'A335BNLT,000C,1631BBBG0959'
> [2.374760] bone_capemgr bone_capemgr:
> compatible-baseboard=ti,beaglebone-black - #slots=4
> [2.413510] bone_capemgr bone_capemgr: slot #0:
> 'nh7cape,A0,Cembsoft,BB-BONE-NH7C-01'

bingo! that's what i needed (eeprom value), i'll start working on a
patch as i found the schematic!

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

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Rasmus Olesen]

 Hi Robert

I could have sworn that space was a typo in the message.

anyway, now it boots and this is what I get from 
dmesg | grep bone



ubuntu@arm:~$ dmesg | grep bone
[2.374724] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,000C,1631BBBG0959'
[2.374760] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone-black - #slots=4
[2.413510] bone_capemgr bone_capemgr: slot #0: 
'nh7cape,A0,Cembsoft,BB-BONE-NH7C-01'
[2.453402] bone_capemgr bone_capemgr: slot #1: No cape found
[2.493583] bone_capemgr bone_capemgr: slot #2: No cape found
[2.533395] bone_capemgr bone_capemgr: slot #3: No cape found
[2.533636] bone_capemgr bone_capemgr: initialized OK.
[3.545642] bone_capemgr bone_capemgr: loader: failed to load slot-0 
BB-BONE-NH7C-01:A0 (prio 0)
[   30.019837] bone_capemgr bone_capemgr: part_number 'univ-emmc', version 
'N/A'
[   30.019880] bone_capemgr bone_capemgr: slot #4: override
[   30.019898] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4
[   30.019914] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,univ-emmc'
[   30.593518] bone_capemgr bone_capemgr: slot #4: dtbo 
'univ-emmc-00A0.dtbo' loaded; overlay id #0
ubuntu@arm:~$ 

So it looks as if the cape is recognized, but there is still no picture. I 
dont have HDMI either so currently I'm SSH'ing into it.
There is plenty of backlight in the display though...

Regards Rasmus
 

-- 
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/2c29a38b-7876-48b4-848d-189d0ae4c19e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU and CPU driven by different oscillators?

[Graham]

Well, best way is to read the schematic. (BBB Rev C schematic, dated March 
21, 2014)
24 MHz Sitara clock crystal is on upper left of page 3, hooked to main 
oscillator I/O.
There is also a 32 kHz crystal shown there for the Real Time Clock.

The 25 MHz crystal is on page 9, hooked to the LAN8710, which is the 
Ethernet PHI.

I am not a PRU expert, but I don't think there is, or should be, a fixed 
relationship between
the PRU clock and the CPU clock.  The CPU in a Sitara is a variable speed 
CPU, and 
can run anywhere from a few hundred MHz to a GHz, depending on loading,
and it is under kernel control.

I would not think you would want the 200 MHz clock for the PRU to be 
variable
like that, since it would totally destroy the real time advantage of the 
PRU.

So, I suspect that the clock for the PRU is a fixed clock coming from a 
different
place in the clock tree than the variable speed CPU.

You should really check and verify the clock tree behavior.

--- Graham

==

On Wednesday, April 26, 2017 at 8:02:38 AM UTC-5, Justin Pearson wrote:
>
> Thanks Graham. Follow-up questions: 
>
> 1. Where exactly did you find this information? I looked through the TRM 
> and SRM but couldn't find anything definitive.
>
> 2. Is the 200-MHz PRU driven from the same 24 MHz oscillator that drives 
> the CPU? If so, is it correct that the PRU cycle counter increments 
> precisely once for every 5 CPU cycles? 
>
> Thanks for your help.
> -Justin
>
> On Tuesday, April 25, 2017 at 7:35:19 PM UTC-7, Graham wrote:
>>
>> The CPU in a BBB runs from a 24 MHz Oscillator.
>> There is a 25 MHz oscillator on the board, but that is for the Ethernet.
>> --- Graham
>>
>> ==
>>
>> On Tuesday, April 25, 2017 at 7:09:50 PM UTC-5, Justin Pearson wrote:
>>>
>>> How can I find out whether the PRU and CPU are driven by the same 
>>> oscillator? Specifically, a colleague told me that the IEP timer (which I'm 
>>> reading with the PRU) is driven by a 24 MHz oscillator that's PLL'd so the 
>>> timer increments at 200 MHz, whereas the CPU is driven by a 25 MHz 
>>> oscillator PLL'd so that the CPU runs at 1 GHz.
>>>
>>> It seems to me that if they're driven by different oscillators, then 
>>> they could drift apart over time. 
>>>
>>> Page 1177 of the TRM (spruh73n.pdf) mentions a 32-kHz crystal 
>>> oscillator, but I don't see how that's related.
>>>
>>> Also, are these oscillators within the Sitara SoC, or somewhere else on 
>>> the BBB? The SRM just references 24.576 MHz oscillator (pg 70 of e14 
>>> BBB_SRM_rev 0.9.pdf), and I'm not sure how that's related to the 24/25 MHz 
>>> oscillators my colleague mentioned.
>>>
>>> Thanks for your 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/843f0f74-584e-440d-828f-df0cd61d1e1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Robert Nelson]

On Wed, Apr 26, 2017 at 11:41 AM, Rasmus Olesen
 wrote:
>
> Hi Robert
>
> I don't know what I'm doing wrong but I have tried your instructions several
> times with the result that the BBB won't boot.
> It turns on the four LED and stop there. they keep being on all the time.
>
> I use nano to edit the uEnv.txt file.
>
> When I flash a new image I have the following
>
> uname_r=4.4.59-ti-r96
> #uuid=
> #dtb=
>
>
> ###U-Boot Overlays###
> ###Documentation:
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
> ###Master Enable
> enable_uboot_overlays=1
> ###
> ###Overide capes with eeprom
> #uboot_overlay_addr0=/lib/firmware/.dtbo
> #uboot_overlay_addr1=/lib/firmware/.dtbo
> #uboot_overlay_addr2=/lib/firmware/.dtbo
> #uboot_overlay_addr3=/lib/firmware/.dtbo
> ###
> ###Additional custom capes
> #uboot_overlay_addr4=/lib/firmware/.dtbo
> #uboot_overlay_addr5=/lib/firmware/.dtbo
> #uboot_overlay_addr6=/lib/firmware/.dtbo
> #uboot_overlay_addr7=/lib/firmware/.dtbo
> ###
> ###Custom Cape
> #dtb_overlay=/lib/firmware/.dtbo
> ###
> ###Disable auto loading of virtual capes (emmc/video/wireless/adc)
> #disable_uboot_overlay_emmc=1
> #disable_uboot_overlay_video=1
> #disable_uboot_overlay_audio=1
> #disable_uboot_overlay_wireless=1
> #disable_uboot_overlay_adc=1
> ###
> ###Cape Universal Enable
> enable_uboot_cape_universal=1
> ###
> ###Debug: disable uboot autoload of Cape
> #disable_uboot_overlay_addr0=1
> #disable_uboot_overlay_addr1=1
> #disable_uboot_overlay_addr2=1
> #disable_uboot_overlay_addr3=1
> ###
> ###U-Boot fdt tweaks...
> #uboot_fdt_buffer=0x6
> ###U-Boot Overlays###
>
> cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=enable
>
> #In the event of edid real failures, uncomment this next line:
> #cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=enable
> video=HDMI-A-1:1024x768@60e
>
> ##Example v3.8.x
> #cape_disable=capemgr.disable_partno=
> #cape_enable=capemgr.enable_partno=
>
> ##Example v4.1.x
> #cape_disable=bone_capemgr.disable_partno=
> #cape_enable=bone_capemgr.enable_partno=
>
> ##enable Generic eMMC Flasher:
> #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
>
> uuid=d70dd19c-28f6-4541-bf1e-a261ac779f90
>
>
>
>
> I have tried to change it to
>
> uname_r=4.4.59-ti-r96
> #uuid=
> dtb= am335x-boneblack-emmc-overlay.dtb

no space between dtb= and am*

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

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Rasmus Olesen]

Hi Robert

I don't know what I'm doing wrong but I have tried your instructions 
several times with the result that the BBB won't boot.
It turns on the four LED and stop there. they keep being on all the time.

I use nano to edit the uEnv.txt file.

When I flash a new image I have the following

uname_r=4.4.59-ti-r96
#uuid=
#dtb=


###U-Boot Overlays###
###Documentation: 
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/.dtbo
#uboot_overlay_addr5=/lib/firmware/.dtbo
#uboot_overlay_addr6=/lib/firmware/.dtbo
#uboot_overlay_addr7=/lib/firmware/.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks...
#uboot_fdt_buffer=0x6
###U-Boot Overlays###

cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=enable

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=enable 
video=HDMI-A-1:1024x768@60e

##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=

##enable Generic eMMC Flasher:
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

uuid=d70dd19c-28f6-4541-bf1e-a261ac779f90




I have tried to change it to

uname_r=4.4.59-ti-r96
#uuid=
dtb= am335x-boneblack-emmc-overlay.dtb


###U-Boot Overlays###
###Documentation: 
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
#enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
###
(etc...)


and to 

uname_r=4.4.59-ti-r96
#uuid=
#dtb=

dtb= am335x-boneblack-emmc-overlay.dtb

###U-Boot Overlays###
###Documentation: 
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
#enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
###
(etc...)

In both cases it is unable to boot...

I have the recomended debian 8.7 image to that apparently does not use 
U-boot. should I install that instead?

your help is much appreciated...

/Rasmus 

-- 
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/a84a8f30-0302-4004-9227-66fc479fb79f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

[Greg]

You could view the implementation of overlays as an optimization pass.

Greg

On Wednesday, April 26, 2017 at 11:50:02 AM UTC-4, ThomasL wrote:
>
> Edit: This was wrong. Using the config-pin scripts we got everything 
> working even at higher frequencies (30MHz). We are going to have a look at 
> the overlays later. 
> Op woensdag 26 april 2017 11:25:21 UTC+2 schreef ThomasL:
>>
>>
>> Also, we presume that when using the cape-universala with pin config we 
>> are doing the toggles trough software with the bone-pinmux-helper instead 
>> of connecting register 30 to the output pads. We only get a toggle speed of 
>> around 2MHz which should be way higher if it was the PRU controlling the 
>> pin directly.
>>
>>
>>

-- 
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/fcd56bbd-6c9c-4b7e-94a3-612448a5fad0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

[ThomasL]

Edit: This was wrong. Using the config-pin scripts we got everything 
working even at higher frequencies (30MHz). We are going to have a look at 
the overlays later. 
Op woensdag 26 april 2017 11:25:21 UTC+2 schreef ThomasL:
>
>
> Also, we presume that when using the cape-universala with pin config we 
> are doing the toggles trough software with the bone-pinmux-helper instead 
> of connecting register 30 to the output pads. We only get a toggle speed of 
> around 2MHz which should be way higher if it was the PRU controlling the 
> pin directly.
>
>
>

-- 
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/d58b6891-5393-4a23-bf64-0636f03e0433%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Reboot instead of shutdown

[ithinu]

The board is connected to a 5V power supply, to a USB hub and via Ethernet 
to a router. It has no capes.

uname -a
Linux beaglebone 4.4.39-ti-r75 #1 SMP Thu Dec 15 22:16:11 UTC 2016 armv7l 
GNU/Linux

The command

  sudo systemctl poweroff

reboots it just like 

  shutdown -P now

However, if the board is disconnected from the USB hub (still connected to 
the power supply), both of the above commands shut the unit down as 
expected. I checked this several times: connecting even a running unit to 
USB makes it unable to shutdown. However, if powered from USB (power supply 
disconnected) the board shuts down again without a problem.

I tested this several times and it seems, that the only combination where 
the board can not shut down is when connected to both the power supply and 
USB at once. Which is ok as of me, as I do not need the USB connection any 
more.

There is an old thread (the kernel must obviously have been different) 
where a similar problem is reported by several people: 
https://groups.google.com/forum/#!msg/beagleboard/qw5zlS4F4p4/chu0J3VXKgAJ


On Wednesday, April 26, 2017 at 4:45:41 AM UTC+2, Graham wrote:
>
> What OS/kernel is ithinu running?
>
> "shutdown -P now" works on all my BBB/BBG boards.
>
> But, I run from external +5V, without anything on the battery connections.
>
> --- Graham
>
> ==
>
>
>> I usually tell everyone to use:
>>
>> sudo systemctl poweroff
>>
>> as systemd knows how to tell the external tps65217 to cut power.
>>
>> looking at the syslog, i don't remember any issues with 4.4.39-ti-r75,
>> and looking at the git log i don't see any poweroff regressions
>> mentioned..
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/9VdtZKf3Dz0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgHtwySLzoGJOdRLwGKm34kPxxwz6GBj5BFwWYUUtbR9g%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/b71765fd-1179-4c6d-911b-8969233bc7b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Robert Nelson]

On Wed, Apr 26, 2017 at 10:12 AM, Rasmus Olesen
 wrote:
> ohh...
>
> I just saw that I have a
> #dtb=
> Line at the top of uEnv.txt
> I guess I should add it there..?
> and also is it suposed to be "dtb=am335x..." or should it be
> "dtb=arm335x..."? (since this is an arm processor)

no just use:

dtb=am335x-boneblack-emmc-overlay.dtb

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

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Rasmus Olesen]

ohh...

I just saw that I have a
#dtb=
Line at the top of uEnv.txt
I guess I should add it there..?
and also is it suposed to be "dtb=am335x..." or should it be 
"dtb=arm335x..."? (since this is an arm processor)

/Rasmus 

-- 
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/969f4620-d64f-4428-a7d1-7bb9c3187326%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Rasmus Olesen]

Hi Robert.

I get that you want me to out comment the enable line in uEnv.txt.
But do you want me to enter the second command to the bottom of the file or 
just run it at the command line?

Sorry but I'm quite new to linux...

/Rasmus 

-- 
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/ef690563-c603-4ab2-8354-34649580c510%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Robert Nelson]

On Wed, Apr 26, 2017 at 9:50 AM, Rasmus Olesen
 wrote:
>  I don't know how to retrieve the text from the terminal but here goes...
>
> [0.00] Kernel command line: console=ttyO0,115200n8
> bone_capemgr.uboot_capemgr_enabled=1 root=UUID=1be96781-5260-4113-96e
> 3-7c97f1fde997 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0
> quiet cape_universial=enable
> [2.469004] bone_capemgr bone_capemgr: Baseboard:
> 'A335BNLT,000C,1631BBBG0959'
> [2.469040] bone_capemgr bone_capemgr:
> compatible-baseboard=ti,beaglebone-black - #slots=4
> [2.469075] bone_capemgr bone_capemgr: slot #0: auto loading handled by
> U-Boot
> [2.469098] bone_capemgr bone_capemgr: slot #1: auto loading handled by
> U-Boot
> [2.469141] bone_capemgr bone_capemgr: slot #2: auto loading handled by
> U-Boot
> [2.469169] bone_capemgr bone_capemgr: slot #3: auto loading handled by
> U-Boot
> [2.469172] bone_capemgr bone_capemgr: initialized OK.
>
> I think I would have expected to see something actualy loaded here..?
>
> It is the only cape I have connected to my BBB.

Ah, the image your running has u-boot handling it, since you loose
physical access with the serial plugged in, that makes debugging fun.

In /boot/uEnv.txt

Change:

enable_uboot_overlays=1 -> #enable_uboot_overlays=1

and force:

dtb=am335x-boneblack-emmc-overlay.dtb

Then reboot again, and run dmesg | grep bone

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

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Rasmus Olesen]

 I don't know how to retrieve the text from the terminal but here goes...

[0.00] Kernel command line: console=ttyO0,115200n8 
bone_capemgr.uboot_capemgr_enabled=1 
root=UUID=1be96781-5260-4113-96e 3-7c97f1fde997 ro rootfstype=ext4 rootwait 
coherent_pool=1M net.ifnames=0 quiet cape_universial=enable
[2.469004] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,000C,1631BBBG0959'
[2.469040] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone-black - #slots=4
[2.469075] bone_capemgr bone_capemgr: slot #0: auto loading handled by 
U-Boot
[2.469098] bone_capemgr bone_capemgr: slot #1: auto loading handled by 
U-Boot
[2.469141] bone_capemgr bone_capemgr: slot #2: auto loading handled by 
U-Boot
[2.469169] bone_capemgr bone_capemgr: slot #3: auto loading handled by 
U-Boot
[2.469172] bone_capemgr bone_capemgr: initialized OK.

I think I would have expected to see something actualy loaded here..?

It is the only cape I have connected to my BBB.

-- 
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/17a71ac8-af5d-4dd0-bf20-eee9398841ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] update the beagle kernel with ftp when it's running

[Robert Nelson]

On Wed, Apr 26, 2017 at 3:34 AM, Micka  wrote:
> Well, I don't mind to reboot the beagle after. I was just wondering if it's
> possible to untar all the file while the beagle is running ? I'm worried
> about some file open by the kernel/linux !

Kernel is in memory..  the biggest issue you might face is "loading" a
module after you've copied the new kernel/modules into the rootfs. As
depending on how you built it, there could be an abi diff.. (a reboot
would fix that issue to)..

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/CAOCHtYhK-2Kv6-3d0h0m0S-ik%2B95BnOd0ekyMYU-XBU6_Dc%3DQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Robert Nelson]

On Wed, Apr 26, 2017 at 9:20 AM, Rasmus Olesen
 wrote:
> Hi Robert
>
> It came in a cardboard box with loads of bubble wrap. No CD, no
> documentation. The only thing I got is what is on their web page
> http://www.newhavendisplay.com/nhd70ctpcapen-p-9537.html
>
> I have tried the Ubuntu 14.04-3.8 image, but it didn't give me a picture,
> and I couldn't get it to flash either... :(
>
> I'm wondering if the BBB is reading the CAPE EEprom correct and if I could
> verify it in the device-tree.
> I used this command in the terminal
>
> find /proc/device-tree/ -type f -exec head {} + | less
>
> It returns a really long list, But I can't seem to find any information
> about how the LCD pins a muxed...
> But I'm also faily new to linux, so I don't really know what to expect...

what does "dmesg | grep bone" show?

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/CAOCHtYhc1P%2BkD51Uqm2mDEh-sH-rnyNOFpiNc62iCaD6t_-%3DQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Rasmus Olesen]

Hi Robert

It came in a cardboard box with loads of bubble wrap. No CD, no 
documentation. The only thing I got is what is on their web page
http://www.newhavendisplay.com/nhd70ctpcapen-p-9537.html

I have tried the Ubuntu 14.04-3.8 image, but it didn't give me a picture, 
and I couldn't get it to flash either... :(

I'm wondering if the BBB is reading the CAPE EEprom correct and if I could 
verify it in the device-tree.
I used this command in the terminal

find /proc/device-tree/ -type f -exec head {} + | less

It returns a really long list, But I can't seem to find any information about 
how the LCD pins a muxed...
But I'm also faily new to linux, so I don't really know what to expect...

Regards Rasmus

 

Den onsdag den 26. april 2017 kl. 15.45.20 UTC+2 skrev RobertCNelson:
>
> On Wed, Apr 26, 2017 at 7:46 AM, Rasmus Olesen 
> > wrote: 
> > Hi all 
> > 
> > I'm trying to use the New Haven NHD-7.0CTP-CAPE with my BBB. 
> > But so far I have not been able to get a picture on the screen. 
> > I have tried running the latest Debian 8.7 image (From BeagleBoard.org), 
> > Ubuntu 14.04 Kernel 3.8 and Ubuntu 16.04.2 kernel 4.4.59-ti-r96. 
> > 
> > So far I have not been able to get a picture on the cape, but the HDMI 
> works 
> > fine. I have tried to look in the device-tree to see if I could conclude 
> > weather or not the cape was recognized. But I don't really know what to 
> look 
> > for. 
> > 
> > There must be other people out there that uses this cape, so what did 
> you do 
> > to make it work, and what distribution are you running? 
>
> Oh these are brand new: 
>
>
> http://www.newhavendisplay.com/development-tools-shields-and-capes-c-979_981.html?zenid=ihsl54v4p4fiu2rvr1b3eapd94
>  
>
> First i've seen of it, so yeah they aren't supported "this minute".. 
>
> Did they provide a CD or any documentation in the box?  if so can you 
> dump it to dropbox and share it with me? 
>
> 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/7eae90e4-13be-4a79-9df1-1a9d8daafc93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] NHD-7.0CTP-CAPE-N no picture

[Robert Nelson]

On Wed, Apr 26, 2017 at 7:46 AM, Rasmus Olesen
 wrote:
> Hi all
>
> I'm trying to use the New Haven NHD-7.0CTP-CAPE with my BBB.
> But so far I have not been able to get a picture on the screen.
> I have tried running the latest Debian 8.7 image (From BeagleBoard.org),
> Ubuntu 14.04 Kernel 3.8 and Ubuntu 16.04.2 kernel 4.4.59-ti-r96.
>
> So far I have not been able to get a picture on the cape, but the HDMI works
> fine. I have tried to look in the device-tree to see if I could conclude
> weather or not the cape was recognized. But I don't really know what to look
> for.
>
> There must be other people out there that uses this cape, so what did you do
> to make it work, and what distribution are you running?

Oh these are brand new:

http://www.newhavendisplay.com/development-tools-shields-and-capes-c-979_981.html?zenid=ihsl54v4p4fiu2rvr1b3eapd94

First i've seen of it, so yeah they aren't supported "this minute"..

Did they provide a CD or any documentation in the box?  if so can you
dump it to dropbox and share it with me?

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

[beagleboard] Re: PRU and CPU driven by different oscillators?

[Justin Pearson]

Thanks Graham. Follow-up questions: 

1. Where exactly did you find this information? I looked through the TRM 
and SRM but couldn't find anything definitive.

2. Is the 200-MHz PRU driven from the same 24 MHz oscillator that drives 
the CPU? If so, is it correct that the PRU cycle counter increments 
precisely once for every 5 CPU cycles? 

Thanks for your help.
-Justin

On Tuesday, April 25, 2017 at 7:35:19 PM UTC-7, Graham wrote:
>
> The CPU in a BBB runs from a 24 MHz Oscillator.
> There is a 25 MHz oscillator on the board, but that is for the Ethernet.
> --- Graham
>
> ==
>
> On Tuesday, April 25, 2017 at 7:09:50 PM UTC-5, Justin Pearson wrote:
>>
>> How can I find out whether the PRU and CPU are driven by the same 
>> oscillator? Specifically, a colleague told me that the IEP timer (which I'm 
>> reading with the PRU) is driven by a 24 MHz oscillator that's PLL'd so the 
>> timer increments at 200 MHz, whereas the CPU is driven by a 25 MHz 
>> oscillator PLL'd so that the CPU runs at 1 GHz.
>>
>> It seems to me that if they're driven by different oscillators, then they 
>> could drift apart over time. 
>>
>> Page 1177 of the TRM (spruh73n.pdf) mentions a 32-kHz crystal oscillator, 
>> but I don't see how that's related.
>>
>> Also, are these oscillators within the Sitara SoC, or somewhere else on 
>> the BBB? The SRM just references 24.576 MHz oscillator (pg 70 of e14 
>> BBB_SRM_rev 0.9.pdf), and I'm not sure how that's related to the 24/25 MHz 
>> oscillators my colleague mentioned.
>>
>> Thanks for your 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/a001d53b-ce5d-4b05-a0a1-d703971cb75e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] NHD-7.0CTP-CAPE-N no picture

[Rasmus Olesen]

Hi all

I'm trying to use the New Haven NHD-7.0CTP-CAPE with my BBB.
But so far I have not been able to get a picture on the screen.
I have tried running the latest Debian 8.7 image (From BeagleBoard.org), 
Ubuntu 14.04 Kernel 3.8 and Ubuntu 16.04.2 kernel 4.4.59-ti-r96.

So far I have not been able to get a picture on the cape, but the HDMI 
works fine. I have tried to look in the device-tree to see if I could 
conclude weather or not the cape was recognized. But I don't really know 
what to look for.

There must be other people out there that uses this cape, so what did you 
do to make it work, and what distribution are you running?

Thanks Rasmus.

-- 
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/8ef45a8d-11ec-47e8-b06e-b18bab4d4545%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] JTAG Access

[prashanthg24]

Hi,

I'm using Beaglebone black, I'm developing a low level drivers  for this 
board. I'm using GHS probe and have soldered a JTAG header. Initially I was 
to debug and download the code on to the board successfully. From past few 
days I'm not able to debug or download any code , I do receive a error 
message "Icepick couldn't activate the core". Can you please let me know 
the reason for this behavior ? 

Best regards
Prashanth

-- 
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/bd92da73-a23b-4fab-836c-c8b427ac37cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone black ssh problem

[l . haram92]

Hi, I am using beaglebone black with wifi usb dongle. 
While I was working on connecting wifi network using wifi usb dongle, I 
edited configuration file and my beaglebone stopped working.
I tried to ssh using putty and I can't even connect to ssh (ssh login 
window is now displaying).
I believe that I did something wrong with configuration file and I do now 
know how to resolve this issue.

I am very new to beaglebone black and I need some help.
I would greatly appreciate it if someone help me..
Thank you

-- 
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/d850275f-32c1-48ca-ade2-a5e60458251b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

[ThomasL]

Also, we presume that when using the cape-universala with pin config we are 
doing the toggles trough software with the bone-pinmux-helper instead of 
connecting register 30 to the output pads. We only get a toggle speed of 
around 2MHz which should be way higher if it was the PRU controlling the 
pin directly.


-- 
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/bf181e1f-54f8-4582-93f5-a4bc39c305c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] No GPIO access from PRU's - GPIO toggle example - device tree overlay/pinmux problem?

[ThomasL]

Thanks for your reply.

using uEnv.txt no capes are loaded on boot since we had pin conflicts with 
the emmc virtual cape. 
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.4.54-ti-r93
#uuid=
#dtb=

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

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

##BeagleBone Black: eMMC disabled:
#dtb=am335x-boneblack-hdmi-overlay.dtb

##BeagleBone Black: HDMI Audio/eMMC disabled:
#dtb=am335x-boneblack-nhdmi-overlay.dtb

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

##BeagleBone Black: wl1835
#dtb=am335x-boneblack-wl1835mod.dtb

##BeagleBone Green: eMMC disabled
#dtb=am335x-bonegreen-overlay.dtb

###U-Boot Overlays###
###Documentation: 
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
#enable_uboot_overlays=1
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
###Custom Cape
#dtb_overlay=/lib/firmware/EBB-PRU-Custom-00A0.dtbo
###Disable auto loading of virtual capes (emmc/video/wireless)
disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
###Cape Universal Enable
#enable_uboot_cape_universal=1
###U-Boot fdt tweaks...
#uboot_fdt_buffer=0x6
###U-Boot Overlays###

cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=disable

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=enable 
video=HDMI-A-1:1024x768@60e

##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh


On boot the slots looks like this:
root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
root@beaglebone:~#


And then I can load my overlay to a slot, but no pins are toggeling. If I 
load cape-universal instead, and do the config-pin, the pin starts 
toggeling.



-- 
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/bc43a399-5520-4779-b971-6e8523f766d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] update the beagle kernel with ftp when it's running

[Micka]

Well, I don't mind to reboot the beagle after. I was just wondering if it's
possible to untar all the file while the beagle is running ? I'm worried
about some file open by the kernel/linux !

Micka,

Le mar. 25 avr. 2017 à 17:03, Robert Nelson  a
écrit :

> On Tue, Apr 25, 2017 at 9:59 AM, Micka  wrote:
> > Hi,
> >
> > I would like to know if someone has tried to update the kernel while the
> > beagle is running ? Is it possible ?
> >
> > Robert Nelson, when you compile the kernel, you put files in the
> > bb-kernel/deploy folder. Can I copy those files to the beagle and untar
> > during the boot ?
>
> kexec is enabled, try it ;)
>
> 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/CAOCHtYhKsv%3D_hqyKR5fJBrCoa%3DNdbbzw5rQrP1ONM95crgWa3g%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/CAF%2BMRtmOAa7%3DtzdtYpUgQQKXYcf88ND7Gq0zXv6Ms%3DGcj%2B%2BVog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Explanation of PRU Programming in C

[Joseph Heller]

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

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