Re: [beagleboard] GPIO high during boot

[liyaoshi]

make it pull up in uboot
or
use as fixedregulator

  regulators {
compatible = "simple-bus";

reg_3p3v: 3p3v {
compatible = "regulator-fixed";
regulator-name = "3P3V";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
gpio = <&gpio3 23 0> ,<&gpio3 20 0>;



2014-11-25 23:55 GMT+08:00 Nils :

> Hello,
>
> I'm using the BeagleBone Black's GPIOs to drive some outputs.
> I'm running Kernel 3.8, so I used the Device Tree to configure the GPIOs.
> The cape is loaded during boot via the capemgr.
> But until the BBB has fully booted, some of the GPIOs are set to high.
> Is there a way to prevent this?
>
> Regards,
> Nils
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] How do I mount rootfs instead of fatfs with g_multi?

[Jason Lange]

I managed to change the partition number
...and g_multi is serving up my rootfs as pretty as a peach.

The odd thing is that I forgot to modify /etc/fstab and it still mounted (?)

"mount" gives me:

/dev/mmcblk0p1 on / type ext4 (rw,noatime,errors=remount-ro,data=ordered)
  ^^^
"cat /etc/fstab" gives this line:

/dev/mmcblk0p2  /  ext4  noatime,errors=remount-ro  0  1
  ^^^
...odd.

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

Re: [beagleboard] uSD Disconnects; Reset Fails with "CCCCC"; Re-Insert Boots

[William Hermans]

SRM aside. Gerald was saying that "" indicates that no boot-able
media was found. if "we" stop and think about this for a minute multiple
situations can cause this issue. Not least of which is physical sdcard
bracket is loose, and the media over time got screwed inside of it.

I've had this happen to me for inexplicable reasoning. I've taken the
sdcard out, blown it off, and have had it immediately start working again.
Why ? No idea . . .

On Tue, Nov 25, 2014 at 10:21 PM, Loren Amelang 
wrote:

>
> On Tuesday, November 25, 2014 5:11:56 AM UTC-8, Gerald wrote:
>>
>>  means the SD card is unreadable as a boot source and it cannot read
>> the eMMC either.  It is looking for a boot source.
>
>
> So you are saying that even though it was previously booted from the uSD,
> and was not power cycled, it would boot from the eMMC if the uSD was not
> available? I have a fully bootable image on my eMMC, so if it didn't take
> over and boot, that would mean something had blocked access to both uSD and
> eMMC.
>
> Removing the uSD and pressing Reset did not make the eMMC boot, so if your
> scenario is true the eMMC block survived Reset.
>
> Re-inserting the uSD with no further Reset lets it boot, so what could
> have been blocking both storage devices that merely inserting the uSD could
> fix?
>
> I was under the impression that only a power cycle could switch between
> uSD and eMMC. But SRM 6.8 does sort-of match your scenario:
> ---
> If you have a microSD card from which you need to boot from, hold the boot
> button
> down. On boot, the processor will look for the SPIO0 port first, then
> microSD on the
> MMC0 port, followed by USB0 and UART0. In the event there is no microSD
> card and
> the eMMC is empty, USB0 or UART0 could be used as the board source.
> ---
> But the language is not exactly clear...
>
> A slightly different view:
> 
> -
> The boot sequence is as follows : eMMC->microSD->USB port->serial
> and in the case that the boot button is pressed the sequence becomes
> microSD->USB port->serial.
> -
> That has been my understanding, that with the boot button held, eMMC will
> not boot even if the uSD is missing.
>
> The flowchart on that page says the sequence is traversed only once, but
> my experience shows it continues looping through all the available options.
> I do think their sequence is correct, though, as making the eMMC
> un-bootable will start the sequence at the uSD.
>
> Loren
>
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] serial UART async_low_latency does not seem to work. still > 10ms latency!

[liyaoshi]

Finally CONFIG_HZ  will take effects the scheduler

Assuming you  use default 32k clock source .from default kernel config and
source .

And what I guess if you get delay about 10ms , you might get a delay
schedule on 128HZ in default config

So , If you use 1024HZ ,you can get about 1ms latency .

And if the data is very frequency , fifo will not be the problem ,

what I just guess ,

if you only send several bytes in a peak time . fifo might be not enough to
generate an interrupt . there is a 64 BYTES fifo in omap uart host
controller .

If this case just for bluetooth like

skip fifo setting , just use 1024HZ ,it should be solve

2014-11-26 11:40 GMT+08:00 William Hermans :

> This is for UART ? There may even be a kernel boot config option that will
> work with this hardware as well. Meaning: No need to recompile the kernel
> to see if it works.
>
> On Tue, Nov 25, 2014 at 7:47 PM, liyaoshi  wrote:
>
>> So , can you try the 1024HZ for kernel scheduler ?
>> And , do you have fflush () after you write uart ?
>>
>> 2014-11-25 23:51 GMT+08:00 Thomas O :
>>
>>> Hey liyaoshi... I am running both uarts in 3,000,000 bytes per second!
>>> It is the problem that i get long delys 10ms or more so it is not related
>>> to speed but to latency.
>>> Also it seems the kernel only copies from kernel space to the uart in
>>> that same 10ms intervals. so it fills up the send queue for 10ms.
>>>
>>> On Tuesday, November 25, 2014 1:54:06 AM UTC, liyaoshi wrote:

 speed up to 921600bps or more if your remote uart can work

 2014-11-24 19:17 GMT+08:00 Thomas O :

> Hi all i am writing some software using the OMAP_SERIAL drivers to
> send and receive data from a c program (TERMIOS).
>
> I am seeing large delays 10ms ticks when sending and receiving data on
> the UARTS
>
  --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] uSD Disconnects; Reset Fails with "CCCCC"; Re-Insert Boots

[Loren Amelang]

On Tuesday, November 25, 2014 5:11:56 AM UTC-8, Gerald wrote:
>
>  means the SD card is unreadable as a boot source and it cannot read 
> the eMMC either.  It is looking for a boot source.


So you are saying that even though it was previously booted from the uSD, 
and was not power cycled, it would boot from the eMMC if the uSD was not 
available? I have a fully bootable image on my eMMC, so if it didn't take 
over and boot, that would mean something had blocked access to both uSD and 
eMMC. 

Removing the uSD and pressing Reset did not make the eMMC boot, so if your 
scenario is true the eMMC block survived Reset. 

Re-inserting the uSD with no further Reset lets it boot, so what could have 
been blocking both storage devices that merely inserting the uSD could fix? 

I was under the impression that only a power cycle could switch between uSD 
and eMMC. But SRM 6.8 does sort-of match your scenario:
---
If you have a microSD card from which you need to boot from, hold the boot 
button
down. On boot, the processor will look for the SPIO0 port first, then 
microSD on the
MMC0 port, followed by USB0 and UART0. In the event there is no microSD 
card and
the eMMC is empty, USB0 or UART0 could be used as the board source.
---
But the language is not exactly clear...  

A slightly different view:

-
The boot sequence is as follows : eMMC->microSD->USB port->serial 
and in the case that the boot button is pressed the sequence becomes 
microSD->USB port->serial.
-
That has been my understanding, that with the boot button held, eMMC will 
not boot even if the uSD is missing. 

The flowchart on that page says the sequence is traversed only once, but my 
experience shows it continues looping through all the available options. I 
do think their sequence is correct, though, as making the eMMC un-bootable 
will start the sequence at the uSD. 

Loren


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

Re: [beagleboard] How do I mount rootfs instead of fatfs with g_multi?

[Jason Lange]

I took the risk.

Since it was on an sd card I popped it out and used gparted to erase the
fatfs and then resize rootfs (leaving that holiest of 1M holes).  I booted
fine except for:

[   15.517979] g_multi musb-hdrc.0.auto: failed to start g_multi: -2

'mount' shows:

/dev/mmcblk0p2 on / type ext4 (rw,noatime,errors=remount-ro,data=ordered)

...it's still calling itself partition 2, which is probably a good thing
since /etc/fstab is referring to it  by its /dev entry

So now I'm going to figure out how to re-enumerate the partition and change
the fstab entry accordingly.

But, I'm hoping to be able to use this card to flash eMMC and now I'm
wondering if all this is going to break your scripts?



On Tue, Nov 25, 2014 at 6:50 PM, Robert Nelson 
wrote:

> On Tue, Nov 25, 2014 at 8:43 PM, Jason Lange  wrote:
> > Thank you Robert.
> >
> > Are there any caveats to erasing the fatfs and resizing rootfs ?  And if
> I
> > did that would your script mount rootfs without modification?
>
> Well... "in theory" with the newer images that should still work.. The
> big (and i mean big) issue, the u-boot (MLO/u-boot.img) files where
> dd'ed below the 1Mb position.  So as long as you leave the 1MB hole at
> the start of the drive alone, it 'should' work..
>
> Regards,
>
>
> --
> Robert Nelson
> http://www.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: how to make pwm_P8_13 low on boot?

[William Hermans]

IN short, use external hardware or do something cleaver like Peter G, and
reverse polarity. *OR* have an external "switch" that switches the PWM line
off, until you tell it to turn on. simples ?

On Tue, Nov 25, 2014 at 7:26 PM, Miguel Aveiro <
miguel.ave...@brascontrol.com.br> wrote:

>  It's not a kernel driver, I believe it's the processor default mode. You
> can check the processor datasheet:
>
> http://www.ti.com/product/AM3359/datasheet/terminal_description?search=pin,default#sprs717824
>
> If you want to change it earlier than linux, you need to set the pin in
> uboot (as far as I can understand). You can check the list because I know
> that I have already read something about change default IO in BBB. Or
> something about u-boot and gpio, like this:
> http://www.crashcourse.ca/wiki/index.php/U-Boot_on_the_BBB
>
> Hopefully, this can help a little
>
> Miguel Aveiro
>
> On 25-11-2014 22:28, janszymanski12...@gmail.com wrote:
>
> thanks, unfortunately didn't work for me.
>
> On Wednesday, 26 November 2014 10:02:27 UTC+11, Peter Gregory wrote:
>>
>> I had the same issue driving RBG Leds.
>> They were starting turned on full force since the PWM was driving high on
>> boot.
>> Changing the polarity worked for me.
>>
>> Is it possible the order of overlays is undoing your changes to
>> bone_pwm_P8_13?
>> Instead of:
>>
>> cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_
>> eqep2b,bone_pwm_P8_13,am33xx_pwm
>>
>> Maybe try it with your modifications being the last overlay to load:
>>
>> cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_
>> eqep2b,am33xx_pwm,bone_pwm_P8_13
>>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] serial UART async_low_latency does not seem to work. still > 10ms latency!

[William Hermans]

This is for UART ? There may even be a kernel boot config option that will
work with this hardware as well. Meaning: No need to recompile the kernel
to see if it works.

On Tue, Nov 25, 2014 at 7:47 PM, liyaoshi  wrote:

> So , can you try the 1024HZ for kernel scheduler ?
> And , do you have fflush () after you write uart ?
>
> 2014-11-25 23:51 GMT+08:00 Thomas O :
>
>> Hey liyaoshi... I am running both uarts in 3,000,000 bytes per second! It
>> is the problem that i get long delys 10ms or more so it is not related to
>> speed but to latency.
>> Also it seems the kernel only copies from kernel space to the uart in
>> that same 10ms intervals. so it fills up the send queue for 10ms.
>>
>> On Tuesday, November 25, 2014 1:54:06 AM UTC, liyaoshi wrote:
>>>
>>> speed up to 921600bps or more if your remote uart can work
>>>
>>> 2014-11-24 19:17 GMT+08:00 Thomas O :
>>>
 Hi all i am writing some software using the OMAP_SERIAL drivers to send
 and receive data from a c program (TERMIOS).

 I am seeing large delays 10ms ticks when sending and receiving data on
 the UARTS

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

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

Re: [beagleboard] How do I mount rootfs instead of fatfs with g_multi?

[Robert Nelson]

On Tue, Nov 25, 2014 at 8:43 PM, Jason Lange  wrote:
> Thank you Robert.
>
> Are there any caveats to erasing the fatfs and resizing rootfs ?  And if I
> did that would your script mount rootfs without modification?

Well... "in theory" with the newer images that should still work.. The
big (and i mean big) issue, the u-boot (MLO/u-boot.img) files where
dd'ed below the 1Mb position.  So as long as you leave the 1MB hole at
the start of the drive alone, it 'should' work..

Regards,


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

Re: [beagleboard] serial UART async_low_latency does not seem to work. still > 10ms latency!

[liyaoshi]

So , can you try the 1024HZ for kernel scheduler ?
And , do you have fflush () after you write uart ?

2014-11-25 23:51 GMT+08:00 Thomas O :

> Hey liyaoshi... I am running both uarts in 3,000,000 bytes per second! It
> is the problem that i get long delys 10ms or more so it is not related to
> speed but to latency.
> Also it seems the kernel only copies from kernel space to the uart in that
> same 10ms intervals. so it fills up the send queue for 10ms.
>
> On Tuesday, November 25, 2014 1:54:06 AM UTC, liyaoshi wrote:
>>
>> speed up to 921600bps or more if your remote uart can work
>>
>> 2014-11-24 19:17 GMT+08:00 Thomas O :
>>
>>> Hi all i am writing some software using the OMAP_SERIAL drivers to send
>>> and receive data from a c program (TERMIOS).
>>>
>>> I am seeing large delays 10ms ticks when sending and receiving data on
>>> the UARTS
>>>
>>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] How do I mount rootfs instead of fatfs with g_multi?

[Jason Lange]

Thank you Robert.

Are there any caveats to erasing the fatfs and resizing rootfs ?  And if I
did that would your script mount rootfs without modification?

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

Re: [beagleboard] Re: how to make pwm_P8_13 low on boot?

[Miguel Aveiro]

It's not a kernel driver, I believe it's the processor default mode. You 
can check the processor datasheet:

http://www.ti.com/product/AM3359/datasheet/terminal_description?search=pin,default#sprs717824

If you want to change it earlier than linux, you need to set the pin in 
uboot (as far as I can understand). You can check the list because I 
know that I have already read something about change default IO in BBB. 
Or something about u-boot and gpio, like this:

http://www.crashcourse.ca/wiki/index.php/U-Boot_on_the_BBB

Hopefully, this can help a little

Miguel Aveiro

On 25-11-2014 22:28, janszymanski12...@gmail.com wrote:

thanks, unfortunately didn't work for me.

On Wednesday, 26 November 2014 10:02:27 UTC+11, Peter Gregory wrote:

I had the same issue driving RBG Leds.
They were starting turned on full force since the PWM was driving
high on boot.
Changing the polarity worked for me.

Is it possible the order of overlays is undoing your changes to
bone_pwm_P8_13?
Instead of:


cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_eqep2b,bone_pwm_P8_13,am33xx_pwm


Maybe try it with your modifications being the last overlay to load:


cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_eqep2b,am33xx_pwm,bone_pwm_P8_13


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

For more options, visit https://groups.google.com/d/optout.


--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: TTYO0 mystery

[William Hermans]

remove "console=tty0" and see what that results in.

On Tue, Nov 25, 2014 at 7:16 PM, foreverska  wrote:

> console=tty0 console=/dev/ttyO0,115200n8
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
> root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet
> init=/lib/systemd/systemd
>
> On Tuesday, November 25, 2014 7:12:54 PM UTC-6, William Hermans wrote:
>>
>> Finally I wanted to see if I could finagle it working even with the
>>> terminal running on TTYO0 (login and run a program that doesn't poll the
>>> resource).  However, after changing uenv.txt back the terminal hasn't come
>>> back after several reboots.  I might have changed other stuff in trying to
>>> get it to work but I can't remember what.  What else controls the function
>>> of TTYO0?
>>>
>>
>> Double check to make sure the changes stuck. Also what is the pout put of
>> :
>>
>> *$ cat /proc/cmdline*
>>
>> ?
>>
>> On Tue, Nov 25, 2014 at 6:06 PM, William Hermans 
>> wrote:
>>
>>> Does the file */etc/inittab*
>>>
>>> Contain a line similar to this -> *T0:23:respawn:/sbin/getty -L ttyO0
>>> 115200 vt102*
>>>
>>> ??
>>>
>>> On Tue, Nov 25, 2014 at 2:41 PM, foreverska  wrote:
>>>
 Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring
 it on the other side.


 On Tuesday, November 25, 2014 3:35:18 PM UTC-6, foreverska wrote:
