Re: [beagleboard] Re: 3.17.1-rc4 sudden reset

2014-11-15 Thread Ives van der Flaas
is rather complicated. All help is welcome. Op zondag 9 november 2014 19:50:46 UTC+1 schreef david turvene: On Saturday, November 8, 2014 10:01:52 AM UTC-5, Ives van der Flaas wrote: However, not enoug of a difference apparently. I just had a sudden reset occur. This is on a 3.18-rc2-bone1

Re: [beagleboard] Re: 3.17.1-rc4 sudden reset

2014-11-08 Thread Ives van der Flaas
of the systems. The uptime is more than 3 days now. If interested, I can post more details. On Tuesday, November 4, 2014 3:01:53 PM UTC+1, Ives van der Flaas wrote: Have you had *any* resets since the upgrade to the new u-boot version? I've also been suspecting u-boot, hence my Meaning that I'm

Re: [beagleboard] Re: 3.17.1-rc4 sudden reset

2014-11-08 Thread Ives van der Flaas
+1 schreef Ives van der Flaas: Setting the usb0 dr_mode to peripheral and disabling OTG in the .config definitely makes a big difference. I have a 3.18-rc2-bone1 currently running for almost 24 hours with this patch, much more than I've ever previously achieved with 3.18 or 3.17. Op

Re: [beagleboard] Re: 3.17.1-rc4 sudden reset

2014-11-07 Thread Ives van der Flaas
@David, did you try it on 3.17 or 3.18? Jens did his patch on 3.17 so there could potentially be a difference there (unlikely that it is). Op donderdag 6 november 2014 23:31:43 UTC+1 schreef david turvene: On Thursday, November 6, 2014 11:10:37 AM UTC-5, Jens Peter Schroer wrote: I have

Re: [beagleboard] Re: 3.17.1-rc4 sudden reset

2014-11-04 Thread Ives van der Flaas
Have you had *any* resets since the upgrade to the new u-boot version? I've also been suspecting u-boot, hence my Meaning that I'm also running an old u-boot. in the last post. Op dinsdag 4 november 2014 00:18:43 UTC+1 schreef david turvene: On Saturday, November 1, 2014 3:24:33 PM UTC-4,

Re: [beagleboard] Re: 3.17.1-rc4 sudden reset

2014-10-31 Thread Ives van der Flaas
I can confirm that the problem still exists on the 3.18-rc2-bone1. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send

Re: [beagleboard] Re: 3.17.1-rc4 sudden reset

2014-10-31 Thread Ives van der Flaas
Op donderdag 30 oktober 2014 18:15:33 UTC+1 schreef William Hermans: So I'm curious. Did all of you follow Roberts DebianOnARM kernel build instructions, or are you all using a prebuilt image ? I'm using a pretty old prebuilt 13.04 image (with lots of libraries and scripts with quite a few

[beagleboard] 3.17.1-rc4 sudden reset

2014-10-30 Thread Ives van der Flaas
I'm running Robert C Nelson's latest 3.17 kernel (3.17.1-bone4) because I need the new TI musb babble recovery code. It seems however that I'm having some strange instability on my BBB. After somewhere between 10 and 24 hours, the device seems to reset suddenly and without warning. There's no

Re: [beagleboard] Re: CAUTION: musb: Babble Interrupt Occurred

2014-06-13 Thread Ives van der Flaas
Do you by any chance know in what revision the babble interrupt problem was fixed? Was it only fixed in 3.12 or also in other trees (e.g. 3.8)? Op dinsdag 13 mei 2014 17:19:42 UTC+2 schreef cody: What version of the 3.12 kernel do you have? The latest version of the 3.12 kernel should have

[beagleboard] Re: Prevent linux from clearing GPIO pins during boot

2013-12-27 Thread Ives van der Flaas
Some more information: I'm running the BeagleBone Black with a 3.8.13-bone33 kernel. Op donderdag 26 december 2013 09:42:12 UTC+1 schreef Ives van der Flaas: I have two GPIO pins that I'd like to be high during the boot process. These pins, GPIO 44 and 23, are connected to LEDs through some

[beagleboard] Prevent linux from clearing GPIO P8_12 and P8_13 on boot

2013-12-26 Thread Ives van der Flaas
Hi everyone, I'm building a product based on the BeagleBone Black that uses LEDs to indicate the current status. These LEDs are connected to P8_12 and P8_13 (GPIO 44 and 23) and need to be turned on during boot. I succeeded in setting the relevant pins to high in uBoot, but as soon as the

[beagleboard] Prevent linux from clearing GPIO pins during boot

2013-12-26 Thread Ives van der Flaas
I have two GPIO pins that I'd like to be high during the boot process. These pins, GPIO 44 and 23, are connected to LEDs through some circuitry. I've managed to set those pins when uBoot runs, but they are reset during the boot process: as soon as the linux kernel starts these pins are pulled