Re: [beagleboard] hdmi audio stops 10 minutes after boot, repeatable

[William Hermans]

Any reason why you can't look at the post you made yesterday ?

On Mon, Jan 2, 2017 at 12:17 PM, John Franey  wrote:

> Black's hdmi connected to an hdmi-2-av external powered device connected
> to a power amplifier connected to speakers.
>
> In other words:  Black -> hdmi-2-av -> amplifier -> speakers
>
> Audio is tested with 'speaker-test'.  Speaker-test is started soon after
> reboot.  "Right channel.left channel.right channelleft
> channel"
>
> The test tone is heard as expected until exactly 10 minutes after reboot.
>
> The only external sign of a problem is no more sound.  There are no log
> messages in dmesg or /var/log/*.  speaker-test continues to run, sending
> text to stdout.
>
>
> Any hypotheses?
>
> How can I debug?
>
> Thanks.
> John
>
>
>
>
> Other info:
>
> The faulty black runs this linux:
>
> root@beaglebone:~# uname -a
> Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l
> GNU/Linux
> root@beaglebone:~# cat /etc/debian_version
> 8.6
>
>
>
> I have a second black and it does not have audio problem.  It was
> purchased several months earlier than the above.  It is running factory
> provided angstrom.  I don't have it handy to obtain the 'uname -a' output.
>
> --
> 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/5a14a8d0-919d-4801-8940-2fb9c4a29b70%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/CALHSORrfk4WVm7JLHqvnu%2BhH0VBijmts%3DW3-24xvOXAXuahjCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Cape Manager for U-Boot

[William Hermans]

dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo

*Seems* to work fine as well. I've no reason to think it doesn't work, but
I have not tested the SPI transmission with spidev_test, or a logic
analyzer *YET*. The overlay does seem to load the drivers fine

loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb ...
60139 bytes read in 40 ms (1.4 MiB/s)
debug: [dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo] ...
loading /lib/firmware/BB-SPIDEV0-00A0.dtbo ...
1235 bytes read in 60 ms (19.5 KiB/s)
loading /boot/initrd.img-4.4.12-ti-r31 ...

 And the interfaces show up in /dev/

debian@beaglebone:~$ ls /dev |grep spidev
spidev1.0
spidev1.1



On Fri, Dec 30, 2016 at 5:25 PM, William Hermans <yyrk...@gmail.com> wrote:

> So I thought about it for a few minutes when not otherwise busy, and
> figured it out on my own.
>
>
> $ cd /opt/scripts/tools/developers/
> $ git pull
> $ sudo ./update_bootloader.sh
> $ sudo reboot
>
> serial debug:
> ...
> [84389.038894] reboot: Restarting system
>
> U-Boot SPL 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57)
> Trying to boot from MMC2
>
> *U-Boot 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600),
> Build: jenkins-github_Bootloader-Builder-497*
> ...
>
>
> *But I forgot to change /boot/uEnv.txt to allow uboot cape manager . . .*
> $ sudo nano /boot/uEnv.txt
> . . .
> ##BeagleBone Black: HDMI (Audio/Video) disabled:
> *enable_uboot_overlays=1*
> dtb=am335x-boneblack-emmc-overlay.dtb
> dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo
>
> . . .
>
> Serial debug now:
> loading /boot/vmlinuz-4.4.12-ti-r31 ...
> 640 bytes read in 514 ms (14.4 MiB/s)
> loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb ...
> 60139 bytes read in 39 ms (1.5 MiB/s)
>
>
> *debug: [dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo] ...loading
> /lib/firmware/BB-W1-P8.26-00A0.dtbo ...974 bytes read in 72 ms (12.7 KiB/s)*
>
> Testing 1-wire temp sensor:
> debian@beaglebone:~$ cat /sys/bus/w1/devices/28-0647ddf6/w1_slave
> 1c 01 4b 46 7f ff 04 10 e8 : crc=e8 YES
> 1c 01 4b 46 7f ff 04 10 e8 t=17750
>
> Everything working fine.
>
> On Fri, Dec 30, 2016 at 2:07 PM, William Hermans <yyrk...@gmail.com>
> wrote:
>
>> On Fri, Dec 30, 2016 at 11:03 AM, Robert Nelson <robertcnel...@gmail.com>
>> wrote:
>>
>>> Okay, time to push it out as default...
>>>
>>> First stable build is:
>>>
>>> U-Boot SPL 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57)
>>> Trying to boot from MMC1
>>>
>>> U-Boot 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600),
>>> Build: jenkins-github_Bootloader-Builder-497
>>>
>>> This includes a U-Boot overlays disabled by default, end user has to
>>> enable in /boot/uEnv.txt overide..
>>>
>>> Doc's:
>>>
>>> to enable this new feature, set enable_boot_overlays in /boot/uEnv.txt
>>>
>>> enable_uboot_overlays=1
>>>
>>> First 4 slots are then auto-loaded
>>> 5th slot, can be set by user
>>>
>>> dtb_overlay=/lib/firmware/*.dtbo
>>>
>>> Works best with a r78 based v4.4.x kernel..
>>>
>>
>> Hey Robert,
>>
>> So, a question some of us who already have existing, and working images
>> may have. Is how do we update our uboot ? When updating to a new kernel, I
>> suspect this will happen automatically via dpkg. But what if "we" do not
>> wish to update our kernel? Things may be working perfectly etc, and maybe
>> we're a bit skittish about updating to a newer kernel. Or maybe we have
>> kernel reliant software ( custom kernel modules, etc ).
>>
>> I just did a git pull update of the scripts repo's but the only two files
>> updated seem like they're unrelated. Or maybe it just seems that way to me
>> . . .
>>
>
>

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

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[William Hermans]

Ok so here is the quick skinny( untested ) to setup spidev on kernel 4.x.
By untested, I mean I have not actually tested the signal generated, or
received by the device. I was reading however, there is a "spidev_test" bit
of code you can use to test send / receive by shorting MISO to MOSI( I'm
supposing at it's the only way that makes sense ). However I want to read
more about this code, I've not seen yet. Information is rather sparse from
my source. Here: http://elinux.org/BeagleBone_Black_Enable_SPIDEV

I will say however that the information was rather plain, and easy for me
to understand anyway. But I also know there are already pre-made overlays
included with most, if not all images  now days. Official images that is .
. . But if you do need other pins than what's used in these overlays. You'd
have to write your own overlay, and include it in /lib/firmware. With that
said, I'm not exactly sure how that works, or technically if it's even
possible. My understand of spidev is that it is a software only driver for
SPI, but I'm not 100% sure if you need physical hardware to be used with
spidev, or not. Anyway . . .

*Test for already functioning spidev interfaces:*
debian@beaglebone:~$ ls /dev |grep spi
*Check which spidev overlays come with stock image:*
debian@beaglebone:~$ ls /lib/firmware/ |grep SPI
BB-SPI0-MCP3008-00A0.dtbo
BB-SPIDEV0-00A0.dtbo
BB-SPIDEV1-00A0.dtbo
BB-SPIDEV1A1-00A0.dtbo

*Edit /boot/uEnv.txt to load chosen overlay at boot:*
##BeagleBone Black: HDMI (Audio/Video) disabled:
enable_uboot_overlays=1
dtb=am335x-boneblack-emmc-overlay.dtb
dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo

The above requires a little extra explanation. enable_uboot_overlays=1 is
required to enable uboot loading of overlays. The line after that loads the
device tree board file I want loaded at boot. It disables both forms of
HDMI. Which strictly speaking I'm not sure is necessary for the given
overlay im loading. But is something I personally always do. Since I never
use HDMI. dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo loads the overlay
I want through uboot, at boot.

*Rebot required to take effect:*
debian@beaglebone:~$ sudo reboot

*Test again for functioning spidev interfaces:*
debian@beaglebone:~$ ls /dev |grep spi
spidev1.0
spidev1.1

Profit !

Do keep in mind that this is the very newest way to load overlays at boot.
However, with that said, this would also work nearly exactly the same with
the previous method with one exception. Instead of using:

enable_uboot_overlays=1
dtb=am335x-boneblack-emmc-overlay.dtb
dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo

*You would use*
dtb=am335x-boneblack-emmc-overlay.dtb
. . .
##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0

Pretty straight forward, and it's been this way a while now. There is one
caveat however. If you're loading a custom overlay( one not included with
the stock image ), you need to inject it into the initramfs. This is done
by. . .

debian@beaglebone:~$ cd /opt/scripts/tools/developers/
debian@beaglebone:/opt/scripts/tools/developers$ git pull
debian@beaglebone:/opt/scripts/tools/developers$ sudo ./update_initrd.sh

*AFTER* You make sure your custom overlay is located in /lib/firmware



On Sun, Jan 1, 2017 at 4:21 PM, William Hermans <yyrk...@gmail.com> wrote:

> So, if you think "ah this is confusing . . ." it does get worse.
>
> The new future way( I suspect) to load overlays at boot will likely be
> through uboot. Robert has recently added this functionality into uboot,
> I've tested it, and it does seem to work great. But I think this is for
> 4.1.x kernels and above only. However, this pretty much renders the need to
> inject your overlays into the initramfs moot. It may also be a little
> faster, but I can not see it being hugely faster. It has been said however
> it will make other issues with various devices at boot - Better.
>
> You can read about it some here: https://groups.google.com/
> forum/#!searchin/beagleboard/HERE$20THERE$20BE%7Csort:
> relevance/beagleboard/W0QPDee5u2s/c1cbhzN4FAAJ
>
> On Sun, Jan 1, 2017 at 4:04 PM, William Hermans <yyrk...@gmail.com> wrote:
>
>> I meant to say I've not used SPI on any embedded Linux platform. I do
>> have plenty of experience with SPI on bare metal MCU's.
>>
>> On Sun, Jan 1, 2017 at 3:35 PM, Greg <soapy-sm...@comcast.net> wrote:
>>
>>> Nice!  I will add this as a reference to my project documentation.
>>>
>>> Regarding the fact that you have to run config-pin after each boot, you
>>> can add a section that the config-pin commands can be added
>>> to whatever start-up configuration is most appropriate.
>>>
>>> The way I am doing this currently is to simply list the commands in a
>>> text file like:
>>>
>>> config-pin P

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[William Hermans]

So, if you think "ah this is confusing . . ." it does get worse.

The new future way( I suspect) to load overlays at boot will likely be
through uboot. Robert has recently added this functionality into uboot,
I've tested it, and it does seem to work great. But I think this is for
4.1.x kernels and above only. However, this pretty much renders the need to
inject your overlays into the initramfs moot. It may also be a little
faster, but I can not see it being hugely faster. It has been said however
it will make other issues with various devices at boot - Better.

You can read about it some here:
https://groups.google.com/forum/#!searchin/beagleboard/HERE$20THERE$20BE%7Csort:relevance/beagleboard/W0QPDee5u2s/c1cbhzN4FAAJ

On Sun, Jan 1, 2017 at 4:04 PM, William Hermans <yyrk...@gmail.com> wrote:

> I meant to say I've not used SPI on any embedded Linux platform. I do have
> plenty of experience with SPI on bare metal MCU's.
>
> On Sun, Jan 1, 2017 at 3:35 PM, Greg <soapy-sm...@comcast.net> wrote:
>
>> Nice!  I will add this as a reference to my project documentation.
>>
>> Regarding the fact that you have to run config-pin after each boot, you
>> can add a section that the config-pin commands can be added
>> to whatever start-up configuration is most appropriate.
>>
>> The way I am doing this currently is to simply list the commands in a
>> text file like:
>>
>> config-pin P8.30 pruout
>> config-pin P9.31 pruout
>> etc.
>>
>> Then add this to the .bashrc file in the home directory:
>>
>> source (path to the above file)
>>
>> Then the configuration is done automatically!
>> Check this discussion for some other interesting info on Device Tree:
>>
>> https://groups.google.com/forum/#!category-topic/beagleboard/1iFM1ywGQX4
>>
>> The impression I have gotten, and I could be wrong, is that adding or
>> subtracting overlays at the command
>> line is a not guaranteed to work operation.  The overlays should be
>> reliably controlled via uEnv.txt and the eeprom.
>>
>> On Sunday, January 1, 2017 at 4:49:57 PM UTC-5, Clayton Gulick wrote:
>>>
>>> Ok, here's the first draft: https://github.com/clay
>>> tongulick/beagle_bone_black_spi/blob/master/README.md
>>>
>>> Corrections and additions are welcome!
>>>
>> --
>> 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/daacf5b9-572f-4fcb-b609-0d598dd2f0e7%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/daacf5b9-572f-4fcb-b609-0d598dd2f0e7%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

[William Hermans]

I'd probably try to run your executable through strace, and output into a
file.

On Sun, Jan 1, 2017 at 1:25 PM, John Franey  wrote:

> I have hdmi audio working up until 10 minutes from boot time.  Exactly 10
> minutes.every boot.
>
> I test with 'speaker-test'.  Running continuously.  Output stops exactly
> at TimeBoot + 10mins.
>
> There is no outward appearance of a problem:
> 1)  The output of speaker-test is not affected.  Blissfully continues to
> test: "Right channelLeft channelRight channeletc".
> 2) No message in dmesg.
> 3) No message in /var/log/*
>
>
> How can I debug?
>
> Any hypotheses?
>
> Thanks
>
> root@beaglebone:~# uname -a
> Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l
> GNU/Linux
>
> root@beaglebone:~# cat /etc/debian_version
> 8.6
>
>
> --
> 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/3c2aedb0-70b7-42ff-8ef7-4782590f9838%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/CALHSORpqqjTjzuw3H7iYg2jCwwHqhU1Bf-K1XRDzqa9pky3DQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[William Hermans]

I meant to say I've not used SPI on any embedded Linux platform. I do have
plenty of experience with SPI on bare metal MCU's.

On Sun, Jan 1, 2017 at 3:35 PM, Greg  wrote:

> Nice!  I will add this as a reference to my project documentation.
>
> Regarding the fact that you have to run config-pin after each boot, you
> can add a section that the config-pin commands can be added
> to whatever start-up configuration is most appropriate.
>
> The way I am doing this currently is to simply list the commands in a text
> file like:
>
> config-pin P8.30 pruout
> config-pin P9.31 pruout
> etc.
>
> Then add this to the .bashrc file in the home directory:
>
> source (path to the above file)
>
> Then the configuration is done automatically!
> Check this discussion for some other interesting info on Device Tree:
>
> https://groups.google.com/forum/#!category-topic/beagleboard/1iFM1ywGQX4
>
> The impression I have gotten, and I could be wrong, is that adding or
> subtracting overlays at the command
> line is a not guaranteed to work operation.  The overlays should be
> reliably controlled via uEnv.txt and the eeprom.
>
> On Sunday, January 1, 2017 at 4:49:57 PM UTC-5, Clayton Gulick wrote:
>>
>> Ok, here's the first draft: https://github.com/clay
>> tongulick/beagle_bone_black_spi/blob/master/README.md
>>
>> Corrections and additions are welcome!
>>
> --
> 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/daacf5b9-572f-4fcb-b609-0d598dd2f0e7%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/CALHSORr7qTWcwhLZgzVgA907oohLX0iV6eqAQnnuo39bcK_%3DOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[William Hermans]

On Sun, Jan 1, 2017 at 2:08 PM, Greg  wrote:

> Hi William, if you could point to an easily discoverable source which says
> that Universal IO is available in the latest images and encouraged to be
> used, then you could be correct.
> Being able to successfully manipulate the SOC multiplexer is fundamental
> to getting a Beagleboard project off the ground.
> If there is no such info, which should be right at the top, then Clayton's
> post is a pretty good version 1.0 guide for newbies.
>

Here is the thing.

The way things are right now, one could, but perhaps should not be editing
the first stage environment file. That is to say: /uEnv.txt. Instead we
could argue that "we" should be using /boot/uEnv.txt. In other words,
optargs. So from that perspective, this is outdated information, which will
definitely contribute to the confusion for new comers. Coming from a
different angle, the first stage environment file is definitely not newb
friendly and should be avoided. One simple typo, or mis-pressed key, and
the system will no longer boot. In addition to the above.

So, after that, there are multiple ways to load an overlay file. One of
which would be more consistent with using universal IO. Which is to use the
universal IO script 'config-pin'. So . . .

$ config-pin overlay 

Which also means this could be loaded about 3 different ways at boot
through rc.local, a cron job, or as a service.

Another thing of importance is that if your device tree overlay is not
stock, it won't load at boot, through the second stage environment file.
Robert wrote a script to remedy this issue. But basically you need to
inject your overlay binary into the initramfs. This script makes an
otherwise tedious job, very simple.

Anyway, if one were to examine the contents of /bootuEnv.txt, it would, or
at least should become very clear how it is expected to load an overlay
file at boot. There is an example for 3.8.x, and another for 4.x kernels.

As for me providing instructions as to how I believe this should be done
properly. Well I have not exactly used SPI on this platform, or any
embedded platform period. For this platform specifically because, in the
case of a gpio multiplexer, SPI would be the furthest thing from my mind.
Because it would tie up too many extra pins. Which if I'm using an expander
/ multiplexer . .. I must need pins. So, I would probably go for using one
of the already used I2C buses .  . . Which I would say, at least from my
own perspective. Is much easier to deal with than spidev. Also do keep in
mind that I do have hands on with SPI, but only from a bare metal MCU
perspective. I do however believe I could set SPI up on this platform no
problem. Granted I do have ~4 years hands on with this platform . . .

So the point in short is this. While I do appreciate that Clayton was
trying to help others like himself who may have problems getting SPI
working on the beaglebone. In actuality the information provided by this
post is not exactly correct. Even though it works. Which I think will in
the end add the the confusion of beginners to the platform.

Maybe I'll write something up for 4.x myyself, as I get time, As I did buy
myself a logic analyzer. But there would be no guarantee as to when,
assuming even *if*.

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

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[William Hermans]

By the way, for me the key to understanding device tree was not to read any
of the garbage on the internet about it. But to actually go into several
device tree files, then learning about each subsystem used. Experimenting,
and all that. Plus I still don't know everything, but do know enough to at
least create my own overlay based off of existing overlays.

On Sun, Jan 1, 2017 at 12:12 PM, William Hermans <yyrk...@gmail.com> wrote:

> Just to be clear . . . The Hadron collider in Genva is the biggest
> engineering "feat" in the world . . .Involving over 10,000 scientists from
> over 100 countries, and I'm not sure how many engineers.
>
> Passed that, it's not surprising the Beaglebone works at all. For
> instance, you do realize that most of the packages, that you, I, or anyone
> else uses from Debian, actually comes from the Debian team Repo's right ?
> Then all of the embedded subsystems such as spidev, and all that predate
> this specific hardware ?
>
> So, the real surprise would be if the hardware DID NOT work.
>
> Then you have many, many people, who are just part of this community, Or
> part of this community, as well as others. Of whom I'll refrain of trying
> to name anyone, least I forget someone. I can think of at least one person
> who is constantly working in this community, and probably at least 10
> others who contribute a bit here and there, As needed.
>
> Additionally, I've been thinking this the whole time after this post, but
> . . . the information given here. Isn't exactly the best. I wasn't going to
> say anything, but now that I'm already posting . .  However I can pretty
> much say with 99% certainty this is because of the lack of experience from
> the OP. spidev's been around, and I happen to know someone who is very
> familiar with Linux, and got it working in a matter of minutes, from
> nothing. That is, to say. He was also new to the Beaglebone black, at that
> time. So . . .
>
> On Sun, Jan 1, 2017 at 7:43 AM, Greg <soapy-sm...@comcast.net> wrote:
>
>> Hi Clayton, what you have written is correct and the Device Tree is a
>> significant barrier to entry.
>> The Universal IO is a good solution to this, and I've had good luck with
>> it while keeping in mind my requirements to manipulate the Device Tree have
>> been minimal.
>>
>> The Beagleboard is driven by the community, and it is a wonder such a
>> complex piece of technology is accessible at all!
>> The Linux kernel has something like 8000 developers contributing, making
>> it perhaps the largest engineering project in human history.
>> The complexity of this technology is breathtaking!  I very much
>> appreciate what the community has done and I have learned a great deal and
>> also had fun.
>>
>> In looking about, Github appears to be the de-facto standard for sharing
>> information in electronic form, and the Beagleboard related stuff is there.
>> But not all of it, especially documentation, is located in several wiki
>> pages.  These pages are not reliable.
>>
>> So what I am getting at, is that Github is an accepted means of
>> publishing documentation, and you can get a public account for free.
>> If you could tidy up your post, and put it in publishable form, I think
>> it would be a good contribution to the community.
>> As far as what "publishable form" means, that could be as simple as
>> Markdown, or better yet a PDF file, which Github can display in the browser.
>>
>> Just a suggestion, good luck with your projects and please let us know
>> how it is going.
>>
>> 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/ms
>> gid/beagleboard/42488410-1f08-42eb-8aa4-30d403225f30%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/42488410-1f08-42eb-8aa4-30d403225f30%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[William Hermans]

Just to be clear . . . The Hadron collider in Genva is the biggest
engineering "feat" in the world . . .Involving over 10,000 scientists from
over 100 countries, and I'm not sure how many engineers.

Passed that, it's not surprising the Beaglebone works at all. For instance,
you do realize that most of the packages, that you, I, or anyone else uses
from Debian, actually comes from the Debian team Repo's right ? Then all of
the embedded subsystems such as spidev, and all that predate this specific
hardware ?

So, the real surprise would be if the hardware DID NOT work.

Then you have many, many people, who are just part of this community, Or
part of this community, as well as others. Of whom I'll refrain of trying
to name anyone, least I forget someone. I can think of at least one person
who is constantly working in this community, and probably at least 10
others who contribute a bit here and there, As needed.

Additionally, I've been thinking this the whole time after this post, but .
. . the information given here. Isn't exactly the best. I wasn't going to
say anything, but now that I'm already posting . .  However I can pretty
much say with 99% certainty this is because of the lack of experience from
the OP. spidev's been around, and I happen to know someone who is very
familiar with Linux, and got it working in a matter of minutes, from
nothing. That is, to say. He was also new to the Beaglebone black, at that
time. So . . .

On Sun, Jan 1, 2017 at 7:43 AM, Greg  wrote:

> Hi Clayton, what you have written is correct and the Device Tree is a
> significant barrier to entry.
> The Universal IO is a good solution to this, and I've had good luck with
> it while keeping in mind my requirements to manipulate the Device Tree have
> been minimal.
>
> The Beagleboard is driven by the community, and it is a wonder such a
> complex piece of technology is accessible at all!
> The Linux kernel has something like 8000 developers contributing, making
> it perhaps the largest engineering project in human history.
> The complexity of this technology is breathtaking!  I very much appreciate
> what the community has done and I have learned a great deal and also had
> fun.
>
> In looking about, Github appears to be the de-facto standard for sharing
> information in electronic form, and the Beagleboard related stuff is there.
> But not all of it, especially documentation, is located in several wiki
> pages.  These pages are not reliable.
>
> So what I am getting at, is that Github is an accepted means of publishing
> documentation, and you can get a public account for free.
> If you could tidy up your post, and put it in publishable form, I think it
> would be a good contribution to the community.
> As far as what "publishable form" means, that could be as simple as
> Markdown, or better yet a PDF file, which Github can display in the browser.
>
> Just a suggestion, good luck with your projects and please let us know how
> it is going.
>
> 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/42488410-1f08-42eb-8aa4-30d403225f30%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/CALHSORpdc-y5nPwp9hR4y1PyT1qqUz2sU8gi5m2kNO%2BD_EKncg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

[William Hermans]

Why the repost ? Wasn't it you who alread posted this exact same
information 2 days ago ?

On Sat, Dec 31, 2016 at 12:39 PM, Graham  wrote:

> Clayton:
> Thanks for taking the time to post this summary.
> --- Graham
>
> ==
>
> On Saturday, December 31, 2016 at 1:23:13 PM UTC-6, Clayton Gulick wrote:
>>
>> I'm posting this here hoping to save others some frustration/pain that
>> I've gone through as a noobie trying to get SPI working on the beagle bone
>> black wireless.
>>
>> The documentation for this is a shambles currently, with conflicting and
>> out of date information all over the internet.
>>
>> So, for those who find this post via google, let me explain what's going
>> on and how we got to here. SPI on the BBB is actually really easy, it just
>> may not seem like it.
>>
>> Ok, for starters when you google this, you've probably found a bunch of
>> information on dts, overlays, capemgr, slots, etc...
>>
>> I'll take a sec to explain the history of this first.
>>
>> So, linux traditionally used kernel modules (drivers) for every piece of
>> hardware that you might want to use. This strategy didn't work very well
>> when all these ARM devices like the beagle bone started showing up because
>> there were so many devices with different configurations, and it really
>> didn't make sense to add all that to the kernel. As a solution to this,
>> Linus came up with this idea for a level of abstraction called a device
>> tree.
>>
>> The device tree is basically a way to describe the mapping and purpose of
>> physical hardware to the kernel. This is done via a 'dts' file, which is a
>> source code file that lists the specific properties of the hardware. This
>> source code file is compiled into a binary that the kernel can understand,
>> a 'dtb' or 'dtbo' file. So, early on in beagle bone history, this was how
>> things were done. There were lots of dts and dtbo files that were made for
>> all sorts of different purposes, and you, as the user could swap these out
>> depending on how you want pins configured. You can also create your own.
>> This is where some of the older articles you see that have instructions
>> about creating a dts file and compiling it to enable SPI come from.
>>
>> Well, that whole thing was pretty spiffy, but there were some drawbacks.
>> One, it wasn't very approachable for new folks. You basically had to learn
>> a new language and toolchain just to configure pins. While better than
>> writing a kernel module, that still wasn't great. Also, all of this
>> configuration happened at boot time, so every time you wanted to make a
>> change you had to reboot. This really doesn't work well for a device where
>> you want to be able to hot swap extension boards and reconfigure things at
>> runtime. Third, this all happened in kernel space, which as an industry we
>> try not to do. It's better to keep as much as possible in user space.
>>
>> To address those issues: enter the Cape Manager. The cape manager is a
>> pretty fancy piece of kernel module software that has the ability to
>> dynamically load and swap out device tree overlays, and the tools live in
>> userspace. When you see instructions on the web about adding lines to
>> uEnv.txt like:
>>
>>
>> optargs=quiet drm.debug=7 capemgr.enable_partno=BB-SPIDEV0
>>
>> This is telling the cape manager to load the SPI device tree overlay at
>> boot time. Everywhere you look on the internet, this is the recommended
>> solution for enabling SPI on 'current' devices. But, it doesn't work.
>>
>> Why? Well, to explain that requires one more step.
>> Even though the cape manager is neat software from an engineering
>> perspective, and really accomplished its goals well, it still leaves
>> something to be desired from a new user perspective. Folks who are just
>> getting into the whole maker scene are reasonably confused by all this.
>>
>> To address that, some new software was created (which is enormously
>> fancy), called universal io.
>>
>> Basically what this is, is a device tree overlay that's loaded by the
>> cape manager at boot time that has the ability to dynamically configure all
>> of the pins at runtime using a tool called config-pin.
>>
>> You can see it and read more about it here:
>> https://github.com/cdsteinkuehler/beaglebone-universal-io
>>
>> So, with this utility all of the pins that aren't reserved for HDMI can
>> be hot configured by using the simple config-pin command, and this includes
>> SPI!
>>
>> So, finally after that long bit of history, here's how you actually set
>> up and use SPI on a new beagle bone black wireless with a current image:
>>
>> #data out
>> config-pin P.18 spi
>> #clock out
>> config-pin P.22 spi
>>
>> Rinse, repeat if you need other pins like CS, or MISO.
>>
>> After days of learning all of the above, and figuring all this out, I'm
>> finally able to see a beautiful output waveform on my oscope.
>>
>> I hope this helps someone else new to all this!
>>
>>
>> --
> For more options, 

Re: [beagleboard] Re: Cape Manager for U-Boot

[William Hermans]

So I thought about it for a few minutes when not otherwise busy, and
figured it out on my own.


$ cd /opt/scripts/tools/developers/
$ git pull
$ sudo ./update_bootloader.sh
$ sudo reboot

serial debug:
...
[84389.038894] reboot: Restarting system

U-Boot SPL 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57)
Trying to boot from MMC2

*U-Boot 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600),
Build: jenkins-github_Bootloader-Builder-497*
...


*But I forgot to change /boot/uEnv.txt to allow uboot cape manager . . .*
$ sudo nano /boot/uEnv.txt
. . .
##BeagleBone Black: HDMI (Audio/Video) disabled:
*enable_uboot_overlays=1*
dtb=am335x-boneblack-emmc-overlay.dtb
dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo

. . .

Serial debug now:
loading /boot/vmlinuz-4.4.12-ti-r31 ...
640 bytes read in 514 ms (14.4 MiB/s)
loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb ...
60139 bytes read in 39 ms (1.5 MiB/s)


*debug: [dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo] ...loading
/lib/firmware/BB-W1-P8.26-00A0.dtbo ...974 bytes read in 72 ms (12.7 KiB/s)*

Testing 1-wire temp sensor:
debian@beaglebone:~$ cat /sys/bus/w1/devices/28-0647ddf6/w1_slave
1c 01 4b 46 7f ff 04 10 e8 : crc=e8 YES
1c 01 4b 46 7f ff 04 10 e8 t=17750

Everything working fine.

On Fri, Dec 30, 2016 at 2:07 PM, William Hermans <yyrk...@gmail.com> wrote:

> On Fri, Dec 30, 2016 at 11:03 AM, Robert Nelson <robertcnel...@gmail.com>
> wrote:
>
>> Okay, time to push it out as default...
>>
>> First stable build is:
>>
>> U-Boot SPL 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57)
>> Trying to boot from MMC1
>>
>> U-Boot 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600),
>> Build: jenkins-github_Bootloader-Builder-497
>>
>> This includes a U-Boot overlays disabled by default, end user has to
>> enable in /boot/uEnv.txt overide..
>>
>> Doc's:
>>
>> to enable this new feature, set enable_boot_overlays in /boot/uEnv.txt
>>
>> enable_uboot_overlays=1
>>
>> First 4 slots are then auto-loaded
>> 5th slot, can be set by user
>>
>> dtb_overlay=/lib/firmware/*.dtbo
>>
>> Works best with a r78 based v4.4.x kernel..
>>
>
> Hey Robert,
>
> So, a question some of us who already have existing, and working images
> may have. Is how do we update our uboot ? When updating to a new kernel, I
> suspect this will happen automatically via dpkg. But what if "we" do not
> wish to update our kernel? Things may be working perfectly etc, and maybe
> we're a bit skittish about updating to a newer kernel. Or maybe we have
> kernel reliant software ( custom kernel modules, etc ).
>
> I just did a git pull update of the scripts repo's but the only two files
> updated seem like they're unrelated. Or maybe it just seems that way to me
> . . .
>

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

Re: [beagleboard] Re: Cape Manager for U-Boot

[William Hermans]

On Fri, Dec 30, 2016 at 11:03 AM, Robert Nelson 
wrote:

> Okay, time to push it out as default...
>
> First stable build is:
>
> U-Boot SPL 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57)
> Trying to boot from MMC1
>
> U-Boot 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600),
> Build: jenkins-github_Bootloader-Builder-497
>
> This includes a U-Boot overlays disabled by default, end user has to
> enable in /boot/uEnv.txt overide..
>
> Doc's:
>
> to enable this new feature, set enable_boot_overlays in /boot/uEnv.txt
>
> enable_uboot_overlays=1
>
> First 4 slots are then auto-loaded
> 5th slot, can be set by user
>
> dtb_overlay=/lib/firmware/*.dtbo
>
> Works best with a r78 based v4.4.x kernel..
>

Hey Robert,

So, a question some of us who already have existing, and working images may
have. Is how do we update our uboot ? When updating to a new kernel, I
suspect this will happen automatically via dpkg. But what if "we" do not
wish to update our kernel? Things may be working perfectly etc, and maybe
we're a bit skittish about updating to a newer kernel. Or maybe we have
kernel reliant software ( custom kernel modules, etc ).

I just did a git pull update of the scripts repo's but the only two files
updated seem like they're unrelated. Or maybe it just seems that way to me
. . .

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

Re: [beagleboard] Cape Manager for U-Boot

[William Hermans]

On Thu, Dec 29, 2016 at 6:25 PM, William Hermans <yyrk...@gmail.com> wrote:

> Robert, oh right the other bit of information I needed to let you know
> about . . .
>
> debian@beaglebone:~$ cd /opt/scripts/tools/developers/
> debian@beaglebone:/opt/scripts/tools/developers$ git pull
> Already up-to-date.
>
> Where the boot log still says . . .
>
> [116467.340818] reboot: Restarting system
>
> U-Boot SPL 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21)
> Trying to boot from MMC2
>
> U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600),
> Build: jenk  ins-github_Bootloader-Builder-493
>
> CPU  : AM335X-GP rev 2.1
>
> So apparently, for now. I'm unable to "play". I'd so an apt-get update.
> But somehow, I don't think that'd work ;)
>
>
What I mean, is that in this post you seem to be on build 496, where I am
still in "sync" with the last post using build 493. Not sure that is
important or not after the information you just posted about disabling cape
manager disables everything . . . but Perhaps not.

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

Re: [beagleboard] Cape Manager for U-Boot

[William Hermans]

Robert, oh right the other bit of information I needed to let you know
about . . .

debian@beaglebone:~$ cd /opt/scripts/tools/developers/
debian@beaglebone:/opt/scripts/tools/developers$ git pull
Already up-to-date.

Where the boot log still says . . .

[116467.340818] reboot: Restarting system

U-Boot SPL 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21)
Trying to boot from MMC2

U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600), Build:
jenk  ins-github_Bootloader-Builder-493

CPU  : AM335X-GP rev 2.1

So apparently, for now. I'm unable to "play". I'd so an apt-get update. But
somehow, I don't think that'd work ;)



On Thu, Dec 29, 2016 at 6:12 PM, William Hermans <yyrk...@gmail.com> wrote:

>
> On Thu, Dec 29, 2016 at 6:05 PM, Robert Nelson <robertcnel...@gmail.com>
> wrote:
>
>> You just stumbled on the biggest issue...
>>
>> Debugging's going to be fun..  Specially if the end user doesn't have
>> a usb-serial cable..
>>
>> After u-boot patches the device-tree, the kernel will never know..
>> (that's also why things, video/mmc/wl18xx will also just work better)
>>
>>
> Honestly, and obviously just my opinion. But if anyone is truly serious
> about using a beaglebone black / green*. They really need a serial debug
> cable. Otherwise, they should just "stay home". As far as spending a little
> extra time reading a couple logs, versus just one . . .yeah whatever. If
> you're serious, you're serious. A small price to pay for such a useful bit
> of hardware that can be used in many different ways.
>

-- 
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/CALHSORqn-4-7jb%2BFK5fGY6o-vWsfHtEojNH_E5noDSVVTieLdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Cape Manager for U-Boot

[William Hermans]

On Thu, Dec 29, 2016 at 6:05 PM, Robert Nelson 
wrote:

> You just stumbled on the biggest issue...
>
> Debugging's going to be fun..  Specially if the end user doesn't have
> a usb-serial cable..
>
> After u-boot patches the device-tree, the kernel will never know..
> (that's also why things, video/mmc/wl18xx will also just work better)
>
>
Honestly, and obviously just my opinion. But if anyone is truly serious
about using a beaglebone black / green*. They really need a serial debug
cable. Otherwise, they should just "stay home". As far as spending a little
extra time reading a couple logs, versus just one . . .yeah whatever. If
you're serious, you're serious. A small price to pay for such a useful bit
of hardware that can be used in many different ways.

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

Re: [beagleboard] Cape Manager for U-Boot

[William Hermans]

Ok, cool, thanks Robert.

However I feel compelled to add a bit more information just in case it ever
becomes important.

First up. While the one wire overlay does seem to work fine( I can talk to
a 1-wire temp sensor just fine ). dmesg only gives this:


*[   11.712253] Driver for 1-wire Dallas network protocol.*
Where as the serial boot log I get:

. . .
Running uname_boot ...
loading /boot/vmlinuz-4.4.12-ti-r31 ...
640 bytes read in 513 ms (14.5 MiB/s)
loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb ...
60139 bytes read in 39 ms (1.5 MiB/s)
debug: [dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo] ...
*loading /lib/firmware/BB-W1-P8.26-00A0.dtbo ...*
974 bytes read in 72 ms (12.7 KiB/s)
loading /boot/initrd.img-4.4.12-ti-r31 ...
4556959 bytes read in 308 ms (14.1 MiB/s)
debug: [console=ttyO0,115200n8
root=UUID=b83ca291-b04b-4c94-819a-b33f39e574c8 ro rootfstype=ext4 rootwait
coherent_pool=1M quiet] ...
. . .

No biggie to me, it works. So if that information is not in the dmesg
syslogs, personally I'm fine with that. But maybe that is not your desired
result ?

The rest I think you may have just answered in a new post so will read that
first.


On Thu, Dec 29, 2016 at 5:53 PM, Robert Nelson <robertcnel...@gmail.com>
wrote:

> On Thu, Dec 29, 2016 at 6:31 PM, William Hermans <yyrk...@gmail.com>
> wrote:
> >
> >
> > On Thu, Dec 29, 2016 at 3:05 PM, Robert Nelson <robertcnel...@gmail.com>
> > wrote:
> >>
> >> Okay, second pass more things work, more corner cases to fix...
> >
> > Does this replace the current method? Yes, I'm thinking for v4.10.x+ ;)
> >
> > 
>
> yeah, probably not. ;)
>
> >>
> >>
> >> What have you tested it on?  Just BB-UART2-00A0.dtbo and then i wrote
> >> this email up and got ready to go home...
> >
> >
> >  BB-W1-P8.26-00A0.dtbo which is an adaption of the "stock"
> > BB-W1-P9.12-00A0.dtbo overlay works too.
>
> Sweet!
>
> >>
> >>
> >> Will this fix the issue with the painful out of box experience with
> >> LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. ;)
> >>
> >> How do i actually test things?
> >>
> >> Easiest, /boot/uEnv.txt
> >>
> >> dtb=am335x-boneblack-overlay.dtb
> >>
> >> Regards,
> >>
> >
> > Ok so let me get one thing clear here. I can remove "dtb= > board file> and it should load automatically via uboot's board file
> loader ?
> > One caveat here, for me anyhow. I have a modified
> > am335x-boneblack-emmc-overlay.dtb with ethernet sleep functionality
> removed.
> > So, how could I load that instead of the default for the board eeprom ?
>
> As long as you specify "dtb="  i won't start with a
> different default dtb..  Your still in full control.
>
> I also want to add a variable to /boot/uEnv.txt enable this, so end
> users can easily disable 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/CAOCHtYiX1Fyp9FzcnqrU0rR91z1mN
> utd4HCqWf01t0gdnaN5oA%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/CALHSORo4w%2B_9pH3ExchYEo7h1xqPpUs5HbnNHNJW42AdhHK-Gg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Cape Manager for U-Boot

[William Hermans]

err, I kind of messed that post up. but the question is still valid, just
hanging off the wrong post. But I was curious what you mentioned in your
last post.

> adding "of_overlay_disable" to the boot arg's kills it.

So I find this a little confusing. This means we're able to disable the
kernel / userspace cap manager, or the uboot cape manager? The later
doesn't make sense to me. what who says that it needs to ?

On Thu, Dec 29, 2016 at 5:36 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Thu, Dec 29, 2016 at 3:16 PM, Robert Nelson <robertcnel...@gmail.com>
> wrote:
>
>> > First issue... Now the Kernel Cape Manager get's in the way, i need to
>> > pass a global kill switch (or find the global disable), right now you
>> > have to "disable" capes loaded by U-Boot.. (you don't have too, it
>> > just looks weird when they both load fine..)
>>
>> adding "of_overlay_disable" to the boot arg's kills it..
>>
>
> Additionally to the previous post I've made. So assuming I leave my
> dtb= in to bypass the default behavior. Does this
> work in this manner ? e.g. I need a specific, and custom board file to load
> at boot.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORq%2BNnkaV2ndNB5-5D%3DT7xHfY%2Bq_DmvpHPf9vNkaN71oCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Cape Manager for U-Boot

[William Hermans]

On Thu, Dec 29, 2016 at 3:16 PM, Robert Nelson 
wrote:

> > First issue... Now the Kernel Cape Manager get's in the way, i need to
> > pass a global kill switch (or find the global disable), right now you
> > have to "disable" capes loaded by U-Boot.. (you don't have too, it
> > just looks weird when they both load fine..)
>
> adding "of_overlay_disable" to the boot arg's kills it..
>

Additionally to the previous post I've made. So assuming I leave my
dtb= in to bypass the default behavior. Does this
work in this manner ? e.g. I need a specific, and custom board file to load
at boot.

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

Re: [beagleboard] Cape Manager for U-Boot

[William Hermans]

On Thu, Dec 29, 2016 at 3:05 PM, Robert Nelson 
wrote:

> Okay, second pass more things work, more corner cases to fix...
>
Does this replace the current method? Yes, I'm thinking for v4.10.x+ ;)



>
> What have you tested it on?  Just BB-UART2-00A0.dtbo and then i wrote
> this email up and got ready to go home...
>

 BB-W1-P8.26-00A0.dtbo which is an adaption of the "stock"
BB-W1-P9.12-00A0.dtbo overlay works too.

>
> Will this fix the issue with the painful out of box experience with
> LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. ;)
>
> How do i actually test things?
>
> Easiest, /boot/uEnv.txt
>
> dtb=am335x-boneblack-overlay.dtb
>
> Regards,
>
>
Ok so let me get one thing clear here. I can remove "dtb= and it should load automatically via uboot's board file loader
? One caveat here, for me anyhow. I have a modified
am335x-boneblack-emmc-overlay.dtb with ethernet sleep functionality
removed. So, how could I load that instead of the default for the board
eeprom ?

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

Re: [beagleboard] What kernel is recommended?

[William Hermans]

Not to mention that redesigning the same processor with a different GPU in
it would cost a lot of money too. But that does not explain the newer
processors with integrated GPU's from the same company.

On Wed, Dec 28, 2016 at 6:42 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Wed, Dec 28, 2016 at 6:20 PM, Brett Sawyer <mixmasterbr...@gmail.com>
> wrote:
>
>> Thank you Robert! FBDEV is exactly what I need for this project so I'll
>> start with option 1. I appreciate the work you have put into the
>> beagleboard.org projects. I remember the beagleboard-xm had similar
>> struggles. Why is SGX always so painful? I don't understand why TI's own
>> instructions don't work (I couldn't make them work without manually editing
>> parts of SGX, maybe I did something wrong).
>>
>
> Some say it's PowerVR's unwillingness to open source it's driver software.
> For a possible myriad of reasons. Passed that, what has me wondering, is
> why does TI continue to cripple themselves by dealing with such a company ?
> Perhaps they're trying to recoup form extravagant licensing fees, or
> perhaps they're locked into some sort of contract, I suspect us, the lowly
> end users, who actually make these people money. Will never know.
>

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

Re: [beagleboard] What kernel is recommended?

[William Hermans]

On Wed, Dec 28, 2016 at 6:20 PM, Brett Sawyer 
wrote:

> Thank you Robert! FBDEV is exactly what I need for this project so I'll
> start with option 1. I appreciate the work you have put into the
> beagleboard.org projects. I remember the beagleboard-xm had similar
> struggles. Why is SGX always so painful? I don't understand why TI's own
> instructions don't work (I couldn't make them work without manually editing
> parts of SGX, maybe I did something wrong).
>

Some say it's PowerVR's unwillingness to open source it's driver software.
For a possible myriad of reasons. Passed that, what has me wondering, is
why does TI continue to cripple themselves by dealing with such a company ?
Perhaps they're trying to recoup form extravagant licensing fees, or
perhaps they're locked into some sort of contract, I suspect us, the lowly
end users, who actually make these people money. Will never know.

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

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

Someone, it seems, I've already added to my "block list".

On Wed, Dec 28, 2016 at 6:33 PM, Gerald Coley <ger...@beagleboard.org>
wrote:

> Well, I don't know. Seems like some people will set an out of office and
> respond with Spam. I guess this is a new thing.
>
> Gerald
>
> On Wed, Dec 28, 2016 at 7:31 PM, evilwulfie <evilwul...@gmail.com> wrote:
>
>> why does this person repost these emails without adding any comments ? ?
>>
>> On 12/28/2016 5:44 PM, chao.ruth via BeagleBoard wrote:
>> > --------
>> > On Thu, 12/29/16, William Hermans <yyrk...@gmail.com> wrote:
>> >
>> >  Subject: Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND
>> THEY BE HUNGRY) ;)
>> >  To: beagleboard@googlegroups.com, "Robert Nelson" <
>> robertcnel...@gmail.com>
>> >  Date: Thursday, December 29, 2016, 1:27 AM
>> >
>> >  Anyway, this is
>> >  pretty slick. How long do you figure it'll take before
>> >  this functionality come into the default uboot ?
>> >
>> >  On Wed, Dec 28, 2016
>> >  at 9:36 AM, William Hermans <yyrk...@gmail.com>
>> >  wrote:
>> >  Robert,
>> >
>> >  Have you created a script that removes all the
>> >  unnecessary kernel modules loaded superfluously at boot ? I
>> >  mean there are a lot of them, and I'd say that 99% of
>> >  them in most cases will just be wasting a lot of memory . .
>> >  .
>> >
>> >  On Wed, Dec 28, 2016
>> >  at 9:34 AM, William Hermans <yyrk...@gmail.com>
>> >  wrote:
>> >  Ok so from a fresh emmc flashing( slightly
>> >  modified rootfs on the flasher image)
>> >
>> >  debian@beaglebone:~$ rm /uEnv.txt
>> >  rm: cannot remove '/uEnv.txt': No such file or
>> >  directory
>> >
>> >  debian@beaglebone:~$ sudo apt-get update
>> >  debian@beaglebone:~$ sudo apt-get install git
>> >
>> >  debian@beaglebone:~$ cd
>> >  /opt/scripts/tools/developers/
>> >  debian@beaglebone:/opt/scripts /tools/developers$ git
>> >  pull
>> >  debian@beaglebone:/opt/scripts /tools/developers$
>> >  sudo ./update_bootloader.sh --use-beta-bootloader
>> >  debian@beaglebone:/opt/scripts /tools/developers$
>> >  sudo reboot
>> >
>> >  U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21
>> >  -0600), Build: jenkins-github_Bootloader-Buil der-493
>> >
>> >  debian@beaglebone:~$ sudo nano /boot/uEnv.txt
>> >  ##BeagleBone Black: HDMI (Audio/Video) disabled:
>> >  dtb=am335x-boneblack-emmc-over lay.dtb
>> >  dtb_overlay=/lib/firmware/BB-W 1-P8.26-00A0.dtbo
>> >
>> >  cmdline=coherent_pool=1M quiet
>> >
>> >  debian@beaglebone:~$ sudo reboot
>> >  debian@beaglebone:~$ cat
>> >  /sys/bus/w1/devices/28-0000064 7ddf6/w1_slave
>> >  0b 01 4b 46 7f ff 05 10 a8 : crc=a8 YES
>> >  0b 01 4b 46 7f ff 05 10 a8 t=16687
>> >
>> >
>> >  One minor thing of concern - "evm" :
>> >
>> >  Are you 100%
>> >  sure, on selecting [am335x_evm] (y/n)? y
>> >  log: dd if=/tmp/tmp.HPy1G6iV9J/dl/MLO-
>> >  am335x_evm-v2017.01-rc2-r4 of=/dev/mmcblk0 seek=1 bs=128k
>> >  0+1 records in
>> >  0+1 records out
>> >  68504 bytes (69 kB) copied, 0.00287351 s, 23.8 MB/s
>> >  log: dd if=/tmp/tmp.HPy1G6iV9J/dl/u-bo
>> >  ot-am335x_evm-v2017.01-rc2-r4. img of=/dev/mmcblk0 seek=1
>> >  bs=384k
>> >
>> >
>> >  On Wed, Dec 28, 2016
>> >  at 8:52 AM, William Hermans <yyrk...@gmail.com>
>> >  wrote:
>> >  Well, I'm not sure why I should be testing
>> >  then. I do not have an LCD cape, and probably never will.
>> >  But I figured I could test my custom cape at boot *AFTER* I
>> >  get something like 1-wire to load at boot. e.g. the is
>> >  infinitely easier to test, and something I could also test
>> >  in hardware right away.
>> >
>> >  On Wed, Dec 28, 2016
>> >  at 8:27 AM, Robert Nelson <robertcnel...@gmail.com>
>> >  wrote:
>> >  On
>> >  Wed, Dec 28, 2016 at 9:25 AM, William Hermans <yyrk...@gmail.com>
>> >  wrote:
>> >
>> >  > On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson <
>> robertcnel...@gmail.com>
>> >
>> >  > wrote:
>> >
>> >  >>
>> >
>> >

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

Anyway, this is pretty slick. How long do you figure it'll take before this
functionality come into the default uboot ?

On Wed, Dec 28, 2016 at 9:36 AM, William Hermans <yyrk...@gmail.com> wrote:

> Robert,
>
> Have you created a script that removes all the unnecessary kernel modules
> loaded superfluously at boot ? I mean there are a lot of them, and I'd say
> that 99% of them in most cases will just be wasting a lot of memory . . .
>
> On Wed, Dec 28, 2016 at 9:34 AM, William Hermans <yyrk...@gmail.com>
> wrote:
>
>> Ok so from a fresh emmc flashing( slightly modified rootfs on the flasher
>> image)
>>
>> *debian@beaglebone:~$* rm /uEnv.txt
>> rm: cannot remove '/uEnv.txt': No such file or directory
>>
>> *debian@beaglebone:~$* sudo apt-get update
>> *debian@beaglebone:~$* sudo apt-get install git
>>
>> *debian@beaglebone:~$* cd /opt/scripts/tools/developers/
>> *debian@beaglebone:/opt/scripts/tools/developers$* git pull
>> *debian@beaglebone:/opt/scripts/tools/developers$* sudo
>> ./update_bootloader.sh --use-beta-bootloader
>> *debian@beaglebone:/opt/scripts/tools/developers$* sudo reboot
>>
>> U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600),
>> Build: jenkins-github_Bootloader-Builder-493
>>
>> *debian@beaglebone:~$* sudo nano /boot/uEnv.txt
>> ##BeagleBone Black: HDMI (Audio/Video) disabled:
>> dtb=am335x-boneblack-emmc-overlay.dtb
>> dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo
>>
>> cmdline=coherent_pool=1M quiet
>>
>> *debian@beaglebone:~$* sudo reboot
>> *debian@beaglebone:~$* cat /sys/bus/w1/devices/28-0647ddf6/w1_slave
>> 0b 01 4b 46 7f ff 05 10 a8 : crc=a8 YES
>> 0b 01 4b 46 7f ff 05 10 a8 t=16687
>>
>>
>> One minor thing of concern - "evm" :
>>
>> Are you 100% sure, on selecting [am335x_evm] (y/n)? y
>> log: dd if=/tmp/tmp.HPy1G6iV9J/dl/MLO-am335x_evm-v2017.01-rc2-r4
>> of=/dev/mmcblk0 seek=1 bs=128k
>> 0+1 records in
>> 0+1 records out
>> 68504 bytes (69 kB) copied, 0.00287351 s, 23.8 MB/s
>> log: dd if=/tmp/tmp.HPy1G6iV9J/dl/u-boot-am335x_evm-v2017.01-rc2-r4.img
>> of=/dev/mmcblk0 seek=1 bs=384k
>>
>>
>> On Wed, Dec 28, 2016 at 8:52 AM, William Hermans <yyrk...@gmail.com>
>> wrote:
>>
>>> Well, I'm not sure why I should be testing then. I do not have an LCD
>>> cape, and probably never will. But I figured I could test my custom cape at
>>> boot *AFTER* I get something like 1-wire to load at boot. e.g. the is
>>> infinitely easier to test, and something I could also test in hardware
>>> right away.
>>>
>>> On Wed, Dec 28, 2016 at 8:27 AM, Robert Nelson <robertcnel...@gmail.com>
>>> wrote:
>>>
>>>> On Wed, Dec 28, 2016 at 9:25 AM, William Hermans <yyrk...@gmail.com>
>>>> wrote:
>>>> > On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson <
>>>> robertcnel...@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> On Wed, Dec 28, 2016 at 9:10 AM, William Hermans <yyrk...@gmail.com>
>>>> >> wrote:
>>>> >> > So what you're telling me that testing for different boards is
>>>> >> > irrelevant ?
>>>> >>
>>>> >> That is correct.  This feature has been enabled in our version of
>>>> >> u-boot since last October or so...  So we know those boards work.
>>>> >>
>>>> >> Just finally figured out the missing piece to actually load an
>>>> overlay
>>>> >> on top of the main dtb..
>>>> >
>>>> >
>>>> > sweet. Do tell ;)
>>>>
>>>> "fdt resize"
>>>>
>>>> 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/ms
>>>> gid/beagleboard/CAOCHtYgemJazx%3Dg2qndYNmGF%2BPs%2BK%3DAE47_
>>>> Z6Vv6H03kYJO%3D6A%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/CALHSORpa-OLfZLFc1nshG541EBqfCtGX%3DT7J5DgHY1-pnmY4Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

Robert,

Have you created a script that removes all the unnecessary kernel modules
loaded superfluously at boot ? I mean there are a lot of them, and I'd say
that 99% of them in most cases will just be wasting a lot of memory . . .

On Wed, Dec 28, 2016 at 9:34 AM, William Hermans <yyrk...@gmail.com> wrote:

> Ok so from a fresh emmc flashing( slightly modified rootfs on the flasher
> image)
>
> *debian@beaglebone:~$* rm /uEnv.txt
> rm: cannot remove '/uEnv.txt': No such file or directory
>
> *debian@beaglebone:~$* sudo apt-get update
> *debian@beaglebone:~$* sudo apt-get install git
>
> *debian@beaglebone:~$* cd /opt/scripts/tools/developers/
> *debian@beaglebone:/opt/scripts/tools/developers$* git pull
> *debian@beaglebone:/opt/scripts/tools/developers$* sudo
> ./update_bootloader.sh --use-beta-bootloader
> *debian@beaglebone:/opt/scripts/tools/developers$* sudo reboot
>
> U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600),
> Build: jenkins-github_Bootloader-Builder-493
>
> *debian@beaglebone:~$* sudo nano /boot/uEnv.txt
> ##BeagleBone Black: HDMI (Audio/Video) disabled:
> dtb=am335x-boneblack-emmc-overlay.dtb
> dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo
>
> cmdline=coherent_pool=1M quiet
>
> *debian@beaglebone:~$* sudo reboot
> *debian@beaglebone:~$* cat /sys/bus/w1/devices/28-0647ddf6/w1_slave
> 0b 01 4b 46 7f ff 05 10 a8 : crc=a8 YES
> 0b 01 4b 46 7f ff 05 10 a8 t=16687
>
>
> One minor thing of concern - "evm" :
>
> Are you 100% sure, on selecting [am335x_evm] (y/n)? y
> log: dd if=/tmp/tmp.HPy1G6iV9J/dl/MLO-am335x_evm-v2017.01-rc2-r4
> of=/dev/mmcblk0 seek=1 bs=128k
> 0+1 records in
> 0+1 records out
> 68504 bytes (69 kB) copied, 0.00287351 s, 23.8 MB/s
> log: dd if=/tmp/tmp.HPy1G6iV9J/dl/u-boot-am335x_evm-v2017.01-rc2-r4.img
> of=/dev/mmcblk0 seek=1 bs=384k
>
>
> On Wed, Dec 28, 2016 at 8:52 AM, William Hermans <yyrk...@gmail.com>
> wrote:
>
>> Well, I'm not sure why I should be testing then. I do not have an LCD
>> cape, and probably never will. But I figured I could test my custom cape at
>> boot *AFTER* I get something like 1-wire to load at boot. e.g. the is
>> infinitely easier to test, and something I could also test in hardware
>> right away.
>>
>> On Wed, Dec 28, 2016 at 8:27 AM, Robert Nelson <robertcnel...@gmail.com>
>> wrote:
>>
>>> On Wed, Dec 28, 2016 at 9:25 AM, William Hermans <yyrk...@gmail.com>
>>> wrote:
>>> > On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson <
>>> robertcnel...@gmail.com>
>>> > wrote:
>>> >>
>>> >> On Wed, Dec 28, 2016 at 9:10 AM, William Hermans <yyrk...@gmail.com>
>>> >> wrote:
>>> >> > So what you're telling me that testing for different boards is
>>> >> > irrelevant ?
>>> >>
>>> >> That is correct.  This feature has been enabled in our version of
>>> >> u-boot since last October or so...  So we know those boards work.
>>> >>
>>> >> Just finally figured out the missing piece to actually load an overlay
>>> >> on top of the main dtb..
>>> >
>>> >
>>> > sweet. Do tell ;)
>>>
>>> "fdt resize"
>>>
>>> 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/ms
>>> gid/beagleboard/CAOCHtYgemJazx%3Dg2qndYNmGF%2BPs%2BK%3DAE47_
>>> Z6Vv6H03kYJO%3D6A%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/CALHSORrBGiXL74qNfji8t_8xWUyaoOLP7TYgpuPKq2bjr2UBag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

Ok so from a fresh emmc flashing( slightly modified rootfs on the flasher
image)

*debian@beaglebone:~$* rm /uEnv.txt
rm: cannot remove '/uEnv.txt': No such file or directory

*debian@beaglebone:~$* sudo apt-get update
*debian@beaglebone:~$* sudo apt-get install git

*debian@beaglebone:~$* cd /opt/scripts/tools/developers/
*debian@beaglebone:/opt/scripts/tools/developers$* git pull
*debian@beaglebone:/opt/scripts/tools/developers$* sudo
./update_bootloader.sh --use-beta-bootloader
*debian@beaglebone:/opt/scripts/tools/developers$* sudo reboot

U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600), Build:
jenkins-github_Bootloader-Builder-493

*debian@beaglebone:~$* sudo nano /boot/uEnv.txt
##BeagleBone Black: HDMI (Audio/Video) disabled:
dtb=am335x-boneblack-emmc-overlay.dtb
dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo

cmdline=coherent_pool=1M quiet

*debian@beaglebone:~$* sudo reboot
*debian@beaglebone:~$* cat /sys/bus/w1/devices/28-0647ddf6/w1_slave
0b 01 4b 46 7f ff 05 10 a8 : crc=a8 YES
0b 01 4b 46 7f ff 05 10 a8 t=16687


One minor thing of concern - "evm" :

Are you 100% sure, on selecting [am335x_evm] (y/n)? y
log: dd if=/tmp/tmp.HPy1G6iV9J/dl/MLO-am335x_evm-v2017.01-rc2-r4
of=/dev/mmcblk0 seek=1 bs=128k
0+1 records in
0+1 records out
68504 bytes (69 kB) copied, 0.00287351 s, 23.8 MB/s
log: dd if=/tmp/tmp.HPy1G6iV9J/dl/u-boot-am335x_evm-v2017.01-rc2-r4.img
of=/dev/mmcblk0 seek=1 bs=384k


On Wed, Dec 28, 2016 at 8:52 AM, William Hermans <yyrk...@gmail.com> wrote:

> Well, I'm not sure why I should be testing then. I do not have an LCD
> cape, and probably never will. But I figured I could test my custom cape at
> boot *AFTER* I get something like 1-wire to load at boot. e.g. the is
> infinitely easier to test, and something I could also test in hardware
> right away.
>
> On Wed, Dec 28, 2016 at 8:27 AM, Robert Nelson <robertcnel...@gmail.com>
> wrote:
>
>> On Wed, Dec 28, 2016 at 9:25 AM, William Hermans <yyrk...@gmail.com>
>> wrote:
>> > On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson <robertcnel...@gmail.com
>> >
>> > wrote:
>> >>
>> >> On Wed, Dec 28, 2016 at 9:10 AM, William Hermans <yyrk...@gmail.com>
>> >> wrote:
>> >> > So what you're telling me that testing for different boards is
>> >> > irrelevant ?
>> >>
>> >> That is correct.  This feature has been enabled in our version of
>> >> u-boot since last October or so...  So we know those boards work.
>> >>
>> >> Just finally figured out the missing piece to actually load an overlay
>> >> on top of the main dtb..
>> >
>> >
>> > sweet. Do tell ;)
>>
>> "fdt resize"
>>
>> 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/ms
>> gid/beagleboard/CAOCHtYgemJazx%3Dg2qndYNmGF%2BPs%2BK%3DAE47_
>> Z6Vv6H03kYJO%3D6A%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/CALHSORr_m_s9w282YhzBR6yA4Ly-Wz5e-6NLiYCsU7aVRRzjUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

Well, I'm not sure why I should be testing then. I do not have an LCD cape,
and probably never will. But I figured I could test my custom cape at boot
*AFTER* I get something like 1-wire to load at boot. e.g. the is infinitely
easier to test, and something I could also test in hardware right away.

On Wed, Dec 28, 2016 at 8:27 AM, Robert Nelson <robertcnel...@gmail.com>
wrote:

> On Wed, Dec 28, 2016 at 9:25 AM, William Hermans <yyrk...@gmail.com>
> wrote:
> > On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson <robertcnel...@gmail.com>
> > wrote:
> >>
> >> On Wed, Dec 28, 2016 at 9:10 AM, William Hermans <yyrk...@gmail.com>
> >> wrote:
> >> > So what you're telling me that testing for different boards is
> >> > irrelevant ?
> >>
> >> That is correct.  This feature has been enabled in our version of
> >> u-boot since last October or so...  So we know those boards work.
> >>
> >> Just finally figured out the missing piece to actually load an overlay
> >> on top of the main dtb..
> >
> >
> > sweet. Do tell ;)
>
> "fdt resize"
>
> 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/CAOCHtYgemJazx%3Dg2qndYNmGF%
> 2BPs%2BK%3DAE47_Z6Vv6H03kYJO%3D6A%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/CALHSORq1x4hX7pva8Qx1sHcS4%3DUPpCFWOFY3yd5-yAmCQFJWoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] EQEP pin conflict with MCASP

[William Hermans]

On Wed, Dec 28, 2016 at 8:10 AM, Kevin Cox  wrote:

> Hello
>
> I am trying to enable and use eqep0 on my BBB (kernel 4.4.30-ti-r64) and
> am encountering a pin conflict (pin 107) between the eqep driver and mcasp
> driver
>
> From dmesg output:
>
> [   41.150493] eqep 48300180.eqep: ver. 1.0
> [   41.150628] pinctrl-single 44e10800.pinmux: pin 44e109ac.0 already
> requested by 48038000.mcasp; cannot claim for 48300180.eqep
> [   41.162226] pinctrl-single 44e10800.pinmux: pin-107 (48300180.eqep)
> status -22
> [   41.169520] pinctrl-single 44e10800.pinmux: could not request pin 107
> (44e109ac.0) from group pinctrl_eqep0_pins  on device pinctrl-single
> [   41.182036] eqep 48300180.eqep: Error applying setting, reverse things
> back
>
>
> In /boot/uEnv.txt I enable bone_eqep0 and disable HDMI with/without audio:
>
> ##Example v4.1.x
> cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
> cape_enable=bone_capemgr.enable_partno=BB-UART1,bone_eqep0
>

Thats wrong. First of all cape_disable for the purpose you're trying to
achieve here is unnecessary.

william@beaglebone:~/dev$ head /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.4.27-ti-r62
#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


> In /opt/bb.org-overlays/src/arm/bone_eqep0-00A0 shows the following pins
> being used which none of them map to pin 107 on my BBB:
>
> pinctrl-single,pins = <
> BONE_P9_42B (PIN_INPUT | MUX_MODE1) // GPIO3_18 = EQEP0A_in
> BONE_P9_27  (PIN_INPUT | MUX_MODE1) // GPIO3_19 = EQEP0B_in
> BONE_P9_41B (PIN_INPUT | MUX_MODE1) // GPIO3_20 = EQEP0_index
> BONE_P9_25  (PIN_INPUT | MUX_MODE1) // GPIO3_21 = EQEP0_strobe
>
> I have found a thread here: https://groups.google.com/
> forum/#!category-topic/beagleboard/audio/YNhtwbe_b4k that shows how to
> disable mcasp0 but I am concerned that something is not configured right as
> my understanding was that eqep0 should not conflict with other hardware and
> especially a pin that should not overlap.  Am I missing something obvious.
> I thought I could just enable this driver out of the box.
>

The rest assuming your overlay is correct should just work.

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

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson <robertcnel...@gmail.com>
wrote:

> On Wed, Dec 28, 2016 at 9:10 AM, William Hermans <yyrk...@gmail.com>
> wrote:
> > So what you're telling me that testing for different boards is
> irrelevant ?
>
> That is correct.  This feature has been enabled in our version of
> u-boot since last October or so...  So we know those boards work.
>
> Just finally figured out the missing piece to actually load an overlay
> on top of the main dtb..
>

sweet. Do tell ;)

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

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

My point was that . . .

on reboot, it should show:
>
> U-Boot SPL 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21)
> Trying to boot from MMC1
>
> U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600),
> Build: jenkins-github_Bootloader-Builder-493
>
> If not, eMMC probably messing with you..
>
> dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
>

Is a bit heavy handed, and perhaps a bit too overboard.


On Wed, Dec 28, 2016 at 8:10 AM, William Hermans <yyrk...@gmail.com> wrote:

> So what you're telling me that testing for different boards is irrelevant ?
>
> On Wed, Dec 28, 2016 at 6:14 AM, Robert Nelson <robertcnel...@gmail.com>
> wrote:
>
>> On Wed, Dec 28, 2016 at 4:07 AM, William Hermans <yyrk...@gmail.com>
>> wrote:
>> > By the way, I could test with 3 different boards. and A5A, an Element14
>> > RevC, and an BBG.
>>
>> This patch/test is not about the base board's..
>>
>> This is about capes..  Especially the LCD capes...
>>
>> 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/ms
>> gid/beagleboard/CAOCHtYjRPnK4OK5OJKPFEkwFxSkQgSSO5Jhd7K15%
>> 2BRxy_X-jtg%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/CALHSORpE3BvsFb-THO%2B3xK0ciBkPnAhnxHqWuKcp8cfCK6FVbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

So what you're telling me that testing for different boards is irrelevant ?

On Wed, Dec 28, 2016 at 6:14 AM, Robert Nelson <robertcnel...@gmail.com>
wrote:

> On Wed, Dec 28, 2016 at 4:07 AM, William Hermans <yyrk...@gmail.com>
> wrote:
> > By the way, I could test with 3 different boards. and A5A, an Element14
> > RevC, and an BBG.
>
> This patch/test is not about the base board's..
>
> This is about capes..  Especially the LCD capes...
>
> 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/CAOCHtYjRPnK4OK5OJKPFEkwFxSkQgSSO5Jhd7K15%2BRxy_X-jtg%
> 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/CALHSORrkTAL-nqOSJw4AWX-2aXF5Y7UwKgaxdKopbLNrYXA7tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

By the way, I could test with 3 different boards. and A5A, an Element14
RevC, and an BBG.

On Wed, Dec 28, 2016 at 3:04 AM, William Hermans <yyrk...@gmail.com> wrote:

> So . . .
>
> On Fri, Dec 23, 2016 at 3:50 PM, Robert Nelson <robertcnel...@gmail.com>
> wrote:
>
>> Okay, i have a version of u-boot with overlays enabled, ready for some
>> basic testing..
>>
>> *Background***
>>
>> in u-boot we are doing:
>>
>> dtb= is loaded at ${fdtaddr}
>>
>> We read /boot/uEnv.txt for (dtb_overlay=)
>>
>> then load it, into ${rdaddr} #(no reason that specific address)
>>
>> Then we must run thru this routine:
>>
>> fdt addr ${fdtaddr}
>> fdt resize;
>> fdt apply ${rdaddr}
>> fdt resize;
>>
>> Without the "fdt resize, the jump to kernel bomb's in bootz."
>>
>> *
>>
>> *Actual testing...***
>>
>> Step 1: Do you have a usb serial adapter to monitor the boot process?
>>
>> no = stop reading now...  till you have one in hand...
>> yes = please continue
>>
>> Step 2: Remove /uEnv.txt  (i forgot to code that path in this test)
>>
>> rm /uEnv.txt
>>
>> Step 3: Update u-boot to v2017.01-rc2
>>
>> cd /opt/scripts/tools/developers/
>> git pull
>> ./update_bootloader.sh --use-beta-bootloader
>>
>> On reboot, it should show:
>>
>> U-Boot SPL 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21)
>> Trying to boot from MMC1
>>
>> U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600),
>> Build: jenkins-github_Bootloader-Builder-493
>>
>> If not, eMMC probably messing with you..
>>
>> dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
>>
>
> What ?!?
>
>>
>> Step 4: /boot/uEnv.txt
>>
>> remove "cape_universal=enable" we dont want any false posititves...
>>
>> dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo
>>
>> before:
>> kernel:
>> root@beaglebone:~# dmesg | grep serial
>> [2.082007] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
>> base_baud = 300) is a 8250
>> [2.096583] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 159,
>> base_baud = 300) is a 8250
>> [   20.106023] systemd[1]: Created slice system-serial\x2dgetty.slice.
>>
>> after:
>> U-Boot:
>> loading /boot/dtbs/4.4.39-ti-r75/am335x-boneblack-wireless.dtb ...
>> 64988 bytes read in 163 ms (388.7 KiB/s)
>> debug: [dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo] ...
>> loading /lib/firmware/BB-UART2-00A0.dtbo ...
>> 883 bytes read in 276 ms (2.9 KiB/s)
>>
>> kernel:
>> root@beaglebone:~# dmesg | grep serial
>> [2.081559] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
>> base_baud = 300) is a 8250
>> [2.095942] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 159,
>> base_baud = 300) is a 8250
>> [2.096807] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 160,
>> base_baud = 300) is a 8250
>> [   20.316939] systemd[1]: Created slice system-serial\x2dgetty.slice.
>>
>> Step 5: Profit!!! ;)
>>
>> *
>>
>> I know it's a little limited, but something for testing over Christmas. ;)
>>
>> FAQ:
>>
>> What does this solve?  Lots of random kernel races... (looking at
>> video/emmc/etc)... As U-Boot updates the final *.dtb and not the
>> kernel...
>>
>> What about 2+ overlays? Maybe next week, for Christmas you get one.. ;)
>>
>> Does this replace the current method? No it just improves things..
>>
>> What have you tested it on?  Just BB-UART2-00A0.dtbo and then i wrote
>> this email up and got ready to go home...
>>
>> Will it read the eeprom and auto load the correct overlay?  Sure,
>> sometime between next week and the start of the new year... ;)
>>
>> Will this fix the issue with the painful out of box experience with
>> LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. ;)
>>
>> How do i actually test things?
>>
>> Easiest, /boot/uEnv.txt
>>
>> dtb=am335x-boneblack-overlay.dtb
>> dtb_overlay=/lib/firmware/xyz.dtbo
>>
>>
> Ok, so I have zero problems testing. But what I do have problems with is
> understanding how to get from point A to point B
>
> Exact steps, with no "mumbo jumbo" in between.
>
> So fir

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

So . . .

On Fri, Dec 23, 2016 at 3:50 PM, Robert Nelson 
wrote:

> Okay, i have a version of u-boot with overlays enabled, ready for some
> basic testing..
>
> *Background***
>
> in u-boot we are doing:
>
> dtb= is loaded at ${fdtaddr}
>
> We read /boot/uEnv.txt for (dtb_overlay=)
>
> then load it, into ${rdaddr} #(no reason that specific address)
>
> Then we must run thru this routine:
>
> fdt addr ${fdtaddr}
> fdt resize;
> fdt apply ${rdaddr}
> fdt resize;
>
> Without the "fdt resize, the jump to kernel bomb's in bootz."
>
> *
>
> *Actual testing...***
>
> Step 1: Do you have a usb serial adapter to monitor the boot process?
>
> no = stop reading now...  till you have one in hand...
> yes = please continue
>
> Step 2: Remove /uEnv.txt  (i forgot to code that path in this test)
>
> rm /uEnv.txt
>
> Step 3: Update u-boot to v2017.01-rc2
>
> cd /opt/scripts/tools/developers/
> git pull
> ./update_bootloader.sh --use-beta-bootloader
>
> On reboot, it should show:
>
> U-Boot SPL 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21)
> Trying to boot from MMC1
>
> U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600),
> Build: jenkins-github_Bootloader-Builder-493
>
> If not, eMMC probably messing with you..
>
> dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
>

What ?!?

>
> Step 4: /boot/uEnv.txt
>
> remove "cape_universal=enable" we dont want any false posititves...
>
> dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo
>
> before:
> kernel:
> root@beaglebone:~# dmesg | grep serial
> [2.082007] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
> base_baud = 300) is a 8250
> [2.096583] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 159,
> base_baud = 300) is a 8250
> [   20.106023] systemd[1]: Created slice system-serial\x2dgetty.slice.
>
> after:
> U-Boot:
> loading /boot/dtbs/4.4.39-ti-r75/am335x-boneblack-wireless.dtb ...
> 64988 bytes read in 163 ms (388.7 KiB/s)
> debug: [dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo] ...
> loading /lib/firmware/BB-UART2-00A0.dtbo ...
> 883 bytes read in 276 ms (2.9 KiB/s)
>
> kernel:
> root@beaglebone:~# dmesg | grep serial
> [2.081559] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
> base_baud = 300) is a 8250
> [2.095942] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 159,
> base_baud = 300) is a 8250
> [2.096807] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 160,
> base_baud = 300) is a 8250
> [   20.316939] systemd[1]: Created slice system-serial\x2dgetty.slice.
>
> Step 5: Profit!!! ;)
>
> *
>
> I know it's a little limited, but something for testing over Christmas. ;)
>
> FAQ:
>
> What does this solve?  Lots of random kernel races... (looking at
> video/emmc/etc)... As U-Boot updates the final *.dtb and not the
> kernel...
>
> What about 2+ overlays? Maybe next week, for Christmas you get one.. ;)
>
> Does this replace the current method? No it just improves things..
>
> What have you tested it on?  Just BB-UART2-00A0.dtbo and then i wrote
> this email up and got ready to go home...
>
> Will it read the eeprom and auto load the correct overlay?  Sure,
> sometime between next week and the start of the new year... ;)
>
> Will this fix the issue with the painful out of box experience with
> LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. ;)
>
> How do i actually test things?
>
> Easiest, /boot/uEnv.txt
>
> dtb=am335x-boneblack-overlay.dtb
> dtb_overlay=/lib/firmware/xyz.dtbo
>
>
Ok, so I have zero problems testing. But what I do have problems with is
understanding how to get from point A to point B

Exact steps, with no "mumbo jumbo" in between.

So first, will this work with the latest "stable" image ? If so, why would
I want to destroy the partition table of the only boot-able partition ? I
would actually want the partition table intact so I can make these changes
while reflecting those same changes.on the boot able "image" / file system.

-- 
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/CALHSORqsXhFqQpyXsJ6Zse0fM%2BSY%2BWWx_rx8uH%2Bd0NuOEMy%3DFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: How do I keep a program running after disconnecting from ssh?

[William Hermans]

Generally, all you need is '&' to send the process to the background. So if
I had a Nodejs script called 'app.js' . . .

$ node app.js &

This would start app.js through node, then send the  process into the
background. Giving me a PID which I could use later to kill the process.

On Tue, Dec 27, 2016 at 10:56 AM, Denis Cosmin 
wrote:

> I retried with nohup and it works now. I think I had problems in the
> sender code.
>
> On Tuesday, December 27, 2016 at 7:32:46 PM UTC+2, Denis Cosmin wrote:
>>
>>
>> Hello,
>>
>> I use the BBB to turn on my christmas light using a simple relay circuit.
>> I made a simple server in python that listens to post requests, so far it
>> works, I also use Microsoft Cognitive Services to send post requests based
>> on speech commands.
>> When I start up the python server: nohup python3 server.py & everything
>> works fine while I am connected to the BBB over ssh but when I leave the
>> server stops working.
>>
>> Could you please give me some advice on how to keep python3 server
>> running after I disconnect from ssh?
>>
>> --
> 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/167a3385-0126-4c45-a7f0-2cdd1796759b%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/CALHSORpj5TFuXcCKN47k2OMpxKKXP6EvWZhNy6e91beXc44hWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Turn off VDD_5V or SYS_5V

[William Hermans]

On Mon, Dec 26, 2016 at 5:19 PM, Denis Cosmin  wrote:

> I wanted to power an Arduino and I didn't want to use a relay.
>

Technically speaking, what you're asking I do think is possible. When using
a battery, the beaglebone will still continue running after the 5VDC input
is removed. However, since the battery is only 3.7v nominal. you'll no
longer have a 5volt rail to power the USB. That's at minimum. I'm not sure
whatever other effects you'll encounter here, but the beaglebone will
continue to run until shutdown, or ( not recommended ) the battery runs out
of usable power.

Anyway, do keep in mind I'm no electronics engineer. Gerald definitely is(
just posted a comment to this post, s I write mine. ), and I'm pretty sure
Wulfman is too.

What I've done personally is powered an MSP430 V1.5 Launchpad from the 3v3
power on the P9 header. Why I did this was so that I had the external MCU
powered after the beaglebone is up, and hopefully the pins I had connected
back to the P8/P9 headers of the beaglebone already had power. That is to
keep form having to isolate input/output pins to, or from the beaglebone.
To help mitigate burning out the pins, or worse yet the AM335x processor on
the beaglebone.

With all that said, I think it would be prudent to use some sort of
"switch" to power your external board. This, if done correctly would make
absolutely sure the pins on the Arduino would not be active before the pins
on the beaglebone. Assuming you are connecting pins between the two. In
addition to that, I'm not quite sure if it would also be prudent to isolate
the pins connected between the two boards. But if I/O on the Arduino is 5V,
you'll definitely want to buffer or level convert for sure. Asthe GPIO pins
on the beaglebone are 3v3 tolerant only, while the ADC pins on the
beaglebone are 1.8v tolerant.



On Mon, Dec 26, 2016 at 5:35 PM, Gerald Coley 
wrote:

> Yes, you can turn those off by unplugging the power supply.
>
> Gerald
>
>
> On Mon, Dec 26, 2016 at 6:19 PM, Denis Cosmin 
> wrote:
>
>> I wanted to power an Arduino and I didn't want to use a relay.
>>
>> On Tuesday, December 27, 2016 at 2:15:16 AM UTC+2, Wulf Man wrote:
>>>
>>> Why would you want to do that ?
>>>
>>> On 12/26/2016 5:03 PM, Denis Cosmin wrote:
>>>
>>> Hello, is it possible to turn off the VDD_5V pin or the SYS_5V pin?
>>>
>>> --
>>> 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/6da34fb9-ba14-4468-a96b-5ac73ced7c41%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/ms
>> gid/beagleboard/4dfcbd5b-b6fd-4911-b9e3-0e4814bda97d%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
> gcol...@emprodesign.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/CAHK_S%2BeAAEtm_4XO8DAibx%3DvTdmYem_
> yOj5vdNJKX2%3DZM5z%2BWw%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/CALHSORpTvcYb51k_SVP8UNrtQu1RCgq9hDKhx6XSpZ-D0gcFTQ%40mail.gmail.com.
For more 

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

On Fri, Dec 23, 2016 at 6:15 PM, Robert Nelson 
wrote:

>
> the cpsw/eth0 is just broken. ;)  i saw on github (irc zmatt) was looking
> at it:
>
> https://github.com/dutchanddutch/bb-kernel/commit/
> 0c720957b43a8cea423b80e9fa8772ddb41c186c



hmmm, I wonder if that works ? Matthijs hehe I should have known.


> ah, just don't have /uEnv.txt, /boot.scr, /boot/boot.scr in the 1st
> partition, or /boot/uEnv.txt in any of the first 7 partitions and
> it'll ignore the microSD..
>
>
Ah, ok, sounds like it's been around a while and I just haven't realized.
Thanks for the answers, and have a great Christmas !

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

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

On Fri, Dec 23, 2016 at 5:58 PM, Robert Nelson 
wrote:

> For those interfaces, there's not a lot of overlay loading issues on
> the kernel side.  The biggest change, you should see your pin's taken
> earlier and more consistently at bootup.  You can also optimize your
> boot time more, as one of the big reasons everything we have is built
> as a module, is just too make the kernel overlays work more reliable.
>

I wonder if this will help mitigate, at least *some* of the big boot "lag"
waiting on network interfaces to come up. That alone, if so, would be a
huge plus.

Anyway, the steps you've listed above will work on emmc as well as sdcard ?

Additionally, although perhaps not related to this per se. I'd really like
to see some sort of boot options where "we" did not have to write an
environment file for the sdcard *if* we just wanted to boot from the emmc,
but would like an sdcard inserted for extra storage. That is, without
having to hack the second stage bootloader. Or is that a big deal for you
guys ? You know, I'm not even sure how that would work . . .honestly this
just popped into my head right now.

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

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[William Hermans]

Robert,

So, I have a custom overlay for a physical custom cape . . . as of this
moment, I have a few gpio's( I think around 22 ish ), 6 PWM's,, and
eventually I can put an ADC into that same overlay. Right, now for the ADC
I'm just loading the "stock" ADC overlay for ADC functionality.
Additionally, in the future I may also need to add uart4 back into the mix.
For now, our current cape no longer needs uart.

The question I have is . . . Would this improve anything for us ? Right
now, I just load the custom overlay through initramfs, which also seems
fine. For this project we do not really have a need for an LCD, but that
might change in the future. At least for *some* hardware configurations.

On Fri, Dec 23, 2016 at 3:50 PM, Robert Nelson 
wrote:

> Okay, i have a version of u-boot with overlays enabled, ready for some
> basic testing..
>
> *Background***
>
> in u-boot we are doing:
>
> dtb= is loaded at ${fdtaddr}
>
> We read /boot/uEnv.txt for (dtb_overlay=)
>
> then load it, into ${rdaddr} #(no reason that specific address)
>
> Then we must run thru this routine:
>
> fdt addr ${fdtaddr}
> fdt resize;
> fdt apply ${rdaddr}
> fdt resize;
>
> Without the "fdt resize, the jump to kernel bomb's in bootz."
>
> *
>
> *Actual testing...***
>
> Step 1: Do you have a usb serial adapter to monitor the boot process?
>
> no = stop reading now...  till you have one in hand...
> yes = please continue
>
> Step 2: Remove /uEnv.txt  (i forgot to code that path in this test)
>
> rm /uEnv.txt
>
> Step 3: Update u-boot to v2017.01-rc2
>
> cd /opt/scripts/tools/developers/
> git pull
> ./update_bootloader.sh --use-beta-bootloader
>
> On reboot, it should show:
>
> U-Boot SPL 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21)
> Trying to boot from MMC1
>
> U-Boot 2017.01-rc2-2-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600),
> Build: jenkins-github_Bootloader-Builder-493
>
> If not, eMMC probably messing with you..
>
> dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
>
> Step 4: /boot/uEnv.txt
>
> remove "cape_universal=enable" we dont want any false posititves...
>
> dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo
>
> before:
> kernel:
> root@beaglebone:~# dmesg | grep serial
> [2.082007] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
> base_baud = 300) is a 8250
> [2.096583] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 159,
> base_baud = 300) is a 8250
> [   20.106023] systemd[1]: Created slice system-serial\x2dgetty.slice.
>
> after:
> U-Boot:
> loading /boot/dtbs/4.4.39-ti-r75/am335x-boneblack-wireless.dtb ...
> 64988 bytes read in 163 ms (388.7 KiB/s)
> debug: [dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo] ...
> loading /lib/firmware/BB-UART2-00A0.dtbo ...
> 883 bytes read in 276 ms (2.9 KiB/s)
>
> kernel:
> root@beaglebone:~# dmesg | grep serial
> [2.081559] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
> base_baud = 300) is a 8250
> [2.095942] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 159,
> base_baud = 300) is a 8250
> [2.096807] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 160,
> base_baud = 300) is a 8250
> [   20.316939] systemd[1]: Created slice system-serial\x2dgetty.slice.
>
> Step 5: Profit!!! ;)
>
> *
>
> I know it's a little limited, but something for testing over Christmas. ;)
>
> FAQ:
>
> What does this solve?  Lots of random kernel races... (looking at
> video/emmc/etc)... As U-Boot updates the final *.dtb and not the
> kernel...
>
> What about 2+ overlays? Maybe next week, for Christmas you get one.. ;)
>
> Does this replace the current method? No it just improves things..
>
> What have you tested it on?  Just BB-UART2-00A0.dtbo and then i wrote
> this email up and got ready to go home...
>
> Will it read the eeprom and auto load the correct overlay?  Sure,
> sometime between next week and the start of the new year... ;)
>
> Will this fix the issue with the painful out of box experience with
> LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. ;)
>
> How do i actually test things?
>
> Easiest, /boot/uEnv.txt
>
> dtb=am335x-boneblack-overlay.dtb
> dtb_overlay=/lib/firmware/xyz.dtbo
>
> 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/CAOCHtYiSVX8-koZ2DFH36xUqEAcSwDn%
> 2Btv8phoYDE8O-tpvUXw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit 

Re: [beagleboard] Re: Announcement: Debian 8.6 released for all boards

[William Hermans]

On Fri, Dec 23, 2016 at 11:21 AM, John Dammeyer 
wrote:


> Ah the vigilante police strike again with zero information and instead the
> usual "you're an idiot for posting here comment". I'm sorry you don't
> understand this question.  If you don't have anything useful to post then
> please don't.  The forums on Beagles and Linux are littered with these
> vigilante comments of "answered before comments that in fact aren't"
>
> The Beagleboard.org group is clearly saying (and that Digikey will be
> shipping) Rev 8.6 in the near future.  I'm saying there is a problem with
> 8.6 and that it's not a good idea.  A posting where 8.6 is announced is
> IMHO a good starting spot along with a clear request for a suggestion for a
> better subject heading.
>
> Why not instead respond with "I tried vncserver with 8.6 with tightvnc on
> windows machine and didn't get garbled characters with QTerminal"? But you
> didn't.  Instead you continued this thread with a chastising message that
> this isn't a Pi Forum.  Talk about hijacking a thread.
>

Good luck with getting help with your problem. Welcome to my ignore list.

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

Re: [beagleboard] Re: Announcement: Debian 8.6 released for all boards

[William Hermans]

On Fri, Dec 23, 2016 at 10:36 AM, John Dammeyer 
wrote:

> My apologies Robert,
> I realize now after seeing your answer (sarcastic?) that the lack of a
> question mark at the end of the sentence left it as a statement rather than
> a question.  So I'll start with the question and then elaborate.
>
> Under which forum topic should I post a question on how to get Debian 8.6
> to interface correctly with the VNC so that I don't get garbled characters
> with QtTerminal or any other Qt application?
>
> The problem does not occur with Idle Lazarus or the non Qt Command Line
> Interface.  The problem does not occur with the HDMI LCD touch screen
> display from Adafruit, USB keyboard and mouse.  It appears to be with VNC
> and Windows Remote Desktop which means with headless operation.
>
> The bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img appears to be more
> responsive than the previous 8.6 I was running.
> Thank you
> John Dammeyer
>

I don't think Robert was being Sarcastic. I think he was trying to tell you
if you don't like the Debian 8.6 image - Don't use it. Plus you didn't
start your own topic, but instead hijacked another. Additionally, what the
hell are you asking ? Your question is not remotely clear, at least not to
me.

Anyway, go make your own post, and post there. Give a few details as to
what's happening, then form a proper question. Lastly, this google group is
beagleboard.org, not RaspberryPI.

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

Re: [beagleboard] HID on BBB with 4.9 kernel

[William Hermans]

On Wed, Dec 21, 2016 at 1:56 PM, roboknight <robokni...@gmail.com> wrote:

>
>
> On Tuesday, December 20, 2016 at 3:27:44 PM UTC-5, William Hermans wrote:
>>
>>
>>
>> On Tue, Dec 20, 2016 at 10:02 AM, roboknight <robok...@gmail.com> wrote:
>>
>> At the underlined point, I believe ep->desc is NULL because using the
>> kernel and an arm objdump variant,
>>>
>>> I located the assembly that is causing the NULL dereference.  Inside of
>>> usb_endpoing_dir_out, it tries to
>>> dereference ep->desc, but ep->desc must be NULL otherwise things would
>>> likely go swimmingly.  The problem
>>> is, I don't know what would cause ep->desc == NULL?  Whatever causes
>>> this (and it might be related to
>>> a function called "usb_gadget_ep_match_desc") I'd like to know because
>>> knowing might tell me how to fix
>>> whatever it is I'm doing wrong or maybe patch the code so that things
>>> might work.
>>>
>>> I'm hoping someone knowledgeable about am335x USB can help here, or
>>> maybe let me know what I'm missing
>>> in my HID configuration.  The above configuration steps may not work,
>>> however, some python code I had previously
>>> also fails to function.  It might even be possible that I just need to
>>> use the regular HID driver and not one based on
>>> libcomposite.
>>>
>>> Thanks for reading this.  Hopefully there are some answers.
>>>
>>
>> So, I'm not a USB composite framework expert. I only started reading
>> about it last night for another reason. A lot of what you're stating in
>> your last couple paragraphs here do not make sense to me. What I'm reading
>> from your post is that the end point descriptor must be NULL. but you're
>> not sure why it's NULL . . .yadda yadda yadda . . .That should not be true.
>>
>
> The yadda yadda yadda was kind of the point.  I actually have looked into
> it further and the only way that reference would actually be null is if the
> autoepconfig function couldn't choose any available endpoint because none
> of them matched the correct criteria.  I'm not sure where I'm supposed to
> SET UP the appropriate criteria, hence the question, and the details.
>
>>
>> My first impression after looking through that code is user error. Simply
>> because a function that's being used requires a valid end point descriptor
>> reference as an argument, and that argument is NULL. Which tells me that
>> whole "object" was never instantiated in the first place.
>>
> those objects aren't "instantiated".  They are actually endpoints that are
> "built-in" (you can see one for full-speed, high-speed, and now
> super-speed).  One of the endpoints is supposed to get selected based on an
> appropriate description.  Mine probably doesn't match or I haven't set one,
> hence it doesn't work.  But I don't see anywhere where I can actually
> SPECIFY the necessary things in configfs... Maybe you just can't build a
> HID device with configfs right now?  Or maybe something changed.  Either
> way, I'm researching the answer to that question so I can figure out what I
> really need to do.  Maybe there is another way I can configure a HID
> driver, not using configfs.
>
> The things I was able to do in the 3.13.xx kernel don't seem to work with
> this kernel either, or I don't have them set up correctly, hence I figured
> the "new" or current method was to use configfs.  But maybe this isn't the
> case.
>
> I have tried to get the "latest" from the TI repo, and the results are the
> same.  So I'm guessing that my kernel configuration was probably okay, but
> somehow I'm not doing something right with configfs, or configfs doesn't
> work for HID devices yet (I don't know if I believe that, but its
> possible).  At any rate, I've not managed to get it working yet.
>

Yeah that's all I was really saying. Sometimes *things* like to be done in
a certain order, or maybe a configfs step that was required was missed ?
Theres a LWN article I was reading the other day, that seems to be pretty
full of information. However, the "walk-thru" only talks about
re-implementing the mass storage gadget using USB composite.
https://lwn.net/Articles/395712/

I've also seen a few presentation type PDF's out there. I do not really
know enough about the framework to know how useful these are though. Passed
that, I have not yet seen one for HiD. Although . . . you know what, I
think DR. Phil Polstra did a presentation on emulating a keyboard using HiD
USB device, and I do think he used configfs . . . However he may have used
an ol

Re: [beagleboard] Shutting Down PRUs via RemoteProc Framework from user-space?

[William Hermans]

I typically search the web with a keyword like "Documentation/remoteproc",
and if documentation exists I'll usually find it right away. >
https://www.kernel.org/doc/Documentation/remoteproc.txt. Then I'll check
free-electrons site if I think the documentation may be different between
kernels. Since on their web site, you can look at source files, and
documentation for different kernel versions. Which often times can be
different from source and occasionally documentation one may download from
linus' tree patched for our board here . . . So I tend to start off with
the documentation in Linus' tree, then keep looking if, and when I need to
- Afterwards.

On Wed, Dec 21, 2016 at 11:31 AM, Greg <soapy-sm...@comcast.net> wrote:

> That's a good idea...I did that earlier this year when I understood the
> workings of the kernel much less.
> I don't think I made any progress figuring out how user-space access gets
> exported to virtual file system at /sys.
> Will do some grepping on the kernel sources and drill into the
> documentation and see what I can come up with.
> There is some fantastic stuff at free-electrons.com, but it is much
> material!
>
> I'm wrapping up some documentation, want to get it done, RemoteProc
> shutdown is a secondary issue so I will put it on the backburner until I
> have another look at the kernel.
>
> On Wednesday, December 21, 2016 at 9:28:38 AM UTC-5, William Hermans wrote:
>>
>> Greg, have you read the remoteproc kernel documentation ? I did like a
>> year ago, and I do want to say there is a method to halt remoteproc. But
>> I'm not sure, and even if I did read that. There is no telling if it's
>> actually been implemented yet into our kernel / kernel modules . . .
>>
>>
>> --
> 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/7bf54826-24ec-465b-a3d7-22dc5337ddff%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/7bf54826-24ec-465b-a3d7-22dc5337ddff%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Shutting Down PRUs via RemoteProc Framework from user-space?

[William Hermans]

Greg, have you read the remoteproc kernel documentation ? I did like a year
ago, and I do want to say there is a method to halt remoteproc. But I'm not
sure, and even if I did read that. There is no telling if it's actually
been implemented yet into our kernel / kernel modules . . .

On Wed, Dec 21, 2016 at 7:21 AM, Greg  wrote:

> Hello, a quick question on operating PRUs via the RemoteProc framework on
> Beaglebone:
>
> Is there a command via RemoteProc which will stop execution of firmwares
> running on the PRU(s)?
>
> There are bind and unbind capability in sys:
>
> echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/bind
> echo "4a338000.pru1" > /sys/bus/platform/drivers/pru-rproc/bind
>
> echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/unbind
> echo "4a338000.pru1"  > /sys/bus/platform/drivers/pru-rproc/unbind
>
> The unbind appears to disconnect RPMsg (character devices gone), but it
> does not halt the PRU!
>
> So after unbind, I am doing this:
>
> sudo rmmod pru_rproc
> sudo rmmod pruss
>
> So after removing pruss the PRUs appear to halt.
> So that is a total of 3 commands to halt a PRU.
>
> So what I am looking for is a RemoteProc framework capability to halt the
> PRU(s) from user-space.
> If there is none, I will use the rmmod commands as above.  I'm hoping I am
> missing a simpler method.
>
> 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/e12d6e11-3d19-469f-83bb-71f69922f125%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/CALHSORpqDtw5Yx7dARt1x8Qng_JCV_kqQSzvO6w%2BTdjaWQOqLg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 3v3 regulator bug

[William Hermans]

Ah, and I forgot to mention. Disconnecting power to the beaglebone is a
necessity when shutting down the board. Otherwise, the beaglebone will
occasionally be stuck in power limbo( what we talked about before ). Then
will be unable to reset until someone physically disconnects / reconnects
the power input to the beaglebone. Where the power is disconnected depends
on whether you're externally powering via Geralds, and mine( for that
matter ) preferred method. Or via a LiPO connected directly to the
beaglebone / PMIC.

On Wed, Dec 21, 2016 at 7:14 AM, William Hermans <yyrk...@gmail.com> wrote:

> On Wed, Dec 21, 2016 at 7:00 AM, Jason van Belzen <
> jasonvanbel...@gmail.com> wrote:
>
>> I understand that an external battery cape is the best solution.
>> Do you know if the following is possible from linux perspective:
>>
>>- We run on battery and DC power
>>- If we detect DC power loss, we close all running processes
>>- Only kernel stays active
>>- Kernel clocks itself down to a very low clockrate
>>- Kernel checks periodically if power is restored
>>- If power is restored, kernel gives itself a reboot
>>
>> Is something like this feasible or is this a very bad idea?
>>
>> Jason
>>
>
> The problem is, no matter what, I think you're going to need some sort of
> external interaction. I was the one who actually came up with the idea I
> mentioned above around 3 or so years ago. I posted about it on the groups
> here, and someone also implemented my same exact idea. Which I only
> described at a high level.
>
> Anyway, what you're asking *may* be possible, but a lot of thought, and
> perhaps some testing would have to be put into the idea. So apparently,
> soon, power management will be put into the kernel, for the beaglebones . .
> .What this means is that you should be able to hibernate, or suspend to
> ram. What I'm unclear on personally though. Is how do we wake from this
> state that we put ourselves into ?  With an x86/x86-64 we have wake on lan,
> possibly wake on wifi, etc. But all that uses power, power that may not be
> in abundance.
>
> So I think the least complicated scenario is to use an external MCU, that
> is able to detect when power is lost. The Beaglebone will also know when
> the power is gone, and in fact, will either shutdown right away. Or if the
> Debian package acpid is installed, the beaglebone will shut it's self down
> in an orderly fashion. It then just becomes a case of having some form of a
> battery(LiPO in our case connected to the battery test points ). If you
> have an external battery that is able to provide 5v to the system. Then you
> will probably want this MCU to check the AC input( or DC 5v if pre
> regulated ), then connect a few isolated pins to the beaglebone for reset,
> and a GPIO to initiate a beaglebone shutdown.
>
> But once again, you will need to put some thought into your design. Test
> it, and discuss is with a few fairly bright people. To make sure did not
> leave something out. I actually had to redesign my own software a few times
> as a few things I did not think about came to light after testing.
>

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

Re: [beagleboard] 3v3 regulator bug

[William Hermans]

On Wed, Dec 21, 2016 at 7:00 AM, Jason van Belzen 
wrote:

> I understand that an external battery cape is the best solution.
> Do you know if the following is possible from linux perspective:
>
>- We run on battery and DC power
>- If we detect DC power loss, we close all running processes
>- Only kernel stays active
>- Kernel clocks itself down to a very low clockrate
>- Kernel checks periodically if power is restored
>- If power is restored, kernel gives itself a reboot
>
> Is something like this feasible or is this a very bad idea?
>
> Jason
>

The problem is, no matter what, I think you're going to need some sort of
external interaction. I was the one who actually came up with the idea I
mentioned above around 3 or so years ago. I posted about it on the groups
here, and someone also implemented my same exact idea. Which I only
described at a high level.

Anyway, what you're asking *may* be possible, but a lot of thought, and
perhaps some testing would have to be put into the idea. So apparently,
soon, power management will be put into the kernel, for the beaglebones . .
.What this means is that you should be able to hibernate, or suspend to
ram. What I'm unclear on personally though. Is how do we wake from this
state that we put ourselves into ?  With an x86/x86-64 we have wake on lan,
possibly wake on wifi, etc. But all that uses power, power that may not be
in abundance.

So I think the least complicated scenario is to use an external MCU, that
is able to detect when power is lost. The Beaglebone will also know when
the power is gone, and in fact, will either shutdown right away. Or if the
Debian package acpid is installed, the beaglebone will shut it's self down
in an orderly fashion. It then just becomes a case of having some form of a
battery(LiPO in our case connected to the battery test points ). If you
have an external battery that is able to provide 5v to the system. Then you
will probably want this MCU to check the AC input( or DC 5v if pre
regulated ), then connect a few isolated pins to the beaglebone for reset,
and a GPIO to initiate a beaglebone shutdown.

But once again, you will need to put some thought into your design. Test
it, and discuss is with a few fairly bright people. To make sure did not
leave something out. I actually had to redesign my own software a few times
as a few things I did not think about came to light after testing.

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

Re: [beagleboard] 3v3 regulator bug

[William Hermans]

On Wed, Dec 21, 2016 at 6:42 AM, Gerald Coley 
wrote:

> In my experience, and external battery is the way to go. I designed a cape
> for that a log time ago. That let's you support multiple types of battery
> chemistry and multiple configurations.
>
> Gerald
>
> I think that is the best way to go as well. However,  was recently
involved in a project where the hardware engineer though that was a
terrible idea. Added cost, and all that. So, he designed an MCU of my
choice onto the cape, with a few isolated pins coming back to the
beaglebone. For reset, power switch, and one for a watchdog feature I also
designed into the MCU's firmware. Problem solved, it works great.

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

Re: [beagleboard] 3v3 regulator bug

[William Hermans]

On Wed, Dec 21, 2016 at 6:26 AM, Jason van Belzen 
wrote:

> Thanks for your reply.
>
> How does this issue damage the processor?
>
> Jason
>

As Gerald already said, I do not believe it does either. What does happen
however is that the board when in this state through the PMIC wont always
reset from the switch. Meaning, you have to completely disconnect the input
power, reconnect it, and then reset before the board will restart.
Additionally, some people claim that the board when in this state continues
to draw power. I don't doubt that, I've just never personally tested that.

Anyway, it's probably simpler to design a cape that deals with all this for
you. Either that, or use an external battery / charging system that
provides 5v directly to the board. In either case, you'll probably need /
want an external MCU involved .  . .

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

Re: [beagleboard] Supporting Ubuntu Core on BBB in the long term

[William Hermans]

snapd on Debian requires sid( unstable ). So would not work with any of the
official images, unless back ported.

There are many ways to achieve the same end goal. Involving chroot, BSD
like jails, etc. The idea of containerized apps has actually been around a
long time, and probably started originally with Solaris. Debian has also
picked up a lot of Solaris-isms in the past such as zfs, zraid, etc. So it
is possible that Debian also picked up the original concept of Solaris
containers. But I'm not sure.

One of the things that throws me off this whole Ubuntu core thing is that
first, It's Ubuntu, and Ubuntu is Canonical. Second, it requires
"registration" online which I think is absolutely unnecessary and
potentially insecure. With databases being cracked, and hacked all the
time. Additionally, and I am not 100% sure of this. But it seems that
Canonical s idea of monitizing Ubuntu has crept into Ubuntu core. e.g. you
search for something on the local system, and the system feeds you adverts
back from the internet as well . . . which is stupid, and crazy.

By the way, the Linux kernel is, or can be thought of as a single
executable. So it would not be impossible to containerize the kernel as
well. Usually, this is done for debugging purposes, and it may not be
possible to abstract out the hardware properly. However, I think in this
case. Personally, I would do something like a chroot jail snap . . . but
that's just me.

On Tue, Dec 20, 2016 at 12:03 AM, lorrianemayfield via BeagleBoard <
beagleboard@googlegroups.com> wrote:

>
> 
> On Tue, 12/20/16, John Syne <john3...@gmail.com> wrote:
>
>  Subject: Re: [beagleboard] Supporting Ubuntu Core on BBB in the long term
>  To: beagleboard@googlegroups.com
>  Date: Tuesday, December 20, 2016, 2:14 AM
>
>  So my
>  reading of Ubuntu Core, it the containerized system is based
>  on snaps, which are also available on Debian.
>  http://snapcraft.io
>
>  Regards,John
>
>
>
>
>
>
>  On Dec 18,
>  2016, at 7:37 PM, 'Luther Goh Lu Feng' via
>  BeagleBoard <beagleboard@googlegroups.com>
>  wrote:
>
>
>  On Monday, December 19, 2016 at
>  4:04:47 AM UTC+8, William Hermans wrote:
>  On Sun, Dec 18, 2016 at
>  1:00 PM, 'Luther Goh Lu Feng' via BeagleBoard <beagl...@googlegroups.com>
>  wrote:
>  Noted your comments. In
>  case it isn't clear, I am referring to Ubuntu Core[1],
>  not Ubuntu. My use case, I am looking at deploying BBB as
>  IoT gateway devices and I am assessing Ubuntu Core as a
>  distro of choice for IoT use case. Thanks.
>
>
>
>  -- Luther
>
>
>
>  [1] https://www.ubuntu.com/core
>
>  It's still Ubuntu.
>  Just a minimal version of.
>  I am looking at "containerised
>  operating systems"[1]. At a cursory glance, Project
>  Atomic and CoreOS didn't seem to have BBB images.I found
>  community Ubuntu Core images for BBB, and that's why I
>  am evaluating it for use now.
>  If there are any other choices out
>  there, I will be happy to consider debian based alternatives
>  that are containerised out of the box. Thanks.
>
>  -- Luther
>
>  [1] https://blog.docker.com/2015/02/the-new-minimalist-operating-systems/
>
>
>
>  --
>
>  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/8105de60-8740-41e2-8f21-43fdd5d34e8f%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/FEE2C8DE-5180-4D5C-9466-6913A6A198B9%40gmail.com.
>
>  For more options, visit https://groups.google.com/d/optout.
>   14 iebr  - Se fonde  -a   Societatea drumurilor de fier din Romji ia
>  care preia drepturile si datoriile conso'tiu'ui Stroussberg 7 19  apr   -
> Modificarea  legii   tocmelilor agricole 13 25 sept - Inaugurarea Garii de
> Nord din Bucuresti 12 oct infiintarea Universitatii d>n Ouj1872
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You re

Re: [beagleboard] Libpruio repository for Debian 7 or 8

[William Hermans]

On Tue, Dec 20, 2016 at 1:28 PM, Renzo Fabián  wrote:

> Is there a repository that allows install libpruio using "apt-get install"
> in Debian 7 or 8?
>
> Thanks.
>

No. At least not form the official, or RCN repo's.

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

Re: [beagleboard] HID on BBB with 4.9 kernel

[William Hermans]

To clarify my response somewhat. It does seem to me that you're using
configfs to create your HID device. I get that, so you're not modifying the
kernel module, or anything like that. What I'm saying is that perhaps
things have changed in how configfs is used, in order to setup a composite
HID device. Or the kernel module code has reverted to an earlier state that
was previously non functional. When moving to 4.9.x. This( the later )
seems to happen a lot in these "cutting edge" kernels. Which is why I
personally sty away from them for a few weeks at least.


I'm also not sure who would need to be contacted for this type of
situation. But it's likely the maintainer for this part of the kernel.

On Tue, Dec 20, 2016 at 1:27 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Tue, Dec 20, 2016 at 10:02 AM, roboknight <robokni...@gmail.com> wrote:
>
> At the underlined point, I believe ep->desc is NULL because using the
> kernel and an arm objdump variant,
>>
>> I located the assembly that is causing the NULL dereference.  Inside of
>> usb_endpoing_dir_out, it tries to
>> dereference ep->desc, but ep->desc must be NULL otherwise things would
>> likely go swimmingly.  The problem
>> is, I don't know what would cause ep->desc == NULL?  Whatever causes this
>> (and it might be related to
>> a function called "usb_gadget_ep_match_desc") I'd like to know because
>> knowing might tell me how to fix
>> whatever it is I'm doing wrong or maybe patch the code so that things
>> might work.
>>
>> I'm hoping someone knowledgeable about am335x USB can help here, or maybe
>> let me know what I'm missing
>> in my HID configuration.  The above configuration steps may not work,
>> however, some python code I had previously
>> also fails to function.  It might even be possible that I just need to
>> use the regular HID driver and not one based on
>> libcomposite.
>>
>> Thanks for reading this.  Hopefully there are some answers.
>>
>
> So, I'm not a USB composite framework expert. I only started reading about
> it last night for another reason. A lot of what you're stating in your last
> couple paragraphs here do not make sense to me. What I'm reading from your
> post is that the end point descriptor must be NULL. but you're not sure why
> it's NULL . . .yadda yadda yadda . . .That should not be true.
>
> My first impression after looking through that code is user error. Simply
> because a function that's being used requires a valid end point descriptor
> reference as an argument, and that argument is NULL. Which tells me that
> whole "object" was never instantiated in the first place.
>

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

Re: [beagleboard] HID on BBB with 4.9 kernel

[William Hermans]

On Tue, Dec 20, 2016 at 10:02 AM, roboknight  wrote:

At the underlined point, I believe ep->desc is NULL because using the
kernel and an arm objdump variant,
>
> I located the assembly that is causing the NULL dereference.  Inside of
> usb_endpoing_dir_out, it tries to
> dereference ep->desc, but ep->desc must be NULL otherwise things would
> likely go swimmingly.  The problem
> is, I don't know what would cause ep->desc == NULL?  Whatever causes this
> (and it might be related to
> a function called "usb_gadget_ep_match_desc") I'd like to know because
> knowing might tell me how to fix
> whatever it is I'm doing wrong or maybe patch the code so that things
> might work.
>
> I'm hoping someone knowledgeable about am335x USB can help here, or maybe
> let me know what I'm missing
> in my HID configuration.  The above configuration steps may not work,
> however, some python code I had previously
> also fails to function.  It might even be possible that I just need to use
> the regular HID driver and not one based on
> libcomposite.
>
> Thanks for reading this.  Hopefully there are some answers.
>

So, I'm not a USB composite framework expert. I only started reading about
it last night for another reason. A lot of what you're stating in your last
couple paragraphs here do not make sense to me. What I'm reading from your
post is that the end point descriptor must be NULL. but you're not sure why
it's NULL . . .yadda yadda yadda . . .That should not be true.

My first impression after looking through that code is user error. Simply
because a function that's being used requires a valid end point descriptor
reference as an argument, and that argument is NULL. Which tells me that
whole "object" was never instantiated in the first place.

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

Re: [beagleboard] Load address for beagle bone.

[William Hermans]

william@beaglebone:~$ uname -r
4.4.27-ti-r62
william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2016-10-30
william@beaglebone:~$ head /uEnv.txt
##These are needed to be compliant with Angstrom's 2013.06.20 u-boot.

loadaddr=0x8200
fdtaddr=0x8800
rdaddr=0x8808

initrd_high=0x
fdt_high=0x

##These are needed to be compliant with Debian 2014-05-14 u-boot.


On Tue, Dec 20, 2016 at 7:38 AM,  wrote:

> Hello,
>
>
>
> With a 4.8 mainline kernel zImage I use
>
>
>
> fdtaddr=0x8800
>
> loadaddr=0x8200
>
>
>
> HTH
>
>
>
> *From:* beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com]
> *On Behalf Of *Madhu K
> *Sent:* 20 December 2016 06:23
> *To:* BeagleBoard
> *Cc:* Madhu babu
> *Subject:* [beagleboard] Load address for beagle bone.
>
>
>
> HI All,
>
>
>
> What is the Kernel and device tree load address for beaglebone black board.
>
>
>
> Thanks & regards,
>
> Madhu
>
> --
> 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/f6d05fae-4d52-4c86-b2d7-391f65ba9886%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/103b01d25ace%24b4d4e660%241e7eb320%24%40novadsp.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/CALHSORrBegMF7BNfdkO93Hwy7YyHhFEUescw-3OT%3DJc2RwgYuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Wireless speed issues?

[William Hermans]

On Tue, Dec 20, 2016 at 7:16 AM, Jay Doobie  wrote:

> Is there a power supply requirement difference between the BBB and a BBBW?
>
>

You should get, and read the SRM for the BBBW. But there almost certainly
is.

>
> The BBB works great outside of my machine connected to USB on a computer,
> but within the machine it hangs and crashes.
>
> The cape powers the BBB, it has a 24v 2.7a supply.  I have noticed some
> funny things (I have to plug it in to the wall first, then the device; it
> won't start if the device is plugged in first) with the supply and am in
> the process of trying to acquire a new one.
>

Is everything that needs to be isolated properly isolated ? My buddy
designed a cape for us too, which is also 24v powered, But everything is
properly isolated, and we're doing some external power management as well.

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

Re: [beagleboard] Re: Wireless speed issues?

[William Hermans]

If your power supply reliably supplies 1A or more, at 5v, then that's
probably not the problem.

On Mon, Dec 19, 2016 at 5:00 PM, Jay Doobie <doobi...@gmail.com> wrote:

> I think I know what is going on, I think the BBBW uses a bit more power
> than the BBB, I believe the power supply that came with my 3d printer may
> either be faulty or at it's limit of what it can supply.  Going to look
> into a slightly beefier supply.
>
> On Monday, December 19, 2016 at 3:42:01 PM UTC-5, William Hermans wrote:
>>
>> Well I do not have a BBBW, but I do have an rPI 3. Disabling power save
>> at boot is fairly easy.
>>
>> william@rpi:~$ sudo nano /etc/rc.local
>> Add: /sbin/iw dev wlan0 set power_save off
>>
>> william@rpi:~$ sudo reboot
>> william@rpi:~$ iwconfig wlan0
>> wlan0 IEEE 802.11bgn  Mode:Master  Tx-Power=31 dBm
>>   Retry short limit:7   RTS thr:off   Fragment thr:off
>>   Power Management:off
>>
>> However, I have a sneaking suspicion that this, and all the other methods
>> mentioned above won't work. I'm fairly sure Robert is using some form of a
>> network manager to handle the BBBW's wireless, and in this case, disabling
>> power_save will have to be done through this network manager.
>>
>>
>>
>> On Mon, Dec 19, 2016 at 10:52 AM, Jay Doobie <doob...@gmail.com> wrote:
>>
>>> At this point I don't know what it is.  I setup a cronjob to turn off
>>> wireless power management, but something else seems to be causing a crash.
>>> My SSH hangs or so so slow that I can type "ls" and walk away to make a cup
>>> of coffee and it still hasn't done an 'ls', but 5 minutes later, bam, it
>>> happens.
>>>
>>> I've looked in dmesg and journalctl to see if there are any messages,
>>> but nothing.
>>>
>>> --
>>> 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/2c23a6b8-df50-4a95-a43d-fbd9499724c0%40googlegroups.com
>>> <https://groups.google.com/d/msgid/beagleboard/2c23a6b8-df50-4a95-a43d-fbd9499724c0%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/1a0cb60b-64ac-4cbf-b677-6999df34da78%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/1a0cb60b-64ac-4cbf-b677-6999df34da78%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Re: BBB Ethernet stopped working.

[William Hermans]

You know, I've had my hand on 4 BBB's and well over 40 BBG's and have yet
to see this problem manifest it's self.

On Mon, Dec 19, 2016 at 3:17 PM,  wrote:

> Hi Gerald,
>
> I saw your comment in response to the question about another revision to
> the BBB.  There is a long standing issue with the BBB reset related to the
> Ethernet PHY not coming out of reset properly.  In order to work around the
> problem you need to hack the board and drive the Ethernet PHY with a GPIO
> to ensure the proper reset timing for the PHY.
>
> Is there any plan by CircuitCo to make a revision to address this issue?
> Its a rather tricky hack to do because you have to drill out one of the
> via's to do it properly and that takes a special laser to do it.
>
> Here is another link to a post on the TI forum that also discusses this
> issue and I have seen it discussed here as well.  I am not aware of any
> software revision that has addressed this but perhaps there has been a
> software fix?
>
> Phy Address Issue beaglebone U-boot - Sitara Processors Forum - Sitara™
> Processors - TI E2E Community
> 
>
> Thank you,
> Steve
>
>
> On Sunday, June 14, 2015 at 6:31:58 PM UTC-6, John Reeve wrote:
>>
>> Hi All,
>>
>> I have a pair of BBB's that I bought from Canada Robotix. They are both
>> Rev C boards from Element 14. I've been running debian on a micro SD card
>> on each of them. The one board had been running a web server for about 2
>> months straight, but suddenly lost Ethernet capabilities one day. Both the
>> Ethernet LED's stay ON solid even when no cable is plugged in. I tried to
>> rule out software by loading up a couple different OS's but none of them
>> can connect to my network. I even tried flashing an experimental version of
>> debian from the beagleboard.org wiki but that did not work either. When
>> I boot into debian now I notice the ethernet lights blink for a bit then
>> stop and stay on solid, and I get messages from dmesg like:
>>
>> root@beaglebone:/var/lib/cloud9# dmesg | grep phy
>> [0.00] Booting Linux on physical CPU 0x0
>> [2.715169] 47401300.usb-phy supply vcc not found, using dummy
>> regulator
>> [2.830812] 47401b00.usb-phy supply vcc not found, using dummy
>> regulator
>> [3.392979] davinci_mdio 4a101000.mdio: detected phy mask fffe
>> [3.399823] libphy: 4a101000.mdio: probed
>> [3.399859] davinci_mdio 4a101000.mdio: phy[0]: device
>> 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
>> [   13.783697] net eth0: phy found : id is : 0x7c0f1
>> [   13.783894] libphy: PHY 4a101000.mdio:01 not found
>> [   13.788720] net eth0: phy 4a101000.mdio:01 not found on slave 1
>> [   16.863473] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
>> [   46.943180] libphy: 4a101000.mdio:00 - Link is Down
>> [   71.703444] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
>> [   79.783276] libphy: 4a101000.mdio:00 - Link is Down
>> [  111.023649] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
>> [  233.103186] libphy: 4a101000.mdio:00 - Link is Down
>> [  369.103554] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
>> [  385.183238] libphy: 4a101000.mdio:00 - Link is Down
>> etc.. etc
>>
>> Does anyone have experience with this type of problem?
>> Other info:
>> root@beaglebone:/var/lib/cloud9# uname -a
>> Linux beaglebone 3.14.43-ti-r67 #1 SMP PREEMPT Thu Jun 4 20:37:18 UTC
>> 2015 armv7l GNU/Linux
>>
>> Everything else seems to work.
>>
>> Thanks!
>>
>> -John
>>
>> .
>>
> --
> 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/4ad554f4-4cb9-440e-974f-120eb55266a8%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/CALHSORrSWmpJ4nL9chESScoXScvd06HyKy-aDmikBOA%3DFLra9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Console image vs IOT image

[William Hermans]

On Mon, Dec 19, 2016 at 3:02 PM, Ross Morrison  wrote:

> On the latest images page(https://beagleboard.org/latest-images) has
> the IOT version replaced the plain jane console image? I would really
> like to build from the latest basic console image then add options as
> needed.
>

Have you actually looked ? There is still a console image, and very likely
always will be.

>
> And, how would one go about changing the port nodejs/bonescript listens
> on? I would like to get Apache back to port 80 and move
> nodejs/bonescript over to port 8080 reversing the way they are
> shipped.
>

There are many ways, including using iptables, or nginx. However, this is
not a question that is specific to this hardware. As such searching the web
for "linux how to change Nodejs port. . ." etc will produce a lot of fruit.

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

Re: [beagleboard] Re: How to see the beagleBone Board from a VBOX running Ubuntu14.04.02LTS

[William Hermans]

On Mon, Dec 19, 2016 at 1:40 PM, Graham  wrote:

> I would recommend putting the BBB directly on the Ethernet network,
> Then connect to it via Ethernet.
>
> The USB-Bridge is useful only in certain simple connection configurations.
>
> --- Graham
>

Some people, specifically that are college students may not have the luxury
of using ethernet. In the case where they have a laptop, with ethernet
plugged into the schools network. Or even if they're using wifi, using an
additional cable may not be convenient, or otherwise very difficult if
they're using that ethernet adapter at home on a dedicated network.

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

Re: [beagleboard] Re: Wireless speed issues?

[William Hermans]

Well I do not have a BBBW, but I do have an rPI 3. Disabling power save at
boot is fairly easy.

william@rpi:~$ sudo nano /etc/rc.local
Add: /sbin/iw dev wlan0 set power_save off

william@rpi:~$ sudo reboot
william@rpi:~$ iwconfig wlan0
wlan0 IEEE 802.11bgn  Mode:Master  Tx-Power=31 dBm
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Power Management:off

However, I have a sneaking suspicion that this, and all the other methods
mentioned above won't work. I'm fairly sure Robert is using some form of a
network manager to handle the BBBW's wireless, and in this case, disabling
power_save will have to be done through this network manager.



On Mon, Dec 19, 2016 at 10:52 AM, Jay Doobie  wrote:

> At this point I don't know what it is.  I setup a cronjob to turn off
> wireless power management, but something else seems to be causing a crash.
> My SSH hangs or so so slow that I can type "ls" and walk away to make a cup
> of coffee and it still hasn't done an 'ls', but 5 minutes later, bam, it
> happens.
>
> I've looked in dmesg and journalctl to see if there are any messages, but
> nothing.
>
> --
> 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/2c23a6b8-df50-4a95-a43d-fbd9499724c0%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/CALHSORq5fKwuLxrTnWn2nydd0-Q4RH37LtJz40BQ9pCNp3-YWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Supporting Ubuntu Core on BBB in the long term

[William Hermans]

On Sun, Dec 18, 2016 at 1:00 PM, 'Luther Goh Lu Feng' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Noted your comments. In case it isn't clear, I am referring to Ubuntu
> Core[1], not Ubuntu. My use case, I am looking at deploying BBB as IoT
> gateway devices and I am assessing Ubuntu Core as a distro of choice for
> IoT use case. Thanks.
>
> -- Luther
>
> [1] https://www.ubuntu.com/core
>

It's still Ubuntu. Just a minimal version of.

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

Re: [beagleboard] Supporting Ubuntu Core on BBB in the long term

[William Hermans]

I'm not sure I understand the rationale behind wanting to run Ubuntu on the
Beaglebone hardware. Doing so would present all sort of problems for the
end user attempting to replicate what others do with this platform using
Debian. Also, while this hardware platform *can* run a desktop environment.
It's not really well suited to do so. The experience would be incredibly
slow, and potentially problematic.

Now, running Ubuntu on a Beagleboard X15 would probably make for an
excellent experience. But we're talking 4x the system memory, with a multi
core processor that is much faster.

Additionally, if one wants to run Ubuntu CLI( command line interface only
), then one needs to understand that there would really be no benefit
compared to Debian. In fact, as mentioned above. Imposing such a
"restriction" on yourself would be potentially very problematic. The only
beneficial difference here would be Ubuntu's different packages, which may,
or may not be newer in nature. For the beaglebone hardware however, this is
largely if not completely moot, and unnecessary.

The money thing I get though. They're just wanting their developers to get
paid. Which as a developer myself, I like to get paid too. However, in this
case where we're talking armhf as the platform ABI. I'm not sure why they
would want more money for something they're already doing for the rPI, and
multiple other platforms. Maybe they're talking specifically about the
beaglebone hardware abstraction . . . but seriously. Everything the
beaglebone has in hardware is already supported, Otherwise those who are
using older versions of Ubuntu successfully, would not be so successful.

On Sun, Dec 18, 2016 at 12:25 PM, evilwulfie  wrote:

> Good reasons to stick with Debian i would say.
>
> On 12/18/2016 12:23 PM, Robert Nelson wrote:
> > On Sun, Dec 18, 2016 at 12:38 PM, 'Luther Goh Lu Feng' via BeagleBoard
> >  wrote:
> >> Hi there,
> >>
> >> I am having a conversation with the Ubuntu Core community to figure out
> how
> >> to get BBB supported in the long run. I am posting the thread link here
> in
> >> case anyone is interested in this as well
> >>
> >> https://lists.ubuntu.com/archives/snapcraft/2016-December/002086.html
> > Dealing with Canonical on anything long run requires $...
> >
> > They rely on $ from support requests, by having this vibrant
> > self-sufficient community, that blows there whole profit opportunity.
> >
> > In the past Canonical has talked to us before about a special Blessed
> > BeagleBone image.. BUT they wanted "us" to support "it"...  Each time
> > I've said No, if you want "our" support on anything, you have to have
> > a ubuntu developer helping users in our forum..
> >
> > 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/5afb4cc1-da54-f026-8103-8ca55bcdee62%40gmail.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/CALHSORoQp0giYr9z8%2B3mHcb%3D2nwVseLZ9vssjmHermTZ_gMnPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] are there other ARMHF repos?

[William Hermans]

By the way, the package I built from source, would work on any armhf, using
the same libc. Which I forget which version comes on the latest beaglebone
images. but a good guide is that whichever system you want install  it on
uses the same version of gcc. So in this case, the package I built for my
beaglebones was built on a Raspberry Pi 3 running Raspbian Jessie, with gcc
4.9.x.

The point I'm trying to make here, is that this package would, and does
work for more than just the beaglebones.

On Sun, Dec 18, 2016 at 12:15 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Sun, Dec 18, 2016 at 11:56 AM, Stephane Charette <
> stephanechare...@gmail.com> wrote:
>
>> By default when I install a BB with one of the usual RCN builds, the
>> repos as defined in /etc/apt/sources.list are set to the following:
>>
>> deb http://httpredir.debian.org/debian/ jessie main contrib non-free
>> deb http://httpredir.debian.org/debian/ jessie-updates main contrib
>> non-free
>> deb http://security.debian.org/ jessie/updates main contrib non-free
>> deb https://deb.nodesource.com/node_0.12 jessie main
>> deb [arch=armhf] http://repos.rcn-ee.com/debian/ jessie main
>>
>> Are there other well-known ARMHF repos that I can add if the package I'm
>> looking for isn't there?
>>
>
> Well this is a problem. "well known" does not necessarily imply "secure".
> All those listed above except for the nodesource, and RCN repo's are
> official. Personally, I would not add the nodesource repo, but have no
> qualms with Roberts repo.
>
>>
>> For example, I like to use "fish" as my shell.  When I try to install it,
>> I get this:
>>
>> $ *sudo apt-get install fish*
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Package fish is not available, but is referred to by another package.
>> This may mean that the package is missing, has been obsoleted, or
>> is only available from another source
>> E: Package 'fish' has no installation candidate
>>
>> Yes, I could build it myself, but that defeats the entire purpose of
>> having package management, automatic updates when security fixes are
>> available, etc.
>>
>
> So build the package once, and use it multiple times. This is one reason
> why I would not use the nodesource repo. I build my own Nodejs, from source
> tarballs my self. Currently I have a Nodejs 4.6.2 *deb, that I install on
> any system that needs it. Just a simple file transfer, and sudo dpkg -i
>  away.
>
>

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

Re: [beagleboard] are there other ARMHF repos?

[William Hermans]

On Sun, Dec 18, 2016 at 11:56 AM, Stephane Charette <
stephanechare...@gmail.com> wrote:

> By default when I install a BB with one of the usual RCN builds, the repos
> as defined in /etc/apt/sources.list are set to the following:
>
> deb http://httpredir.debian.org/debian/ jessie main contrib non-free
> deb http://httpredir.debian.org/debian/ jessie-updates main contrib
> non-free
> deb http://security.debian.org/ jessie/updates main contrib non-free
> deb https://deb.nodesource.com/node_0.12 jessie main
> deb [arch=armhf] http://repos.rcn-ee.com/debian/ jessie main
>
> Are there other well-known ARMHF repos that I can add if the package I'm
> looking for isn't there?
>

Well this is a problem. "well known" does not necessarily imply "secure".
All those listed above except for the nodesource, and RCN repo's are
official. Personally, I would not add the nodesource repo, but have no
qualms with Roberts repo.

>
> For example, I like to use "fish" as my shell.  When I try to install it,
> I get this:
>
> $ *sudo apt-get install fish*
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package fish is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'fish' has no installation candidate
>
> Yes, I could build it myself, but that defeats the entire purpose of
> having package management, automatic updates when security fixes are
> available, etc.
>

So build the package once, and use it multiple times. This is one reason
why I would not use the nodesource repo. I build my own Nodejs, from source
tarballs my self. Currently I have a Nodejs 4.6.2 *deb, that I install on
any system that needs it. Just a simple file transfer, and sudo dpkg -i
 away.

-- 
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/CALHSORrcAQ_tiMpWjq5Fcv-AM-69a6iQsXwayDOqL8t3%2B-ExjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Ubuntu on the Beagle

[William Hermans]

On Sun, Dec 18, 2016 at 5:05 AM, Elena ``of Valhalla'' <
elena.valha...@gmail.com> wrote:

>
> Other hardware that may be problematic of course is new hardware which
> requires a new kernel, and if you're not already using testing (as
> mentioned in the other email), usually there is always one in backports.
>

This has not been my experience. My experience has been that if your
drivers are not in stable, dont bother with testing, or sid. My last
experience with this was when I had a new Core 2 Duo( E6300 CPU) system
that would not work 100%. As I recall no matter what I did, the SATA
controller would not work. Which was because the chipset was not fully
recognized by Debian. With that said, the hardware at that time would not
work with any distro.

However, I'm of the opinion now days that you buy the hardware for your
software. e.g. You buy hardware you know that works good for your given OS.

There also comes the point that sure, maybe I've a lot of experience with
Debian, and can figure out most problem related to it. But often,
especially the older I get. I just want whatever it is I'm using to work.
So if I need a desktop, for a system that may serve as a personal system,
or a workstation. I may just opt for something that "just works" "out of
the box".

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

Re: [beagleboard] Re: Ubuntu on the Beagle

[William Hermans]

On Sun, Dec 18, 2016 at 2:40 AM, Elena ``of Valhalla'' <
elena.valha...@gmail.com> wrote:

> On 2016-12-15 at 14:49:25 -0700, William Hermans wrote:
> > Debian, and Ubuntu use different init daemons, at least the last I
> > read. Although I've also read that Canonical was seriously considering
> > switching to systemd, soon.
>
> Already happened, in 15.04
>

I figured as much, but did not bother to look.

>
> They still use their own custom desktop environment unity and they are
> still working on their own display server mir (which afaik they use in
> the phone version of Ubuntu)
>

I never used Unity. I have used Lubuntu(LXDE) 14,04, have it installed on
an old laptop in fact. I think it rivals the desktop of Windows, and is
very good for that sort of thing.

>
> Also, Debian uses systemd by default in the linux archs, but still
> supports sysV init and iirc openrc (altought the latter is probably used
> by just a handful of people). Using Upstart as in Ubuntu was available
> as another choice (and possibly still is), but since its developement
> has been stopped by upstream (Canonical) it's probably going to die away.
>
> So, there are several "Debian without systemd" websites out there that are
dedicated to instructing a user to remove systemd, and reinstall SysV. I've
personally done this in the past, but I think more people out there that
are old school probably do not want to deal with systemd - At least
initially. I do understand why, as it's a serious pain having to try and
figure something out, that you already know how to do another way. But
documentation now seems to be much better, and it's not too hard figuring
things out now. That's my take on it anyhow.

Anyway, I've been using Debian a lng time - Since the 90's. That and my
hands on experience with Ubuntu also goes back a long ways. Furthest back I
remember is 8.xx, but possibly further back. On a, or for a "desktop", now
days Ubuntu does not seem all that terrible. But I do recall the days where
you couldn't trust Ubuntu to do much of anything. Personally, I think for
the beaglebone,  Ubuntu is useless. Definitely, on the cmd line, it's not
easier to use than Debian. On an x86 Desktop *maybe*, but only because
there is a much better out of the box experience. Then stuff like LXDE +
Cairo was easy on 14.04, where it would turn into a hair pulling "festival"
attempting the same thing on Debian.

I'm of the opinion however, if you're running X on Debian . . .well then
you're doing it wrong, or you're using the wrong distro. Simply, because
there are other more "cutting edge" distro's out there that will have a
much better desktop experience. Ubuntu is one, and Sabayon( Gentoo based )
is another. Others yet, seem to like LMDE( Mint ) . . . and I know a few
who think that Kali is something to be used as a desktop . . .heh.

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

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] 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?

[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 <doobi...@gmail.com> 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 <yyr...@gmail.com>
>> 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 <doob...@gmail.com> 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

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 <yyrk...@gmail.com> 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 <doobi...@gmail.com> 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
>> <https://groups.google.com/d/msgid/beagleboard/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrA1HUCuchZryO-aMdH9RfwfhzrTUbtg4%3D%3DATWaD-CQUw%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.

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

[William Hermans]

On Thu, Dec 15, 2016 at 8:40 PM, Jay Doobie  wrote:

> Sadly this did not work.  I'm using the default kernel/setup from the
> image bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz
> .
> It uses kernel 4.4.30-ti-r64. Is there something better to start with?  I'd
> like something newer than the 2012 build I previously had.
>

If that did not work, then you're doing something wrong, or you missed a
step. But you can not just do what Greg suggested and have it work. You
need to make sure you either replace the exact board file you load at boot,
or change the board file that loads at boot.

Anyway, I know what Greg suggest works, because I was the first person on
the list to test the changes, on the list. Once Robert posted to the list
about these changes. In fact, if you search my username on this google
group, with the additional keyword "uio_pruss", it probably won't take you
long to find the exact steps post I made.

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

Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW

[William Hermans]

By the way . . .

Yes, I can read the dts files fairly easily. The problem is knowing which
> overlays are included for a given device.
>

Everything in /lib/firmware/


On Thu, Dec 15, 2016 at 6:18 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Thu, Dec 15, 2016 at 3:06 PM, codemonkey <tea...@burfl.com> wrote:
>
>> Your intuition seems to be very good. After much testing, I now can see
>> that as soon as I enable "dtb=am335x-boneblack-emmc-overlay.dtb" and
>> reboot, the system does come up but wlan0 is no longer known. By that I
>> mean that "ifconfig -a" and "connmanctl technologies" both fail to list it.
>> The odd thing is that having setup wlan0 with connmanctl, it does come up
>> and run and I can login (although it may quit after awhile).
>>
>> Yes, I can read the dts files fairly easily. The problem is knowing which
>> overlays are included for a given device.
>>
>> Between the problems mentioned above and the failures that I'm seeing
>> trying to use config-pin to setup the gpios, I guess I'm wondering if there
>> is anyone who is actively working on getting the BBGW DT running. This is
>> supposed to be a simple port of an existing application to the BBGW because
>> we don't need hdmi and would like to add wifi. Of course, the desire is to
>> reduce cost as well.
>>
>> If there is anyone working on the DT issues for the BBGW, I would
>> appreciate a note. If I don't hear soon, I will simply recommend that we
>> move to the BBBW instead.
>>
>
> My understanding that the two boards, BBGW and BBBW both use the same
> wireless radio. I have not looked into that personally, because I do not
> own either one. But assuming that were fact, I'd probably try using the
> BBBW wireless board overlay. Because I do have hands on using the same
> overlay you mentioned in your first post, on several beaglebone greens. The
> reason why it works, is that the beaglebone green has no HDMI framer, and
> that overlay disables HDMI video, and audio.
>
> So I'd probably try to compile the BBBW overlay https://github.com/
> RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-
> boneblack-wireless-emmc-overlay.dts and see if it worked.
>
> You'd need git installed, then just git clone that whole repo( not just
> that one file ), then . . .
>
> cd into the working directory
> make
> make install
>
> To test it. If I had a BBGW wireless I'd test it myself before hand. But I
> don't . . . Also keep in mind that I'm not 100% sure that overlay won't
> damage your board, but I really do not see how it could . . . which is why
> I'd dive right in myself if I had the hardware in hand.
>

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

Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW

[William Hermans]

On Thu, Dec 15, 2016 at 3:06 PM, codemonkey  wrote:

> Your intuition seems to be very good. After much testing, I now can see
> that as soon as I enable "dtb=am335x-boneblack-emmc-overlay.dtb" and
> reboot, the system does come up but wlan0 is no longer known. By that I
> mean that "ifconfig -a" and "connmanctl technologies" both fail to list it.
> The odd thing is that having setup wlan0 with connmanctl, it does come up
> and run and I can login (although it may quit after awhile).
>
> Yes, I can read the dts files fairly easily. The problem is knowing which
> overlays are included for a given device.
>
> Between the problems mentioned above and the failures that I'm seeing
> trying to use config-pin to setup the gpios, I guess I'm wondering if there
> is anyone who is actively working on getting the BBGW DT running. This is
> supposed to be a simple port of an existing application to the BBGW because
> we don't need hdmi and would like to add wifi. Of course, the desire is to
> reduce cost as well.
>
> If there is anyone working on the DT issues for the BBGW, I would
> appreciate a note. If I don't hear soon, I will simply recommend that we
> move to the BBBW instead.
>

My understanding that the two boards, BBGW and BBBW both use the same
wireless radio. I have not looked into that personally, because I do not
own either one. But assuming that were fact, I'd probably try using the
BBBW wireless board overlay. Because I do have hands on using the same
overlay you mentioned in your first post, on several beaglebone greens. The
reason why it works, is that the beaglebone green has no HDMI framer, and
that overlay disables HDMI video, and audio.

So I'd probably try to compile the BBBW overlay
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-wireless-emmc-overlay.dts
and see if it worked.

You'd need git installed, then just git clone that whole repo( not just
that one file ), then . . .

cd into the working directory
make
make install

To test it. If I had a BBGW wireless I'd test it myself before hand. But I
don't . . . Also keep in mind that I'm not 100% sure that overlay won't
damage your board, but I really do not see how it could . . . which is why
I'd dive right in myself if I had the hardware in hand.

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

Re: [beagleboard] Overlay does not create SPI pingroups with 4.4.21 kernel

[William Hermans]

If you load overlays that are already included in your image, then you do
not have to update the initramfs. But if you create your own custom
overlay, it will not be included in the initramfs.

On Thu, Dec 15, 2016 at 4:10 PM, Phil  wrote:

> Thanks for the info. I am not so sure about the need to update initramfs
> though. Just for yuks, I specified my custom overlay in uEnv.txt, and it
> seems to have loaded properly, which I confirmed by inspecting the output
> of dmesg. I am still verifying that my SPI ports work as expected (phase
> and polarity, mostly), but it seems to be working.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/cbf34cf0-aa12-471f-afc5-375008b3e5bc%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/CALHSORq6pAb2kAkB_ORwsSNd%2BOETpduWuQEHXXC8cx0TkXmN-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Ubuntu on the Beagle

[William Hermans]

>From a practical perspective. Ubuntu has support for packages that Debian
may not have in the stable release. Both Debian, and Ubuntu use APT as a
package repository manager. But they have different repositories.

Canonical tends to support more cutting edge technologies in their
software, were the Debian team tends to opt out of the latest greatest
software for system stability. In both cases, it shows.

Debian is a go to Distro when you need something to be rock solid reliable.
A more "no frills" approach. This however does not mean Debian is not
useful. Quite the contrary, Debian is thought of as the go to Distro for
many server applications. Some even prefer to use it as their desktop OS.

Ubuntu is a go to Distro for systems that may be running newer( current )
hardware, that may not be supported  by another distros out of the box.
Ubuntu is also good for desktop like situations. Where someone may want an
OS that "just works", and looks good, with desktop hardware acceleration.

In the past, Ubuntu had been known as very flaky. e.g. in many cases Ubuntu
was not very reliable. Now days, perhaps that has changed *some*.  Debian,
and Ubuntu use different init daemons, at least the last I read. Although
I've also read that Canonical was seriously considering switching to
systemd, soon.

Anyway, Ubuntu is based off Debian. So you can think of Ubuntu as Debian
with different features that may not have been put through the rigorous
Debian testing cycle. Which by the way is why Debian is behind the curve
for software, and hardware support. If something does not "make the grade"
within a certain time frame, then that something does not make it into the
next stable release of the distro. Which many, many people prefer.



On Thu, Dec 15, 2016 at 12:52 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Thu, Dec 15, 2016 at 3:02 AM, Heinz Hummel <heinz.humme...@gmail.com>
> wrote:
>
>> I don't know what the reason is but I personally prefer Ubuntu because it
>> is easier to use, it has a bigger community which is more responsive and
>> more friendly and one can choose to use a LTS version (and stay with older
>> software) or a normal version (and get newer software). Debian seems to be
>> LLLTS only...
>>
>>
> The above is 100% FUD. Ubuntu is not easier to use, it's even based on
> Debian, and the community is not larger.
>
> The difference is Ubuntu is developed by an organization whose goals are
> different than those of the Debian team. Ubuntu is more geared towards the
> desktop experience, which it does very well. Where Debian is geared towards
> reliability. Which it also does very well.
>

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

Re: [beagleboard] Overlay does not create SPI pingroups with 4.4.21 kernel

[William Hermans]

On Thu, Dec 15, 2016 at 12:36 PM, Phil  wrote:

> On Thursday, December 15, 2016 at 11:20:13 AM UTC-6, Phil wrote:
>
I have written a device tree overlay that incorporates SPI0, SPI1 and the
> PRUSS, and where SPI1 uses a GPIO for a 2nd chip select. Can I load this in
> the same manner via the kernel parameter in /boot/uEnv.txt? If this isn't
> the right way, then what is?
>

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.

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

Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW

[William Hermans]

On Thu, Dec 15, 2016 at 12:03 PM, codemonkey  wrote:

> Hello William, thank you for the prompt response. First of all, I have to
> say that I have very little experience with the device tree, although I did
> use dtb-rebuilder to enable SPI back in the linux v3.8 days. So, my first
> request is: please point me to documentation that is current and helpful
> for dealing with the device tree.
>

I learned by doing. But there are several docs on the web covering it.
Personally I found the documentation on the web counter intuitive though. I
felt it was holding me back. So one day I just dove in, and everything
started making sense. Granted at that point I had 3+ years hands on with
the hardware. A little here, and there.

If you've been programming for any amount of time, reading through an
overlay while you may not know specific details, should make sense. In
fact, if you toss a device tree file into an editor with syntax
highlighting, and select C as the language. You get syntax highlighting too
;)

Anyway, there is a document by Panto, and Tom King in PDF format called
something like " kernel 3.8 and device tree". Should come up in the top of
a google search list. IN fact:
http://elinux.org/BeagleBone_and_the_3.8_Kernel

Just keep in mind that there would be some differences for the newer
kernels . . . but the gist should be nearly the same.

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

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

[William Hermans]

There's also a software package known as fake hwclock. It's not a real time
clock, and perhaps it'll even lose time over long periods. But it seems to
do a reasonable job of keeping time on a system close.

We actually use  DS3232 on those devices that *need* to keep accurate time.

On Thu, Dec 15, 2016 at 10:15 AM, 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..
>
> 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/CAOCHtYgeFJMvE6EZkMVCx%2Bw8ZrZ9G1%3DOimRJnuw-
> Qcy5YE8DYQ%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/CALHSORpX9pO70Xy0LuW682xiX4vudNM8Wxqeb6UN%3DgEdH760pw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Ubuntu on the Beagle

[William Hermans]

On Thu, Dec 15, 2016 at 3:02 AM, Heinz Hummel 
wrote:

> I don't know what the reason is but I personally prefer Ubuntu because it
> is easier to use, it has a bigger community which is more responsive and
> more friendly and one can choose to use a LTS version (and stay with older
> software) or a normal version (and get newer software). Debian seems to be
> LLLTS only...
>
>
The above is 100% FUD. Ubuntu is not easier to use, it's even based on
Debian, and the community is not larger.

The difference is Ubuntu is developed by an organization whose goals are
different than those of the Debian team. Ubuntu is more geared towards the
desktop experience, which it does very well. Where Debian is geared towards
reliability. Which it also does very well.

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

Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW

[William Hermans]

Additionally, this is a reason for you to buy a serial debug cable, or
module. With such a device, you'd probably know exactly why the board fails
to boot, or at minimum have a really good idea based on uboot output.

On Wed, Dec 14, 2016 at 5:18 PM, William Hermans <yyrk...@gmail.com> wrote:

> That cape does work on the Beaglebone green. However, the Beaglebone
> green, and Beaglebone black both have ethernet, where the Beaglebone green
> wireless has a wifi network interface. So, this is an assumption but here
> are two points of contention:
>
>
>1. Since the BBGW has wifi and the Beaglebone black has ethernet it
>could be failing because of a networking interface conflict.
>2. Since all Beaglebone have an EEPROM that when flashed properly hold
>a board identification string" The board file you've chosen may fail to
>load at boot.
>
> So, if you look here: https://github.com/RobertCNelson/dtb-rebuilder/
> blob/4.4-ti/src/arm/am335x-boneblack-emmc-overlay.dts#L36 then compare it
> to this:  https://github.com/RobertCNelson/dtb-rebuilder/
> blob/4.4-ti/src/arm/am335x-bonegreen-wireless.dts#L36 You'll note the
> difference. However I'm not convinced that is the problem. I'm thinking the
> problem probably lies here:  https://github.com/
> RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-
> bonegreen-wireless.dts#L12 As f you note in the BBB equivalent file here:
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-
> boneblack-emmc-overlay.dts#L10-L13 there is no listing for the wireless
> hardware module as an include file.
>
> With that said, it's going to be more complicated than that. As the files
> for the BBB will probably not have the proper network interface
> configuration for the wireless interface: ethernet versus wireless. So I'm
> fairly sure just adding the #include would not work. However . . . it may
> be possible that https://github.com/RobertCNelson/dtb-rebuilder/
> blob/4.4-ti/src/arm/am335x-boneblack-wireless-emmc-overlay.dts would
> work. I'd double check with Robert first however. To make sure nothing bad
> would happen. I wouldn't think so, but thats what I *think*, and not what I
> *know* as fact.
>
> On Wed, Dec 14, 2016 at 4:52 PM, codemonkey <tea...@burfl.com> wrote:
>
>> When I uncomment "#dtb=am335x-boneblack-emmc-overlay.dtb" and add a line
>> for BB-SPIDEV1 as follows:
>>
>> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>>
>> uname_r=4.4.38-bone-rt-r14
>> ###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
>> cape_enable=bone_capemgr.enable_partno=BB-SPIDEV1
>>
>> ... (nothing is changed beyond this point)
>>
>>
>> The system appears to fail during boot. This has worked for a long time
>> on the BBB and I'm trying to move a running application to the BBGW.
>>
>> root@bbgw:/home/cd5# uname -a
>> Linux bbgw 4.4.38-bone-rt-r14 #1 PREEMPT RT Mon Dec 12 10:10:25 UTC 2016
>> armv7l GNU/Linux
>>
>> I have also tried to use config-pin, but I haven't been able to find any
>> documentation that will allow me to work through the problems.
>> For example:
>>
>> cd5@bbgw:~$ sudo ./config-pin P8_18 low
>> P8_18 pinmux file not found!
>> cape-universala overlay not found
>> run "config-pin overlay cape-universala" to load the cape
>> root@bbgw:/home/cd5# ./config-pin overlay cape-universala
>> Loading cape-universala overlay
>> root@bbgw:/home/cd5# ./config-pin overlay BB-SPIDEV1
>> Loading BB-SPIDEV1 overlay
>> bash: line 0: echo: write error: File exists
>> Error loading device tree overlay file: BB-SPIDEV1
>>
>> It appears that cape-universala loads both spidev0 and spidev1 - I need
>> the spidev0 pins available for gpio
>>
>> Trying to push on:
>>
>> root@bbgw:/home/cd5# ./config-pin -l p8_18
>> default gpio gpio_pu gpio_pd
>> root@bbgw:/home/cd5# ./config-pin -i p8_18
>> Pin name: P8_18
>> Function if no cape loaded: gpio
>> Function if cape loaded: default gpio gpio_pu gpio_pd
>> Function information: gpio2_1 default gpio2_1 gpio2_1 gpio2_1
>> Cape: cape-universala cape-universal cape-universaln
>> Kernel GPIO id: 65
>> PRU GPIO id: 97
>> root@bbgw:/home/cd5# ./config-pin -q p8_18
>> Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P8_18_pinmux/state
>>
>> I can't see where to go from here except to post this hoping that someone
>> can help with either the uEnv.txt problem 

Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW

[William Hermans]

That cape does work on the Beaglebone green. However, the Beaglebone green,
and Beaglebone black both have ethernet, where the Beaglebone green
wireless has a wifi network interface. So, this is an assumption but here
are two points of contention:


   1. Since the BBGW has wifi and the Beaglebone black has ethernet it
   could be failing because of a networking interface conflict.
   2. Since all Beaglebone have an EEPROM that when flashed properly hold a
   board identification string" The board file you've chosen may fail to load
   at boot.

So, if you look here:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-emmc-overlay.dts#L36
then compare it to this:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-bonegreen-wireless.dts#L36
You'll note the difference. However I'm not convinced that is the problem.
I'm thinking the problem probably lies here:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-bonegreen-wireless.dts#L12
As f you note in the BBB equivalent file here:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-emmc-overlay.dts#L10-L13
there is no listing for the wireless hardware module as an include file.

With that said, it's going to be more complicated than that. As the files
for the BBB will probably not have the proper network interface
configuration for the wireless interface: ethernet versus wireless. So I'm
fairly sure just adding the #include would not work. However . . . it may
be possible that
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-wireless-emmc-overlay.dts
would work. I'd double check with Robert first however. To make sure
nothing bad would happen. I wouldn't think so, but thats what I *think*,
and not what I *know* as fact.

On Wed, Dec 14, 2016 at 4:52 PM, codemonkey  wrote:

> When I uncomment "#dtb=am335x-boneblack-emmc-overlay.dtb" and add a line
> for BB-SPIDEV1 as follows:
>
> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>
> uname_r=4.4.38-bone-rt-r14
> ###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
> cape_enable=bone_capemgr.enable_partno=BB-SPIDEV1
>
> ... (nothing is changed beyond this point)
>
>
> The system appears to fail during boot. This has worked for a long time on
> the BBB and I'm trying to move a running application to the BBGW.
>
> root@bbgw:/home/cd5# uname -a
> Linux bbgw 4.4.38-bone-rt-r14 #1 PREEMPT RT Mon Dec 12 10:10:25 UTC 2016
> armv7l GNU/Linux
>
> I have also tried to use config-pin, but I haven't been able to find any
> documentation that will allow me to work through the problems.
> For example:
>
> cd5@bbgw:~$ sudo ./config-pin P8_18 low
> P8_18 pinmux file not found!
> cape-universala overlay not found
> run "config-pin overlay cape-universala" to load the cape
> root@bbgw:/home/cd5# ./config-pin overlay cape-universala
> Loading cape-universala overlay
> root@bbgw:/home/cd5# ./config-pin overlay BB-SPIDEV1
> Loading BB-SPIDEV1 overlay
> bash: line 0: echo: write error: File exists
> Error loading device tree overlay file: BB-SPIDEV1
>
> It appears that cape-universala loads both spidev0 and spidev1 - I need
> the spidev0 pins available for gpio
>
> Trying to push on:
>
> root@bbgw:/home/cd5# ./config-pin -l p8_18
> default gpio gpio_pu gpio_pd
> root@bbgw:/home/cd5# ./config-pin -i p8_18
> Pin name: P8_18
> Function if no cape loaded: gpio
> Function if cape loaded: default gpio gpio_pu gpio_pd
> Function information: gpio2_1 default gpio2_1 gpio2_1 gpio2_1
> Cape: cape-universala cape-universal cape-universaln
> Kernel GPIO id: 65
> PRU GPIO id: 97
> root@bbgw:/home/cd5# ./config-pin -q p8_18
> Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P8_18_pinmux/state
>
> I can't see where to go from here except to post this hoping that someone
> can help with either the uEnv.txt problem or the config-pin problems.
>
> When all is configured properly I should have spidev1 (the second spi bus)
> enabled along with a long list of gpios needed for the application.
>
> Thanks in advance,
> Tim
>
>
>
>
> --
> 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/1546c704-46ee-41b3-8f01-ec0dbafcada6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You 

Re: [beagleboard] Difference between images available at https://rcn-ee.com/rootfs/bb.org/testing/2016-12-12/iot/

[William Hermans]

IF you're using Windows, this is most likely a Windows issue. The thing
I've found in the past when dealing with the USB g_ether gadget driver. Is
that when upgrading from one image to another on the Beaglebone you may
have to upgrade the driver on the Windows host side. This is one place
where Windows definitely falls on it's face - Dealing with drivers of this
type. Which it seems that Windows is just "lazy" and would rather keep an
older driver, and fail than double check to make sure it's using the
correct driver, and work.

There are a few things to check, which may help.

Run Windows update.
Search the internet for the best way of completely removing drivers for
your version of Windows.
Make sure the device is configured properly under windows network
interfaces.
Make sure g_ether( possibly g_multi ) is actually running and configured
properly on the beaglebone.

When dealing with Windows, sometimes there there may be no particular rhyme
or reason to why things are not working. When it comes to drivers of this
sort, Windows has a really bad tendency to loose it's brain.Not just for
this external hardware, or even this type of hardware. COM ports will start
behaving like this as well, if a system is not properly and manually
maintained. I've found that completely uninstalling the drivers, making
sure no old instances of these driver are still installed, before
attempting to reinstall them works the best. But the steps between Windows
version can vary, and require a lot of time to perform. You have to be
meticulous. Sometimes booting into safe mode, removing the drivers,
removing all old instances of similar drivers. Then once completely clean,
start over from scratch. Then if the driver still does not work, you may
have to run Windows update to "complete the deal".

As for the images, the LXDE or similar images are going to have X, and LXDE
etc on them. Then the console images are going to be fairly minimal, with
minimal tools installed for connectivity( ssh server, etc ). The IoT
images, whcih I've not used at all myself. As I understand it are similar
to the console images, but with Nodejs, NodeRED, etc, pre installed, and
working properly.



On Wed, Dec 14, 2016 at 12:24 PM, Gregg Harrington <
gr...@greggharrington.com> wrote:

>
> Hello,
>
> I have seen several images at https://rcn-ee.com/rootfs/bb.
> org/testing/2016-12-12/iot/ and I am wondering which one is best. I see
> the BBBL and BBB versions. Is one of these geared toward wireless? I have
> been downloading the BBB one but having issues with my BBBWL after flashing
> it. I can't get the USB -> ethernet bridge to work (which worked fine when
> I received the board).
>
> Cheers,
>
> 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/1d028e37-fcac-4d9d-9ccb-69a106c6a32f%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/CALHSORok3%2BJ5BfcLdGMDChPebnJnU1JZLjzneVBir666MBKc-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Loading PRU overlay causes BBB to lock

[William Hermans]

You should not have to upgrade the device tree compiler( dtc ). As each
kernel version, as provided with the latest images have the proper device
tree compiler. However, assuming, running Wheezy, then upgrading to a newer
kernel( 3.8.x to 4.x ) the device tree compiler would have to be upgraded
at this time. But it is also worth nothing that it's not only easier, but
better to just download and burn a new image at this time. As there can be
multiple problems when upgrading from a 3.8.x kernel, to 4.x on older
Wheezy images.

On Wed, Dec 14, 2016 at 11:33 AM, TJF  wrote:

> @Greg:
>
> Sorry, I didn't answer your question.
>
> Am Mittwoch, 14. Dezember 2016 19:14:34 UTC+1 schrieb Greg:
>>
>> TJF, so what is the best way to update the dtc?
>>
> ...
>>
> An apt-get install ...?
>>
>
> sudo apt-get install device-tree-compiler
>
>  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/fc982f79-df4b-437f-9950-504360f54c5a%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/CALHSORpxmzPmmwccTvZ%3D7YCrB%2BbkuYKVLQwtJ%3Ddx6JEpR0eZfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Cape for picamera

[William Hermans]

The Logitech 920C I believe it is is reported to work very well with the
Beaglebone.

On Tue, Dec 13, 2016 at 10:37 AM, Andrew Goh  wrote:

> On Sunday, July 14, 2013 at 7:08:45 PM UTC+8, James Richins wrote:
>>
>> Is it possible for there to be an interface board for the picamera. It is
>> significantly cheaper than the current camera cape and has a higher
>> megapixel resolution.
>>
>> I don't know what kind of speeds you get compared to a USB camera.
>>
>
>  bouncing an old thread but unfortunately i've not found a solution
> either, recently got a 5mp picamera OV5647 from ebay
> the camera is apparently pretty performant and high quality, videos from
> the web
> https://www.youtube.com/watch?v=OYcsRjgQ48A
> https://www.youtube.com/watch?v=hpU6oAQoTSg
> https://www.youtube.com/watch?v=qXEaJR4nMZU
>
> but that'd require the use of the mipi csi-2 interface
> there are also 8mp versions out there
>
> decided to do it the *brute force* way, get an rpi 3 model b (important
> thing is to check for the csi camera connector)
> rpi is apparently the 'better platform' for media streaming due to its use
> of closed sourced mipi csi & dsi interfaces
> however rpi lacks the open sourced flare of beagleboards and in a way
> beaglebone black is more versatile for 'arduino' style interfacing projects
> due to its open source nature, its connector design & that the linux kernel
> is very much designed 'around' the beagle bone black with things like
> device overlays that's pioneered on the beaglebone black
>
> --
> 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/2be28c85-7af1-45b6-ad2d-64500c9ea6ef%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/CALHSORqsTChi%3DTTK8ooxYnhHjyzFUi%3DcxwpSYV8ECSubB_TsxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BUS ERROR modprobe uio_pruss extram_pool_sz=0x800000

[William Hermans]

01101=0x05
> 0x190 0x05  // P9_31 pr1_pru0_pru_r30_0, MODE5 |
> OUTPUT | PRU 1101=0x05
>
>
> >;
> };
>
> };
> };
>
> //Allowed us to have the differents uio
> fragment@1{
> target = <>;
> __overlay__{
> status = "okay";
> pinctrl-names = "default";
> };
> };
>
>  //Make the uio working
> fragment@2 {
> target = <>;
> __overlay__ {
> #address-cells = <1>;
> #size-cells = <1>;
>
> gpio_keys {
> compatible = "gpio-keys";
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> #address-cells = <1>;
> #size-cells = <0>;
> };
>
> };
> };
>
>
> };
>
>
>
> Le lundi 12 décembre 2016 20:05:05 UTC+1, William Hermans a écrit :
>>
>> I suspect that you need to make these changes in the overlay file you use
>> to initially configure the PRU's.
>>
>> On Mon, Dec 12, 2016 at 9:39 AM, TJF <jeli.f...@gmail.com> wrote:
>>
>>> Hi malkowki!
>>>
>>> Sorry, I cannot really help. Just some info: The same commands work well
>>> for me on several kernel versions (3.8, 4.1 and 4.4, but no rt). I use them
>>> often and I always get the first two messages
>>>
>>> Am Montag, 12. Dezember 2016 10:32:31 UTC+1 schrieb malkowki:
>>>>
>>>> [  749.642962] pruss_uio 4a30.pruss: Unbalanced pm_runtime_enable!
>>>> [  749.643073] pruss_uio 4a30.pruss: pins are not configured from
>>>> the driver
>>>>
>>>
>>> But I never got the fault message
>>>
>>>
>>>> [  763.164615] Unhandled fault: external abort on non-linefetch (0x1018
>>>> ) at 0xb6e33000
>>>> [  763.172351] pgd = ddde8000
>>>> [  763.175081] [b6e33000] *pgd=9c27e831, *pte=4a304303, *ppte=4a304a33
>>>>
>>>
>>> I wonder why the fault comes with some delay (> 5 s).
>>>
>>> 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/7db92f8b-21cd-4193-9569-f24c62f2080f%40googlegroups.com
>>> <https://groups.google.com/d/msgid/beagleboard/7db92f8b-21cd-4193-9569-f24c62f2080f%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/c20b8356-cebb-4b23-bb8c-20c352e76fba%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/c20b8356-cebb-4b23-bb8c-20c352e76fba%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Which way BBBW or BBGW

[William Hermans]

I think the SiP on the beaglebone black wireless is really cool, but it
also seems to add cost. For board designers the SiP is a god send, for many
reasons. But in cases like this where it adds additional costs to an "end
product" . . . yeah.

Hopefully, once the sales of the SiP increase over time. The cost will come
down.

On Mon, Dec 12, 2016 at 12:39 PM, Ross Morrison <r...@buy-ei.com> wrote:

> On Mon, 12 Dec 2016 12:29:37 -0700
> William Hermans <yyrk...@gmail.com> wrote:
>
> > The beaglebone black wireless seems to have HDMI, where the beaglebone
> > green's do not.
> >
> > On Mon, Dec 12, 2016 at 12:14 PM, Ross Morrison <r...@buy-ei.com>
> > wrote:
> >
> > > Now that the BBBW is out (in stock), my question is: Which one, the
> > > BBBW or the BBGW board for a project? This project will be small
> > > volume this year (under 15), but could grow to 25 - 50 annually.
> > > Yes, the obvious differences are the number of on board USB ports
> > > and the removal of the power jack from the BBGW (both a non-issue
> > > for me). The other obvious difference is the price, $20 difference
> > > here in the USA (that is a big difference). I'm just trying to get
> > > a good gut check on which way to go. I've been working the both the
> > > BBG and BBGW and have had no problems. Why should one spend the
> > > extra money for the BBBW? Are Octavo and GHI going to be around
> > > awhile and yes, Seeed Studios could go away tomorrow (I understand
> > > that). Are there any real technical differences between the two, ie
> > > performance, heat dissipation, noise immunity, noise radiation?
> > > They both seem to have the same wireless TI part, so no differences
> > > there???
> > >
> > > Anyway, thanks for listening. If possible any feedback would be
> > > greatly appreciated.
> > >
> > > --
> > > Ross Morrison
> > >
> > > --
> > > 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/20161212111410.75b6dd6e%40kubuntu-14-04. For more
> > > options, visit https://groups.google.com/d/optout.
> > >
> >
>
> Forgot to mention that one (HDMI), another don't need for my project.
> So, it does seem to be a self answering question, go with the BBGW. I
> just want to make sure that is the best decision, considering all known
> factors (pricing, availability, longevity, reliability, compatibility,
> support, other user's experiences).
>
> Thanks again,
> --
> Ross Morrison
>
> --
> 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/20161212113916.51b427ee%40kubuntu-14-04.
> 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/CALHSORqxSmAykzC6TGSz8p84p3tJpW-L9ThFK8BdSNKjiCxsXQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Which way BBBW or BBGW

[William Hermans]

Well, that, and the beaglebone black wireless also does not have the two
grove connectors. Which personally I found no use for.

On Mon, Dec 12, 2016 at 12:29 PM, William Hermans <yyrk...@gmail.com> wrote:

> The beaglebone black wireless seems to have HDMI, where the beaglebone
> green's do not.
>
> On Mon, Dec 12, 2016 at 12:14 PM, Ross Morrison <r...@buy-ei.com> wrote:
>
>> Now that the BBBW is out (in stock), my question is: Which one, the BBBW
>> or the BBGW board for a project? This project will be small volume
>> this year (under 15), but could grow to 25 - 50 annually. Yes, the
>> obvious differences are the number of on board USB ports and the
>> removal of the power jack from the BBGW (both a non-issue for me). The
>> other obvious difference is the price, $20 difference here in the USA
>> (that is a big difference). I'm just trying to get a good gut check on
>> which way to go. I've been working the both the BBG and BBGW and have
>> had no problems. Why should one spend the extra money for the BBBW? Are
>> Octavo and GHI going to be around awhile and yes, Seeed Studios could
>> go away tomorrow (I understand that). Are there any real technical
>> differences between the two, ie performance, heat dissipation, noise
>> immunity, noise radiation? They both seem to have the same wireless
>> TI part, so no differences there???
>>
>> Anyway, thanks for listening. If possible any feedback would be greatly
>> appreciated.
>>
>> --
>> Ross Morrison
>>
>> --
>> 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/20161212111410.75b6dd6e%40kubuntu-14-04.
>> 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/CALHSORrCCT67NXqb6Z74QhVqbZvRg1jEg9KPCxHFv9kMRCMqOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Which way BBBW or BBGW

[William Hermans]

The beaglebone black wireless seems to have HDMI, where the beaglebone
green's do not.

On Mon, Dec 12, 2016 at 12:14 PM, Ross Morrison  wrote:

> Now that the BBBW is out (in stock), my question is: Which one, the BBBW
> or the BBGW board for a project? This project will be small volume
> this year (under 15), but could grow to 25 - 50 annually. Yes, the
> obvious differences are the number of on board USB ports and the
> removal of the power jack from the BBGW (both a non-issue for me). The
> other obvious difference is the price, $20 difference here in the USA
> (that is a big difference). I'm just trying to get a good gut check on
> which way to go. I've been working the both the BBG and BBGW and have
> had no problems. Why should one spend the extra money for the BBBW? Are
> Octavo and GHI going to be around awhile and yes, Seeed Studios could
> go away tomorrow (I understand that). Are there any real technical
> differences between the two, ie performance, heat dissipation, noise
> immunity, noise radiation? They both seem to have the same wireless
> TI part, so no differences there???
>
> Anyway, thanks for listening. If possible any feedback would be greatly
> appreciated.
>
> --
> Ross Morrison
>
> --
> 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/20161212111410.75b6dd6e%40kubuntu-14-04.
> 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/CALHSORrb%3DELPYc5waPscVHryZSAX6C9x8r6GtVLR8t%3DqmLBaOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BUS ERROR modprobe uio_pruss extram_pool_sz=0x800000

[William Hermans]

I suspect that you need to make these changes in the overlay file you use
to initially configure the PRU's.

On Mon, Dec 12, 2016 at 9:39 AM, TJF  wrote:

> Hi malkowki!
>
> Sorry, I cannot really help. Just some info: The same commands work well
> for me on several kernel versions (3.8, 4.1 and 4.4, but no rt). I use them
> often and I always get the first two messages
>
> Am Montag, 12. Dezember 2016 10:32:31 UTC+1 schrieb malkowki:
>>
>> [  749.642962] pruss_uio 4a30.pruss: Unbalanced pm_runtime_enable!
>> [  749.643073] pruss_uio 4a30.pruss: pins are not configured from
>> the driver
>>
>
> But I never got the fault message
>
>
>> [  763.164615] Unhandled fault: external abort on non-linefetch (0x1018)
>> at 0xb6e33000
>> [  763.172351] pgd = ddde8000
>> [  763.175081] [b6e33000] *pgd=9c27e831, *pte=4a304303, *ppte=4a304a33
>>
>
> I wonder why the fault comes with some delay (> 5 s).
>
> 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/7db92f8b-21cd-4193-9569-f24c62f2080f%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/CALHSORr4reEq1anHBzoeJKwegLxsDTGTDo%2BkZnVd%3DwePtmymrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ony one parition on boot.

[William Hermans]

I use a combination of an NFS share, and a samba share. So . . .

Linux server == NFS share to BBB, and Samba share to Windows workstation.

What this nets me is the ability to edit files from Windows directly on the
BBB. Or more correctly on the Linux server, which also hosts a share to the
BBB.

On Thu, Dec 8, 2016 at 8:18 AM, Robert Nelson 
wrote:

> On Thu, Dec 8, 2016 at 8:33 AM, DragosP  wrote:
> > So on the new installed version, how can you tell me how to access a
> > partition, from BBB on Windows 7, with write permissions?
>
> Well on the new version it's a raw read-only *.img file...
>
> I guess the better question, what do you want to do?
>
> If you just want to transfer files over from windows, use the free version
> of:
>
> https://www.bitvise.com/ssh-client
>
> 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/CAOCHtYiYRxu%3Dgg%3DpmiXfBSADn25u73Zx-V_
> XiFFAPqOcpqGngg%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/CALHSORosbJ7JyuXdYmUbZE82Tv0uipTjRFyj-hJGD9-tUvZhqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Ony one parition on boot.

[William Hermans]

There is no FAT partition in the images since . . . over a year now.

On Thu, Dec 8, 2016 at 4:56 AM, DragosP  wrote:

>
> Hi,
>
> I run Debin beaglebone 4.4.36-ti-r72 on Beaglebone Black Rev C.
>
> I want to mount the FAT partition I see in Windows, to /media/folder_name
> in BBB.
>
> Sending "lsblk" command will return:
>
> mmcblk1boot0 179:804M  1 disk
> mmcblk1boot1 179:16   04M  1 disk
> mmcblk1  179:00  3.6G  0 disk
> `-mmcblk1p1  179:10  3.6G  0 part /
>
> So I don't see anything about the FAT partition.
>
> Can you please tell me what I have to do to access FAT partition from 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/9f3bd700-89e4-491f-917e-1941fb07e713%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/CALHSORq_PxrWP-_djBrH0in%3Doayvmg9Uga_sTY7RosEoybHgnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU UART Debian 8.6

[William Hermans]

Anyway, sorry if that "stings" but hey, it's pretty much the truth. People
have lives of their own and contribute what they can, when they can. But I
would assume most people are pretty busy doing stuff for people who
actually pay them. A lot of the time.

On Tue, Dec 6, 2016 at 10:10 PM, William Hermans <yyrk...@gmail.com> wrote:

> Did you expect someone to do all the work for you ? But yes, I've
> experienced the same thing. So "free" as in beer, open sourced software.
> You get what you pay for. If you need something more, then it's up to you
> to do that for yourself. Or pay someone else to do it for you.
>
> On Tue, Dec 6, 2016 at 3:42 AM, <pidders...@gmail.com> wrote:
>
>> Hi,  I have found setting the pru uart pins P9_17 and P9_18 to mode 5
>> does not work using config-pins with the latest release Debian 8.6.
>> The overlays I used in Debian 7.9 no longer work.  I have found that the
>> overlay used to disable the hdmi, univ-emmc-00A0.dtbo does
>> not include the pru_uart option for P9_17 and P9_18, whereas
>> cape-universal does.  So I copied the entries for P9-17 & -18 over to
>> univ-emmc, recompiled and copied to /lib/firmware which seems to solve
>> the problem.  Has anyone else had a similar experience?
>>
>> --
>> 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/37fbdce6-2cca-4fc1-9a9e-8cde0dce505c%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/37fbdce6-2cca-4fc1-9a9e-8cde0dce505c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [beagleboard] PRU UART Debian 8.6

[William Hermans]

Did you expect someone to do all the work for you ? But yes, I've
experienced the same thing. So "free" as in beer, open sourced software.
You get what you pay for. If you need something more, then it's up to you
to do that for yourself. Or pay someone else to do it for you.

On Tue, Dec 6, 2016 at 3:42 AM,  wrote:

> Hi,  I have found setting the pru uart pins P9_17 and P9_18 to mode 5 does
> not work using config-pins with the latest release Debian 8.6.
> The overlays I used in Debian 7.9 no longer work.  I have found that the
> overlay used to disable the hdmi, univ-emmc-00A0.dtbo does
> not include the pru_uart option for P9_17 and P9_18, whereas
> cape-universal does.  So I copied the entries for P9-17 & -18 over to
> univ-emmc, recompiled and copied to /lib/firmware which seems to solve the
> problem.  Has anyone else had a similar experience?
>
> --
> 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/37fbdce6-2cca-4fc1-9a9e-8cde0dce505c%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/CALHSORptR1VG2mmdHVafk9x7qQzuLqHU7yD-swgcudHN5R0mZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: ds18b20 with BBGW

[William Hermans]

Nope, actually that persons overlay file is wrong. So yeah I don;t know
time to learn Linux and start troubleshooting your problems ;)

On Mon, Dec 5, 2016 at 8:47 PM, William Hermans <yyrk...@gmail.com> wrote:

> Actually the last bit probably wont work because:
>
> william@beaglebone:~$ ls /sys/devices/platform/ocp/*.gpio/gpio/
> /sys/devices/platform/ocp/44e07000.gpio/gpio/:
> gpiochip0
>
> /sys/devices/platform/ocp/4804c000.gpio/gpio/:
> gpiochip32
>
> /sys/devices/platform/ocp/481ac000.gpio/gpio/:
> gpiochip64
>
> /sys/devices/platform/ocp/481ae000.gpio/gpio/:
> gpiochip96
>
> You wont get an actual gpio bank number. Just the bank offset. So going by
> this beaglebone blogpost: http://www.bonebrews.com/
> temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/
>
> gpios = < 13 0>;  /* P8.11*/
>
> I show P8.11 as gpio1_13 in my pinmux pdf file. So yes, 4.x versus 3.8.x,
> for gpio banks are definitely off by one. Looks like for 3.8.x kernel gpio
> banks start at gpio1, and I know for a fact that gpio banks in 4.x start at
> gpio0.
>
> Anyway, very good chance your overlay file is slightly wrong. Based on off
> by one gpio bank.
>
> On Mon, Dec 5, 2016 at 8:28 PM, William Hermans <yyrk...@gmail.com> wrote:
>
>> On Mon, Dec 5, 2016 at 7:30 PM, acheesehead <acheeseh...@gmail.com>
>> wrote:
>>
>>> Tried your workflow today without success. Everything is OK up to the
>>> lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel
>>> expert, so I don't know how to troubleshoot why the other entries aren't
>>> showing up.
>>>
>>> I didn't see any activity on the oscilloscope either.
>>>
>>
>> Then, you must be using a 3.8.x kernel. Right ? But here are the modules
>> needed at least on a 4.x kernel:
>>
>> william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
>> w1_therm4886  0
>> w1_gpio 3764  0
>> wire   35398  2 w1_gpio,w1_therm
>>
>> All three of those need to be loaded in order for the DS18B20 to work.
>> So, try manually loading those via modprobe. SO let's take a look at a rPI
>> blogpost: https://www.modmypi.com/blog/ds18b20-one-wire-digital-temper
>> ature-sensor-and-the-raspberry-pi
>>
>> Much of this blog post is going to be RaspberryPI centric. 
>> *dtoverlay=w1-gpio,
>> */boot/config.txt, etc. However if you scroll down to the *"Programming"
>> *part of the blog post. This person talks about loading the required
>> kernel modules( also note that kernel version is 3.6.11 ) Using modprobe.
>> So if you run those two modprobe commands, and then list the contents of
>> /sys/bus/w1/devices:
>>
>> *william@beaglebone:~$* ls /sys/bus/w1/devices/
>> 28-0647ddf6  w1_bus_master1
>>
>> And you get output like the above. 1-wire *is* working, and the 1-wire
>> master ( beaglebone ) has detected a 1-wire slave device. It's working.
>> However, if you load both the above 1-wire kernel modules, and there is
>> nothing in /sys/bus/w1/devices, then something is wrong. I'd have to say at
>> this point, if you do not get an error about a missing module, that you
>> have your pin muxed incorrectly, or not properly connected to the pin.
>>
>> Now if you get an error on the command line from trying to load either of
>> those two 1-wire modules. Chances are pretty good you haven't compiled in
>> the given proper 1-wire support. In fact, I do believe there is a whole
>> section in menu-config for 1-wire devices. You may actually have to
>> recompile your kernel with support for the DS18B20 1-wire device . . .
>>
>> Another issues between 4.x, and 3.8.x kernels is that device enumeration
>> was different for some devices. So . . . It is entirely possible, in your
>> overlay, that the GPIO bank you're passing in as parameters is off by one.
>> How can be test for this ? On 4.x kernels . . .
>>
>> *william@beaglebone:~$* ls /sys/devices/platform/ocp
>> 4030.ocmcram  48042000.timer
>> 480ca000.spinlock  4980.tptc  driver_override
>> 40302000.ocmcram_nocache  48044000.timer
>> 4819c000.i2c   4990.tptc  modalias
>> 44e07000.gpio 48046000.timer
>> 481ac000.gpio  49a0.tptc  ocp:l4_wkup@44c0
>> 44e09000.serial   48048000.timer
>> 481ae000.gpio  4a10.ethernet  of_node
>> 44e0b000.i2c  4804a000.timer
>> 481d8000.mmc   4c00.emif  power
>> 44e35000.wdt  4804

