Re: [beagleboard] Re: how to unfreeze my BBB?

[William Hermans]

On Wed, Feb 15, 2017 at 10:13 AM, mzimmers <mzimm...@gmail.com> wrote:

> On Tuesday, February 14, 2017 at 7:58:39 PM UTC-7, William Hermans wrote:
>>
>>  (some excellent directions on modifying boot arguments)
>>
>
> Thanks, William. But, given that the BBB isn't booting, how am I supposed
> to get to that file to edit it?
>

Well that implies you're able to boot from sdcard. I guess I should have
written that too ?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORobGqk%3DQSgu4-MhZUwdGiSpXmX6g-QPj7i8neJ4K93uHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: how to unfreeze my BBB?

[William Hermans]

Additional information I unintentionally left out, and be VERY CAREFUL with
using he -rf flags with rm. Make sure you're removing the correct
directory. This can completely hose your Linux rootfs if you're not
absolutely sure what you're doing. This is also partly why I traverse into
a new mount when working with system files. So I don't accidentally modify
anything on the live system . . .

root@beaglebone:~/a# cd ..
root@beaglebone:~# umount /root/a
root@beaglebone:~# rm -rf a/


On Tue, Feb 14, 2017 at 8:03 PM, William Hermans <yyrk...@gmail.com> wrote:

> By the way, DR. Molloy seems to be a good guy, and has a lot of useful
> information. But much of that information is dated, and wont work with
> current images.
>  What this boils down to is that if you're not an expert, or at least
> proficient with Linux. You're very likely to run into many problems. It may
> be best just to pose your questions here on the groups. Robert knows all
> the details of the images, and often times I can at least help pick up his
> slack. As well as I probably have a lot of hands on experience with most of
> the peripheral modules, on current Linux image.
>
> On Tue, Feb 14, 2017 at 7:58 PM, William Hermans <yyrk...@gmail.com>
> wrote:
>
>>
>>
>> On Tue, Feb 14, 2017 at 7:02 PM, mzimmers <mzimm...@gmail.com> wrote:
>>
>>>
>>> William: I do in fact own a debug cable. I'll try plugging it in and see
>>> if I can see anything. I've never worked with boot arguments; can you tell
>>> me where they're kept?
>>>
>>> mz
>>>
>>
>> root@beaglebone:~# lsblk
>> NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
>> mmcblk1boot0 179:16   02M  1 disk
>> mmcblk1boot1 179:24   02M  1 disk
>> mmcblk0  179:00 14.7G  0 disk
>> `-mmcblk0p1  179:10  1.7G  0 part /
>> mmcblk1  179:80  3.6G  0 disk
>> `-mmcblk1p1  179:90  3.6G  0 part
>>
>> root@beaglebone:~# mkdir a
>>
>> root@beaglebone:~# mount /dev/mmcblk1p1 /root/a/
>>
>> root@beaglebone:~# cd a/
>>
>> root@beaglebone:~/a# nano boot/uEnv.txt
>>
>> You're looking for( Whichever line has this and is not commented out) -> 
>> cmdline=coherent_pool=1M
>> quiet
>>
>> Remove the "quiet" off the end, then save / exit the file then reboot -
>> From the emmc of course. Observe the serial debug output. Also, at least
>> one person I can remember reported issues with booting without the quiet
>> option. So perhaps you may want to put it back after you're done getting
>> your verbose information ? Up to you.
>>
>>
>>
>>
>>
>

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

Re: [beagleboard] Re: how to unfreeze my BBB?

[William Hermans]

By the way, DR. Molloy seems to be a good guy, and has a lot of useful
information. But much of that information is dated, and wont work with
current images.
 What this boils down to is that if you're not an expert, or at least
proficient with Linux. You're very likely to run into many problems. It may
be best just to pose your questions here on the groups. Robert knows all
the details of the images, and often times I can at least help pick up his
slack. As well as I probably have a lot of hands on experience with most of
the peripheral modules, on current Linux image.

On Tue, Feb 14, 2017 at 7:58 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Tue, Feb 14, 2017 at 7:02 PM, mzimmers <mzimm...@gmail.com> wrote:
>
>>
>> William: I do in fact own a debug cable. I'll try plugging it in and see
>> if I can see anything. I've never worked with boot arguments; can you tell
>> me where they're kept?
>>
>> mz
>>
>
> root@beaglebone:~# lsblk
> NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
> mmcblk1boot0 179:16   02M  1 disk
> mmcblk1boot1 179:24   02M  1 disk
> mmcblk0  179:00 14.7G  0 disk
> `-mmcblk0p1  179:10  1.7G  0 part /
> mmcblk1  179:80  3.6G  0 disk
> `-mmcblk1p1  179:90  3.6G  0 part
>
> root@beaglebone:~# mkdir a
>
> root@beaglebone:~# mount /dev/mmcblk1p1 /root/a/
>
> root@beaglebone:~# cd a/
>
> root@beaglebone:~/a# nano boot/uEnv.txt
>
> You're looking for( Whichever line has this and is not commented out) -> 
> cmdline=coherent_pool=1M
> quiet
>
> Remove the "quiet" off the end, then save / exit the file then reboot -
> From the emmc of course. Observe the serial debug output. Also, at least
> one person I can remember reported issues with booting without the quiet
> option. So perhaps you may want to put it back after you're done getting
> your verbose information ? Up to you.
>
>
>
>
>

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

Re: [beagleboard] Re: how to unfreeze my BBB?

[William Hermans]

On Tue, Feb 14, 2017 at 7:02 PM, mzimmers  wrote:

>
> William: I do in fact own a debug cable. I'll try plugging it in and see
> if I can see anything. I've never worked with boot arguments; can you tell
> me where they're kept?
>
> mz
>

root@beaglebone:~# lsblk
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk1boot0 179:16   02M  1 disk
mmcblk1boot1 179:24   02M  1 disk
mmcblk0  179:00 14.7G  0 disk
`-mmcblk0p1  179:10  1.7G  0 part /
mmcblk1  179:80  3.6G  0 disk
`-mmcblk1p1  179:90  3.6G  0 part

root@beaglebone:~# mkdir a

root@beaglebone:~# mount /dev/mmcblk1p1 /root/a/

root@beaglebone:~# cd a/

root@beaglebone:~/a# nano boot/uEnv.txt

You're looking for( Whichever line has this and is not commented out)
-> cmdline=coherent_pool=1M
quiet

Remove the "quiet" off the end, then save / exit the file then reboot -
>From the emmc of course. Observe the serial debug output. Also, at least
one person I can remember reported issues with booting without the quiet
option. So perhaps you may want to put it back after you're done getting
your verbose information ? Up to you.

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

Re: [beagleboard] how to unfreeze my BBB?

[William Hermans]

On Tue, Feb 14, 2017 at 4:34 PM, mzimmers  wrote:

> So, in an attempt to upgrade the OS on my BBB, I managed to get it to lock
> up.
>
> When I try to boot, the LEDs look like normal for a few seconds, but then
> LED2 comes on solid, and the others are off.
>
> This occurs whether or not I plug in my flash drive.
>
> When I hold down the boot button, I get no LEDs at all.
>
> So...I'm guessing that I've corrupted some system files and am entering an
> infinite loop. Given that the workings of the BBB are essentially hidden
> from me (I can't access it via ssh or even ping), what is my best course of
> action?
>
> Thank you.
>

This is one reason to buy, own, and use a serial debug cable, or module.
You'd know exactly where the boot process was stopping. Then if you put the
kernel in verbose mode( remove "quiet" form the boot args ), you would
probably know exactly why the board is hanging. Chances are pretty good
that the image flashing just failed for something like insufficient power
while flashing( using USB power ) or maybe a picky, or bad 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/CALHSORqk%3DbDGo-qQkZeiWVm%3DnwQbgA6a%2B5wMRZFu8hzXKxFmog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Analog input cape/wiring scheme

[William Hermans]

By the way, the whole software interface for the on chip ADC is already in
place, and functional. You simply need to load the driver, or have a device
tree overlay do that for you. Then you setup the IIO driver to tell it if
you would rather operate in single-shot, or continuous mode. Then you
simply read from the "buffer file". If you're still unconvinced. Google
"beaglebone ADC" and learn how simple the software side really is. There
are many blogposts out there on the subject. One of which is mine, but
seems to be down at this moment.

On Mon, Feb 13, 2017 at 6:37 PM, William Hermans <yyrk...@gmail.com> wrote:

> On Mon, Feb 13, 2017 at 11:44 AM, Rob van der Putten <r...@sput.nl> wrote:
>
>> Hi there
>
>
>> Why is I2C a better choice then SPI?
>> The BBB has both.
>>
>>
>> Regards,
>> Rob
>>
>
> From a software developers perspective, I2C is far simpler. One call to
> ioctl() to set the mode of the file descriptor, then you simply start
> reading from whichever registers you need. Also, since the onboard PMIC,
> and EEPROM both use I2C interfaces. The buses already exist, are in use,
> the drivers, and software *have* to work. Otherwise the board does not
> function at all. Can we simply "plug in" to one of these two I2C buses to
> save pins ? I do believe so yes. It's been a while since I've looked into
> that. I think one can use i2c-2 for sure, but I'm not sure if one can also
> tie into the I2C bus which the PMIC is connected to or not.
>
> SPI conversely is not required for the board to function. So drivers are
> not necessarily already loaded, and functioning. SPI also uses at minimum 3
> pins. 2 data lines, and a CS pin. I have heard of, and seen 1 "wire" SPI
> implementations, but I'm not sure that could be made to work easily in
> Linux. Since most software implementations use SPIDev. Which is master mode
> only SPI. Not that this matters for using an externally interface device,
> such as an ADC.
>
> I still think it's much easier to use the on chip ADC. We're using it here
> for a custom cape. Using one opamp, and a voltage divider. Input is 0-10v
> dc, and the resistor network limits the voltage to 1.5v max, Which does
> limit the resolution *some*, but you most definitely do not want to go over
> 1.8v on the ADC. As stated in the TRM.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORqpyFekypMA3xWFoWQ%3DLbydW%3DBSdz%2BAdCf9_cn3P1ns8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Analog input cape/wiring scheme

[William Hermans]

On Mon, Feb 13, 2017 at 11:44 AM, Rob van der Putten  wrote:

> Hi there


> Why is I2C a better choice then SPI?
> The BBB has both.
>
>
> Regards,
> Rob
>

>From a software developers perspective, I2C is far simpler. One call to
ioctl() to set the mode of the file descriptor, then you simply start
reading from whichever registers you need. Also, since the onboard PMIC,
and EEPROM both use I2C interfaces. The buses already exist, are in use,
the drivers, and software *have* to work. Otherwise the board does not
function at all. Can we simply "plug in" to one of these two I2C buses to
save pins ? I do believe so yes. It's been a while since I've looked into
that. I think one can use i2c-2 for sure, but I'm not sure if one can also
tie into the I2C bus which the PMIC is connected to or not.

SPI conversely is not required for the board to function. So drivers are
not necessarily already loaded, and functioning. SPI also uses at minimum 3
pins. 2 data lines, and a CS pin. I have heard of, and seen 1 "wire" SPI
implementations, but I'm not sure that could be made to work easily in
Linux. Since most software implementations use SPIDev. Which is master mode
only SPI. Not that this matters for using an externally interface device,
such as an ADC.

I still think it's much easier to use the on chip ADC. We're using it here
for a custom cape. Using one opamp, and a voltage divider. Input is 0-10v
dc, and the resistor network limits the voltage to 1.5v max, Which does
limit the resolution *some*, but you most definitely do not want to go over
1.8v on the ADC. As stated in the TRM.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORoDcaE8qpSND2Xh4uoE3Z4B77i-Tb8PqXei-RoSL4y4Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Analog input cape/wiring scheme

[William Hermans]

On Mon, Feb 13, 2017 at 5:20 AM, Rob van der Putten  wrote:

> Hi there
>
>
> On 13/02/17 13:01, evilwulfie wrote:
>
> I use a single rail opamp to level convert and protect the analog input.
>>
>
> It's probably easier to use an SPI ADC (EG: MCP3201) running on 5V and
> then do the level translation in the digital signal.
>
>
> Regards,
> Rob
>
>
Probably not. With the onchip ADC, all the software( drivers etc ) are
already written for you. Using an external SPI ADC you have to deal with
additional costs, additional circuitry, and additional software, which is
on you to create. Not only that, you will probably still have to level
convert, in order to make sure the input on the ADC does not swing too
high. You also need to isolate the pin.

I'd say an I2C ADC would be a better choice, and it would be except. You
would have to deal with everything i mentioned about an SPI ADC. Except
writing the "driver" software would be much easier to deal with.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORri5W7UX37fmQTQGJJPpmQ4e_uDZbtGbPFy8%3DUNE33u7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

[William Hermans]

Anyway, my idea was something like this. In the past I've written a couple
different applications that have directly accessed peripherals registers
through mmap() + /dev/mem/. So I would imagine( again no hands on here )
accessing the PRU's memory directly from user space Linux could be
potentially as simple. Now whether or not the scratchpad areas could be
access the same way from user space Linux, I'm not sure. I am also not even
sure if that would be important. However, since a user space C application
is used to load the PRU's executable binary in the first place. Not much of
a stretch to imagine one could, or should be able to access all of the
PRU's periphery. I could be wrong I suppose.

But the point is really this. If you need to get data out of the PRU's into
userland Linux as quickly as possible. Maybe the way to pull that data ot
of the PRU's memory is from the ARM(Linux ) side of things ?



On Thu, Feb 9, 2017 at 7:16 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Thu, Feb 9, 2017 at 6:56 PM, Charles Steinkuehler <
> char...@steinkuehler.net> wrote:
>
> >You cannot "broadside" store the register file into the 8k or 12k data
> >
> > rams, only into one of the three scratch pad locations or directly
> > into the other PRU's register file.  Table 4-21 (of the AM335x TRM
> > version spruh73o) lists what happens when you encounter collisions or
> > stalls with the XIN/XOUT commands.
> >
> > --
> > Charles Steinkuehler
> > char...@steinkuehler.net
>
> Thanks Charles, Yeah the whole time I'm thinking to myself "but theres
> three areas . . ." Anyway you have actually have hands on. Everything I
> know is just from reading. Also good to know there is a newer TRM with PRU
> information in it that I was unaware 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/CALHSORqmQva6AwqeT8mN0n5iE9c0B4Zqa7mZc2y5kJVv_WFPxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

[William Hermans]

On Thu, Feb 9, 2017 at 6:56 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

>You cannot "broadside" store the register file into the 8k or 12k data
>
> rams, only into one of the three scratch pad locations or directly
> into the other PRU's register file.  Table 4-21 (of the AM335x TRM
> version spruh73o) lists what happens when you encounter collisions or
> stalls with the XIN/XOUT commands.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net

Thanks Charles, Yeah the whole time I'm thinking to myself "but theres
three areas . . ." Anyway you have actually have hands on. Everything I
know is just from reading. Also good to know there is a newer TRM with PRU
information in it that I was unaware 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/CALHSORpCWwtvP9r1WqrDw-GzeE5RZua2fhAyKT5vLct9%2BHHgwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

[William Hermans]

On Thu, Feb 9, 2017 at 4:20 PM, ags  wrote:

