[beagleboard] Debian 3.8.13-bone-68 and RALINK 7601 driver

[Colin Bester]

I have been using the 5370 driver for usb wifi dongle successfully with 
ability to support both Master and Managed mode with no issues whatsoever.

However last batch of wifi dongles delivered no longer work and lsusb shows
  Bus 001 Device 002: ID 148f:7601 Ralink Technology, Corp. 
instead of 
  Bus 001 Device 002: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless 
Adapter

I expected the 7601 drivers to be installed in my build (Debian 
3.8.13-bone68, which I am stuck with for now due to changes in bone69 and 
up that makes using LCD and Audio Cape together an issue 
)
 
but this doesn't appear to be the case.

Powering with external 5V, and ensuring usb dongle is inserted prior to 
power up.

dmesg shows 
[1.097202] usb 1-1: new high-speed USB device number 2 using musb-hdrc
[1.216778] usb 1-1: default language 0x0409
[1.581547] usb 1-1: udev 2, busnum 1, minor = 1
[1.581571] usb 1-1: New USB device found, idVendor=148f, idProduct=7601
[1.581583] usb 1-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[1.582006] usb 1-1: usb_probe_device
[1.582024] usb 1-1: configuration #1 chosen from 1 choice
[1.582114] usb 1-1: adding 1-1:1.0 (config #1, interface 0)

Running lsmod shows no indication of wifi driver

I have also tried building various 7601 driver sources but am unable to get 
both managed and master mode working.

Does/should 3.8.13-bone68 support 7601 driver? If so what could I be doing 
wrong.

If not supported, any suggestion on source files to build in order to 
support both managed and master mode.

This feels like a pretty solid wall I have hit and would appreciate any 
assistance 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] compiler for BBB wheezy ( glibc 2.13 version problem )

[박연호]

Hello, RobertCNelson.
I appreciate your effort. 

I would like to mention finding networking more detail.
It seems networking daemon takes too much time for looking DHCP. 
If BBB doesn't be connected to a Lan cable, it takes too much time to boot.

By the way, USB Networking 192.168.7.2 problem is critical.
If the problem is fixed. I can use jessie Image.


Thank you very very much...




2015년 8월 10일 월요일 오후 9시 32분 47초 UTC+9, RobertCNelson 님의 말:
>
> On Mon, Aug 10, 2015 at 2:01 AM, 박연호 > 
> wrote: 
> > I had used the Jessie image, but it has problems. 
> > 
> > First, USB Network 192.168.7.2 doesn't work constantly, 
> > For example, after reboot or reconnect bbb, it doesn't wort at all. 
>
> Why didn't you report this?  I had another user report it on saturday, 
> i'm taking a look at in a litle bit this morning.. 
>
> > Second, finding networking takes too much time. 
> > 
> > Thirds, somehow wheezy's HDMI has better comparability. 
>
> sudo apt-get update 
> sudo apt-get install linux-image-3.8.13-bone73 
> sudo reboot 
>
>
> > Generally, Wheezy seems far more stable than Jessie. 
> > 
> > I gave up Jessie for those reasons. 
> > 
> > Please, Is there any compiler for armhf glibc 2.13? 
>
> Nope, build on target.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Felipe Balbi]

On Mon, Aug 10, 2015 at 03:04:52PM -0500, Robert Nelson wrote:
> On Mon, Aug 10, 2015 at 2:59 PM, Robert Nelson  
> wrote:
> > On Mon, Aug 10, 2015 at 2:55 PM, Felipe Balbi  wrote:
> >> Hi again,
> >>
> >> On Mon, Aug 10, 2015 at 02:48:11PM -0500, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> I'll leave my BBB running with v4.1.0 vanilla, with Debian unstable
> >>> userland.
> >>
> >> are you guys running with or without wkup_m3 firmware ? Is PM enabled at
> >> all ?
> >
> > The v4.1.x-ti-rX have pm enabled and wkup_m3 firmware..
> 
> m3: 0x191: 277eef8611e260a5d73a9e3773fff8f767fe2b01
> 
> head of "next-upstream"
> http://git.ti.com/gitweb/?p=ti-cm3-pm-firmware/amx3-cm3.git;a=shortlog;h=refs/heads/next-upstream

all right, but if you reproduced without PM, I'll stick my tests to
vanilla kernels.

-- 
balbi

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


signature.asc
Description: Digital signature

Re: [beagleboard] Re: BBB intermittently rebooting.

[William Hermans]

Hi Maxim,

The reason why we did this is that the board in question was mounted to a
piece of wood, that is screwed into a wall. So grounding Vbus would not
have been easy. Vusb for us was really easy. Solder the outside pins on a
USB A socket to the outer shielding, then plug a MALE A to mini B cable to
the socket, and BBB. Took a total of like 5 minutes . . .

Normally I do not worry about any of this, and use USB power. Except this
time for this project we needed the canbus running, and powering via USB
cause the canbus to be less than reliable.

On Mon, Aug 10, 2015 at 9:36 AM, Maxim Podbereznyy 
wrote:

> William, or short Vusb to 5V, the result is the same - total stability.
> You can do it if you need to enable the USB-Host function at USB0
>
> 2015-08-08 23:22 GMT+03:00 William Hermans :
>
>> So far shorting Vusb to ground seems to be doing the trick. We'll give it
>> a couple days to be "sure". Prior to shorting Vusb to ground, this linux
>> image would reboot several times a day ( 4-5 )
>>
>> william@xanbustester:~$ uptime
>>>  13:20:26 up 15:28,  3 users,  load average: 0.01, 0.02, 0.05
>>> william@xanbustester:~$ uname -r
>>> 4.2.0-rc4-bone2
>>>
>>
>>
>>
>> On Fri, Aug 7, 2015 at 5:31 PM, William Hermans 
>> wrote:
>>
>>> Starting new post . . .
>>>
>>> On Fri, Aug 7, 2015 at 5:19 PM, William Hermans 
>>> wrote:
>>>
 Ok, I'm stuck in a boot loop, what you see above is what I keep
 getting. Let me explore some.

 On Fri, Aug 7, 2015 at 5:17 PM, Robert Nelson 
 wrote:

> On Fri, Aug 7, 2015 at 7:13 PM, William Hermans 
> wrote:
> > These TI kernels support nfsroot ?
>
> They should. ;)
>
> bone kernel: bone patchset + mainline
> ti kernel: bone patchset + ti patchset + mainline..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com.
> 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.
>>
>
>
>
> --
> LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
> Company - http://www.linkedin.com/company/mentorel
> Facebook - https://www.facebook.com/mentorel.company
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to 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] BeagleBone Black Relay Module

[evilwulfie]

unless your using level translators your going to fry your BBB
BBB has 3.3v I/O




On 8/10/2015 9:44 AM, Manuel David Garcia Cardenas wrote:
>
> Hello!
> This is the first time I write here. I'm from Spain, so firstly sorry
> for my bad english :D
>
> We are connecting a BBB with a 5v 8-relay module, with the pins
> 66,67,68,69,45,44,23,26, and pin p9_01 for gnd and P9_05 for 5V
>
> We have two problems. When the system start, the relay #1 goes on, and
> 3 minutes later, the relay #1 goes off.
> The second problem comes when we halt the system. When we do this
> action, all the relays goes on.
>
> We don't know what's happening. We are trying all we know to solve this.
>
> Please, help us. 
>
> Best Regards
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> 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] Image 2015-7-26, kernel 4.1.3-ti-r6

[Robert Nelson]

On Mon, Aug 10, 2015 at 2:59 PM, Robert Nelson  wrote:
> On Mon, Aug 10, 2015 at 2:55 PM, Felipe Balbi  wrote:
>> Hi again,
>>
>> On Mon, Aug 10, 2015 at 02:48:11PM -0500, Felipe Balbi wrote:
>>> Hi,
>>>
>>> I'll leave my BBB running with v4.1.0 vanilla, with Debian unstable
>>> userland.
>>
>> are you guys running with or without wkup_m3 firmware ? Is PM enabled at
>> all ?
>
> The v4.1.x-ti-rX have pm enabled and wkup_m3 firmware..

m3: 0x191: 277eef8611e260a5d73a9e3773fff8f767fe2b01

head of "next-upstream"
http://git.ti.com/gitweb/?p=ti-cm3-pm-firmware/amx3-cm3.git;a=shortlog;h=refs/heads/next-upstream

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Robert Nelson]

On Mon, Aug 10, 2015 at 2:55 PM, Felipe Balbi  wrote:
> Hi again,
>
> On Mon, Aug 10, 2015 at 02:48:11PM -0500, Felipe Balbi wrote:
>> Hi,
>>
>> I'll leave my BBB running with v4.1.0 vanilla, with Debian unstable
>> userland.
>
> are you guys running with or without wkup_m3 firmware ? Is PM enabled at
> all ?

The v4.1.x-ti-rX have pm enabled and wkup_m3 firmware..

It's using ti's 4.1.y as base:
http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.1.y

BUT..

When doing the v4.0.0 <-> v4.1.0-rc1 bisect the wkup firmware wasn't
used. (this why it took a couple of days to factor out our local & ti
patchset against v4.1.0-rc1)

Here's the config I used during the bisect:

https://github.com/RobertCNelson/bisector/blob/master/patches/defconfig

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Felipe Balbi]

Hi again,

On Mon, Aug 10, 2015 at 02:48:11PM -0500, Felipe Balbi wrote:
> Hi,
> 
> I'll leave my BBB running with v4.1.0 vanilla, with Debian unstable
> userland.