Re: [beagleboard] Re: ds18b20 with BBGW

[William Hermans]

Actually the last bit probably wont work because:

william@beaglebone:~$ ls /sys/devices/platform/ocp/*.gpio/gpio/
/sys/devices/platform/ocp/44e07000.gpio/gpio/:
gpiochip0

/sys/devices/platform/ocp/4804c000.gpio/gpio/:
gpiochip32

/sys/devices/platform/ocp/481ac000.gpio/gpio/:
gpiochip64

/sys/devices/platform/ocp/481ae000.gpio/gpio/:
gpiochip96

You wont get an actual gpio bank number. Just the bank offset. So going by
this beaglebone blogpost:
http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/

gpios = < 13 0>;  /* P8.11*/

I show P8.11 as gpio1_13 in my pinmux pdf file. So yes, 4.x versus 3.8.x,
for gpio banks are definitely off by one. Looks like for 3.8.x kernel gpio
banks start at gpio1, and I know for a fact that gpio banks in 4.x start at
gpio0.

Anyway, very good chance your overlay file is slightly wrong. Based on off
by one gpio bank.

On Mon, Dec 5, 2016 at 8:28 PM, William Hermans <yyrk...@gmail.com> wrote:

> On Mon, Dec 5, 2016 at 7:30 PM, acheesehead <acheeseh...@gmail.com> wrote:
>
>> Tried your workflow today without success. Everything is OK up to the
>> lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel
>> expert, so I don't know how to troubleshoot why the other entries aren't
>> showing up.
>>
>> I didn't see any activity on the oscilloscope either.
>>
>
> Then, you must be using a 3.8.x kernel. Right ? But here are the modules
> needed at least on a 4.x kernel:
>
> william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
> w1_therm4886  0
> w1_gpio 3764  0
> wire   35398  2 w1_gpio,w1_therm
>
> All three of those need to be loaded in order for the DS18B20 to work. So,
> try manually loading those via modprobe. SO let's take a look at a rPI
> blogpost: https://www.modmypi.com/blog/ds18b20-one-wire-digital-
> temperature-sensor-and-the-raspberry-pi
>
> Much of this blog post is going to be RaspberryPI centric. *dtoverlay=w1-gpio,
> */boot/config.txt, etc. However if you scroll down to the *"Programming" *part
> of the blog post. This person talks about loading the required kernel
> modules( also note that kernel version is 3.6.11 ) Using modprobe. So if
> you run those two modprobe commands, and then list the contents of
> /sys/bus/w1/devices:
>
> *william@beaglebone:~$* ls /sys/bus/w1/devices/
> 28-0647ddf6  w1_bus_master1
>
> And you get output like the above. 1-wire *is* working, and the 1-wire
> master ( beaglebone ) has detected a 1-wire slave device. It's working.
> However, if you load both the above 1-wire kernel modules, and there is
> nothing in /sys/bus/w1/devices, then something is wrong. I'd have to say at
> this point, if you do not get an error about a missing module, that you
> have your pin muxed incorrectly, or not properly connected to the pin.
>
> Now if you get an error on the command line from trying to load either of
> those two 1-wire modules. Chances are pretty good you haven't compiled in
> the given proper 1-wire support. In fact, I do believe there is a whole
> section in menu-config for 1-wire devices. You may actually have to
> recompile your kernel with support for the DS18B20 1-wire device . . .
>
> Another issues between 4.x, and 3.8.x kernels is that device enumeration
> was different for some devices. So . . . It is entirely possible, in your
> overlay, that the GPIO bank you're passing in as parameters is off by one.
> How can be test for this ? On 4.x kernels . . .
>
> *william@beaglebone:~$* ls /sys/devices/platform/ocp
> 4030.ocmcram  48042000.timer480ca000.spinlock
> 4980.tptc  driver_override
> 40302000.ocmcram_nocache  48044000.timer4819c000.i2c
> 4990.tptc  modalias
> 44e07000.gpio 48046000.timer481ac000.gpio
> 49a0.tptc  ocp:l4_wkup@44c0
> 44e09000.serial   48048000.timer481ae000.gpio
> 4a10.ethernet  of_node
> 44e0b000.i2c  4804a000.timer481d8000.mmc
> 4c00.emif  power
> 44e35000.wdt  4804c000.gpio 4820.interrupt-controller
> 5310.sham  subsystem
> 44e3e000.rtc  4806.mmc  4831.rng
> 5350.aes   uevent
> 4740.usb  480c8000.mailbox  4900.edma
> 5600.sgx
>
> *william@beaglebone:~$* ls /sys/devices/platform/ocp/44e07000.gpio/gpio/
> gpiochip0
>
> And the very first gpio address entry in this case was the lowest gpio
> bank. So, if you investigate the equivalent directory in 3.8.x, you should
> be able to check all gpio banks, to see what the actual lowest gpio bank
> is. Do also keep in mind that /sys/devices/platform/ocp/ will be
> different in 3.8.x. So you'll have t