>
> Hi board,
>
> I'm working on a project and there are some comms traditionally done
> by RS232.  The "cape" already has a FTDI chip connected to J1 for
> convenience.  So I thought that might just be the easiest solution, tell C
> to latch onto ttyO0 and call it a day.  Well it worked alright but the 
> open
> terminal on that port kinda got in the way.  So I went into uEnv.txt and
> moved the terminal (the splurge of info on boot isn't a big deal).  
> However
> now TTYO0 is basically unresponsive.  When I open TTYUSB1 on my PC with
> screen the boot splurge happens and then after the kernel is booted there
> is no more output and it won't accept input.  When I run my application
> screen stays unresponsive.
>
> Finally I wanted to see if I could finagle it working even with the
> terminal running on TTYO0 (login and run a program that doesn't poll the
> resource).  However, after changing uenv.txt back the terminal hasn't come
> back after several reboots.  I might have changed other stuff in trying to
> get it to work but I can't remember what.  What else controls the function
> of TTYO0?
>
  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you 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.
 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: TTYO0 mystery

[foreverska]

/etc/initab does have that line

the output of cat /proc/cmdline is
console=tty0 console=/dev/ttyO0,115200n8 
capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G 
root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet 
init=/lib/systemd/systemd

I got the program working I think by sudo killall screen although I don't 
remember starting a screen since reboot so I'm not 100% that was the fix. 
 I still don't get a terminal on ttyO0 anyway.

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

Re: [beagleboard] PRU C Header files for am335x specific hardware

[William Hermans]

You'd honest to god do yourself a better favor by picking up a good book on
the gcc tool chain ( general term ), and just read. So, with that said, the
TI PRU C compiler is not gcc ( at least strictly speaking ), but what this
information will do is give you an idea of what all is involved whenever
doing *anything* of this nature. e.g. setting up toolchains.

My own first time doing this was a few years back with the msp430-gcc
toolchain. I can honestly say that this helped me understand everything
much better. Prior to that I was just tinkering around with C/C++ , C# etc.
Albeit for many years, and having some very nice results, at least on the
Windows desktop.

On Tue, Nov 25, 2014 at 7:08 PM, Peter Gregory  wrote:

> I've read mention of TI header files specific to the am335x PRU C language
> compiler.
> I've installed the PRU support packages for debian 3.8 kernel:
> am335x-pru-package ti-pru-cgt-installer.
> The PRU C compiler is installed and a C runtime library is installed.
> I can't find any header files under /usr/share/ti/cgt-pru/include that
> target the PRU memory layout and structures.
>
> The TI website mentions PRU header files targeting the am335x PRU:
> http://processors.wiki.ti.com/index.php/PRU-ICSS_Header_Files
>
> Are they included somewhere I haven't looked?
> I can create PRU layout unions and structures, but if some already exist,
> I'd rather use them.
> Also, if there is a document that spells all this out and I missed it,
> please add a link to where it is.
> All I've been able to find is this guide:  PRU Optimizing C/C++ Compiler
> User's Guide 
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Re: TTYO0 mystery

[foreverska]

console=tty0 console=/dev/ttyO0,115200n8 
capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G 
root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet 
init=/lib/systemd/systemd

On Tuesday, November 25, 2014 7:12:54 PM UTC-6, William Hermans wrote:
>
> Finally I wanted to see if I could finagle it working even with the 
>> terminal running on TTYO0 (login and run a program that doesn't poll the 
>> resource).  However, after changing uenv.txt back the terminal hasn't come 
>> back after several reboots.  I might have changed other stuff in trying to 
>> get it to work but I can't remember what.  What else controls the function 
>> of TTYO0?
>>
>
> Double check to make sure the changes stuck. Also what is the pout put of :
>
> *$ cat /proc/cmdline*
>
> ?
>
> On Tue, Nov 25, 2014 at 6:06 PM, William Hermans  > wrote:
>
>> Does the file */etc/inittab*
>>
>> Contain a line similar to this -> *T0:23:respawn:/sbin/getty -L ttyO0 
>> 115200 vt102*
>>
>> ??
>>
>> On Tue, Nov 25, 2014 at 2:41 PM, foreverska > > wrote:
>>
>>> Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring 
>>> it on the other side.
>>>
>>>
>>> On Tuesday, November 25, 2014 3:35:18 PM UTC-6, foreverska wrote:

 Hi board,

 I'm working on a project and there are some comms traditionally done by 
 RS232.  The "cape" already has a FTDI chip connected to J1 for 
 convenience.  So I thought that might just be the easiest solution, tell C 
 to latch onto ttyO0 and call it a day.  Well it worked alright but the 
 open 
 terminal on that port kinda got in the way.  So I went into uEnv.txt and 
 moved the terminal (the splurge of info on boot isn't a big deal).  
 However 
 now TTYO0 is basically unresponsive.  When I open TTYUSB1 on my PC with 
 screen the boot splurge happens and then after the kernel is booted there 
 is no more output and it won't accept input.  When I run my application 
 screen stays unresponsive.

 Finally I wanted to see if I could finagle it working even with the 
 terminal running on TTYO0 (login and run a program that doesn't poll the 
 resource).  However, after changing uenv.txt back the terminal hasn't come 
 back after several reboots.  I might have changed other stuff in trying to 
 get it to work but I can't remember what.  What else controls the function 
 of TTYO0?

>>>  -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you 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 .
>>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: TTYO0 mystery

[foreverska]

It does.

On Tuesday, November 25, 2014 7:06:48 PM UTC-6, William Hermans wrote:
>
> Does the file */etc/inittab*
>
> Contain a line similar to this -> *T0:23:respawn:/sbin/getty -L ttyO0 
> 115200 vt102*
>
> ??
>
> On Tue, Nov 25, 2014 at 2:41 PM, foreverska  > wrote:
>
>> Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring 
>> it on the other side.
>>
>>
>> On Tuesday, November 25, 2014 3:35:18 PM UTC-6, foreverska wrote:
>>>
>>> Hi board,
>>>
>>> I'm working on a project and there are some comms traditionally done by 
>>> RS232.  The "cape" already has a FTDI chip connected to J1 for 
>>> convenience.  So I thought that might just be the easiest solution, tell C 
>>> to latch onto ttyO0 and call it a day.  Well it worked alright but the open 
>>> terminal on that port kinda got in the way.  So I went into uEnv.txt and 
>>> moved the terminal (the splurge of info on boot isn't a big deal).  However 
>>> now TTYO0 is basically unresponsive.  When I open TTYUSB1 on my PC with 
>>> screen the boot splurge happens and then after the kernel is booted there 
>>> is no more output and it won't accept input.  When I run my application 
>>> screen stays unresponsive.
>>>
>>> Finally I wanted to see if I could finagle it working even with the 
>>> terminal running on TTYO0 (login and run a program that doesn't poll the 
>>> resource).  However, after changing uenv.txt back the terminal hasn't come 
>>> back after several reboots.  I might have changed other stuff in trying to 
>>> get it to work but I can't remember what.  What else controls the function 
>>> of TTYO0?
>>>
>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you 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 .
>> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU C Header files for am335x specific hardware

[Peter Gregory]

I've read mention of TI header files specific to the am335x PRU C language 
compiler.
I've installed the PRU support packages for debian 3.8 kernel: 
am335x-pru-package ti-pru-cgt-installer.
The PRU C compiler is installed and a C runtime library is installed.
I can't find any header files under /usr/share/ti/cgt-pru/include that 
target the PRU memory layout and structures.

The TI website mentions PRU header files targeting the am335x PRU:
http://processors.wiki.ti.com/index.php/PRU-ICSS_Header_Files

Are they included somewhere I haven't looked?
I can create PRU layout unions and structures, but if some already exist, 
I'd rather use them.
Also, if there is a document that spells all this out and I missed it, 
please add a link to where it is.
All I've been able to find is this guide:  PRU Optimizing C/C++ Compiler 
User's Guide 

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

Re: [beagleboard] How do I mount rootfs instead of fatfs with g_multi?

[Robert Nelson]

On Tue, Nov 25, 2014 at 7:29 PM, Jason Lange  wrote:
> Hello All,
>
> At one point I accidentally had the root filesystem mounting and perusable
> from my desktop file browser -- which was useful to me (unlike the fatfs).
> I am trying to duplicate this deliberately, but can't find where to
> configure this.  Any help with this is much appreciated...my google-fu is
> failing me.

There's an example here:

/opt/scripts/boot/am335x_evm.sh

(web)
https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L83

Just point the "file=/dev/mmcblkXpY" option in g_multi to the rootfs partition..

Regards,

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

[beagleboard] How do I mount rootfs instead of fatfs with g_multi?

[Jason Lange]

Hello All,

At one point I accidentally had the root filesystem mounting and perusable 
from my desktop file browser -- which was useful to me (unlike the fatfs).  
I am trying to duplicate this deliberately, but can't find where to 
configure this.  Any help with this is much appreciated...my google-fu is 
failing me.

Thanks in advance.

j.

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

[beagleboard] Re: GPIO Header Pins that can be muxed to the PRU

[Peter Gregory]

That would be sweet!
That would give me 10 pins exactly on PRU0
I was basing my info on the Beaglebone Black reference manual.



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

Re: [beagleboard] Re: JavaFX 8 on BeagleBone Black (SGX driver problem?)

[Robert Nelson]

On Tue, Nov 25, 2014 at 7:18 PM, William Hermans  wrote:

> LOL !!!
>
>
> *The oddity is the BeagleBone Black (BBB) which can outperform the quad
> core i.MX6 in all tests*
>
>
> I'll have to read that in fuller detail when im 100% sober . . .
>

Since that was 2013, i wouldn't be surprised a tunned uni-processor arm
kernel from that era was just more task optimized then an arm smp setup.

Regards,

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

Re: [beagleboard] Re: JavaFX 8 on BeagleBone Black (SGX driver problem?)

[William Hermans]

LOL !!!


*The oddity is the BeagleBone Black (BBB) which can outperform the quad
core i.MX6 in all tests*


I'll have to read that in fuller detail when im 100% sober . . .




On Tue, Nov 25, 2014 at 6:15 PM, Robert Nelson 
wrote:

>
>
> On Tue, Nov 25, 2014 at 7:10 PM, Robert Nelson 
> wrote:
>
>>
>>
>> On Tue, Nov 25, 2014 at 6:45 PM, William Hermans 
>> wrote:
>>
>>> OH, it's still building..  Been at it almost 24 hours...

 It's in the middle of the test suite:

 compiler/java/jar running ...
 Passed: tools/javac/annotations/
>>>
>>> repeatingAnnotations/combo/ReflectionTest.java
>>> Passed:
>>> tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java
>>> Passed:
>>> tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java
>>> Passed:
>>> tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java
>>>
>>> Compare with:
>>>
>>> https://buildd.debian.org/status/fetch.php?pkg=openjdk-8&arch=armhf&ver=8u40~b04-2.1&stamp=1413548257
>>>
>>> which took over 5 days..
>>>
>>> I think my omap5 is a little more powerful then debian's armhf builder..
>>>
>>>
>>> My god, what on earth could possibly take that long to build on a quad
>>> with 2GB of ram ? I'm assuming you're using the wanderboard . . . but you
>>> mentioned omap5 above, which is what ? the X15 ? lol
>>>
>>> If OpenJDK takes that long the kernel must take weeks . . . and yeah,
>>> mostly that was sarcasm.
>>>
>>>
>> For the heavy stuff i use an omap5 (Cortex-A15 dual core 1.5Ghz) it's got
>> 2GB of ram just like the wand quad's. It's actually faster then the Quad
>> A9's at 1Ghz.
>>
>> The omap5 is two generations prior to the am57xx found on the x15..
>>
>
> Just a quick random benchmark which had the omap5 @ 800Mhz..
>
>
> http://www.cnx-software.com/2013/08/17/texas-instruments-omap5432-evm-benchmarked-against-odroid-u2-beaglebone-black-gk802-and-an-intel-core-i7-2600k-based-pc/
>
> Regards,
>
> --
> Robert Nelson
> http://www.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: JavaFX 8 on BeagleBone Black (SGX driver problem?)

[Robert Nelson]

On Tue, Nov 25, 2014 at 7:10 PM, Robert Nelson 
wrote:

>
>
> On Tue, Nov 25, 2014 at 6:45 PM, William Hermans 
> wrote:
>
>> OH, it's still building..  Been at it almost 24 hours...
>>>
>>> It's in the middle of the test suite:
>>>
>>> compiler/java/jar running ...
>>> Passed: tools/javac/annotations/
>>
>> repeatingAnnotations/combo/ReflectionTest.java
>> Passed:
>> tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java
>> Passed:
>> tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java
>> Passed:
>> tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java
>>
>> Compare with:
>>
>> https://buildd.debian.org/status/fetch.php?pkg=openjdk-8&arch=armhf&ver=8u40~b04-2.1&stamp=1413548257
>>
>> which took over 5 days..
>>
>> I think my omap5 is a little more powerful then debian's armhf builder..
>>
>>
>> My god, what on earth could possibly take that long to build on a quad
>> with 2GB of ram ? I'm assuming you're using the wanderboard . . . but you
>> mentioned omap5 above, which is what ? the X15 ? lol
>>
>> If OpenJDK takes that long the kernel must take weeks . . . and yeah,
>> mostly that was sarcasm.
>>
>>
> For the heavy stuff i use an omap5 (Cortex-A15 dual core 1.5Ghz) it's got
> 2GB of ram just like the wand quad's. It's actually faster then the Quad
> A9's at 1Ghz.
>
> The omap5 is two generations prior to the am57xx found on the x15..
>

Just a quick random benchmark which had the omap5 @ 800Mhz..

http://www.cnx-software.com/2013/08/17/texas-instruments-omap5432-evm-benchmarked-against-odroid-u2-beaglebone-black-gk802-and-an-intel-core-i7-2600k-based-pc/

Regards,

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

Re: [beagleboard] Re: TTYO0 mystery

[William Hermans]

>
> Finally I wanted to see if I could finagle it working even with the
> terminal running on TTYO0 (login and run a program that doesn't poll the
> resource).  However, after changing uenv.txt back the terminal hasn't come
> back after several reboots.  I might have changed other stuff in trying to
> get it to work but I can't remember what.  What else controls the function
> of TTYO0?
>

Double check to make sure the changes stuck. Also what is the pout put of :

*$ cat /proc/cmdline*

?

On Tue, Nov 25, 2014 at 6:06 PM, William Hermans  wrote:

> Does the file */etc/inittab*
>
> Contain a line similar to this -> *T0:23:respawn:/sbin/getty -L ttyO0
> 115200 vt102*
>
> ??
>
> On Tue, Nov 25, 2014 at 2:41 PM, foreverska  wrote:
>
>> Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring
>> it on the other side.
>>
>>
>> On Tuesday, November 25, 2014 3:35:18 PM UTC-6, foreverska wrote:
>>>
>>> Hi board,
>>>
>>> I'm working on a project and there are some comms traditionally done by
>>> RS232.  The "cape" already has a FTDI chip connected to J1 for
>>> convenience.  So I thought that might just be the easiest solution, tell C
>>> to latch onto ttyO0 and call it a day.  Well it worked alright but the open
>>> terminal on that port kinda got in the way.  So I went into uEnv.txt and
>>> moved the terminal (the splurge of info on boot isn't a big deal).  However
>>> now TTYO0 is basically unresponsive.  When I open TTYUSB1 on my PC with
>>> screen the boot splurge happens and then after the kernel is booted there
>>> is no more output and it won't accept input.  When I run my application
>>> screen stays unresponsive.
>>>
>>> Finally I wanted to see if I could finagle it working even with the
>>> terminal running on TTYO0 (login and run a program that doesn't poll the
>>> resource).  However, after changing uenv.txt back the terminal hasn't come
>>> back after several reboots.  I might have changed other stuff in trying to
>>> get it to work but I can't remember what.  What else controls the function
>>> of TTYO0?
>>>
>>  --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [beagleboard] Custom Beaglebone black Audio cape with TLV320AIC3110

[Rick]

Thanks, Peter. I'm doing something similar for the first pass of this, but if 
it works out, I'll want to make the cape so I can make a few more (they are 
intended to be gifts for special people), and so others can do the same.

Mine doesn't actually have a radio or clock in it. It's just an appliance that 
plays MP3s.

> On Nov 25, 2014, at 17:08 , Peter Gregory  wrote:
> 
> I'm developing a clock-radio device using a USB sound card and a USB radio 
> tuner.
> Since it is a one-off project, I decided to use existing USB devices: 
> 
> ADS RDX-155-EF Instant FM Music - $7.50
> Plugable USB Audio Adapter - $7.95
> 
> Just a suggestion.
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/8RU9ayMPBlc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: JavaFX 8 on BeagleBone Black (SGX driver problem?)

[Robert Nelson]

On Tue, Nov 25, 2014 at 6:45 PM, William Hermans  wrote:

> OH, it's still building..  Been at it almost 24 hours...
>>
>> It's in the middle of the test suite:
>>
>> compiler/java/jar running ...
>> Passed: tools/javac/annotations/
>
> repeatingAnnotations/combo/ReflectionTest.java
> Passed:
> tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java
> Passed:
> tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java
> Passed:
> tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java
>
> Compare with:
>
> https://buildd.debian.org/status/fetch.php?pkg=openjdk-8&arch=armhf&ver=8u40~b04-2.1&stamp=1413548257
>
> which took over 5 days..
>
> I think my omap5 is a little more powerful then debian's armhf builder..
>
>
> My god, what on earth could possibly take that long to build on a quad
> with 2GB of ram ? I'm assuming you're using the wanderboard . . . but you
> mentioned omap5 above, which is what ? the X15 ? lol
>
> If OpenJDK takes that long the kernel must take weeks . . . and yeah,
> mostly that was sarcasm.
>
>
For the heavy stuff i use an omap5 (Cortex-A15 dual core 1.5Ghz) it's got
2GB of ram just like the wand quad's. It's actually faster then the Quad
A9's at 1Ghz.

The omap5 is two generations prior to the am57xx found on the x15..

Regards,

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

[beagleboard] Re: Custom Beaglebone black Audio cape with TLV320AIC3110

[Peter Gregory]

I'm developing a clock-radio device using a USB sound card and a USB radio 
tuner.
Since it is a one-off project, I decided to use existing USB devices: 

ADS RDX-155-EF Instant FM Music - $7.50
Plugable USB Audio Adapter - $7.95

Just a suggestion.

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

Re: [beagleboard] Re: TTYO0 mystery

[William Hermans]

Does the file */etc/inittab*

Contain a line similar to this -> *T0:23:respawn:/sbin/getty -L ttyO0
115200 vt102*

??

On Tue, Nov 25, 2014 at 2:41 PM, foreverska  wrote:

> Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring it
> on the other side.
>
>
> On Tuesday, November 25, 2014 3:35:18 PM UTC-6, foreverska wrote:
>>
>> Hi board,
>>
>> I'm working on a project and there are some comms traditionally done by
>> RS232.  The "cape" already has a FTDI chip connected to J1 for
>> convenience.  So I thought that might just be the easiest solution, tell C
>> to latch onto ttyO0 and call it a day.  Well it worked alright but the open
>> terminal on that port kinda got in the way.  So I went into uEnv.txt and
>> moved the terminal (the splurge of info on boot isn't a big deal).  However
>> now TTYO0 is basically unresponsive.  When I open TTYUSB1 on my PC with
>> screen the boot splurge happens and then after the kernel is booted there
>> is no more output and it won't accept input.  When I run my application
>> screen stays unresponsive.
>>
>> Finally I wanted to see if I could finagle it working even with the
>> terminal running on TTYO0 (login and run a program that doesn't poll the
>> resource).  However, after changing uenv.txt back the terminal hasn't come
>> back after several reboots.  I might have changed other stuff in trying to
>> get it to work but I can't remember what.  What else controls the function
>> of TTYO0?
>>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Accessing and controlling PMIC, TPS65217C, from shell

[William Hermans]

resandevinwebb, btw thank you for sharing the information. This is of
personal interest for me as well.

On Tue, Nov 25, 2014 at 5:58 PM, William Hermans  wrote:

> Ah ok my mistake I misread your post initially as I did not read the whole
> thing sorry.
>
> So yes, I would think you would have to write your own kernel module, or
> modify the existing I2C bus utils. Recompile, etc.
>
> On Tue, Nov 25, 2014 at 5:52 PM, William Hermans 
> wrote:
>
>> *>  i2cdetect -l*
>>> *> on Beaglebone Black it will give you:*
>>> *i2c-0   unknown OMAP I2C adapterN/A*
>>> *i2c-1   unknown OMAP I2C adapterN/A*
>>>
>>
>> Ok, so I2C to the PMIC does work. A person on the group got this working
>> from within uboot and posted about it over a month ago.
>>
>> When i asked, "ok great, but how does that translate to this working
>> while under linux?" He / she replied: something to the effect of "I'm
>> unsure".
>>
>> Anyway, the point is it is possible to control the PMIC, or at minimum
>> communicate with it via software + I2C. I am however not a Linux kernel
>> expert / guru, but I *would* assume this would require a kernel level
>> driver to work.
>>
>>
>> On Tue, Nov 25, 2014 at 2:31 PM,  wrote:
>>
>>> Hi liyaoshi,
>>>
>>> So how can I measure the charge percentage left in the battery? Is there
>>> an example that I can use? TPS65217 does not allow us to read the battery
>>> voltage if I am right or at least I cannot find it in datasheet. what
>>> voltage are you talking about?
>>>
>>> I did some progress with controlling PMIC and I can use i2c utilities to
>>> read and write to it. However I have to use -f to force it since kernel is
>>> using the I2C interface. How can I do this cleanly from user space without
>>> forcing it? One way would be to expand the driver to add extra features.
>>> Does anyone know a good example that I can use as starting point? Is there
>>> a better/easier way to do this?
>>> my procedure is as follow:
>>>
>>>  i2cdetect -l
>>> on Beaglebone Black it will give you:
>>>
>>> i2c-0   unknown OMAP I2C adapterN/A
>>>
>>> i2c-1   unknown OMAP I2C adapterN/A
>>>
>>>
>>> For reading status register of TPS65217. device is at 0x25 and status
>>> register is 0x0a on I2C0
>>>
>>> i2cget [-f] [-y] i2cbus chip-address [data-address [mode]]
>>>
>>>
>>> sudo i2cdet -f 0 0c24 0x0a
>>>
>>> WARNING! This program can confuse your I2C bus, cause data loss and
>>> worse!
>>>
>>> I will read from device file /dev/i2c-0, chip address 0x24, data address
>>>
>>> 0x0a, using read byte data.
>>>
>>> Continue?
>>> [Y/n]
>>> 0x88
>>>
>>>
>>> To set battery charging voltage to 4.2V
>>>
>>> i2cset [-f] [-y] [-m mask] [-r] i2cbus chip-address data-address [value]
>>> ... [mode]
>>> sudo i2cset -f -m 0x30 0 0x24 0x05 0x20
>>>
>>> WARNING! This program can confuse your I2C bus, cause data loss and
>>> worse!
>>>
>>> I will write to device file /dev/i2c-0, chip address 0x24, data address
>>>
>>> 0x05, data 0x20 (masked), mode byte.
>>>
>>> Continue? [Y/n]
>>>
>>> Old value 0x80, write mask 0x30: Will write 0xa0 to register 0x05
>>>
>>> Continue? [Y/n]
>>>
>>>
>>> Thanks a lot
>>>
>>>
>>>
>>> On Monday, November 24, 2014 6:08:45 PM UTC-8, liyaoshi wrote:

 As I know , if only 2 wires , you can not access the Li+battery status
 , you can just get voltage value from PMU

 There always another 1 wire to get the communication with MCU in
 battery module

 2014-11-25 8:52 GMT+08:00 :

> Hi All,
>
> I connected a rechargeable Li+ battery to my BBB TP5, TP6, TP7, and
> TP8. I shorted TP5 and TP6 and added a 10uF decoupling capacitor. In
> addition, I connected TS to GND with a 9K resistor which is 10K || 75K
> according to the datasheet and the board boots fine from battery.
> Now my question is that how can I monitor the battery status(how much
> they are charged) or change the setting of PMIC, TPS65127C from shell. For
> instance, I would like to set the charging voltage to 4.2 rather than the
> default 4.1V. Or I would like to turn on/off WLED etc. Is there a tool,
> like Alsamixer, for this? if not what would be the best approach for
> controlling PMIC from shell? I posted it here because PMIC uses I2C
> interface to talk to AM335x.
>
>
> 
>
>
> 
>
> Thanks for your time and consideration.
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard

Re: [beagleboard] Accessing and controlling PMIC, TPS65217C, from shell

[William Hermans]

Ah ok my mistake I misread your post initially as I did not read the whole
thing sorry.

So yes, I would think you would have to write your own kernel module, or
modify the existing I2C bus utils. Recompile, etc.

On Tue, Nov 25, 2014 at 5:52 PM, William Hermans  wrote:

> *>  i2cdetect -l*
>> *> on Beaglebone Black it will give you:*
>> *i2c-0   unknown OMAP I2C adapterN/A*
>> *i2c-1   unknown OMAP I2C adapterN/A*
>>
>
> Ok, so I2C to the PMIC does work. A person on the group got this working
> from within uboot and posted about it over a month ago.
>
> When i asked, "ok great, but how does that translate to this working while
> under linux?" He / she replied: something to the effect of "I'm unsure".
>
> Anyway, the point is it is possible to control the PMIC, or at minimum
> communicate with it via software + I2C. I am however not a Linux kernel
> expert / guru, but I *would* assume this would require a kernel level
> driver to work.
>
>
> On Tue, Nov 25, 2014 at 2:31 PM,  wrote:
>
>> Hi liyaoshi,
>>
>> So how can I measure the charge percentage left in the battery? Is there
>> an example that I can use? TPS65217 does not allow us to read the battery
>> voltage if I am right or at least I cannot find it in datasheet. what
>> voltage are you talking about?
>>
>> I did some progress with controlling PMIC and I can use i2c utilities to
>> read and write to it. However I have to use -f to force it since kernel is
>> using the I2C interface. How can I do this cleanly from user space without
>> forcing it? One way would be to expand the driver to add extra features.
>> Does anyone know a good example that I can use as starting point? Is there
>> a better/easier way to do this?
>> my procedure is as follow:
>>
>>  i2cdetect -l
>> on Beaglebone Black it will give you:
>>
>> i2c-0   unknown OMAP I2C adapterN/A
>>
>> i2c-1   unknown OMAP I2C adapterN/A
>>
>>
>> For reading status register of TPS65217. device is at 0x25 and status
>> register is 0x0a on I2C0
>>
>> i2cget [-f] [-y] i2cbus chip-address [data-address [mode]]
>>
>>
>> sudo i2cdet -f 0 0c24 0x0a
>>
>> WARNING! This program can confuse your I2C bus, cause data loss and worse
>> !
>>
>> I will read from device file /dev/i2c-0, chip address 0x24, data address
>>
>> 0x0a, using read byte data.
>>
>> Continue?
>> [Y/n]
>> 0x88
>>
>>
>> To set battery charging voltage to 4.2V
>>
>> i2cset [-f] [-y] [-m mask] [-r] i2cbus chip-address data-address [value]
>> ... [mode]
>> sudo i2cset -f -m 0x30 0 0x24 0x05 0x20
>>
>> WARNING! This program can confuse your I2C bus, cause data loss and worse
>> !
>>
>> I will write to device file /dev/i2c-0, chip address 0x24, data address
>>
>> 0x05, data 0x20 (masked), mode byte.
>>
>> Continue? [Y/n]
>>
>> Old value 0x80, write mask 0x30: Will write 0xa0 to register 0x05
>>
>> Continue? [Y/n]
>>
>>
>> Thanks a lot
>>
>>
>>
>> On Monday, November 24, 2014 6:08:45 PM UTC-8, liyaoshi wrote:
>>>
>>> As I know , if only 2 wires , you can not access the Li+battery status ,
>>> you can just get voltage value from PMU
>>>
>>> There always another 1 wire to get the communication with MCU in battery
>>> module
>>>
>>> 2014-11-25 8:52 GMT+08:00 :
>>>
 Hi All,

 I connected a rechargeable Li+ battery to my BBB TP5, TP6, TP7, and
 TP8. I shorted TP5 and TP6 and added a 10uF decoupling capacitor. In
 addition, I connected TS to GND with a 9K resistor which is 10K || 75K
 according to the datasheet and the board boots fine from battery.
 Now my question is that how can I monitor the battery status(how much
 they are charged) or change the setting of PMIC, TPS65127C from shell. For
 instance, I would like to set the charging voltage to 4.2 rather than the
 default 4.1V. Or I would like to turn on/off WLED etc. Is there a tool,
 like Alsamixer, for this? if not what would be the best approach for
 controlling PMIC from shell? I posted it here because PMIC uses I2C
 interface to talk to AM335x.


 


 

 Thanks for your time and consideration.

  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you 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.
 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 a

Re: [beagleboard] Accessing and controlling PMIC, TPS65217C, from shell

[William Hermans]

>
> *>  i2cdetect -l*
> *> on Beaglebone Black it will give you:*
> *i2c-0   unknown OMAP I2C adapterN/A*
> *i2c-1   unknown OMAP I2C adapterN/A*
>

Ok, so I2C to the PMIC does work. A person on the group got this working
from within uboot and posted about it over a month ago.

When i asked, "ok great, but how does that translate to this working while
under linux?" He / she replied: something to the effect of "I'm unsure".

Anyway, the point is it is possible to control the PMIC, or at minimum
communicate with it via software + I2C. I am however not a Linux kernel
expert / guru, but I *would* assume this would require a kernel level
driver to work.


On Tue, Nov 25, 2014 at 2:31 PM,  wrote:

> Hi liyaoshi,
>
> So how can I measure the charge percentage left in the battery? Is there
> an example that I can use? TPS65217 does not allow us to read the battery
> voltage if I am right or at least I cannot find it in datasheet. what
> voltage are you talking about?
>
> I did some progress with controlling PMIC and I can use i2c utilities to
> read and write to it. However I have to use -f to force it since kernel is
> using the I2C interface. How can I do this cleanly from user space without
> forcing it? One way would be to expand the driver to add extra features.
> Does anyone know a good example that I can use as starting point? Is there
> a better/easier way to do this?
> my procedure is as follow:
>
>  i2cdetect -l
> on Beaglebone Black it will give you:
>
> i2c-0   unknown OMAP I2C adapterN/A
>
> i2c-1   unknown OMAP I2C adapterN/A
>
>
> For reading status register of TPS65217. device is at 0x25 and status
> register is 0x0a on I2C0
>
> i2cget [-f] [-y] i2cbus chip-address [data-address [mode]]
>
>
> sudo i2cdet -f 0 0c24 0x0a
>
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
>
> I will read from device file /dev/i2c-0, chip address 0x24, data address
>
> 0x0a, using read byte data.
>
> Continue?
> [Y/n]
> 0x88
>
>
> To set battery charging voltage to 4.2V
>
> i2cset [-f] [-y] [-m mask] [-r] i2cbus chip-address data-address [value]
> ... [mode]
> sudo i2cset -f -m 0x30 0 0x24 0x05 0x20
>
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
>
> I will write to device file /dev/i2c-0, chip address 0x24, data address
>
> 0x05, data 0x20 (masked), mode byte.
>
> Continue? [Y/n]
>
> Old value 0x80, write mask 0x30: Will write 0xa0 to register 0x05
>
> Continue? [Y/n]
>
>
> Thanks a lot
>
>
>
> On Monday, November 24, 2014 6:08:45 PM UTC-8, liyaoshi wrote:
>>
>> As I know , if only 2 wires , you can not access the Li+battery status ,
>> you can just get voltage value from PMU
>>
>> There always another 1 wire to get the communication with MCU in battery
>> module
>>
>> 2014-11-25 8:52 GMT+08:00 :
>>
>>> Hi All,
>>>
>>> I connected a rechargeable Li+ battery to my BBB TP5, TP6, TP7, and TP8.
>>> I shorted TP5 and TP6 and added a 10uF decoupling capacitor. In addition, I
>>> connected TS to GND with a 9K resistor which is 10K || 75K according to the
>>> datasheet and the board boots fine from battery.
>>> Now my question is that how can I monitor the battery status(how much
>>> they are charged) or change the setting of PMIC, TPS65127C from shell. For
>>> instance, I would like to set the charging voltage to 4.2 rather than the
>>> default 4.1V. Or I would like to turn on/off WLED etc. Is there a tool,
>>> like Alsamixer, for this? if not what would be the best approach for
>>> controlling PMIC from shell? I posted it here because PMIC uses I2C
>>> interface to talk to AM335x.
>>>
>>>
>>> 
>>>
>>>
>>> 
>>>
>>> Thanks for your time and consideration.
>>>
>>>  --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you 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.
>>> 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.
> 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+uns

Re: [beagleboard] Re: JavaFX 8 on BeagleBone Black (SGX driver problem?)

[William Hermans]

>
> OH, it's still building..  Been at it almost 24 hours...
>
> It's in the middle of the test suite:
>
> compiler/java/jar running ...
> Passed: tools/javac/annotations/

repeatingAnnotations/combo/ReflectionTest.java
Passed:
tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java
Passed:
tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java
Passed:
tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java

Compare with:
https://buildd.debian.org/status/fetch.php?pkg=openjdk-8&arch=armhf&ver=8u40~b04-2.1&stamp=1413548257

which took over 5 days..

I think my omap5 is a little more powerful then debian's armhf builder..


My god, what on earth could possibly take that long to build on a quad with
2GB of ram ? I'm assuming you're using the wanderboard . . . but you
mentioned omap5 above, which is what ? the X15 ? lol

If OpenJDK takes that long the kernel must take weeks . . . and yeah,
mostly that was sarcasm.

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

Re: [beagleboard] serialWrite function in Bonescript/javascript

[William Hermans]

John,

I think the bigger issue is *why* would you do this ? If you're going to
send the data out the serial port anyhow, why not just send the data as its
available ?

How about an explanation as to why you would do this, and how you would use
it in an application. I will however say this. What you're doing is
terribly inefficient on memory usage.

On Tue, Nov 25, 2014 at 4:30 PM, John Mladenik 
wrote:

> I only showed the individual write as an example that also does not work,
> it only performs the very first serialWrite and ignores the rest.
> Your example does work with various delays between each byte, but this
> will work for me.   I might still use the:
>
>  b.serialWrite(port, [
> dio6Hi[0] ,dio6Hi[1] ,dio6Hi[2] ,dio6Hi[3] ,dio6Hi[4] ,dio6Hi[5]
> ,dio6Hi[6] ,dio6Hi[7] ,dio6Hi[8] ,dio6Hi[9],
> dio6Hi[10],dio6Hi[11],dio6Hi[12],dio6Hi[13],dio6Hi[14],
> dio6Hi[15],dio6Hi[16],dio6Hi[17],dio6Hi[18],dio6Hi[19] ]);
>
> command since it writes the bytes consecutive with no delay between each
> byte and so is a little more efficient.   At 9600 baud it took just over
> 20ms to send out the data without the delays between bytes and just under
> 200ms with the delays.
>
> Thanks for the quick response.  I learn something every time you post :)
>
>
> On Tuesday, November 25, 2014 3:14:08 PM UTC-8, Jason Kridner wrote:
>>
>> On Tue, Nov 25, 2014 at 4:23 PM, John Mladenik 
>> wrote:
>> > Does anyone know an easier way to send a packet of hex data out the
>> serial
>> > port.  Here is what works for me
>> >
>> > var dio6Hi = [0x7E, 0x00, 0x10, 0x17, 0x01, 0x00, 0x13, 0xA2, 0x00,
>> > 0x40, 0xC0, 0xA9, 0x99, 0xFF, 0xFE, 0x02, 0x44, 0x36, 0x05, 0x72 ];
>> >
>> > b.serialWrite(port, [
>> > dio6Hi[0] ,dio6Hi[1] ,dio6Hi[2] ,dio6Hi[3] ,dio6Hi[4]
>> ,dio6Hi[5]
>> > ,dio6Hi[6] ,dio6Hi[7] ,dio6Hi[8] ,dio6Hi[9],
>> >
>> > dio6Hi[10],dio6Hi[11],dio6Hi[12],dio6Hi[13],dio6Hi[14],
>> dio6Hi[15],dio6Hi[16],dio6Hi[17],dio6Hi[18],dio6Hi[19]
>> > ]);
>> >
>> > This will write all of the data in variable  dio6Hi  out of the UART in
>> > order that I want.But I would like to do this or something like it:
>> >
>> > for (var i = 0; i < dio6Hi.length; i++) {
>> > b.serialWrite(port, [dio6Hi[i]] );
>> > }
>> >
>> > or even this:
>> >
>> >   b.serialWrite(port, [dio6Hi[0]] );
>> >   b.serialWrite(port, [dio6Hi[1]] );
>> >   b.serialWrite(port, [dio6Hi[2]] );
>> >
>> >.
>> >.
>> >.
>> >   b.serialWrite(port, [dio6Hi[18]] );
>> >   b.serialWrite(port, [dio6Hi[19]] );
>> >
>> > Either of these do not work they only send out the first byte in dio[0]
>> and
>> > then stop.   Is there any way with the serialWrite function to index
>> the
>> > variable with a "for" or other command in order to simplify sending out
>> an
>> > array of numbers?
>>
>> I believe your primary issue here is that the calls to b.serialWrite()
>> are asynchronous and you aren't waiting for the writes to complete.
>> I'm not really sure why you'd want to have individual calls to write
>> each byte, but you could try something like:
>>
>> var i = 0;
>> mySerialWrites();
>> function mySerialWrites() {
>>   if(i < dio6Hi.length) {
>> b.serialWrite(port, [dio6Hi[i]], mySerialWrites);
>> i++;
>>   }
>> }
>>
>> I haven't tested this, but I think it might be your issue. Let us know.
>>
>> >
>> > --
>> > For more options, visit http://beagleboard.org/discuss
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "BeagleBoard" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to beagleboard...@googlegroups.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: how to make pwm_P8_13 low on boot?

[janszymanski12345]

thanks, unfortunately didn't work for me.

On Wednesday, 26 November 2014 10:02:27 UTC+11, Peter Gregory wrote:
>
> I had the same issue driving RBG Leds. 
> They were starting turned on full force since the PWM was driving high on 
> boot. 
> Changing the polarity worked for me. 
>
> Is it possible the order of overlays is undoing your changes to 
> bone_pwm_P8_13? 
> Instead of: 
>
> cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_eqep2b,bone_pwm_P8_13,am33xx_pwm
>  
>
>
> Maybe try it with your modifications being the last overlay to load: 
>
> cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_eqep2b,am33xx_pwm,bone_pwm_P8_13
>  
>
>

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

[beagleboard] Re: Custom Beaglebone black Audio cape with TLV320AIC3110

[Rick M]

On Thursday, November 13, 2014 5:46:32 PM UTC-8, resande...@gmail.com wrote:
>
> Hi,
>
> I am trying to design a cape with TLV320AIC3110 for Beaglebone black using 
> I2c2 and Mcasp0. 
>

Alex, I, too am looking to develop an audio application using a BBB, but 
know very little about Linux audio (I'm a capable-enough hardware engineer, 
and have lots of software development experience on iOS/OS X and numerous 
small processors, bare-metal, but not a ton of Linux). I essentially want 
to build a "radio," so I'll be developing a cape with audio out and 
amplifier. Your choice of IC might be adequate, or I'll find some other I2S 
chip (is I2S the same as your "I2c2"?). My cape will also have some 
additional electronics for interfacing the rest of my "radio's" user 
interface.

Could I ask you additional questions as I get further into this?

Thanks!

-- 
Rick

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

[beagleboard] [BBB] USB-OTG working in Kernel 3.15 or later?

[Adam Lee]

Hello everyone, I have a custom AM335x board that is not changing its USB 
mode based on the ID pin. 

My kernel is mainline 3.17.4. And my device tree file sets my two USBs as 
'otg' (dr_mode = 'otg'). 
I see the two usb ports when I type `lsusb` or `usb-devices` in the prompt. 
Yet nothing happens when I plugin a device. My board neither goes into the 
host nor peripheral mode. 

When I set my USBs to `host` (dr_mode = 'host'), they work just fine as 
hosts.

USB-OTG has worked well in pre-device-tree kernel (3.4). I was able to use 
open a console session over ttyACM.  

Hence it's definitely the kernel change between 3.4 and 3.17. 

A good data point for me would be whether or not USB-OTG is working with 
BBB running kernel 3.15 or later (ideal running 3.17). If yes, I know the 
problem is my device tree configuration. 

Any help would be appreciated!

Adam

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

[beagleboard] Re: GPIO Header Pins that can be muxed to the PRU

[Jon E]

Hi,

I believe the pins on P8 (11/12/15/16) that you've listed as used by the 
eMMC are free to use. I'd double check the schematic, but think the eMMC is 
connected as per the mode1 pinmux.

Jon.

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

Re: [beagleboard] serialWrite function in Bonescript/javascript

[John Mladenik]

I only showed the individual write as an example that also does not work, 
it only performs the very first serialWrite and ignores the rest.   
Your example does work with various delays between each byte, but this will 
work for me.   I might still use the:

 b.serialWrite(port, [
dio6Hi[0] ,dio6Hi[1] ,dio6Hi[2] ,dio6Hi[3] ,dio6Hi[4] ,dio6Hi[5] 
,dio6Hi[6] ,dio6Hi[7] ,dio6Hi[8] ,dio6Hi[9],

dio6Hi[10],dio6Hi[11],dio6Hi[12],dio6Hi[13],dio6Hi[14],dio6Hi[15],dio6Hi[16],dio6Hi[17],dio6Hi[18],dio6Hi[19]
 
]);

command since it writes the bytes consecutive with no delay between each 
byte and so is a little more efficient.   At 9600 baud it took just over 
20ms to send out the data without the delays between bytes and just under 
200ms with the delays.  

Thanks for the quick response.  I learn something every time you post :)


On Tuesday, November 25, 2014 3:14:08 PM UTC-8, Jason Kridner wrote:
>
> On Tue, Nov 25, 2014 at 4:23 PM, John Mladenik  > wrote: 
> > Does anyone know an easier way to send a packet of hex data out the 
> serial 
> > port.  Here is what works for me 
> > 
> > var dio6Hi = [0x7E, 0x00, 0x10, 0x17, 0x01, 0x00, 0x13, 0xA2, 0x00, 
> > 0x40, 0xC0, 0xA9, 0x99, 0xFF, 0xFE, 0x02, 0x44, 0x36, 0x05, 0x72 ]; 
> > 
> > b.serialWrite(port, [ 
> > dio6Hi[0] ,dio6Hi[1] ,dio6Hi[2] ,dio6Hi[3] ,dio6Hi[4] ,dio6Hi[5] 
> > ,dio6Hi[6] ,dio6Hi[7] ,dio6Hi[8] ,dio6Hi[9], 
> > 
> > 
> dio6Hi[10],dio6Hi[11],dio6Hi[12],dio6Hi[13],dio6Hi[14],dio6Hi[15],dio6Hi[16],dio6Hi[17],dio6Hi[18],dio6Hi[19]
>  
>
> > ]); 
> > 
> > This will write all of the data in variable  dio6Hi  out of the UART in 
> > order that I want.But I would like to do this or something like it: 
> > 
> > for (var i = 0; i < dio6Hi.length; i++) { 
> > b.serialWrite(port, [dio6Hi[i]] ); 
> > } 
> > 
> > or even this: 
> > 
> >   b.serialWrite(port, [dio6Hi[0]] ); 
> >   b.serialWrite(port, [dio6Hi[1]] ); 
> >   b.serialWrite(port, [dio6Hi[2]] ); 
> > 
> >. 
> >. 
> >. 
> >   b.serialWrite(port, [dio6Hi[18]] ); 
> >   b.serialWrite(port, [dio6Hi[19]] ); 
> > 
> > Either of these do not work they only send out the first byte in dio[0] 
> and 
> > then stop.   Is there any way with the serialWrite function to index the 
> > variable with a "for" or other command in order to simplify sending out 
> an 
> > array of numbers? 
>
> I believe your primary issue here is that the calls to b.serialWrite() 
> are asynchronous and you aren't waiting for the writes to complete. 
> I'm not really sure why you'd want to have individual calls to write 
> each byte, but you could try something like: 
>
> var i = 0; 
> mySerialWrites(); 
> function mySerialWrites() { 
>   if(i < dio6Hi.length) { 
> b.serialWrite(port, [dio6Hi[i]], mySerialWrites); 
> i++; 
>   } 
> } 
>
> I haven't tested this, but I think it might be your issue. Let us know. 
>
> > 
> > -- 
> > For more options, visit http://beagleboard.org/discuss 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "BeagleBoard" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to beagleboard...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] serialWrite function in Bonescript/javascript

[Jason Kridner]

On Tue, Nov 25, 2014 at 4:23 PM, John Mladenik  wrote:
> Does anyone know an easier way to send a packet of hex data out the serial
> port.  Here is what works for me
>
> var dio6Hi = [0x7E, 0x00, 0x10, 0x17, 0x01, 0x00, 0x13, 0xA2, 0x00,
> 0x40, 0xC0, 0xA9, 0x99, 0xFF, 0xFE, 0x02, 0x44, 0x36, 0x05, 0x72 ];
>
> b.serialWrite(port, [
> dio6Hi[0] ,dio6Hi[1] ,dio6Hi[2] ,dio6Hi[3] ,dio6Hi[4] ,dio6Hi[5]
> ,dio6Hi[6] ,dio6Hi[7] ,dio6Hi[8] ,dio6Hi[9],
>
> dio6Hi[10],dio6Hi[11],dio6Hi[12],dio6Hi[13],dio6Hi[14],dio6Hi[15],dio6Hi[16],dio6Hi[17],dio6Hi[18],dio6Hi[19]
> ]);
>
> This will write all of the data in variable  dio6Hi  out of the UART in
> order that I want.But I would like to do this or something like it:
>
> for (var i = 0; i < dio6Hi.length; i++) {
> b.serialWrite(port, [dio6Hi[i]] );
> }
>
> or even this:
>
>   b.serialWrite(port, [dio6Hi[0]] );
>   b.serialWrite(port, [dio6Hi[1]] );
>   b.serialWrite(port, [dio6Hi[2]] );
>
>.
>.
>.
>   b.serialWrite(port, [dio6Hi[18]] );
>   b.serialWrite(port, [dio6Hi[19]] );
>
> Either of these do not work they only send out the first byte in dio[0] and
> then stop.   Is there any way with the serialWrite function to index the
> variable with a "for" or other command in order to simplify sending out an
> array of numbers?

I believe your primary issue here is that the calls to b.serialWrite()
are asynchronous and you aren't waiting for the writes to complete.
I'm not really sure why you'd want to have individual calls to write
each byte, but you could try something like:

var i = 0;
mySerialWrites();
function mySerialWrites() {
  if(i < dio6Hi.length) {
b.serialWrite(port, [dio6Hi[i]], mySerialWrites);
i++;
  }
}

I haven't tested this, but I think it might be your issue. Let us know.

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

Re: [beagleboard] Re: how to make pwm_P8_13 low on boot?

[Peter Gregory]

I had the same issue driving RBG Leds.
They were starting turned on full force since the PWM was driving high on boot.
Changing the polarity worked for me.

Is it possible the order of overlays is undoing your changes to bone_pwm_P8_13?
Instead of:

cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_eqep2b,bone_pwm_P8_13,am33xx_pwm

Maybe try it with your modifications being the last overlay to load:

cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_eqep2b,am33xx_pwm,bone_pwm_P8_13

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

Re: [beagleboard] Re: JavaFX 8 on BeagleBone Black (SGX driver problem?)

[Robert Nelson]

On Tue, Nov 25, 2014 at 4:42 PM, Nick Apperley  wrote:
> Can't see the OpenJDK 8 build. I take it the build failed?
>
> Have some fantastic news on the Ubuntu front. Various OpenJDK 8 packages via
> an unofficial PPA are available for Ubuntu 12.04 (Precise) and 14.04
> (Trusty).

OH, it's still building..  Been at it almost 24 hours...

It's in the middle of the test suite:

compiler/java/jar running ...
Passed: tools/javac/annotations/repeatingAnnotations/combo/ReflectionTest.java
Passed: 
tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java
Passed: tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java
Passed: 
tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java

Compare with:
https://buildd.debian.org/status/fetch.php?pkg=openjdk-8&arch=armhf&ver=8u40~b04-2.1&stamp=1413548257

which took over 5 days..

I think my omap5 is a little more powerful then debian's armhf builder..

Regards,

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

Re: [beagleboard] Re: JavaFX 8 on BeagleBone Black (SGX driver problem?)

[Nick Apperley]

Can't see the OpenJDK 8 build. I take it the build failed?

Have some fantastic news on the Ubuntu front. Various OpenJDK 8 packages 
 via an unofficial PPA 
 are available for Ubuntu 12.04 (Precise) and 14.04 
(Trusty).


On Tuesday, 25 November 2014 11:23:20 UTC+13, RobertCNelson wrote:
>
> On Mon, Nov 24, 2014 at 4:21 PM, Nick Apperley  > wrote: 
> > Hopefully if the custom build of OpenJDK 8 works then that can be 
> adjusted 
> > to work on the stable Debian/Ubuntu images for the BBB. 
>
> If the test build goes thru, i'll just add it to: 
>
> https://github.com/rcn-ee/repos 
>
> So it'll end up on repos.rcn-ee.net  :) 
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Accessing and controlling PMIC, TPS65217C, from shell

[resandevinwebb]

Hi liyaoshi,

So how can I measure the charge percentage left in the battery? Is there an 
example that I can use? TPS65217 does not allow us to read the battery 
voltage if I am right or at least I cannot find it in datasheet. what 
voltage are you talking about? 

I did some progress with controlling PMIC and I can use i2c utilities to 
read and write to it. However I have to use -f to force it since kernel is 
using the I2C interface. How can I do this cleanly from user space without 
forcing it? One way would be to expand the driver to add extra features. 
Does anyone know a good example that I can use as starting point? Is there 
a better/easier way to do this?
my procedure is as follow:

 i2cdetect -l
on Beaglebone Black it will give you:

i2c-0   unknown OMAP I2C adapterN/A

i2c-1   unknown OMAP I2C adapterN/A


For reading status register of TPS65217. device is at 0x25 and status 
register is 0x0a on I2C0

i2cget [-f] [-y] i2cbus chip-address [data-address [mode]]


sudo i2cdet -f 0 0c24 0x0a

WARNING! This program can confuse your I2C bus, cause data loss and worse!

I will read from device file /dev/i2c-0, chip address 0x24, data address

0x0a, using read byte data.

Continue?
[Y/n]
0x88


To set battery charging voltage to 4.2V

i2cset [-f] [-y] [-m mask] [-r] i2cbus chip-address data-address [value] ... 
[mode]
sudo i2cset -f -m 0x30 0 0x24 0x05 0x20

WARNING! This program can confuse your I2C bus, cause data loss and worse!

I will write to device file /dev/i2c-0, chip address 0x24, data address

0x05, data 0x20 (masked), mode byte.

Continue? [Y/n]

Old value 0x80, write mask 0x30: Will write 0xa0 to register 0x05

Continue? [Y/n]


Thanks a lot



On Monday, November 24, 2014 6:08:45 PM UTC-8, liyaoshi wrote:
>
> As I know , if only 2 wires , you can not access the Li+battery status , 
> you can just get voltage value from PMU
>
> There always another 1 wire to get the communication with MCU in battery 
> module  
>
> 2014-11-25 8:52 GMT+08:00 >:
>
>> Hi All,
>>
>> I connected a rechargeable Li+ battery to my BBB TP5, TP6, TP7, and TP8. 
>> I shorted TP5 and TP6 and added a 10uF decoupling capacitor. In addition, I 
>> connected TS to GND with a 9K resistor which is 10K || 75K according to the 
>> datasheet and the board boots fine from battery. 
>> Now my question is that how can I monitor the battery status(how much 
>> they are charged) or change the setting of PMIC, TPS65127C from shell. For 
>> instance, I would like to set the charging voltage to 4.2 rather than the 
>> default 4.1V. Or I would like to turn on/off WLED etc. Is there a tool, 
>> like Alsamixer, for this? if not what would be the best approach for 
>> controlling PMIC from shell? I posted it here because PMIC uses I2C 
>> interface to talk to AM335x.
>>
>>
>> 
>>
>>
>> 
>>
>> Thanks for your time and consideration.
>>
>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you 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 .
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: how to make pwm_P8_13 low on boot?

[Jason Lange]

>
> The inverter is not a solution as on boot initial pin value is low and
> after the device tree is loaded it jumps high until the application
> software (controlling pwm) takes over.
> I will use it as a temporary solution.
>
> Cheers
>
> Jan
>
>
> On Wednesday, 26 November 2014 08:45:34 UTC+11, Jason Lange wrote:


- after power on the logic level on P8_13 is low (as I want it to be)
>> - after that (loading dtc overlay) the logic level on P8_13 become high
>> (I dont want it)
>>
>
Sorry, I missed this.  The 74HC04 would work if it started high and stayed
that way.  Do you need to use an overlay?

 *Maybe if you modified the initial device tree, perhaps with Roberts
system for the 3.14 kernel it would start high and you could flip it.*

http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb

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

[beagleboard] Re: BBB: Serial Wiring For External Device Over UART1

[John Mladenik]

I would make sure that the Analog device IC has the output TX connected to 
the TX on the Ext. Board and the input RX to RX.  I wish I had a nickel for 
every time I saw the DTE (Data Terminal Equipment) and DCE (Data 
Communications Equipment) swapped.

 

 It would be helpfull to probe the RX and TX line to see if there is 
activity on it using a logic analyzer or o-scope.  This will let you verify 
the TX/RX and baud rates of the two devices.   I did not have to change 
any configuration or enable anything to get the UARTS working using 
Bonescript commands on my two Rev C BBB's.   I have a simple HTML/Java app 
that you can point to from Chrome to send out data bytes on the UART if you 
want that let me know, I havn't gotten to the receive part of my app yet.  
  I am probably less experienced than you with software so this is the only 
way I got the UARTs working.  



  

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

Re: [beagleboard] Re: how to make pwm_P8_13 low on boot?

[janszymanski12345]

 Thanks Jason,

 There is a hardware solution to my problem in a form of a tiny logic 
08 (AND gate). The PWM is connected to one input and an extra ENABLE signal 
from GPIO is connected to another input. On the output the resulting gated 
PWM signal will appear when the ENABLE signal goes high from the 
application.
The solution however is non-elegant and can be avoided if I had a better 
knowledge of the software - in this case a PWM driver and it's interaction 
with a device tree overlay.

The inverter is not a solution as on boot initial pin value is low and 
after the device tree is loaded it jumps high until the application 
software (controlling pwm) takes over.
I will use it as a temporary solution.

Cheers

Jan


On Wednesday, 26 November 2014 08:45:34 UTC+11, Jason Lange wrote:
>
>
>
> - after power on the logic level on P8_13 is low (as I want it to be)
>>> - after that (loading dtc overlay) the logic level on P8_13 become high 
>>> (I dont want it)
>>>
>>
> Sorry, I missed this.  The 74HC04 would work if it started high and stayed 
> that way.  Do you need to use an overlay?  Maybe if you modified the 
> initial device tree, perhaps with Roberts system for the 3.14 kernel it 
> would start high and you could flip 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBB: Serial Wiring For External Device Over UART1

[John Mladenik]

I think the 3.3V you are connecting to is an output from the BBB look at U4 
on the schematics, this is an LDO (LowDropout Regulator)  I think 
connecting an external supply to that point could damage U4 on the 
BBB.  You really want to input the power on the VDD_5V input the feeds 
the Texas Instruments Power Management chip on the BBB.  

 

I would make sure that the Analog device IC has the output TX connected to 
the TX on the Ext. Board and the input RX to RX.  I wish I had a nickel for 
every time I saw the DTE (Data Terminal Equipment) and DCE (Data 
Communications Equipment) swapped.

 

 It would be helpfull to probe the RX and TX line to see if there is 
activity on it using a logic analyzer or o-scope.  This will let you verify 
the TX/RX and baud rates of the two devices.   I did not have to change 
any configuration or enable anything to get the UARTS working using 
Bonescript commands on my two Rev C BBB's.   I have a simple HTML/Java app 
that you can point to from Chrome to send out data bytes on the UART if you 
want that let me know, I haven't gotten to the receive part of my app yet.  
  I am probably less experienced than you with software so this is the only 
way I got the UARTs working.  

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

[beagleboard] Re: how to make pwm_P8_13 low on boot?

[janszymanski12345]

 Thanks Peter, 

 I have exercised that option already before posting and somehow it didn't 
work.

Changing the parameters (and recompiling) didn't change the default values, 
so my conclusion is that they might be
 
somehow hard-coded in a kernel driver.
Jan

On Monday, 24 November 2014 09:58:19 UTC+11, janszyma...@gmail.com wrote:
>
> Hi,
>
> I'm trying to use pwm on BBB
> Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
> GNU/Linux
> I have modified uEnv.tx
> ...
>
> cape_enable=capemgr.enable_partno=BB-UART1,SPI-4SS,bone_eqep2b,bone_pwm_P8_13,am33xx_pwm
> ...
> and /etc/default/capemgr
> ...
> # Options to pass to capemgr
> CAPE=SPI-4SS,bone_eqep2b,bone_pwm_P8_13,am33xx_pwm
> ...
>
> after booting I have correctly in slots
>  0: 54:PF--- 
>  1: 55:PF--- 
>  2: 56:PF--- 
>  3: 57:PF--- 
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
> 10: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_P8_13
> 11: ff:P-O-L Override Board Name,00A0,Override Manuf,am33xx_pwm
> 12: ff:P-O-L Override Board Name,00A0,Override Manuf,SPI-4SS
> 13: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_eqep2b
>
> and pwm works, but,
>
> - after power on the logic level on P8_13 is low (as I want it to be)
> - after that (loading dtc overlay) the logic level on P8_13 become high (I 
> dont want it)
>
> My attempt to modify  /lib/firmware/bone_pwm_P8_13-00A0.dts and then 
> recompiling doesn't effect any of:
> /sys/devices/ocp.3/pwm_test_P8_13.11/ duty, period, polarity, run, 
>
> As I don't want the motor connected to PWM to run, before the applications 
> takes over the control,
> can anyone help me to achieve it?
>
> Jan
>
>
>
>

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

Re: [beagleboard] Re: how to make pwm_P8_13 low on boot?

[Jason Lange]

- after power on the logic level on P8_13 is low (as I want it to be)
>> - after that (loading dtc overlay) the logic level on P8_13 become high
>> (I dont want it)
>>
>
Sorry, I missed this.  The 74HC04 would work if it started high and stayed
that way.  Do you need to use an overlay?  Maybe if you modified the
initial device tree, perhaps with Roberts system for the 3.14 kernel it
would start high and you could flip 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: TTYO0 mystery

[foreverska]

Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring it 
on the other side.

On Tuesday, November 25, 2014 3:35:18 PM UTC-6, foreverska wrote:
>
> Hi board,
>
> I'm working on a project and there are some comms traditionally done by 
> RS232.  The "cape" already has a FTDI chip connected to J1 for convenience. 
>  So I thought that might just be the easiest solution, tell C to latch onto 
> ttyO0 and call it a day.  Well it worked alright but the open terminal on 
> that port kinda got in the way.  So I went into uEnv.txt and moved the 
> terminal (the splurge of info on boot isn't a big deal).  However now TTYO0 
> is basically unresponsive.  When I open TTYUSB1 on my PC with screen the 
> boot splurge happens and then after the kernel is booted there is no more 
> output and it won't accept input.  When I run my application screen stays 
> unresponsive.
>
> Finally I wanted to see if I could finagle it working even with the 
> terminal running on TTYO0 (login and run a program that doesn't poll the 
> resource).  However, after changing uenv.txt back the terminal hasn't come 
> back after several reboots.  I might have changed other stuff in trying to 
> get it to work but I can't remember what.  What else controls the function 
> of TTYO0?
>

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

[beagleboard] TTYO0 mystery

[foreverska]

Hi board,

I'm working on a project and there are some comms traditionally done by 
RS232.  The "cape" already has a FTDI chip connected to J1 for convenience. 
 So I thought that might just be the easiest solution, tell C to latch onto 
ttyO0 and call it a day.  Well it worked alright but the open terminal on 
that port kinda got in the way.  So I went into uEnv.txt and moved the 
terminal (the splurge of info on boot isn't a big deal).  However now TTYO0 
is basically unresponsive.  When I open TTYUSB1 on my PC with screen the 
boot splurge happens and then after the kernel is booted there is no more 
output and it won't accept input.  When I run my application screen stays 
unresponsive.

Finally I wanted to see if I could finagle it working even with the 
terminal running on TTYO0 (login and run a program that doesn't poll the 
resource).  However, after changing uenv.txt back the terminal hasn't come 
back after several reboots.  I might have changed other stuff in trying to 
get it to work but I can't remember what.  What else controls the function 
of TTYO0?

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

Re: [beagleboard] Re: how to make pwm_P8_13 low on boot?

[Jason Lange]

>From hardware you could use a 74HC04 to invert the signal.  No need for an
additional enable line.

Cheers.

On Tue, Nov 25, 2014 at 1:27 PM, ja...@bigpond.net.au 
wrote:

>
>  Thanks Peter,
>
>  I have exercised that option already before posting and somehow it didn't
> work.
>
> Changing the parameters (and recompiling) didn't change the default
> values, so my conclusion is that they might be
>
> somehow hard-coded in a kernel driver.
>
> Jan
> --
> On 26/11/2014 12:34 AM Peter Gregory wrote:
>
> I don't know if this will help, but have you tried changing the polarity
> of the PWM pin in the device tree overlay?
>
> bs_pwm_test_P8_13 {
> compatible = "pwm_test";
> pwms = <&ehrpwm2 1 50 0>;
> pwm-names = "PWM_P8_13";
>
> pinctrl-names = "default";
> pinctrl-0 = <&bs_pwm_P8_13_0xc>;
>
> enabled = <1>;
> duty = <0>;
> status = "okay";
> };
>
>
> The last numeric parameter of pwms <&ehrpwm2 1 50 0> swaps the
> polarity of the PWM output.
> With the default duty cycle of 0, the pin will be low on power-up.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/bqsOg6NMyIM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: how to make pwm_P8_13 low on boot?

[ja...@bigpond.net.au]

  Thanks Peter, I have exercised that option already before posting and somehow it didn't work.Changing the parameters (and recompiling) didn't change the default values, so my conclusion is that they might be somehow hard-coded in a kernel driver.JanOn 26/11/2014 12:34 AM Peter Gregory  wrote:I don't know if this will help, but have you tried changing the polarity of the PWM pin in the device tree overlay?	bs_pwm_test_P8_13 {		compatible	= "pwm_test";		pwms 		= <&ehrpwm2 1 50 0>;		pwm-names 	= "PWM_P8_13";		pinctrl-names	= "default";		pinctrl-0	= <&bs_pwm_P8_13_0xc>;		enabled		= <1>;		duty		= <0>;		status 		= "okay";	};The last numeric parameter of pwms  <&ehrpwm2 1 50 0> swaps the polarity of the PWM output.With the default duty cycle of 0, the pin will be low on power-up.-- For more options, visit http://beagleboard.org/discuss--- You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/bqsOg6NMyIM/unsubscribe.To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] serialWrite function in Bonescript/javascript

[John Mladenik]

Does anyone know an easier way to send a packet of hex data out the serial 
port.  Here is what works for me

var dio6Hi = [0x7E, 0x00, 0x10, 0x17, 0x01, 0x00, 0x13, 0xA2, 0x00, 
0x40, 0xC0, 0xA9, 0x99, 0xFF, 0xFE, 0x02, 0x44, 0x36, 0x05, 0x72 ];

b.serialWrite(port, [
dio6Hi[0] ,dio6Hi[1] ,dio6Hi[2] ,dio6Hi[3] ,dio6Hi[4] ,dio6Hi[5] 
,dio6Hi[6] ,dio6Hi[7] ,dio6Hi[8] ,dio6Hi[9],

dio6Hi[10],dio6Hi[11],dio6Hi[12],dio6Hi[13],dio6Hi[14],dio6Hi[15],dio6Hi[16],dio6Hi[17],dio6Hi[18],dio6Hi[19]
 
]);

This will write all of the data in variable  dio6Hi  out of the UART in 
order that I want.But I would like to do this or something like it:

for (var i = 0; i < dio6Hi.length; i++) {   
b.serialWrite(port, [dio6Hi[i]] ); 
}

or even this:

  b.serialWrite(port, [dio6Hi[0]] ); 
  b.serialWrite(port, [dio6Hi[1]] ); 
  b.serialWrite(port, [dio6Hi[2]] ); 

   .
   .
   .
  b.serialWrite(port, [dio6Hi[18]] ); 
  b.serialWrite(port, [dio6Hi[19]] ); 

Either of these do not work they only send out the first byte in dio[0] and 
then stop.   Is there any way with the serialWrite function to index the 
variable with a "for" or other command in order to simplify sending out an 
array of numbers?   

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

Re: [beagleboard] How to communicate USB-to-serial through USB hub ("ttyACM0")

[Teis Draiby]

That sounds reasonable. I wondered too what difference it would make to cut
the wire. Ideally I would prefer not to fall back to such substandard
modifications. I'm happy with the workaround though.

regards, Teis


On 25 November 2014 at 21:37, William Hermans  wrote:

> Glad it worked for you. My guess is while power is being fed back into the
> beaglebone, the USB get puts into another Mode of operation. But I have not
> looked into that personally, so again is just a guess.
>
> On Tue, Nov 25, 2014 at 1:29 PM, Teis Draiby  wrote:
>
>> Thank you for the responses,
>>
>> beyond all expectations cutting the red power wire of the USB cable
>> connecting the Beaglebone (A/host port) to the USB hub (mini/client port)
>> actually did solve the problem. I now have the Maple board serial device
>> ttyACM0 available again.
>>
>> (for information, both the Beaglebone and the USB hub are powered
>> independently, and the Maple board is powered through the USB hub.)
>>
>>
>> Thanks for the hint on this, Teis
>>
>>
>> Den tirsdag den 25. november 2014 04.13.14 UTC+1 skrev William Hermans:
>>>
>>> Expanding on what liyaoshi just posted. I remember someone else having a
>>> similar problem but with a different device. His solution was to cut the
>>> power wire feeding back from the USB hub back into the beaglebone. However,
>>> as said above he / she used a different device, and the device its self was
>>> not showing up at all under lsusb output. Also, I'm fairly sure the USB hub
>>> was self powered.
>>>
>>> On Mon, Nov 24, 2014 at 7:14 PM, liyaoshi  wrote:
>>>
 check your usb hub power supply ?

 2014-11-25 0:29 GMT+08:00 Teis Draiby :

>
> I am currently communicating between my Beaglebone and a Maple board
> via a serial connection directly through a USB cable. This works well.
> (LeafLabs Maple is an Arduino-like board with an on-board USB connector)
>
> Due to power requirements I want to relpace the direct USB connection
> with a power supplied USB hub but when connecting the Maple board this way
> I do no longer see the serial device listed.
>
> I am new to Linux/Debian and am unsure what to do from here, and if
> it's even possible to perform serial communication through an USB hub.
>
> 
> -
> Direct USB(Beaglebone)-to-USB(Maple) serial communication (works)
> 
> -
> Beaglebone terminal:
>
> # uname -a
> Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014
> armv7l GNU/Linux
>
> # lsusb
> *Bus 001 Device 003: ID 1eaf:0004*
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> # ls /dev/ttyA*
> */dev/ttyACM0*
>
> 
> 
> Serial communication through USB hub (missing serial device?)
> 
> 
> Beaglebone terminal:
>
> # lsusb
> *Bus 001 Device 002: ID 05e3:0612 Genesys Logic, Inc.*<- this
> only shows up when using a special hd-USB cable.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> # ls /dev/ttyA*
> ls: cannot access /dev/ttyA*: No such file or directory
>
> # ls /dev/ttyU*
> ls: cannot access /dev/ttyU*: No such file or directory
>
> 
> 
>
>
> Any advice from here is greatly appreciated.
>
>
> thanks, Teis
>


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

RE: [beagleboard] BBB: Serial Wiring For External Device Over UART1

[William Pretty Security]

Hi Pieter;

 

Your wiring and voltages look fine.

However you have to ‘enable’ the other serial ports.

 

Try searching for “enable /dev/ttyO1” on this list or via Google.

 

Bill

 

"No one could make a greater mistake than he who did nothing because he could 
do only a little."

"All that is necessary for the triumph of evil is that good men do nothing" 
Edmond Burke (1729 - 1797)

http://www.packtpub.com/building-a-home-security-system-with-beaglebone/book

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Jason Lange
Sent: Tuesday, November 25, 2014 3:12 PM
To: Beagle Board
Subject: Re: [beagleboard] BBB: Serial Wiring For External Device Over UART1

 

It looks good to me, as long as you are drawing less then 250ma. 

 

On Tue, Nov 25, 2014 at 12:41 AM,  wrote:

I've been trying to attach a serial device to the beaglebone black and 
communicating with it over UART 1 (p9_24 and p9_26) with no success.

 

In part because I am new to linux and have no idea how to ping/check connected 
devices over terminal and NO prior electronic knowledge to insure the device is 
properly wired up to the beaglebone black.

 

I've attached a wiring diagram below. Can someone please confirm:

 

 1. That I've wired it correctly by looking at the diagram 

 2. That the supplied voltage from the BBB is sufficient to power the attached 
device (3.3V TTL)

 

Mapping explained (see device diagram): 

 

Pin 1 VCC (P) to 3.3Vdc on the BBB (p9_03)

Pin 2 GND (G) to GND on the BBB (p9_01)

PIN 3 TXD (O) to UART1 RX on the BBB (p9_26)

PIN 4 RXD (I) to UART1 TX on the BBB (p9_24)

 

 

 

 

Regards

Pieter

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

 

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



No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5577 / Virus Database: 4223/8629 - Release Date: 11/25/14

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5577 / Virus Database: 4223/8621 - Release Date: 11/24/14

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

Re: [beagleboard] How to communicate USB-to-serial through USB hub ("ttyACM0")

[William Hermans]

Glad it worked for you. My guess is while power is being fed back into the
beaglebone, the USB get puts into another Mode of operation. But I have not
looked into that personally, so again is just a guess.

On Tue, Nov 25, 2014 at 1:29 PM, Teis Draiby  wrote:

> Thank you for the responses,
>
> beyond all expectations cutting the red power wire of the USB cable
> connecting the Beaglebone (A/host port) to the USB hub (mini/client port)
> actually did solve the problem. I now have the Maple board serial device
> ttyACM0 available again.
>
> (for information, both the Beaglebone and the USB hub are powered
> independently, and the Maple board is powered through the USB hub.)
>
>
> Thanks for the hint on this, Teis
>
>
> Den tirsdag den 25. november 2014 04.13.14 UTC+1 skrev William Hermans:
>>
>> Expanding on what liyaoshi just posted. I remember someone else having a
>> similar problem but with a different device. His solution was to cut the
>> power wire feeding back from the USB hub back into the beaglebone. However,
>> as said above he / she used a different device, and the device its self was
>> not showing up at all under lsusb output. Also, I'm fairly sure the USB hub
>> was self powered.
>>
>> On Mon, Nov 24, 2014 at 7:14 PM, liyaoshi  wrote:
>>
>>> check your usb hub power supply ?
>>>
>>> 2014-11-25 0:29 GMT+08:00 Teis Draiby :
>>>

 I am currently communicating between my Beaglebone and a Maple board
 via a serial connection directly through a USB cable. This works well.
 (LeafLabs Maple is an Arduino-like board with an on-board USB connector)

 Due to power requirements I want to relpace the direct USB connection
 with a power supplied USB hub but when connecting the Maple board this way
 I do no longer see the serial device listed.

 I am new to Linux/Debian and am unsure what to do from here, and if
 it's even possible to perform serial communication through an USB hub.

 
 -
 Direct USB(Beaglebone)-to-USB(Maple) serial communication (works)
 
 -
 Beaglebone terminal:

 # uname -a
 Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014
 armv7l GNU/Linux

 # lsusb
 *Bus 001 Device 003: ID 1eaf:0004*
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 # ls /dev/ttyA*
 */dev/ttyACM0*

 
 
 Serial communication through USB hub (missing serial device?)
 
 
 Beaglebone terminal:

 # lsusb
 *Bus 001 Device 002: ID 05e3:0612 Genesys Logic, Inc.*<- this only
 shows up when using a special hd-USB cable.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 # ls /dev/ttyA*
 ls: cannot access /dev/ttyA*: No such file or directory

 # ls /dev/ttyU*
 ls: cannot access /dev/ttyU*: No such file or directory

 
 


 Any advice from here is greatly appreciated.


 thanks, Teis

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

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

[beagleboard] Audio via USB Client

[jay]

Has anyone in this group ever attempted to use the USB Client in BBB to act 
as an audio player for devices like car stereos?

If so, what resources did you use to learn to program Isochronous comms 
with the BBB client USB port?

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

[beagleboard] Re: How do i get python 3.3 on Angstrom

[Kyle Lee]

I'm sorry, about asking again. Could you elaborate more on using the recipe?

On Wed, Nov 19, 2014 at 6:37 AM, Mikhail <
mikhail.zakha...@cognitivesystems.com> wrote:

> There are proper recipes for python 3.3 in openembedded:
>
> http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/recipes-devtools/python/python3_3.3.3.bb?h=master
>
>
> On Friday, November 14, 2014 5:12:30 PM UTC-5, kyle...@gmail.com wrote:
>>
>> I've tried  getting python 3.3 here:
>> http://www.python.org/ftp/python/3.3.3/Python-3.3.3.tgz
>>
>> Then i run the commands :
>>
>> ./configure
>> make
>> make install
>> But it seems like its stuck checking on pieces in make...
>>
>>


-- 
Kyle Lee
University of Washington 2012-2016
C: 206-307-6030
E: kylek...@uw.edu

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

Re: [beagleboard] How to communicate USB-to-serial through USB hub ("ttyACM0")

[Teis Draiby]

Thank you for the responses,

beyond all expectations cutting the red power wire of the USB cable 
connecting the Beaglebone (A/host port) to the USB hub (mini/client port) 
actually did solve the problem. I now have the Maple board serial device 
ttyACM0 available again.

(for information, both the Beaglebone and the USB hub are powered 
independently, and the Maple board is powered through the USB hub.)


Thanks for the hint on this, Teis


Den tirsdag den 25. november 2014 04.13.14 UTC+1 skrev William Hermans:
>
> Expanding on what liyaoshi just posted. I remember someone else having a 
> similar problem but with a different device. His solution was to cut the 
> power wire feeding back from the USB hub back into the beaglebone. However, 
> as said above he / she used a different device, and the device its self was 
> not showing up at all under lsusb output. Also, I'm fairly sure the USB hub 
> was self powered.
>
> On Mon, Nov 24, 2014 at 7:14 PM, liyaoshi 
> > wrote:
>
>> check your usb hub power supply ?
>>
>> 2014-11-25 0:29 GMT+08:00 Teis Draiby >:
>>
>>>
>>> I am currently communicating between my Beaglebone and a Maple board via 
>>> a serial connection directly through a USB cable. This works well. 
>>> (LeafLabs Maple is an Arduino-like board with an on-board USB connector)
>>>
>>> Due to power requirements I want to relpace the direct USB connection 
>>> with a power supplied USB hub but when connecting the Maple board this way 
>>> I do no longer see the serial device listed.
>>>
>>> I am new to Linux/Debian and am unsure what to do from here, and if it's 
>>> even possible to perform serial communication through an USB hub. 
>>>
>>>
>>> -
>>> Direct USB(Beaglebone)-to-USB(Maple) serial communication (works)
>>>
>>> -
>>> Beaglebone terminal:
>>>
>>> # uname -a
>>> Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 
>>> armv7l GNU/Linux
>>>
>>> # lsusb
>>> *Bus 001 Device 003: ID 1eaf:0004*
>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>
>>> # ls /dev/ttyA*
>>> */dev/ttyACM0*
>>>
>>>
>>> 
>>> Serial communication through USB hub (missing serial device?)
>>>
>>> 
>>> Beaglebone terminal:
>>>
>>> # lsusb
>>> *Bus 001 Device 002: ID 05e3:0612 Genesys Logic, Inc.*<- this only 
>>> shows up when using a special hd-USB cable.
>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>
>>> # ls /dev/ttyA*
>>> ls: cannot access /dev/ttyA*: No such file or directory
>>>
>>> # ls /dev/ttyU*
>>> ls: cannot access /dev/ttyU*: No such file or directory
>>>
>>>
>>> 
>>>
>>>
>>> Any advice from here is greatly appreciated.
>>>
>>>
>>> thanks, Teis 
>>>
>>

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

Re: [beagleboard] BBB: Serial Wiring For External Device Over UART1

[Jason Lange]

It looks good to me, as long as you are drawing less then 250ma.

On Tue, Nov 25, 2014 at 12:41 AM,  wrote:

> I've been trying to attach a serial device to the beaglebone black and
> communicating with it over UART 1 (p9_24 and p9_26) with no success.
>
> In part because I am new to linux and have no idea how to ping/check
> connected devices over terminal and NO prior electronic knowledge to insure
> the device is properly wired up to the beaglebone black.
>
> I've attached a wiring diagram below. Can someone please confirm:
>
>  1. That I've wired it correctly by looking at the diagram
>  2. That the supplied voltage from the BBB is sufficient to power the
> attached device (3.3V TTL)
>
> Mapping explained (see device diagram):
>
> Pin 1 VCC (P) to 3.3Vdc on the BBB (p9_03)
> Pin 2 GND (G) to GND on the BBB (p9_01)
> PIN 3 TXD (O) to UART1 RX on the BBB (p9_26)
> PIN 4 RXD (I) to UART1 TX on the BBB (p9_24)
>
>
> 
>
>
> Regards
> Pieter
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[beagleboard] Re: Maximum SD card size for BBB

[Jesus Garcia]

 

I'm using a Sandisk 64GB microSD, no issues.


beaglebone:/card/player# lsblk

NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

mmcblk1boot0 179:16   0 2M  1 disk 

mmcblk1boot1 179:24   0 2M  1 disk 

mmcblk0  179:00  59.5G  0 disk 

└─mmcblk0p1  179:10  59.5G  0 part /card

mmcblk1  179:80   3.6G  0 disk 

├─mmcblk1p1  179:9096M  0 part /boot/uboot

└─mmcblk1p2  179:10   0   3.5G  0 part /
On Thursday, July 17, 2014 6:05:01 PM UTC-4, Jonmar wrote:
>
> Greetings everyone,
>
> What is the maximum size SD or SDHC flash memory card that the "BeagleBone 
> Black" will support ?
>
> Also, what is the recommended speed class (e.g. Class 4, Class 10, etc.) ?
>
> Thank you in advance for your help :-)
>
> Jonmar
>

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

Re: [beagleboard] Loading CAN cape on startup

[Robert Nelson]

On Tue, Nov 25, 2014 at 12:33 PM,   wrote:
> Hey Robert,
>
> Its seems I have the same problem for beaglebone wihite with the following
> specs:
>
> # uname -a
> Linux air2 3.8.13-bone63 #1 SMP Mon Aug 11 23:03:02 UTC 2014 armv7l armv7l
> armv7l GNU/Linux
>
> # echo $SLOTS
> /sys/devices/bone_capemgr.8/slots
>
>
> cat /boot/uEnv.txt
> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>
> uname_r=3.8.13-bone63
>
> #dtb=
>
> uuid=218093a4-e1e1-4e3f-8607-fba670d2a5d8
>
> cmdline=quiet
>
> ##Example
> #cape_disable=capemgr.disable_partno=
> cape_enable=capemgr.enable_partno=AIR-ADC,AIR-GPIO,AIR-UART1,AIR-UART2,AIR-UART4,AIR-UART5
>
> ##enable BBB: eMMC Flasher:
> ##make sure, these tools are installed: dosfstools rsync
> #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v2.sh
>
> How can I add multiple DT's to /etc/default/capemgr ? (Sytax for CAPE= 1 2 3

Just seperate them with ',''s

CAPE=1,2,3,4

https://github.com/RobertCNelson/omap-image-builder/blob/master/target/init_scripts/capemgr-debian.sh#L18

It'll load them in a for loop in that order..

Regards,

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

Re: [beagleboard] Beaglebone Black Ethernet Phy Not Detected on Boot.

[rathod . pratik12]

I also believe the issue mentioned here : 
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/366351.aspx  is the same 
as we are facing in bbb.

Regards,
Pratik 
On Monday, 24 November 2014 21:12:50 UTC+5:30, alexschn...@gmail.com wrote:
>
> It appears that the issue is known for a long time: several registers of 
> the LAN8710A Ethernet transceiver sometimes get wrong values at power-up, 
> in spite of correct pin strapping configurations. One of those wrong values 
> is PHYAD (PHY address in the Special Modes Register), which is erroneously 
> initialized to 2, while the processor expects it to be 0. This makes it 
> impossible for the processor to communicate with the transceiver and 
> override those wrong values.
>
> Here , they 
> suggest that this issue is inherent in the LAN8710A by Microchip, and may 
> be caused by some interference from the clock signal. However, Microchip 
> did not admit that.
>
> The messages within this topic propose 3 main solutions:
>
> 1) Rebuilt the device tree to make it somehow work with a PHY address that 
> can take on 0 or 2, or probably some other values
>
> 2) Remove C24 capacitor (this is not safe)
>
> 3) Change the file drivers/net/ethernet/ti/davinci_mdio.c and rebuild the 
> Linux (this patch, as far as I understand, will update the device tree in 
> such a way that other, non-zero PHY addresses, will become also acceptable)
>
> I have tried to do another thing: to rewrite wrong register values with 
> U-Boot, using commands like "mdio write 2 18 0xe0", and I managed to make 
> the content of those registers looking like that of a successfully started 
> transceiver (including the PHYAD and MODE). However, to successfully apply 
> these changes, a reset with RESET button is required. And if I just run 
> "reset" command in U-Boot, the transceiver doesn't work properly after 
> reboot, even though it already has the right PHY address: 0. In this case 
> the registers look like as if the auto-negotiation fails, and as if the 
> link partner (i.e. the processor) doesn't have auto-negotiation ability 
> (the Auto Negotiation Expansion Register contains 0).
>
> If that worked, it would be possible to append all required "rewriting 
> commands" into "bootcmd" variable, thus forcing U-Boot to rewrite wrong 
> values automatically. But there is another obstacle on this way: the U-boot 
> I have (2014.10-dirty) does not have "saveenv" command, for some reason. 
> So, I cannot save any changes in environmental variables there.
>
> If anyone solved this problem by modifying the device tree or by some 
> U-Boot script, please share the details.
>
> On Monday, November 24, 2014 8:18:31 AM UTC+1, Jerin George wrote:
>>
>> As suggested in this discussion i moved to 3.14.1 kernel and everything 
>> went well for the first 48 hours. 
>> After that i could see that the ETH stopped responding for close to 10 
>> seconds. 
>> Then it came back. 
>>
>> Test set up:-
>> I'm using BBB for Data acquisition thru ETH. For testing i have connected 
>> BBB and 2 PC in a switch. One PC is running a data acquisition software to 
>> collect data from BBB. Another PC is running the software "Total Network 
>> Monitor" and it keeps on logging the Network status by pinging to both BBB 
>> & the other PC. 
>>
>> After 48 Hours :-
>> I could see that the Total Network monitor reported that link to BBB was 
>> lost for close to 10 seconds. 
>>
>> Is this a known issue ? Is there any fix to this. 
>>
>> regards, 
>> Jerin
>>
>> On Saturday, 22 November 2014 14:25:03 UTC+5:30, alexschn...@gmail.com 
>> wrote:
>>>
>>> But the SW can do that only when the transceiver chip is always in a 
>>> "writable" state, which is unfortunately not the case.
>>>
>>> On Saturday, November 22, 2014 1:38:54 AM UTC+1, Gerald wrote:

 All the SW has to do itvwrite to the registers and not rely on the 
 straps. Hmm I have been saying that for 3+ years now.

 Gerald

 On Friday, November 21, 2014,  wrote:

> Hi Gerald,
>
> I meant "strap values", not connections on the board. As far as I 
> understand it, correct strappings alone cannot always ensure correct bits 
> in the respective registers of the transceiver chip. The power-on and 
> reset 
> timing is also important, and this timing, unlike strappings, is 
> different 
> at least for some revisions. 
>
> In my experiments, a reset performed with RESET button never resolved 
> the "phy not found" problem. A power-on reset as well as a reset with 
> POWER 
> button helped, but not always. Cannot the transceiver sometimes enter 
> into 
> some unresponsive state, which makes it impossible for the processor to 
> override the strappings?
>
> Alex
>
> On Thursday, November 20, 2014 9:50:56 PM UTC+1, Gerald wrote:
>>
>> If you have what you think are he correct trappings, let me know. 
>>>

Re: [beagleboard] Send Raw or hex data out the serial port using bonescript

[John Mladenik]

My UART2 app worked the whole time, I had the logic analyzer probes on the 
wrong pins and thought it was not working.  I found this once I tried a 2nd 
BBB and it worked right out of the box.I then went back and realized 
the probes were on the wrong pins.  

thanks for all the help.


On Monday, November 24, 2014 7:43:55 AM UTC-8, George Lu wrote:
>
>
> On Sat, Nov 22, 2014 at 7:49 PM, John Mladenik  > wrote:
>
>> So it worked but once I let the board sit not being powered overnight it 
>> stopped working.   Do you or anyone know how to get the UART2 working and 
>> stay working once powered down and then turned back on?   
>>
>
> Once power cycled, you would need to start up the program again so that 
> the serial port could be properly opened for writing. I would have the 
> bonescript code in, say, /home/debian/doSerial.js, and run that 
> automatically on every reboot. There are a number of ways to do this. One 
> quick way is try to add a line in /etc/crontab to run this command on 
> @reboot:
>
> @reboot rootcd /home/debian && 
> NODE_PATH=/usr/local/lib/node_modules && export NODE_PATH && doSerial.js 
>
> Assuming you are using debian image, /dev/ttyO1 and /dev/ttyO2 have 
> "rw-rw---" as their permission. So you either need to run it as root or add 
> your desired user to the dialout group to be able to write to these serial 
> interfaces.
>
> If doSerial.js crashes for any reason, you could use a process monitor to 
> restart it. Supervisord , forever 
> , pm2 
> , are some options to explore.
>   
>
>>
>> On Wednesday, November 19, 2014 3:44:26 PM UTC-8, George Lu wrote:
>>>
>>> On Wed, Nov 19, 2014 at 3:26 PM, John Mladenik  
>>> wrote:
>>>
 I need to be able to send raw data out of the serial port using 
 Bonescript command b.serialWrite.I set up an HTML Bonescript to send 
 data and then looked on the logic analyzer to see what bit pattern is sent 
 out.  The pattern is always the ASCII value of the character whether the 
 variable is a text or number.

 Does anyone know how to pass to b.serialWrite a value so that the UART 
 outputs that value?

 so I want to have 

 var port = '/dev/ttyO2'; // set UART port
 var data = 0x55 ;  
 b.serialWrite(port, data );

 and for the bit pattern coming out of the UART to be  01010101  

 I tried using String.fromCharCode(data);  but this only works for 
 values up to 127 (0x7F) since that is all ASCII goes to.   This must not 
 support extended ASCII?

 here is my html/javascript to test this functionality

 
 

 Uart Byte:
 
 SEND

 
 
 
 
 function uartWr() {
 var b = require('bonescript');
 var port = '/dev/ttyO2'; // set UART port
 var data = document.getElementById('value').value;
 // set baud rate and buffer size
 var options = {
 baudrate: 9600
 };

 b.serialWrite(port, data );

 }
 

 
 