are you guys running with or without wkup_m3 firmware ? Is PM enabled at
all ?

[ trim ]

-- 
balbi

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


signature.asc
Description: Digital signature

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Felipe Balbi]

Hi,

I'll leave my BBB running with v4.1.0 vanilla, with Debian unstable
userland.

On Mon, Aug 10, 2015 at 02:20:22PM -0500, Robert Nelson wrote:
> On Mon, Aug 10, 2015 at 2:16 PM, Robert Nelson  
> wrote:
> > On Mon, Aug 10, 2015 at 2:00 PM, Felipe Balbi  wrote:
> >> Hi,
> >>
> >> On Mon, Aug 10, 2015 at 01:56:04PM -0500, Robert Nelson wrote:
> >>> On Mon, Aug 10, 2015 at 1:05 PM, Robert Nelson  
> >>> wrote:
> >>> > On Mon, Aug 10, 2015 at 11:23 AM, Nuno Gonçalves  
> >>> > wrote:
> >>> >> 3 weeks ago I asked for it "For what is worth I believe the OMAP and
> >>> >> PMIC reset reason registers should be part of the boot log so future
> >>> >> reboot problems can be sorted.".
> >>> >>
> >>> >> But I just asked, I didn't actually code!
> >>> >>
> >>> >> Not sure if it is easy to retrieve both, or if PMIC is that much
> >>> >> relevant for this issues.
> >>> >>
> >>> >> Anyway, this will surely take out black magic from the equation when
> >>> >> debugging this problems.
> >>> >
> >>> > Okay here's something quick/dirty...
> >>> >
> >>> > http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/MLO-am335x_evm-v2015.07-r3
> >>> > http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/u-boot-am335x_evm-v2015.07-r3.img
> >>> >
> >>> > #patch:
> >>> > https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L21
> >>> >
> >>> > make sure the eMMC doesn't have it's own bootloader:
> >>> >
> >>> > U-Boot 2015.07-1-gd8d32cf (Aug 10 2015 - 12:54:52 -0500)
> >>> >
> >>> >Watchdog enabled
> >>> > I2C:   ready
> >>> > DRAM:  512 MiB
> >>> > Reset Source: Global external warm reset has occurred.
> >>> > Reset Source: Power-on reset has occurred.
> >>> > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> >>> > Using default environment
> >>> >
> >>> > dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
> >>> >
> >>> > sudo dd if=MLO-am335x_evm-v2015.07-r3 of=/dev/sde count=1 seek=1 bs=128k
> >>> > sudo dd if=u-boot-am335x_evm-v2015.07-r3.img of=/dev/sde count=2 seek=1 
> >>> > bs=384k
> >>> >
> >>> > I need to fire up x86, that's attached to the bbb's (right now i can't
> >>> > log serial)
> >>>
> >>> Okay within a few minutes the first board rebooted...
> >>>
> >>> "Reset Source: Power-on reset has occurred." 
> >>
> >> weird, this is likely either flakey DC Jack connection, or PMIC going
> >> bonkers.
> >>
> >> How do you guys reproduce this ? Is the board idle or is it running ?
> >> Which gadget driver ? Is USB cable connected to a host ? A desktop
> >> host or wired back into the host port of BBB itself ?
> >>
> >> I wanna try to reproduce it here.
> >
> > Pretty much just grab:
> >
> > http://rcn-ee.com/rootfs/bb.org/testing/2015-08-09/console/bb-debian-8.1-console-armhf-2015-08-09-2gb.img.xz
> >
> > dd it to a microSD card and just let it idle..
> >
> > powered via DC
> > ethernet connected (i was echoing "uptime -p" to a file on nfs)
> > serial debug attached
> > usb otg = not connected.. (if you connect this it'll stay ON and won't 
> > reset)
> > usb host = not connected
> > hdmi = not connected
> > no capes plugged in
> >
> > gadget drivers: 4.1.4-ti-rt-r8
> >
> > CONFIG_USB_MUSB_HDRC=y
> > # CONFIG_USB_MUSB_HOST is not set
> > # CONFIG_USB_MUSB_GADGET is not set
> > CONFIG_USB_MUSB_DUAL_ROLE=y
> >
> > CONFIG_USB_MUSB_DSPS=y
> > CONFIG_USB_MUSB_AM335X_CHILD=y
> > # CONFIG_USB_TI_CPPI41_DMA is not set
> > CONFIG_MUSB_PIO_ONLY=y
> >
> > CONFIG_USB_LIBCOMPOSITE=y
> > CONFIG_USB_U_ETHER=y
> > CONFIG_USB_F_ECM=y
> > CONFIG_USB_F_SUBSET=y
> > CONFIG_USB_F_RNDIS=y
> > # CONFIG_USB_CONFIGFS is not set
> > # CONFIG_USB_ZERO is not set
> > # CONFIG_USB_AUDIO is not set
> > CONFIG_USB_ETH=y
> > CONFIG_USB_ETH_RNDIS=y
> >
> > https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/4.1.4-ti-rt-r8/patches/defconfig#L4804-L4813
> 
> Opps that's the rt variant..
> 
> https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/4.1.4-ti-r8/patches/defconfig#L4810-L4819
> 
> (that section is the same, but to dot the i's)
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/

-- 
balbi

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


signature.asc
Description: Digital signature

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Robert Nelson]

On Mon, Aug 10, 2015 at 2:16 PM, Robert Nelson  wrote:
> On Mon, Aug 10, 2015 at 2:00 PM, Felipe Balbi  wrote:
>> Hi,
>>
>> On Mon, Aug 10, 2015 at 01:56:04PM -0500, Robert Nelson wrote:
>>> On Mon, Aug 10, 2015 at 1:05 PM, Robert Nelson  
>>> wrote:
>>> > On Mon, Aug 10, 2015 at 11:23 AM, Nuno Gonçalves  
>>> > wrote:
>>> >> 3 weeks ago I asked for it "For what is worth I believe the OMAP and
>>> >> PMIC reset reason registers should be part of the boot log so future
>>> >> reboot problems can be sorted.".
>>> >>
>>> >> But I just asked, I didn't actually code!
>>> >>
>>> >> Not sure if it is easy to retrieve both, or if PMIC is that much
>>> >> relevant for this issues.
>>> >>
>>> >> Anyway, this will surely take out black magic from the equation when
>>> >> debugging this problems.
>>> >
>>> > Okay here's something quick/dirty...
>>> >
>>> > http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/MLO-am335x_evm-v2015.07-r3
>>> > http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/u-boot-am335x_evm-v2015.07-r3.img
>>> >
>>> > #patch:
>>> > https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L21
>>> >
>>> > make sure the eMMC doesn't have it's own bootloader:
>>> >
>>> > U-Boot 2015.07-1-gd8d32cf (Aug 10 2015 - 12:54:52 -0500)
>>> >
>>> >Watchdog enabled
>>> > I2C:   ready
>>> > DRAM:  512 MiB
>>> > Reset Source: Global external warm reset has occurred.
>>> > Reset Source: Power-on reset has occurred.
>>> > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>> > Using default environment
>>> >
>>> > dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
>>> >
>>> > sudo dd if=MLO-am335x_evm-v2015.07-r3 of=/dev/sde count=1 seek=1 bs=128k
>>> > sudo dd if=u-boot-am335x_evm-v2015.07-r3.img of=/dev/sde count=2 seek=1 
>>> > bs=384k
>>> >
>>> > I need to fire up x86, that's attached to the bbb's (right now i can't
>>> > log serial)
>>>
>>> Okay within a few minutes the first board rebooted...
>>>
>>> "Reset Source: Power-on reset has occurred." 
>>
>> weird, this is likely either flakey DC Jack connection, or PMIC going
>> bonkers.
>>
>> How do you guys reproduce this ? Is the board idle or is it running ?
>> Which gadget driver ? Is USB cable connected to a host ? A desktop
>> host or wired back into the host port of BBB itself ?
>>
>> I wanna try to reproduce it here.
>
> Pretty much just grab:
>
> http://rcn-ee.com/rootfs/bb.org/testing/2015-08-09/console/bb-debian-8.1-console-armhf-2015-08-09-2gb.img.xz
>
> dd it to a microSD card and just let it idle..
>
> powered via DC
> ethernet connected (i was echoing "uptime -p" to a file on nfs)
> serial debug attached
> usb otg = not connected.. (if you connect this it'll stay ON and won't reset)
> usb host = not connected
> hdmi = not connected
> no capes plugged in
>
> gadget drivers: 4.1.4-ti-rt-r8
>
> CONFIG_USB_MUSB_HDRC=y
> # CONFIG_USB_MUSB_HOST is not set
> # CONFIG_USB_MUSB_GADGET is not set
> CONFIG_USB_MUSB_DUAL_ROLE=y
>
> CONFIG_USB_MUSB_DSPS=y
> CONFIG_USB_MUSB_AM335X_CHILD=y
> # CONFIG_USB_TI_CPPI41_DMA is not set
> CONFIG_MUSB_PIO_ONLY=y
>
> CONFIG_USB_LIBCOMPOSITE=y
> CONFIG_USB_U_ETHER=y
> CONFIG_USB_F_ECM=y
> CONFIG_USB_F_SUBSET=y
> CONFIG_USB_F_RNDIS=y
> # CONFIG_USB_CONFIGFS is not set
> # CONFIG_USB_ZERO is not set
> # CONFIG_USB_AUDIO is not set
> CONFIG_USB_ETH=y
> CONFIG_USB_ETH_RNDIS=y
>
> https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/4.1.4-ti-rt-r8/patches/defconfig#L4804-L4813