Re: [beagleboard] Re: ds18b20 with BBGW

[William Hermans]

On Mon, Dec 5, 2016 at 7:30 PM, acheesehead  wrote:

> Tried your workflow today without success. Everything is OK up to the
> lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel
> expert, so I don't know how to troubleshoot why the other entries aren't
> showing up.
>
> I didn't see any activity on the oscilloscope either.
>

Then, you must be using a 3.8.x kernel. Right ? But here are the modules
needed at least on a 4.x kernel:

william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
w1_therm4886  0
w1_gpio 3764  0
wire   35398  2 w1_gpio,w1_therm

All three of those need to be loaded in order for the DS18B20 to work. So,
try manually loading those via modprobe. SO let's take a look at a rPI
blogpost:
https://www.modmypi.com/blog/ds18b20-one-wire-digital-temperature-sensor-and-the-raspberry-pi

Much of this blog post is going to be RaspberryPI centric. *dtoverlay=w1-gpio,
*/boot/config.txt, etc. However if you scroll down to the *"Programming" *part
of the blog post. This person talks about loading the required kernel
modules( also note that kernel version is 3.6.11 ) Using modprobe. So if
you run those two modprobe commands, and then list the contents of
/sys/bus/w1/devices:

*william@beaglebone:~$* ls /sys/bus/w1/devices/
28-0647ddf6  w1_bus_master1

