Yeah, that one rebooted…
Dahm, ok . .
Give this one a shot:
http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/linux-image-4.1.4-ti-r8.1_1cross_armhf.deb
boards 1 & 2 listed here:
http://rcn-ee.homeip.net:81/farm/uptime/
Are running that right now… 9 hours +…
It’s based on Nuno’s git bisect log, with just a revert of the one commit…
Ok cool. Yeah, ran into insufficient power with a USB walwart adapter . … can0 was refusing ot come up after a while.
Also, I have another unrelated question. Ever see an install start acting wierd after losing power ? Our battery bank went over temp this morning and inverers shut off leaving the BBB in question in a lurch. Now . . . sudo requires a passwd every use. Was considering using fsck, but it’s a live /home directory NFS share . . . 
These TI kernels support nfsroot ?
U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img
U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
I2C: ready
DRAM: 512 MiB
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
Net: not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
638 bytes read in 5 ms (124 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from uEnv.txt
Importing environment from mmc …
Checking if uenvcmd is set …
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd …
reading vmlinuz-4.1.4-ti-r8.1
8195768 bytes read in 452 ms (17.3 MiB/s)
reading /dtbs/4.1.4-ti-r8.1/am335x-boneblack.dtb
57860 bytes read in 17 ms (3.2 MiB/s)
Kernel image @ 0x80300000 [ 0x000000 - 0x7d0eb8 ]
Flattened Device Tree blob at 815f0000
Booting using the fdt blob at 0x815f0000
Using Device Tree in place at 815f0000, end 81601203
Starting kernel …
They should. 
bone kernel: bone patchset + mainline
ti kernel: bone patchset + ti patchset + mainline..
Regards,
Ok, I’m stuck in a boot loop, what you see above is what I keep getting. Let me explore some.
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, 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
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.
you can power a board by USB but from a special wall adapter with an integrated USB socket. As an option
you can power a board by USB but from a special wall adapter with an integrated USB socket. As an option
Yes, and we tried it. It was not enough power. It is also my understanding that powering the BBB in such a way can not give more than 500ma. It was not enough power. the canbus would not function at all part of the time. As soon as I applied power via barrel jack. Then problem went away.
probably you used a wall adapter with integrated monitoring chip which does not allow to overcurrent 500mA. You should use a dumb version of such device when it simply supplies as much power as it can 
probably you used a wall adapter with integrated monitoring chip which does not allow to overcurrent 500mA. You should use a dumb version of such device when it simply supplies as much power as it can 
Was simply a guess on my behalf. As I recall Gerald saying that the USB will not pull more than 500ma.
I believe the pmic needs to talk with something on the usb bus...
that's why dumb usb chargers don't always work for powering the bbb..
Regards,
I believe the pmic needs to talk with something on the usb bus…
that’s why dumb usb chargers don’t always work for powering the bbb…
Well, that I could not say. This is actually the first time I’ve run into USB power not being enough. I probably could have swapped USB wall adapters, but why ? Pretty sure none of the others we have would have worked either. Barrel jack + Vusb to ground is working fine
While that's a quick hardware hack, I'm having pretty good luck with
the revert..
revert: 4.1.4-ti-r8.1
http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-1.log
reboot happy: 4.1.4-ti-r8
http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-3.log
Regards,
While that’s a quick hardware hack, I’m having pretty good luck with
the revert…
revert: 4.1.4-ti-r8.1
http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-1.log
reboot happy: 4.1.4-ti-r8
http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-3.log
Yeah. Mayhaps I’ll check it out once we run the generator again - In a couple days. 30kW onan cummings to pump water + transfer switch is slow enough most of the time that it wont keep the BBB up.
That image has the change you implemented ? for mii or whatever it was ( I forget ).
Changing linux-image’s on my nfsroot setup is a bit of a hassle though. Have to manually copy / move all the boot files, and dtb’s. IF I were better with shell scripts I’d probably write one lol.
Yeah, 4.1.4-ti-r9 has both the nfs mii change and the musb revert. So
when have lots of spare time for upgrades, don't pick anything earlier
than that for nfs.
Regards,
Yeah, 4.1.4-ti-r9 has both the nfs mii change and the musb revert. So
when have lots of spare time for upgrades, don’t pick anything earlier
than that for nfs. 
OK cool - thanks. I’ll pick a day when I’m not in a hurry to get things done. As usually the only real hassle is when I’m in a hurry, and make mistakes . . . because I’m thinking too much about the other things, and not enough of the job at hand
Hence why I usually have notes on hand for things like this, but not in this case. I should probably remedy that . . .