>>>
>>> I recall BoneScript uses https://github.com/
>>> voodootikigod/node-serialport for serial port interface.
>>> You should be able to send raw binary with b.serialWrite(port, [0x55]); 
>>> Data should be a buffer (http://nodejs.org/api/buffer.html).
>>>
>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you 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 .
>> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PWM: only a finite number of pulses? Controlling stepper motor

[cncbasher]

see Linuxcnc.org  and the beaglbone variant Machinekit does exactly that  


On Saturday, 18 October 2014 02:26:26 UTC+1, plla...@gmail.com wrote:
>
>
>
> 
>  
>   
> I'm wanting to use the BeagleBone Black to generate a FINITE number of 
> pulses, in order to control a stepper motor. For the controller I have, an 
> A4988, each pulse is one step on the motor. How can I use the PWM on the 
> BBB to send, say, 5 pulses, and no more or less than 5? Or I can use a 
> GPIO. Whichever works. 
>
> I have the Adafruit BBIO library 
> 
>  
> installed. I have thought of doing this in a simple, stupid way - just 
> using python's time.wait() and toggling a GPIO pin, however many times 
> I'd like. But this seems very inaccurate, timing-wise, and moreover 
> inelegant; is there a way to do this better? I'm also investigating events 
> -- i.e., count the numberof pulses that have occured using another GPIO, 
> then stop the PWM when the number of pulses I want has been counted. 
>
>
> Any ideas?
>

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

[beagleboard] Re: GTK application - compiling and linking, not exactly running

[joeglens]

Im also having the same problem with the latest Angstrom dist for BBB 
(2013-09-04)

but when I used debian build for BBB everything is working as intended

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

[beagleboard] Re: Debian image and FTD2XX driver can't load

[achbaa . zakaria]

Hello evry one !

I have the same problem and i need a solution. Anyone can help plz !!

Thank you !

Zakaria.
Le samedi 31 mai 2014 20:13:33 UTC+1, Charles Kerr a écrit :
>
>
> Ok, I noticed in this post " BeagleBone Black: Debian vs Angstrom C++ 
> Executable Issue" I see the same type of error.I am not sure how to 
> fix the hard vs soft float.  Is there any instructions on that?
>
>
>
> On Saturday, May 31, 2014 3:10:58 PM UTC-4, Charles Kerr wrote:
>>
>> I ref lashed my BeagleBone black to the latest debian image posted on 
>> this site.  I rebuilt my program I am writing which uses the FTDI 
>> libftd2xx.so driver. I use the arm one for the raspberry pi (same one I 
>> used on the Angstrom version of my BBB) and it all built fine (library is 
>> in /usr/local/lib).  However, it can't load the library, even if I put it 
>> in /usr/lib.  On angstrom is all works fine.  Any thoughts?
>>
>>  
>>
>

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

[beagleboard] BBB: Serial Wiring For External Device Over UART1

[pietersydneytheron]

I've been trying to attach a serial device to the beaglebone black and 
communicating with it over UART 1 (p9_24 and p9_26) with no success.

In part because I am new to linux and have no idea how to ping/check 
connected devices over terminal and NO prior electronic knowledge to insure 
the device is properly wired up to the beaglebone black.

I've attached a wiring diagram below. Can someone please confirm:

 1. That I've wired it correctly by looking at the diagram 
 2. That the supplied voltage from the BBB is sufficient to power the 
attached device (3.3V TTL)

Mapping explained (see device diagram): 

Pin 1 VCC (P) to 3.3Vdc on the BBB (p9_03)
Pin 2 GND (G) to GND on the BBB (p9_01)
PIN 3 TXD (O) to UART1 RX on the BBB (p9_26)
PIN 4 RXD (I) to UART1 TX on the BBB (p9_24)




Regards
Pieter

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

Re: [beagleboard] Beaglebone Black Ethernet Phy Not Detected on Boot.

[rathod . pratik12]

Well, may be you can add your mdio command inside u-boot source code's 
default bootcmd and rebuild the u-boot.
In my case, I updated my cpsw platform data (I use 3.2 kernel, so no device 
tree) inside kernel dynamically to fix this problem. It seems to be working 
for me. 

Regards,
Pratik

On Monday, 24 November 2014 21:12:50 UTC+5:30, alexschn...@gmail.com wrote:
>
> It appears that the issue is known for a long time: several registers of 
> the LAN8710A Ethernet transceiver sometimes get wrong values at power-up, 
> in spite of correct pin strapping configurations. One of those wrong values 
> is PHYAD (PHY address in the Special Modes Register), which is erroneously 
> initialized to 2, while the processor expects it to be 0. This makes it 
> impossible for the processor to communicate with the transceiver and 
> override those wrong values.
>
> Here , they 
> suggest that this issue is inherent in the LAN8710A by Microchip, and may 
> be caused by some interference from the clock signal. However, Microchip 
> did not admit that.
>
> The messages within this topic propose 3 main solutions:
>
> 1) Rebuilt the device tree to make it somehow work with a PHY address that 
> can take on 0 or 2, or probably some other values
>
> 2) Remove C24 capacitor (this is not safe)
>
> 3) Change the file drivers/net/ethernet/ti/davinci_mdio.c and rebuild the 
> Linux (this patch, as far as I understand, will update the device tree in 
> such a way that other, non-zero PHY addresses, will become also acceptable)
>
> I have tried to do another thing: to rewrite wrong register values with 
> U-Boot, using commands like "mdio write 2 18 0xe0", and I managed to make 
> the content of those registers looking like that of a successfully started 
> transceiver (including the PHYAD and MODE). However, to successfully apply 
> these changes, a reset with RESET button is required. And if I just run 
> "reset" command in U-Boot, the transceiver doesn't work properly after 
> reboot, even though it already has the right PHY address: 0. In this case 
> the registers look like as if the auto-negotiation fails, and as if the 
> link partner (i.e. the processor) doesn't have auto-negotiation ability 
> (the Auto Negotiation Expansion Register contains 0).
>
> If that worked, it would be possible to append all required "rewriting 
> commands" into "bootcmd" variable, thus forcing U-Boot to rewrite wrong 
> values automatically. But there is another obstacle on this way: the U-boot 
> I have (2014.10-dirty) does not have "saveenv" command, for some reason. 
> So, I cannot save any changes in environmental variables there.
>
> If anyone solved this problem by modifying the device tree or by some 
> U-Boot script, please share the details.
>
> On Monday, November 24, 2014 8:18:31 AM UTC+1, Jerin George wrote:
>>
>> As suggested in this discussion i moved to 3.14.1 kernel and everything 
>> went well for the first 48 hours. 
>> After that i could see that the ETH stopped responding for close to 10 
>> seconds. 
>> Then it came back. 
>>
>> Test set up:-
>> I'm using BBB for Data acquisition thru ETH. For testing i have connected 
>> BBB and 2 PC in a switch. One PC is running a data acquisition software to 
>> collect data from BBB. Another PC is running the software "Total Network 
>> Monitor" and it keeps on logging the Network status by pinging to both BBB 
>> & the other PC. 
>>
>> After 48 Hours :-
>> I could see that the Total Network monitor reported that link to BBB was 
>> lost for close to 10 seconds. 
>>
>> Is this a known issue ? Is there any fix to this. 
>>
>> regards, 
>> Jerin
>>
>> On Saturday, 22 November 2014 14:25:03 UTC+5:30, alexschn...@gmail.com 
>> wrote:
>>>
>>> But the SW can do that only when the transceiver chip is always in a 
>>> "writable" state, which is unfortunately not the case.
>>>
>>> On Saturday, November 22, 2014 1:38:54 AM UTC+1, Gerald wrote:

 All the SW has to do itvwrite to the registers and not rely on the 
 straps. Hmm I have been saying that for 3+ years now.

 Gerald

 On Friday, November 21, 2014,  wrote:

> Hi Gerald,
>
> I meant "strap values", not connections on the board. As far as I 
> understand it, correct strappings alone cannot always ensure correct bits 
> in the respective registers of the transceiver chip. The power-on and 
> reset 
> timing is also important, and this timing, unlike strappings, is 
> different 
> at least for some revisions. 
>
> In my experiments, a reset performed with RESET button never resolved 
> the "phy not found" problem. A power-on reset as well as a reset with 
> POWER 
> button helped, but not always. Cannot the transceiver sometimes enter 
> into 
> some unresponsive state, which makes it impossible for the processor to 
> override the strappings?
>
> Alex
>
> On Thursday, No

[beagleboard] GPIO high during boot

[Nils]

Hello,

I'm using the BeagleBone Black's GPIOs to drive some outputs.
I'm running Kernel 3.8, so I used the Device Tree to configure the GPIOs. 
The cape is loaded during boot via the capemgr.
But until the BBB has fully booted, some of the GPIOs are set to high.
Is there a way to prevent this?

Regards,
Nils

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

Re: [beagleboard] Loading CAN cape on startup

[dan . novischi]

Hey Robert,

Its seems I have the same problem for beaglebone wihite with the following 
specs:

# uname -a
Linux air2 3.8.13-bone63 #1 SMP Mon Aug 11 23:03:02 UTC 2014 armv7l armv7l 
armv7l GNU/Linux