And you get output like the above. 1-wire *is* working, and the 1-wire
master ( beaglebone ) has detected a 1-wire slave device. It's working.
However, if you load both the above 1-wire kernel modules, and there is
nothing in /sys/bus/w1/devices, then something is wrong. I'd have to say at
this point, if you do not get an error about a missing module, that you
have your pin muxed incorrectly, or not properly connected to the pin.

Now if you get an error on the command line from trying to load either of
those two 1-wire modules. Chances are pretty good you haven't compiled in
the given proper 1-wire support. In fact, I do believe there is a whole
section in menu-config for 1-wire devices. You may actually have to
recompile your kernel with support for the DS18B20 1-wire device . . .

Another issues between 4.x, and 3.8.x kernels is that device enumeration
was different for some devices. So . . . It is entirely possible, in your
overlay, that the GPIO bank you're passing in as parameters is off by one.
How can be test for this ? On 4.x kernels . . .

*william@beaglebone:~$* ls /sys/devices/platform/ocp
4030.ocmcram  48042000.timer480ca000.spinlock
4980.tptc  driver_override
40302000.ocmcram_nocache  48044000.timer4819c000.i2c
4990.tptc  modalias
44e07000.gpio 48046000.timer481ac000.gpio
49a0.tptc  ocp:l4_wkup@44c0
44e09000.serial   48048000.timer481ae000.gpio
4a10.ethernet  of_node
44e0b000.i2c  4804a000.timer481d8000.mmc
4c00.emif  power
44e35000.wdt  4804c000.gpio 4820.interrupt-controller
5310.sham  subsystem
44e3e000.rtc  4806.mmc  4831.rng
5350.aes   uevent
4740.usb  480c8000.mailbox  4900.edma
5600.sgx