Opps that's the rt variant..

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/4.1.4-ti-r8/patches/defconfig#L4810-L4819

(that section is the same, but to dot the i's)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Graham Haddock]

It is not a flakey DC jack. But yes the symptoms do mimic that kind of
failure.
Same hardware works fine with Debian 8.1/kernel 3.14 and prior.

It happens under all loading /activity, but easy to reproduce with the
board idling, minimum console software load.

It does not happen with the board powered by the USB port.
It only happens when powered by the +5V barrel jack.

No indication in syslog as to what happened.

==

I note that you were working in area changing ticks to jiffies or something
like that.

I personally suspect that there was some code dependent on the previous
timing system
that was used to time some of the USB power switch over mechanisms, that
was not updated
to deal with the timing system changes you made.

For instance, the On-the-Go USB system periodically pushes power out the
USB port
to see if someone has connected a USB device.  The PMIC sees this and can
interpret
this as power has appeared on the USB connector and to attempt a
switchover.  It really
needs to wait some time period to see that it is stable input power rather
than a power probe
pulse generated by the BBB itself.  If your timing system changes modified
this
switchover timing, the system could attempt to switch to a non-existant
power source and
die, causing a power-on reboot.

This theory is supported by experimental tests run by William that says if
the USB
power line is shorted to ground, then the unit does not reboot.

I am just summarizing several weeks of observations by all the guys on this
thread.

--- Graham



On Mon, Aug 10, 2015 at 2:00 PM, Felipe Balbi  wrote:

> Hi,
>
> On Mon, Aug 10, 2015 at 01:56:04PM -0500, Robert Nelson wrote:
> > On Mon, Aug 10, 2015 at 1:05 PM, Robert Nelson 
> wrote:
> > > On Mon, Aug 10, 2015 at 11:23 AM, Nuno Gonçalves 
> wrote:
> > >> 3 weeks ago I asked for it "For what is worth I believe the OMAP and
> > >> PMIC reset reason registers should be part of the boot log so future
> > >> reboot problems can be sorted.".
> > >>
> > >> But I just asked, I didn't actually code!
> > >>
> > >> Not sure if it is easy to retrieve both, or if PMIC is that much
> > >> relevant for this issues.
> > >>
> > >> Anyway, this will surely take out black magic from the equation when
> > >> debugging this problems.
> > >
> > > Okay here's something quick/dirty...
> > >
> > >
> http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/MLO-am335x_evm-v2015.07-r3
> > >
> http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/u-boot-am335x_evm-v2015.07-r3.img
> > >
> > > #patch:
> > >
> https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L21
> > >
> > > make sure the eMMC doesn't have it's own bootloader:
> > >
> > > U-Boot 2015.07-1-gd8d32cf (Aug 10 2015 - 12:54:52 -0500)
> > >
> > >Watchdog enabled
> > > I2C:   ready
> > > DRAM:  512 MiB
> > > Reset Source: Global external warm reset has occurred.
> > > Reset Source: Power-on reset has occurred.
> > > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > > Using default environment
> > >
> > > dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
> > >
> > > sudo dd if=MLO-am335x_evm-v2015.07-r3 of=/dev/sde count=1 seek=1
> bs=128k
> > > sudo dd if=u-boot-am335x_evm-v2015.07-r3.img of=/dev/sde count=2
> seek=1 bs=384k
> > >
> > > I need to fire up x86, that's attached to the bbb's (right now i can't
> > > log serial)
> >
> > Okay within a few minutes the first board rebooted...
> >
> > "Reset Source: Power-on reset has occurred." 
>
> weird, this is likely either flakey DC Jack connection, or PMIC going
> bonkers.
>
> How do you guys reproduce this ? Is the board idle or is it running ?
> Which gadget driver ? Is USB cable connected to a host ? A desktop
> host or wired back into the host port of BBB itself ?
>
> I wanna try to reproduce it here.
>
> --
> balbi
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Image 2015-7-26, kernel 4.1.3-ti-r6

[Robert Nelson]

On Mon, Aug 10, 2015 at 2:00 PM, Felipe Balbi  wrote:
> Hi,
>
> On Mon, Aug 10, 2015 at 01:56:04PM -0500, Robert Nelson wrote:
>> On Mon, Aug 10, 2015 at 1:05 PM, Robert Nelson  
>> wrote:
>> > On Mon, Aug 10, 2015 at 11:23 AM, Nuno Gonçalves  wrote:
>> >> 3 weeks ago I asked for it "For what is worth I believe the OMAP and
>> >> PMIC reset reason registers should be part of the boot log so future
>> >> reboot problems can be sorted.".
>> >>
>> >> But I just asked, I didn't actually code!
>> >>
>> >> Not sure if it is easy to retrieve both, or if PMIC is that much
>> >> relevant for this issues.
>> >>
>> >> Anyway, this will surely take out black magic from the equation when
>> >> debugging this problems.
>> >
>> > Okay here's something quick/dirty...
>> >
>> > http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/MLO-am335x_evm-v2015.07-r3
>> > http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/u-boot-am335x_evm-v2015.07-r3.img
>> >
>> > #patch:
>> > https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L21
>> >
>> > make sure the eMMC doesn't have it's own bootloader:
>> >
>> > U-Boot 2015.07-1-gd8d32cf (Aug 10 2015 - 12:54:52 -0500)
>> >
>> >Watchdog enabled
>> > I2C:   ready
>> > DRAM:  512 MiB
>> > Reset Source: Global external warm reset has occurred.
>> > Reset Source: Power-on reset has occurred.
>> > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> > Using default environment
>> >
>> > dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
>> >
>> > sudo dd if=MLO-am335x_evm-v2015.07-r3 of=/dev/sde count=1 seek=1 bs=128k
>> > sudo dd if=u-boot-am335x_evm-v2015.07-r3.img of=/dev/sde count=2 seek=1 
>> > bs=384k
>> >
>> > I need to fire up x86, that's attached to the bbb's (right now i can't
>> > log serial)
>>
>> Okay within a few minutes the first board rebooted...
>>
>> "Reset Source: Power-on reset has occurred." 
>
> weird, this is likely either flakey DC Jack connection, or PMIC going
> bonkers.
>
> How do you guys reproduce this ? Is the board idle or is it running ?
> Which gadget driver ? Is USB cable connected to a host ? A desktop
> host or wired back into the host port of BBB itself ?
>
> I wanna try to reproduce it here.

Pretty much just grab:

http://rcn-ee.com/rootfs/bb.org/testing/2015-08-09/console/bb-debian-8.1-console-armhf-2015-08-09-2gb.img.xz

dd it to a microSD card and just let it idle..

powered via DC
ethernet connected (i was echoing "uptime -p" to a file on nfs)
serial debug attached
usb otg = not connected.. (if you connect this it'll stay ON and won't reset)
usb host = not connected
hdmi = not connected
no capes plugged in

gadget drivers: 4.1.4-ti-rt-r8

CONFIG_USB_MUSB_HDRC=y
# CONFIG_USB_MUSB_HOST is not set
# CONFIG_USB_MUSB_GADGET is not set
CONFIG_USB_MUSB_DUAL_ROLE=y

CONFIG_USB_MUSB_DSPS=y
CONFIG_USB_MUSB_AM335X_CHILD=y
# CONFIG_USB_TI_CPPI41_DMA is not set
CONFIG_MUSB_PIO_ONLY=y

CONFIG_USB_LIBCOMPOSITE=y
CONFIG_USB_U_ETHER=y
CONFIG_USB_F_ECM=y
CONFIG_USB_F_SUBSET=y
CONFIG_USB_F_RNDIS=y
# CONFIG_USB_CONFIGFS is not set
# CONFIG_USB_ZERO is not set
# CONFIG_USB_AUDIO is not set
CONFIG_USB_ETH=y
CONFIG_USB_ETH_RNDIS=y

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/4.1.4-ti-rt-r8/patches/defconfig#L4804-L4813

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Felipe Balbi]

Hi,

On Mon, Aug 10, 2015 at 01:56:04PM -0500, Robert Nelson wrote:
> On Mon, Aug 10, 2015 at 1:05 PM, Robert Nelson  
> wrote:
> > On Mon, Aug 10, 2015 at 11:23 AM, Nuno Gonçalves  wrote:
> >> 3 weeks ago I asked for it "For what is worth I believe the OMAP and
> >> PMIC reset reason registers should be part of the boot log so future
> >> reboot problems can be sorted.".
> >>
> >> But I just asked, I didn't actually code!
> >>
> >> Not sure if it is easy to retrieve both, or if PMIC is that much
> >> relevant for this issues.
> >>
> >> Anyway, this will surely take out black magic from the equation when
> >> debugging this problems.
> >
> > Okay here's something quick/dirty...
> >
> > http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/MLO-am335x_evm-v2015.07-r3
> > http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/u-boot-am335x_evm-v2015.07-r3.img
> >
> > #patch:
> > https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L21
> >
> > make sure the eMMC doesn't have it's own bootloader:
> >
> > U-Boot 2015.07-1-gd8d32cf (Aug 10 2015 - 12:54:52 -0500)
> >
> >Watchdog enabled
> > I2C:   ready
> > DRAM:  512 MiB
> > Reset Source: Global external warm reset has occurred.
> > Reset Source: Power-on reset has occurred.
> > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > Using default environment
> >
> > dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
> >
> > sudo dd if=MLO-am335x_evm-v2015.07-r3 of=/dev/sde count=1 seek=1 bs=128k
> > sudo dd if=u-boot-am335x_evm-v2015.07-r3.img of=/dev/sde count=2 seek=1 
> > bs=384k
> >
> > I need to fire up x86, that's attached to the bbb's (right now i can't
> > log serial)
> 
> Okay within a few minutes the first board rebooted...
> 
> "Reset Source: Power-on reset has occurred." 