# echo $SLOTS
/sys/devices/bone_capemgr.8/slots


cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=3.8.13-bone63

#dtb=

uuid=218093a4-e1e1-4e3f-8607-fba670d2a5d8

cmdline=quiet 

##Example
#cape_disable=capemgr.disable_partno=
cape_enable=capemgr.enable_partno=AIR-ADC,AIR-GPIO,AIR-UART1,AIR-UART2,AIR-UART4,AIR-UART5

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

*How can I add multiple DT's to /etc/default/capemgr ? (Sytax for CAPE= 1 2 
3 ...)*

Thanks,
Dan.


On Thursday, 6 March 2014 23:58:54 UTC+2, RobertCNelson wrote:
>
> On Thu, Mar 6, 2014 at 3:37 PM, sixvolts > 
> wrote: 
> > Using the new Debian builds on my beaglebone white, I'm trying to load a 
> > device tree overlay for the CAN cape on startup, but it seems to fail to 
> > load automatically (but try), however, I can load the device tree 
> overlay 
> > manually and it seems to work just fine. What am I doing wrong? 
> > 
> > I even tried putting the following entry in uEnv.txt: 
> > 
> > 
> optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G 
>
> > capemgr.enable_partno=BB-BONE-SERL-01 
> > 
> > I don't know of any hardware conflicts, and the same hardware works fine 
> on 
> > Angstrom. I really want to migrate to Debian for several reasons. 
> > 
> > Here's the command and successful load manually: 
> > 
> > 
> > debian@arm:~$ sudo sh -c "echo BB-BONE-SERL-01 > 
> > /sys/devices/bone_capemgr.8/slots" 
>
> For some reason the "capemgr.enable_partno=" is just not reliable on 
> the bootargs.. 
>
> As a workaround I've added an init script workaround by default: 
>
> sudo sh -c "echo CAPE=BB-BONE-SERL-01 >> /etc/default/capemgr" 
>
> and it'll load pretty early on bootup.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] UARTs enabled but don't work on Debian!