*william@beaglebone:~$* ls /sys/devices/platform/ocp/44e07000.gpio/gpio/
gpiochip0

And the very first gpio address entry in this case was the lowest gpio
bank. So, if you investigate the equivalent directory in 3.8.x, you should
be able to check all gpio banks, to see what the actual lowest gpio bank
is. Do also keep in mind that /sys/devices/platform/ocp/ will be different
in 3.8.x. So you'll have to poke around a bit. Unless someone else posts
here and gives you the proper path. I don't remember what it is.

Anyway, there is another option. You can upgrade your kernel to a newer
version. Which, yes, will probably mean you'll also have to either flash a
newer image, or run a newer image from sdcard.

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

Re: [beagleboard] Re: ds18b20 with BBGW

[William Hermans]

*OR* P8.26 . . . *smacks hardware designer / buddy . . .

*william@beaglebone:~/dev/bb.org-overlays$* diff
src/arm/BB-W1-P8.26-00A0.dts src/arm/BB-W1-P8.14-00A0.dts
4c4
<  * Virtual cape for onewire on connector pin P8.26
---
>  * Virtual cape for onewire on connector pin P8.14
21c21
<   part-number = "BB-W1-P8.26";
---
>   part-number = "BB-W1-P8.14";
27c27
<   "P8.26";
---
>   "P8.14";
35c35
<   BONE_P8_26 0x37
---
>   BONE_P8_14 0x37
51c51
<   gpios = < 29 GPIO_ACTIVE_HIGH>;
---
>   gpios = < 26 GPIO_ACTIVE_HIGH>;
*william@beaglebone:~$* cd dev/bb.org-overlays/
william@beaglebone:~/dev/bb.org-overlays$ make
./src/arm/BB-W1-P8.26-00A0.dtbo
  DTC src/arm/BB-W1-P8.26-00A0.dtbo