weird, this is likely either flakey DC Jack connection, or PMIC going
bonkers.

How do you guys reproduce this ? Is the board idle or is it running ?
Which gadget driver ? Is USB cable connected to a host ? A desktop
host or wired back into the host port of BBB itself ?

I wanna try to reproduce it here.

-- 
balbi

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


signature.asc
Description: Digital signature

Re: [beagleboard] How to interface a second sd card (that operates in SPI mode) under the 4.1 kernel?

[thomastdt]

RCNelson, Thanks for you help so far.

When trying to compile the 4.1 kernel i'm running into an ftrace error:
...
arch/arm/kernel/ftrace.c: In function 
‘ftrace_arch_code_modify_post_process’:
arch/arm/kernel/ftrace.c:93:2: error: implicit declaration of function 
‘flush_tlb_all’ [-Werror=implicit-function-declaration]
  flush_tlb_all();
  ^
cc1: some warnings being treated as errors
scripts/Makefile.build:258: recipe for target 'arch/arm/kernel/ftrace.o' 
failed
make[1]: *** [arch/arm/kernel/ftrace.o] Error 1
Makefile:946: recipe for target 'arch/arm/kernel' failed
make: *** [arch/arm/kernel] Error 2


Is there any kernel patch i can install to fix this error?

Also I decided to use the mmc2 lines for the sd card instead of using the 
spi bus.  I believe that the pin configuration is correct but the 
beaglebone is still not detecting the sd card.

In the *am335x-bone-common.dtsi* file:

mmc2_pins: pinmux_mmc2_pins {
pinctrl-single,pins = <
0x078 (PIN_OUTPUT_PULLUP | MUX_MODE3)   /* 
mmc2_dat3---CS, p9_12*/
0x044 (PIN_INPUT_PULLUP | MUX_MODE3)/* 
mmc2_dat0---DO---MISO, p9_23 */
0x088 (PIN_OUTPUT_PULLUP | MUX_MODE3)   /* 
mmc2_cmd---T13---MOSI */
0x08c (PIN_OUTPUT_PULLUP | MUX_MODE3)   /* 
mmc2_clk, p8_18 */
0x040 (PIN_OUTPUT_PULLUP | MUX_MODE7)   /* 
R13 which is tied to T13, p9_15*/
0x074 (PIN_INPUT_PULLUP | MUX_MODE4)/* 
mmc2_sdcd, p9_13 */
0x048 (PIN_INPUT_PULLUP | MUX_MODE3)/* 
mmc2_dat1, p9_14 */
0x04c (PIN_INPUT_PULLUP | MUX_MODE3)/* 
mmc2_dat2, p9_16 */

>;


};


&mmc2 {
status = "okay";
bus-width = <0x4>;
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins>;
};


I figured out that mmc2_cmd pin is the T13 ZCZ Ball: 
http://www.ti.com/product/AM3358/datasheet/terminal_configuration_and_functions#bc_15x15_T13

and that the T13 line is tied to the R13 line, so i configured R13 to GPIO 
output pullup and T13 as mode 3 output pullup. 

Is there anything else in the device tree that needs to be edited in order 
to get mmc2 detected by the OS on the beaglebone?


On Wednesday, August 5, 2015 at 6:35:12 AM UTC-7, RobertCNelson wrote:
>
> On Tue, Aug 4, 2015 at 7:32 PM,  > 
> wrote: 
> > I've managed to disable HIGHMEM from within the kernel.  However im 
> having 
> > trouble compiling.  The usual 'make clean' and 'make all' gives me 
> errors: 
> > 
> > root@beaglebone:/usr/src/linux-headers-4.1.2-ti-r4# make all 
> >   CHK include/config/kernel.release 
> >   UPD include/config/kernel.release 
> >   CHK include/generated/uapi/linux/version.h 
> >   CHK include/generated/utsrelease.h 
> >   UPD include/generated/utsrelease.h 
> > make[1]: *** No rule to make target 'arch/arm/tools/gen-mach-types', 
> needed 
> > by 'include/generated/mach-types.h'.  Stop. 
> > arch/arm/Makefile:297: recipe for target 'archprepare' failed 
> > make: *** [archprepare] Error 2 
>
> Sorry, that's "headers" 
>
> > root@beaglebone:/usr/src/linux-"headers"-4.1.2-ti-r4# make all 
>
> Grab the source via: 
>
> git clone -b 4.1.2-ti-r4 https://github.com/beagleboard/linux --depth=1 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Robert Nelson]

On Mon, Aug 10, 2015 at 1:05 PM, Robert Nelson  wrote:
> On Mon, Aug 10, 2015 at 11:23 AM, Nuno Gonçalves  wrote:
>> 3 weeks ago I asked for it "For what is worth I believe the OMAP and
>> PMIC reset reason registers should be part of the boot log so future
>> reboot problems can be sorted.".
>>
>> But I just asked, I didn't actually code!
>>
>> Not sure if it is easy to retrieve both, or if PMIC is that much
>> relevant for this issues.
>>
>> Anyway, this will surely take out black magic from the equation when
>> debugging this problems.
>
> Okay here's something quick/dirty...
>
> http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/MLO-am335x_evm-v2015.07-r3
> http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/u-boot-am335x_evm-v2015.07-r3.img
>
> #patch:
> https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L21
>
> make sure the eMMC doesn't have it's own bootloader:
>
> U-Boot 2015.07-1-gd8d32cf (Aug 10 2015 - 12:54:52 -0500)
>
>Watchdog enabled
> I2C:   ready
> DRAM:  512 MiB
> Reset Source: Global external warm reset has occurred.
> Reset Source: Power-on reset has occurred.
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Using default environment
>
> dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
>
> sudo dd if=MLO-am335x_evm-v2015.07-r3 of=/dev/sde count=1 seek=1 bs=128k
> sudo dd if=u-boot-am335x_evm-v2015.07-r3.img of=/dev/sde count=2 seek=1 
> bs=384k
>
> I need to fire up x86, that's attached to the bbb's (right now i can't
> log serial)

Okay within a few minutes the first board rebooted...

"Reset Source: Power-on reset has occurred." 

bbb-4 is an "A6" model..  I have 3 others still running, so i'll keep
track of those too...

root@test-bbb-4:~#
U-Boot SPL 2015.07-1-gd8d32cf (Aug 10 2015 - 12:54:52)


U-Boot 2015.07-1-gd8d32cf (Aug 10 2015 - 12:54:52 -0500)

   Watchdog enabled
I2C:   ready
DRAM:  512 MiB
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot:  0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
gpio: pin 55 (gpio 55) value is 1
1550 bytes read in 31 ms (48.8 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
gpio: pin 56 (gpio 56) value is 1
Running uname_boot ...
loading /boot/vmlinuz-4.1.4-ti-r8 ...

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Robert Nelson]

On Mon, Aug 10, 2015 at 11:23 AM, Nuno Gonçalves  wrote:
> 3 weeks ago I asked for it "For what is worth I believe the OMAP and
> PMIC reset reason registers should be part of the boot log so future
> reboot problems can be sorted.".
>
> But I just asked, I didn't actually code!
>
> Not sure if it is easy to retrieve both, or if PMIC is that much
> relevant for this issues.
>
> Anyway, this will surely take out black magic from the equation when
> debugging this problems.

Okay here's something quick/dirty...

http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/MLO-am335x_evm-v2015.07-r3
http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/u-boot-am335x_evm-v2015.07-r3.img

#patch:
https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L21

make sure the eMMC doesn't have it's own bootloader:

U-Boot 2015.07-1-gd8d32cf (Aug 10 2015 - 12:54:52 -0500)

   Watchdog enabled
I2C:   ready
DRAM:  512 MiB
Reset Source: Global external warm reset has occurred.
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

sudo dd if=MLO-am335x_evm-v2015.07-r3 of=/dev/sde count=1 seek=1 bs=128k
sudo dd if=u-boot-am335x_evm-v2015.07-r3.img of=/dev/sde count=2 seek=1 bs=384k

I need to fire up x86, that's attached to the bbb's (right now i can't
log serial)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

[beagleboard] Re: Image 2015-7-26, kernel 4.1.3-ti-r6

[Graham]

Bruce:

The system generates a "syslog" text file per day stored at  /var/log/.
It archives all previous days indefinitely as syslog.1 then syslog.2 etc.
You can easily examine these files and see the reboot  at  
example:
cat /var/log/syslog

You may have to uncompress older files.

If the BBB did not reboot in that one day period, all that there will be in 
the "syslog" is the time stamps from  systemd-timesyncd and a few DHCP 
activities.
If it rebooted, there will be several hundred lines of booting "spew" for 
each reboot.

If you are looking for a visual indication,
I run the following script to turn off the four blue user LEDs.
If they come back on autonomously, then the unit has rebooted.



#!/bin/sh
#
# killleds.sh  --  kill all user LEDs

echo none > /sys/class/leds/beaglebone\:green\:usr0/trigger
echo none > /sys/class/leds/beaglebone\:green\:usr1/trigger
echo none > /sys/class/leds/beaglebone\:green\:usr2/trigger
echo none > /sys/class/leds/beaglebone\:green\:usr3/trigger