> Continued review of documentation has caused me to wonder if I've missed a
> fundamental error in my thinking about what is and isn't deterministic when
> using the PRUs. The PRU-local 32-bit interconnect bus is itself a shared
> resource. If one PRU writes to its own DRAM, and the other PRU writes to
> its own DRAM, won't that potentially cause one to stall waiting for the
> other to complete (particularly with a burst load/store)? That would make
> the dual/triple porting of the shared DRAM also less valuable. If the PRUs
> are being used to get data from the ARM core/main memory and then bit bang
> pins, that too is subject to competition for control of the 32-bit bus.
> Does this make sense or am I still missing something?`
>

What is it that you're asking ? There is no "shared DRAM". There is only
"the DRAM" that is used by the main ARM processor, which the PRU's can
access through the interconnect which you speak of. Writing to, and reading
from the DRAM as I understand it is not deterministic. e.g. the L4
interconnect can incur a latency penalty.

However, the 8k memory used by each PRU core, as well as the shared 12k
memory each PRU has access to is supposed to be single cycle read / write
access. In fact each PRU core as I understand it has the ability to
"broadside" all of it's 32bit registers in a single cycle over to the 12k
shared memory.

Now, if you're looking for a way to move data out of the PRU's memory,
maybe having a userspace mmap(), and /dev/mem/ application read directly
from the 12k PRU shared RAM ? You're going to incur a penalty one way or
another. No need to bog down the PRU's trying to solve that problem. What
do you think Charles ? Is this reasonable ?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORqHv%2B31Y3cmWud0Rv%2BbDFhzkFKy7CdykirL7EjAx01W4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Desired existing open source cape recommendation

[William Hermans]

If someone here is really good at PCB / electronics design, I can verbally
explain exactly what needs doing, Also, while I personally do prefer an
external style UPS( wide input voltage ). There is probably something to be
said for a cape that has an power management micro controller, plus lets
say an 18650 LiPo battery holder, etc. I really think having hte ability to
use 18650 style batteries would be an awesome feature.

On Wed, Feb 8, 2017 at 7:31 AM, Jason Kridner <jason.krid...@hangerhead.com>
wrote:

> Is the Andice cape readily available already? Is it good for the UPS
> function?
>
> On Wed, Feb 8, 2017 at 9:26 AM Graham <gra...@flex-radio.com> wrote:
>
>> I would like to support William's recommendation for a UPS type cape.
>>
>> Something that would allow the BBB to operate directly from ~11V to ~21V
>> Instantly switch to an optional +12V battery if present, upon primary
>> power loss.
>> Recharge and float the optional +12V battery, if present, after any use.
>> A couple of status outputs.
>>
>> Intended for use in server or remote applications of the BBB.
>> Could also be used as a wide range power supply input without the
>> optional UPS battery.
>>
>> --- Graham
>>
>> ==
>>
>>
>> On Tuesday, February 7, 2017 at 2:17:55 PM UTC-6, William Hermans wrote:
>>
>> I'd recommend just about any decent UPS type cape with good power
>> management features. e.g. Features that addressed the Beaglebone's
>> inability to function remotely( well ).
>>
>> On Tue, Feb 7, 2017 at 1:00 PM, Jason Kridner <jkri...@gmail.com> wrote:
>>
>> Anyone want to nominate an open source cape to go into production via a
>> group buy?
>>
>> If I don't get suggestions, I'll recommend: http://elinux.org/
>> BeagleBone_Black_RFID_Adaptor_Cape or https://github.com/
>> cclark2/interacto_bbone_cape.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard...@googlegroups.com.
>>
>>
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/beagleboard/CA%2BT6QPmCC1VDYUXogqwQRBMYqhAh7X
>> 5GjEP_2oswGFHTb6qnDg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmCC1VDYUXogqwQRBMYqhAh7X5GjEP_2oswGFHTb6qnDg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/beagleboard/491d838b-47a4-4adc-8ffd-fbbfb8ac239c%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/491d838b-47a4-4adc-8ffd-fbbfb8ac239c%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/CA%2BT6QPmUc8qhi9suXQnWL0yUh9J2qo
> SYaqJed00Z5ejLmQh3zw%40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmUc8qhi9suXQnWL0yUh9J2qoSYaqJed00Z5ejLmQh3zw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Re: PRU SPI ADC communication

[William Hermans]

> I dont know if u can answer me, but i have another two question. What is
the max RAM i can allocate to the samples from PRU, and if is possible to
write directly to an uSDcard working as external
> memory from the PRU. If not, i can do the a discuss about this.

Theoretically, you should be able to access and use all of the ARM's system
memory. Realistically, I'd say you could probably use up to around
300M-400M of the main processors memory. The system needs around ~100M for
processes, and buffering. With all that said, your bottleneck is going to
be the medium you choose to store your samples to. I would avoid the emmc,
as repeated writting / erasing to the emmc would make "short work" of the
emmc. e.g. You'd probably kill the emmc pretty fast. An sdcard will
probably die much quicker.

So the way I see it is that you have two viable options. Some sort of
networked storage, or use an external USB hard drive. Of these two when I
tested this, USB was the fastest option at around 20 Megabytes/second
throughput. The onboard Ethernet is really fast for ethernet at around  ~11
Megabytes / second with the correct tweaks.

Maybe what you really need is a fast C application that grabs the data from
the PRU's memory directly, in real-time, and shuttle that data out just as
fast as you need to. Just off the top of my head, 500ksps will probably be
between 6-7 Megabytes a second, in plain text format. If you dream up some
sort of data packing format, perhaps a good bit less.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORq18OH%2BoBa2vV-BfHiAiLe%2BKunO586Oh4ET5LaNtCFQ7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: HELP! - I can't access my BBB any more.

[William Hermans]

On Wed, Feb 8, 2017 at 3:16 PM, evilwulfie  wrote:

> ME and a software buddy have a nice watchdog timer powered from the BBB
> battery holds up the BBB till it shuts down then removes power
> draws 400uA from the battery while waiting for the power to be reapplied.
>

So, in a pinch, and if you have  physical access to the board. You can use
a LiPO battery, connected to the PMIC battery test points( ask an EE if you
need specifics ), then install the debian package acpid. Then everything
should be fine. e.g. the board will power down cleanly. However, the PMIC
will still be supplying a bit of power from the battery. So if you need it
shutdown for an extended time period. You'll need to disconnect the battery.

As for remotely installed systems. You'll have to design a watchdog / power
management system to disconnect the battery, and reset the processor when
power is reapplied. This is why in Jason's post yesterday, or the day
before. I mentioned I like to see a proper UPS cape with good power
management features built in. The beaglebone as it is is what I'd consider
a very good board, but to cut costs, when designed. Several things were
left out of the board. So instead of paying $100 + per board, we pay ~$50
per board, and design in features we need for our own situations. A fair
trade, but something we need to be aware 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/CALHSORoxjzTmVQ4wLUJZgV_DTnXBDQe9Kdg7sK50VA50KGJpEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Desired existing open source cape recommendation

[William Hermans]

I'd recommend just about any decent UPS type cape with good power
management features. e.g. Features that addressed the Beaglebone's
inability to function remotely( well ).

On Tue, Feb 7, 2017 at 1:00 PM, Jason Kridner  wrote:

> Anyone want to nominate an open source cape to go into production via a
> group buy?
>
> If I don't get suggestions, I'll recommend: http://elinux.org/
> BeagleBone_Black_RFID_Adaptor_Cape or https://github.com/
> cclark2/interacto_bbone_cape.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CA%2BT6QPmCC1VDYUXogqwQRBMYqhAh7X
> 5GjEP_2oswGFHTb6qnDg%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/CALHSORqc5TWAm%2BTuhKsd9J5TCZDFp5b%2B5xTPhKY2q8ygzJ6s%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: No LED light, My BBB perhaps died while running a PocketNC machine

[William Hermans]

One fast blink of the power LED is a good indication that the processor is
shot.

On Tue, Feb 7, 2017 at 1:59 AM,  wrote:

> So I have now removed the board from the machine and plugged it in to the
> computer USB again. One fast LED blink happens when it is connected. I have
> pressed reset button, I have pressed power off. Nothing more happens. So is
> the board dead or not? There is nothing connected to the board itself only
> the USB to power it.
>
> Den tisdag 7 februari 2017 kl. 02:15:30 UTC+1 skrev Dennis Lee Bieber:
>>
>> On Mon, 6 Feb 2017 13:05:35 -0800 (PST),
>> mic...@cyto365.com declaimed the following:
>>
>> >Thanks all for great posts. Tomorrow I will start by cleaning the
>> machine from all potential leftover aluminium chips from previous milling
>> carefully. I believe that this is the most promising lead so far, a short
>> circuit in a connector somewhere. I will keep you posted here of the
>> result.
>>
>> That is also the most likely killer... A short between 5V and
>> ground
>> could overload the current capability of the regulators. A short between
>> 5V
>> and any GPIO pin could kill the main processor (3.3v except for ADC pins
>> which are 1.8V).
>> --
>> Wulfraed Dennis Lee Bieber AF6VN
>> wlf...@ix.netcom.comHTTP://wlfraed.home.netcom.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/b28c3c2c-ddb1-4749-aa80-e398e3fa68b1%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/CALHSORrZX9F6Li6Oeu19wN-C%2Byt6oMVacqSyjsw1Gk%3DhxfgNog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

On Mon, Feb 6, 2017 at 11:00 AM,  wrote:

> I got the solutio (i think.. hehe)
>

If you're happy with the code you've got, who am I to argue about it ?

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

Re: [beagleboard] Re: Video image shifts right randomly

[William Hermans]

On Mon, Feb 6, 2017 at 1:52 PM, William Hermans <yyrk...@gmail.com> wrote:
>>
>> Something I noticed is that if I pipe /dev/urandom to /dev/fb0, I get
all the random colors, even in the left blank area when the image is
shifted. Then I started our app and the top left 10 or so pixels remained
the random colors. If I then using dd fill /dev/fb0 with zero from
/dev/null, everything becomes black, including the top left row. I am not
sure what all this means yet...
>
>
> /dev/fb0 is most likely a direct access frame buffer for the video
device. In the case, the SGX video chip. I honestly do not know about the
Linux frame buffer in great detail. But if it works similar to how old VGA
frame buffers work. Essentially it's a two dimensional array. Similar to
how you plot a coordinate in geometry.  So think 1024( up / down ) rows, of
768( left to right ) columns.
>
> Absolute top left is considered coordinate 0,0, where absolute opposite
would be 1023, 767. How a frame buffer works, is that once you go over the
maximum value in width(767), you wrap back to 0(most left ), and drop down
a row. If that row is your maximum height, then there are a couple this can
be implemented. Wrap back to 0 height, or continue on to the next "page"
Which is how sometimes frame buffering is done. Again, I do not know the
Linux frame buffer specification at all, so this part I'm not sure how this
is dealt with.
>
> Anyway, this makes it really simple, and fast to "blast" or blit changed
to screen. As the whole screen is seen at one large file, with x amount of
bytes. Each byte representing a pixel on screen. While each byte value
represents the actual color of that pixel. So when you dd random values
into this file. you're actually dding those value to your screen. By the
same logic, if you blast nothing but NULL to this file. Well, your screen
will be black ;)

And, of course I think I answered the wrong question,. e.g. one you did not
ask. So if I now understand your statement correctly there. It would seem
like someone's math is wrong. Perhaps in the frame buffer driver for this
hardware.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORqqp_-X33deSWd1mpzt74KjrwOgpsgQPHM1jzpKYkD48Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Video image shifts right randomly

[William Hermans]

>
> Something I noticed is that if I pipe /dev/urandom to /dev/fb0, I get all
> the random colors, even in the left blank area when the image is shifted.
> Then I started our app and the top left 10 or so pixels remained the random
> colors. If I then using dd fill /dev/fb0 with zero from /dev/null,
> everything becomes black, including the top left row. I am not sure what
> all this means yet...
>

/dev/fb0 is most likely a direct access frame buffer for the video device.
In the case, the SGX video chip. I honestly do not know about the Linux
frame buffer in great detail. But if it works similar to how old VGA frame
buffers work. Essentially it's a two dimensional array. Similar to how you
plot a coordinate in geometry.  So think 1024( up / down ) rows, of 768(
left to right ) columns.

Absolute top left is considered coordinate 0,0, where absolute opposite
would be 1023, 767. How a frame buffer works, is that once you go over the
maximum value in width(767), you wrap back to 0(most left ), and drop down
a row. If that row is your maximum height, then there are a couple this can
be implemented. Wrap back to 0 height, or continue on to the next "page"
Which is how sometimes frame buffering is done. Again, I do not know the
Linux frame buffer specification at all, so this part I'm not sure how this
is dealt with.

Anyway, this makes it really simple, and fast to "blast" or blit changed to
screen. As the whole screen is seen at one large file, with x amount of
bytes. Each byte representing a pixel on screen. While each byte value
represents the actual color of that pixel. So when you dd random values
into this file. you're actually dding those value to your screen. By the
same logic, if you blast nothing but NULL to this file. Well, your screen
will be 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/CALHSORp6UuP9PRF2C%3D83tsibwY1zU%2BE3SJG4HrbY_NoMF7t7Og%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

Or better yet, get rid of the second loop entirely, and just print the
values as you receive them. However, printf() *is* a system all that would
definitely slow down your ADC read speeds. Unless you pipe the output of
the application to a file. Which would not be healthy for the emmc, or
sdcard you're running from.

On Mon, Feb 6, 2017 at 10:52 AM, William Hermans <yyrk...@gmail.com> wrote:

> Thinking about how to "throttle" reading from the ADC to get correct
> values. A little more. One way you could potentially deal with that
> situation  could be to change both loops to a while() loop, and only
> increment your loop index value if the ADC index value is greater than 0.
> Or maybe test if the actual ADC index value is your loop index value +1.
> With that said, actually you would only need to throttle the ADC read loop,
> so the printing to screen loop could be left alone.
>
> However, this kind of loop would be very CPU intensive, but the problem
> with with using usleep() is that technically htis is a system call, and in
> addition to adding a hard coded delay, you're likely to also have some
> system( between user space and kernel space ) non deterministic delay
> penalty inured.
>
> On Mon, Feb 6, 2017 at 10:06 AM, William Hermans <yyrk...@gmail.com>
> wrote:
>
>>
>> On Mon, Feb 6, 2017 at 9:12 AM, Rodrigo Mesquita <
>> mesquita.rodrig...@gmail.com> wrote:
>>
>>> Mr, Willians, thanks for your answer.
>>>
>>> According to the lipruio's documentation, the variable io->DRam[0]
>>> contains the index of the last ADC data read.
>>>
>>> About the part:
>>>
>>> do{
>>> . . .
>>> }while(io->DRam[0] < 126);
>>>
>>> This is inconsistent with:
>>>
>>> for(i = 0; i<=127; i++ ){
>>> . . .
>>> }
>>>
>>> ,
>>>
>>> the for is to print the values stored. The do-while is to read the
>>> sample 1 to 126. the samples 0 and 127 are read before and after this loop,
>>> respectively.
>>>
>>> What are you sugestions to improve my code, Mr. Hermans?
>>>
>>
>> Please, in the future do not email me personally. Please email to the
>> group, so everyone can see the answer, as this may help others in the
>> future. It also makes it much harder for me to follow the posts, and give a
>> proper answer. Anyway . . .
>>
>> Assuming what you say is correct. Your loops are still off by two between
>> them. The do / while() loop being 1 based( starts from 1 ) where the for()
>> loop being zero based( starts from 0 ). To correct this most simply, change
>> your for loop to i<=125, or i<126 if that is clearer for you.
>>
>> After that, starting from the top down.
>>
>>  float n[256];
>>  int a[256];
>>  int i=0;
>>
>>
>> float n[256]; is not needed. For this particular application you only
>> need one float value for printing a voltage value in your printf()
>> statement. In fact, in the future if you plan on expanding on this
>> application you may wish to do away with float values entirely, send the
>> raw PRU values to an external source( if that's what happens ) and let the
>> external source do the heavy math. This makes what your beaglebone is doing
>> more efficient, and if performance is needed can make a huge difference.
>> Also, you can look into using fixed point numbers, but this would use more
>> processor cycles than just sending out raw values.
>>
>> int a[256]; Assuming 128 samples, I might change this to: int
>> channel_n[128]; ( n representing the actual channel you're reading from ),
>> then do all the formatting in your printf() statement. If, and when you
>> decide to print more than one channel worth of samples. This is however
>> more a matter of semantics,  but it'll also make your code much more
>> readable. Again, you need to read the C standard  for the compiler you're
>> using. It does seem possible you're using a post C99 compiler as you're not
>> initializing the variable i within the for() loop. Again, make sure your
>> array has enough room for a NULL termination byte, if needed. Which
>> wouldn't be of type byte, but instead of type int.
>>
>> The libpruio stuff TJF will be able to give you a much better answer on.
>> As it's his code, and I know nearly nothing of the specifics for this code.
>>
>> if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); //
>> start measurement
>> This is also a bit unclear to me, mostly due to not knowing the
>> implementation, but I

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

Thinking about how to "throttle" reading from the ADC to get correct
values. A little more. One way you could potentially deal with that
situation  could be to change both loops to a while() loop, and only
increment your loop index value if the ADC index value is greater than 0.
Or maybe test if the actual ADC index value is your loop index value +1.
With that said, actually you would only need to throttle the ADC read loop,
so the printing to screen loop could be left alone.

However, this kind of loop would be very CPU intensive, but the problem
with with using usleep() is that technically htis is a system call, and in
addition to adding a hard coded delay, you're likely to also have some
system( between user space and kernel space ) non deterministic delay
penalty inured.

On Mon, Feb 6, 2017 at 10:06 AM, William Hermans <yyrk...@gmail.com> wrote:

>
> On Mon, Feb 6, 2017 at 9:12 AM, Rodrigo Mesquita <
> mesquita.rodrig...@gmail.com> wrote:
>
>> Mr, Willians, thanks for your answer.
>>
>> According to the lipruio's documentation, the variable io->DRam[0]
>> contains the index of the last ADC data read.
>>
>> About the part:
>>
>> do{
>> . . .
>> }while(io->DRam[0] < 126);
>>
>> This is inconsistent with:
>>
>> for(i = 0; i<=127; i++ ){
>> . . .
>> }
>>
>> ,
>>
>> the for is to print the values stored. The do-while is to read the sample
>> 1 to 126. the samples 0 and 127 are read before and after this loop,
>> respectively.
>>
>> What are you sugestions to improve my code, Mr. Hermans?
>>
>
> Please, in the future do not email me personally. Please email to the
> group, so everyone can see the answer, as this may help others in the
> future. It also makes it much harder for me to follow the posts, and give a
> proper answer. Anyway . . .
>
> Assuming what you say is correct. Your loops are still off by two between
> them. The do / while() loop being 1 based( starts from 1 ) where the for()
> loop being zero based( starts from 0 ). To correct this most simply, change
> your for loop to i<=125, or i<126 if that is clearer for you.
>
> After that, starting from the top down.
>
>  float n[256];
>  int a[256];
>  int i=0;
>
>
> float n[256]; is not needed. For this particular application you only
> need one float value for printing a voltage value in your printf()
> statement. In fact, in the future if you plan on expanding on this
> application you may wish to do away with float values entirely, send the
> raw PRU values to an external source( if that's what happens ) and let the
> external source do the heavy math. This makes what your beaglebone is doing
> more efficient, and if performance is needed can make a huge difference.
> Also, you can look into using fixed point numbers, but this would use more
> processor cycles than just sending out raw values.
>
> int a[256]; Assuming 128 samples, I might change this to: int
> channel_n[128]; ( n representing the actual channel you're reading from ),
> then do all the formatting in your printf() statement. If, and when you
> decide to print more than one channel worth of samples. This is however
> more a matter of semantics,  but it'll also make your code much more
> readable. Again, you need to read the C standard  for the compiler you're
> using. It does seem possible you're using a post C99 compiler as you're not
> initializing the variable i within the for() loop. Again, make sure your
> array has enough room for a NULL termination byte, if needed. Which
> wouldn't be of type byte, but instead of type int.
>
> The libpruio stuff TJF will be able to give you a much better answer on.
> As it's his code, and I know nearly nothing of the specifics for this code.
>
> if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); //
> start measurement
> This is also a bit unclear to me, mostly due to not knowing the
> implementation, but I'd probably move this if() statement into a while
> statement. That way you can loop, and sleep 1 second between fails.
> Assuming the check fails more than once. Still it'd be clearer to at least
> me, which may not matter to you, or anyone else. Semantics . . . However,
> as it stands, if the check fails, you code will probably just exit. Maybe
> this is what you want ?
>
> As for your index values being "off" or just plain zero in some cases. The
> first thought that comes to mind is that you're trying to read from the ADC
> too fast. But again, I have no idea what TJF's code is doing, so this may
> not be possible. That would be the first place I'd look though, and in fact
> looking at your output, that seems very possible. As ev

Re: [beagleboard] Configuration GPIO during Linux start up

[William Hermans]

On Mon, Feb 6, 2017 at 9:49 AM, Shimon Filtzer  wrote:

> Hello, guys!
> For my application I need, that pin P8-13(GPIO23), will get output high
> level as soon as possible. As I understand, I need to change both uboot and
> kernel. (is it correct?)
> But I can not find some manual for these changes.
> Any help?
> Thank you!
>

Yes, and sort of no. With either way I'm about to mention, you will of
course have to write, or modify an overlay to make your GPIO(s) high, or
low as needed. After that.

Loading the overlay the absolute fastest, you'll want to upgrade to one of
the latest kernels, and uboot.

You can also just load the overlay from uEnv.txt as per normal, and it'll
also load nearly as fast, but perhaps a split second slower.

The actual difference here is undocumented, but in the first case, the
second stage bootloader is what loads the overlay, where in the second
case, the initramfs( initial ram disk ) is what loads the overlay.

As far as documentation goes. You'd be better off waiting for Robert's
reply. As the bootloader method as far as I'm aware is still experimental,
and subject to change.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORo7onQ0ssem%2B8NOtDRGLNuKa3A0YhqQUM2qndo%3DD-ZbBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

On Mon, Feb 6, 2017 at 9:12 AM, Rodrigo Mesquita <
mesquita.rodrig...@gmail.com> wrote:

> Mr, Willians, thanks for your answer.
>
> According to the lipruio's documentation, the variable io->DRam[0]
> contains the index of the last ADC data read.
>
> About the part:
>
> do{
> . . .
> }while(io->DRam[0] < 126);
>
> This is inconsistent with:
>
> for(i = 0; i<=127; i++ ){
> . . .
> }
>
> ,
>
> the for is to print the values stored. The do-while is to read the sample
> 1 to 126. the samples 0 and 127 are read before and after this loop,
> respectively.
>
> What are you sugestions to improve my code, Mr. Hermans?
>

Please, in the future do not email me personally. Please email to the
group, so everyone can see the answer, as this may help others in the
future. It also makes it much harder for me to follow the posts, and give a
proper answer. Anyway . . .

Assuming what you say is correct. Your loops are still off by two between
them. The do / while() loop being 1 based( starts from 1 ) where the for()
loop being zero based( starts from 0 ). To correct this most simply, change
your for loop to i<=125, or i<126 if that is clearer for you.

After that, starting from the top down.

 float n[256];
 int a[256];
 int i=0;


float n[256]; is not needed. For this particular application you only need
one float value for printing a voltage value in your printf() statement. In
fact, in the future if you plan on expanding on this application you may
wish to do away with float values entirely, send the raw PRU values to an
external source( if that's what happens ) and let the external source do
the heavy math. This makes what your beaglebone is doing more efficient,
and if performance is needed can make a huge difference. Also, you can look
into using fixed point numbers, but this would use more processor cycles
than just sending out raw values.

int a[256]; Assuming 128 samples, I might change this to: int
channel_n[128]; ( n representing the actual channel you're reading from ),
then do all the formatting in your printf() statement. If, and when you
decide to print more than one channel worth of samples. This is however
more a matter of semantics,  but it'll also make your code much more
readable. Again, you need to read the C standard  for the compiler you're
using. It does seem possible you're using a post C99 compiler as you're not
initializing the variable i within the for() loop. Again, make sure your
array has enough room for a NULL termination byte, if needed. Which
wouldn't be of type byte, but instead of type int.

The libpruio stuff TJF will be able to give you a much better answer on. As
it's his code, and I know nearly nothing of the specifics for this code.

if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); //
start measurement
This is also a bit unclear to me, mostly due to not knowing the
implementation, but I'd probably move this if() statement into a while
statement. That way you can loop, and sleep 1 second between fails.
Assuming the check fails more than once. Still it'd be clearer to at least
me, which may not matter to you, or anyone else. Semantics . . . However,
as it stands, if the check fails, you code will probably just exit. Maybe
this is what you want ?

As for your index values being "off" or just plain zero in some cases. The
first thought that comes to mind is that you're trying to read from the ADC
too fast. But again, I have no idea what TJF's code is doing, so this may
not be possible. That would be the first place I'd look though, and in fact
looking at your output, that seems very possible. As every value that has a
garbage index value seems to be zero, or close to it. Ask TJF how you
should throttle your loop. e.g. does he have something implemented in the
library, or not.

The rest of your code looks like it should work, so I'd clean up your code
a bit, throttle the ADC reading loop how TJF suggests, and check your
application output.



On Mon, Feb 6, 2017 at 8:50 AM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Mon, Feb 6, 2017 at 4:21 AM, <mesquita.rodrig...@gmail.com> wrote:
>
>> Hello Mr. TJF
>>
>> First of All, thank you so much for providing support on real-time tasks
>> using a low cost plataform.
>> I'm trying to apply the libary "libpruio" to make a system for energy
>> meansurement using the beaglebone black. To do this,  I need to enable 2
>> ADC channels, set a sample time, fil a buffer with the samples and make
>> some calculation that includes the FFT. I'm really newbie on
>> microprocessors, but i wrote a simple C code. The idea of this code is just
>> to make 128 samples os the two channels and print the values. Just it:
>>
>> #include "unistd.h"
>> #include "../c_wrapper/pruio.h" // inc

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

[William Hermans]

On Mon, Feb 6, 2017 at 4:21 AM,  wrote:

> Hello Mr. TJF
>
> First of All, thank you so much for providing support on real-time tasks
> using a low cost plataform.
> I'm trying to apply the libary "libpruio" to make a system for energy
> meansurement using the beaglebone black. To do this,  I need to enable 2
> ADC channels, set a sample time, fil a buffer with the samples and make
> some calculation that includes the FFT. I'm really newbie on
> microprocessors, but i wrote a simple C code. The idea of this code is just
> to make 128 samples os the two channels and print the values. Just it:
>
> #include "unistd.h"
> #include "../c_wrapper/pruio.h" // include header
> #include "time.h"
>
>
> //! The main function.
> int main(/*int argc, char **argv*/)
> {
>  float n[256];
>  int a[256];
>  int i=0;
>
>
>   pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 1); //! create new
> driver structure
>   pruio_adc_setStep(io, 9, 1, 0, 0, 0);
>// step 9, AIN-0
>   pruio_adc_setStep(io, 10, 2, 0, 0, 0);
>
>
>   if (pruio_config(io, 128, 9<<10 , 156250, 4)){ // upload (default)
> settings, start IO mode
>   printf("config failed (%s)\n", io->Errr);}
>   else {
>
>
>   if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); //
> start measurement
>
>
>   else{
> sleep(1);
>
>
> i=io->DRam[0];
> a[i] = i;
> n[i] = io->Adc->Value[i];
> do{
> if(i != io->DRam[0]){
> i=io->DRam[0];
> a[i] = i;
> n[i] = io->Adc->Value[i];
> }
> }while(io->DRam[0] < 126);
> a[io->DRam[0]] = io->DRam[0];
> n[io->DRam[0]] = io->Adc->Value[io->DRam[0]];
>
> for(i = 0; i<=127; i++ ){
> printf("amostra %d-   %f \n",
> a[i],  (n[i]/65536)*1.8);
> }
>
> }
> /* we're done */
> }
>   pruio_destroy(io);/* destroy driver structure */
> return 0;
> }
>
>   Right from the start I see several problems with your code.

125 zero based indexes. Or is it 128 ? Or do you really want 127 indexes ?
It's impossible for us to know.

do{
. . .
}while(io->DRam[0] < 126);

This is inconsistent with:

for(i = 0; i<=127; i++ ){
. . .
}

So, I have no clue what io-DRam[] *is*, but I can assume, somehow, you're
storing ADC values in DRAM *somehow* Based on your comments. However, first
off,  your indexes to not match one another from buffer "packaging" to
buffer "unpacking". Secondly, you're not clearing your buffers(arrays)
before using them. This is what the "garbage" numbers are coming from. It's
just random values in memory, which by the way is very bad from a couple
perspectives. But this also leaves these arrays without a NULL termination
at the end. Which is very unsafe, as a potential stack overflow. At least
this applies for type char[], I'd have to double check the C standard that
you're using for your particular case to make sure. Which you can do more
easily than I.

Additionally, your code is hard to follow. With variable names such as a,
n, and i, and zero helpful comments. The code is not exactly self
documenting. But here is what seems to be happening. You're only storing
one ADC channel value into the first half of your array. Or maybe the
conditional if statement is testing for this somehow( unclear ), and taking
care of that ?

Assuming what you really want is 128 samples of the two ADC channels you
mention, your code needs to change. You need to check and make sure you're
never going to overflow from your arrays. Which may mean your arrays need
be of size 256 + 1 for each given type. Secondly, your loops need to be
consistent at whichever number of values you wish to store. Thirdly, you
need to clear your arrays before you use them, which can be done at array
initialization, or by using memset(), after initialization.

A couple of things worth mentioning. In your printf() statement I'm not
sure of libpruio's implementation, but from my experience with the
beaglebone's ADC, this does not seem right ---> (n[i]/65536)*1.8) Values
output from the ADC are in range 0-4095, I'd double check to make sure that
is correct. It could be that libpruio's values are different in
implementation through some sort of conversation. Secondly, for some
reason, it may become readily apparent that your index value may contain a
lot of zero's in the middle indexes. You're going to need to look into why
that it happening after you clean your code up some. As I said above. I am
not familiar with libpruio's implementation, and the rest of your code is
not clear enough to make a determination at a glance.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 

Re: [beagleboard] Re: No LED light, My BBB perhaps died while running a PocketNC machine

[William Hermans]

>
> As the beaglebone is only 3.3v tolerant, and the ADC pins have a max
> tolerance of 1.8v.


Should read: Most pins on the beaglebone are only 3.3v tolerant with the
exception of the ADC pins which are only 1.8v tolerant.

On Sun, Feb 5, 2017 at 7:30 PM, William Hermans <yyrk...@gmail.com> wrote:

> Micael,
>
> For good measure, you should be aware that pins that are connected to
> external hardware. Should be isolated if those pins, and hardware are
> powered up before the beaglebone. I would think that if the beaglebone it's
> self is powering these external circuits, and hardware. Then this would be
> less of a problem.
>
> Additionally, I've had more than one beaglebone come across my "desk" in
> the last 4 or so years. One in particular is possibly form the first batch
> sold to the public. e.g. ~4 years old. I have heard people saying that if
> you pull the power, while the board is running, that the processor can be
> damaged from this action. I'm not saying to is false, I am just saying that
> it would probably be a fairly rare issue. As I've been in a situation where
> I've had to do exactly that, many times. As far as corrupting the operating
> system. It is possible, as with any operating system. But again, it's a
> fairly rare situation. You're just as likely to corrupt the system by
> installing an application, updating the system, or flashing an new image to
> the eMMC.
>
> So there is one thing I have not seen you mention if you've attempted this
> or not. Sometimes, the board needs to have the reset button pressed, before
> it will power up again. I've run into this a few times myself, and like you
> I was nearly convinced the board was dead. No power lights coming on. even
> after completely disconnecting the input power several times. I also power
> my own personal beaglebones the same way you do. Via USB. Anyway, I'm not
> saying this will fix your problem. but it is worth looking into. If in
> doubt which button is reset, it probably would not hurt for you to just
> press both of the button to the right of the ethernet jack, with ethernet
> jack oriented at the top of the board.
>
> Anyway, if you care for a much better "analysis" of what happened, and how
> to avoid the same in the future. It would behoove you to tell us exactly
> how many pins you had connected to your external hardware. What kind of
> periphery, and how much current source/sink + voltage levels. As the
> beaglebone is only 3.3v tolerant, and the ADC pins have a max tolerance of
> 1.8v.
>
> On Sun, Feb 5, 2017 at 6:38 PM, William Hermans <yyrk...@gmail.com> wrote:
>
>> Or as Gerald already eluded to in his first post. Voltage levels on the
>> GPIO's, or other periphery was too high.
>>
>> On Sun, Feb 5, 2017 at 5:18 PM, Dennis Lee Bieber <wlfr...@ix.netcom.com>
>> wrote:
>>
>>> On Sun, 5 Feb 2017 07:55:47 -0800 (PST),
>>> mic...@cyto365.com declaimed the following:
>>>
>>> >It doesn't flashes, no light at all.. during operation it went down.
>>> The BeagleBoard doesn't show up any longer as a hard drive. I connect via
>>> the micro USB port, and that is the only power source for the board.
>>>
>>> If the unit is driving any other hardware, I'd be concerned
>>> about the
>>> power supply... USB is normally only rated for 5V 500mA max (normally
>>> that
>>> 500mA is distributed among up to four sockets of a hub).
>>>
>>> However... "during operation it went down" is too vague to really
>>> comment upon... Failure points could be the USB to PMIC, the PMIC itself,
>>> or something later. A short between almost anything could draw more power
>>> than the USB could provide.
>>>
>>> Also, if that unit is running normal Linux (rather than a totally
>>> custom embedded application), then shutdown should NEVER be done by just
>>> pulling the power... Pulling power could lead to a corrupt file system
>>> (though a corrupt file system won't affect the power LED, and maybe not
>>> even the status LEDs.
>>> --
>>> Wulfraed Dennis Lee Bieber AF6VN
>>> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.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

Re: [beagleboard] Re: No LED light, My BBB perhaps died while running a PocketNC machine

[William Hermans]

Micael,

For good measure, you should be aware that pins that are connected to
external hardware. Should be isolated if those pins, and hardware are
powered up before the beaglebone. I would think that if the beaglebone it's
self is powering these external circuits, and hardware. Then this would be
less of a problem.

Additionally, I've had more than one beaglebone come across my "desk" in
the last 4 or so years. One in particular is possibly form the first batch
sold to the public. e.g. ~4 years old. I have heard people saying that if
you pull the power, while the board is running, that the processor can be
damaged from this action. I'm not saying to is false, I am just saying that
it would probably be a fairly rare issue. As I've been in a situation where
I've had to do exactly that, many times. As far as corrupting the operating
system. It is possible, as with any operating system. But again, it's a
fairly rare situation. You're just as likely to corrupt the system by
installing an application, updating the system, or flashing an new image to
the eMMC.

So there is one thing I have not seen you mention if you've attempted this
or not. Sometimes, the board needs to have the reset button pressed, before
it will power up again. I've run into this a few times myself, and like you
I was nearly convinced the board was dead. No power lights coming on. even
after completely disconnecting the input power several times. I also power
my own personal beaglebones the same way you do. Via USB. Anyway, I'm not
saying this will fix your problem. but it is worth looking into. If in
doubt which button is reset, it probably would not hurt for you to just
press both of the button to the right of the ethernet jack, with ethernet
jack oriented at the top of the board.

Anyway, if you care for a much better "analysis" of what happened, and how
to avoid the same in the future. It would behoove you to tell us exactly
how many pins you had connected to your external hardware. What kind of
periphery, and how much current source/sink + voltage levels. As the
beaglebone is only 3.3v tolerant, and the ADC pins have a max tolerance of
1.8v.

On Sun, Feb 5, 2017 at 6:38 PM, William Hermans <yyrk...@gmail.com> wrote:

> Or as Gerald already eluded to in his first post. Voltage levels on the
> GPIO's, or other periphery was too high.
>
> On Sun, Feb 5, 2017 at 5:18 PM, Dennis Lee Bieber <wlfr...@ix.netcom.com>
> wrote:
>
>> On Sun, 5 Feb 2017 07:55:47 -0800 (PST),
>> mic...@cyto365.com declaimed the following:
>>
>> >It doesn't flashes, no light at all.. during operation it went down. The
>> BeagleBoard doesn't show up any longer as a hard drive. I connect via the
>> micro USB port, and that is the only power source for the board.
>>
>> If the unit is driving any other hardware, I'd be concerned about
>> the
>> power supply... USB is normally only rated for 5V 500mA max (normally that
>> 500mA is distributed among up to four sockets of a hub).
>>
>> However... "during operation it went down" is too vague to really
>> comment upon... Failure points could be the USB to PMIC, the PMIC itself,
>> or something later. A short between almost anything could draw more power
>> than the USB could provide.
>>
>> Also, if that unit is running normal Linux (rather than a totally
>> custom embedded application), then shutdown should NEVER be done by just
>> pulling the power... Pulling power could lead to a corrupt file system
>> (though a corrupt file system won't affect the power LED, and maybe not
>> even the status LEDs.
>> --
>> Wulfraed Dennis Lee Bieber AF6VN
>> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.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/2sff9c9cnbgt4amu00s1j4r8bdtghojqsb%404ax.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/CALHSORqCRPPUYnWJRwhR6495AG1x%3DpFDPiPT%2BMXEfYfYmycvEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: No LED light, My BBB perhaps died while running a PocketNC machine

[William Hermans]

Or as Gerald already eluded to in his first post. Voltage levels on the
GPIO's, or other periphery was too high.

On Sun, Feb 5, 2017 at 5:18 PM, Dennis Lee Bieber 
wrote:

> On Sun, 5 Feb 2017 07:55:47 -0800 (PST),
> mic...@cyto365.com declaimed the following:
>
> >It doesn't flashes, no light at all.. during operation it went down. The
> BeagleBoard doesn't show up any longer as a hard drive. I connect via the
> micro USB port, and that is the only power source for the board.
>
> If the unit is driving any other hardware, I'd be concerned about
> the
> power supply... USB is normally only rated for 5V 500mA max (normally that
> 500mA is distributed among up to four sockets of a hub).
>
> However... "during operation it went down" is too vague to really
> comment upon... Failure points could be the USB to PMIC, the PMIC itself,
> or something later. A short between almost anything could draw more power
> than the USB could provide.
>
> Also, if that unit is running normal Linux (rather than a totally
> custom embedded application), then shutdown should NEVER be done by just
> pulling the power... Pulling power could lead to a corrupt file system
> (though a corrupt file system won't affect the power LED, and maybe not
> even the status LEDs.
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.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/2sff9c9cnbgt4amu00s1j4r8bdtghojqsb%404ax.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/CALHSORo1eny0Q1UvbEpYGKFmP3MCaNB3mCaUy5_TqaZh_8hH3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] the-iot-beaglebone-beagle-treat-feeder

[William Hermans]

The link is not to anything I've done. I only saw the material, and though 
others might enjoy the link as well.

http://www.allaboutcircuits.com/projects/the-iot-beaglebone-beagle-treat-feeder/?utm_source=All+About+Circuits+Members_campaign=c35ae9f1c3-EMAIL_CAMPAIGN_2017_02_01_medium=email_term=0_2565529c4b-c35ae9f1c3-265615941/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/f4a7718b-e753-4b91-86a8-65dd7738a16c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] i2c read block

[William Hermans]

On Fri, Feb 3, 2017 at 3:06 AM, Francis  wrote:

> Hi,
>
> I am trying to create an application on top/based on the i2c tools.
> Everything was working well, except the i2c_smbus_block_process_call(),
> which returns an error when called.
>
> Below is the output of i2cdetect -F:
>
> Functionalities implemented by /dev/i2c-2:
> I2C  yes
> SMBus Quick Command  no
> SMBus Send Byte  yes
> SMBus Receive Byte   yes
> SMBus Write Byte yes
> SMBus Read Byte  yes
> SMBus Write Word yes
> SMBus Read Word  yes
> SMBus Process Call   yes
> SMBus Block Writeyes
> SMBus Block Read no
> SMBus Block Process Call no
> SMBus PECyes
> I2C Block Write  yes
> I2C Block Read   yes
>
> -
>
> Based from it, I could tell that SMBus Process Call is not supported.
> could anyone suggests an alternative or give directions on how to make a
> process call?
>
> Thanks in advance!
>
>
Well the reason why the functionality you mention is not supported should
be obvious from your output above. Block read isn't supported either.
Honestly though, I'm not even sure how the block process call functionality
is even useful. What's the point of writing up to 31 bytes into ONE
register, and reading it back again ?

As far as answering your question goes. Technically you can not duplicate
this functionality. Realistically, you could attempt to use the standard
I2C block read listed above, or just use i2c_smbus_read_byte_data(), and
loop over the whole register set ? Again, I honestly do not get the point
of such a "feature".

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORrsE_qdUB4GC5iQje%3DhojpP7OQ%2BnK7z6Nzxp8KVtPsYAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[William Hermans]

Thanks Drew.

On Tue, Jan 31, 2017 at 9:08 PM, Drew Fustini <pdp7p...@gmail.com> wrote:

> On Tue, Jan 31, 2017 at 9:28 PM, William Hermans <yyrk...@gmail.com>
> wrote:
> > Drew, do you have a complete gist on how you set this all up ? Mark Yoder
> > was interested in the wqep module a while back, but I do not thnk he was
> > able to figure it out completely. Also, from a personal project /
> somethign
> > to tpy with. I'm very interested in the eqep module as well. Or hmm maybe
> > ecap is more of what I'm interested in ?
>
> Here is a gist that I've been keeping notes in:
> https://gist.github.com/pdp7/0df175876304e30e8971c2aadb7493c7
>
> Here is repeating the steps on 4.1, 4.4 and 4.9:
> https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673
>
> For 4.9, I am forcing the eQEP peripheral that I'm using to never
> suspend by changing its power/control file in sysfs to "on" instead of
> "auto".  I still need to figure out the real solution so that the
> tieqep handles suspend and resume properly.
>
> -drew
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/CAEf4M_A%2BD-09JaDaAwTmA7PmEWvFsvmEE-
> Z2V_1N3-Ztc9dWng%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/CALHSORqGrA-_2QKgwBPDAm_V-sU6w2kHkSYkQRg4hYTWTN3i2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[William Hermans]

On Tue, Jan 31, 2017 at 4:47 AM, Drew Fustini  wrote:

> On Mon, Jan 30, 2017 at 8:40 PM, Robert Nelson 
> wrote:
> > Once you enable the power control, it's it acting the same as v4.4.x was?
>
> Yes, it does read position ok.
>
>   # uname -r
>   4.9.6-ti-r17
>
>   # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/
> power/control
>   auto
>   # echo on > /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/
> power/control
>   # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/
> power/control
>   on
>   # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/
> power/runtime_status
>   active
>
>   # config-pin p8.11 qep
>   # config-pin p8.12 qep
>
>   # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
>   -2
>   
>   # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
>   46
>
>
> thanks,
> drew
>

Drew, do you have a complete gist on how you set this all up ? Mark Yoder
was interested in the wqep module a while back, but I do not thnk he was
able to figure it out completely. Also, from a personal project / somethign
to tpy with. I'm very interested in the eqep module as well. Or hmm maybe
ecap is more of what I'm interested in ?

>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/CAPgEAj6P6Zsh%2BfRPtzfA9i%2Bm3O7bTUHq9cNwQYZdbo0GzdX6wA%
> 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/CALHSORrAUBWCnLdngV841DP3j%3D8EZbTEH%2BQCdqjDQtAkokivfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Of SPI and such

[William Hermans]

On Tue, Jan 31, 2017 at 8:08 PM, William Hermans <yyrk...@gmail.com> wrote:

> No way in hell CANBUS is going to keep up with multi channel ADC samples
> at faster sample rates. If one needs fast, or super fast sampling, the only
> real option is going to be SPI.
>

Sorry, I meant to say ethernet here. Was thinking about interfacing and
"exit strategy" at the same time ;)

>
> So using the on die ADC last year I did a bit of a test to see how much
> data really would be written out to "disk" from reading from the ADC's for
> a constant 200ksps over . . . You know I do not remember the time frame,
> but it was for a total of 2M samples I think. 2M samples in text form came
> to a total of about 9M in size on disk, and I seem to recall 2.5M-3M per
> second. Averaged. CanBUS is 1Mbit/second max, which does not even come
> close. Somewhere around 24x too slow. But the point is, if you need a
> serious amount of ADC samples  sent out remotely, the only real option
> would be Ethernet. Which could be as simple as setting up an NFS mount on
> the beaglebone. e.g. the storage is remote, but the beagleobne writes to
> that storage as if it's local, and it's pretty fast. ~10M/s +
>

Additionally, and this relates to my comment above. Technically, the all
out fastest possibility here would be USB. I did manage to achieve ~20M /
second writes a few years ago. Using an externally powered IDE<->USB
enclosure. I also have an enclosure here with a much better controller,
just have not had the time to replace the disk for a good test. The
controller is of the USB 3.0 variant, and should show just how much the USB
2.0 bus on the Beaglebone can handle. *shrug*

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORr3eg4NV%2Brrp3RUqn%2B9d0uuUXca2ZN7sQj04Qk5kwE9GA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBBwireless Wifi disabled with LiPo

[William Hermans]

I have no idea what voltage is required by the wifi module is. But if it
requires more than 3.7v, it won't get it when you're running off the
onboard PMIC battery circuit. So if you need a constant 5v uninterrupted,
you would be better off setting up your own external "UPS" type of system.

On Tue, Jan 31, 2017 at 7:45 AM, Peter Kuskoff  wrote:

> Hi,
> I have an issue when booting from battery on the VIN_BAT. The WIFI_EN
> light never turns on in this case but it does on USB power. It seems like
> the TL1963A Regulator doesn't get any input voltage when on battery. We
> noticed the D2 diode is missing from our boards and it would give power to
> the regulator if it was there, but I am wondering if this was left off for
> a reason, or if there is a better way to fix it? Would it cause problems
> replacing the diode?
> Thanks!
> Peter
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/8ee371cb-2725-4e08-8f4a-8f14ef21f51e%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/CALHSORpC1ty%2BBKBNonM%2B0ipiEgVNGh9LHOnciKbEV1yyAjMQ7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Of SPI and such

[William Hermans]

No way in hell CANBUS is going to keep up with multi channel ADC samples at
faster sample rates. If one needs fast, or super fast sampling, the only
real option is going to be SPI.

So using the on die ADC last year I did a bit of a test to see how much
data really would be written out to "disk" from reading from the ADC's for
a constant 200ksps over . . . You know I do not remember the time frame,
but it was for a total of 2M samples I think. 2M samples in text form came
to a total of about 9M in size on disk, and I seem to recall 2.5M-3M per
second. Averaged. CanBUS is 1Mbit/second max, which does not even come
close. Somewhere around 24x too slow. But the point is, if you need a
serious amount of ADC samples  sent out remotely, the only real option
would be Ethernet. Which could be as simple as setting up an NFS mount on
the beaglebone. e.g. the storage is remote, but the beagleobne writes to
that storage as if it's local, and it's pretty fast. ~10M/s +

On Tue, Jan 31, 2017 at 6:11 AM, mickeyf  wrote:

> If you want one 'thing' to talk to a bunch of 'things', or a bunch of
> 'things' to all talk to each other, you should read up on that mysterious
> CAN stuff. That is exactly what it was designed for.
>
> On Monday, January 30, 2017 at 1:16:41 PM UTC-8, woody stanford wrote:
>>
>> The answer I was looking for. Thank you much Graham. A yes...this is good
>> as now I have control of my BBB UARTS from C (and thus python, etc. etc.)
>>
>> My next question might be an elaboration on how to access the
>> GPIO/SPI/I2C/CAN/ADC however I have the magic key to BBB because I'm lazy
>> and I can just break everything out to external MCU via UART. Clever huh?
>>
>> My PIC's have bad ass multichannel 10-bit ADC, and I do the PWM in
>> software which gives me absolutely perfect wave form control. I can even
>> slow down my motors before stopping them at 20 Mhz on my PIC16Fx. I mean
>> I'm not YouTube needing DMA-driven super streaming capability for my next
>> round of financing. I'm just me.
>>
>> I just want GPS, 9DOF accel/gyro with magnetometer calibration, RS485,
>> MAX232, thermistor, pressure, stepper motor and industrial-strength servo
>> motor control. I don't ask much. Not to mention ganged isolated MOSFET
>> power handling and relay board capability. You know...the usual. :)
>>
>> On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:
>>>
>>> I'm of the opinion that a lot of the terminology being used is being
>>> mixed, slurred, shifted in such a way to make basic concepts difficult to
>>> understand. I thought I would just talk about it.
>>>
>>> What is SPI? You can use the terms UART and SPI interchangably. Bear
>>> with me on this...my point is cultural. SPI is ***serial***, asynchronous
>>> (in that it doesn't require a clock line, it uses timing purely) and 0V
>>> meaning zero and +5V meaning one (TTL). That I suppose you can have SPI use
>>> +3.3V to represent one is acceptable.
>>>
>>> This whole idea about SPI "throwing ioctl errors" is preposterous based
>>> on the previous. SPI is generated by a UART, a chip, a piece of hardware
>>> (that you can code a software UART not withstanding). SPI is the protocol
>>> that is the raw output of a UART.
>>>
>>> I2C is understood to be (1) a protocol that uses a clock signal in
>>> conjunction with a data line, and (2) has something to do with being able
>>> to multiplex several "peripherals" at the same time with allusions to being
>>> the little brother of RS485. And no one really knows what CAN does, only
>>> that it is there and is comforting to know that you can connect as many
>>> things to your CPU as you could possibly conceive. It is a mystery lol.
>>>
>>> That we are being held hostage by electrical engineers and the whole
>>> microcontroller community does in no way change the fact that the BBB is a
>>> true UN*X host. Its just the way that it is.
>>>
>>> Which leads to the inevitable question, why this ambiguity regarding the
>>> correct procedure to configure and utilize the P8 and P9 connectors. This
>>> is a TRIVIAL issue on a microcontroller. You just set the configuration
>>> registers such and communicate. Why this ambiguity on the BBB, whether real
>>> or perceived? I suppose that someone in authority at Beagleboard has to
>>> settle the issue for the prime path to success in using the P8/9
>>> connectors. This ambiguity is killing me. Does libpruio do it? I don't know
>>> :)
>>>
>>> My understanding of it is thus (and I'm sure its inaccurate and I beg
>>> someone to definitively explain it better so that I might understand), that
>>> it is a combination of a systems administration task combined with a
>>> programming task, that both must be done in order to unlock the potent
>>> connectivity powers of the BBB's P8 and P9 headers.That the crux of the
>>> issue is two fold, that I must add some lines to various configuration
>>> files so that it activates the ttyO1 thru ttyO6 "terminals" which 

Re: [beagleboard] Prevent overheating BeagleBone?

[William Hermans]

The DS18B20 is the 1-wire sensor I'm using. I knew that when I initially
connected it, but have not bothered to remember that after looking at the
datasheet . . .too much else going on right now. They're really easy to
read from using C, and C++( one or the other ), and probably any other
language you'd care to use. Doing something similar in C++ I think I did in
less than 75 lines of code, using no special libraries:

root@beaglebone:~# cat /sys/bus/w1/devices/28-*/w1_slave
f2 00 4b 46 7f ff 0e 10 f8 : crc=f8 YES
f2 00 4b 46 7f ff 0e 10 f8 t=15125


On Thu, Jan 26, 2017 at 11:19 PM, William Hermans <yyrk...@gmail.com> wrote:

> HI Drew,
>
> I have not used a thermocouple on the beaglebone it's self. I have however
> used a SPI interface MAX31855, and they ramp up fairly quickly, and are
> reasonably accurate. We used this for a convection oven to reflow oven
> conversion. In testing, it seemed to work really well, but we never
> actually used that oven to flow boards. Instead we decided to change to an
> IR oven.
>
> As far as placement, I think you would want to place the cable end
> directly onto the processor die, with a bit of heat sink grease between
> both.
>
> Another option would be to use a 1-wire temperature sensor. I have one
> here connected to a beaglebone at this moment, but I could not tell you
> offhand what the part number is . . .
>  So it's my understanding that these 1wire sensors in not as accurate as a
> thermocouple. However I think I could work well enough. As far as placement
> of these . . . well I'm not sure about that. A datasheet would need to be
> referenced. But perhaps directly on the processor it's self as well with a
> bit of thermo grease between the two ? Not sure. They're a similar package
> to a small transistor. Additionally, these are rather slow in response. I
> think the best 1-wire query "speed" is 750ms between reads. But I think if
> you need to read temperatures faster than this for this particular
> application .  .something else is "wrong" ;)
>
> ​
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORqKo2HFs1J42UABOOnqwjcnA2dL9g5dj3zM-W0NfR_okg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Prevent overheating BeagleBone?

[William Hermans]

HI Drew,

I have not used a thermocouple on the beaglebone it's self. I have however
used a SPI interface MAX31855, and they ramp up fairly quickly, and are
reasonably accurate. We used this for a convection oven to reflow oven
conversion. In testing, it seemed to work really well, but we never
actually used that oven to flow boards. Instead we decided to change to an
IR oven.

As far as placement, I think you would want to place the cable end directly
onto the processor die, with a bit of heat sink grease between both.

Another option would be to use a 1-wire temperature sensor. I have one here
connected to a beaglebone at this moment, but I could not tell you offhand
what the part number is . . .
 So it's my understanding that these 1wire sensors in not as accurate as a
thermocouple. However I think I could work well enough. As far as placement
of these . . . well I'm not sure about that. A datasheet would need to be
referenced. But perhaps directly on the processor it's self as well with a
bit of thermo grease between the two ? Not sure. They're a similar package
to a small transistor. Additionally, these are rather slow in response. I
think the best 1-wire query "speed" is 750ms between reads. But I think if
you need to read temperatures faster than this for this particular
application .  .something else is "wrong" ;)

​

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORpAO-0p6EykSnmsUvGXNK4q_AYTRvAOJ1yQFbTS0NvZaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Syntax highlighter for pasm in Sublime Text 3

[William Hermans]

On Mon, Jan 23, 2017 at 6:59 PM, Justin Pearson 
wrote:
>
> Thanks William & TJF. Following your advice I wrote my own syntax
> highlighting file for pasm (for Sublime Text 3):
>
> https://github.com/justinpearson/pasm-sublime-text-syntax-highlight
>
> Best,
> Justin

Awesome !

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORpYLXSGu_ONBT0bmOUPgrn3gRxOs%2BobUORnPM-bE76Fqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Filesystem read-only

[William Hermans]

On Mon, Jan 23, 2017 at 3:01 AM, Tarmo Kuuse  wrote:
>
> Actually, that's a relevant question for me too. I got as far as mounting
/tmp and /var as ramdisks and configuring logrotate to aggressively
compress and prune logs (so they don't swamp the RAM). That's not a very
difficult task, e.g. /etc/fstab has these entries:
>
> tmpfs  /vartmpfs  defaults,noatime,nosuid,size=128M  0  0
> tmpfs  /tmp  tmpfs  defaults,noatime,nosuid,size=128M  0  0
>
> And /etc/logrotate.conf needs this:
>
> compress
> compresscmd /bin/bzip2
> uncompresscmd /bin/bunzip2
> compressoptions --best
> compressext .bz2

If you're using a Jessie image. It might actually be worthwhile to look
into creating a service that initializes, and uses a zram ramdisk. Also, I
think, but am not 100% positive that /tmp is already created from a zram
ramdisk- By default. I just can not remember where I got this impression.
Probably form reading through one of the default scripts that run at boot.
Anyway, zram is supposed to be pretty fast, and can offer up to a 2:1
compression ratio.

https://www.kernel.org/doc/Documentation/blockdev/zram.txt

I can say with certainty that is is built into these kernels. As I'm
currently running it on a board right now. I have not experimented with
using for /var though. . .but if you put any files in /tmp, then reboot.
The files, and/or directories will be gone after a restart.

One thing does concern me though . . .
root@beaglebone:~# last -x
debian   pts/0192.168.254.162  Mon Jan 23 02:59   still logged in
  
  reboot   system boot  4.4.12-ti-r31Fri Dec 31 17:01 - 12:14
(6014+19:13)

Anyway, the way I'm using zram is to create a ramdisk at startup through a
service that calls a script to create the ramdisk, and rsync persistent
data back into the ramdisk. Then two more services that call the same
shutdown script. Which rsync's the data back into the persistent directory.
Perfect ? I don't know, I'm still experimenting.

>
> Plus anything needs to be rotated at least weekly, with no more than a
month's worth of compressed logs kept. It seems to keep the entire /var/log
pretty compact (a few MB).
>
> I also installed an SD card and stored all the logs which need to survive
reboots on it. If the SD card dies, I can simply swap it out and the entire
device should still remain functional the whole time.
>
> But then I got stumped. There remain a bunch of files sprinkled around
elsewhere which still need to remain writable. I could only come up with
/etc/resolv.conf at first, but there are probably others. I guess you could
make them readable by symlinking from a read-only root file system to a
file on ramdisk.
>
> I didn't have time to experiment and play around, so I just left root as
RW in the hope that removing logs and temporary files will reduce eMMC load
sufficiently for it to last longer
 than the remainder of the device :)

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORpxCbiTihAiPJK%2BUAf4syEzAhUaShoOmPJqj%2BiD72to5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Devicetree with IoT Images 4.4.36

[William Hermans]

With the 4.x kernels the path has changed to:
/sys/devices/platform/bone_capemgr/slots



On Sun, Jan 22, 2017 at 4:09 AM, Fohnbit  wrote:

> Hello,
>
> I setup a new BBB with the image IoT 4.4.36.
>
> But there I miss the /sys/devices/bone_capemgr.9/slots folder.
>
> I need some Uarts and some inputs/outputs at the GPIO
>
> Is in this firmware different?
>
> Thank you!
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/c2685330-b9cb-4715-941e-d46efa50adfe%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/CALHSORoenFcKjO%2BTu7g%2BkGm_6iQpBg4p50wkfcaidUZ92LRbWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle expertise needed

[William Hermans]

On Sat, Jan 21, 2017 at 6:16 PM, Richard Maurer  wrote:
>
>   BTW, your .service file had the same bug with a small 'i' in Install,
so it would not have worked anyway.

That was not my script, that was your service edited, with all the
unnecessary stuff removed. Copy-pasted.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORrwXcnbj6EAJR_fhxHCOH%3D7NbFdcHnBPsPOgKGFm3yjbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle expertise needed

[William Hermans]

Additionally. "Everything" online hasn't worked out for you yet, Has it ?
I've tested what I've done. It works with:

root@beaglebone:~# uname -r
4.4.38-bone-rt-r14
root@beaglebone:~# cat /etc/dogtag
BeagleBoard.org Debian Image 2016-06-19
root@beaglebone:~# systemctl status log-halt.service
● log-halt.service - Halt logger
   Loaded: loaded (/lib/systemd/system/log-halt.service; enabled; vendor
preset: enabled)
   Active: inactive (dead)
root@beaglebone:~# systemctl status log-reboot.service
● log-reboot.service - Reboot logger
   Loaded: loaded (/lib/systemd/system/log-reboot.service; enabled; vendor
preset: enabled)
   Active: inactive (dead)

Which "logging" system going down is actually a small part of the services.
So again, I know what I said will work for you, because it works for me. It
has to work, otherwise I don't get paid. The only thing I don't know for
your case, is what target you need to hook off of. It could be
network.target, network-online.target, or any other number of network
related target I'm unaware of. It could even be more than one target
simultaneously.

So in the future, do me a favor. I took time out of my life to try and help
you fix your problem. Do me the service of at least doing exactly as I
mentioned, before you try to discredit what I'm saying works. Maybe, that
was intentional, maybe not. I honestly don't care. Because I do not get
paid trying to help you with your problem.

Also, there may even be many ways, or slightly similar ways to do the same
thing. Maybe creating a symbolic file link will work ? But if I'm
instructing someone to do something the way I know how, and they're off in
left field somewhere, complaining that what I'm trying to instruct doesn't
work . . . well at some point, I'm just going to stop caring if they find a
solution or not.


On Sat, Jan 21, 2017 at 5:06 PM, William Hermans <yyrk...@gmail.com> wrote:

> On Sat, Jan 21, 2017 at 5:03 PM, Richard Maurer <maure...@gmail.com>
> wrote:
> >
> > okay, fair enough, although everything on line states to create a
> symlink.  Anyway, I found the error -- if you look at my cut/paste, you'll
> notice {install] -- should be [Install].
> > I was manually copying from my ipad.  Knew it was a bad idea at the time.
> > Thanks
>
> So keep in mind when I say it bugs the s**t out of me when someone says
> they followed my instructions when they fail to duplicate my results.
> Because I test everything, and put that test, and instructions in a text
> file. As it happens, I had just done this yesterday, for a client's 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/CALHSORrQXt9EKZrMzibxs5td-%2Ba85uPYw3FA0Wn2VAsFzC9i-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle expertise needed

[William Hermans]

On Sat, Jan 21, 2017 at 5:03 PM, Richard Maurer  wrote:
>
> okay, fair enough, although everything on line states to create a
symlink.  Anyway, I found the error -- if you look at my cut/paste, you'll
notice {install] -- should be [Install].
> I was manually copying from my ipad.  Knew it was a bad idea at the time.
> Thanks

So keep in mind when I say it bugs the s**t out of me when someone says
they followed my instructions when they fail to duplicate my results.
Because I test everything, and put that test, and instructions in a text
file. As it happens, I had just done this yesterday, for a client's 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/CALHSORpSE35wveMR4OPuRAFp%3DY%2BHnsA4FcdgwGRqTswVyZC_BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle expertise needed

[William Hermans]

On Sat, Jan 21, 2017 at 4:29 PM, Richard Maurer <maure...@gmail.com> wrote:
>
> William Hermans, I can assure you that I started with a simple unit file
nearly exactly as you had offered. Knowing little about Linux, I somewhat
blindly added guesses on additional commands, but with no improvement.  And
just to be sure, I followed your instructions to the tee.  I used,
> ln /lib/systemd/imuout.service imuout.service
> to create the link.  But I had the same result/error message when I
attempt to enable the service.

Except you didn't follow my instructions to the tee.

I gave no such instructions to do this:

> ln /lib/systemd/imuout.service imuout.service
>

The file must physically be located in /lib/systemd/system/. Not a link to
another file, not in a different directory.
/lib/systemd/system/imuout.service

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORobczZSU5PLMbJn_rEyf6Ou3X1%3DihQ-O87-shT-44yn2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle expertise needed

[William Hermans]

You need something like this:

[Unit]
Description=imu output
After=network.target

[Service]
ExecStart=/usr/bin/imuout.sh
Type=oneshot

[install]
WantedBy=network.target

All the rest of that "garbage" is exactly that - Garbage. Your script can
deal with working directory, and not outputting to terminal if that's what
you wish. Then you simply . . .

systemctl daemon-reload
systemctl enable  --now

Making sure that service-name.service exists in /lib/systemd/system/

As far as what target you need, well that I don't know. I have no clue what
an IMU *is* in the context of Nodered, and no idea what you're trying to
do. However, if you need your service to run, and all it requires is a
network to be established. The above should work.



On Sat, Jan 21, 2017 at 1:32 PM, Richard Maurer <maure...@gmail.com> wrote:

> Yup, been all over searches for systemd, and tried different options.
> Here is my current script /lib/systemd/system/imuout.service:
>
> [Unit]
> Description=imu output
> #Wants=network.target
> #After=syslog.target network.target
>
> [Service]
> #Type=simple
> #User=root
> #Group=root
> #Nice=5
> ExecStart=/usr/bin/imuout.sh
> WorkingDirectory=/home/tinkerforge/Example_project/
> StandardOutput=null
>
> [install]
> WantedBy=multi-user.target
> Alias=imuout.service
>
>
>
> with the same error with various options above attempted and commented out
>
>
> On Sat, Jan 21, 2017 at 3:27 PM, William Hermans <yyrk...@gmail.com>
> wrote:
>
>> If you're trying to enable, thus "install" a service with systemctl You
>> need a Wantedby target.
>>
>> But just google: "how to systemd" +  and
>> you'll probably be greated by way more hits than you'll ever need.
>>
>> On Sat, Jan 21, 2017 at 12:40 PM, Richard Maurer <maure...@gmail.com>
>> wrote:
>>
>>> FYI, I ended up implementing the solution exactly as I had hoped -- One
>>> Beagle Green wireless as client, another Beagle hooked via ethernet to an
>>> AP as server, and using Nodered to TCP between the two.  It's working
>>> nearly exactly as I want except that I seem to be unable to establish a
>>> service on the BBG wireless (needed to execute a .py program to run an
>>> IMU.  It's giving me a
>>> The unit files have no installation config (WantedBy, RequiredBy, Also,
>>> Alias
>>> error when I try to enable the service.  Not sure why, as I was able to
>>> enable the Nodered service, using their code and installation guide.  I've
>>> seen a number of recent similar errors that have been reported in bug
>>> reports, so I might be doing the installation correctly, but just can't
>>> figure out what is different in the node-red service.
>>> Anyway thanks for the inputs, offers, and suggestions.
>>>
>>> On Thu, Jan 12, 2017 at 1:35 PM, TJF <jeli.freih...@gmail.com> wrote:
>>>
>>>>
>>>> Am Donnerstag, 12. Januar 2017 18:56:26 UTC+1 schrieb Richard Maurer:
>>>>>
>>>>> So... gotta go with what is easiest for me to understand.
>>>>>
>>>>
>>>> That's why I introduced the ESP solution.
>>>>
>>>> It's plug-and-play when you spend a few further bugs and buy a
>>>> developers board like nodeMCU <https://en.wikipedia.org/wiki/NodeMCU>.
>>>> You plug in the USB, start a terminal and you'll also see what's going on
>>>> with it in the Lua interpreter.
>>>>
>>>> For my engineers mind, this solution will provide faster results. You
>>>> can focus on the necessary features and use a lot of-the-shelf features.
>>>>
>>>> Anyway, it's your decision. Good luck for your project.
>>>>
>>>> --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "BeagleBoard" group.
>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>>> pic/beagleboard/59BZEmeiSIE/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> beagleboard+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/beagleboard/ae0f51f5-5df9-4cb5-96a6-1d72d6f01c38%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/beagleboard/ae0f51f5-5df9-4cb5-96a6-1d72d6f01c38%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> Fo

Re: [beagleboard] Re: Syntax highlighter for pasm in Sublime Text 3

[William Hermans]

You can write your own syntax highlighter for Sublime Text3. I say this,
because I've never seen any assembly language highlighting for Sublime text
period. And yes, I do use Sublime text myself( for the last 4-5 years ).
You might try using C highlighting, to see if the standard C highlighting
also highlights inline assembly. But that's doubtful.

I was looking a while back for something similar, and the only thing I
found was someone on parallax's forum's talking about having writen a
syntax highlighter for Visual Studio Code( not to be confused with the
Visual studio IDE ) and the p2asm language. Maybe It's possible to adapt
that, or in a pinch just use it in code. I've been using VSC myself
recently a lot for javascript, C, and C++. It's not a bad text editor at
all.

On Sat, Jan 21, 2017 at 11:25 AM, TJF  wrote:

> Hi!
>
> I don't know SublimeText and can't help on topic. But in addition to the
> TI configurations, I can provide pasm highlighting for Geany IDE
> , if you're interested.
>
> 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/b9fad1cd-8d55-42d6-96b9-8bd0b48a4417%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/CALHSORoH7KRZYZOMz7OxpiwToprMevi-7%3D%3DJu%2BNdgmvqpbQuSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle expertise needed

[William Hermans]

If you're trying to enable, thus "install" a service with systemctl You
need a Wantedby target.

But just google: "how to systemd" +  and
you'll probably be greated by way more hits than you'll ever need.

On Sat, Jan 21, 2017 at 12:40 PM, Richard Maurer  wrote:

> FYI, I ended up implementing the solution exactly as I had hoped -- One
> Beagle Green wireless as client, another Beagle hooked via ethernet to an
> AP as server, and using Nodered to TCP between the two.  It's working
> nearly exactly as I want except that I seem to be unable to establish a
> service on the BBG wireless (needed to execute a .py program to run an
> IMU.  It's giving me a
> The unit files have no installation config (WantedBy, RequiredBy, Also,
> Alias
> error when I try to enable the service.  Not sure why, as I was able to
> enable the Nodered service, using their code and installation guide.  I've
> seen a number of recent similar errors that have been reported in bug
> reports, so I might be doing the installation correctly, but just can't
> figure out what is different in the node-red service.
> Anyway thanks for the inputs, offers, and suggestions.
>
> On Thu, Jan 12, 2017 at 1:35 PM, TJF  wrote:
>
>>
>> Am Donnerstag, 12. Januar 2017 18:56:26 UTC+1 schrieb Richard Maurer:
>>>
>>> So... gotta go with what is easiest for me to understand.
>>>
>>
>> That's why I introduced the ESP solution.
>>
>> It's plug-and-play when you spend a few further bugs and buy a developers
>> board like nodeMCU . You plug in
>> the USB, start a terminal and you'll also see what's going on with it in
>> the Lua interpreter.
>>
>> For my engineers mind, this solution will provide faster results. You can
>> focus on the necessary features and use a lot of-the-shelf features.
>>
>> Anyway, it's your decision. Good luck for your project.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/beagleboard/59BZEmeiSIE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/beagleboard/ae0f51f5-5df9-4cb5-96a6-1d72d6f01c38%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/CAMYVp3kFTEVCpuxaX1QsftdgJY7VZ2ScVJ%2BpnZxSca4Zzo8-gA%
> 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/CALHSORqYhrGuF6%2B6QAmB9UQizeTB2nFbj5Fm3ghOJQTCN3Hgcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

Awesome. So here is a decent reference for all things USB network related:
http://www.linux-usb.org/usbnet/

Which I had forgotten that using USB-A to USB-A cables is electrically
unsound. E.g. you can destroy USB equipment using these. The cables I was
probably remembering was the USB host-to-host cables mentioned on that
page.

Can't wait for USB3-C "bridge" adapters ;)

On Fri, Jan 20, 2017 at 6:43 PM, Bert Beckmann  wrote:

> SUCCESS!
>
> It works - BBB1 is 192.168.7.2, BBB2 is 192.168.7.3 and I can ssh between
> the two.
>
> :)
>
> Looks like it was Robert's mod plus getting the IP's correctly.
>
> Thanks very much to both of you
>
>
>
>
> On Friday, January 20, 2017 at 4:04:38 PM UTC-7, Bert Beckmann wrote:
>>
>> Is this possible? I see that RP zero and RP 3 can do this. I have tried
>> with no luck so far (mini/otg port on one to full USB on the other) and
>> have searched the internet for an example. I see that the mini ports come
>> up as usb/ethernet/device ports - can they be connect together? Or how to
>> we get the full USB port to act as a host and also act as ethernet device?
>> This would be very useful.
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/a8ddf915-5a0a-46c3-a75e-81a062e05b3b%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/CALHSORodGKvZngFDuMdjpa6FVha0X2H_cVcJmVvK%3DVvbdW3aGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

On Fri, Jan 20, 2017 at 5:30 PM, William Hermans <yyrk...@gmail.com> wrote:

> Bert, So it a distinct possibility you're running into the "wall" that
> Robert mentioned in his first post. The OTG interface in the device tree
> board overlay file is configured in peripheral mode. In order to fix that.
> No you would not need to recompile the kernel( this is one of the great
> things about device tree overlays ), but you would have to edit, and
> recompile the device tree board overlay, move the old one out of the way,
> and replace with the newly created device tree overlay binary. This would
> however only have to be performed on the client (USB mini ) BBB.
>

In fact I would say it is the most likely cause for what you're seeing.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORrD%2Bfd38Fg59F-790h7HcOBbCTmVSmM%2BP2ix_w534iDxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

Bert, So it a distinct possibility you're running into the "wall" that
Robert mentioned in his first post. The OTG interface in the device tree
board overlay file is configured in peripheral mode. In order to fix that.
No you would not need to recompile the kernel( this is one of the great
things about device tree overlays ), but you would have to edit, and
recompile the device tree board overlay, move the old one out of the way,
and replace with the newly created device tree overlay binary. This would
however only have to be performed on the client (USB mini ) BBB.

On Fri, Jan 20, 2017 at 5:26 PM, William Hermans <yyrk...@gmail.com> wrote:

> On Fri, Jan 20, 2017 at 5:20 PM, Bert Beckmann <bertb...@gmail.com> wrote:
> >
> > using ethernet would be simpler but we need the ethernet ports on each
> BBB for another purpose (isolated networks).
> >
> > I think this will work - the host side of things seems to be behaving
> properly, the client is not and maybe that's what Robert's change is for.
> >
> > This approach also will make for an interesting BBB cluster when the
> SanCloud EBBB is back on the market and we can USB network 4 BBB's (1 EBBB
> + 3 regular BBB's) with no ethernet switch or hub.
> >
>
> Well the good news is that if this does not work out, you can purchase two
> USB to ethernet adapters, which should be natively supported ( drivers
> already included in the kernel, assuming they were not compiled out ).
> Which is to say, I know they exist, I've seen them used, but I've never
> used them personally. So you would or should do your own homework on that,
> if and when it comes to that. To make sure they will in fact work. I've
> been told however, they work pretty good. But again, no personal hands on.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORqjRxnVCBF81OMZZ4vsPbc1p04g0wnh8Rpy4cnGktRzTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

On Fri, Jan 20, 2017 at 5:20 PM, Bert Beckmann  wrote:
>
> using ethernet would be simpler but we need the ethernet ports on each
BBB for another purpose (isolated networks).
>
> I think this will work - the host side of things seems to be behaving
properly, the client is not and maybe that's what Robert's change is for.
>
> This approach also will make for an interesting BBB cluster when the
SanCloud EBBB is back on the market and we can USB network 4 BBB's (1 EBBB
+ 3 regular BBB's) with no ethernet switch or hub.
>

Well the good news is that if this does not work out, you can purchase two
USB to ethernet adapters, which should be natively supported ( drivers
already included in the kernel, assuming they were not compiled out ).
Which is to say, I know they exist, I've seen them used, but I've never
used them personally. So you would or should do your own homework on that,
if and when it comes to that. To make sure they will in fact work. I've
been told however, they work pretty good. But again, no personal hands on.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORqs31vgPo6fZ0bdQVTxhV%2Bb662Pz8_6MUX4RFiHOaFSWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

Mask:255.255.255.252

^^ Will be a problem.

This mask means you have the ability to use 3 address, of which one is
reserved for the broadcast "IP" Which is not usable by an interface.
192.168.7.0. Which, I'm not a network guru, and I could be remembering
incorrectly. You could try loosing that last field from 252 to 251m and see
if that works.

In an attempt to fix your multiple USB interfaces on the first BBB try to
disable the generic start up service temporarily. This can be done by
issuing the command:

systemctl disable generic-board-startup.service

With elevated commands. reboot the board, and try again. If neither
interface comes up after a reboot, then you can reenable the service by
running:

systemctl enable generic-board-startup.service

On Fri, Jan 20, 2017 at 5:12 PM, Bert Beckmann  wrote:

> so close!
>
> without any kernel changes - I am now seeing usb0 and usb1 in ifconfig on
> BBB1 when I connect the 2nd BBB to the first (mini to full).
> I assign IP's - I gave 192.168.7.1 to the 2nd BBB.
> Maybe netmask / ip #'s are causing problems - will try using .2 and .3
> with mask of 255.255.255.0
>
> what happens now --- if I ssh to 192.168.7.1 expecting to see my 2nd BBB,
> I get connected to the BBB I am running on.
> so so close!
>
> ah - however - now on the 2nd BBB - no usb0 device shows up. That explains
> a little. When the cable is connected, the 2nd BBB drops it's usb0
> definition. The 1st BBB get's usb1 added though.
>
> Maybe Robert's mod is needed.
>
> Here are the ifconfigs:
>
> BBB1:
>
> root@rib2bbb-08977:~# ifconfig -a
>
> eth0  Link encap:Ethernet  HWaddr 80:30:dc:91:16:b5
>
>   inet addr:172.28.0.120  Bcast:172.28.0.255  Mask:255.255.255.0
>
>   inet6 addr: fe80::8230:dcff:fe91:16b5/64 Scope:Link
>
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>
>   RX packets:7500 errors:0 dropped:0 overruns:0 frame:0
>
>   TX packets:1464 errors:0 dropped:0 overruns:0 carrier:0
>
>   collisions:0 txqueuelen:1000
>
>   RX bytes:806150 (787.2 KiB)  TX bytes:163855 (160.0 KiB)
>
>   Interrupt:175
>
>
> loLink encap:Local Loopback
>
>   inet addr:127.0.0.1  Mask:255.0.0.0
>
>   inet6 addr: ::1/128 Scope:Host
>
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>
>   RX packets:415 errors:0 dropped:0 overruns:0 frame:0
>
>   TX packets:415 errors:0 dropped:0 overruns:0 carrier:0
>
>   collisions:0 txqueuelen:1
>
>   RX bytes:41928 (40.9 KiB)  TX bytes:41928 (40.9 KiB)
>
>
> usb0  Link encap:Ethernet  HWaddr 3a:a6:6d:9c:15:2d
>
>   inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
>
>   inet6 addr: fe80::38a6:6dff:fe9c:152d/64 Scope:Link
>
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>
>   TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
>
>   collisions:0 txqueuelen:1000
>
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
>
> usb1  Link encap:Ethernet  HWaddr 9a:2a:76:42:c0:87
>
>   inet addr:192.168.7.1  Bcast:192.168.7.3  Mask:255.255.255.252
>
>   inet6 addr: fe80::982a:76ff:fe42:c087/64 Scope:Link
>
>   UP BROADCAST MULTICAST  MTU:1500  Metric:1
>
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>
>   TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
>
>   collisions:0 txqueuelen:1000
>
>   RX bytes:0 (0.0 B)  TX bytes:90 (90.0 B)
> BBB2:
> root@rib2bbb-1:~# ifconfig
> eth0  Link encap:Ethernet  HWaddr 68:c9:0b:ee:66:c4
>   UP BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>   Interrupt:175
>
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>   RX packets:452 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:452 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1
>   RX bytes:36528 (35.6 KiB)  TX bytes:36528 (35.6 KiB)
>
>
> On Friday, January 20, 2017 at 4:04:38 PM UTC-7, Bert Beckmann wrote:
>>
>> Is this possible? I see that RP zero and RP 3 can do this. I have tried
>> with no luck so far (mini/otg port on one to full USB on the other) and
>> have searched the internet for an example. I see that the mini ports come
>> up as usb/ethernet/device ports - can they be connect together? Or how to
>> we get the full USB port to act as a host and also act as ethernet device?
>> This would be very useful.
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are 

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

Honestly, it would be much simpler to just connect the two board together
via an ethernet cross over cable if possible. Or, if you have other ideas
for the erthernet ports, and you're comm traffic is light, You could
purchase a 3v3 TTL serial to USB cable, and communicate between the two
over serial.

On Fri, Jan 20, 2017 at 5:01 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Fri, Jan 20, 2017 at 4:41 PM, Bert Beckmann <bertb...@gmail.com> wrote:
> >
> > thanks for the quick replies
> >
> > so I need to rebuild the kernel in order to change 'dr_mode' to 'otg'?
>   (it would be much more useful if we didn't have to do this)
> >
> > when I boot as is - usb0 comes up ready to network - wouldn't that mean
> it's already setup as otg ?
> > usb0 Link encap:Ethernet HWaddr  22:87:1a:2a:80:6a
> >
> > If I do this - do I connect usb mini to usb mini ? or mini to full size
> usb as I've been doing ?
> >
> > also - why don't I usb0 or usb1 in /dev? I do see /dev/bus/usb/001 and
> then /dev/buf/usb/002 when I plug in the 2nd BBB to the full size USB on
> the first. I assume somewhere I have to assign an ip?
> > it seems like usb0 and usb1 exist but not as I'd expect
> >
> > Bert
>
> So, you would connect these boards just like you would connect a
> beaglebone to a PC. The "client" would be connected to the USB mini, while
> the "host" would be connected to the full sized USB port. There is a catch
> here however. The "host" Beaglebone would have to be power by the barrel
> jack, or through the P9 header with probably a 2A power supply - To be
> safe. This is because the "client" will probably want to power it's self
> over the USB port. Additionally, if you're going to run more than just the
> basic hardware on the client. You're going to need more than 500mA where,
> I'm not sure how it works when you have both USB and the barrel jack
> plugged in at the same time.
>
> As far as configuring the interface for networking. I always hard coded
> this myself in /etc/network/interfaces like so:
>
> PC side:
> william@eee-pc:~$ tail /etc/network/interfaces
> auto usb0
> allow-hotplug usb0
> iface usb0 inet static
> address 192.168.7.1
> netmask 255.255.255.0
> network 192.168.7.0
> gateway 192.168.7.1
>
> Then the beaglebone "client" side(USB mini) would be the same, except the
> "address" would be 192.168.7.2. Configured this way, there is no need for a
> DHCP server on either end.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORobPhdGKjgmQa-0xbmJ%2BGY35m8h25%3Dc1sLCB352WRvb8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

On Fri, Jan 20, 2017 at 4:41 PM, Bert Beckmann  wrote:
>
> thanks for the quick replies
>
> so I need to rebuild the kernel in order to change 'dr_mode' to 'otg'?
  (it would be much more useful if we didn't have to do this)
>
> when I boot as is - usb0 comes up ready to network - wouldn't that mean
it's already setup as otg ?
> usb0 Link encap:Ethernet HWaddr  22:87:1a:2a:80:6a
>
> If I do this - do I connect usb mini to usb mini ? or mini to full size
usb as I've been doing ?
>
> also - why don't I usb0 or usb1 in /dev? I do see /dev/bus/usb/001 and
then /dev/buf/usb/002 when I plug in the 2nd BBB to the full size USB on
the first. I assume somewhere I have to assign an ip?
> it seems like usb0 and usb1 exist but not as I'd expect
>
> Bert

So, you would connect these boards just like you would connect a beaglebone
to a PC. The "client" would be connected to the USB mini, while the "host"
would be connected to the full sized USB port. There is a catch here
however. The "host" Beaglebone would have to be power by the barrel jack,
or through the P9 header with probably a 2A power supply - To be safe. This
is because the "client" will probably want to power it's self over the USB
port. Additionally, if you're going to run more than just the basic
hardware on the client. You're going to need more than 500mA where, I'm not
sure how it works when you have both USB and the barrel jack plugged in at
the same time.

As far as configuring the interface for networking. I always hard coded
this myself in /etc/network/interfaces like so:

PC side:
william@eee-pc:~$ tail /etc/network/interfaces
auto usb0
allow-hotplug usb0
iface usb0 inet static
address 192.168.7.1
netmask 255.255.255.0
network 192.168.7.0
gateway 192.168.7.1

Then the beaglebone "client" side(USB mini) would be the same, except the
"address" would be 192.168.7.2. Configured this way, there is no need for a
DHCP server on either end.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORqVfNV5PuzYy2fC7qr%2BA4sTmnr0k10OqYST-x34cTF5Pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

Bert,

Show us the output of the command:

*root@beaglebone:~#* ifconfig -a



On Fri, Jan 20, 2017 at 4:41 PM, Bert Beckmann  wrote:

> thanks for the quick replies
>
> so I need to rebuild the kernel in order to change 'dr_mode' to 'otg'?
>   (it would be much more useful if we didn't have to do this)
>
> when I boot as is - usb0 comes up ready to network - wouldn't that mean
> it's already setup as otg ?
> usb0 Link encap:Ethernet HWaddr  22:87:1a:2a:80:6a
>
> If I do this - do I connect usb mini to usb mini ? or mini to full size
> usb as I've been doing ?
>
> also - why don't I usb0 or usb1 in /dev? I do see /dev/bus/usb/001 and
> then /dev/buf/usb/002 when I plug in the 2nd BBB to the full size USB on
> the first. I assume somewhere I have to assign an ip?
> it seems like usb0 and usb1 exist but not as I'd expect
>
> Bert
>
> On Friday, January 20, 2017 at 4:04:38 PM UTC-7, Bert Beckmann wrote:
>>
>> Is this possible? I see that RP zero and RP 3 can do this. I have tried
>> with no luck so far (mini/otg port on one to full USB on the other) and
>> have searched the internet for an example. I see that the mini ports come
>> up as usb/ethernet/device ports - can they be connect together? Or how to
>> we get the full USB port to act as a host and also act as ethernet device?
>> This would be very useful.
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/8be4b8ee-bd5f-484f-8ce4-f170ca53346b%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/CALHSORo2qSZT7u5fUomYV%3Dpoo3ibiaerughFC7k-FJww603BgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

On Fri, Jan 20, 2017 at 4:20 PM, Robert Nelson 
wrote:
>
> The whole musb/otg setup is just weird..
>
> I revisited this again last week on the xM, when setting up a
> production tester..
>
> To use the port as a host, and plug in a (usb flash drive for
> example), you need to modprobe one of the gadget drivers (g_ether for
> example)..  then the usb port also comes alive and detects the usb
> flash disk..
>
> A trick I use to do on the xM, just build-in the g_ether driver, while
> you then can't change it later while running, the usb host port always
> on kernel bootup..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/

I did some research on this a while back, because I thought it would be
really cool connecting a USB-A cable between two regular computers as a way
to get a peer to peer networking happening. When I read that in order for
this to work, one side *has* to be OTG. Which you kindly pointed out in the
generic board overlay include isn't configured. By default. But anyway, my
point on that is that it's not really an musb / otg issue. But something
that's expected for any g_ether network to function.

If I had the time, I'd dive into the problem full tilt, and see what I
could do to work around that. As far as trying to use peer to peer USN
networking without having to use at least one OTG interface. Which from
what I've read isn't possible, but perhaps I could find a work around. So
for now,  like many other potential projects I have in mind . . .back
burner.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORpeoz-8yR3L0uLS9cku-bUdD7jU8NtpHzTvCd21aBW7NQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

Something that does come to mind is that there is a service that runs a set
of "generic" scripts at boot. One of these scripts does attempt to run
g_ether , or perhaps g_multi on the USB OTG interface. This kernel module I
believe is not the same as the as the host kernel module that would have to
run on the host board. It's been a while since I've messed with all this
though . . .

On Fri, Jan 20, 2017 at 4:10 PM, William Hermans <yyrk...@gmail.com> wrote:

> This should just work. However, you should be aware this technically is
> not peer to peer OTG. This is one OTG to host USB. Anyway, this should be
> no different than connecting a beaglebone to an x86 PC. With the obvious
> architecture difference as an exception. When you have both connected
> together what does lsusb tell you ?
>
> On Fri, Jan 20, 2017 at 3:15 PM, Bert Beckmann <bertb...@gmail.com> wrote:
>
>> Is this possible? I see that RP zero and RP 3 can do this. I have tried
>> with no luck so far (mini/otg port on one to full USB on the other) and
>> have searched the internet for an example. I see that the mini ports come
>> up as usb/ethernet/device ports - can they be connect together? Or how to
>> we get the full USB port to act as a host and also act as ethernet device?
>> This would be very useful.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving 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/916e44f5-1ea7-4f12-8a79-8919e3084215%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/916e44f5-1ea7-4f12-8a79-8919e3084215%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/CALHSORroZVwmtRZp3kzPQCStiLEBif6bkPpHTVJWWmJxHG4wtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

[William Hermans]

This should just work. However, you should be aware this technically is not
peer to peer OTG. This is one OTG to host USB. Anyway, this should be no
different than connecting a beaglebone to an x86 PC. With the obvious
architecture difference as an exception. When you have both connected
together what does lsusb tell you ?

On Fri, Jan 20, 2017 at 3:15 PM, Bert Beckmann  wrote:

> Is this possible? I see that RP zero and RP 3 can do this. I have tried
> with no luck so far (mini/otg port on one to full USB on the other) and
> have searched the internet for an example. I see that the mini ports come
> up as usb/ethernet/device ports - can they be connect together? Or how to
> we get the full USB port to act as a host and also act as ethernet device?
> This would be very useful.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/916e44f5-1ea7-4f12-8a79-8919e3084215%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/CALHSORrF%3D%2BVJcdVFy%3D2oAdVRV3DWyPWxQ8ot9MwQop60KKXjLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI Woes with different Kernel Versions

[William Hermans]

>
> Now I can use the board with its user space software (no kernel driver
> whatsoever involved).
> The setup *works* with 3.8 and 4.1 kernels but *not* with 4.4 and 4.9.
> Below I have the output of
>

So maybe if you're a bit more verbose with what you mean by "it doesn't
work". What you're trying to do, what you've done to get there, and how you
know it's not working.

You should also be aware, that you are in fact using a kernel module if
you're loading the stock device tree files. You just may not be aware of
it. As all of the most recent Debian image will boot up, with the SPI
kernel module loaded automatically. Which is actually annoying if you do
not want, or need it running. Since it takes a "fakeinstall" to keep it
from loading automatically.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORpr7QKi4pgO7OAHHasxAaPadCpj%3DZyvFfqBo1i_21C3ig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI Woes with different Kernel Versions

[William Hermans]

Thomas,

I don't rightly know. I've done plenty of bare metal SPI, or enough of it
anyway. The only thing I've done with SPI on the beaglebone, is a lot of
reading. No actual hands on, Honestly I'm not sure if the edma fix would
work for your situation or not. I think the edma fix was more or less to
make the SPI modules usable. Something about the kernel modules having to
be loaded at boot, otherwise edma got in the way somehow I *THINK*

On Thu, Jan 19, 2017 at 2:50 PM, Robert Nelson 
wrote:

> On Thu, Jan 19, 2017 at 3:43 PM, Thomas Hoppe 
> wrote:
> > Maybe there was a misunderstanding, I do have the SPI devices with all
> the
> > kernels I mention!
> > And that is because I have the lines on the bottom in uEnv.txt. So again
> the
> > existence of the devices is not my problem,
> > it just does not work. Do you think the patch you mention can be the
> reason
> > for that?
>
> SPI/SPIDEV has always been picky between kernel releases.
>
> I'll take a look at it again..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CAOCHtYidraFhheOkwRHeLWsVM9wWXwNM8HZMKtMBo%3DWPwADLVw%
> 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%3DtWHbQfATOky3H3T-dyOH5%2B8kqx%2B0nWMVgRTzzX1-iA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Which script allocates /var/swap.img on second boot?

[William Hermans]

On Thu, Jan 19, 2017 at 7:44 AM, Robert Nelson 
wrote:
>
>
> Me too...
>
> It's definitely not something i added to the default images by default..
>
> Are you sure you didn't enable it yourself?
>
> (doesn't even run swap on my debian x86 development machine)
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/

Is this possibly related to zram ? I noticed that zram is in the kernel I
use. While not strictly speaking *only* for swap disks in memory. Many seem
to relate zram to doubling their memory by running a compressed swap disk
in RAM.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORru-UGHxwBz3hq9%2B0bwpniv1tWnRLcNAwkDUQ6JiMVF4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB SPI throwing ioctl errors

[William Hermans]

>
> I also noticed that now (with the new kernel) I had to remove cs_change =
> 1 from the spi_ioc_transfer struct or else CS would stay low the whole time
> (between messages).
>
> Anyway, should I revert to 3.* or does anyone know what's going on?
>

I'm not familiar with SPI code on embedded Linux, but I have written a bit
for bare metal devices. What you're describing here almost sounds like
cs_change = 1 is behaving like a mechanism for toggling the CS bit.

Here is something to keep in mind. kernel 3.8.x in the context of the
beaglebone is a fairly old kernel. It's noticeably slower to me( less
responsive ), it's going to have less features than 4.x.

Anyway:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am33xx-overlay-edma-fix.dtsi

What this overlay does is enable SPI at boot through the main board file
overlay. I'm not sure why this is supposed to fix the problem, but
supposedly it does. This overlay is meant to be #include(ed) in the main
board file overlay that gets loaded at boot. Like so:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack.dts#L12-Lundefined

But you'll notice that it's disabled in this board file, and probably all(
by default ). You can try uncommenting this in the given board file you're
using, and then giving it a shot.
 Will it work ? I'm not sure, but it's a good place to start.

How would you do this ? Well you would git pull this repo, Find the source
for the board file you're using. Edit the source appropriately(uncomment
the line I mentioned ). then from the root directory of this repo run make,
then make install. Also, if you're familiar with make files, and you read
the makefile for this project. You'll notice there is the possibility to
make, and install a single overlay.

Something you should be aware of. Occasionally I've had this whole
procedure lock my own beaglebone at boot. I'm not 100% sure why, but I
suspect this problem was because of a kernel to overlay version mismatch.
How I personally resolved this problem for myself. Was to make a copy of
the board overlay file I needed. Decompile it with dtc, make my changes to
the output file. Then recompile the source with these changes in place.
Finally, move the "old" overlay out of the way, and replace with the newly
recompiled overlay binary.

On Thu, Jan 19, 2017 at 7:19 AM, William Hermans <yyrk...@gmail.com> wrote:

> It's not your code, that should be obvious when it work in 3.8.x kernels,
> and not so well on 4.x.
>
> But the first thing that pops into my mind is that this is related to DMA.
> However about pasting a full output of the error messages you're getting.
>
> On Thu, Jan 19, 2017 at 3:41 AM, Gregor Steiner <gluasto...@gmail.com>
> wrote:
>
>> Hi,
>>
>> about two years ago I was running the old 3.* kernel and SPI worked fine
>> for what I was doing.
>> I updated to Debian 8.6 / 4.4.40-ti-r80 but now the same unchanged code
>> throws odd errors that I can't figure out on my own.
>>
>> Here is how I'm writing out via SPI (16 bpw, mode 2)
>>
>> struct spi_ioc_transfer info =
>> {
>> .tx_buf = (unsigned long)wbuf,
>> .len = length,
>> };
>>
>> int ret = ioctl(fd, SPI_IOC_MESSAGE(1), );
>> if (ret < 1)
>> {
>> printf("error: %s\n", strerror(ret));
>> return 0;
>> }
>>
>> The size of wbuf usually ranges from 10 bytes to 1 bytes.
>> It will print "error: Unknown error -1" which does not leave me with much.
>>
>> I also noticed that now (with the new kernel) I had to remove cs_change =
>> 1 from the spi_ioc_transfer struct or else CS would stay low the whole time
>> (between messages).
>>
>> Anyway, should I revert to 3.* or does anyone know what's going on?
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving 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/d73c231c-5d89-4e18-94a7-30b0cf5dc744%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/d73c231c-5d89-4e18-94a7-30b0cf5dc744%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/CALHSORovj-V%2B7NdsW8PSPamiJpqA3zSny6vKh8JQzptqM2pciQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Which script allocates /var/swap.img on second boot?

[William Hermans]

By the way, if you use USB networking. Don't disable this service, and
don't move, or delete any of the scripts in /opt/scripts/boot

On Thu, Jan 19, 2017 at 7:12 AM, William Hermans <yyrk...@gmail.com> wrote:

> So . . .
>
> root@beaglebone:~# systemctl status generic-board-startup.service
> ● generic-board-startup.service - Generic Board Startup
>Loaded: loaded (/lib/systemd/system/generic-board-startup.service;
> disabled; vendor preset: enabled)
>Active: inactive (dead)
>
> This service is responsible for starting up the scripts in
> /opt/scripts/boot. Personally, I disable it because it loads things I don't
> want running. I do believe that one of the scripts in /opt/scripts/boot
> "mentions" swap. So you can start by looking through those.
>
> On Thu, Jan 19, 2017 at 5:14 AM, Tarmo Kuuse <tarmo.ku...@gmail.com>
> wrote:
>
>> Hi!
>>
>> I flashed an rcn-ee image into eMMC 
>> (bone-debian-8.7-seeed-iot-armhf-2017-01-15-4gb.img.xz).
>> On first boot there's no swap anywhere.
>>
>> On second boot something allocates /var/swap.img and installs it as swap
>> in fstab. This seems to happen right after the root filesystem is
>> remounted. dmesg says:
>>
>> [   31.270174] EXT4-fs (mmcblk1p1): re-mounted. Opts: errors=remount-ro
>> [   31.717598] Adding 262140k swap on /var/swap.img.  Priority:-1
>> extents:10 across:745468k SSFS
>>
>> I'd really like to snip that. Any hints where to look?
>>
>> --
>> Kind regards,
>> Tarmo Kuuse
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving 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/407e8b17-78dc-407e-94cf-106e56098a37%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/407e8b17-78dc-407e-94cf-106e56098a37%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/CALHSORr%3D4ZbR5RLbaJP7rJEZmsTwmDuUUF0G72F%3DXti9d6PhPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB SPI throwing ioctl errors

[William Hermans]

It's not your code, that should be obvious when it work in 3.8.x kernels,
and not so well on 4.x.

But the first thing that pops into my mind is that this is related to DMA.
However about pasting a full output of the error messages you're getting.

On Thu, Jan 19, 2017 at 3:41 AM, Gregor Steiner 
wrote:

> Hi,
>
> about two years ago I was running the old 3.* kernel and SPI worked fine
> for what I was doing.
> I updated to Debian 8.6 / 4.4.40-ti-r80 but now the same unchanged code
> throws odd errors that I can't figure out on my own.
>
> Here is how I'm writing out via SPI (16 bpw, mode 2)
>
> struct spi_ioc_transfer info =
> {
> .tx_buf = (unsigned long)wbuf,
> .len = length,
> };
>
> int ret = ioctl(fd, SPI_IOC_MESSAGE(1), );
> if (ret < 1)
> {
> printf("error: %s\n", strerror(ret));
> return 0;
> }
>
> The size of wbuf usually ranges from 10 bytes to 1 bytes.
> It will print "error: Unknown error -1" which does not leave me with much.
>
> I also noticed that now (with the new kernel) I had to remove cs_change =
> 1 from the spi_ioc_transfer struct or else CS would stay low the whole time
> (between messages).
>
> Anyway, should I revert to 3.* or does anyone know what's going on?
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/d73c231c-5d89-4e18-94a7-30b0cf5dc744%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/CALHSORqhM-A-fB47pAAzEF47tdkaP_bvj_7Sua5HGaTezKyZvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Which script allocates /var/swap.img on second boot?

[William Hermans]

So . . .

root@beaglebone:~# systemctl status generic-board-startup.service
● generic-board-startup.service - Generic Board Startup
   Loaded: loaded (/lib/systemd/system/generic-board-startup.service;
disabled; vendor preset: enabled)
   Active: inactive (dead)

This service is responsible for starting up the scripts in
/opt/scripts/boot. Personally, I disable it because it loads things I don't
want running. I do believe that one of the scripts in /opt/scripts/boot
"mentions" swap. So you can start by looking through those.

On Thu, Jan 19, 2017 at 5:14 AM, Tarmo Kuuse  wrote:

> Hi!
>
> I flashed an rcn-ee image into eMMC 
> (bone-debian-8.7-seeed-iot-armhf-2017-01-15-4gb.img.xz).
> On first boot there's no swap anywhere.
>
> On second boot something allocates /var/swap.img and installs it as swap
> in fstab. This seems to happen right after the root filesystem is
> remounted. dmesg says:
>
> [   31.270174] EXT4-fs (mmcblk1p1): re-mounted. Opts: errors=remount-ro
> [   31.717598] Adding 262140k swap on /var/swap.img.  Priority:-1
> extents:10 across:745468k SSFS
>
> I'd really like to snip that. Any hints where to look?
>
> --
> Kind regards,
> Tarmo Kuuse
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/407e8b17-78dc-407e-94cf-106e56098a37%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/CALHSORrt7%2B%3DemWhxoowuyGQ1eqC5jAiLNjXu%3DoG6hrYmRX%2ByYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[William Hermans]

So I stopped what I was doing and did some testing. It seems as though the
current iteration of capemgr has a problem loading more than two overlays
at boot, through the cmdline parameter. Both of the "custom" overlays have
been injected into the initramfs via the script update_initrd.sh.

Worklog and testing output:
http://pastebin.com/YkHnZ4f2

On Wed, Jan 18, 2017 at 1:57 PM, William Hermans <yyrk...@gmail.com> wrote:

> Yet more information I noticed, sorry for the multiple posts . . . But
> notice how the custom cape is attempted to load first, but the actual
> overlay id is dead last. It's almost as though capemgr is trying to load
> them simultaneously but the ADC overlay being smaller in size won out ?
>
> root@beaglebone:~# dmesg |grep bone_capemgr
> [0.00] Kernel command line: console=ttyO0,115200n8
> bone_capemgr.enable_partno=controller,BB-ADC,BB-W1-P8.26
> root=UUID=826386f9-a359-428a-a111-486cd84f92b5 ro rootfstype=ext4
> rootwait coherent_pool=1M quiet ipv6.disable=1
> [4.252789] bone_capemgr bone_capemgr: Baseboard:
> 'A335BNLT,00C0,3214BBBK0403'
> [4.252815] bone_capemgr bone_capemgr: 
> compatible-baseboard=ti,beaglebone-black
> - #slots=4
> [4.305592] bone_capemgr bone_capemgr: slot #0: No cape found
> [4.365587] bone_capemgr bone_capemgr: slot #1: No cape found
> [4.425586] bone_capemgr bone_capemgr: slot #2: No cape found
> [4.485586] bone_capemgr bone_capemgr: slot #3: No cape found
> [4.491376] bone_capemgr bone_capemgr: enabled_partno PARTNO
> 'controller' VER 'N/A' PR '0'
> [4.491388] bone_capemgr bone_capemgr: slot #4: override
> [4.491401] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 4
> [4.491415] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,controller'
> [4.491498] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-ADC'
> VER 'N/A' PR '0'
> [4.491509] bone_capemgr bone_capemgr: slot #5: override
> [4.491520] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 5
> [4.491533] bone_capemgr bone_capemgr: slot #5: 'Override Board
> Name,00A0,Override Manuf,BB-ADC'
> [4.491602] bone_capemgr bone_capemgr: enabled_partno PARTNO
> 'BB-W1-P8.26' VER 'N/A' PR '0'
> [4.491613] bone_capemgr bone_capemgr: slot #6: override
> [4.491624] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 6
> [4.491637] bone_capemgr bone_capemgr: slot #6: 'Override Board
> Name,00A0,Override Manuf,BB-W1-P8.26'
> [4.492070] bone_capemgr bone_capemgr: initialized OK.
> [4.503689] bone_capemgr bone_capemgr: slot #5: dtbo 'BB-ADC-00A0.dtbo'
> loaded; overlay id #0
> [4.505152] bone_capemgr bone_capemgr: slot #6: dtbo
> 'BB-W1-P8.26-00A0.dtbo' loaded; overlay id #1
> [    4.540874] bone_capemgr bone_capemgr: slot #4: dtbo
> 'controller-00A0.dtbo' loaded; overlay id #2
>
>
> On Wed, Jan 18, 2017 at 1:49 PM, William Hermans <yyrk...@gmail.com>
> wrote:
>
>> Just for informational purposes here is that one pin in my custom overlay:
>>
>> . . .
>>> exclusive-use =
>>> /* the pin header uses */
>>> "P8.11",
>>> . . .
>>> /* P8_11 (ZCZ ball R12) */
>>> P8_11_default_pin: pinmux_P8_11_default_pin {
>>> pinctrl-single,pins = <0x034  0x27>; }; /* Mode 7,
>>> Pull-Down, RxActive */
>>> . . .
>>> fragment@1 {
>>> target = <>;
>>> __overlay__ {
>>>
>>> P8_11_pinmux {
>>> compatible = "bone-pinmux-helper";
>>> status = "okay";
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_11_default_pin>;
>>> };
>>> . . .
>>>
>>> P8_11 {
>>> gpio-name = "P8_11";
>>> gpio = < 13 0>;
>>> input;
>>> dir-changeable;
>>> };
>>> . . .
>>
>>
>> Then the P8.26 1-wire overlay is exactly the same as the one example
>> 1-wire overlay included with the stock image. But I changed the pin
>> configuration to match P8.26 instead of what was it ? P9.12 was it ? No
>> idea why I'm getting that boot message, and this is the first time I've
>> ever seen it.
>>
>> On Wed, Jan 18, 2017 at 1:39 PM, William Hermans <yyrk...@gmail.com>
>> wrote:
>>
>>> The error I noticed on my end was: *libfdt fdt_check_header():
>>> FDT_ERR_BADMAGIC* Which d

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

[William Hermans]

Yet more information I noticed, sorry for the multiple posts . . . But
notice how the custom cape is attempted to load first, but the actual
overlay id is dead last. It's almost as though capemgr is trying to load
them simultaneously but the ADC overlay being smaller in size won out ?

root@beaglebone:~# dmesg |grep bone_capemgr
[0.00] Kernel command line: console=ttyO0,115200n8
bone_capemgr.enable_partno=controller,BB-ADC,BB-W1-P8.26
root=UUID=826386f9-a359-428a-a111-486cd84f92b5 ro rootfstype=ext4 rootwait
coherent_pool=1M quiet ipv6.disable=1
[4.252789] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,3214BBBK0403'
[4.252815] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[4.305592] bone_capemgr bone_capemgr: slot #0: No cape found
[4.365587] bone_capemgr bone_capemgr: slot #1: No cape found
[4.425586] bone_capemgr bone_capemgr: slot #2: No cape found
[4.485586] bone_capemgr bone_capemgr: slot #3: No cape found
[4.491376] bone_capemgr bone_capemgr: enabled_partno PARTNO
'controller' VER 'N/A' PR '0'
[4.491388] bone_capemgr bone_capemgr: slot #4: override
[4.491401] bone_capemgr bone_capemgr: Using override eeprom data at
slot 4
[4.491415] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,controller'
[4.491498] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-ADC'
VER 'N/A' PR '0'
[4.491509] bone_capemgr bone_capemgr: slot #5: override
[4.491520] bone_capemgr bone_capemgr: Using override eeprom data at
slot 5
[4.491533] bone_capemgr bone_capemgr: slot #5: 'Override Board
Name,00A0,Override Manuf,BB-ADC'
[4.491602] bone_capemgr bone_capemgr: enabled_partno PARTNO
'BB-W1-P8.26' VER 'N/A' PR '0'
[4.491613] bone_capemgr bone_capemgr: slot #6: override
[4.491624] bone_capemgr bone_capemgr: Using override eeprom data at
slot 6
[4.491637] bone_capemgr bone_capemgr: slot #6: 'Override Board
Name,00A0,Override Manuf,BB-W1-P8.26'
[4.492070] bone_capemgr bone_capemgr: initialized OK.
[4.503689] bone_capemgr bone_capemgr: slot #5: dtbo 'BB-ADC-00A0.dtbo'
loaded; overlay id #0
[4.505152] bone_capemgr bone_capemgr: slot #6: dtbo
'BB-W1-P8.26-00A0.dtbo' loaded; overlay id #1
[4.540874] bone_capemgr bone_capemgr: slot #4: dtbo
'controller-00A0.dtbo' loaded; overlay id #2


On Wed, Jan 18, 2017 at 1:49 PM, William Hermans <yyrk...@gmail.com> wrote:

> Just for informational purposes here is that one pin in my custom overlay:
>
> . . .
>> exclusive-use =
>> /* the pin header uses */
>> "P8.11",
>> . . .
>> /* P8_11 (ZCZ ball R12) */
>> P8_11_default_pin: pinmux_P8_11_default_pin {
>> pinctrl-single,pins = <0x034  0x27>; }; /* Mode 7,
>> Pull-Down, RxActive */
>> . . .
>> fragment@1 {
>> target = <>;
>> __overlay__ {
>>
>> P8_11_pinmux {
>> compatible = "bone-pinmux-helper";
>> status = "okay";
>> pinctrl-names = "default";
>> pinctrl-0 = <_11_default_pin>;
>> };
>> . . .
>>
>> P8_11 {
>> gpio-name = "P8_11";
>> gpio = < 13 0>;
>> input;
>> dir-changeable;
>> };
>> . . .
>
>
> Then the P8.26 1-wire overlay is exactly the same as the one example
> 1-wire overlay included with the stock image. But I changed the pin
> configuration to match P8.26 instead of what was it ? P9.12 was it ? No
> idea why I'm getting that boot message, and this is the first time I've
> ever seen it.
>
> On Wed, Jan 18, 2017 at 1:39 PM, William Hermans <yyrk...@gmail.com>
> wrote:
>
>> The error I noticed on my end was: *libfdt fdt_check_header():
>> FDT_ERR_BADMAGIC* Which did not really make sense to me as the overlays
>> seems to work just fine. I did not check everythign with my overlays, but I
>> did check gpio45, and according to the direciton, and value files it's
>> configured correctly. But I was getting some odd boot log error message
>> about the capemgr back peddling a non existent pin conflict. From where it
>> came, I have no idea.
>>
>> beaglebone login: [   19.548440] omap-sham 5310.sham: initialization
>>> failed.
>>> [   19.880445] pinctrl-single 44e10800.pinmux: pin 44e10834.0 already
>>> requested by ocp:P8_11_pinmux; cannot claim for onewire
>>> [   19.921657] pinctrl-single 44e10800.pinmux: pin-13 (onewire) status
>>> -22
>>> [   20.000724] pinctrl-single 44e10800.pinmux: could not request pin 13
>>> (44e10834.0

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

[William Hermans]

Just for informational purposes here is that one pin in my custom overlay:

. . .
> exclusive-use =
> /* the pin header uses */
> "P8.11",
> . . .
> /* P8_11 (ZCZ ball R12) */
> P8_11_default_pin: pinmux_P8_11_default_pin {
> pinctrl-single,pins = <0x034  0x27>; }; /* Mode 7,
> Pull-Down, RxActive */
> . . .
> fragment@1 {
> target = <>;
> __overlay__ {
>
> P8_11_pinmux {
> compatible = "bone-pinmux-helper";
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_11_default_pin>;
> };
> . . .
>
> P8_11 {
> gpio-name = "P8_11";
> gpio = < 13 0>;
> input;
> dir-changeable;
> };
> . . .


Then the P8.26 1-wire overlay is exactly the same as the one example 1-wire
overlay included with the stock image. But I changed the pin configuration
to match P8.26 instead of what was it ? P9.12 was it ? No idea why I'm
getting that boot message, and this is the first time I've ever seen it.

On Wed, Jan 18, 2017 at 1:39 PM, William Hermans <yyrk...@gmail.com> wrote:

> The error I noticed on my end was: *libfdt fdt_check_header():
> FDT_ERR_BADMAGIC* Which did not really make sense to me as the overlays
> seems to work just fine. I did not check everythign with my overlays, but I
> did check gpio45, and according to the direciton, and value files it's
> configured correctly. But I was getting some odd boot log error message
> about the capemgr back peddling a non existent pin conflict. From where it
> came, I have no idea.
>
> beaglebone login: [   19.548440] omap-sham 5310.sham: initialization
>> failed.
>> [   19.880445] pinctrl-single 44e10800.pinmux: pin 44e10834.0 already
>> requested by ocp:P8_11_pinmux; cannot claim for onewire
>> [   19.921657] pinctrl-single 44e10800.pinmux: pin-13 (onewire) status -22
>> [   20.000724] pinctrl-single 44e10800.pinmux: could not request pin 13
>> (44e10834.0) from group pinmux_P8_11_default_pin  on device pinctrl-single
>> [   20.093995] w1-gpio onewire: Error applying setting, reverse things
>> back
>>
>
> That's another error message I've been noticing lately. omap_sham
> initialization failing. But when I take a look at the output of lsmod . . .
> *root@beaglebone:~#* lsmod |grep omap
> omap_aes   13637  0
> omap_rng4572  0
> omap_sham  21458  0
> rng_core7390  1 omap_rng
>
> It seems to have loaded fine ? So I'm guessing omap_sham is related to SHA
> somehow, and thus probably important. Not sure why this error message
> though :/
>  I'm also assuming it's fine since it's already loaded, but . . .I'm not
> 100% positive.
>
> On Wed, Jan 18, 2017 at 1:29 PM, Robert Nelson <robertcnel...@gmail.com>
> wrote:
>
>> On Wed, Jan 18, 2017 at 2:24 PM, William Hermans <yyrk...@gmail.com>
>> wrote:
>> > Not enough memory allocated ?
>>
>> Correct by default it was only 4k, defaulted to 0x6
>>
>> seems to have fixed the big overlays...
>>
>> https://github.com/RobertCNelson/Bootloader-Builder/commit/6
>> f3929a577056d10a7994252aa521835bf3f3984
>>
>> 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/CAOCHtYiu5hnmwr23woC5ST6X7HR2KJA8%2BfQkaA8U_
>> %3DpaGkO%2BBA%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/CALHSORojFT8bfr2%3DQ%3DYVjT0k93TnkEs_N2xhLiQsW_2BSNr71Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[William Hermans]

The error I noticed on my end was: *libfdt fdt_check_header():
FDT_ERR_BADMAGIC* Which did not really make sense to me as the overlays
seems to work just fine. I did not check everythign with my overlays, but I
did check gpio45, and according to the direciton, and value files it's
configured correctly. But I was getting some odd boot log error message
about the capemgr back peddling a non existent pin conflict. From where it
came, I have no idea.

beaglebone login: [   19.548440] omap-sham 5310.sham: initialization
> failed.
> [   19.880445] pinctrl-single 44e10800.pinmux: pin 44e10834.0 already
> requested by ocp:P8_11_pinmux; cannot claim for onewire
> [   19.921657] pinctrl-single 44e10800.pinmux: pin-13 (onewire) status -22
> [   20.000724] pinctrl-single 44e10800.pinmux: could not request pin 13
> (44e10834.0) from group pinmux_P8_11_default_pin  on device pinctrl-single
> [   20.093995] w1-gpio onewire: Error applying setting, reverse things back
>

That's another error message I've been noticing lately. omap_sham
initialization failing. But when I take a look at the output of lsmod . . .
*root@beaglebone:~#* lsmod |grep omap
omap_aes   13637  0
omap_rng4572  0
omap_sham  21458  0
rng_core7390  1 omap_rng

It seems to have loaded fine ? So I'm guessing omap_sham is related to SHA
somehow, and thus probably important. Not sure why this error message
though :/
 I'm also assuming it's fine since it's already loaded, but . . .I'm not
100% positive.

On Wed, Jan 18, 2017 at 1:29 PM, Robert Nelson <robertcnel...@gmail.com>
wrote:

> On Wed, Jan 18, 2017 at 2:24 PM, William Hermans <yyrk...@gmail.com>
> wrote:
> > Not enough memory allocated ?
>
> Correct by default it was only 4k, defaulted to 0x6
>
> seems to have fixed the big overlays...
>
> https://github.com/RobertCNelson/Bootloader-Builder/commit/
> 6f3929a577056d10a7994252aa521835bf3f3984
>
> 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/CAOCHtYiu5hnmwr23woC5ST6X7HR2K
> JA8%2BfQkaA8U_%3DpaGkO%2BBA%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/CALHSORoANfq9%2BiaNwV9TPzJZJZv3Abxt6yqgD0AqeXskQPCiQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[William Hermans]

Not enough memory allocated ?

On Wed, Jan 18, 2017 at 11:30 AM, Robert Nelson 
wrote:

> So adding a couple more fdt commits from u-boot mainline: (to actually
> report what failed)
>
> loading /boot/vmlinuz-4.9.4-bone4 ...
> 8225160 bytes read in 543 ms (14.4 MiB/s)
> loading /boot/dtbs/4.9.4-bone4/am335x-boneblack-overlay.dtb ...
> 52712 bytes read in 63 ms (816.4 KiB/s)
> debug: [uboot_overlay_addr0=/lib/firmware/BB-BONE-LCD7-01-00A3.dtbo] ...
> loading /lib/firmware/BB-BONE-LCD7-01-00A3.dtbo ...
> 5778 bytes read in 136 ms (41 KiB/s)
> fdt_overlay_apply(): FDT_ERR_NOSPACE
>
> that's why it's not applying 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/CAOCHtYjXDCsStAuLOgobXCUzsuZcWG%2BQDBhUmjAaKxSexdCj9w%
> 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/CALHSORpECbGXs-nfu-2AD2eGj87E3tY5ybG8P5_7FBrptJ81RQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[William Hermans]

By the way, the kernel I failed with was: linux-image-4.4.43-bone-rt-r16

On Wed, Jan 18, 2017 at 9:32 AM, William Hermans <yyrk...@gmail.com> wrote:

> So, I've tested this a few times over the last . . . since announcement >, and I have found that loading a single overlay seems
> to work really good. Attempting multiple overlays however, seems to  be an
> exercise in frustration. e.g. It's not ready. It's possible that I got
> something wrong, but I do not usually do that more than once. I've tried
> multiple times.
>
> So my recommendation is, if you're an embedded Linux noob, or a beginner
> to this platforms boot process. Steer clear. If you're reasonably
> experienced in both of these areas, and don't mind testing - Have fun. But
> I would definitely strongly advise to not attempt this on a production
> system.
>
> Basically what happens is uboot complains that the cmdline kernel
> parameter does not contain a valid flattened device tree overlay path. Why
> exactly, I'm not sure. I did see uboot "mention" that it can not find a
> valid partition for partitions 1-6 . . . which I think may be standard
> uboot debug output. First, it checked the path for the UUID, then attempted
> the blk device. Failing ( or flailing ). However, this works perfectly fine
> when using:
>
> ##Example v4.1.x
>> #cape_disable=bone_capemgr.disable_partno=
>> cape_enable=bone_capemgr.enable_partno=controller,BB-ADC,BB-W1-P8.26
>>
>
> After making sure the overlays exist in /lib/firmware/, and then running:
>
> root@beaglebone:~# cd /opt/scripts/tools/developers/
>> root@beaglebone:/opt/scripts/tools/developers# ./update_initrd.sh
>> root@beaglebone:/opt/scripts/tools/developers# reboot
>>
>
> One should also keep in mind that if you update to a newer kernel before
> this process. Make sure you reboot into your new kernel first. Otherwise
> your board *WILL* boot, but the boot process will stop inside the
> initramfs. I fell into this trap myself, and basically what happens. You
> will end up updating the initramfs you just replaced, while leaving the
> replacement initramfs without a clue as to where to go next. Once the
> initramfs loads that is.
>
> Anyway, this is a potentially really cool, and good feature. I look
> forward to this working flawlessly in the future. However, at this point in
> time, I have to give testing a pass. As I have other priorities that must
> come first - currently.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORoGCkgSi_6rdESMt%3DPsu59pp39GzE%3DQDLHfruntV0QHNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[William Hermans]

So, I've tested this a few times over the last . . ., and I have found that loading a single overlay seems
to work really good. Attempting multiple overlays however, seems to  be an
exercise in frustration. e.g. It's not ready. It's possible that I got
something wrong, but I do not usually do that more than once. I've tried
multiple times.

So my recommendation is, if you're an embedded Linux noob, or a beginner to
this platforms boot process. Steer clear. If you're reasonably experienced
in both of these areas, and don't mind testing - Have fun. But I would
definitely strongly advise to not attempt this on a production system.

Basically what happens is uboot complains that the cmdline kernel parameter
does not contain a valid flattened device tree overlay path. Why exactly,
I'm not sure. I did see uboot "mention" that it can not find a valid
partition for partitions 1-6 . . . which I think may be standard uboot
debug output. First, it checked the path for the UUID, then attempted the
blk device. Failing ( or flailing ). However, this works perfectly fine
when using:

##Example v4.1.x
> #cape_disable=bone_capemgr.disable_partno=
> cape_enable=bone_capemgr.enable_partno=controller,BB-ADC,BB-W1-P8.26
>

After making sure the overlays exist in /lib/firmware/, and then running:

root@beaglebone:~# cd /opt/scripts/tools/developers/
> root@beaglebone:/opt/scripts/tools/developers# ./update_initrd.sh
> root@beaglebone:/opt/scripts/tools/developers# reboot
>

One should also keep in mind that if you update to a newer kernel before
this process. Make sure you reboot into your new kernel first. Otherwise
your board *WILL* boot, but the boot process will stop inside the
initramfs. I fell into this trap myself, and basically what happens. You
will end up updating the initramfs you just replaced, while leaving the
replacement initramfs without a clue as to where to go next. Once the
initramfs loads that is.

Anyway, this is a potentially really cool, and good feature. I look forward
to this working flawlessly in the future. However, at this point in time, I
have to give testing a pass. As I have other priorities that must come
first - currently.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORrS8OMK1%3DnzDkLPcVccHPyoASoz%2BQO1su%3D4ak2ibFk0vQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone black bricked... May be???

[William Hermans]

OK. Be aware, that it should be possible to adapt that course, *somewhat*
to work with the beaglebone hardware. But you'll need to understand Llinux,
and several other things very well before making that leap. But anything
pertaining to the beaglebone hardware, and the boot process will be
different. At least.

Setting up crosstools-ng, and all that. Should work fine, if you're setting
up a cross toolchain. But trust me when I say:  If all you want to do is to
write source, and compile the typical user space applications to work with
your system. Compiling form the cmdline, on the board it's self. This will
make your life much easier. Now if you're concerned about compiling
directly on the emmc, or sdcard. This is understandable. But can be
mitigated by compiling in a tmpfs directory( ram disk ), or on an NFS share.

On Wed, Jan 18, 2017 at 3:34 AM, Hemant Kapoor 
wrote:

> Thanks.
>>
>
> I will try the option you suggested this evening and let you know the
> result.
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/328bdeb3-0289-4d9b-a5d3-aa7b7ba40025%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/CALHSORoCFokPg_mx3uiUR%2B1Lta-LhD1mdZO%2BHr%2BkEfydRosxRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] SPI Woes with different Kernel Versions

[William Hermans]

Additional information:

I seem to recall there was an issue with SPI loading at boot. This had
something to do with having to enable the spi software module in main board
overlay file. Of which there has been several posts over the last few
months. So see those for the exact details. So basically . . .

*root@beaglebone:~#* dmesg |grep SPI
[   47.792110] bone_capemgr bone_capemgr: part_number 'BB-SPIDEV0', version
'N/A'
[   47.802326] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-SPIDEV0'
[   47.826377] bone_capemgr bone_capemgr: slot #4: dtbo
'BB-SPIDEV0-00A0.dtbo' loaded; overlay id #0

There two modules must be loaded at boot, through the main board overlay
file:
*root@beaglebone:~#* lsmod |grep spi
spidev  7564  0
spi_omap2_mcspi11588  0

Here is the include file:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am33xx-overlay-edma-fix.dtsi

Which you'll see is commented out by default in at least this one board
overlay file. Which I'm fairly certain it's commented out in all the stock
board files.
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-emmc-overlay.dts#L12-Lundefined

Additionally, if you simply upgraded your kernel from an older image( e.g.
an image that started with kernel 3.8.x ). You'll need to git pull that
whole git repo, rebuild the board files, then install the ones you need.
But you did not mention how you've managed to update your kernels from one
test to the next. The best way to test would actually be to use two
different flasher or stand alone images to test properly. Wheezy(debian 7 )
for 3.8.x, and Jessie(debian 8 ) for 4.x kernels. As some important changes
have been made which may conflict between different kernels. 3.8.x may
actually work fine on Jessie images, but I did personally run into troubles
trying to update to a 4.x kernel on Wheezy images.




On Wed, Jan 18, 2017 at 3:33 AM, William Hermans <yyrk...@gmail.com> wrote:

> *root@beaglebone:~#* cat /etc/dogtag
> BeagleBoard.org Debian Image 2016-06-19
>
> *root@beaglebone:~#* uname -r
> 4.4.43-bone-rt-r16
>
> *root@beaglebone:~#* ls /lib/firmware/ |grep SPI
> BB-SPI0-MCP3008-00A0.dtbo
> BB-SPIDEV0-00A0.dtbo
> BB-SPIDEV1-00A0.dtbo
> BB-SPIDEV1A1-00A0.dtbo
>
> *root@beaglebone:~#* ls /dev |grep spi
>
> *root@beaglebone:~# *echo 'BB-SPIDEV0' > /sys/devices/platform/bone_
> capemgr/slots
>
> *root@beaglebone:~#* ls /dev |grep spi
> spidev1.0
> spidev1.1
>
>
>
> On Wed, Jan 18, 2017 at 3:22 AM, Thomas Hoppe <thomas.ho...@n-fuse.co>
> wrote:
>
>> Hi,
>>
>> I have a board attached via SPI0 to a BBB (also tested with Green).
>> I'm activating SPI0 via uEnv.txt entries which I read is the best
>> practice.
>> Now I can use the board with its user space software (no kernel driver
>> whatsoever involved).
>> The setup *works* with 3.8 and 4.1 kernels but *not* with 4.4 and 4.9.
>> Below I have the output of
>>
>> cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins | grep spi
>>
>> and the actual device name for each version.
>> I cannot spot any relevant difference. So what has changed in the SPI
>> code between those kernels
>> or has anyone an idea what could be the issue here?
>>
>> BG, Thomas
>>
>>
>> 3.8.13
>>
>> /dev/spidev1.0
>>
>> pin 84 (44e10950): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>> pin 85 (44e10954): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>> pin 86 (44e10958): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>> pin 87 (44e1095c): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>>
>> 4.1.x
>>
>> /dev/spidev1.0
>>
>> pin 84 (44e10950.0): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>> pin 85 (44e10954.0): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>> pin 86 (44e10958.0): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>> pin 87 (44e1095c.0): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>>
>>
>> 4.4.x
>>
>> /dev/spidev1.0
>>
>> pin 84 (44e10950.0): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>> pin 85 (44e10954.0): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>> pin 86 (44e10958.0): 4803.spi (GPIO UNCLAIMED) function
>> pinmux_bb_spi0_pin

Re: [beagleboard] SPI Woes with different Kernel Versions

[William Hermans]

*root@beaglebone:~#* cat /etc/dogtag
BeagleBoard.org Debian Image 2016-06-19

*root@beaglebone:~#* uname -r
4.4.43-bone-rt-r16

*root@beaglebone:~#* ls /lib/firmware/ |grep SPI
BB-SPI0-MCP3008-00A0.dtbo
BB-SPIDEV0-00A0.dtbo
BB-SPIDEV1-00A0.dtbo
BB-SPIDEV1A1-00A0.dtbo

*root@beaglebone:~#* ls /dev |grep spi

*root@beaglebone:~# *echo 'BB-SPIDEV0' >
/sys/devices/platform/bone_capemgr/slots

*root@beaglebone:~#* ls /dev |grep spi
spidev1.0
spidev1.1


On Wed, Jan 18, 2017 at 3:22 AM, Thomas Hoppe 
wrote:

> Hi,
>
> I have a board attached via SPI0 to a BBB (also tested with Green).
> I'm activating SPI0 via uEnv.txt entries which I read is the best practice.
> Now I can use the board with its user space software (no kernel driver
> whatsoever involved).
> The setup *works* with 3.8 and 4.1 kernels but *not* with 4.4 and 4.9.
> Below I have the output of
>
> cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins | grep spi
>
> and the actual device name for each version.
> I cannot spot any relevant difference. So what has changed in the SPI code
> between those kernels
> or has anyone an idea what could be the issue here?
>
> BG, Thomas
>
>
> 3.8.13
>
> /dev/spidev1.0
>
> pin 84 (44e10950): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 85 (44e10954): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 86 (44e10958): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 87 (44e1095c): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>
> 4.1.x
>
> /dev/spidev1.0
>
> pin 84 (44e10950.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 85 (44e10954.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 86 (44e10958.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 87 (44e1095c.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>
>
> 4.4.x
>
> /dev/spidev1.0
>
> pin 84 (44e10950.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 85 (44e10954.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 86 (44e10958.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 87 (44e1095c.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>
>
> 4.9.x
>
> /dev/spidev0.0
>
> pin 84 (44e10950.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 85 (44e10954.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 86 (44e10958.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
> pin 87 (44e1095c.0): 4803.spi (GPIO UNCLAIMED) function
> pinmux_bb_spi0_pins group pinmux_bb_spi0_pins
>
>
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/e1a2e7ae-1e6e-406b-be64-7efb1cbfe8f6%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/CALHSORq1x_Axzgjvac1mnTRqU%3D%2BH_HcWdhVFkx3RtJrFvefq-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone black bricked... May be???

[William Hermans]

That free electrons course does not seem to revolve around the same
hardware. At least at a glance it seems to revolve around an Atmel dev
board. So right off, that course won't work for this board.

As far as the latest debian images for the beaglebone boards they can be
had here:
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots

Make sure you read everything carefully before downloading an image and
attempting to flash it. As if you're using an older A5A, or Revision B
board. You'll have to use a 2G image.


On Wed, Jan 18, 2017 at 3:01 AM, Hemant Kapoor 
wrote:

> First of all thanks for the quick response.
>
> The main reason I want to flash the new image is so that I can run debain
> image stright from emmc so that I can follow free electron tutorial on
> Linux System Development (http://free-electrons.com/
> doc/training/embedded-linux/)
>
> Because of different things I have tried I am unable to Boot and run
> debian from eMMC.
>
> Can you please point me to the direction where I can get the latest image
> to SD card which will inturn update the uboot and a new image to emmc.
>
> Thanks.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/88950f46-7e36-4b12-a53d-90a498cfe333%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/CALHSORo3oLW8xASgxTqb2uY4B0dT8bYXkhkSMUAoLynr8Ef-rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone black bricked... May be???

[William Hermans]

By the way that boot loader is ancient. It's around 2 years, and 8 months
old. Which also means the image you're trying to flash is also dated, and
likely not much in the way for support with it any more.

On Wed, Jan 18, 2017 at 2:36 AM, William Hermans <yyrk...@gmail.com> wrote:

> First. it's impossible to brick the beaglebone in this manner. Even
> assuming you'd had written to the emmc millions of times, and rendered the
> emmc unworkable. Since the board can also boot from sdcard, as well as
> serial.
>
> Second, why are you flashing a new image onto the beaglebone ? Meaning
> what features are you hoping to gain from this procedure ? This is an
> important question to answer, otherwise no one will really know how to help
> you out of your situation. At least not correctly.
>
> Lastly, no idea where you got the flasher image from. But where ever it
> came from. Apparently it did not write the uboot environment file to the
> boot partition. This is what uEnv.txt is, and it's important to uboot, so
> uboot knows how to configure your board at boot.
>
> On Wed, Jan 18, 2017 at 1:49 AM, Hemant Kapoor <kapoor.hem...@gmail.com>
> wrote:
>
>> Hello All,
>>
>> I am learning Linux using Beaglebone black and was following Free
>> electrons tutorial.
>> At one stage I got my setup so that I have an SD Card with Uboot and the
>> configuration was loading Kernel via network.
>>
>> I was happy with the result and then I decided to run the debain version
>> from eMMc and followed instructions present at
>> http://derekmolloy.ie/write-a-new-image-to-the-beaglebone-black/
>>
>> Once I removed the SD card after the whole processs, I was not able to
>> get anything.
>> Below is the trace from picocom:
>>
>> U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
>>  reading args
>>  spl_load_image_fat_os: error reading image args, err - -1
>>  reading u-boot.img
>>  reading u-boot.img
>>
>>
>>  U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
>>
>>  I2C:   ready
>>  DRAM:  512 MiB
>>  NAND:  0 MiB
>>  MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>  *** Warning - readenv() failed, using default environment
>>
>>  Net:not set. Validating first E-fuse MAC
>>  cpsw, usb_ether
>>  Hit any key to stop autoboot:  0
>>  gpio: pin 53 (gpio 53) value is 1
>>  Card did not respond to voltage select!
>>  mmc0(part 0) is current device
>>  Card did not respond to voltage select!
>>  gpio: pin 56 (gpio 56) value is 0
>>  gpio: pin 55 (gpio 55) value is 0
>>  gpio: pin 54 (gpio 54) value is 0
>>  mmc1(part 0) is current device
>>  gpio: pin 54 (gpio 54) value is 1
>>  SD/MMC found on device 1
>>  reading uEnv.txt
>>  ** Unable to read file uEnv.txt **
>>  Checking if uenvcmd is set ...
>>
>>  uenvcmd was not defined in uEnv.txt ...
>>  Booting from nand ...
>>
>>  no devices available
>>
>>  no devices available
>>  Bad Linux ARM zImage magic!
>>  U-Boot#
>>
>>
>>
>> Any ideas what I am doing wrong.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving 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/4ecc65e6-5d92-41a8-b38e-2acb7649d119%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/4ecc65e6-5d92-41a8-b38e-2acb7649d119%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/CALHSORqu4T8Rw-o8TpOZCvNKNfgTTWazTcPgqfZy8CYmNLgq7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone black bricked... May be???

[William Hermans]

First. it's impossible to brick the beaglebone in this manner. Even
assuming you'd had written to the emmc millions of times, and rendered the
emmc unworkable. Since the board can also boot from sdcard, as well as
serial.

Second, why are you flashing a new image onto the beaglebone ? Meaning what
features are you hoping to gain from this procedure ? This is an important
question to answer, otherwise no one will really know how to help you out
of your situation. At least not correctly.

Lastly, no idea where you got the flasher image from. But where ever it
came from. Apparently it did not write the uboot environment file to the
boot partition. This is what uEnv.txt is, and it's important to uboot, so
uboot knows how to configure your board at boot.

On Wed, Jan 18, 2017 at 1:49 AM, Hemant Kapoor 
wrote:

> Hello All,
>
> I am learning Linux using Beaglebone black and was following Free
> electrons tutorial.
> At one stage I got my setup so that I have an SD Card with Uboot and the
> configuration was loading Kernel via network.
>
> I was happy with the result and then I decided to run the debain version
> from eMMc and followed instructions present at
> http://derekmolloy.ie/write-a-new-image-to-the-beaglebone-black/
>
> Once I removed the SD card after the whole processs, I was not able to get
> anything.
> Below is the trace from picocom:
>
> U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
>  reading args
>  spl_load_image_fat_os: error reading image args, err - -1
>  reading u-boot.img
>  reading u-boot.img
>
>
>  U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
>
>  I2C:   ready
>  DRAM:  512 MiB
>  NAND:  0 MiB
>  MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>  *** Warning - readenv() failed, using default environment
>
>  Net:not set. Validating first E-fuse MAC
>  cpsw, usb_ether
>  Hit any key to stop autoboot:  0
>  gpio: pin 53 (gpio 53) value is 1
>  Card did not respond to voltage select!
>  mmc0(part 0) is current device
>  Card did not respond to voltage select!
>  gpio: pin 56 (gpio 56) value is 0
>  gpio: pin 55 (gpio 55) value is 0
>  gpio: pin 54 (gpio 54) value is 0
>  mmc1(part 0) is current device
>  gpio: pin 54 (gpio 54) value is 1
>  SD/MMC found on device 1
>  reading uEnv.txt
>  ** Unable to read file uEnv.txt **
>  Checking if uenvcmd is set ...
>
>  uenvcmd was not defined in uEnv.txt ...
>  Booting from nand ...
>
>  no devices available
>
>  no devices available
>  Bad Linux ARM zImage magic!
>  U-Boot#
>
>
>
> Any ideas what I am doing wrong.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/4ecc65e6-5d92-41a8-b38e-2acb7649d119%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/CALHSORoE3VAWgqHpC%3D7X3MW69bAP%3DKtdoW-9oD4QMHVx%3Dmi8eQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Bug, or conflict with kernels 4.x and universal IO

[William Hermans]

Thanks Robert. The odd thing, when I do a std apt-cache search linux-image
|grep bone. I don't see those versions, or they're ordered out of sequence,
and I just look in the wrong place I guess. So in context of 4.4.x, the
kernel I pulled in "seemed" to be the newest. *shrug*

On Mon, Jan 16, 2017 at 12:46 PM, Robert Nelson <robertcnel...@gmail.com>
wrote:

> On Mon, Jan 16, 2017 at 1:19 PM, William Hermans <yyrk...@gmail.com>
> wrote:
> >
> >
> > On Mon, Jan 16, 2017 at 10:06 AM, Robert Nelson <robertcnel...@gmail.com
> >
> > wrote:
> >>
> >> the issue is 4.4.9-bone-rt-r10...
> >>
> >> grab 4.4.39-bone-rt-r16 or later, which includes a dtc resync:
> >>
> >>
> >> https://github.com/RobertCNelson/bb-kernel/blob/
> 722d8ee587bc6573c01136ef18dc14d0de903f46/patches/dtc/0001-
> scripts-dtc-Update-to-upstream-version-overlays.patch
> >>
> >> as that fixes:
> >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> >>
> >> and:
> >> debug: [bootz 0x8200 0x8808:48b75f 8800] ...
> >> ERROR: Did not find a cmdline Flattened Device Tree
> >> Could not find a valid device tree
> >>
> >> Regards,
> >>
> >> --
> >> Robert Nelson
> >> https://rcn-ee.com/
> >>
> >
> > D'oh . . .Ok, was sure it was my fault, and it was. Way too early of a
> > kernel, and I did not even think about that.
> >
> > After an apt-get update . . .
> > root@beaglebone:~# apt-cache search linux-image |grep 4.4.39-bone
> > linux-image-4.4.39-bone-rt-r14 - Linux kernel, version 4.4.39-bone-rt-r14
> > linux-image-4.4.39-bone-rt-r15 - Linux kernel, version 4.4.39-bone-rt-r15
> > linux-image-4.4.39-bone14 - Linux kernel, version 4.4.39-bone14
> > linux-image-4.4.39-bone15 - Linux kernel, version 4.4.39-bone15
> >
> > What am I missing ?
>
> of course my dtc update alone wasn't built-able..
>
> Grab the next release, where i fixed the dtc build errors...
>
> linux-image-4.4.41-bone-rt-r16
>
> 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/CAOCHtYh-V%3DihA1jWK%2BgF1zos_V73cOiKAGabgkHn5O5r3X3DCQ%
> 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/CALHSORrou2625V1XSs1yB6LqrjVsvpOeE9iwqTAfuAkFoDP35Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Figure out how to configure correctly modules, pins, and PRU to blink a led

[William Hermans]

On Mon, Jan 16, 2017 at 9:55 AM, Greg  wrote:

> There was nothing particularly practical about that PRU-ADC project.  It
> was a means of learning PRU C programming, SPI bus, RemoteProc framework,
> and user-space C code (and others).
> It was an extremely good learning experience!  I want to apply the
> knowledge gained to robotic projects and also I am interested in Software
> Defined Radio.
>
> I'm pretty sure that others have successfully accessed the internal ADCs
> from the PRU.  If you do some searching I think you can find a specific
> instance.
> I think it should be possible via the PRU's OCP master port.
>

Several people have done external ADC's through the PRU via various means.
SPI for you, but I think for example DR Molloy used I2C ? It's been a while
since I've read any of his material. But I'd like to see someone talk about
the internal ADC *only* because it does not require additional circuitry,
or hardware to make work. Although, obviously one would still have to
"design" a circuit anyhow, for 1.8v or less. Not like you could just plug a
GPIO, PWM, or whatever to an ADC pin, and expect the ADC, or processor to
survive. Without some form of voltage scaling.

However, other than for touchscreens, I'm finding the on processor ADC is
not exactly that good. Having 8 input channels is cool, but only if the
pins aren't multiplexed. Which is the case with the on die ADC. e.g. it's
not a true 200ksps x8 ADC. Despite what many people out there think.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORr905e6YRgiQDPHh9DUYqPsrNARyGNUa4CwQb5bhAOBTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Bug, or conflict with kernels 4.x and universal IO

[William Hermans]

On Mon, Jan 16, 2017 at 10:06 AM, Robert Nelson 
wrote:

> the issue is 4.4.9-bone-rt-r10...
>
> grab 4.4.39-bone-rt-r16 or later, which includes a dtc resync:
>
> https://github.com/RobertCNelson/bb-kernel/blob/
> 722d8ee587bc6573c01136ef18dc14d0de903f46/patches/dtc/0001-
> scripts-dtc-Update-to-upstream-version-overlays.patch
>
> as that fixes:
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>
> and:
> debug: [bootz 0x8200 0x8808:48b75f 8800] ...
> ERROR: Did not find a cmdline Flattened Device Tree
> Could not find a valid device tree
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
>
D'oh . . .Ok, was sure it was my fault, and it was. Way too early of a
kernel, and I did not even think about that.

*After an apt-get update . . .*
*root@beaglebone:~#* apt-cache search linux-image |grep 4.4.39-bone
linux-image-4.4.39-bone-rt-r14 - Linux kernel, version 4.4.39-bone-rt-r14
linux-image-4.4.39-bone-rt-r15 - Linux kernel, version 4.4.39-bone-rt-r15
linux-image-4.4.39-bone14 - Linux kernel, version 4.4.39-bone14
linux-image-4.4.39-bone15 - Linux kernel, version 4.4.39-bone15

What am I missing ?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORqBAPB_rQQFyvywO9a2BbGtPcK3i9OKT0suxQDp2wBHJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Bug, or conflict with kernels 4.x and universal IO

[William Hermans]

Robert,

So, I got around to updating to the latest bootloader this morning, and,
well something went wrong. not sure exactly what yet. But here is the
serial debug output. For some reason it can't seem to find a valid boot
partition ?

http://pastebin.com/tUqkDvef

On Mon, Jan 9, 2017 at 3:17 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Mon, Jan 9, 2017 at 3:12 PM, Robert Nelson <robertcnel...@gmail.com>
> wrote:
>
>>
>> Use this in /boot/uEnv.txt
>>
>> enable_uboot_overlays=1
>> uboot_overlay_addr0=/lib/firmware/BB-CAPE-1-00A0.dtbo
>> uboot_overlay_addr1=/lib/firmware/BB-CAPE-2-00A0.dtbo
>> uboot_overlay_addr2=/lib/firmware/BB-CAPE-3-00A0.dtbo
>> uboot_overlay_addr3=/lib/firmware/BB-CAPE-4-00A0.dtbo
>> dtb_overlay=/lib/firmware/BB-CAPE-5-00A0.dtbo
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>>
> Awesome, thanks Robert.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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%2Bc6jauf6JW6wF26Yqm%2BybMdmYPcSUfiLC8xXc9CGtiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Issues With I2C and Beagle Board Black?

[William Hermans]

George, how about you give us  step by step of exactly what you're doing to
try to get this working. Assuming Gerald's suggestion does not work out for
you.

On Wed, Jan 11, 2017 at 9:02 AM, Gerald Coley 
wrote:

> What is the value of your pull up resistors on SCL and SDA?
>
> Gerald
>
>
> On Wed, Jan 11, 2017 at 9:53 AM, George Faraj 
> wrote:
>
>> Both with the BBB and the BBBW I have been unable to detect any I2C
>> devices. both have Debian 8.6 images (the most recent one I believe).
>>
>> My device is properly wired with the CL going to P9_19 and DA going to
>> P9_20 and I used a multimeter to ensure its powered properly.
>>
>> I've tried all the I2C pins on the BBB and whenever I run i2cdetect -y -r
>> #  (my i2xdetect-tools is the most recent) all I get is either a blank
>> matrix with a couple of UUs or a completely blank matrix.
>>
>> I am a beginner and I get the feeling that what I am missing is something
>> very basic, if anyone else has been having this issue please let me know
>> how you solved it!
>>
>> The i2c devices Ive tried are: HTU21D temp and humidity sensor, and an
>> ADS1015.
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving 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/528f20c6-91dd-428f-9b54-df8e78405552%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%2BeWVooeXqkLWymXO_4NbFRVSqSRikYMxyGkW9QmyMU2cw%
> 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/CALHSORqfwjBeyfErZe%2BDE2CfwTDgJh%3DHCS1kjXjHt%2B4V_ZX_qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beagle expertise needed

[William Hermans]

I'd like to point out, that if you want / need reliability. Wireless is
probably not the vehicle to get you there.

On Wed, Jan 11, 2017 at 10:12 AM, Richard Maurer  wrote:

> Here is some additional info that was requested:
>
> Message size is small (< 20 bits probably no more than 5 -- just enough to
> turn stuff on and off), but with at least 5 updates per second.  At this
> point, I'm only envisioning streaming data.  Reliability is not critical
> (i,e., system can tolerate message loss), however system cannot tolerate
> inaccurate messages, as we don't want to turn off/on something incorrectly,
> but if there is a short delay, that is acceptable.  The solution has to be
> manageable by me which means that the software can't be wrapped up in
> highly complex networking algorithms that would be inaccessible by an
> 'engineer'.  I need to at least manage changes in data (not necessarily
> data type, but at least what data is sent), and I need to be able to access
> the data in each beagle with either Python, C#, or some other simple
> language.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/937bbabf-3972-4f7f-a8a4-0d1d997d0970%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/CALHSORou61rVEC_GmBNpy59Kwby0Ba4k%2BjyZY5xZR71w4C3ZPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Bug, or conflict with kernels 4.x and universal IO

[William Hermans]

On Mon, Jan 9, 2017 at 3:12 PM, Robert Nelson 
wrote:

>
> Use this in /boot/uEnv.txt
>
> enable_uboot_overlays=1
> uboot_overlay_addr0=/lib/firmware/BB-CAPE-1-00A0.dtbo
> uboot_overlay_addr1=/lib/firmware/BB-CAPE-2-00A0.dtbo
> uboot_overlay_addr2=/lib/firmware/BB-CAPE-3-00A0.dtbo
> uboot_overlay_addr3=/lib/firmware/BB-CAPE-4-00A0.dtbo
> dtb_overlay=/lib/firmware/BB-CAPE-5-00A0.dtbo
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
>
Awesome, thanks Robert.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORoHce1zAVdy-HO5ErvxPQhcLcYz%2BZCeSd87P3VJ7irKkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Bug, or conflict with kernels 4.x and universal IO

[William Hermans]

I should also add, that I have only tested this "fix" on a beaglebone
green. I seem to recall that this problem does not exist when using a
beaglebone black.

On Mon, Jan 9, 2017 at 3:05 PM, William Hermans <yyrk...@gmail.com> wrote:

> So this is probably more of an oversight than a bug. But when loading
> *some* overlays via config-pin overlay , *AFTER* already having
> loaded an overlay through /boot/uEnv.txt. At least one pin will still
> continue function correctly( electrically ) but the file that indicates the
> actual value of the pin will not update correctly. As an GPI( input ).
> Which has nothing to do with a conflict in overlays, as I have a custom
> overlay that initializes several GPIO pins, as well as a few PWM pins. Plus
> I am loading  BB-ADC-00A0.dtbo, and BB-W1-P8.26-00A0.dtbo, Where
> BB-W1-P8.26-00A0.dtbo is an adaption of the stock overlay
> BB-W1-P9.12-00A0.dtbo.
>
> None of the above overlays describe, or use any of the same pins. So there
> can not be a conflict between overlays in that regard.
>
> The fix I found for this problem, was to load all the overlays through
> /boot/uEnv.txt. Through cape_enable=bone_capemgr.enable_partno=
>
> The pin in question that we're having issues with is P8.16. Which if
> memory serves me correctly is also tied to another processor pad/pin
> through a zero ohm resistor.
>
> Before, all the GPI's would read correctly through the value file using a
> shell script. While this one pin would always read 0. Now, the pin value
> file works correctly.
>
> @Robert,
>
> Has the ability to load  multiple overlays through uboot been implemented
> yet ?
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/0dc4c9de-50d2-4d76-aacd-0bb3943ea467%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/0dc4c9de-50d2-4d76-aacd-0bb3943ea467%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/CALHSORq6DAji9xg-6JPHezWc2o8My8e2djQ-Js5gjVMHWSNRYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Bug, or conflict with kernels 4.x and universal IO

[William Hermans]

So this is probably more of an oversight than a bug. But when loading 
*some* overlays via config-pin overlay , *AFTER* already having 
loaded an overlay through /boot/uEnv.txt. At least one pin will still 
continue function correctly( electrically ) but the file that indicates the 
actual value of the pin will not update correctly. As an GPI( input ). 
Which has nothing to do with a conflict in overlays, as I have a custom 
overlay that initializes several GPIO pins, as well as a few PWM pins. Plus 
I am loading  BB-ADC-00A0.dtbo, and BB-W1-P8.26-00A0.dtbo, Where 
BB-W1-P8.26-00A0.dtbo is an adaption of the stock overlay 
BB-W1-P9.12-00A0.dtbo.

None of the above overlays describe, or use any of the same pins. So there 
can not be a conflict between overlays in that regard.

The fix I found for this problem, was to load all the overlays through 
/boot/uEnv.txt. Through cape_enable=bone_capemgr.enable_partno=

The pin in question that we're having issues with is P8.16. Which if memory 
serves me correctly is also tied to another processor pad/pin through a 
zero ohm resistor.

Before, all the GPI's would read correctly through the value file using a 
shell script. While this one pin would always read 0. Now, the pin value 
file works correctly.

@Robert,

Has the ability to load  multiple overlays through uboot been implemented 
yet ?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/0dc4c9de-50d2-4d76-aacd-0bb3943ea467%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Building a 2gb lxqt version

[William Hermans]

err, Samsung emmc modules can't be used with Samsung processors*

On Thu, Jan 5, 2017 at 10:28 PM, William Hermans <yyrk...@gmail.com> wrote:

> Rick, Yes, and in fact I'm going to buy one myself very soon because it
> has 2G ram quad A15's and quad A7's, GbE that's true GbE( not shared with
> another bus ) and USB 3.0. Plus, the emmc option is pretty dahmed fast in
> most cases. I think the Sandisk module( Samsung modules can't be used with
> Samsung modules for some reason ), which has to be used with the XU4, has
> fairly slow write speeds( 24-ish MB/s ) in the 16G emmc. But has amazingly
> fast reads at around 150MB/s.
>
> Anyway, it's not a mustang board with 16G ram or anything like that, but
> it also doesn't cost ~$1800 USD.
>
> On Thu, Jan 5, 2017 at 8:19 PM, Robert Nelson <robertcnel...@gmail.com>
> wrote:
>
>> On Thu, Jan 5, 2017 at 9:14 PM, Rick Mann <rm...@latencyzero.com> wrote:
>> >
>> >> On Jan 5, 2017, at 18:36 , Robert Nelson <robertcnel...@gmail.com>
>> wrote:
>> >>
>> >> that's why we just say beefy ARM system..
>> >
>> > What qualifies as "beefy" (and that I can get today)? Something like
>> this?
>> >
>> > http://www.hardkernel.com/main/products/prdt_info.php?g_cod
>> e=G143452239825
>>
>> 2GB, Dual Core with onboard sata is fine..
>>
>> 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/CAOCHtYjWSg8%3DKzszkzH_%2BWVhupc8KBAyHTgdQU
>> a2npn8nD64AQ%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/CALHSORpXrTvUnekeicNyXf7h-kMRNjYYYNzdNLj2BSMPWMw8rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Building a 2gb lxqt version

[William Hermans]

Rick, Yes, and in fact I'm going to buy one myself very soon because it has
2G ram quad A15's and quad A7's, GbE that's true GbE( not shared with
another bus ) and USB 3.0. Plus, the emmc option is pretty dahmed fast in
most cases. I think the Sandisk module( Samsung modules can't be used with
Samsung modules for some reason ), which has to be used with the XU4, has
fairly slow write speeds( 24-ish MB/s ) in the 16G emmc. But has amazingly
fast reads at around 150MB/s.

Anyway, it's not a mustang board with 16G ram or anything like that, but it
also doesn't cost ~$1800 USD.

On Thu, Jan 5, 2017 at 8:19 PM, Robert Nelson 
wrote:

> On Thu, Jan 5, 2017 at 9:14 PM, Rick Mann  wrote:
> >
> >> On Jan 5, 2017, at 18:36 , Robert Nelson 
> wrote:
> >>
> >> that's why we just say beefy ARM system..
> >
> > What qualifies as "beefy" (and that I can get today)? Something like
> this?
> >
> > http://www.hardkernel.com/main/products/prdt_info.php?g_
> code=G143452239825
>
> 2GB, Dual Core with onboard sata is fine..
>
> 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/CAOCHtYjWSg8%3DKzszkzH_%2BWVhupc8KBAyHTgdQUa2npn8nD64A
> Q%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/CALHSORoC3b-d84EtVKPto2P3aGd7LjSpD14ZmZ0wkYHswG3nDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] InitRamFs

[William Hermans]

Oh, and for additional informational purposes. ~/dev on my system is an NFS
share, I would not recommend writing files to the emmc, or an sdcard .  ..

On Thu, Jan 5, 2017 at 5:01 AM, William Hermans <yyrk...@gmail.com> wrote:

> My last worklog working with the initrd, which by the way is not required
> _just_to_add_ overlays. Robert has a script that can do this automatically
> for you. Just keep in mind that I tend to make small mistakes once in a
> while so my work logs can be superfluous . . .
>
> http://pastebin.com/naKbbRWd
>
>
> On Thu, Jan 5, 2017 at 4:39 AM, William Hermans <yyrk...@gmail.com> wrote:
>
>>
>>
>> On Thu, Jan 5, 2017 at 4:28 AM, Micka <mickamus...@gmail.com> wrote:
>>
>>> I saw that. But was not sure. The idea is to save the state of your ram?
>>>
>>>
>> I don't understand your question. But an initial ram disk is a very
>> minimalist Linux file system that is loaded at boot. Used for loading
>> various drivers, early. So for instance if you wanted to boot from say an
>> iSCSI type disk, You'd very likely have to initialize it through an initrd.
>>
>> Anyway, my definition is rather crude, like I said I'm going form pure
>> memory, and my memory is not always accurate. Better that you google for
>> your answers.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORqgwmwAer6ANNjcFir6NVSg5HhQBKH%2B9tW0L0ZFx75iwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] InitRamFs

[William Hermans]

My last worklog working with the initrd, which by the way is not required
_just_to_add_ overlays. Robert has a script that can do this automatically
for you. Just keep in mind that I tend to make small mistakes once in a
while so my work logs can be superfluous . . .

http://pastebin.com/naKbbRWd


On Thu, Jan 5, 2017 at 4:39 AM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Thu, Jan 5, 2017 at 4:28 AM, Micka <mickamus...@gmail.com> wrote:
>
>> I saw that. But was not sure. The idea is to save the state of your ram?
>>
>>
> I don't understand your question. But an initial ram disk is a very
> minimalist Linux file system that is loaded at boot. Used for loading
> various drivers, early. So for instance if you wanted to boot from say an
> iSCSI type disk, You'd very likely have to initialize it through an initrd.
>
> Anyway, my definition is rather crude, like I said I'm going form pure
> memory, and my memory is not always accurate. Better that you google for
> your answers.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORrT3prnJdFFfRy3TkvPE%3D_SAeUnLq7SsRE7uFt%2BZ%3DTSbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] InitRamFs

[William Hermans]

On Thu, Jan 5, 2017 at 4:28 AM, Micka  wrote:

> I saw that. But was not sure. The idea is to save the state of your ram?
>
>
I don't understand your question. But an initial ram disk is a very
minimalist Linux file system that is loaded at boot. Used for loading
various drivers, early. So for instance if you wanted to boot from say an
iSCSI type disk, You'd very likely have to initialize it through an initrd.

Anyway, my definition is rather crude, like I said I'm going form pure
memory, and my memory is not always accurate. Better that you google for
your answers.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORpv4YGmxFd0U499M0gY%2BeNiVT8sYQ_QmXM-CxPMTMdGyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] InitRamFs

[William Hermans]

Well. all this is from memory, so, I'm remembering that initramfs can be of
two types, but I seem to recall that there is non compressed, and gzip
compressed types of initrd's

debian@beaglebone:~$ sudo apt-get install file

debian@beaglebone:~$ sudo file /boot/initrd.img-4.4.9-bone-rt-r10
*/boot/initrd.img-4.4.9-bone-rt-r10: gzip compressed data, last modified:
Mon Jan  2 05:05:08 2017, from Unix*


On Thu, Jan 5, 2017 at 4:14 AM, William Hermans <yyrk...@gmail.com> wrote:

> You should really google this Micka,
>
> But initrd == initial ram disk, and initramfs is a cpio archived initial
> ram disk.
>
> On Thu, Jan 5, 2017 at 3:50 AM, Micka <mickamus...@gmail.com> wrote:
>
>> Hi, I would like how is it initialized in the beaglebone black ?
>>
>> What is initrd.img for ?
>>
>>
>> Micka,
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving 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/CAF%2BMRt%3DX6FeAf6T_5zB-XgQeovcdMp3wh-z2Mgz
>> 3f%2BqAxmqPHA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/beagleboard/CAF%2BMRt%3DX6FeAf6T_5zB-XgQeovcdMp3wh-z2Mgz3f%2BqAxmqPHA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [beagleboard] InitRamFs

[William Hermans]

You should really google this Micka,

But initrd == initial ram disk, and initramfs is a cpio archived initial
ram disk.

On Thu, Jan 5, 2017 at 3:50 AM, Micka  wrote:

> Hi, I would like how is it initialized in the beaglebone black ?
>
> What is initrd.img for ?
>
>
> Micka,
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CAF%2BMRt%3DX6FeAf6T_5zB-XgQeovcdMp3wh-
> z2Mgz3f%2BqAxmqPHA%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/CALHSORq7inYkWZCMRY2r_XZnuRdn_WOL-WHR2pdvaWDVknK3Eg%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]

So this is not guaranteed to work, but worth exploring. Give the following
a shot:
$ sudo alsa force-reload

But if that does not work. Try running:

$ sudo apt-get update
$ sudo apt-get install --fix-missing
$ sudo alsa force-reload
$ sudo reboot

I've seen mention of this multiple times, but always for Ubuntu it seems.
So maybe it'll cure your problems, maybe it won't.

On Mon, Jan 2, 2017 at 3:24 PM, William Hermans <yyrk...@gmail.com> wrote:

> Ok, my bad, I completely missed the part where you said it still output,
> just no sound from speakers . . .
>
> Well then, that will be problematic to troubleshoot.
>
> With that said, which kernel version are you running ? Ok, 4.4.30-ti-r64
>
> Have you tried different kernels ? newer, and older.
>
> On Mon, Jan 2, 2017 at 3:04 PM, William Hermans <yyrk...@gmail.com> wrote:
>
>> More to the point. Try running the command I gave above *AFTER* the audio
>> already stops. That'll at least tell you where, and why it fails. After
>> that you can investigate these reason why. Perhaps providing a fruitful
>> google search, or at minimum giving you something to report.
>>
>> On Mon, Jan 2, 2017 at 2:57 PM, William Hermans <yyrk...@gmail.com>
>> wrote:
>>
>>> $ strace -o /path/file speaker-test
>>>
>>>
>>> It'll at least tell you where it stops, and most likely why.
>>>
>>> On Mon, Jan 2, 2017 at 2:54 PM, John Franey <jjfra...@gmail.com> wrote:
>>>
>>>> William,
>>>>
>>>> Thanks.
>>>>
>>>> If your suggestion is that the speaker-test program itself is silencing
>>>> the hdmi output with some driver callI'm really doubtful.  I hope you
>>>> don't mind me saying so.  For a couple of reasons, but mainly: The audio
>>>> stops 10 minutes after boot time even if there is no audio process running
>>>> at the time.  For example, I can run speaker-test before 10min mark to
>>>> prove audio comes out right after boot.  Then turn off speaker-test before
>>>> the 10min mark, and run it after.  There is no audio.
>>>>
>>>> Do I understand you correctly? That is, strace speaker-test?
>>>>
>>>> ...or maybe I should strace another process that maybe disabling
>>>> sound.  Guessing which one is the root question anyway.
>>>>
>>>>
>>>> John
>>>>
>>>>
>>>> On Monday, January 2, 2017 at 3:05:14 PM UTC-5, William Hermans wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 2, 2017 at 12:28 PM, John Franey <jjfr...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> What do you think strace would show?
>>>>>>
>>>>>> I used strace a long time ago.  Back then, it traced the system calls
>>>>>> of an application process.   What should I look for in that output?
>>>>>>
>>>>>> Thanks,
>>>>>> John
>>>>>>
>>>>>
>>>>> Ok so then you know what strace is then I suppose. In your case, I
>>>>> would *imagine* strace would make things really easy to understand what is
>>>>> happening at that 10 minute mark. Since in your shoes, I'd run everything
>>>>> normally, but through strace. There is very likely going to be a lot of
>>>>> output. So you'd want to output that to a file, using the -o option( dash
>>>>> oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
>>>>> reading the file in reverse, until you find a potential culprit. That is:
>>>>> start of the end of the output file reading towards the beginning.
>>>>>
>>>>> Quite honestly, I have no idea what you should be looking for, But I
>>>>> suspect you'll know it when you see it. But if you do not, You could paste
>>>>> the last 10 lines of output here, or so. Then see if any one else here can
>>>>> spot a potential problem. I think that it could be very likely you will 
>>>>> not
>>>>> see an exact cause, but instead see something that should give a very good
>>>>> indication as to what the problem is.
>>>>>
>>>> --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "BeagleBoard" group.
>>>> To unsubscribe from this group and stop receiving 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/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/beagleboard/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%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/CALHSORrN0V6i9%2BH2LwAuuJ%2BUR-UAgmAXD5ryLctcw%3DF1s78Knw%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]

Ok, my bad, I completely missed the part where you said it still output,
just no sound from speakers . . .

Well then, that will be problematic to troubleshoot.

With that said, which kernel version are you running ? Ok, 4.4.30-ti-r64

Have you tried different kernels ? newer, and older.

On Mon, Jan 2, 2017 at 3:04 PM, William Hermans <yyrk...@gmail.com> wrote:

> More to the point. Try running the command I gave above *AFTER* the audio
> already stops. That'll at least tell you where, and why it fails. After
> that you can investigate these reason why. Perhaps providing a fruitful
> google search, or at minimum giving you something to report.
>
> On Mon, Jan 2, 2017 at 2:57 PM, William Hermans <yyrk...@gmail.com> wrote:
>
>> $ strace -o /path/file speaker-test
>>
>>
>> It'll at least tell you where it stops, and most likely why.
>>
>> On Mon, Jan 2, 2017 at 2:54 PM, John Franey <jjfra...@gmail.com> wrote:
>>
>>> William,
>>>
>>> Thanks.
>>>
>>> If your suggestion is that the speaker-test program itself is silencing
>>> the hdmi output with some driver callI'm really doubtful.  I hope you
>>> don't mind me saying so.  For a couple of reasons, but mainly: The audio
>>> stops 10 minutes after boot time even if there is no audio process running
>>> at the time.  For example, I can run speaker-test before 10min mark to
>>> prove audio comes out right after boot.  Then turn off speaker-test before
>>> the 10min mark, and run it after.  There is no audio.
>>>
>>> Do I understand you correctly? That is, strace speaker-test?
>>>
>>> ...or maybe I should strace another process that maybe disabling sound.
>>> Guessing which one is the root question anyway.
>>>
>>>
>>> John
>>>
>>>
>>> On Monday, January 2, 2017 at 3:05:14 PM UTC-5, William Hermans wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Jan 2, 2017 at 12:28 PM, John Franey <jjfr...@gmail.com> wrote:
>>>>
>>>>> What do you think strace would show?
>>>>>
>>>>> I used strace a long time ago.  Back then, it traced the system calls
>>>>> of an application process.   What should I look for in that output?
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>
>>>> Ok so then you know what strace is then I suppose. In your case, I
>>>> would *imagine* strace would make things really easy to understand what is
>>>> happening at that 10 minute mark. Since in your shoes, I'd run everything
>>>> normally, but through strace. There is very likely going to be a lot of
>>>> output. So you'd want to output that to a file, using the -o option( dash
>>>> oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
>>>> reading the file in reverse, until you find a potential culprit. That is:
>>>> start of the end of the output file reading towards the beginning.
>>>>
>>>> Quite honestly, I have no idea what you should be looking for, But I
>>>> suspect you'll know it when you see it. But if you do not, You could paste
>>>> the last 10 lines of output here, or so. Then see if any one else here can
>>>> spot a potential problem. I think that it could be very likely you will not
>>>> see an exact cause, but instead see something that should give a very good
>>>> indication as to what the problem is.
>>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving 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/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%40googlegroups.com
>>> <https://groups.google.com/d/msgid/beagleboard/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%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/CALHSORobu83x0AMj87FA%2BRLYhdEfF9XBKd%3DVwhzDxmXsOYmEhw%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]

More to the point. Try running the command I gave above *AFTER* the audio
already stops. That'll at least tell you where, and why it fails. After
that you can investigate these reason why. Perhaps providing a fruitful
google search, or at minimum giving you something to report.

On Mon, Jan 2, 2017 at 2:57 PM, William Hermans <yyrk...@gmail.com> wrote:

> $ strace -o /path/file speaker-test
>
>
> It'll at least tell you where it stops, and most likely why.
>
> On Mon, Jan 2, 2017 at 2:54 PM, John Franey <jjfra...@gmail.com> wrote:
>
>> William,
>>
>> Thanks.
>>
>> If your suggestion is that the speaker-test program itself is silencing
>> the hdmi output with some driver callI'm really doubtful.  I hope you
>> don't mind me saying so.  For a couple of reasons, but mainly: The audio
>> stops 10 minutes after boot time even if there is no audio process running
>> at the time.  For example, I can run speaker-test before 10min mark to
>> prove audio comes out right after boot.  Then turn off speaker-test before
>> the 10min mark, and run it after.  There is no audio.
>>
>> Do I understand you correctly? That is, strace speaker-test?
>>
>> ...or maybe I should strace another process that maybe disabling sound.
>> Guessing which one is the root question anyway.
>>
>>
>> John
>>
>>
>> On Monday, January 2, 2017 at 3:05:14 PM UTC-5, William Hermans wrote:
>>>
>>>
>>>
>>> On Mon, Jan 2, 2017 at 12:28 PM, John Franey <jjfr...@gmail.com> wrote:
>>>
>>>> What do you think strace would show?
>>>>
>>>> I used strace a long time ago.  Back then, it traced the system calls
>>>> of an application process.   What should I look for in that output?
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>
>>> Ok so then you know what strace is then I suppose. In your case, I would
>>> *imagine* strace would make things really easy to understand what is
>>> happening at that 10 minute mark. Since in your shoes, I'd run everything
>>> normally, but through strace. There is very likely going to be a lot of
>>> output. So you'd want to output that to a file, using the -o option( dash
>>> oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
>>> reading the file in reverse, until you find a potential culprit. That is:
>>> start of the end of the output file reading towards the beginning.
>>>
>>> Quite honestly, I have no idea what you should be looking for, But I
>>> suspect you'll know it when you see it. But if you do not, You could paste
>>> the last 10 lines of output here, or so. Then see if any one else here can
>>> spot a potential problem. I think that it could be very likely you will not
>>> see an exact cause, but instead see something that should give a very good
>>> indication as to what the problem is.
>>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving 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/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%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/CALHSORp5F6Ap5x51-PkOSv_-r5%3DSGN%3DA%2BTcTOZkbPC8tXiM77g%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]

$ strace -o /path/file speaker-test


It'll at least tell you where it stops, and most likely why.

On Mon, Jan 2, 2017 at 2:54 PM, John Franey <jjfra...@gmail.com> wrote:

> William,
>
> Thanks.
>
> If your suggestion is that the speaker-test program itself is silencing
> the hdmi output with some driver callI'm really doubtful.  I hope you
> don't mind me saying so.  For a couple of reasons, but mainly: The audio
> stops 10 minutes after boot time even if there is no audio process running
> at the time.  For example, I can run speaker-test before 10min mark to
> prove audio comes out right after boot.  Then turn off speaker-test before
> the 10min mark, and run it after.  There is no audio.
>
> Do I understand you correctly? That is, strace speaker-test?
>
> ...or maybe I should strace another process that maybe disabling sound.
> Guessing which one is the root question anyway.
>
>
> John
>
>
> On Monday, January 2, 2017 at 3:05:14 PM UTC-5, William Hermans wrote:
>>
>>
>>
>> On Mon, Jan 2, 2017 at 12:28 PM, John Franey <jjfr...@gmail.com> wrote:
>>
>>> What do you think strace would show?
>>>
>>> I used strace a long time ago.  Back then, it traced the system calls of
>>> an application process.   What should I look for in that output?
>>>
>>> Thanks,
>>> John
>>>
>>
>> Ok so then you know what strace is then I suppose. In your case, I would
>> *imagine* strace would make things really easy to understand what is
>> happening at that 10 minute mark. Since in your shoes, I'd run everything
>> normally, but through strace. There is very likely going to be a lot of
>> output. So you'd want to output that to a file, using the -o option( dash
>> oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
>> reading the file in reverse, until you find a potential culprit. That is:
>> start of the end of the output file reading towards the beginning.
>>
>> Quite honestly, I have no idea what you should be looking for, But I
>> suspect you'll know it when you see it. But if you do not, You could paste
>> the last 10 lines of output here, or so. Then see if any one else here can
>> spot a potential problem. I think that it could be very likely you will not
>> see an exact cause, but instead see something that should give a very good
>> indication as to what the problem is.
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving 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/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/49e4bbaa-0b7d-4e52-8b75-09f402c7db9d%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/CALHSORqtM_zQGcPmGt2WLhrWXysaWEyiCQA1KFK4QBE3DX54tw%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]

One thing that does come to mind is that having just recently removed the
kernel module from loading at boot on my own system here. Is that it
*could* be related to DMA. As it seems the sound modules do include a dma
sound module. Which, there has been some issues with DMA on this platform
in the past. I only remember seeing issues with dma in relation to SPI, but
perhaps it's also an issue for sound too ? Pure speculation on my behalf.

On Mon, Jan 2, 2017 at 1:05 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Mon, Jan 2, 2017 at 12:28 PM, John Franey <jjfra...@gmail.com> wrote:
>
>> What do you think strace would show?
>>
>> I used strace a long time ago.  Back then, it traced the system calls of
>> an application process.   What should I look for in that output?
>>
>> Thanks,
>> John
>>
>
> Ok so then you know what strace is then I suppose. In your case, I would
> *imagine* strace would make things really easy to understand what is
> happening at that 10 minute mark. Since in your shoes, I'd run everything
> normally, but through strace. There is very likely going to be a lot of
> output. So you'd want to output that to a file, using the -o option( dash
> oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
> reading the file in reverse, until you find a potential culprit. That is:
> start of the end of the output file reading towards the beginning.
>
> Quite honestly, I have no idea what you should be looking for, But I
> suspect you'll know it when you see it. But if you do not, You could paste
> the last 10 lines of output here, or so. Then see if any one else here can
> spot a potential problem. I think that it could be very likely you will not
> see an exact cause, but instead see something that should give a very good
> indication as to what the problem is.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORrZXZiAYuzvVAtJ3krrfdVUT5RjR-PP0NwvyF5CfCbjNA%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]

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

> What do you think strace would show?
>
> I used strace a long time ago.  Back then, it traced the system calls of
> an application process.   What should I look for in that output?
>
> Thanks,
> John
>

Ok so then you know what strace is then I suppose. In your case, I would
*imagine* strace would make things really easy to understand what is
happening at that 10 minute mark. Since in your shoes, I'd run everything
normally, but through strace. There is very likely going to be a lot of
output. So you'd want to output that to a file, using the -o option( dash
oh, as in Oscar ). Passed that I then( I would think ) becomes a matter of
reading the file in reverse, until you find a potential culprit. That is:
start of the end of the output file reading towards the beginning.

Quite honestly, I have no idea what you should be looking for, But I
suspect you'll know it when you see it. But if you do not, You could paste
the last 10 lines of output here, or so. Then see if any one else here can
spot a potential problem. I think that it could be very likely you will not
see an exact cause, but instead see something that should give a very good
indication as to what the problem is.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving 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/CALHSORqo-Y%3D%2BQ8JoDZzq2bJ2bbeBcGOtgiO7ugAMKAD_183Drw%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]

Yeah, I dont know. For me, it's all a moot point. The biggest hurdle to
understanding devices on the beaglebone, is first understanding the
hardware period. Then you need to understand the subsystems for each device
type - On Linux. After that, device trees, and device tree overlays all
start to make sense. Device tree files after all are only hardware
descriptions.

Anyway, to answer your question, about universal IO. No I don't have a
problem with it at all. But at some point, you'll realize that universal IO
is a generic set of device tree overlays, with a tool(config-pin) to make
pix muxing much simplier. e.g. an abstraction layer. At some point, you may
actually find yourself not wanting to use it. For me, part of my nature is
that I *have* to understand how things work, after which sometimes things
may become redundant. . .

On Mon, Jan 2, 2017 at 6:10 AM, Greg  wrote:

> Hi William, great inputs and perhaps we can ask Clayton to push these
> additional details to the repository.
>
> There should be a clear delimiter between the current and experimental
> improvements.
> I wonder if there is going to be a distinct cut-over to the revised Uboot
> process?  Maybe too soon to determine.
>
> Another thing:
>
> 1.  dtb-rebuilder
> https://github.com/RobertCNelson/dtb-rebuilder
> 2.  bb.org-overlays
> https://github.com/RobertCNelson/bb.org-overlays
>
> Perhaps not a newbie concern, as I think 1 and 2 above are at the
> intermediate level.
> I think these should at least be mentioned as they are important bits for
> dealing with the Beagleboard Device Tree ecosystem.
>
> 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/d7035e17-09a1-4839-b287-cfcecc60576d%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/CALHSORom8CGBs3uDUi3MGKwJcDmsVij5MN9H2CWWTG9XKan2oQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.