*william@beaglebone:~/dev/bb.org-overlays*$ sudo cp
./src/arm/BB-W1-P8.26-00A0.dtbo /lib/firmware/
*william@beaglebone:~/dev/bb.org-overlays*$ cat
/sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
*william@beaglebone:~/dev/bb.org-overlays$* sudo sh -c "echo 'BB-W1-P8.26'
> /sys/devices/platform/bone_capemgr/slots"
*william@beaglebone:~/dev/bb.org-overlays$* cat
/sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P8.26
*william@beaglebone:~/dev/bb.org-overlays$* dmesg |grep W1
[  210.416201] bone_capemgr bone_capemgr: part_number 'BB-W1-P8.26',
version 'N/A'
[  210.416276] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-W1-P8.26'
[  210.430251] bone_capemgr bone_capemgr: slot #4: dtbo
'BB-W1-P8.26-00A0.dtbo' loaded; overlay id #0
*william@beaglebone:~/dev/bb.org-overlays$* ls /sys/bus/w1/devices/
28-0647ddf6  w1_bus_master1
*william@beaglebone:~/dev/bb.org-overlays$* cat
/sys/bus/w1/devices/28-0647ddf6/w1_slave
19 01 4b 46 7f ff 07 10 eb : crc=eb YES
19 01 4b 46 7f ff 07 10 eb t=17562