echo 0 > /sys/class/leds/beaglebone\:green\:usr0/brightness
echo 0 > /sys/class/leds/beaglebone\:green\:usr1/brightness
echo 0 > /sys/class/leds/beaglebone\:green\:usr2/brightness
echo 0 > /sys/class/leds/beaglebone\:green\:usr3/brightness





On Sunday, August 9, 2015 at 11:38:15 AM UTC-5, Bruce Boyes wrote:
>
> Interesting thread, just back in town after a week on a river in central 
> Idaho where there is no connectivity (and I like it that way, though 
> HughesNet is available, but was actually down for several days last week). 
>  I'm running Ubuntu 14.04. I had been arriving at a similar point after 
> having several 3.18 (I think, it was months ago) BBB Rev C and A5A systems 
> running htop for 90+ days. I too have noticed the dependency on the power 
> jack. One other possible detail about that: the Adafruit "5V" supplies seem 
> to never be actually 5V, they are always higher, and deliberately so. I 
> have several and they are typically 5.2, 5.3, or higher, and I have 
> wondered if this is an issue. This variance exceeds +5% on many supplies. 
> If I run off of the USB mini B power input from a monitor hub (I have a 
> number of older HP 1600x1200 ISP monitors with USB hubs built in) they are 
> right at 5V exactly and don't have the reboot issue. Recently I have been 
> buying 5V 1-2A switching wall warts from Digikey, name brands such as 
> Triad, in hopes that they are actually 5V.
>
> All my systems just have power, Ethernet, USB keyboard/mouse via RF 
> dongle, hdmi video, and are running Apache and htop. I have some FTDI USB 
> 3v3 serial adapters on the boot monitor port.
>
> I'm a Linux newbie but a hardware EE. I have a DSO, SPI and I2C analyzers, 
> etc, and some other tools at hand which I'd be happy to apply if helpful, 
> and have a handful of mostly Rev C BBB purchased from Allied and Newark.
>
> What is the best way to determine  when reboots occur? Is there a log file 
> I can check? I'm meaning to write some simple test code which will time 
> stamp a file. Linux newbie like I said.
>
> Happy to test other distros. Ubuntu or Debian, perhaps I don't really 
> care. I started with Ubuntu since I run that on desktops and notebooks.
>
> Bruce
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] BeagleBone Black Relay Module

[Manuel David Garcia Cardenas]

Hello!
This is the first time I write here. I'm from Spain, so firstly sorry for 
my bad english :D

We are connecting a BBB with a 5v 8-relay module, with the pins 
66,67,68,69,45,44,23,26, and pin p9_01 for gnd and P9_05 for 5V

We have two problems. When the system start, the relay #1 goes on, and 3 
minutes later, the relay #1 goes off.
The second problem comes when we halt the system. When we do this action, 
all the relays goes on.

We don't know what's happening. We are trying all we know to solve this.

Please, help us. 

Best Regards

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

Re: [beagleboard] Re: BBB intermittently rebooting.

[Maxim Podbereznyy]

William, or short Vusb to 5V, the result is the same - total stability. You
can do it if you need to enable the USB-Host function at USB0

2015-08-08 23:22 GMT+03:00 William Hermans :

> So far shorting Vusb to ground seems to be doing the trick. We'll give it
> a couple days to be "sure". Prior to shorting Vusb to ground, this linux
> image would reboot several times a day ( 4-5 )
>
> william@xanbustester:~$ uptime
>>  13:20:26 up 15:28,  3 users,  load average: 0.01, 0.02, 0.05
>> william@xanbustester:~$ uname -r
>> 4.2.0-rc4-bone2
>>
>
>
>
> On Fri, Aug 7, 2015 at 5:31 PM, William Hermans  wrote:
>
>> Starting new post . . .
>>
>> On Fri, Aug 7, 2015 at 5:19 PM, William Hermans 
>> wrote:
>>
>>> Ok, I'm stuck in a boot loop, what you see above is what I keep getting.
>>> Let me explore some.
>>>
>>> On Fri, Aug 7, 2015 at 5:17 PM, Robert Nelson 
>>> wrote:
>>>
 On Fri, Aug 7, 2015 at 7:13 PM, William Hermans 
 wrote:
 > These TI kernels support nfsroot ?

 They should. ;)

 bone kernel: bone patchset + mainline
 ti kernel: bone patchset + ti patchset + mainline..

 Regards,

 --
 Robert Nelson
 https://rcn-ee.com/

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



-- 
LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
Company - http://www.linkedin.com/company/mentorel
Facebook - https://www.facebook.com/mentorel.company

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Image 2015-7-26, kernel 4.1.3-ti-r6

[Nuno Gonçalves]

3 weeks ago I asked for it "For what is worth I believe the OMAP and
PMIC reset reason registers should be part of the boot log so future
reboot problems can be sorted.".

But I just asked, I didn't actually code!

Not sure if it is easy to retrieve both, or if PMIC is that much
relevant for this issues.

Anyway, this will surely take out black magic from the equation when
debugging this problems.

Nuno

On Mon, Aug 10, 2015 at 5:12 PM, Robert Nelson  wrote:
> On Mon, Aug 10, 2015 at 11:09 AM, Nuno Gonçalves  wrote:
>> On Mon, Aug 10, 2015 at 5:04 PM, Robert Nelson  
>> wrote:
>>> PS, i'm working on adding a PRM_RSTST check to u-boot so i can catch
>>> the reboot reason..
>>
>> That's really great Robert. Thanks!
>
> Felipe actually pointed me to it. ;)
>
> It'll give us something:
>
> Table 8-197. PRM_RSTST Register Field Descriptions
> Bit Field Type Reset Description
> 31-10 RESERVED Rreturns0s 0h
> 9 ICEPICK_RST R/W1toClr 0h IcePick reset event.
> This is a source of global warm reset initiated by the emulation.
> [warm reset insensitive]
> 0h = 0x0 : No ICEPICK reset.
> 1h = 0x1 : IcePick reset has occurred.
> 8-6 RESERVED Rreturns0s 0h
> 5 EXTERNAL_WARM_RST R/W1toClr 0h External warm reset event [warm reset
> insensitive]
> 0h = 0x0 : No global warm reset.
> 1h = 0x1 : Global external warm reset has occurred.
> 4 WDT1_RST R/W1toClr 0h Watchdog1 timer reset event.
> This is a source of global WARM reset.
> [warm reset insensitive]
> 0h = 0x0 : No watchdog reset.
> 1h = 0x1 : watchdog reset has occurred.
> 3 RESERVED R/W1toClr 0h Reserved.
> 2 RESERVED R/W1toClr 0h Reserved.
> 1 GLOBAL_WARM_SW_RS R/W1toClr 0h Global warm software reset event
> [warm reset insensitive]
> T
> 0h = 0x0 : No global warm SW reset
> 1h = 0x1 : Global warm SW reset has occurred.
> 0 GLOBAL_COLD_RST R/W1toClr 1h Power-on (cold) reset event [warm reset
> insensitive]
> 0h = 0x0 : No power-on reset.
> 1h = 0x1 : Power-on reset has occurred.
> 1338 Power, Reset, and Clock Management (PRCM)
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/

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

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Robert Nelson]

On Mon, Aug 10, 2015 at 11:09 AM, Nuno Gonçalves  wrote:
> On Mon, Aug 10, 2015 at 5:04 PM, Robert Nelson  
> wrote:
>> PS, i'm working on adding a PRM_RSTST check to u-boot so i can catch
>> the reboot reason..
>
> That's really great Robert. Thanks!

Felipe actually pointed me to it. ;)

It'll give us something:

Table 8-197. PRM_RSTST Register Field Descriptions
Bit Field Type Reset Description
31-10 RESERVED Rreturns0s 0h
9 ICEPICK_RST R/W1toClr 0h IcePick reset event.
This is a source of global warm reset initiated by the emulation.
[warm reset insensitive]
0h = 0x0 : No ICEPICK reset.
1h = 0x1 : IcePick reset has occurred.
8-6 RESERVED Rreturns0s 0h
5 EXTERNAL_WARM_RST R/W1toClr 0h External warm reset event [warm reset
insensitive]
0h = 0x0 : No global warm reset.
1h = 0x1 : Global external warm reset has occurred.
4 WDT1_RST R/W1toClr 0h Watchdog1 timer reset event.
This is a source of global WARM reset.
[warm reset insensitive]
0h = 0x0 : No watchdog reset.
1h = 0x1 : watchdog reset has occurred.
3 RESERVED R/W1toClr 0h Reserved.
2 RESERVED R/W1toClr 0h Reserved.
1 GLOBAL_WARM_SW_RS R/W1toClr 0h Global warm software reset event
[warm reset insensitive]
T
0h = 0x0 : No global warm SW reset
1h = 0x1 : Global warm SW reset has occurred.
0 GLOBAL_COLD_RST R/W1toClr 1h Power-on (cold) reset event [warm reset
insensitive]
0h = 0x0 : No power-on reset.
1h = 0x1 : Power-on reset has occurred.
1338 Power, Reset, and Clock Management (PRCM)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Nuno Gonçalves]

On Mon, Aug 10, 2015 at 5:04 PM, Robert Nelson  wrote:
> PS, i'm working on adding a PRM_RSTST check to u-boot so i can catch
> the reboot reason..

That's really great Robert. Thanks!

Nuno

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Image 2015-7-26, kernel 4.1.3-ti-r6

[Robert Nelson]