[John Mladenik]

Thanks for the response but I got it to work right after I posted this and 
I tried to delete it to not bother you with the explanation.   The thing 
worked the whole time I had my logic analyzer on the wrong pins.  When I 
tried it on my 2nd BBB, that had never been powered until then, it worked 
right out of the box without any configuration or setup.   I then went back 
to the original BBB and realized I had the test point on the wrong pins, 
and once probing the correct pins, I realized that it works and probably 
had worked from the beginning.  

Thanks again for your help and responses.
John

So Uart2 works right out of the box without setting any configuration, or 
pin mux or anything, at least if does for my 2 BBB Rev C's that I have.  

On Tuesday, November 25, 2014 12:13:03 AM UTC-8, William Hermans wrote:
>
> What user is the script running as ?
>
> On Mon, Nov 24, 2014 at 9:02 PM, John Mladenik  > wrote:
>
>> Ok Sorry, I am trying to send characters out the UART2 on a BBB Rev C 
>> using HTML Javascript SEE program below:  This worked before and stopped 
>> working, not sure why.   Be patient with my I am a newbie a month or so 
>> into learning HTML. Javascript, linux, beaglebone, but only working on it 
>> part time outside of my regular job.  
>>
>> I have a logic analyzer connected to P9 Pins 20 & 21 which are the UART2 
>> TX and RX line.   When I send the data using below program the TX pin does 
>> not toggle so no data comes out of the TX pin. 
>>
>> When this worked it sent the data using program below and if I input a 5 
>> a value of 0x05 was shifted out of the UART2 on the TX pin.My goal is 
>> to get the UART2 to work after power up without having to type in a bunch 
>> of commands before running the HTML/Javscript.
>>
>>
>> When I type   
>> cat /sys/devices/bone_capemgr.*/slots  
>> I get the following:
>>  0: 54:PF---
>>  1: 55:PF---
>>  2: 56:PF---
>>  3: 57:PF---
>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART2
>>
>> I did add the following line to my uEnv.txt file
>> capemgr.enable_partno=BB-UART2
>>
>> But this didn't seem to make a difference either way.Any suggestions 
>> would be appreciated. 
>>
>> Example code below here ***
>> // UART2 TX Test filename = uartwr.html
>>
>> 
>> 
>>
>> Uart Byte:
>> 
>> SEND
>>
>> 
>> 
>> 
>> 
>>
>> function uartWr() {
>> var b = require('bonescript');
>> // set baud rate and buffer size
>>
>> var port = '/dev/ttyO2'; // set UART port
>> var data = document.getElementById('value').value;
>> 
>> var options = { baudrate: 9600, buffer: 100} ;
>> b.serialOpen(port, options, onSerial);// 
>> 
>> function onSerial(x) {
>> var b = require('bonescript');
>> if (x.err) {
>> console.log('***ERROR*** ' + JSON.stringify(x));
>> }
>> if (x.event == 'open') {
>>console.log('***OPENED***');
>> }
>> if (x.event == 'data') {
>> console.log(String(x.data));
>> }
>> }
>> b.serialWrite(port, [data] );
>> }
>>
>> 
>> 
>>
>> 
>> 
>> Example code Above here ***
>>
>>
>> On Saturday, November 22, 2014 7:52:22 PM UTC-8, William Hermans wrote:
>>>
>>> John, detailed description is required. "Dont work" is pretty vague and 
>>> leaves a lot of room for guessing.
>>>
>>> On Sat, Nov 22, 2014 at 8:41 PM, John Mladenik  
>>> wrote:
>>>
 Robert,

 I am having the same problem with UART2 (the only UART I need to work) 
  but mine worked in the past.  It even worked through re-power until the 
 BBB sat overnight unpowered.  I went through all of the steps I found in 
 links to make it work, but none of the steps were anything like yours.
 I 
 am a newbie to software and linux so I don't really understand what you 
 are 
 saying to do.  .  Can you tell me what exactly your program and compile 
 are 
 doing?  Will it work for UART2.  

 When you said "The pins aren't mixed to the peripheral." did you mean 
 MUXED instead of mixed?

 so you have a dtb file that you compile into a dts file?   Since 
 /src/arm does no exist on my BBB do I need to create that folder to copy 
 the file into it?I assume it is changing the mux configuration of the 
 UART pins to be connected in the ARM to the UART iinstead of the GPIO?   

 Sorry of my questions seem dumb, but that is what I feel like, I spent 
 at least 10-12 hours to get the UART to work the first time and when it 
 stopped working the next day it set me back weeks in my project. :(  

 On Friday, November 14, 2014 1:12:22 PM UTC-8, RobertCNelson wrote:
>
> http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb
>
> The pins a

[beagleboard] Re: a question about asking questions

[Peter Gregory]

As someone getting to know the Beaglebone Black, I've relied on "the kindness 
of strangers" in this group to help me get going.
I've been working on my home project for 6 months and still have roadblocks 
getting it up and running (Yeah, I'm slow).
I'm still trying to get all the pieces together for the device tree + GPIO 
programming + PRU programming (Slowly making progress).
I've bounced back and forth between kernels 3.14 (SGX support + Device Tree) 
and 3.8 (Cape Manager is easier + PWM support, LinuxFb is a bit slow)
Qt 5.3.2 has several issues I need to resolve before it works with embedded 
linux & the 4DCape-43T (KB & Mouse bleed-thru, speed, Touch issues).
I've been able to find clues to solve some of the issues by Googling, but when 
I can't, this user groups is my best source.

This group is a good group of people and a good source for information. (Not 
too much whining & lots of good relevant issues)
I find it useful to see how others have approached a problem that I'm having.
Even if they don't have a solution, it shows me different ways to ask questions 
to get at the answer. (What did people do before Google?)

To the point: ask questions when you need to.
Search before you ask and see if it has already been answered.
Someone will find your question interesting because others have hit the same 
problem.

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

Re: [beagleboard] serial UART async_low_latency does not seem to work. still > 10ms latency!

[Thomas O]

Hey liyaoshi... I am running both uarts in 3,000,000 bytes per second! It 
is the problem that i get long delys 10ms or more so it is not related to 
speed but to latency.
Also it seems the kernel only copies from kernel space to the uart in that 
same 10ms intervals. so it fills up the send queue for 10ms.

On Tuesday, November 25, 2014 1:54:06 AM UTC, liyaoshi wrote:
>
> speed up to 921600bps or more if your remote uart can work 
>
> 2014-11-24 19:17 GMT+08:00 Thomas O >:
>
>> Hi all i am writing some software using the OMAP_SERIAL drivers to send 
>> and receive data from a c program (TERMIOS).
>>
>> I am seeing large delays 10ms ticks when sending and receiving data on 
>> the UARTS
>>
>

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

[beagleboard] Re: GPIO Header Pins that can be muxed to the PRU

[TJF]

The CPU ball mapping is hard coded in the AM335x logic, no tricks AFAIK. 

Your list seems to be OK (I didn't check all details). There're just a few 
header pins usable for PRUSS low latency GPIO, when LCD isn't disabled. All 
other GPIOs can get accessed over the OCP master port with 2 or 3 cycles of 
latency.

Instead of memory mapped access (from the host) I recommend to consider 
controlling the GPIO subsystems directly by the PRU. Find some example code 
in the package libpruio .

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

[beagleboard] Re: GPIO Header Pins that can be muxed to the PRU

[TJF]

The CPU ball mapping is hard coded in the AM335x logic, no tricks AFAIK. 

Your list seems to be OK (I didn't check all details). There're just a few 
header pins usable for PRUSS low latency GPIO, when LCD isn't enabled. All 
other GPIOs can get accessed over the OCP master port with 2 or 3 cycles of 
latency.

Instead of memory mapped access (from the host) I recommend to consider 
controlling the GPIO subsystems directly by the PRU. Find some example code 
in the package libpruio .

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

Re: [beagleboard] Re: Kernel 3.13 and above: How to enable dcan_1 and GPIOs

[Robert Nelson]

On Tue, Nov 25, 2014 at 8:25 AM, Robert Nelson  wrote:
> On Tue, Nov 25, 2014 at 8:14 AM, Marco Steger  wrote:
>>
>> Hi Robert,
>> thanks for your comments.
>>>
>>> Yes and No...  It'll boot, but not everything will work, ...
>>
>> I'm not that sure about that. I just tried this and the BBB doesn't boot
>> afterwards. But maybe I did a bad mistake. Here my steps:
>>
>> 1.) Downloaded your DTB-rebuilder "
>>
>> git clone -b 3.14-ti https://github.com/RobertCNelson/dtb-rebuilder.git";
>>
>> 2.) Uncommented line 53 (/* #include "am335x-bone-can1.dtsi" */) in file
>> dtb-rebuilder/src/arm/am335x-boneblack.dts.
>> 3.) make
>> 4.) copied the am335x-boneblack.dtb file to /boot/dtbs/3.16.1-bone4/
>> 5.) Reboot. Without result. After running modprobe can; modprobe can-dev;
>> modprobe can-raw there was no CAN interface when typing ifconfig -a
>
> Do you have can enabled?
>
> The can "pinmux" relies on this patchset in my v3.14.x tree:
>
> https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-3.14.y/patches/beaglebone/pinmux-helper
>
>> 6.) So I checked the uEnv file in /boot dir. There was a line "#dtb="
>> 7.) Then I uncommented this line and used
>> dtb=/boot/dtbs/3.16.1-bone4/am335x-boneblack.dtb
>
> Yuck, don't do that, just the file name.. (i need to add the exact
> path to the lookup function in u-boot so user's don't break their boot
> via that^^^)
>
>> 8.) After reboot all 4 LEDs stay lid and after lets say 30 seconds its seems
>> that the board reboots again.
>>
>> What did I wrong here? Any ideas?
>>
>> In the meantime I will reflash my board and start again... :)

btw, just to refresh everyone on all the branches.

Right now i'm mainly focusing on the "v3.14-ti" branch, as a stepping
stone off "v3.8.x"

Otherwise, i'm staying in sync with mainline, as dt "overlay's" are
getting so close:

http://www.spinics.net/lists/devicetree/msg59480.html

Regards,

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

Re: [beagleboard] Re: Kernel 3.13 and above: How to enable dcan_1 and GPIOs

[Robert Nelson]

On Tue, Nov 25, 2014 at 8:14 AM, Marco Steger  wrote:
>
> Hi Robert,
> thanks for your comments.
>>
>> Yes and No...  It'll boot, but not everything will work, ...
>
> I'm not that sure about that. I just tried this and the BBB doesn't boot
> afterwards. But maybe I did a bad mistake. Here my steps:
>
> 1.) Downloaded your DTB-rebuilder "
>
> git clone -b 3.14-ti https://github.com/RobertCNelson/dtb-rebuilder.git";
>
> 2.) Uncommented line 53 (/* #include "am335x-bone-can1.dtsi" */) in file
> dtb-rebuilder/src/arm/am335x-boneblack.dts.
> 3.) make
> 4.) copied the am335x-boneblack.dtb file to /boot/dtbs/3.16.1-bone4/
> 5.) Reboot. Without result. After running modprobe can; modprobe can-dev;
> modprobe can-raw there was no CAN interface when typing ifconfig -a

Do you have can enabled?

The can "pinmux" relies on this patchset in my v3.14.x tree:

https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-3.14.y/patches/beaglebone/pinmux-helper

> 6.) So I checked the uEnv file in /boot dir. There was a line "#dtb="
> 7.) Then I uncommented this line and used
> dtb=/boot/dtbs/3.16.1-bone4/am335x-boneblack.dtb

Yuck, don't do that, just the file name.. (i need to add the exact
path to the lookup function in u-boot so user's don't break their boot
via that^^^)

> 8.) After reboot all 4 LEDs stay lid and after lets say 30 seconds its seems
> that the board reboots again.
>
> What did I wrong here? Any ideas?
>
> In the meantime I will reflash my board and start again... :)

Regards,

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

Re: [beagleboard] Re: Kernel 3.13 and above: How to enable dcan_1 and GPIOs

[Marco Steger]

Hi Robert, 
thanks for your comments. 

> Yes and No...  It'll boot, but not everything will work, ...
>
I'm not that sure about that. I just tried this and the BBB doesn't boot 
afterwards. But maybe I did a bad mistake. Here my steps:

1.) Downloaded your DTB-rebuilder "

git clone -b 3.14-ti https://github.com/RobertCNelson/dtb-rebuilder.git";

2.) Uncommented line 53 (/* #include "am335x-bone-can1.dtsi" */) in file 
dtb-rebuilder/src/arm/am335x-boneblack.dts.
3.) make
4.) copied the am335x-boneblack.dtb file to /boot/dtbs/3.16.1-bone4/
5.) Reboot. Without result. After running modprobe can; modprobe can-dev; 
modprobe can-raw there was no CAN interface when typing ifconfig -a
6.) So I checked the uEnv file in /boot dir. There was a line "#dtb="
7.) Then I uncommented this line and used 
dtb=/boot/dtbs/3.16.1-bone4/am335x-boneblack.dtb
8.) After reboot all 4 LEDs stay lid and after lets say 30 seconds its 
seems that the board reboots again. 

What did I wrong here? Any ideas? 

In the meantime I will reflash my board and start again... :)

Hope you can help me once again!

Thanks a lot!!!

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

[beagleboard] Re: how to make pwm_P8_13 low on boot?

[Peter Gregory]

I don't know if this will help, but have you tried changing the polarity of the 
PWM pin in the device tree overlay?

bs_pwm_test_P8_13 {
compatible  = "pwm_test";
pwms= <&ehrpwm2 1 50 0>;
pwm-names   = "PWM_P8_13";

pinctrl-names   = "default";
pinctrl-0   = <&bs_pwm_P8_13_0xc>;

enabled = <1>;
duty= <0>;
status  = "okay";
};


The last numeric parameter of pwms  <&ehrpwm2 1 50 0> swaps the polarity of 
the PWM output.
With the default duty cycle of 0, the pin will be low on power-up.

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

Re: [beagleboard] uSD Disconnects; Reset Fails with "CCCCC"; Re-Insert Boots

[Gerald Coley]

 means the SD card is unreadable as a boot source and it cannot read
the eMMC either.  It is looking for a boot source.

Gerald

On Tuesday, November 25, 2014, Loren Amelang  wrote:

> My Rev.A6 BBB had been running solidly 24/7 for months, with only
> explainable software-related crashes. But in the last week it has just hung
> twice, with no relation to software functions, nothing unusual in the logs,
> and D2/3/4 on solid.
>
> It is powered by an analog regulator from my solar house battery system
> with huge and redundant battery banks, so there is really no chance of a
> power glitch. It runs the RCN distro of Ubuntu 14.04, from a 16 GB SanDisk
> uSD. When it hangs and I press Reset without cycling power, I get no user
> LEDs, but I do get a series of "C" characters on the console port.
>
> My A6 SRM says:
> ---
> Without holding the [boot] switch, the board will boot try to boot from
> the eMMC. If it is empty, then it will try booting from the microSD slot,
> followed by the serial port, and then the USB port.
> ---
> But that is for a power cycle boot. Reset alone, with constant power,
> "does not change the boot mode". Apparently that means does not change
> between eMMC default and uSD default for the first try, but still allows
> for Serial or USB boot if the default local storage fails.
>
> Later it says:
> ---
> On boot, the processor will look for the SPIO0 port first, then microSD on
> the
> MMC0 port, followed by USB0 and UART0. In the event there is no microSD
> card and
> the eMMC is empty, USB0 or UART0 could be used as the board source.
> ---
> It is not clear whether USB and UART/Serial are checked in a particular
> order, or are continuously checked. My experience seems to suggest that
> Serial, at least, is continuously checked, and that uSD is also
> continuously checked:
>
> If I remove the uSD while the "C" is streaming on the console, nothing
> obvious happens. If I then re-insert the uSD, booting begins instantly and
> proceeds normally!
>
> So, I'm guessing the uSD somehow loses contact with its socket, and an
> access from the BBB fails and hangs Linux, with the LED that seems to
> indicate uSD access on solid. But I can't see any problem inside the uSD
> socket, and the contacts on the uSD itself look perfect. And this uSD
> socket has a relatively easy life compared to those in my phone or other
> portable/remote devices, which have never glitched on me.
>
> So what else could this be? An electrical failure inside the uSD card?
> Guess I should try a power-cycle reboot without mechanical disturbance next
> time it happens...
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
http://circuitco.com/support/

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