Anyway, dead horse . . . point made?

On Mon, Dec 5, 2016 at 6:41 PM, William Hermans <yyrk...@gmail.com> wrote:

> I repeated this process for P8.14, and it works fine. This is just to let
> others who may not be aware that you can use 1-wire on any gpio pin that is
> not already in use by the system. Again, double check the pins in the
> schematic, to make sure they're not being used by somethign like HDMI(
> which you can disable hdmi audio and video if you do not need it. ), or
> i2c-0 / i2c-2, emmc, sdcard, etc. But again you have to of course change
> the overlay to reflect the pin you need to use.
>
> *william@beaglebone:~$* diff 
> ./dev/bb.org-overlays/src/arm/BB-W1-P8.14-00A0.dts
> ./dev/bb.org-overlays/src/arm/BB-W1-P9.12-00A0.dts
> 1c1,2
> < /*
> ---
> >
> >  /*
> 4c5
> <  * Virtual cape for onewire on connector pin P8.14
> ---
> >  * Virtual cape for onewire on connector pin P9.12
> 21c22
> <   part-number = "BB-W1-P8.14";
> ---
> >   part-number = "BB-W1-P9.12";
> 27c28
> <   "P8.14";
> ---
> >   "P9.12";
> 35c36
> <   BONE_P8_14 0x37
> ---
> >   BONE_P9_12 0x37
> 51c52
> <   gpios = < 26 GPIO_ACTIVE_HIGH>;
> ---
> >   gpios = < 28 GPIO_ACTIVE_HIGH>;
>
>
>
>
> On Sat, Dec 3, 2016 at 3:11 PM, William Hermans <yyrk...@gmail.com> wrote:
>
>> @ Sebastian
>>
>> Ah I forgot to mention loading capes from /boot/uEnv.txt. So . . .
>>
>> *william@beaglebone:~$* cat /boot/uEnv.txt |grep cape
>> #cmdline=coherent_pool=1M quiet cape_universal=enable
>> video=HDMI-A-1:1024x768@60e
>> #cape_disable=capemgr.disable_partno=
>> #cape_enable=capemgr.enable_partno=
>> #cape_disable=bone_capemgr.disable_partno=
>>
>> cape_enable=capemgr.enable_partno= is the way to go. You
>> can assign multiple cape overlays with this feature, but I do not remember
>> if they are space, or comma separated. I'm thinking comma separated, but
>> may be wrong.
>>
>> That's the first step.
>>
>> The second step would be to . . .
>>
>> Copy all your required overlays into /lib/firmware, which you've
>> probably already done.
>>
>> *william@beaglebone:~$* cd /opt/scripts/
>> *william@beaglebone:/opt/scripts$* git pull
>> *william@beaglebone:/opt/scripts$* cd tools/developers/
>> *william@beaglebone:/opt/scripts/tools/developers$* sudo
>> ./update_initrd.sh
&g

Re: [beagleboard] Re: ds18b20 with BBGW

[William Hermans]

I repeated this process for P8.14, and it works fine. This is just to let
others who may not be aware that you can use 1-wire on any gpio pin that is
not already in use by the system. Again, double check the pins in the
schematic, to make sure they're not being used by somethign like HDMI(
which you can disable hdmi audio and video if you do not need it. ), or
i2c-0 / i2c-2, emmc, sdcard, etc. But again you have to of course change
the overlay to reflect the pin you need to use.

*william@beaglebone:~$* diff
./dev/bb.org-overlays/src/arm/BB-W1-P8.14-00A0.dts
./dev/bb.org-overlays/src/arm/BB-W1-P9.12-00A0.dts
1c1,2
< /*
---
>
>  /*
4c5
<  * Virtual cape for onewire on connector pin P8.14
---
>  * Virtual cape for onewire on connector pin P9.12
21c22
<   part-number = "BB-W1-P8.14";
---
>   part-number = "BB-W1-P9.12";
27c28
<   "P8.14";
---
>   "P9.12";
35c36
<   BONE_P8_14 0x37
---
>   BONE_P9_12 0x37
51c52
<   gpios = < 26 GPIO_ACTIVE_HIGH>;
---
>           gpios = < 28 GPIO_ACTIVE_HIGH>;




On Sat, Dec 3, 2016 at 3:11 PM, William Hermans <yyrk...@gmail.com> wrote:

> @ Sebastian
>
> Ah I forgot to mention loading capes from /boot/uEnv.txt. So . . .
>
> *william@beaglebone:~$* cat /boot/uEnv.txt |grep cape
> #cmdline=coherent_pool=1M quiet cape_universal=enable
> video=HDMI-A-1:1024x768@60e
> #cape_disable=capemgr.disable_partno=
> #cape_enable=capemgr.enable_partno=
> #cape_disable=bone_capemgr.disable_partno=
>
> cape_enable=capemgr.enable_partno= is the way to go. You
> can assign multiple cape overlays with this feature, but I do not remember
> if they are space, or comma separated. I'm thinking comma separated, but
> may be wrong.
>
> That's the first step.
>
> The second step would be to . . .
>
> Copy all your required overlays into /lib/firmware, which you've probably
> already done.
>
> *william@beaglebone:~$* cd /opt/scripts/
> *william@beaglebone:/opt/scripts$* git pull
> *william@beaglebone:/opt/scripts$* cd tools/developers/
> *william@beaglebone:/opt/scripts/tools/developers$* sudo
> ./update_initrd.sh
>
> What this does, is notes what's in uEnv.txt in the way of enabled capes,
> then which overlays you have in /lib/firmware, and "injects" these overlays
> into the initramfs. This is important, and if not done, your overlays will
> not load at boot using this method. But the upside is that once done, this
> will load your overlays at boot faster than any other method. Near
> instantly at boot, 1-2 seconds tops.
>
> Anyway, this method is fairly easy, and is actually the best way to go.
>
>

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

Re: [beagleboard] Re: ds18b20 with BBGW

[William Hermans]

@ Sebastian

Ah I forgot to mention loading capes from /boot/uEnv.txt. So . . .

*william@beaglebone:~$* cat /boot/uEnv.txt |grep cape
#cmdline=coherent_pool=1M quiet cape_universal=enable
video=HDMI-A-1:1024x768@60e
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=
#cape_disable=bone_capemgr.disable_partno=

cape_enable=capemgr.enable_partno= is the way to go. You can
assign multiple cape overlays with this feature, but I do not remember if
they are space, or comma separated. I'm thinking comma separated, but may
be wrong.

That's the first step.

The second step would be to . . .

Copy all your required overlays into /lib/firmware, which you've probably
already done.

*william@beaglebone:~$* cd /opt/scripts/
*william@beaglebone:/opt/scripts$* git pull
*william@beaglebone:/opt/scripts$* cd tools/developers/
*william@beaglebone:/opt/scripts/tools/developers$* sudo ./update_initrd.sh

What this does, is notes what's in uEnv.txt in the way of enabled capes,
then which overlays you have in /lib/firmware, and "injects" these overlays
into the initramfs. This is important, and if not done, your overlays will
not load at boot using this method. But the upside is that once done, this
will load your overlays at boot faster than any other method. Near
instantly at boot, 1-2 seconds tops.

Anyway, this method is fairly easy, and is actually the best way to go.

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

Re: [beagleboard] clone image

[William Hermans]

Also, knowing whether you want an system that boots from the emmc, or
sdcard is required in order to moreproperly answer your question,

Additionally, what I mentioned above in every case is a one off only copy.
Meaning you'd have to re-image each board one at a time. In order to do
multiple boards at once, a more elaborate system would be needed, and would
most likely cost additional monies to implement.

TFTP / NFS boot/root comes to mind, but I'm having a hard time imaging off
the top of my head how that would work out best. BUt for starters, you'd
still have to have atleast an sdcard or multiples, in order to pull that
off.

So having an emmc flasher image of some sort is probably the quickest and
least expensive way to go. Then you just put the sdcard into a board, and
boot -> flash to emmc. Then move on to the next system.

On Sat, Dec 3, 2016 at 2:29 PM, William Hermans <yyrk...@gmail.com> wrote:

> Robert uses rsync I think for his cloning image( emmc flasher images ).
>
> But I think the best, easiest, and most consistent way to clone an image
> would be to use dd. This has the benefit of creating a bit for bit exact
> copy of the image in question. However, one downside to using dd is that if
> you're cloning media with large partitions, it can take a while to make
> these copies.
>
> You can also use tar to make a copy of the rootfs partition This has the
> added benefit of making "images" exactly the size needed for the file
> system. Which can save time in both imaging a working file system, and then
> making multiple copies, However, this method will not copy the medias MBR
> where the first, and second stage bootloaders live. So dd, would still have
> to be used at minimum to copy the first 1M of the media. Which is actually
> much easier said, than done. But if I were to put this method into a usable
> category of some sort. I would say in situations where you only need to
> update the rootfs, or only part of the rootfs( like a rootfs "update" ).
>
> rsync for both of the above situations is probably the best option. It can
> even be really fast But rsync does also have it's own downsides. For one it
> can be really picky about what it wants to do. Under some circumstances. So
> at times it can be less consistent. e.g. an image clone may fail for some
> reason or another.
>
> There was also another method for cloning image that Robert was
> experimenting with, that I can not think of off hand.
>
> With all the above said. I think Robert built in a method to make an emmc
> flasher image out of any sdcard image. But I'm not sure if that will flash
> the entire "live" sdcard image over to the emmc or not. Robert would have
> to answer that.
>
> You could also write, and run your own script at boot up to do any of the
> above mentioned method. This is what I'd consider the best method. Because
> If you had additional setup to do after the copy. You can build in that
> functionality too. But it also requires *you* to first know how to write
> said script, and then know exactl what has to be done in order to create a
> properly working system form the ground up.
>

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

Re: [beagleboard] clone image

[William Hermans]

Robert uses rsync I think for his cloning image( emmc flasher images ).

But I think the best, easiest, and most consistent way to clone an image
would be to use dd. This has the benefit of creating a bit for bit exact
copy of the image in question. However, one downside to using dd is that if
you're cloning media with large partitions, it can take a while to make
these copies.

You can also use tar to make a copy of the rootfs partition This has the
added benefit of making "images" exactly the size needed for the file
system. Which can save time in both imaging a working file system, and then
making multiple copies, However, this method will not copy the medias MBR
where the first, and second stage bootloaders live. So dd, would still have
to be used at minimum to copy the first 1M of the media. Which is actually
much easier said, than done. But if I were to put this method into a usable
category of some sort. I would say in situations where you only need to
update the rootfs, or only part of the rootfs( like a rootfs "update" ).

rsync for both of the above situations is probably the best option. It can
even be really fast But rsync does also have it's own downsides. For one it
can be really picky about what it wants to do. Under some circumstances. So
at times it can be less consistent. e.g. an image clone may fail for some
reason or another.

There was also another method for cloning image that Robert was
experimenting with, that I can not think of off hand.

With all the above said. I think Robert built in a method to make an emmc
flasher image out of any sdcard image. But I'm not sure if that will flash
the entire "live" sdcard image over to the emmc or not. Robert would have
to answer that.

You could also write, and run your own script at boot up to do any of the
above mentioned method. This is what I'd consider the best method. Because
If you had additional setup to do after the copy. You can build in that
functionality too. But it also requires *you* to first know how to write
said script, and then know exactl what has to be done in order to create a
properly working system form the ground up.

-- 
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/CALHSORpoK1WZhqbWb%3DPsJx2%2Bcr%2BogyKy39mnp5ZcHvGiMEhK%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.