On Mon, Aug 10, 2015 at 10:57 AM, Felipe Balbi  wrote:
> On Sun, Aug 09, 2015 at 05:59:09PM -0500, Robert Nelson wrote:
>> Update:
>>
>> Last friday i built v4.1-rc1 and 4.1.4-ti-r8 with the commit Nuno
>> found and reverted it..
>>
>> [test-bbb-1: 4.1.4-ti-r8.1 (up 2 days, 10 hours, 3 minutes)]
>> [test-bbb-2: 4.1.4-ti-r8.1 (up 2 days, 9 hours, 58 minutes)]
>> [test-bbb-5: 4.1.0-rc1-x0-2-gf38e145-dirty (up 2 days, 10 hours,
>> 45 minutes)]
>> [test-bbb-6: 4.1.0-rc1-x0-2-gf38e145-dirty (up 2 days, 10 hours,
>> 40 minutes)]
>
> what does this mean ? vanilla v4.1-rc1 + 2 MUSB commits still hasn't
> crashed ?

It's rc1 +

the musb revert: ad78c918602cb7cce0fab5d5813213853a6f351d

+ deb-pkg resync: (so the *.dtb are part of my  linux-image*.deb build)
https://github.com/RobertCNelson/bisector/blob/master/3rdparty/packaging/builddeb

+ phy search fix: (beaglebone/beaglebone black's phy doesn't come up
100% of the time on mdio[0]...)
https://github.com/RobertCNelson/bisector/blob/master/patches/beaglebone/phy/0003-cpsw-search-for-phy.patch

cron job runs every 5 minutes with uptime info sent over nfs..

http://rcn-ee.homeip.net:81/farm/uptime/

[test-bbb-1: 4.1.4-ti-r8.1 (up 3 days, 3 hours, 8 minutes)]
[test-bbb-2: 4.1.4-ti-r8.1 (up 3 days, 3 hours, 3 minutes)]
[test-bbb-5: 4.1.0-rc1-x0-2-gf38e145-dirty (up 3 days, 3 hours, 50 minutes)]
[test-bbb-6: 4.1.0-rc1-x0-2-gf38e145-dirty (up 3 days, 3 hours, 45 minutes)]

PS, i'm working on adding a PRM_RSTST check to u-boot so i can catch
the reboot reason..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6

[Felipe Balbi]

On Sun, Aug 09, 2015 at 05:59:09PM -0500, Robert Nelson wrote:
> Update:
> 
> Last friday i built v4.1-rc1 and 4.1.4-ti-r8 with the commit Nuno
> found and reverted it..
> 
> [test-bbb-1: 4.1.4-ti-r8.1 (up 2 days, 10 hours, 3 minutes)]
> [test-bbb-2: 4.1.4-ti-r8.1 (up 2 days, 9 hours, 58 minutes)]
> [test-bbb-5: 4.1.0-rc1-x0-2-gf38e145-dirty (up 2 days, 10 hours,
> 45 minutes)]
> [test-bbb-6: 4.1.0-rc1-x0-2-gf38e145-dirty (up 2 days, 10 hours,
> 40 minutes)]

what does this mean ? vanilla v4.1-rc1 + 2 MUSB commits still hasn't
crashed ?

-- 
balbi

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


signature.asc
Description: Digital signature

Re: [beagleboard] 4.1 repo

[Shadi Abdu-Rahman]

 

>
> But i think audio (output) was still not working.. 
>
> Now that the reset bug has a workaround, i'll try and look at audio 
> again today.. 
>
>
Ok. I'll wait for your reply then. 

Thanks for taking the time. Much appreciated.

Best,
Shadi 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Difference between TI and bone kernels.

[William Hermans]

>
> *It was config_mii=m yeah we need that =y for nfs root, as the phy*
> * won't load..  kernel fix pushed out...*
>
> * Regards,*


Yeah figured it was something like that. Was a bit upset at the time . . .
Had just spent all day messing with that, among many other things related -
When All I wanted to do was write code . . . So, just took the easiest
shortest route to getting the kernel stable - shorting Vusb to USB ground.

Had to power down the board yesterday( switched to generator from solar ),
otherwise I'd be pushing a 2 day uptime.

Thank you for the fix :)



On Mon, Aug 10, 2015 at 7:59 AM, Robert Nelson 
wrote:

> On Fri, Aug 7, 2015 at 8:55 PM, William Hermans  wrote:
> > Anyhow, this is the kernel's fault. Somehow it's different, and to be
> honest
> > I do not have the time or energy to mess with it.
>
>
> It was config_mii=m yeah we need that =y for nfs root, as the phy
> won't load..  kernel fix pushed out...
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> 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] Difference between TI and bone kernels.

[Robert Nelson]

On Fri, Aug 7, 2015 at 8:55 PM, William Hermans  wrote:
> Anyhow, this is the kernel's fault. Somehow it's different, and to be honest
> I do not have the time or energy to mess with it.


It was config_mii=m yeah we need that =y for nfs root, as the phy
won't load..  kernel fix pushed out...

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

[beagleboard] [Beaglebone Black, ADC, C++, Eclipse, crosscompiling]First steps: is this doable?

[Valeria M.]

Hi everybody!

I have a Beaglebone Black running the last Debian image and for my current 
project I need to cross-compile it with Eclipse from my WIndows OS.

I'm fairly new both to microcontrollers and C++ (programming in general if 
I am to be honest) and right now I'm still trying to understand if my 
assignment is doable!
Here it goes:
I need to sample with the built-in ADC of the BBB an analog input,  count 
the samples and find a way to 'force' the ADC-clock rollover to synchronize 
with an external clock

Do you think this is feasible? I haven't find, strangely enough, anything 
online about the last two, I'm googling the wrong way?

Regards,
Valeria

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] 4.1 repo

[Robert Nelson]

On Mon, Aug 10, 2015 at 9:05 AM, Shadi Abdu-Rahman  wrote:
>
>>
>> there are some issues with the audio rev b, but i can't find that
>> board for sale anywhere anymore. (i have the rev a)
>>
>
> Hi Robert,
>
> Could you elaborate on the issues you're seeing with the Audio Cape? I'm
> having trouble using the audio system as described here, and I'm wondering
> if it's the same Transmit Buffer Underflow problems you're seeing.

Most of the issues are now fixed:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts

https://github.com/beagleboard/bb.org-overlays/commits/master/src/arm/BB-BONE-AUDI-02-00A0.dts

But i think audio (output) was still not working..

Now that the reset bug has a workaround, i'll try and look at audio
again today..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] 4.1 repo

[Shadi Abdu-Rahman]

>
> there are some issues with the audio rev b, but i can't find that 
> board for sale anywhere anymore. (i have the rev a) 
>  
>

Hi Robert,

Could you elaborate on the issues you're seeing with the Audio Cape? I'm 
having trouble using the audio system as described here 
,
 
and I'm wondering if it's the same Transmit Buffer Underflow problems 
you're seeing.

Kind Regards,
Shadi 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Porting Ubuntu in beagleboard xm rev C using raw sd card

[Robert Nelson]

On Mon, Aug 10, 2015 at 12:49 AM,   wrote:
> Hello Sir,
>
>
>
> I need to port Ubuntu OS in beagle board xm rev C using raw sd card,Can
> anyone help me with this

http://elinux.org/BeagleBoardUbuntu#BeagleBoard_xM

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] samba installation error in BeagleBone Black having Debian whizzy os

[Robert Nelson]

On Mon, Aug 10, 2015 at 4:13 AM,   wrote:
> insserv: Starting led_aging.sh depends on rmnologin and therefore on system
> fac!

Reflash:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-07-28

embest screwed up their default image..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Re: BBB DPLL boot problem

[Fabio Mantelli]

Nothing is plugged in, and no program is running at all for my tests.

2015-08-07 23:40 GMT-03:00 evilwulfie :

> i can see that if your running full tilt MHZ with ethernet plugged in
> it runs a bit below 500ma normally
>
> whats running and whats the cpu load ?
>
>
> On 8/7/2015 11:24 AM, fabiohmante...@gmail.com wrote:
>
> Well, by no apparent reason at all, by the third day my BBB rose from the
> dead and started booting again. No strange boot messages, like as if
> nothing happened. However, 600mA current is being pulled by the BBB from
> the power source with nothing connected to it, which I find strange. Any
> ideas?
>
> On Wednesday, August 5, 2015 at 7:13:20 PM UTC-3, fabiohm...@gmail.com
> wrote:
>>
>> Hey guys, new user here. I got an issue with my BBB and I thought maybe
>> somebody here could help me.
>>
>> After fiddling around with my bbb debugging a custom made cape, it
>> stopped booting at all. When I plug in a serial debug cable to read the
>> boot messages i get the following:
>>
>> U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
>> DPLL locking failed for 0x44e00490
>> ### ERROR ### Please RESET the board ###
>>
>> When I reset it, I get the message again.
>>
>> I tried to google the error message and had no success finding a solution
>> or any other issue similar to that.
>>
>> Does anybody have any idea on what might have caused that error? Any idea
>> on what could be done to fix it? Is there hope for my BBB?
>>
>> Thank You.
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> 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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/CJtqehUj1zw/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: shutdown procedure required for beaglebone black ??

[lmjeung0]

Hi Gerald,

So to unmount the drives and power down the BBB, I can either push the 
power button momentarily or use the Linux shutdown command?

Lawrence