Re: [beagleboard] Re: Kernel 3.13 and above: How to enable dcan_1 and GPIOs

[Robert Nelson]

On Tue, Nov 25, 2014 at 5:25 AM, Marco Steger  wrote:
>
> Hi Jason!
>
> Thanks for your help! The dtb-rebuilder looks like a very promising solution 
> for me. Although, in Robert's GitHub repo is just a branch for kernel 
> "3.14-ti". So a very similar question then in my last post: Can I use the 
> scripts and the dts file also on my 3.16-bone4 kernel?
> Do you think that it would be possible to permanently damage my BBB, if I try 
> to use the scripts on my 3.16 BBB?

Yes and No...  It'll boot, but not everything will work, the 3.14-ti
branch contains a lot of patches that are both heading and hitting
mainline.  Many post "3.16".. Lot's of the can patches have been
posted this last month for review for "3.19"..

>
> If this is possible, then I think (or more hope :) ) it would be really easy 
> to enable d_can1:
>
> 1.) Like suggested in [1] I would take the am335x-boneblack.dtb file.
>
> 2.) It looks like that includes can be added easily:
>
>
> /* can1: P9_24, P9_26 */
>
> #include "am335x-can1.dtsi" (Already there)
>
> #include "am335x-boneblack-can1.dts" (add this line; But I’m not sure if .dts 
> files can be included like .dtsi file?!)
>
> /* #include "am335x-bone-can1.dtsi" */

I have setup that file simpler then that, to enable can1 just
un-comment the 2nd line (pinmux) aka:

/* can1: P9_24, P9_26 */
#include "am335x-can1.dtsi"
#include "am335x-bone-can1.dtsi"

The first include is the device "perhiperal" the second include is the pinmux.

Regards,

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

[beagleboard] Re: a question about asking questions

[Jon E]

Hi,

I thought it was a perfectly fair question - though I couldn't help, as 
I've not done much with the kernel PWM driver. 

Google turned up someone else with basically the same problem (initial pin 
state not reflecting their changes to the device tree config), but no 
answers. I guess in your shoes I'd start looking through the driver source, 
and trying to figure out where these options are meant to be processed.

Good luck!

Jon


On Tuesday, 25 November 2014 07:05:28 UTC, janszyma...@gmail.com wrote:

> Hi,
>
>  I have still unresolved issue (no answer here for how to make pwm_P8_13 
> low on boot? ) and therefore
> trying to figure out if my question is:
> - too easy
> - too difficult
> - not interesting enough
> - other?
>
> As I see there is generally a number of unanswered questions, would it be 
> possible for the moderator to give an indication in a simple style,
> something like: "too easy, google it yourself" or whatever, to avoid 
> frustration.
>
> Jan
>
>

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

Re: [beagleboard] Re: Kernel 3.13 and above: How to enable dcan_1 and GPIOs

[Marco Steger]

 

Hi Jason!

Thanks for your help! The dtb-rebuilder looks like a very promising 
solution for me. Although, in Robert's GitHub repo is just a branch for 
kernel "3.14-ti". So a very similar question then in my last post: Can I 
use the scripts and the dts file also on my 3.16-bone4 kernel? 
Do you think that it would be possible to permanently damage my BBB, if I 
try to use the scripts on my 3.16 BBB? 

If this is possible, then I think (or more hope :) ) it would be really 
easy to enable d_can1: 

1.) Like suggested in [1] I would take the am335x-boneblack.dtb file. 

2.) It looks like that includes can be added easily:
 
  /* can1: P9_24, P9_26 */
  
#include "am335x-can1.dtsi" (Already there)
  
#include "am335x-boneblack-can1.dts" (add this line; But I’m not sure if 
.dts files can be included like .dtsi file?!) 
  
/* #include "am335x-bone-can1.dtsi" */
  
 

3.) Build dtb file using dtb-rebuilder.

4.) Copy to /boot/dtbs/ dir.

5.) reboot


Would be great if you can help me once more here!

[1] http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb

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

Re: [beagleboard] a question about asking questions

[janszymanski12345]

Thanks Jason,

 There is a hardware solution to my problem in a form of a tiny logic 
08 (AND gate). The PWM is connected to one input and an extra ENABLE signal 
from GPIO is connected to another input. On the output the resulting gated 
PWM signal will appear when the ENABLE signal goes high from the 
application.
The solution however is non-elegant and can be avoided if I had a better 
knowledge of the software - in this case a PWM driver and it's interaction 
with a device tree overlay.
The initial values of pins on boot is a thing to be aware of in any system.
Thinking that there are people using PWM on BBB, including the designers of 
PWM capes and they are facing the same issue, there was my hope of finding 
a software solution. And yes, I did a very extensive search beforehand. And 
I am grateful and appreciated for the help received, and if possible I do 
contribute back to community within my limits.

Cheers

Jan


On Tuesday, November 25, 2014 8:28:08 PM UTC+11, Jason Lange wrote:

>
>
> On Mon, Nov 24, 2014 at 11:05 PM, > 
> wrote:
>
> Hi,
>>
>>  I have still unresolved issue (no answer here for how to make pwm_P8_13 
>> low on boot? ) and therefore
>> trying to figure out if my question is:
>> - too easy
>> - too difficult
>> - not interesting enough
>> - other?
>>
>> As I see there is generally a number of unanswered questions, would it be 
>> possible for the moderator to give an indication in a simple style,
>> something like: "too easy, google it yourself" or whatever, to avoid 
>> frustration.
>>
>> Jan
>>
>
>
> Is there a moderator?  I don't know.
>
> But for myself, your question is both too difficult (I don't know the 
> answer) and not interesting enough (It isn't a problem that I need to solve 
> for myself).  Everybody here is going to have a different response, so 
> having a moderator decide is probably a bit ham fisted.  I can imagine an 
> external hardware solution because I do circuits, but it'd be more elegant 
> if someone helped you find a proper on-board software solution.  If you 
> find a solution on your own please post it.  If you get desperate enough to 
> start soldering email me and I'll try to help.
>
> Cheers.
>
>
>

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

Re: [beagleboard] Re: Kernel 3.13 and above: How to enable dcan_1 and GPIOs

[Jason Lange]

...the instructions are pretty lousy.  If it's incomprehensible say so.
I'll help.

On Tue, Nov 25, 2014 at 1:39 AM, Jason Lange  wrote:

> this:
>
> https://groups.google.com/forum/#!topic/beagleboard/WuCvPyi9bqk
>
> suggests that you might be more interested in this:
>
> http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb
>
> On Tue, Nov 25, 2014 at 12:55 AM, Marco Steger 
> wrote:
>
>> Hi again!
>>
>> I spent some more hours on how to enable the d_can interfaces on my BBB.
>>
>> I found Robert Nelsons "Really Simple Cape Manager" (RSCM) here [1]. This
>> looks very promising at first. There is a folder for 3.13-bone and the
>> README says that
>>
>> 3.13-rc6-bone2 should be installed.
>>
>>
>> I'm currently working on 3.16.1-bone4. As far as I understand the idea
>> behind Robert’s  RSCM I would need the original .dts file of my BBB.
>> Than add the needed lines to enable d_can1 (to enable d_can0 I would have
>> to disable I2C2. Am I right?). The build a dtb file using dtc (patched by
>> Robert … he is present everywhere on the BBB I think! J) .
>>
>> Finally I can move this file to /boot/dtbs/3.16.1-bone4/ on my BBB
>> (replace the existing dtb file(s).
>>
>> But where can I find the dts file of my BBB? I wasn’t able to locate it
>> on my board. Can I use the dts file from 3.13? Can I (permanently) damage
>> my BBB when playing around here?
>>
>>
>>
>> Would be great if someone can help me!!!
>>
>>
>> [1] https://github.com/RobertCNelson/rscm
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [beagleboard] Re: Kernel 3.13 and above: How to enable dcan_1 and GPIOs

[Jason Lange]

this:

https://groups.google.com/forum/#!topic/beagleboard/WuCvPyi9bqk

suggests that you might be more interested in this:

http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb

On Tue, Nov 25, 2014 at 12:55 AM, Marco Steger 
wrote:

> Hi again!
>
> I spent some more hours on how to enable the d_can interfaces on my BBB.
>
> I found Robert Nelsons "Really Simple Cape Manager" (RSCM) here [1]. This
> looks very promising at first. There is a folder for 3.13-bone and the
> README says that
>
> 3.13-rc6-bone2 should be installed.
>
>
> I'm currently working on 3.16.1-bone4. As far as I understand the idea
> behind Robert’s  RSCM I would need the original .dts file of my BBB. Than
> add the needed lines to enable d_can1 (to enable d_can0 I would have to
> disable I2C2. Am I right?). The build a dtb file using dtc (patched by
> Robert … he is present everywhere on the BBB I think! J) .
>
> Finally I can move this file to /boot/dtbs/3.16.1-bone4/ on my BBB
> (replace the existing dtb file(s).
>
> But where can I find the dts file of my BBB? I wasn’t able to locate it on
> my board. Can I use the dts file from 3.13? Can I (permanently) damage my
> BBB when playing around here?
>
>
>
> Would be great if someone can help me!!!
>
>
> [1] https://github.com/RobertCNelson/rscm
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] a question about asking questions

[Jason Lange]

On Mon, Nov 24, 2014 at 11:05 PM,  wrote:

Hi,
>
>  I have still unresolved issue (no answer here for how to make pwm_P8_13
> low on boot? ) and therefore
> trying to figure out if my question is:
> - too easy
> - too difficult
> - not interesting enough
> - other?
>
> As I see there is generally a number of unanswered questions, would it be
> possible for the moderator to give an indication in a simple style,
> something like: "too easy, google it yourself" or whatever, to avoid
> frustration.
>
> Jan
>


Is there a moderator?  I don't know.

But for myself, your question is both too difficult (I don't know the
answer) and not interesting enough (It isn't a problem that I need to solve
for myself).  Everybody here is going to have a different response, so
having a moderator decide is probably a bit ham fisted.  I can imagine an
external hardware solution because I do circuits, but it'd be more elegant
if someone helped you find a proper on-board software solution.  If you
find a solution on your own please post it.  If you get desperate enough to
start soldering email me and I'll try to help.

Cheers.

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

[beagleboard] Re: Kernel 3.13 and above: How to enable dcan_1 and GPIOs

[Marco Steger]

 

Hi again!

I spent some more hours on how to enable the d_can interfaces on my BBB. 

I found Robert Nelsons "Really Simple Cape Manager" (RSCM) here [1]. This 
looks very promising at first. There is a folder for 3.13-bone and the 
README says that 

3.13-rc6-bone2 should be installed. 


I'm currently working on 3.16.1-bone4. As far as I understand the idea 
behind Robert’s  RSCM I would need the original .dts file of my BBB. Than 
add the needed lines to enable d_can1 (to enable d_can0 I would have to 
disable I2C2. Am I right?). The build a dtb file using dtc (patched by 
Robert … he is present everywhere on the BBB I think! J) .

Finally I can move this file to /boot/dtbs/3.16.1-bone4/ on my BBB (replace 
the existing dtb file(s). 

But where can I find the dts file of my BBB? I wasn’t able to locate it on 
my board. Can I use the dts file from 3.13? Can I (permanently) damage my 
BBB when playing around here?

 

Would be great if someone can help me!!!


[1] https://github.com/RobertCNelson/rscm

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

Re: [beagleboard] a question about asking questions

[William Hermans]

   1. The question has been asked countless times on the groups already,
   and as such can easily be searched on the groups.
   2. google should always be your first recourse. Most questions asked
   here are not specific to the hardware, and as such can easily be googled
   as: "how to debian ", etc.
   3. Not enough information given.
   4. There are literally 10's of thousands of packages, and tools, and
   x.y.z for Debian. This is why the distro was chosen( or one reason why ).
   Passed that, several ways to achieve most( all ? ) goals for .

People here have their own lives, and do not get paid to answer questions
here for anyone. As smart-ass as that may seem, this is the pure and simple
truth. Many others, myself included subscribe to this group through our
email, and get hammered by 30-100 emails a day just from this group alone.
For me, ever since the beaglebone black was released to the public.

While I can not speak for anyone else. Personally it bugs me to constantly
answer the same question over and over again. Multiple questions on the
same exact problem has been asked multiple times a day. More than once, and
by seemingly different people !!! As well as really simple stuff such as
compiler errors that can easily be copied / pasted into a browser to show
hundreds of thousands of hits. While the answer 99% of the time is on the
first search result page. Why should "we" have to google search for "you" ?

On top of that, we work, or do whatever it is that we all do daily, and try
to find time for our own hobbies. On top of this still, you have people
using this group to ask questions for their products based on beagle
hardware, or even writing books on the beaglebone . . . without so much as
a thank you, or contribution to the community. Unless it makes them a
"buck" in the process. Gratitude for ya . . .

So, do yourself a favor. Do as much of your own work for yourself as
possible. Have to scour 500 + google search hits to find a correct solution
? Tough, and welcome to the club. Log *EVERYTHING* you do, as you do it. So
when you do find something that works you can duplicate the process
reliably. Or if the solution still evades you. Guess what ? You have the
exact steps to show us that you've done in order to help solve your issue !

For the record, I have 3 unanswered posts on this group since last year.
Meaning: topics that I started trying to find information myself. So . . .
I tend to find all my own solutions using some form of a search - First.

On Tue, Nov 25, 2014 at 12:05 AM,  wrote:

> Hi,
>
>  I have still unresolved issue (no answer here for how to make pwm_P8_13
> low on boot? ) and therefore
> trying to figure out if my question is:
> - too easy
> - too difficult
> - not interesting enough
> - other?
>
> As I see there is generally a number of unanswered questions, would it be
> possible for the moderator to give an indication in a simple style,
> something like: "too easy, google it yourself" or whatever, to avoid
> frustration.
>
> Jan
>
>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] UARTs enabled but don't work on Debian!

[William Hermans]

What user is the script running as ?

On Mon, Nov 24, 2014 at 9:02 PM, John Mladenik 
wrote:

> Ok Sorry, I am trying to send characters out the UART2 on a BBB Rev C
> using HTML Javascript SEE program below:  This worked before and stopped
> working, not sure why.   Be patient with my I am a newbie a month or so
> into learning HTML. Javascript, linux, beaglebone, but only working on it
> part time outside of my regular job.
>
> I have a logic analyzer connected to P9 Pins 20 & 21 which are the UART2
> TX and RX line.   When I send the data using below program the TX pin does
> not toggle so no data comes out of the TX pin.
>
> When this worked it sent the data using program below and if I input a 5 a
> value of 0x05 was shifted out of the UART2 on the TX pin.My goal is to
> get the UART2 to work after power up without having to type in a bunch of
> commands before running the HTML/Javscript.
>
>
> When I type
> cat /sys/devices/bone_capemgr.*/slots
> I get the following:
>  0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART2
>
> I did add the following line to my uEnv.txt file
> capemgr.enable_partno=BB-UART2
>
> But this didn't seem to make a difference either way.Any suggestions
> would be appreciated.
>
> Example code below here ***
> // UART2 TX Test filename = uartwr.html
>
> 
> 
>
> Uart Byte:
> 
> SEND
>
> 
> 
> 
> 
>
> function uartWr() {
> var b = require('bonescript');
> // set baud rate and buffer size
>
> var port = '/dev/ttyO2'; // set UART port
> var data = document.getElementById('value').value;
>
> var options = { baudrate: 9600, buffer: 100} ;
> b.serialOpen(port, options, onSerial);//
>
> function onSerial(x) {
> var b = require('bonescript');
> if (x.err) {
> console.log('***ERROR*** ' + JSON.stringify(x));
> }
> if (x.event == 'open') {
>console.log('***OPENED***');
> }
> if (x.event == 'data') {
> console.log(String(x.data));
> }
> }
> b.serialWrite(port, [data] );
> }
>
>
> 
>
> 
> 
> Example code Above here ***
>
>
> On Saturday, November 22, 2014 7:52:22 PM UTC-8, William Hermans wrote:
>>
>> John, detailed description is required. "Dont work" is pretty vague and
>> leaves a lot of room for guessing.
>>
>> On Sat, Nov 22, 2014 at 8:41 PM, John Mladenik 
>> wrote:
>>
>>> Robert,
>>>
>>> I am having the same problem with UART2 (the only UART I need to work)
>>>  but mine worked in the past.  It even worked through re-power until the
>>> BBB sat overnight unpowered.  I went through all of the steps I found in
>>> links to make it work, but none of the steps were anything like yours.I
>>> am a newbie to software and linux so I don't really understand what you are
>>> saying to do.  .  Can you tell me what exactly your program and compile are
>>> doing?  Will it work for UART2.
>>>
>>> When you said "The pins aren't mixed to the peripheral." did you mean
>>> MUXED instead of mixed?
>>>
>>> so you have a dtb file that you compile into a dts file?   Since
>>> /src/arm does no exist on my BBB do I need to create that folder to copy
>>> the file into it?I assume it is changing the mux configuration of the
>>> UART pins to be connected in the ARM to the UART iinstead of the GPIO?
>>>
>>> Sorry of my questions seem dumb, but that is what I feel like, I spent
>>> at least 10-12 hours to get the UART to work the first time and when it
>>> stopped working the next day it set me back weeks in my project. :(
>>>
>>> On Friday, November 14, 2014 1:12:22 PM UTC-8, RobertCNelson wrote:

 http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb

 The pins aren't mixed to the peripheral.

 Example enable this

 https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/
 src/arm/am335x-boneblack.dts#L78

 And run...

 make ; sudo make install ; sudo reboot
 On Nov 14, 2014 2:46 PM,  wrote:

> I've been playing around with my BBB for about a month now and got
> everything up and running. Today I spent the whole day to get UART 
> loopback
> to work on Debian. It simply doesn't work! Tried with Qt (cross-compiled
> and all samples are working), QSerialPortInfo::availablePorts().count()
> returns zero. At first I thought it can be a QtSerialPort issue. So I did 
> a
> loop back on UART1 and UART2 (P9.21 connected to P9.26 and P9.22 connected
> to P9.24). Then opened "minicom -b 9600 -D /dev/ttyO1" and "minicom -b 
> 9600
> -D /dev/ttyO2" in two separate terminals. I expected to see whatever I 
> type
> in each one of the terminals on the other one. But that wasn't the case.
> Nothing h