On Wednesday, August 5, 2015 at 5:39:06 AM UTC-7, Gerald wrote:
>
> By doing this you can get corruption. Linux requires that you unmount the 
> drives before powering down.
>
> There is also a Linux shutdown command that can be used.
>
> Gerald
>
>
> On Wed, Aug 5, 2015 at 4:07 AM, > wrote:
>
>> Hi Gerald,
>>
>> Following the instructions on the BeagleBoard.org - getting-started 
>>  webpage, my team lead and I 
>> have been powering up the BBB by using the provided USB cable to plug our 
>> Beagle into our computers.  We didn't find instructions on powering it 
>> down.  So, we have been powering it down by simply pulling the cable out.  
>> By doing this, can we also get corruption?  If so, where is the shutdown 
>> procedure documented?
>>
>> Lawrence
>>
>> On Sunday, October 13, 2013 at 12:19:54 PM UTC-7, Gerald wrote:
>>>
>>> Nope. If you do it the way I just said, the board is powered off after 
>>> it is done. Then you can pull the power. 
>>>
>>> Pull the power without letting the kernel unmount the eMMC or SD card, 
>>> and you can get corruption.
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Sun, Oct 13, 2013 at 1:31 PM,  wrote:
>>>
 So pulling out the power with properly shutting down the system could 
 corrupt the eMMC ???


 On Sunday, October 13, 2013 4:39:05 PM UTC+5:30, arunbarn...@gmail.com 
 wrote:
>
> Hi,
>
> I am trying to use the beaglebone black (in factory default settings) 
> in a control application, where the BBB interfaces to a 20x4 character 
> LCD, 
> 18 button keypad, and a RS 232 connection using ttyO4 port (connects to 
> RS 
> 485 network using appropriate drivers).
>
> I have almost developed the hardware and the software using Eclispe 
> C++ IDE. 
>
> As I am not using any batteries or other power backup devices for the 
> BBB, Do I have to implement a shutdown procedure for my users ?? 
>
> I have made a procedure in which the user presses a combination of 
> keys to get the shutdown option on the LCD, selecting the shutdown option 
> runs the system("shutdown -h now") command in my C++ program.
>
> Is a shutdown procedure required for the BBB or will just pulling out 
> the +5V power jack be sufficient. 
>
> I have read in some sites that the eMMC could get corrupted causing 
> startup issues
>
> Please advise
>
> thanks
> a
>
> -- 
 For more options, visit http://beagleboard.org/discuss
 --- 
 You received this message because you 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/groups/opt_out.

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

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Shift register PRU

[christianvinaigre]

Hi folks,

i'm currently working with the PRU of the beagle bone black to read and 
decode a SSI Protocol.
Therefore I want to use the build in 28 bit shift register of the PRU. I 
found out, that the shift register is configured via the GPCFG0 (pru0) 
register.
Can anyone explain to me, how I can use the shift register? 
I also haven't found the basic-adress of register GPCFG0, just the offset 
with 0x08.

With best regards
Christian

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Porting Ubuntu in beagleboard xm rev C using raw sd card

[r . harsha6]

Hello Sir,



I need to port Ubuntu OS in beagle board xm rev C using raw sd card,Can 
anyone help me with this




Thanks & Regards
Harsha R

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: Help with Device Tree - possible bug in am33xx.dtsi

[Emrah]

I know that this post is quite old and I hope you got it fixed. I use 
kernel 3.12.10 and I can make the can device up without any problem. 
However I can't get any can mesaages from another board which I am %100 
sure that it is working properly. I use candump utility to check received 
packets. I am suspicious about the changes I made in am335x-boneblack.dts 
file. Here are the lines I added in the file.

dcan0_pins: dcan0_pins {
pinctrl-single,pins = <
0x178 0x12/*(SLEWCTRL_FAST | PIN_INPUT_PULLUP | MUX_MODE2)
0x17C 0x32/*(SLEWCTRL_FAST | PIN_INPUT_PULLUP | MUX_MODE2)
>;
};

&dcan0 {  
 #address-cells = <1>;
#size-cells = <0>;   
 pinctrl-names = "default";
 pinctrl-0 = <&dcan0_pins>;
 status = "okay";
}; 

This is the node in am33xx.dtsi file,

dcan0: d_can@481cc000 {
compatible = "bosch,d_can";
ti,hwmods = "d_can0";
clocks = <&dcan0_fck>;
clock-names = "fck";
reg = <0x481cc000 0x2000
0x44e10644 0x4>;
interrupts = <52>;
status = "disabled";
};

Can you share your changes in am335x-boneblack.dts file?

15 Kasım 2013 Cuma 02:45:06 UTC+2 tarihinde AndrewTaneGlen yazdı:
>
> Using the new 3.12 mainline kernel and Robert C Nelson's Ubuntu rootfs 
> I've managed to get both CAN devices working. However, it get a warning 
> when the device boots:
>
> c_can_platform 481d.d_can: can't request region for resource [mem 
> 0x44e10644-0x44e10647]
>
> What this is referring to is the fact that in the device tree definitions 
> for each of the two can devices, the same register address is being 
> requested. They are defined in 'am33xx.dtsi 
> '
>  
> as follows:
>
> dcan0: d_can@481cc000 {
> compatible = "bosch,d_can";
> ti,hwmods = "d_can0";
> reg = <0x481cc000 0x2000
> 0x44e10644 0x4>;
> interrupts = <52>;
> status = "disabled";
> };
>
> dcan1: d_can@481d {
> compatible = "bosch,d_can";
> ti,hwmods = "d_can1";
> reg = <0x481d 0x2000
> 0x44e10644 0x4>;
> interrupts = <55>;
> status = "disabled";
> };
>
> For both items the address '0x44e10644 0x4', referring to the register 
> 'dcan_raminit' 
> (Pg 793 of spruh73h.pdf ), 
> is being reserved for use. The new devicetree interpreter considers any 
> overlap between device register memory mappings as a problem, hence the 
> message seen on boot.
>
> The register 'dcan_raminit' is in fact used by both can devices, so it 
> does make sense for both to have access to it. It appears however, that 
> this register is only used in the d_can driver which does not appear to be 
> in use with this latest kernel release. In any case, both device work 
> flawlessly (as far as I can tell) regardless of the error message.
>
> I thought I'd have a go at tidying this part of the 'am33xx.dtsi 
> '
>  
> devicetree file up a bit to get rid of this message - and this is where my 
> question comes in. I thought I could make a single parent node for d_can 
> with this shared register defined at the top level, and then add the two 
> can devices to it as child nodes. I came up with something like this:
>
> dcan {
> #address-cells = <1>;
> #size-cells = <1>;
> reg = <0x44e10644 0x4>;
>
> dcan0: d_can@481cc000 {
> compatible = "bosch,d_can";
> ti,hwmods = "d_can0";
> reg = <0x481cc000 0x2000>;
> interrupts = <52>;
> status = "disabled";
> };
>
> dcan1: d_can@481d {
> compatible = "bosch,d_can";
> ti,hwmods = "d_can1";
> reg = <0x481d 0x2000>;
> interrupts = <55>;
> status = "disabled";
> };
> };
>
> I tried various iterations along this line (and modified the 
> am335x-boneblack.dts 
> 
>  file 
> with the corresponding 'status = 'okay' entries for these devices), all 
> of which would compile fine, and the dvice would boot with no error 
> messages, but for whatever reason the devices would never show up as they 
> had previously.
>
> I was wonder if anyone with a better understanding of devicetree syntax 
> could suggest the correct structure for the parent/child nodes I am trying 
> to create.
>
> Any help or suggestions would be greatly appreciated.
>
>
> Regards,
> Andrew Glen.
>

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

Re: [beagleboard] Re: shutdown procedure required for beaglebone black ??

[lmjeung0]

Hi Chad,

Thank you for pointing us to that section.  We missed seeing the 
recommendation, because it was somewhat implied.  We were searching for an 
instruction like "To power down the board, do ..."

Lawrence

On Wednesday, August 5, 2015 at 6:34:45 AM UTC-7, cmbaker3 wrote:
>
> Section 5.10 in the SRM Rev C.1 recommends using the power button to power 
> down the board and prevent contamination of the SD card or the eMMC. This 
> section gives a brief explanation of why also.
> Chad
>
> On 8/5/2015 4:07 AM, lmje...@gmail.com  wrote:
>
> Hi Gerald,
>
> Following the instructions on the BeagleBoard.org - getting-started 
>  webpage, my team lead and I have 
> been powering up the BBB by using the provided USB cable to plug our Beagle 
> into our computers.  We didn't find instructions on powering it down.  So, 
> we have been powering it down by simply pulling the cable out.  By doing 
> this, can we also get corruption?  If so, where is the shutdown procedure 
> documented?
>
> Lawrence
>
> On Sunday, October 13, 2013 at 12:19:54 PM UTC-7, Gerald wrote: 
>>
>> Nope. If you do it the way I just said, the board is powered off after it 
>> is done. Then you can pull the power.  
>>
>> Pull the power without letting the kernel unmount the eMMC or SD card, 
>> and you can get corruption. 
>>
>> Gerald
>>
>>
>>
>> On Sun, Oct 13, 2013 at 1:31 PM,  wrote:
>>
>>> So pulling out the power with properly shutting down the system could 
>>> corrupt the eMMC ??? 
>>>
>>>
>>> On Sunday, October 13, 2013 4:39:05 PM UTC+5:30, arunbarn...@gmail.com 
>>> wrote: 

 Hi,

 I am trying to use the beaglebone black (in factory default settings) 
 in a control application, where the BBB interfaces to a 20x4 character 
 LCD, 
 18 button keypad, and a RS 232 connection using ttyO4 port (connects to RS 
 485 network using appropriate drivers).

 I have almost developed the hardware and the software using Eclispe C++ 
 IDE. 

 As I am not using any batteries or other power backup devices for the 
 BBB, Do I have to implement a shutdown procedure for my users ?? 

 I have made a procedure in which the user presses a combination of keys 
 to get the shutdown option on the LCD, selecting the shutdown option runs 
 the system("shutdown -h now") command in my C++ program.

 Is a shutdown procedure required for the BBB or will just pulling out 
 the +5V power jack be sufficient. 

 I have read in some sites that the eMMC could get corrupted causing 
 startup issues

 Please advise

 thanks
 a

 -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you 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/groups/opt_out.
>>>
>>
>> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you 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.
>
>
>
> -- 
> Chad Baker Memphis, TN
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: shutdown procedure required for beaglebone black ??

[lmjeung0]

Hi Gerald,

Do you mean that the power button function may not necessary work?  Is the 
SW that supports it SW that I will need to develop, like the C++ SW that 
arunbarn...@gmail.com was developing?

Lawrence

On Wednesday, August 5, 2015 at 9:07:57 AM UTC-7, Gerald wrote:
>
> Assuming that the SW supports the power button function.
>
> Gerald
>
>
> On Wed, Aug 5, 2015 at 8:34 AM, Chad Baker  > wrote:
>
>> Section 5.10 in the SRM Rev C.1 recommends using the power button to 
>> power down the board and prevent contamination of the SD card or the eMMC. 
>> This section gives a brief explanation of why also.
>> Chad
>>
>>
>> On 8/5/2015 4:07 AM, lmje...@gmail.com  wrote:
>>
>> Hi Gerald,
>>
>> Following the instructions on the BeagleBoard.org - getting-started 
>>  webpage, my team lead and I 
>> have been powering up the BBB by using the provided USB cable to plug our 
>> Beagle into our computers.  We didn't find instructions on powering it 
>> down.  So, we have been powering it down by simply pulling the cable out.  
>> By doing this, can we also get corruption?  If so, where is the shutdown 
>> procedure documented?
>>
>> Lawrence
>>
>> On Sunday, October 13, 2013 at 12:19:54 PM UTC-7, Gerald wrote: 
>>>
>>> Nope. If you do it the way I just said, the board is powered off after 
>>> it is done. Then you can pull the power.  
>>>
>>> Pull the power without letting the kernel unmount the eMMC or SD card, 
>>> and you can get corruption. 
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Sun, Oct 13, 2013 at 1:31 PM,  wrote:
>>>
 So pulling out the power with properly shutting down the system could 
 corrupt the eMMC ??? 


 On Sunday, October 13, 2013 4:39:05 PM UTC+5:30, arunbarn...@gmail.com 
 wrote: 
>
> Hi,
>
> I am trying to use the beaglebone black (in factory default settings) 
> in a control application, where the BBB interfaces to a 20x4 character 
> LCD, 
> 18 button keypad, and a RS 232 connection using ttyO4 port (connects to 
> RS 
> 485 network using appropriate drivers).
>
> I have almost developed the hardware and the software using Eclispe 
> C++ IDE. 
>
> As I am not using any batteries or other power backup devices for the 
> BBB, Do I have to implement a shutdown procedure for my users ?? 
>
> I have made a procedure in which the user presses a combination of 
> keys to get the shutdown option on the LCD, selecting the shutdown option 
> runs the system("shutdown -h now") command in my C++ program.
>
> Is a shutdown procedure required for the BBB or will just pulling out 
> the +5V power jack be sufficient. 
>
> I have read in some sites that the eMMC could get corrupted causing 
> startup issues
>
> Please advise
>
> thanks
> a
>
> -- 
 For more options, visit http://beagleboard.org/discuss
 --- 
 You received this message because you 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/groups/opt_out.

>>>
>>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you 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.
>>
>>
>>
>> -- 
>> Chad Baker Memphis, TN
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you 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.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] webpage no longer loading

[nordic . savoie]

Using Beaglebone Black Rev C 

Not sure if I accidentally deleted a file or broke during a recent update 
or perhaps when I installed wifi antenna.  

When I point my browser to 192.168.7.2  , the page does not load I get 

Cannot GET /

Similar error when I navigate to the IP address as well.


Cloud9 loads fine both at 192.168.7.2:3000 and 192.168.1.59:3000

If I navigate to:  http://beagleboard.org/support/bone101/
the page does interact with the page and I can run bonescript

*Your board is connected!*
BeagleBone Black rev 00C0 S/N BBBK running BoneScript 0.2.4 at 
192.168.7.2

It's like it lost some redirect.  

My goal is to drop an html file into the Cloud9 folder so that I can serve 
my own webpage on startup after navigating to 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] BBB with serial communication at baud 230400

[zbeckerman41]

I am using a BBB to connect to some third party hardware. The hardware 
serial communication at baud 230400 (8/N/1 - bits/par/stop).

I didn't use the J1 port since it only maps Tx/Rx/Gnd by default. 

I need Tx/Rx/Gnd/DTR/RTS/CTS.

To try and accommodate this, I purchase a cape (USB-2COM-BB) from 
www.titan.tw. While the cape works, I am not sure it can properly 
communicate at the baud I need, or maybe, it isn't passing the rts/cts 
properly or I need a debian patch?

With all the wires connected, my SALEAE logic tells me the TX back to 3rd 
party hardware is 9624 (makes no sense). My software properly sets the baud 
rate.

I am thinking the cape is not working properly. Can someone explain how I 
can utilize the native serial port on the BBB to accomplish this (key part 
the need for RTS/DTR/CTS).

I am using the default debian from the BBB and I have the latest C rev.

Thanks in advance!
Zev.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Beagleboard-xM Camera LI-5M03 (MT9P031) Support With Device Tree Tested

[raj]

Hello,

I've verified beagleboard-xM camera LI-5M03 (mt9p031) with device tree
on Linux 4.2.0-rc5 with the help of Laurent and Sakari.

If anybody interested, please go through link for more details

https://alaganraj.wordpress.com/2015/08/08/beagleboard-xm-camera-li-5m03-mt9p031-support-with-device-tree/

Thanks & Regards,
Alaganraj

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Beagleboard-xM Camera LI-5M03 (MT9P031) Support With Device Tree Tested

[raj]

Hello,

I've verified beagleboard-xM camera LI-5M03 (mt9p031) with device tree on 
Linux 4.2.0-rc5.

If anybody interested, please go through link for more details

https://alaganraj.wordpress.com/2015/08/08/beagleboard-xm-camera-li-5m03-mt9p031-support-with-device-tree/

Thanks & Regards,
Alaganraj

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] compiler for BBB wheezy ( glibc 2.13 version problem )

[Robert Nelson]

On Mon, Aug 10, 2015 at 7:32 AM, Robert Nelson  wrote:
> On Mon, Aug 10, 2015 at 2:01 AM, 박연호  wrote:
>> I had used the Jessie image, but it has problems.
>>
>> First, USB Network 192.168.7.2 doesn't work constantly,
>> For example, after reboot or reconnect bbb, it doesn't wort at all.
>
> Why didn't you report this?  I had another user report it on saturday,
> i'm taking a look at in a litle bit this morning..

Now enabled:
https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/cf4d4833bc58da03be28441b023e2771723df505

my config-checker missed that block..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] compiler for BBB wheezy ( glibc 2.13 version problem )

[Robert Nelson]

On Mon, Aug 10, 2015 at 2:01 AM, 박연호  wrote:
> I had used the Jessie image, but it has problems.
>
> First, USB Network 192.168.7.2 doesn't work constantly,
> For example, after reboot or reconnect bbb, it doesn't wort at all.

Why didn't you report this?  I had another user report it on saturday,
i'm taking a look at in a litle bit this morning..

> Second, finding networking takes too much time.
>
> Thirds, somehow wheezy's HDMI has better comparability.

sudo apt-get update
sudo apt-get install linux-image-3.8.13-bone73
sudo reboot


> Generally, Wheezy seems far more stable than Jessie.
>
> I gave up Jessie for those reasons.
>
> Please, Is there any compiler for armhf glibc 2.13?

Nope, build on target..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] compiler for BBB wheezy ( glibc 2.13 version problem )

[박연호]

I had used the Jessie image, but it has problems.

First, USB Network 192.168.7.2 doesn't work constantly, 
For example, after reboot or reconnect bbb, it doesn't wort at all.

Second, finding networking takes too much time.

Thirds, somehow wheezy's HDMI has better comparability.



Generally, Wheezy seems far more stable than Jessie.

I gave up Jessie for those reasons.

Please, Is there any compiler for armhf glibc 2.13?



2015년 8월 10일 월요일 오후 12시 13분 44초 UTC+9, RobertCNelson 님의 말:
>
> On Sun, Aug 9, 2015 at 8:16 PM, 박연호 > 
> wrote: 
> > compiler for BBB wheezy ( glibc 2.13 armhf ) 
> > 
> > I'm using BBB wheezy ( 
> > 
> https://rcn-ee.com/rootfs/bb.org/release/2015-07-28/console/BBB-eMMC-flasher-debian-7.8-console-armhf-2015-07-28-2gb.img.xz
>  
> > ) 
> > 
> > but, the problem is BBB wheezy has low glibc version 2.13 which is not 
> work 
> > out with recent cross compilers. 
> > 
> > 
> > please help me, out. 
> > 
> > I think you recommend a cross compiler work with glibc 2.13 in ubuntu 12 
> or 
> > 14 ( 64 or 32 bit ). 
> > 
> > or, is there any good way to solve this? 
>
> Yeap.. 
>
> Use the jessie image: 
>
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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