BeagleBone Black doesn't sometimes start. Only Power LED is on

[duckhunt...@gmail.com]

Hi guys,

we have a problem with our Beagle Bone Black (A5C). We are using Ubuntu Raring 13.04 armhf v3.8.13-bone21 (2013-06-14) on the eMMC (no SD Card). The Beagle Bone is placed in a case and we have connected it to a DC power supply. Sometimes (I would say every 5 to 10 times), when we are plugging in our power supply, the BeagleBone powers on (Power LED is on), but nothing more happens (none of the other four LEDs is on). If we are now removing the power supply and putting it in again, the BBB starts normally. I guess the power supply is strong enough: 5A@5V.

Thanks for your help in advance.

Regards,

duckhunter

[Gerald Coley]

I have no idea what is going on inside the box. Most likely you power supply has a ramp up that is too slow. There is more to a power supply than just voltage and current. It may even have a minimum current rating. I have no way to know.

Gerald

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

[William Hermans]

Gerald,

I have experienced this myself too. Not sure what is happening when this occurs, but usually pulling the power ( I power via a USB 3.0 port ) then reapplying fixes it.

Basically, I have given in to that this is just a quirk that occasionally rears it's head.. In the long run if I felt it important to fix, I would probably use some sort of an UPS to solve the issue ( or just power the board via a battery ).

[Gerald Coley]

Check the rise time on the power supply. Also, when it hangs, can you check the SYS_REST line?

Gerald

[William Hermans]

I can try.

Mostly when I have experienced this, it is when I have made changes to uEnv.txt. I am not sure if there is any correlation, but there you have it.

FWIW, lately, when issuing shutdown now -r ,  I have not experienced any problems. I am running Debian/Linux (RCN's build from source instructions / scripts ). and . . .

root@arm:~# uname -a

Linux arm 3.8.13-bone21 #1 SMP Sat Jun 15 19:36:33 MST 2013 armv7l GNU/Linux

 Not sure if that has, or could have anything to do with it. but there we have it.

[evilwulfie]

it happens to me too
i was wondering if the reset cap needed to be a bit larger .01uF  is rather small

[Gerald Coley]

Reset is controlled by the TPS65217C on power up. The SYS_RESET is just a warm reset, used after the board is up and running. It has an internal debounce circuit in the processor..

Gerald

[David Lambert]

I have found that both BBB and BBB seem to be rather sensitive to the
rise time of the DC power supply. I did some tests with a controlled
rate power circuit and found that if the rise time was greater than
around 500uS, then certain of our boards would not start. My solution
was to hold reset until the power was stable, then release it. Now we
get 100% success. I thought the PMIC chip was designed to be tolerant to
slowly rising power, but I have not had time to investigate further.

HTH,

Dave.

[Gerald Coley]

This is what I mentioned earlier. This was one of the reasons I added the power button. Using that to turn on and off helps this issue. The SW handles it OK, but it takes a little too long to shut down.

Gerald

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@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+unsubscribe@googlegroups.com.

[evilwulfie]

for an embedded device that does not have the reset button visable
this poses an issue, is there something that can be done in hardware to hold the reset low longer ?

On 7/31/2013 7:56 PM, Gerald Coley wrote:

This is what I mentioned earlier. This was one of the reasons I added the power button. Using that to turn on and off helps this issue. The SW handles it OK, but it takes a little too long to shut down.

Gerald

On Wed, Jul 31, 2013 at 9:40 PM, David Lambert <da...@lambsys.com> wrote:

I have found that both BBB and BBB seem to be rather sensitive to the rise time of the DC power supply. I did some tests with a controlled rate power circuit and found that if the rise time was greater than around 500uS, then certain of our boards would not start. My solution was to hold reset until the power was stable, then release it. Now we get 100% success. I thought the PMIC chip was designed to be tolerant to slowly rising power, but I have not had time to investigate further.

HTH,

Dave.

On 13-07-31 04:48 PM, duckhunt...@gmail.com wrote:

Hi guys,

we have a problem with our Beagle Bone Black (A5C). We are using Ubuntu Raring 13.04 armhf v3.8.13-bone21 (2013-06-14) on the eMMC (no SD Card). The Beagle Bone is placed in a case and we have connected it to a DC power supply. Sometimes (I would say every 5 to 10 times), when we are plugging in our power supply, the BeagleBone powers on (Power LED is on), but nothing more happens (none of the other four LEDs is on). If we are now removing the power supply and putting it in again, the BBB starts normally. I guess the power supply is strong enough: 5A@5V.

Thanks for your help in advance.

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

[Gerald Coley]

The PORz, PMIC_PGOOD, is programmable via a register setting in the TPS65217C.

Get the right power supply, and the issue should not exist.

Gerald

[evilwulfie]

I thought i read this somewhere a few  months ago  from tps65217c datasheet

Although the user can modify the power-up and power-down sequence through the SEQx
registers, those registers are reset to default values when the device enters SLEEP, OFF
or RESET state. In practice this means that the power-up sequence is fixed and a otherthan-
default power-down sequence has to be written every time the device is powered up.
Custom power-up/down sequences can be checked out in ACTIVE mode (PWR_EN pin
high) by using the SEQUP and SEQDWN bits. To change the power-up default values,
please contact the factory.

so it seems that a very fast ramp up power supply is the only way to ensure perfect power on
every time since the programming does not hold thru a power cycle
but brownouts and power fluctuations cannot be ruled out even with a top of the line power supply
seems the only way to really ensure is with a battery connected to the BBB as well

[dennis.c...@gmail.com]

Which power supply is the right one?

I have four boards and three different power supplies. Three of the boards always boot, on any of those supplies, when the AC is turned on or when the power connector is plugged in. The fourth board never does with any of the power supplies.

The fourth board will boot 100% of the time if the reset button is pushed after it has failed to boot on power up. When I connected the serial cable to see if I could find out what it was doing when it didn't boot I also discovered it would boot 100% of the time when powered up with the serial cable connected. When the serial cable is disconnected it stops booting.

I run NetBSD from an SD card currently, the original Linux is still on the internal flash. It doesn't boot on power up with the SD card plugged in and it doesn't boot with it taken out. The other three boards always do.

The three supplies I've got are a 2A wall wart from either Newark or Adafruit which was recommended for the BBB, a 5A supply with 4 USB outputs and an old HP bench supply. It behaves the same with all of them.

I need the cards to recover from power failures on their own so it's a concern. It certainly seems that not all BBB cards are created equal. If there's a particular power supply that fixes all problems, however, I'd be interested in knowing which.

Dennis Ferguson

[duckhunt...@gmail.com]

Hi Dave,

we have also tried to hold the reset for some time, but unfortunately that didn't work for us. Although it's getting better, we don't have a 100% success rate. How long do you hold the BBB in reset?

Regards,

duckhunter

[Gerald Coley]

Did you check the Wiki? We have power supplies listed there under accessories. Just because a distributor recommends it, does not make it so.

http://circuitco.com/support/BeagleBoneBlack

Again, it is not an amperage question.

Gerald

[duckhunt...@gmail.com]

Well actually we tried it using a transistor for switching on and also using it with just a USB cable. This failure happens again every 10th try.

Regards,

duckhunter

[Gerald Coley]

Are you doing a shutdown of the Kernel or just pulling power? What happens if you use the power button?

Gerald

Regards,

duckhunter

--

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

[Gerald Coley]

One more thing. What are you getting on the serial port, if anything, during the failed power up?

Gerald

[duckhunt...@gmail.com]

We have tried it with both Kernel shutdown and pulling power. I'm logging the serial debug port and will sent you this log as soon as a failure apperars.

Regards,

duckhunter

[Gerald Coley]

Shutdown does not remove the power, so that may indicate it is not an actual power up issue of the PMIC, as in this case, it is already powered up.

Thanks!

Gerald

Regards,

duckhunter

--

[duckhunt...@gmail.com]

Hi Gerald,

we have now a log file. The only things connected to the BBB is the power supply, the serial debug FTDI and an ethernet cable. One issue we found is the following (PHY not found (line 39)):

[Thu Aug 01 16:25:35.316 2013] U-Boot SPL 2013.04-00017-g5c4fa11 (May 03 2013 - 10:48:32)

[Thu Aug 01 16:25:35.443 2013] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)

[Thu Aug 01 16:25:35.498 2013] musb-hdrc: MHDRC RTL version 2.0 

[Thu Aug 01 16:25:35.498 2013] musb-hdrc: setup fifo_mode 4

[Thu Aug 01 16:25:35.498 2013] musb-hdrc: 28/31 max ep, 16384/16384 memory

[Thu Aug 01 16:25:35.498 2013] USB Peripheral mode controller at 47401000 using PIO, IRQ 0

[Thu Aug 01 16:25:35.498 2013] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)

[Thu Aug 01 16:25:35.498 2013] musb-hdrc: MHDRC RTL version 2.0 

[Thu Aug 01 16:25:35.498 2013] musb-hdrc: setup fifo_mode 4

[Thu Aug 01 16:25:35.499 2013] musb-hdrc: 28/31 max ep, 16384/16384 memory

[Thu Aug 01 16:25:35.499 2013] USB Host mode controller at 47401800 using PIO, IRQ 0

[Thu Aug 01 16:25:35.499 2013] OMAP SD/MMC: 0

[Thu Aug 01 16:25:36.489 2013] mmc_send_cmd : timeout: No status update

[Thu Aug 01 16:25:36.553 2013] reading u-boot.img

[Thu Aug 01 16:25:36.553 2013] reading u-boot.img

[Thu Aug 01 16:25:36.612 2013] 

[Thu Aug 01 16:25:36.612 2013] 

[Thu Aug 01 16:25:36.612 2013] U-Boot 2013.04-00017-g5c4fa11 (May 03 2013 - 10:48:32)

[Thu Aug 01 16:25:36.612 2013] 

[Thu Aug 01 16:25:36.612 2013] I2C:   ready

[Thu Aug 01 16:25:36.660 2013] DRAM:  512 MiB

[Thu Aug 01 16:25:37.268 2013] WARNING: Caches not enabled

[Thu Aug 01 16:25:37.780 2013] NAND:  No NAND device found!!!

[Thu Aug 01 16:25:38.034 2013] 0 MiB

[Thu Aug 01 16:25:38.034 2013] MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1

[Thu Aug 01 16:25:38.034 2013] *** Warning - readenv() failed, using default environment

[Thu Aug 01 16:25:38.034 2013] 

[Thu Aug 01 16:25:38.819 2013] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)

[Thu Aug 01 16:25:38.819 2013] musb-hdrc: MHDRC RTL version 2.0 

[Thu Aug 01 16:25:38.819 2013] musb-hdrc: setup fifo_mode 4

[Thu Aug 01 16:25:38.819 2013] musb-hdrc: 28/31 max ep, 16384/16384 memory

[Thu Aug 01 16:25:38.820 2013] USB Peripheral mode controller at 47401000 using PIO, IRQ 0

[Thu Aug 01 16:25:38.820 2013] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)

[Thu Aug 01 16:25:38.820 2013] musb-hdrc: MHDRC RTL version 2.0 

[Thu Aug 01 16:25:38.820 2013] musb-hdrc: setup fifo_mode 4

[Thu Aug 01 16:25:38.820 2013] musb-hdrc: 28/31 max ep, 16384/16384 memory

[Thu Aug 01 16:25:38.820 2013] USB Host mode controller at 47401800 using PIO, IRQ 0

[Thu Aug 01 16:25:38.820 2013] Net:   <ethaddr> not set. Validating first E-fuse MAC

[Thu Aug 01 16:25:38.835 2013] Phy not found

[Thu Aug 01 16:25:39.453 2013] PHY reset timed out

[Thu Aug 01 16:25:39.453 2013] cpsw, usb_ether

[Thu Aug 01 16:25:39.453 2013] Hit any key to stop autoboot:  1  0 

[Thu Aug 01 16:25:40.460 2013] gpio: pin 53 (gpio 53) value is 1

[Thu Aug 01 16:25:40.500 2013] Card did not respond to voltage select!

[Thu Aug 01 16:25:40.501 2013] mmc0(part 0) is current device

[Thu Aug 01 16:25:41.492 2013] mmc_send_cmd : timeout: No status update

[Thu Aug 01 16:25:41.508 2013] Card did not respond to voltage select!

[Thu Aug 01 16:25:42.516 2013] mmc_send_cmd : timeout: No status update

[Thu Aug 01 16:25:42.564 2013] mmc1(part 0) is current device

[Thu Aug 01 16:25:43.572 2013] mmc_send_cmd : timeout: No status update

[Thu Aug 01 16:25:43.620 2013] gpio: pin 54 (gpio 54) value is 1

[Thu Aug 01 16:25:43.620 2013] SD/MMC found on device 1

[Thu Aug 01 16:25:43.665 2013] reading uEnv.txt

[Thu Aug 01 16:25:43.665 2013] 1314 bytes read in 5 ms (255.9 KiB/s)

[Thu Aug 01 16:25:43.665 2013] Importing environment from mmc ...

[Thu Aug 01 16:25:43.665 2013] gpio: pin 55 (gpio 55) value is 1

[Thu Aug 01 16:25:43.665 2013] gpio: pin 56 (gpio 56) value is 1

[Thu Aug 01 16:25:43.665 2013] Running uenvcmd ...

[Thu Aug 01 16:25:43.665 2013] reading zImage

[Thu Aug 01 16:25:44.033 2013] 3252888 bytes read in 373 ms (8.3 MiB/s)

[Thu Aug 01 16:25:44.049 2013] reading uInitrd

[Thu Aug 01 16:25:44.352 2013] 2709355 bytes read in 312 ms (8.3 MiB/s)

[Thu Aug 01 16:25:44.422 2013] reading /dtbs/am335x-boneblack.dtb

[Thu Aug 01 16:25:44.423 2013] 24125 bytes read in 9 ms (2.6 MiB/s)

[Thu Aug 01 16:25:44.423 2013] ## Loading init Ramdisk from Legacy Image at 81000000 ...

[Thu Aug 01 16:25:44.423 2013]    Image Name:   initramfs

[Thu Aug 01 16:25:44.423 2013]    Image Type:   ARM Linux RAMDisk Image (uncompressed)

[Thu Aug 01 16:25:44.423 2013]    Data Size:    2709291 Bytes = 2.6 MiB

[Thu Aug 01 16:25:44.423 2013]    Load Address: 00000000

[Thu Aug 01 16:25:44.423 2013]    Entry Point:  00000000

[Thu Aug 01 16:25:44.423 2013] ## Flattened Device Tree blob at 815f0000

[Thu Aug 01 16:25:44.423 2013]    Booting using the fdt blob at 0x815f0000

[Thu Aug 01 16:25:44.423 2013]    Using Device Tree in place at 815f0000, end 815f8e3c

[Thu Aug 01 16:25:44.470 2013] 

[Thu Aug 01 16:25:44.470 2013] Starting kernel ...

[Thu Aug 01 16:25:44.470 2013] 

[Thu Aug 01 16:25:44.486 2013] Uncompressing Linux... done, booting the kernel.

[Thu Aug 01 16:25:48.468 2013] [    0.000000] Booting Linux on physical CPU 0x0

[Thu Aug 01 16:25:48.468 2013] [    0.000000] Initializing cgroup subsys cpu

[Thu Aug 01 16:25:48.468 2013] [    0.000000] Linux version 3.8.13-bone21 (root@imx6q-sabrelite-1gb-0) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #1 SMP Fri Jun 14 03:10:29 UTC 2013

[Thu Aug 01 16:25:48.468 2013] [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d

[Thu Aug 01 16:25:48.469 2013] [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[Thu Aug 01 16:25:48.469 2013] [    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone

[Thu Aug 01 16:25:48.469 2013] [    0.000000] Memory policy: ECC disabled, Data cache writeback

[Thu Aug 01 16:25:48.469 2013] [    0.000000] AM335X ES1.0 (neon )

[Thu Aug 01 16:25:48.469 2013] [    0.000000] PERCPU: Embedded 9 pages/cpu @c0df4000 s14080 r8192 d14592 u36864

[Thu Aug 01 16:25:48.469 2013] [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129792

[Thu Aug 01 16:25:48.469 2013] [    0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip=

[Thu Aug 01 16:25:48.470 2013] [    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)

[Thu Aug 01 16:25:48.470 2013] [    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)

[Thu Aug 01 16:25:48.473 2013] [    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)

[Thu Aug 01 16:25:48.473 2013] [    0.000000] __ex_table already sorted, skipping sort

[Thu Aug 01 16:25:48.474 2013] [    0.000000] allocated 1048576 bytes of page_cgroup

[Thu Aug 01 16:25:48.474 2013] [    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups

[Thu Aug 01 16:25:48.474 2013] [    0.000000] Memory: 511MB = 511MB total

[Thu Aug 01 16:25:48.474 2013] [    0.000000] Memory: 504832k/504832k available, 19456k reserved, 0K highmem

[Thu Aug 01 16:25:48.474 2013] [    0.000000] Virtual kernel memory layout:

[Thu Aug 01 16:25:48.474 2013] [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)

[Thu Aug 01 16:25:48.474 2013] [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

[Thu Aug 01 16:25:48.475 2013] [    0.000000]     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)

[Thu Aug 01 16:25:48.475 2013] [    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)

[Thu Aug 01 16:25:48.475 2013] [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)

[Thu Aug 01 16:25:48.475 2013] [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)

[Thu Aug 01 16:25:48.475 2013] [    0.000000]       .text : 0xc0008000 - 0xc08a3248   (8813 kB)

[Thu Aug 01 16:25:48.475 2013] [    0.000000]       .init : 0xc08a4000 - 0xc08ec700   ( 290 kB)

[Thu Aug 01 16:25:48.478 2013] [    0.000000]       .data : 0xc08ee000 - 0xc096e970   ( 515 kB)

[Thu Aug 01 16:25:48.478 2013] [    0.000000]        .bss : 0xc096e970 - 0xc09e49fc   ( 473 kB)

[Thu Aug 01 16:25:48.478 2013] [    0.000000] Hierarchical RCU implementation.

[Thu Aug 01 16:25:48.479 2013] [    0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.

[Thu Aug 01 16:25:48.479 2013] [    0.000000] NR_IRQS:16 nr_irqs:16 16

[Thu Aug 01 16:25:48.479 2013] [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts

[Thu Aug 01 16:25:48.479 2013] [    0.000000] Total of 128 interrupts on 1 active controller

[Thu Aug 01 16:25:48.479 2013] [    0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz

[Thu Aug 01 16:25:48.479 2013] [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms

[Thu Aug 01 16:25:48.480 2013] [    0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz

[Thu Aug 01 16:25:48.480 2013] [    0.000000] Console: colour dummy device 80x30

[Thu Aug 01 16:25:48.480 2013] [    0.000384] Calibrating delay loop... 363.67 BogoMIPS (lpj=354304)

[Thu Aug 01 16:25:48.480 2013] [    0.017384] pid_max: default: 32768 minimum: 301

[Thu Aug 01 16:25:48.480 2013] [    0.017632] Security Framework initialized

[Thu Aug 01 16:25:48.480 2013] [    0.017733] Mount-cache hash table entries: 512

[Thu Aug 01 16:25:48.480 2013] [    0.027563] Initializing cgroup subsys cpuacct

[Thu Aug 01 16:25:48.480 2013] [    0.027602] Initializing cgroup subsys memory

[Thu Aug 01 16:25:48.486 2013] [    0.027673] Initializing cgroup subsys blkio

[Thu Aug 01 16:25:48.486 2013] [    0.027828] CPU: Testing write buffer coherency: ok

[Thu Aug 01 16:25:48.486 2013] [    0.028422] CPU0: thread -1, cpu 0, socket -1, mpidr 0

[Thu Aug 01 16:25:48.486 2013] [    0.028499] Setting up static identity map for 0x805f2c70 - 0x805f2cc8

[Thu Aug 01 16:25:48.486 2013] [    0.030192] Brought up 1 CPUs

[Thu Aug 01 16:25:48.486 2013] [    0.030217] SMP: Total of 1 processors activated (363.67 BogoMIPS).

[Thu Aug 01 16:25:48.487 2013] [    0.031637] devtmpfs: initialized

[Thu Aug 01 16:25:48.487 2013] [    0.096758] pinctrl core: initialized pinctrl subsystem

[Thu Aug 01 16:25:48.487 2013] [    0.097003] rstctl core: initialized rstctl subsystem

[Thu Aug 01 16:25:48.487 2013] [    0.097594] regulator-dummy: no parameters

[Thu Aug 01 16:25:48.487 2013] [    0.098154] NET: Registered protocol family 16

[Thu Aug 01 16:25:48.487 2013] [    0.099065] DMA: preallocated 256 KiB pool for atomic coherent allocations

[Thu Aug 01 16:25:48.487 2013] [    0.109035] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568

[Thu Aug 01 16:25:48.488 2013] [    0.109866] platform 49000000.edma: alias fck already exists

[Thu Aug 01 16:25:48.488 2013] [    0.109898] platform 49000000.edma: alias fck already exists

[Thu Aug 01 16:25:48.488 2013] [    0.109924] platform 49000000.edma: alias fck already exists

[Thu Aug 01 16:25:48.831 2013] [    0.111300] OMAP GPIO hardware version 0.1

[Thu Aug 01 16:25:48.831 2013] [    0.116212] gpio-rctrl rstctl.3: loaded OK

[Thu Aug 01 16:25:48.832 2013] [    0.121593] hw-breakpoint: debug architecture 0x4 unsupported.

[Thu Aug 01 16:25:48.832 2013] [    0.123782] cpsw.0: No hwaddr in dt. Using 90:59:af:54:40:30 from efuse

[Thu Aug 01 16:25:48.832 2013] [    0.123818] cpsw.1: No hwaddr in dt. Using 90:59:af:54:40:32 from efuse

[Thu Aug 01 16:25:48.832 2013] [    0.137623] bio: create slab <bio-0> at 0

[Thu Aug 01 16:25:48.832 2013] [    0.149292] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver

[Thu Aug 01 16:25:48.832 2013] [    0.149753] vmmcsd_fixed: 3300 mV 

[Thu Aug 01 16:25:48.832 2013] [    0.152601] SCSI subsystem initialized

[Thu Aug 01 16:25:48.832 2013] [    0.153021] usbcore: registered new interface driver usbfs

[Thu Aug 01 16:25:48.833 2013] [    0.153153] usbcore: registered new interface driver hub

[Thu Aug 01 16:25:48.833 2013] [    0.153479] usbcore: registered new device driver usb

[Thu Aug 01 16:25:48.833 2013] [    0.155603] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz

[Thu Aug 01 16:25:48.833 2013] [    0.157199] input: tps65217_pwr_but as /devices/ocp.2/44e0b000.i2c/i2c-0/0-0024/input/input0

[Thu Aug 01 16:25:48.833 2013] [    0.159496] DCDC1: at 1500 mV 

[Thu Aug 01 16:25:48.833 2013] [    0.160791] vdd_mpu: 925 <--> 1325 mV at 1100 mV 

[Thu Aug 01 16:25:48.833 2013] [    0.162000] vdd_core: 925 <--> 1150 mV at 1100 mV 

[Thu Aug 01 16:25:48.836 2013] [    0.163140] LDO1: at 1800 mV 

[Thu Aug 01 16:25:48.836 2013] [    0.164256] LDO2: at 3300 mV 

[Thu Aug 01 16:25:48.837 2013] [    0.166237] LDO3: 1800 mV 

[Thu Aug 01 16:25:48.837 2013] [    0.167375] LDO4: at 3300 mV 

[Thu Aug 01 16:25:48.837 2013] [    0.168442] tps65217 0-0024: TPS65217 ID 0xe version 1.2

[Thu Aug 01 16:25:48.837 2013] [    0.169221] omap_i2c 44e0b000.i2c: unable to select pin group

[Thu Aug 01 16:25:48.837 2013] [    0.170099] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz

[Thu Aug 01 16:25:48.837 2013] [    0.172668] omap_i2c 4819c000.i2c: unable to select pin group

[Thu Aug 01 16:25:48.837 2013] [    0.172902] media: Linux media interface: v0.10

[Thu Aug 01 16:25:48.837 2013] [    0.173005] Linux video capture interface: v2.00

[Thu Aug 01 16:25:48.838 2013] [    0.173870] Advanced Linux Sound Architecture Driver Initialized.

[Thu Aug 01 16:25:48.838 2013] [    0.174879] NetLabel: Initializing

[Thu Aug 01 16:25:48.838 2013] [    0.174901] NetLabel:  domain hash size = 128

[Thu Aug 01 16:25:48.838 2013] [    0.174913] NetLabel:  protocols = UNLABELED CIPSOv4

[Thu Aug 01 16:25:48.838 2013] [    0.175027] NetLabel:  unlabeled traffic allowed by default

[Thu Aug 01 16:25:48.838 2013] [    0.175368] Switching to clocksource gp_timer

[Thu Aug 01 16:25:48.838 2013] [    0.229831] NET: Registered protocol family 2

[Thu Aug 01 16:25:48.838 2013] [    0.231045] TCP established hash table entries: 4096 (order: 3, 32768 bytes)

[Thu Aug 01 16:25:48.839 2013] [    0.231190] TCP bind hash table entries: 4096 (order: 4, 81920 bytes)

[Thu Aug 01 16:25:48.842 2013] [    0.231352] TCP: Hash tables configured (established 4096 bind 4096)

[Thu Aug 01 16:25:48.842 2013] [    0.231451] TCP: reno registered

[Thu Aug 01 16:25:48.842 2013] [    0.231480] UDP hash table entries: 256 (order: 1, 12288 bytes)

[Thu Aug 01 16:25:48.842 2013] [    0.231527] UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)

[Thu Aug 01 16:25:48.842 2013] [    0.231963] NET: Registered protocol family 1

[Thu Aug 01 16:25:48.842 2013] [    0.232686] RPC: Registered named UNIX socket transport module.

[Thu Aug 01 16:25:48.843 2013] [    0.232710] RPC: Registered udp transport module.

[Thu Aug 01 16:25:48.843 2013] [    0.232723] RPC: Registered tcp transport module.

[Thu Aug 01 16:25:48.843 2013] [    0.232736] RPC: Registered tcp NFSv4.1 backchannel transport module.

[Thu Aug 01 16:25:48.843 2013] [    0.233155] Trying to unpack rootfs image as initramfs...

[Thu Aug 01 16:25:48.843 2013] [    0.543983] Freeing initrd memory: 2644K

[Thu Aug 01 16:25:48.843 2013] [    0.544874] CPU PMU: probing PMU on CPU 0

[Thu Aug 01 16:25:48.843 2013] [    0.544910] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available

[Thu Aug 01 16:25:48.844 2013] [    0.545470] omap2_mbox_probe: platform not supported

[Thu Aug 01 16:25:48.844 2013] [    0.814354] VFS: Disk quotas dquot_6.5.2

[Thu Aug 01 16:25:48.844 2013] [    0.814621] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

[Thu Aug 01 16:25:48.848 2013] [    0.815901] NFS: Registering the id_resolver key type

[Thu Aug 01 16:25:48.849 2013] [    0.816027] Key type id_resolver registered

[Thu Aug 01 16:25:48.849 2013] [    0.816043] Key type id_legacy registered

[Thu Aug 01 16:25:48.849 2013] [    0.816230] fuse init (API version 7.20)

[Thu Aug 01 16:25:48.849 2013] [    0.817142] Btrfs loaded

[Thu Aug 01 16:25:48.849 2013] [    0.817314] msgmni has been set to 991

[Thu Aug 01 16:25:48.849 2013] [    0.820477] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)

[Thu Aug 01 16:25:48.849 2013] [    0.820508] io scheduler noop registered

[Thu Aug 01 16:25:48.849 2013] [    0.820523] io scheduler deadline registered

[Thu Aug 01 16:25:48.850 2013] [    0.820576] io scheduler cfq registered (default)

[Thu Aug 01 16:25:48.850 2013] [    0.822462] tps65217-bl tps65217-bl: no platform data provided

[Thu Aug 01 16:25:48.850 2013] [    0.822508] tps65217-bl: probe of tps65217-bl failed with error -22

[Thu Aug 01 16:25:48.850 2013] [    0.823354] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled

[Thu Aug 01 16:25:48.850 2013] [    0.826099] omap_uart 44e09000.serial: did not get pins for uart0 error: -19

[Thu Aug 01 16:25:48.850 2013] [    0.826430] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0

[Thu Aug 01 16:25:48.851 2013] [    1.548019] console [ttyO0] enabled

[Thu Aug 01 16:25:48.852 2013] [    1.552821] [drm] Initialized drm 1.1.0 20060810

[Thu Aug 01 16:25:48.852 2013] [    1.571339] brd: module loaded

[Thu Aug 01 16:25:48.937 2013] [    1.581557] loop: module loaded

[Thu Aug 01 16:25:48.938 2013] [    1.585042] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[Thu Aug 01 16:25:48.938 2013] [    1.592352] at24 1-0054: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[Thu Aug 01 16:25:48.938 2013] [    1.599638] at24 1-0055: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[Thu Aug 01 16:25:48.938 2013] [    1.606925] at24 1-0056: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[Thu Aug 01 16:25:48.938 2013] [    1.614222] at24 1-0057: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[Thu Aug 01 16:25:48.938 2013] [    1.628270] bone-capemgr bone_capemgr.9: Baseboard: 'A335BNLT,0A5C,2513BBBK3061'

[Thu Aug 01 16:25:48.939 2013] [    1.636076] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,beaglebone-black

[Thu Aug 01 16:25:48.953 2013] [    1.671593] bone-capemgr bone_capemgr.9: slot #0: No cape found

[Thu Aug 01 16:25:49.008 2013] [    1.708701] bone-capemgr bone_capemgr.9: slot #1: No cape found

[Thu Aug 01 16:25:49.045 2013] [    1.745808] bone-capemgr bone_capemgr.9: slot #2: No cape found

[Thu Aug 01 16:25:49.439 2013] [    1.782919] bone-capemgr bone_capemgr.9: slot #3: No cape found

[Thu Aug 01 16:25:49.439 2013] [    1.789186] bone-capemgr bone_capemgr.9: slot #4: specific override

[Thu Aug 01 16:25:49.439 2013] [    1.795798] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4

[Thu Aug 01 16:25:49.440 2013] [    1.803846] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'

[Thu Aug 01 16:25:49.440 2013] [    1.814006] bone-capemgr bone_capemgr.9: slot #5: specific override

[Thu Aug 01 16:25:49.440 2013] [    1.820614] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 5

[Thu Aug 01 16:25:49.440 2013] [    1.828659] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'

[Thu Aug 01 16:25:49.441 2013] [    1.838711] bone-capemgr bone_capemgr.9: slot #6: specific override

[Thu Aug 01 16:25:49.441 2013] [    1.845319] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 6

[Thu Aug 01 16:25:49.441 2013] [    1.853368] bone-capemgr bone_capemgr.9: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'

[Thu Aug 01 16:25:49.441 2013] [    1.864032] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[Thu Aug 01 16:25:49.441 2013] [    1.872924] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[Thu Aug 01 16:25:49.444 2013] [    1.881823] bone-capemgr bone_capemgr.9: loader: before slot-5 BB-BONELT-HDMI:00A0 (prio 1)

[Thu Aug 01 16:25:49.444 2013] [    1.890605] bone-capemgr bone_capemgr.9: loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1)

[Thu Aug 01 16:25:49.444 2013] [    1.899320] bone-capemgr bone_capemgr.9: initialized OK.

[Thu Aug 01 16:25:49.444 2013] [    1.904931] bone-capemgr bone_capemgr.9: loader: before slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:25:49.445 2013] [    1.913792] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:25:49.445 2013] [    1.924559] OneNAND driver initializing

[Thu Aug 01 16:25:49.445 2013] [    1.930004] usbcore: registered new interface driver cdc_ether

[Thu Aug 01 16:25:49.445 2013] [    1.936197] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[Thu Aug 01 16:25:49.445 2013] [    1.945014] bone-capemgr bone_capemgr.9: loader: after slot-5 BB-BONELT-HDMI:00A0 (prio 1)

[Thu Aug 01 16:25:49.446 2013] [    1.953777] usbcore: registered new interface driver rndis_host

[Thu Aug 01 16:25:49.446 2013] [    1.960090] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:25:49.446 2013] [    1.968983] usbcore: registered new interface driver cdc_ncm

[Thu Aug 01 16:25:49.449 2013] [    1.974975] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'

[Thu Aug 01 16:25:49.449 2013] [    1.989309] Initializing USB Mass Storage driver...

[Thu Aug 01 16:25:49.449 2013] [    1.994603] usbcore: registered new interface driver usb-storage

[Thu Aug 01 16:25:49.449 2013] [    2.000923] USB Mass Storage support registered.

[Thu Aug 01 16:25:49.450 2013] [    2.006097] bone-capemgr bone_capemgr.9: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree

[Thu Aug 01 16:25:49.450 2013] [    2.016875] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 'cape-boneblack-hdmi-00A0.dtbo' for board-name 'Bone-Black-HDMI', version '00A0'

[Thu Aug 01 16:25:49.450 2013] [    2.031219] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)

[Thu Aug 01 16:25:49.450 2013] [    2.037870] bone-capemgr bone_capemgr.9: slot #4: #2 overlays

[Thu Aug 01 16:25:49.450 2013] [    2.044339] musb-hdrc musb-hdrc.0.auto: pdev->id = 0

[Thu Aug 01 16:25:49.451 2013] [    2.049601] musb-hdrc musb-hdrc.0.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK

[Thu Aug 01 16:25:49.451 2013] [    2.058673] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.

[Thu Aug 01 16:25:49.451 2013] [    2.065557] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[Thu Aug 01 16:25:49.456 2013] [    2.074277] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:25:49.456 2013] [    2.083077] bone-capemgr bone_capemgr.9: slot #5: dtbo 'cape-boneblack-hdmi-00A0.dtbo' loaded; converting to live tree

[Thu Aug 01 16:25:49.456 2013] [    2.094596] musb-hdrc musb-hdrc.0.auto: *** mode=3

[Thu Aug 01 16:25:49.457 2013] [    2.099668] musb-hdrc musb-hdrc.0.auto: *** power=250

[Thu Aug 01 16:25:49.457 2013] [    2.106057] bone-capemgr bone_capemgr.9: slot #5: #4 overlays

[Thu Aug 01 16:25:49.457 2013] [    2.114604] platform 4830e000.fb: alias fck already exists

[Thu Aug 01 16:25:49.457 2013] [    2.121381] musb-hdrc musb-hdrc.1.auto: pdev->id = 1

[Thu Aug 01 16:25:49.457 2013] [    2.126692] musb-hdrc musb-hdrc.1.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK

[Thu Aug 01 16:25:49.457 2013] [    2.135724] musb-hdrc musb-hdrc.1.auto: *** mode=1

[Thu Aug 01 16:25:49.458 2013] [    2.140803] musb-hdrc musb-hdrc.1.auto: *** power=250

[Thu Aug 01 16:25:49.458 2013] [    2.146124] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver

[Thu Aug 01 16:25:49.458 2013] [    2.153807] bone-capemgr bone_capemgr.9: slot #5: Applied #4 overlays.

[Thu Aug 01 16:25:49.677 2013] [    2.160731] bone-capemgr bone_capemgr.9: loader: done slot-5 BB-BONELT-HDMI:00A0 (prio 1)

[Thu Aug 01 16:25:49.677 2013] [    2.169367] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:25:49.677 2013] [    2.178562] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1

[Thu Aug 01 16:25:49.677 2013] [    2.186852] bone-capemgr bone_capemgr.9: loader: after slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:25:49.678 2013] [    2.195878] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002

[Thu Aug 01 16:25:49.678 2013] [    2.203029] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1

[Thu Aug 01 16:25:49.678 2013] [    2.210633] usb usb1: Product: MUSB HDRC host driver

[Thu Aug 01 16:25:49.678 2013] [    2.215859] usb usb1: Manufacturer: Linux 3.8.13-bone21 musb-hcd

[Thu Aug 01 16:25:49.678 2013] [    2.222173] usb usb1: SerialNumber: musb-hdrc.1.auto

[Thu Aug 01 16:25:49.678 2013] [    2.227459] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version '00A0'

[Thu Aug 01 16:25:49.679 2013] [    2.241939] bone-capemgr bone_capemgr.9: slot #6: dtbo 'cape-boneblack-hdmin-00A0.dtbo' loaded; converting to live tree

[Thu Aug 01 16:25:49.679 2013] [    2.254814] hub 1-0:1.0: USB hub found

[Thu Aug 01 16:25:49.682 2013] [    2.258946] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#5:BB-BONELT-HDMI)

[Thu Aug 01 16:25:49.682 2013] [    2.268565] bone-capemgr bone_capemgr.9: slot #6: Failed verification

[Thu Aug 01 16:25:49.683 2013] [    2.275343] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:25:49.683 2013] [    2.284981] hub 1-0:1.0: 1 port detected

[Thu Aug 01 16:25:49.683 2013] [    2.290862] mousedev: PS/2 mouse device common for all mice

[Thu Aug 01 16:25:49.683 2013] [    2.299143] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0

[Thu Aug 01 16:25:49.683 2013] [    2.307002] i2c /dev entries driver

[Thu Aug 01 16:25:49.683 2013] [    2.312099] Driver for 1-wire Dallas network protocol.

[Thu Aug 01 16:25:49.684 2013] [    2.319140] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec

[Thu Aug 01 16:25:49.684 2013] [    2.326808] cpuidle: using governor ladder

[Thu Aug 01 16:25:49.684 2013] [    2.331197] cpuidle: using governor menu

[Thu Aug 01 16:25:49.684 2013] [    2.335844] omap_hsmmc mmc.4: of_parse_phandle_with_args of 'reset' failed

[Thu Aug 01 16:25:49.684 2013] [    2.343097] omap_hsmmc mmc.4: Failed to get rstctl; not using any

[Thu Aug 01 16:25:49.684 2013] [    2.349539] omap_hsmmc mmc.4: unable to select pin group

[Thu Aug 01 16:25:49.684 2013] [    2.355447] edma-dma-engine edma-dma-engine.0: allocated channel for 0:25

[Thu Aug 01 16:25:49.686 2013] [    2.362681] edma-dma-engine edma-dma-engine.0: allocated channel for 0:24

[Thu Aug 01 16:25:49.686 2013] [    2.370049] mmc.4 supply vmmc_aux not found, using dummy regulator

[Thu Aug 01 16:25:49.686 2013] [    2.376731] omap_hsmmc mmc.4: pins are not configured from the driver

[Thu Aug 01 16:25:49.692 2013] [    2.410145] gpio-rctrl rstctl.3: gpio_rctrl_request eMMC_RSTn

[Thu Aug 01 16:25:49.749 2013] [    2.416388] omap_hsmmc mmc.5: Got rstctl (gpio:#0 name eMMC_RSTn) label:eMMC_RSTn

[Thu Aug 01 16:25:49.750 2013] [    2.424310] gpio-rctrl rstctl.3: gpio_rctrl_deassert eMMC_RSTn

[Thu Aug 01 16:25:49.750 2013] [    2.430805] edma-dma-engine edma-dma-engine.0: allocated channel for 0:3

[Thu Aug 01 16:25:49.750 2013] [    2.437993] edma-dma-engine edma-dma-engine.0: allocated channel for 0:2

[Thu Aug 01 16:25:49.750 2013] [    2.445592] mmc.5 supply vmmc_aux not found, using dummy regulator

[Thu Aug 01 16:25:49.750 2013] [    2.452282] omap_hsmmc mmc.5: pins are not configured from the driver

[Thu Aug 01 16:25:49.964 2013] [    2.486644] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8

[Thu Aug 01 16:25:49.964 2013] [    2.498406] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22

[Thu Aug 01 16:25:49.965 2013] [    2.505724] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single

[Thu Aug 01 16:25:49.965 2013] [    2.514726] leds-gpio gpio-leds.8: pins are not configured from the driver

[Thu Aug 01 16:25:49.965 2013] [    2.523158] ledtrig-cpu: registered to indicate activity on CPUs

[Thu Aug 01 16:25:49.965 2013] [    2.530015] edma-dma-engine edma-dma-engine.0: allocated channel for 0:36

[Thu Aug 01 16:25:49.965 2013] [    2.537319] omap-sham 53100000.sham: hw accel on OMAP rev 4.3

[Thu Aug 01 16:25:49.966 2013] [    2.546128] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2

[Thu Aug 01 16:25:49.966 2013] [    2.552675] edma-dma-engine edma-dma-engine.0: allocated channel for 0:5

[Thu Aug 01 16:25:49.966 2013] [    2.559895] edma-dma-engine edma-dma-engine.0: allocated channel for 0:6

[Thu Aug 01 16:25:49.966 2013] [    2.568344] usbcore: registered new interface driver usbhid

[Thu Aug 01 16:25:49.966 2013] [    2.574231] usbhid: USB HID core driver

[Thu Aug 01 16:25:49.966 2013] [    2.582746] davinci_evm sound.13:  nxp-hdmi-hifi <-> 48038000.mcasp mapping ok

[Thu Aug 01 16:25:49.966 2013] [    2.594429] TCP: cubic registered

[Thu Aug 01 16:25:49.969 2013] [    2.598076] NET: Registered protocol family 10

[Thu Aug 01 16:25:49.969 2013] [    2.604085] NET: Registered protocol family 17

[Thu Aug 01 16:25:49.969 2013] [    2.609368] Key type dns_resolver registered

[Thu Aug 01 16:25:49.969 2013] [    2.614212] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3

[Thu Aug 01 16:25:49.969 2013] [    2.622408] ThumbEE CPU extension supported.

[Thu Aug 01 16:25:49.969 2013] [    2.626984] Registering SWP/SWPB emulation handler

[Thu Aug 01 16:25:49.969 2013] [    2.633348] registered taskstats version 1

[Thu Aug 01 16:25:49.970 2013] [    2.638458] slave hdmi.12: modes-blacklisted #0 -> 1920x1080@25

[Thu Aug 01 16:25:49.970 2013] [    2.644796] mmc1: BKOPS_EN bit is not set

[Thu Aug 01 16:25:49.970 2013] [    2.649068] slave hdmi.12: modes-blacklisted #1 -> 832x624@75

[Thu Aug 01 16:25:49.970 2013] [    2.657099] tilcdc 4830e000.fb: No power control GPIO

[Thu Aug 01 16:25:49.970 2013] [    2.663668] mmc1: new high speed MMC card at address 0001

[Thu Aug 01 16:25:49.970 2013] [    2.677645] mmcblk0: mmc1:0001 MMC02G 1.78 GiB 

[Thu Aug 01 16:25:50.013 2013] [    2.688071] mmcblk0boot0: mmc1:0001 MMC02G partition 1 1.00 MiB

[Thu Aug 01 16:25:50.013 2013] [    2.694783] mmcblk0boot1: mmc1:0001 MMC02G partition 2 1.00 MiB

[Thu Aug 01 16:25:50.013 2013] [    2.703515]  mmcblk0: p1 p2

[Thu Aug 01 16:25:50.013 2013] [    2.709493]  mmcblk0boot1: unknown partition table

[Thu Aug 01 16:25:50.014 2013] [    2.716768]  mmcblk0boot0: unknown partition table

[Thu Aug 01 16:25:50.077 2013] [    2.795776] tilcdc 4830e000.fb: found TDA19988

[Thu Aug 01 16:25:50.122 2013] [    2.801274] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).

[Thu Aug 01 16:25:50.122 2013] [    2.808244] [drm] No driver support for vblank timestamp query.

[Thu Aug 01 16:25:50.122 2013] [    2.814880] tilcdc 4830e000.fb: No connectors reported connected with modes

[Thu Aug 01 16:25:50.123 2013] [    2.822219] [drm] Cannot find any crtc or sizes - going 1024x768

[Thu Aug 01 16:25:50.169 2013] [    2.843078] Console: switching to colour frame buffer device 128x48

[Thu Aug 01 16:25:50.169 2013] [    2.859176] tilcdc 4830e000.fb: fb0:  frame buffer device

[Thu Aug 01 16:25:50.169 2013] [    2.864857] tilcdc 4830e000.fb: registered panic notifier

[Thu Aug 01 16:25:50.169 2013] [    2.870559] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0

[Thu Aug 01 16:25:50.233 2013] [    2.927480] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6

[Thu Aug 01 16:25:50.233 2013] [    2.933918] davinci_mdio 4a101000.mdio: detected phy mask fffffffb

[Thu Aug 01 16:25:50.233 2013] [    2.951696] libphy: 4a101000.mdio: probed

[Thu Aug 01 16:25:50.295 2013] [    2.956029] davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:02, driver SMSC LAN8710/LAN8720

[Thu Aug 01 16:25:50.295 2013] [    2.965931] Detected MACID = 90:59:af:54:40:30

[Thu Aug 01 16:25:50.295 2013] [    2.970662] cpsw 4a100000.ethernet: NAPI disabled

[Thu Aug 01 16:25:50.296 2013] [    2.977773] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)

[Thu Aug 01 16:25:50.296 2013] [    2.990243] ALSA device list:

[Thu Aug 01 16:25:50.296 2013] [    2.993403]   #0: TI BeagleBone Black

[Thu Aug 01 16:25:50.296 2013] [    2.998069] Freeing init memory: 288K

[Thu Aug 01 16:25:50.311 2013] Loading, please wait...

[Thu Aug 01 16:25:50.375 2013] [    3.093296] udevd[101]: starting version 175

[Thu Aug 01 16:25:50.391 2013] Begin: Loading essential drivers ... done.

[Thu Aug 01 16:25:50.407 2013] Begin: Running /scripts/init-premount ... done.

[Thu Aug 01 16:25:50.423 2013] Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.

[Thu Aug 01 16:25:51.078 2013] Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems

[Thu Aug 01 16:25:51.607 2013] done.

[Thu Aug 01 16:25:51.638 2013] [    4.358863] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem

[Thu Aug 01 16:25:51.666 2013] [    4.366630] EXT4-fs (mmcblk0p2): write access will be enabled during recovery

[Thu Aug 01 16:25:52.514 2013] [    5.229516] EXT4-fs (mmcblk0p2): recovery complete

[Thu Aug 01 16:25:52.552 2013] [    5.238475] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)

[Thu Aug 01 16:25:52.553 2013] Begin: Running /scripts/local-bottom ... done.

[Thu Aug 01 16:25:52.553 2013] done.

[Thu Aug 01 16:25:52.553 2013] Begin: Running /scripts/init-bottom ... done.

[Thu Aug 01 16:25:53.238 2013] [    5.938633] init: ureadahead main process (223) terminated with status 5

[Thu Aug 01 16:25:54.081 2013] [    6.781888] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro

[Thu Aug 01 16:25:56.939 2013] [    9.626461] libphy: PHY 4a101000.mdio:00 not found

[Thu Aug 01 16:25:56.939 2013] [    9.631558] net eth0: phy 4a101000.mdio:00 not found on slave 0

[Thu Aug 01 16:25:56.939 2013] [    9.637786] libphy: PHY 4a101000.mdio:01 not found

[Thu Aug 01 16:25:56.939 2013] [    9.642822] net eth0: phy 4a101000.mdio:01 not found on slave 1

[Thu Aug 01 16:26:01.433 2013]  * Loading cpufreq kernel modules...        [ OK ]

[Thu Aug 01 16:26:02.601 2013]  * Starting virtual private network daemon(s)...         *   Autostart disabled, no VPN will be started.

[Thu Aug 01 16:26:02.708 2013]  * CPUFreq Utilities: Setting ondemand CPUFreq governor...         * CPU0...        [ OK ]

[Thu Aug 01 16:26:02.788 2013] Starting very small Busybox based DHCP server: Starting /usr/sbin/udhcpd...

[Thu Aug 01 16:26:02.836 2013] udhcpd.

[Thu Aug 01 16:26:02.916 2013]  * Starting NTP server ntpd        [ OK ]

[Thu Aug 01 16:26:03.108 2013] No apache MPM package installed

[Thu Aug 01 16:26:04.324 2013] 

[Thu Aug 01 16:26:04.324 2013] Ubuntu 13.04 arm ttyO0

Can we solve this problem somehow?

We will do further tests...

[Robert Nelson]

On Thu, Aug 1, 2013 at 9:45 AM, <duckhunt...@gmail.com> wrote:
> Hi Gerald,
>
> we have now a log file. The only things connected to the BBB is the power
> supply, the serial debug FTDI and an ethernet cable. One issue we found is
> the following (PHY not found (line 39)):

That's a little weird, normally you should see, it found on "libphy:
4a101000.mdio:00"

aka:

[ 14.744103] net eth0: initializing cpsw version 1.12 (0)
[ 14.752987] net eth0: phy found : id is : 0x7c0f1
[ 14.758338] libphy: PHY 4a101000.mdio:01 not found
[ 14.763419] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 14.776166] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 14.933683] Installing knfsd (copyright (C) 1996 ok...@monad.swb.de).
[ 17.830099] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[ 17.836958] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

do you have the Ethernet cable plugged in?

if ethernet is working, can you try the latest kernel release?

wget http://rcn-ee.net/deb/raring-armhf/v3.8.13-bone24/install-me.sh
sudo /bin/bash install-me.sh

The current kernel will be backed up as "*_bak" in /boot/uboot/

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Gerald Coley]

Well, the board is most definitely running, so I don't see this as a power up issues.There may be a timing issues somewhere however.

Gerald

[duckhunt...@gmail.com]

Well actually most of the time everything is working. I will try it with the new kernel.

A normal start looks as follows:

[Thu Aug 01 16:09:05.277 2013] 

[Thu Aug 01 16:09:05.277 2013] U-Boot SPL 2013.04-00017-g5c4fa11 (May 03 2013 - 10:48:32)

[Thu Aug 01 16:09:05.389 2013] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)

[Thu Aug 01 16:09:05.443 2013] musb-hdrc: MHDRC RTL version 2.0 

[Thu Aug 01 16:09:05.443 2013] musb-hdrc: setup fifo_mode 4

[Thu Aug 01 16:09:05.444 2013] musb-hdrc: 28/31 max ep, 16384/16384 memory

[Thu Aug 01 16:09:05.444 2013] USB Peripheral mode controller at 47401000 using PIO, IRQ 0

[Thu Aug 01 16:09:05.444 2013] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)

[Thu Aug 01 16:09:05.445 2013] musb-hdrc: MHDRC RTL version 2.0 

[Thu Aug 01 16:09:05.445 2013] musb-hdrc: setup fifo_mode 4

[Thu Aug 01 16:09:05.446 2013] musb-hdrc: 28/31 max ep, 16384/16384 memory

[Thu Aug 01 16:09:05.446 2013] USB Host mode controller at 47401800 using PIO, IRQ 0

[Thu Aug 01 16:09:05.446 2013] OMAP SD/MMC: 0

[Thu Aug 01 16:09:06.434 2013] mmc_send_cmd : timeout: No status update

[Thu Aug 01 16:09:06.498 2013] reading u-boot.img

[Thu Aug 01 16:09:06.498 2013] reading u-boot.img

[Thu Aug 01 16:09:06.558 2013] 

[Thu Aug 01 16:09:06.558 2013] 

[Thu Aug 01 16:09:06.558 2013] U-Boot 2013.04-00017-g5c4fa11 (May 03 2013 - 10:48:32)

[Thu Aug 01 16:09:06.558 2013] 

[Thu Aug 01 16:09:06.558 2013] I2C:   ready

[Thu Aug 01 16:09:06.606 2013] DRAM:  512 MiB

[Thu Aug 01 16:09:07.214 2013] WARNING: Caches not enabled

[Thu Aug 01 16:09:07.726 2013] NAND:  No NAND device found!!!

[Thu Aug 01 16:09:07.981 2013] 0 MiB

[Thu Aug 01 16:09:07.981 2013] MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1

[Thu Aug 01 16:09:07.981 2013] *** Warning - readenv() failed, using default environment

[Thu Aug 01 16:09:07.982 2013] 

[Thu Aug 01 16:09:08.766 2013] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)

[Thu Aug 01 16:09:08.766 2013] musb-hdrc: MHDRC RTL version 2.0 

[Thu Aug 01 16:09:08.766 2013] musb-hdrc: setup fifo_mode 4

[Thu Aug 01 16:09:08.766 2013] musb-hdrc: 28/31 max ep, 16384/16384 memory

[Thu Aug 01 16:09:08.767 2013] USB Peripheral mode controller at 47401000 using PIO, IRQ 0

[Thu Aug 01 16:09:08.767 2013] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)

[Thu Aug 01 16:09:08.767 2013] musb-hdrc: MHDRC RTL version 2.0 

[Thu Aug 01 16:09:08.767 2013] musb-hdrc: setup fifo_mode 4

[Thu Aug 01 16:09:08.767 2013] musb-hdrc: 28/31 max ep, 16384/16384 memory

[Thu Aug 01 16:09:08.767 2013] USB Host mode controller at 47401800 using PIO, IRQ 0

[Thu Aug 01 16:09:08.767 2013] Net:   <ethaddr> not set. Validating first E-fuse MAC

[Thu Aug 01 16:09:08.782 2013] cpsw, usb_ether

[Thu Aug 01 16:09:08.782 2013] Hit any key to stop autoboot:  1  0 

[Thu Aug 01 16:09:09.806 2013] gpio: pin 53 (gpio 53) value is 1

[Thu Aug 01 16:09:10.858 2013] mmc_send_cmd : timeout: No status update

[Thu Aug 01 16:09:10.858 2013] Card did not respond to voltage select!

[Thu Aug 01 16:09:10.858 2013] mmc0(part 0) is current device

[Thu Aug 01 16:09:10.858 2013] Card did not respond to voltage select!

[Thu Aug 01 16:09:11.849 2013] mmc_send_cmd : timeout: No status update

[Thu Aug 01 16:09:11.913 2013] mmc1(part 0) is current device

[Thu Aug 01 16:09:11.961 2013] gpio: pin 54 (gpio 54) value is 1

[Thu Aug 01 16:09:11.961 2013] SD/MMC found on device 1

[Thu Aug 01 16:09:12.010 2013] reading uEnv.txt

[Thu Aug 01 16:09:12.010 2013] 1314 bytes read in 5 ms (255.9 KiB/s)

[Thu Aug 01 16:09:12.010 2013] Importing environment from mmc ...

[Thu Aug 01 16:09:12.010 2013] gpio: pin 55 (gpio 55) value is 1

[Thu Aug 01 16:09:12.011 2013] gpio: pin 56 (gpio 56) value is 1

[Thu Aug 01 16:09:12.011 2013] Running uenvcmd ...

[Thu Aug 01 16:09:12.011 2013] reading zImage

[Thu Aug 01 16:09:12.378 2013] 3252888 bytes read in 373 ms (8.3 MiB/s)

[Thu Aug 01 16:09:12.378 2013] reading uInitrd

[Thu Aug 01 16:09:12.712 2013] 2709355 bytes read in 312 ms (8.3 MiB/s)

[Thu Aug 01 16:09:12.712 2013] reading /dtbs/am335x-boneblack.dtb

[Thu Aug 01 16:09:12.712 2013] 24125 bytes read in 9 ms (2.6 MiB/s)

[Thu Aug 01 16:09:12.763 2013] ## Loading init Ramdisk from Legacy Image at 81000000 ...

[Thu Aug 01 16:09:12.763 2013]    Image Name:   initramfs

[Thu Aug 01 16:09:12.763 2013]    Image Type:   ARM Linux RAMDisk Image (uncompressed)

[Thu Aug 01 16:09:12.763 2013]    Data Size:    2709291 Bytes = 2.6 MiB

[Thu Aug 01 16:09:12.764 2013]    Load Address: 00000000

[Thu Aug 01 16:09:12.764 2013]    Entry Point:  00000000

[Thu Aug 01 16:09:12.764 2013] ## Flattened Device Tree blob at 815f0000

[Thu Aug 01 16:09:12.764 2013]    Booting using the fdt blob at 0x815f0000

[Thu Aug 01 16:09:12.764 2013]    Using Device Tree in place at 815f0000, end 815f8e3c

[Thu Aug 01 16:09:12.811 2013] 

[Thu Aug 01 16:09:12.811 2013] Starting kernel ...

[Thu Aug 01 16:09:12.811 2013] 

[Thu Aug 01 16:09:12.827 2013] Uncompressing Linux... done, booting the kernel.

[Thu Aug 01 16:09:16.808 2013] [    0.000000] Booting Linux on physical CPU 0x0

[Thu Aug 01 16:09:16.808 2013] [    0.000000] Initializing cgroup subsys cpu

[Thu Aug 01 16:09:16.808 2013] [    0.000000] Linux version 3.8.13-bone21 (root@imx6q-sabrelite-1gb-0) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #1 SMP Fri Jun 14 03:10:29 UTC 2013

[Thu Aug 01 16:09:16.809 2013] [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d

[Thu Aug 01 16:09:16.809 2013] [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[Thu Aug 01 16:09:16.809 2013] [    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone

[Thu Aug 01 16:09:16.809 2013] [    0.000000] Memory policy: ECC disabled, Data cache writeback

[Thu Aug 01 16:09:16.809 2013] [    0.000000] AM335X ES1.0 (neon )

[Thu Aug 01 16:09:16.809 2013] [    0.000000] PERCPU: Embedded 9 pages/cpu @c0df4000 s14080 r8192 d14592 u36864

[Thu Aug 01 16:09:16.810 2013] [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129792

[Thu Aug 01 16:09:16.810 2013] [    0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc ip=

[Thu Aug 01 16:09:16.810 2013] [    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)

[Thu Aug 01 16:09:16.810 2013] [    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)

[Thu Aug 01 16:09:16.813 2013] [    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)

[Thu Aug 01 16:09:16.813 2013] [    0.000000] __ex_table already sorted, skipping sort

[Thu Aug 01 16:09:16.814 2013] [    0.000000] allocated 1048576 bytes of page_cgroup

[Thu Aug 01 16:09:16.814 2013] [    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups

[Thu Aug 01 16:09:16.814 2013] [    0.000000] Memory: 511MB = 511MB total

[Thu Aug 01 16:09:16.814 2013] [    0.000000] Memory: 504832k/504832k available, 19456k reserved, 0K highmem

[Thu Aug 01 16:09:16.814 2013] [    0.000000] Virtual kernel memory layout:

[Thu Aug 01 16:09:16.814 2013] [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)

[Thu Aug 01 16:09:16.814 2013] [    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

[Thu Aug 01 16:09:16.815 2013] [    0.000000]     vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)

[Thu Aug 01 16:09:16.815 2013] [    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)

[Thu Aug 01 16:09:16.815 2013] [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)

[Thu Aug 01 16:09:16.815 2013] [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)

[Thu Aug 01 16:09:16.815 2013] [    0.000000]       .text : 0xc0008000 - 0xc08a3248   (8813 kB)

[Thu Aug 01 16:09:16.815 2013] [    0.000000]       .init : 0xc08a4000 - 0xc08ec700   ( 290 kB)

[Thu Aug 01 16:09:16.818 2013] [    0.000000]       .data : 0xc08ee000 - 0xc096e970   ( 515 kB)

[Thu Aug 01 16:09:16.818 2013] [    0.000000]        .bss : 0xc096e970 - 0xc09e49fc   ( 473 kB)

[Thu Aug 01 16:09:16.818 2013] [    0.000000] Hierarchical RCU implementation.

[Thu Aug 01 16:09:16.819 2013] [    0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.

[Thu Aug 01 16:09:16.819 2013] [    0.000000] NR_IRQS:16 nr_irqs:16 16

[Thu Aug 01 16:09:16.819 2013] [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts

[Thu Aug 01 16:09:16.819 2013] [    0.000000] Total of 128 interrupts on 1 active controller

[Thu Aug 01 16:09:16.819 2013] [    0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz

[Thu Aug 01 16:09:16.819 2013] [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms

[Thu Aug 01 16:09:16.820 2013] [    0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz

[Thu Aug 01 16:09:16.820 2013] [    0.000000] Console: colour dummy device 80x30

[Thu Aug 01 16:09:16.820 2013] [    0.000388] Calibrating delay loop... 363.67 BogoMIPS (lpj=354304)

[Thu Aug 01 16:09:16.820 2013] [    0.017383] pid_max: default: 32768 minimum: 301

[Thu Aug 01 16:09:16.820 2013] [    0.017632] Security Framework initialized

[Thu Aug 01 16:09:16.820 2013] [    0.017733] Mount-cache hash table entries: 512

[Thu Aug 01 16:09:16.820 2013] [    0.027567] Initializing cgroup subsys cpuacct

[Thu Aug 01 16:09:16.820 2013] [    0.027606] Initializing cgroup subsys memory

[Thu Aug 01 16:09:16.822 2013] [    0.027676] Initializing cgroup subsys blkio

[Thu Aug 01 16:09:16.823 2013] [    0.027829] CPU: Testing write buffer coherency: ok

[Thu Aug 01 16:09:16.823 2013] [    0.028425] CPU0: thread -1, cpu 0, socket -1, mpidr 0

[Thu Aug 01 16:09:16.823 2013] [    0.028505] Setting up static identity map for 0x805f2c70 - 0x805f2cc8

[Thu Aug 01 16:09:16.823 2013] [    0.030191] Brought up 1 CPUs

[Thu Aug 01 16:09:16.823 2013] [    0.030216] SMP: Total of 1 processors activated (363.67 BogoMIPS).

[Thu Aug 01 16:09:16.823 2013] [    0.031655] devtmpfs: initialized

[Thu Aug 01 16:09:16.823 2013] [    0.096773] pinctrl core: initialized pinctrl subsystem

[Thu Aug 01 16:09:16.823 2013] [    0.097014] rstctl core: initialized rstctl subsystem

[Thu Aug 01 16:09:16.824 2013] [    0.097595] regulator-dummy: no parameters

[Thu Aug 01 16:09:16.824 2013] [    0.098159] NET: Registered protocol family 16

[Thu Aug 01 16:09:16.824 2013] [    0.099070] DMA: preallocated 256 KiB pool for atomic coherent allocations

[Thu Aug 01 16:09:16.824 2013] [    0.109043] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568

[Thu Aug 01 16:09:16.824 2013] [    0.109884] platform 49000000.edma: alias fck already exists

[Thu Aug 01 16:09:16.824 2013] [    0.109915] platform 49000000.edma: alias fck already exists

[Thu Aug 01 16:09:16.825 2013] [    0.109941] platform 49000000.edma: alias fck already exists

[Thu Aug 01 16:09:17.171 2013] [    0.111325] OMAP GPIO hardware version 0.1

[Thu Aug 01 16:09:17.171 2013] [    0.116238] gpio-rctrl rstctl.3: loaded OK

[Thu Aug 01 16:09:17.171 2013] [    0.121615] hw-breakpoint: debug architecture 0x4 unsupported.

[Thu Aug 01 16:09:17.172 2013] [    0.123799] cpsw.0: No hwaddr in dt. Using 90:59:af:54:40:30 from efuse

[Thu Aug 01 16:09:17.172 2013] [    0.123834] cpsw.1: No hwaddr in dt. Using 90:59:af:54:40:32 from efuse

[Thu Aug 01 16:09:17.172 2013] [    0.137684] bio: create slab <bio-0> at 0

[Thu Aug 01 16:09:17.172 2013] [    0.149357] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver

[Thu Aug 01 16:09:17.172 2013] [    0.149818] vmmcsd_fixed: 3300 mV 

[Thu Aug 01 16:09:17.172 2013] [    0.152668] SCSI subsystem initialized

[Thu Aug 01 16:09:17.172 2013] [    0.153086] usbcore: registered new interface driver usbfs

[Thu Aug 01 16:09:17.173 2013] [    0.153219] usbcore: registered new interface driver hub

[Thu Aug 01 16:09:17.173 2013] [    0.153544] usbcore: registered new device driver usb

[Thu Aug 01 16:09:17.173 2013] [    0.155651] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz

[Thu Aug 01 16:09:17.173 2013] [    0.157251] input: tps65217_pwr_but as /devices/ocp.2/44e0b000.i2c/i2c-0/0-0024/input/input0

[Thu Aug 01 16:09:17.173 2013] [    0.159560] DCDC1: at 1500 mV 

[Thu Aug 01 16:09:17.173 2013] [    0.160865] vdd_mpu: 925 <--> 1325 mV at 1100 mV 

[Thu Aug 01 16:09:17.173 2013] [    0.162088] vdd_core: 925 <--> 1150 mV at 1100 mV 

[Thu Aug 01 16:09:17.176 2013] [    0.163231] LDO1: at 1800 mV 

[Thu Aug 01 16:09:17.176 2013] [    0.164374] LDO2: at 3300 mV 

[Thu Aug 01 16:09:17.176 2013] [    0.166369] LDO3: 1800 mV 

[Thu Aug 01 16:09:17.176 2013] [    0.167509] LDO4: at 3300 mV 

[Thu Aug 01 16:09:17.176 2013] [    0.168566] tps65217 0-0024: TPS65217 ID 0xe version 1.2

[Thu Aug 01 16:09:17.177 2013] [    0.169353] omap_i2c 44e0b000.i2c: unable to select pin group

[Thu Aug 01 16:09:17.177 2013] [    0.170224] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz

[Thu Aug 01 16:09:17.177 2013] [    0.172770] omap_i2c 4819c000.i2c: unable to select pin group

[Thu Aug 01 16:09:17.177 2013] [    0.173001] media: Linux media interface: v0.10

[Thu Aug 01 16:09:17.177 2013] [    0.173106] Linux video capture interface: v2.00

[Thu Aug 01 16:09:17.177 2013] [    0.173974] Advanced Linux Sound Architecture Driver Initialized.

[Thu Aug 01 16:09:17.177 2013] [    0.174976] NetLabel: Initializing

[Thu Aug 01 16:09:17.178 2013] [    0.174996] NetLabel:  domain hash size = 128

[Thu Aug 01 16:09:17.178 2013] [    0.175008] NetLabel:  protocols = UNLABELED CIPSOv4

[Thu Aug 01 16:09:17.178 2013] [    0.175123] NetLabel:  unlabeled traffic allowed by default

[Thu Aug 01 16:09:17.178 2013] [    0.175462] Switching to clocksource gp_timer

[Thu Aug 01 16:09:17.178 2013] [    0.229933] NET: Registered protocol family 2

[Thu Aug 01 16:09:17.178 2013] [    0.231147] TCP established hash table entries: 4096 (order: 3, 32768 bytes)

[Thu Aug 01 16:09:17.178 2013] [    0.231293] TCP bind hash table entries: 4096 (order: 4, 81920 bytes)

[Thu Aug 01 16:09:17.181 2013] [    0.231454] TCP: Hash tables configured (established 4096 bind 4096)

[Thu Aug 01 16:09:17.181 2013] [    0.231557] TCP: reno registered

[Thu Aug 01 16:09:17.181 2013] [    0.231583] UDP hash table entries: 256 (order: 1, 12288 bytes)

[Thu Aug 01 16:09:17.182 2013] [    0.231629] UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)

[Thu Aug 01 16:09:17.182 2013] [    0.232068] NET: Registered protocol family 1

[Thu Aug 01 16:09:17.182 2013] [    0.232799] RPC: Registered named UNIX socket transport module.

[Thu Aug 01 16:09:17.182 2013] [    0.232826] RPC: Registered udp transport module.

[Thu Aug 01 16:09:17.182 2013] [    0.232839] RPC: Registered tcp transport module.

[Thu Aug 01 16:09:17.182 2013] [    0.232852] RPC: Registered tcp NFSv4.1 backchannel transport module.

[Thu Aug 01 16:09:17.183 2013] [    0.233273] Trying to unpack rootfs image as initramfs...

[Thu Aug 01 16:09:17.183 2013] [    0.544042] Freeing initrd memory: 2644K

[Thu Aug 01 16:09:17.183 2013] [    0.544932] CPU PMU: probing PMU on CPU 0

[Thu Aug 01 16:09:17.183 2013] [    0.544969] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available

[Thu Aug 01 16:09:17.183 2013] [    0.545528] omap2_mbox_probe: platform not supported

[Thu Aug 01 16:09:17.183 2013] [    0.814419] VFS: Disk quotas dquot_6.5.2

[Thu Aug 01 16:09:17.183 2013] [    0.814683] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

[Thu Aug 01 16:09:17.185 2013] [    0.815952] NFS: Registering the id_resolver key type

[Thu Aug 01 16:09:17.186 2013] [    0.816064] Key type id_resolver registered

[Thu Aug 01 16:09:17.186 2013] [    0.816082] Key type id_legacy registered

[Thu Aug 01 16:09:17.186 2013] [    0.816273] fuse init (API version 7.20)

[Thu Aug 01 16:09:17.186 2013] [    0.817200] Btrfs loaded

[Thu Aug 01 16:09:17.186 2013] [    0.817376] msgmni has been set to 991

[Thu Aug 01 16:09:17.186 2013] [    0.820549] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)

[Thu Aug 01 16:09:17.186 2013] [    0.820581] io scheduler noop registered

[Thu Aug 01 16:09:17.186 2013] [    0.820597] io scheduler deadline registered

[Thu Aug 01 16:09:17.186 2013] [    0.820648] io scheduler cfq registered (default)

[Thu Aug 01 16:09:17.187 2013] [    0.822540] tps65217-bl tps65217-bl: no platform data provided

[Thu Aug 01 16:09:17.187 2013] [    0.822586] tps65217-bl: probe of tps65217-bl failed with error -22

[Thu Aug 01 16:09:17.187 2013] [    0.823431] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled

[Thu Aug 01 16:09:17.187 2013] [    0.826167] omap_uart 44e09000.serial: did not get pins for uart0 error: -19

[Thu Aug 01 16:09:17.187 2013] [    0.826489] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0

[Thu Aug 01 16:09:17.187 2013] [    1.548116] console [ttyO0] enabled

[Thu Aug 01 16:09:17.192 2013] [    1.552897] [drm] Initialized drm 1.1.0 20060810

[Thu Aug 01 16:09:17.192 2013] [    1.571417] brd: module loaded

[Thu Aug 01 16:09:17.273 2013] [    1.581640] loop: module loaded

[Thu Aug 01 16:09:17.273 2013] [    1.585118] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[Thu Aug 01 16:09:17.273 2013] [    1.592422] at24 1-0054: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[Thu Aug 01 16:09:17.273 2013] [    1.599710] at24 1-0055: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[Thu Aug 01 16:09:17.274 2013] [    1.606994] at24 1-0056: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[Thu Aug 01 16:09:17.274 2013] [    1.614291] at24 1-0057: 32768 byte 24c256 EEPROM, writable, 1 bytes/write

[Thu Aug 01 16:09:17.274 2013] [    1.628335] bone-capemgr bone_capemgr.9: Baseboard: 'A335BNLT,0A5C,2513BBBK3061'

[Thu Aug 01 16:09:17.274 2013] [    1.636140] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,beaglebone-black

[Thu Aug 01 16:09:17.312 2013] [    1.671688] bone-capemgr bone_capemgr.9: slot #0: No cape found

[Thu Aug 01 16:09:17.327 2013] [    1.708793] bone-capemgr bone_capemgr.9: slot #1: No cape found

[Thu Aug 01 16:09:17.364 2013] [    1.745903] bone-capemgr bone_capemgr.9: slot #2: No cape found

[Thu Aug 01 16:09:17.401 2013] [    1.783012] bone-capemgr bone_capemgr.9: slot #3: No cape found

[Thu Aug 01 16:09:17.780 2013] [    1.789278] bone-capemgr bone_capemgr.9: slot #4: specific override

[Thu Aug 01 16:09:17.780 2013] [    1.795891] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4

[Thu Aug 01 16:09:17.781 2013] [    1.803940] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'

[Thu Aug 01 16:09:17.781 2013] [    1.814094] bone-capemgr bone_capemgr.9: slot #5: specific override

[Thu Aug 01 16:09:17.781 2013] [    1.820702] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 5

[Thu Aug 01 16:09:17.781 2013] [    1.828749] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'

[Thu Aug 01 16:09:17.781 2013] [    1.838801] bone-capemgr bone_capemgr.9: slot #6: specific override

[Thu Aug 01 16:09:17.782 2013] [    1.845407] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 6

[Thu Aug 01 16:09:17.782 2013] [    1.853455] bone-capemgr bone_capemgr.9: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'

[Thu Aug 01 16:09:17.782 2013] [    1.864123] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[Thu Aug 01 16:09:17.782 2013] [    1.873013] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[Thu Aug 01 16:09:17.785 2013] [    1.881913] bone-capemgr bone_capemgr.9: loader: before slot-5 BB-BONELT-HDMI:00A0 (prio 1)

[Thu Aug 01 16:09:17.785 2013] [    1.890696] bone-capemgr bone_capemgr.9: loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1)

[Thu Aug 01 16:09:17.786 2013] [    1.899413] bone-capemgr bone_capemgr.9: initialized OK.

[Thu Aug 01 16:09:17.786 2013] [    1.905021] bone-capemgr bone_capemgr.9: loader: before slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:09:17.786 2013] [    1.913883] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:09:17.786 2013] [    1.924650] OneNAND driver initializing

[Thu Aug 01 16:09:17.786 2013] [    1.930082] usbcore: registered new interface driver cdc_ether

[Thu Aug 01 16:09:17.786 2013] [    1.936275] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[Thu Aug 01 16:09:17.787 2013] [    1.945066] bone-capemgr bone_capemgr.9: loader: after slot-5 BB-BONELT-HDMI:00A0 (prio 1)

[Thu Aug 01 16:09:17.787 2013] [    1.953834] usbcore: registered new interface driver rndis_host

[Thu Aug 01 16:09:17.787 2013] [    1.960150] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:09:17.787 2013] [    1.969044] usbcore: registered new interface driver cdc_ncm

[Thu Aug 01 16:09:17.790 2013] [    1.975035] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'

[Thu Aug 01 16:09:17.790 2013] [    1.989372] Initializing USB Mass Storage driver...

[Thu Aug 01 16:09:17.791 2013] [    1.994669] usbcore: registered new interface driver usb-storage

[Thu Aug 01 16:09:17.791 2013] [    2.000990] USB Mass Storage support registered.

[Thu Aug 01 16:09:17.791 2013] [    2.006166] bone-capemgr bone_capemgr.9: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree

[Thu Aug 01 16:09:17.791 2013] [    2.016938] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 'cape-boneblack-hdmi-00A0.dtbo' for board-name 'Bone-Black-HDMI', version '00A0'

[Thu Aug 01 16:09:17.791 2013] [    2.031281] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)

[Thu Aug 01 16:09:17.792 2013] [    2.037937] bone-capemgr bone_capemgr.9: slot #4: #2 overlays

[Thu Aug 01 16:09:17.792 2013] [    2.044403] musb-hdrc musb-hdrc.0.auto: pdev->id = 0

[Thu Aug 01 16:09:17.792 2013] [    2.049668] musb-hdrc musb-hdrc.0.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK

[Thu Aug 01 16:09:17.792 2013] [    2.058742] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.

[Thu Aug 01 16:09:17.792 2013] [    2.065630] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

[Thu Aug 01 16:09:17.794 2013] [    2.074348] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:09:17.795 2013] [    2.083147] bone-capemgr bone_capemgr.9: slot #5: dtbo 'cape-boneblack-hdmi-00A0.dtbo' loaded; converting to live tree

[Thu Aug 01 16:09:17.795 2013] [    2.094666] musb-hdrc musb-hdrc.0.auto: *** mode=3

[Thu Aug 01 16:09:17.795 2013] [    2.099735] musb-hdrc musb-hdrc.0.auto: *** power=250

[Thu Aug 01 16:09:17.795 2013] [    2.106123] bone-capemgr bone_capemgr.9: slot #5: #4 overlays

[Thu Aug 01 16:09:17.795 2013] [    2.114667] platform 4830e000.fb: alias fck already exists

[Thu Aug 01 16:09:17.795 2013] [    2.121448] musb-hdrc musb-hdrc.1.auto: pdev->id = 1

[Thu Aug 01 16:09:17.796 2013] [    2.126773] musb-hdrc musb-hdrc.1.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK

[Thu Aug 01 16:09:17.796 2013] [    2.135803] musb-hdrc musb-hdrc.1.auto: *** mode=1

[Thu Aug 01 16:09:17.796 2013] [    2.140885] musb-hdrc musb-hdrc.1.auto: *** power=250

[Thu Aug 01 16:09:17.796 2013] [    2.146205] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver

[Thu Aug 01 16:09:17.796 2013] [    2.153884] bone-capemgr bone_capemgr.9: slot #5: Applied #4 overlays.

[Thu Aug 01 16:09:18.018 2013] [    2.160811] bone-capemgr bone_capemgr.9: loader: done slot-5 BB-BONELT-HDMI:00A0 (prio 1)

[Thu Aug 01 16:09:18.018 2013] [    2.169448] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:09:18.019 2013] [    2.178640] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1

[Thu Aug 01 16:09:18.019 2013] [    2.186933] bone-capemgr bone_capemgr.9: loader: after slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:09:18.019 2013] [    2.195960] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002

[Thu Aug 01 16:09:18.019 2013] [    2.203112] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1

[Thu Aug 01 16:09:18.019 2013] [    2.210715] usb usb1: Product: MUSB HDRC host driver

[Thu Aug 01 16:09:18.019 2013] [    2.215941] usb usb1: Manufacturer: Linux 3.8.13-bone21 musb-hcd

[Thu Aug 01 16:09:18.020 2013] [    2.222255] usb usb1: SerialNumber: musb-hdrc.1.auto

[Thu Aug 01 16:09:18.020 2013] [    2.227545] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version '00A0'

[Thu Aug 01 16:09:18.020 2013] [    2.242073] bone-capemgr bone_capemgr.9: slot #6: dtbo 'cape-boneblack-hdmin-00A0.dtbo' loaded; converting to live tree

[Thu Aug 01 16:09:18.020 2013] [    2.254912] hub 1-0:1.0: USB hub found

[Thu Aug 01 16:09:18.023 2013] [    2.259096] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#5:BB-BONELT-HDMI)

[Thu Aug 01 16:09:18.023 2013] [    2.268717] bone-capemgr bone_capemgr.9: slot #6: Failed verification

[Thu Aug 01 16:09:18.024 2013] [    2.275494] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB-BONELT-HDMIN:00A0 (prio 2)

[Thu Aug 01 16:09:18.024 2013] [    2.285132] hub 1-0:1.0: 1 port detected

[Thu Aug 01 16:09:18.024 2013] [    2.291015] mousedev: PS/2 mouse device common for all mice

[Thu Aug 01 16:09:18.024 2013] [    2.299357] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0

[Thu Aug 01 16:09:18.024 2013] [    2.307218] i2c /dev entries driver

[Thu Aug 01 16:09:18.024 2013] [    2.312381] Driver for 1-wire Dallas network protocol.

[Thu Aug 01 16:09:18.024 2013] [    2.319402] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec

[Thu Aug 01 16:09:18.025 2013] [    2.327026] cpuidle: using governor ladder

[Thu Aug 01 16:09:18.025 2013] [    2.331367] cpuidle: using governor menu

[Thu Aug 01 16:09:18.025 2013] [    2.335995] omap_hsmmc mmc.4: of_parse_phandle_with_args of 'reset' failed

[Thu Aug 01 16:09:18.025 2013] [    2.343247] omap_hsmmc mmc.4: Failed to get rstctl; not using any

[Thu Aug 01 16:09:18.025 2013] [    2.349688] omap_hsmmc mmc.4: unable to select pin group

[Thu Aug 01 16:09:18.025 2013] [    2.355571] edma-dma-engine edma-dma-engine.0: allocated channel for 0:25

[Thu Aug 01 16:09:18.027 2013] [    2.362798] edma-dma-engine edma-dma-engine.0: allocated channel for 0:24

[Thu Aug 01 16:09:18.027 2013] [    2.370156] mmc.4 supply vmmc_aux not found, using dummy regulator

[Thu Aug 01 16:09:18.027 2013] [    2.376834] omap_hsmmc mmc.4: pins are not configured from the driver

[Thu Aug 01 16:09:18.032 2013] [    2.410242] gpio-rctrl rstctl.3: gpio_rctrl_request eMMC_RSTn

[Thu Aug 01 16:09:18.090 2013] [    2.416478] omap_hsmmc mmc.5: Got rstctl (gpio:#0 name eMMC_RSTn) label:eMMC_RSTn

[Thu Aug 01 16:09:18.090 2013] [    2.424400] gpio-rctrl rstctl.3: gpio_rctrl_deassert eMMC_RSTn

[Thu Aug 01 16:09:18.090 2013] [    2.430885] edma-dma-engine edma-dma-engine.0: allocated channel for 0:3

[Thu Aug 01 16:09:18.090 2013] [    2.438071] edma-dma-engine edma-dma-engine.0: allocated channel for 0:2

[Thu Aug 01 16:09:18.090 2013] [    2.445671] mmc.5 supply vmmc_aux not found, using dummy regulator

[Thu Aug 01 16:09:18.091 2013] [    2.452363] omap_hsmmc mmc.5: pins are not configured from the driver

[Thu Aug 01 16:09:18.105 2013] [    2.486733] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8

[Thu Aug 01 16:09:18.356 2013] [    2.498491] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22

[Thu Aug 01 16:09:18.357 2013] [    2.505809] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single

[Thu Aug 01 16:09:18.357 2013] [    2.514811] leds-gpio gpio-leds.8: pins are not configured from the driver

[Thu Aug 01 16:09:18.357 2013] [    2.523181] ledtrig-cpu: registered to indicate activity on CPUs

[Thu Aug 01 16:09:18.357 2013] [    2.530062] edma-dma-engine edma-dma-engine.0: allocated channel for 0:36

[Thu Aug 01 16:09:18.357 2013] [    2.537364] omap-sham 53100000.sham: hw accel on OMAP rev 4.3

[Thu Aug 01 16:09:18.357 2013] [    2.546186] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2

[Thu Aug 01 16:09:18.358 2013] [    2.552721] edma-dma-engine edma-dma-engine.0: allocated channel for 0:5

[Thu Aug 01 16:09:18.358 2013] [    2.559900] edma-dma-engine edma-dma-engine.0: allocated channel for 0:6

[Thu Aug 01 16:09:18.358 2013] [    2.568396] usbcore: registered new interface driver usbhid

[Thu Aug 01 16:09:18.358 2013] [    2.574285] usbhid: USB HID core driver

[Thu Aug 01 16:09:18.358 2013] [    2.582794] davinci_evm sound.13:  nxp-hdmi-hifi <-> 48038000.mcasp mapping ok

[Thu Aug 01 16:09:18.358 2013] [    2.594490] TCP: cubic registered

[Thu Aug 01 16:09:18.361 2013] [    2.598140] NET: Registered protocol family 10

[Thu Aug 01 16:09:18.361 2013] [    2.604161] NET: Registered protocol family 17

[Thu Aug 01 16:09:18.361 2013] [    2.609453] Key type dns_resolver registered

[Thu Aug 01 16:09:18.362 2013] [    2.614299] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3

[Thu Aug 01 16:09:18.362 2013] [    2.622496] ThumbEE CPU extension supported.

[Thu Aug 01 16:09:18.362 2013] [    2.627074] Registering SWP/SWPB emulation handler

[Thu Aug 01 16:09:18.362 2013] [    2.633428] registered taskstats version 1

[Thu Aug 01 16:09:18.362 2013] [    2.638556] slave hdmi.12: modes-blacklisted #0 -> 1920x1080@25

[Thu Aug 01 16:09:18.362 2013] [    2.644886] mmc1: BKOPS_EN bit is not set

[Thu Aug 01 16:09:18.362 2013] [    2.649159] slave hdmi.12: modes-blacklisted #1 -> 832x624@75

[Thu Aug 01 16:09:18.362 2013] [    2.657188] tilcdc 4830e000.fb: No power control GPIO

[Thu Aug 01 16:09:18.363 2013] [    2.663738] mmc1: new high speed MMC card at address 0001

[Thu Aug 01 16:09:18.363 2013] [    2.677748] mmcblk0: mmc1:0001 MMC02G 1.78 GiB 

[Thu Aug 01 16:09:18.363 2013] [    2.688087] mmcblk0boot0: mmc1:0001 MMC02G partition 1 1.00 MiB

[Thu Aug 01 16:09:18.363 2013] [    2.694805] mmcblk0boot1: mmc1:0001 MMC02G partition 2 1.00 MiB

[Thu Aug 01 16:09:18.363 2013] [    2.703550]  mmcblk0: p1 p2

[Thu Aug 01 16:09:18.363 2013] [    2.709583]  mmcblk0boot1: unknown partition table

[Thu Aug 01 16:09:18.363 2013] [    2.716851]  mmcblk0boot0: unknown partition table

[Thu Aug 01 16:09:18.418 2013] [    2.795879] tilcdc 4830e000.fb: found TDA19988

[Thu Aug 01 16:09:18.459 2013] [    2.801380] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).

[Thu Aug 01 16:09:18.459 2013] [    2.808371] [drm] No driver support for vblank timestamp query.

[Thu Aug 01 16:09:18.459 2013] [    2.815047] tilcdc 4830e000.fb: No connectors reported connected with modes

[Thu Aug 01 16:09:18.459 2013] [    2.822468] [drm] Cannot find any crtc or sizes - going 1024x768

[Thu Aug 01 16:09:18.474 2013] [    2.843239] Console: switching to colour frame buffer device 128x48

[Thu Aug 01 16:09:18.508 2013] [    2.859336] tilcdc 4830e000.fb: fb0:  frame buffer device

[Thu Aug 01 16:09:18.508 2013] [    2.865019] tilcdc 4830e000.fb: registered panic notifier

[Thu Aug 01 16:09:18.508 2013] [    2.870720] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0

[Thu Aug 01 16:09:18.573 2013] [    2.927575] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6

[Thu Aug 01 16:09:18.573 2013] [    2.934013] davinci_mdio 4a101000.mdio: detected phy mask fffffffe

[Thu Aug 01 16:09:18.573 2013] [    2.951858] libphy: 4a101000.mdio: probed

[Thu Aug 01 16:09:18.635 2013] [    2.956194] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720

[Thu Aug 01 16:09:18.635 2013] [    2.966096] Detected MACID = 90:59:af:54:40:30

[Thu Aug 01 16:09:18.635 2013] [    2.970840] cpsw 4a100000.ethernet: NAPI disabled

[Thu Aug 01 16:09:18.635 2013] [    2.977947] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:00:01 UTC (946684801)

[Thu Aug 01 16:09:18.635 2013] [    2.990453] ALSA device list:

[Thu Aug 01 16:09:18.635 2013] [    2.993613]   #0: TI BeagleBone Black

[Thu Aug 01 16:09:18.636 2013] [    2.998264] Freeing init memory: 288K

[Thu Aug 01 16:09:18.651 2013] Loading, please wait...

[Thu Aug 01 16:09:18.714 2013] [    3.093364] udevd[101]: starting version 175

[Thu Aug 01 16:09:18.745 2013] Begin: Loading essential drivers ... done.

[Thu Aug 01 16:09:18.745 2013] Begin: Running /scripts/init-premount ... done.

[Thu Aug 01 16:09:18.760 2013] Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.

[Thu Aug 01 16:09:19.400 2013] Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems

[Thu Aug 01 16:09:20.521 2013] done.

[Thu Aug 01 16:09:20.537 2013] [    4.916274] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem

[Thu Aug 01 16:09:20.564 2013] [    4.923996] EXT4-fs (mmcblk0p2): write access will be enabled during recovery

[Thu Aug 01 16:09:21.347 2013] [    5.728182] EXT4-fs (mmcblk0p2): recovery complete

[Thu Aug 01 16:09:21.385 2013] [    5.737140] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)

[Thu Aug 01 16:09:21.385 2013] Begin: Running /scripts/local-bottom ... done.

[Thu Aug 01 16:09:21.385 2013] done.

[Thu Aug 01 16:09:21.385 2013] Begin: Running /scripts/init-bottom ... done.

[Thu Aug 01 16:09:22.067 2013] [    6.426300] init: ureadahead main process (222) terminated with status 5

[Thu Aug 01 16:09:22.898 2013] [    7.276795] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro

[Thu Aug 01 16:09:25.665 2013] [   10.018024] libphy: PHY 4a101000.mdio:01 not found

[Thu Aug 01 16:09:25.665 2013] [   10.018031] net eth0: phy 4a101000.mdio:01 not found on slave 1

[Thu Aug 01 16:09:30.255 2013]  * Loading cpufreq kernel modules...        [ OK ]

[Thu Aug 01 16:09:31.695 2013]  * Starting virtual private network daemon(s)...         *   Autostart disabled, no VPN will be started.

[Thu Aug 01 16:09:31.808 2013]  * CPUFreq Utilities: Setting ondemand CPUFreq governor...         * CPU0...        [ OK ]

[Thu Aug 01 16:09:31.888 2013] Starting very small Busybox based DHCP server: Starting /usr/sbin/udhcpd...

[Thu Aug 01 16:09:31.941 2013] udhcpd.

[Thu Aug 01 16:09:32.021 2013]  * Starting NTP server ntpd        [ OK ]

[Thu Aug 01 16:09:32.229 2013] No apache MPM package installed

[Thu Aug 01 16:09:33.445 2013] 

[Thu Aug 01 16:09:33.445 2013] Ubuntu 13.04 arm ttyO0

[Thu Aug 01 16:09:33.445 2013] 

[Thu Aug 01 16:09:33.445 2013] arm login:

Regards,

duckhunter

[dennis.c...@gmail.com]

Yes, I checked the Wiki.  The 2A wall wart from Adafruit was purchased because the Wiki pointed at it and said it was a power supply that worked.

So I have three perfectly working boards and one not-working board, and I'm using a power supply recommended by the Wiki.  If that recommendation was in error and there's another one which will work better I'm all ears.

On the other hand, is it not possible that the problem might not always be the power supply but in fact might sometimes be the board?

Dennis Ferguson

[Gerald Coley]

if the power supply works with three boards, then the power supply should be fine.

Every board has tolerances, making each board a little unique. From the printout, the board is working fine. No power supply issue. No boot issue.

The question is why it is hanging where it is hanging.

My suggestion is to request an RMA. They will replace the board so you can go on your way. And then we will look at it and see what the issue might be, assuming we can get it to fail at the factory.

Gerald

'

[duckhunt...@gmail.com]

Interesting ... as soon as i have the connected the FTDI cable everything works fine.... When i disconnect it, I still get a error every 10th-20th try.

Regards

[Gerald Coley]

Sounds like you may have a grounding issue somewhere or a power supply that has no ground connection. Make sure all supplies, PC, board, monitors, etc. all connetc to the same exact power strip.

Gerald

On Mon, Aug 5, 2013 at 3:04 AM, <duckhunt...@gmail.com> wrote:

Interesting ... as soon as i have the connected the FTDI cable everything works fine.... When i disconnect it, I still get a error every 10th-20th try.

Regards

--

[duckhunt...@gmail.com]

I think we've found an issue. As I already mentioned, when an FTDI cable is connected everything works fine. First we thought it could be a grounding problem, but we couldn't found anything. Afterwards we had only the TX and GND signal of the FTDI cable connected, so we could see what the BB sends. We found out, that the BB goes into the U-Boot mode (the mode where you have to hit a key shortly after power up). It seems like that the BB receives something over the RX signal of the FTDI. We think the problem is the pull down resistor of the RX signal. We have changed it to a pull up, since the idle state of the UART is 3.3V, and changed the resistor to 10k instead of 100k. Now everything works fine.

Regards,

duckhunter

[Gerald Coley]

That resistor was added because without the cable connected we were getting noise into the RX line, causing the board to crash.

Gerald

Regards,

duckhunter

--

[duckhunt...@gmail.com]

Yes I know, you are right. But we still get noise into our RX line which causes our board to crash. Maybe it would be better to use a lower resistor value (e.g. 10k) and change it to a pull up resistor to 3V3, since the idle state of the UART is high.

It's just a suggestion from our experience :-)

Regards.

[Gerald Coley]

Try a smaller value.

Gerald

--

[duckhunt...@gmail.com]

Do you mean for the pull up or pull down? For the pull down we've already tried it with 7k5. But that didn't help. Now as we have a pull up (10k), it's working perfectly.

Regards

[Gerald Coley]

Got it.

Gerald

On Tue, Aug 6, 2013 at 8:28 AM, <duckhunt...@gmail.com> wrote:

Do you mean for the pull up or pull down? For the pull down we've already tried it with 7k5. But that didn't help. Now as we have a pull up (10k), it's working perfectly.

Regards

--

[gmbe...@gmail.com]

Same problem here, its showing up in 2 ways. The Beagle Board Black has a power control IC that is sensitive to 5 volt rise time and has frozen up under short brownout situations..in fact, I can freeze it up at will by dropping out 5 V for about 100mS, it will lock up with 3.3 volts turned off even though the 5 volt input is good. Removing the 5 volt input for more than 1 second restores normal 3.3 Volt power and all is good. The other way..I'm still investigating, it refuses to boot about 1 in 20 tries for reasons that are so far unknown. In this instance I have power supply monitoring instruments all over this board, and the power supply controller is working even when the lockup occurs. So I'm mainly interested in the situation where the blue lights are on but the board is not booting. We are running a port of Debian Linux.

[gmbe...@gmail.com]

[AndrewTaneGlen]

Hello All,

I am also having this problem - with a bench top power supply set to 5V and 5A, plugging into the barrel connector with no SD card inserted, so running the default Angstrom image from flash, the device will fail to boot at least 1 in 20 tries. A similar failure rate was observed on my two other boards.

I noticed a new board revision has been a released - the A6. The list of revisions included a reference to fixing a random glitch in the SYS_RESETn signal. Could this possibly address the problem I have been seeing - I would be more than happy to buy more boards if this is the case.

Regardless of the new release, I have tried various experiments to find a 100% reliable way of making the A5C board boot, as follows:

1) Hold reset button, connect power, release reset button after ~1 second.

2) Connect power, press and hold reset button, then release after ~1 second.

3) Hold Power button, connect power, wait till power led goes off, then release power button.

All of these also failed at varying rates, but all showing at least one failure out of 40 tries - which is unfortunate as I am building a custom cape that will have access to the reset and power signals, so I there was some sure fire way of making it boot this would have been fairly easy to include in my design.

Any further info would be greatly appreciated.

Regards,

Andrew.

[Gerald Coley]

I don't see that fix as being the issue you are seeing. But, when they are available, you can certainly give it a try.

The reset button is a warm reset button. It is not the power on reset for the board.

I suggest that you use the power button as it is intended and use it to power off the board and then power on the board. See what sort of results you get in that use case.

Gerald

--

[AndrewTaneGlen]

Hi Gerald, thank you for your response.

I tried the following (Using a new BBB with no SD card inserted, and nothing else connected to it at all):

Firstly, plug in 5V barrel connector (connected to regulated 5V, measured with good multimeter as 5.0001V), then:

1) Wait to see he heartbeat led (D2) come on.

2) Press and hold the power key until the power led (D1) goes off.

3) Release the power key

Repeating this process (with 5V connected the entire time) the device failed to boot (the heartbeat led failed to come on) on the 14th try, and continues to do so about 1/20.

I'm using the BBB in a location away from any regular user interaction and with a power supply that can come on and go off randomly (it functions as a wifi client I connect to and control/monitor with an ipad), so unfortunately I don't have the ability to manually press the power or reset buttons to ensure the device always comes on when power is applied (at least as I intend to use it).

What I will do, as a kind of nuclear option, is reassign the heart-beat led to a spare gpio on P9, and implement a basic watchdog circuit that will pull the 'SYS_RESETn' low for a couple of hundred milliseconds if it doesn't see a change in state of the heart-beat signal within about 10 seconds. This should give a 100% guarantee that (as long as the hardware is ok) the kernel will eventually get booted whenever power is applied.

There is a TI part, the TPS382x that is nearly perfect for this task, but has a non-configurable delay time of 1.6s - I'll try to find something like this.

Cheers,

Andrew.

[Gerald Coley]

You must just press the power button once. Not hold it. If you do it just power cycles. Pressing the button once let's the Linux kernel shutdown after a 60 second time out.

Try it again using the power button as it was intended.

Gerald

[AndrewTaneGlen]

When it fails to boot after connecting 5V, a short press of the power switch has no effect. The kernel has not booted, so the button press event is going nowhere.

From this failure mode, pressing and holding the power switch until the power led goes off and then releasing it causes the device to boot - as does a short press of the reset switch. This is what has led me to the conclusion that the only way to guarantee the device boots after applying power is to control the reset signal with a watchdog circuit triggered off a transition of the heart-beat signal (or something similar).

I'm wondering if it possibly is getting to u-boot under this failure mode. Do you know if any of the uarts available on P9 are configured by default for u-boot?

Cheers,

Andrew.

[Gerald Coley]

That is correct. The power button is only good for shutting it down with power attached and turning it back on with power still attached.

UBoot uses the UART0 debug port on the header, J1, on the board.

Gerald

[AndrewTaneGlen]

RESOLVED:

Upon investigating the u-boot output we found we were facing the same problem reported earlier in this thread by duckhunter: u-boot was detecting spurious data on uart0 and entering the u-boot console on about 1/20 power-ups.

Rather than making any hardware mods I decided to reconfigured u-boot to look for a specific key sequence before entering the u-boot console. To do this I firstly downloaded and rebuilt u-boot following instructions here: http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot. (Testing with the default config produced the same 'failure' rate)

I then modified '/include/config.h' in the u-boot source files, adding the following:

#define CONFIG_AUTOBOOT_KEYED 1 
#define CONFIG_AUTOBOOT_DELAY_STR "uboot"

This now forces a user to enter the string 'uboot' before entering the u-boot console, otherwise the device will boot up normally.

Rebuilding with this configuration still gave the same failure rate however. This is when I learned that the boot files on the eMMC flash are still loading before jumping to the files on the sd card I am using. So upon deleting the MLO file on the eMMC flash I had more luck.

We setup a programmable power supply and a script looking at the output of uart0 to detect whether the device had successfully booted or had become stuck in u-boot, and then left it cycling power. We were then able to get many hundreds of consecutive successful boots - we only stopped the test because we decided it would probably never fail.

So in the end it all came down to spurious data on uart0 - along with disabling booting from the eMMC. (we could have simply reconfigured u-boot on the eMMC in the same way, but disabling it drops a few seconds off the boot time).

Thanks for all your help Gerald (and duckhunter).

Regards,

Andrew Glen.

[moonsu...@gmail.com]

Hi i had the same problem.

My solution is to plug the barrel connector first and then plug the adaptor into the wall socket.
The it boots always.

[llindor.ac...@gmail.com]

Hi Gerald,
We encountered exactly the same issue described above with several BeagleBone revision A5C.
Do you plan to fix it in the next hardware board revision? Or must we systematically update the bootloader with the patch from Andrew Glen?
Many thanks
Regards,

Ludovic

[Gerald Coley]

It is called Rev A6A. 

http://www.elinux.org/Beagleboard:BeagleBoneBlack#Board_Revisions_and_Changes

Gerald

[llindor.ac...@gmail.com]

Thanks Gerald.

You changed C24 to a 2.2uF capacitor to improve the reset signal but we don't think that fix the issue.
We made some measurements around UART0 and we are convinced that u-boot detects spurious data during start up. Find below 2 ocilloscope screenshots (CH1 : PIN 3-J1 B_UART0_TX, CH2 : PIN 4-J1 B_UART0_RX).
http://hpics.li/9d7742f
http://hpics.li/956957a
RX signal looks noisy when TX signal changes. Maybe a coupling issue?

Regards,

Ludovic

[Gerald Coley]

Could be. That issue we have not seen. The one we did see was addressed by the capacitor change. I will look at this for a later revision, assuming we can duplicate it. But it won't be in the next revision for sure.

Gerald

Regards,

Ludovic

[Gerald Coley]

Get one of the latest version and try it. There was a change made back on Rev A6 that tied the 3V3B power up to the 3V3A. The 3V3B rail was coming up before the 3V3A rail. That may help this issue.

Gerald

[Hitesh Kalra]

quick question: How do I find out the hw rev version of my beagle bone black? i can't seem to locate it visually on the board itself..

[Gerald Coley]

It is the big white label on the expansion header. There are pictures of it in the System Reference Manual.

Gerald

[pcam...@ci24.com]

Can you post step by step instruction how to compile a new uboot and replace the old uboot in the BBB internal storage?

We tried the steps on the link you provided and got a new uboot.img and tried coping it to boot partition /media/beaglebone but it corrupted the obit partition.

We appreciate any help you can provide.

Pedro

[gbho...@gmail.com]

My A6 version just "bricked" probably due to my ineptitude in creating a bootable SD card. I only get a power light when powered by either brick or USB. The serial debug interface just says "CCCCCCC...." continuously.

This may be a different issue than reported in this thread, but the results are the same: no boot.

Is there hope?

Gary

[Gerald Coley]

Yes, there is hope. You cannot brick the board if you can create a bootable SD card to reflash from.

http://elinux.org/Beagleboard:Updating_The_Software

Gerald

--

[Gary Hoffman]

Thanks. That worked.

Gary

Sent from my iPhone

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/aXv6An1xfqI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[llindor.ac...@gmail.com]

Hi Gerald,
Last measurements were performed with an A6 revision board. We don't think the 3V3 power up update fix this issue.
We will try the bootloader solution described by AndrewTaneGlen.

[Andreas Tauböck]

 I hava a similar problem, just it almost everytime does not boot. I have 1.2A and nothing connected, just uSD card inserted. Also tried to flash the eMMC or boot from uSD, no success. And when it boots one of a hundret tries and i do not diconnect the power source an just reboot in shell, it is the same again.

Can anybody please help me?

[Gerald Coley]

Not sure what your issue is. You may need to request and RMA and get it looked at to see if there is a HW issue. 1 time out of 100 seems to indicate there could be an issue in the HW.

Gerald

--

[Dave Holden]

Just another data point.  I'm running an A5C and about 1/8 times when I restart with a watchdog timer it won't restart.  I have to hit the HW reset button to restart it.  Even then I've noticed it sometimes doesn't restart.  

Kind of nullifies the value of the watchdog, I'm bummed.  Guess I'll hook my Wemo up to the power supply.  :) 

[moonsu...@gmail.com]

Even SHUTDOWN -r not always work!

[rob....@gmail.com]

Just adding to the list.

I am seeing this on hard boot 1/20 

on SHUTDOWN -r I am getting even more frequent failures, closer to 1/10. 

On Wednesday, July 31, 2013 5:48:54 PM UTC-4, duckhunt...@gmail.com wrote:

[Gerald Coley]

Check the support Wiki under changes. This was fixed on a later revision.

Gerald

--

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

[gagu...@stratia.net]

Hello,
Basing on the correct answer of Andrew Glen,I attach the link of the compiled files to avoid the boot problem, you just need to replace the original files "MLO" and "u-boot.img" on eMMC and SD card, sorry for my bad english, regards:

https://www.dropbox.com/sh/98xacnk466xfpza/uTlii1hrsg

[to...@maaiveld.nl]

Hi,

Thanks a lot to all of you guys for this effort...

I have been stuck for weeks with 50+ beagle's that wouldn't reboot (or startup) 1/10 times...

It is driving me crazy...

Do I really assume correctly that all that is needed to fix this is replace the two files? 

No flashing or otherwise "enabling" the changes?

I'm testing with one of them now and sofar it's coming back every time, but I have no idea how to really check if the changes did "stick"

(they're all in a remote location)

Thanks, Tony

[Gerald Coley]

What revision are these boards? You may want to check here:

http://www.elinux.org/Beagleboard:BeagleBoneBlack#Board_Revisions_and_Changes

Gerald

--

[Guillermo A.]

Hi,

I flash the eMMC of BEAGLEBONE BLACK with debian (BBB-eMMC-flasher-debian-7.4-2014-04-14-2gb.img.xz) and then I replace 2 files "MLO" and "u-boot.img" , also in the microSD remplaze files, it is noteworthy that the microSD is loaded ubuntu 13.04

Regards

On Mon, May 5, 2014 at 9:47 AM, <to...@maaiveld.nl> wrote:

[Andrew Glen]

I was also driven crazy by the issue initially, but after fixing it I
have seen zero issues relating to the boot sequence getting stuck.

The problem my solution refers to is noise on the uart causing u-boot
to enter its terminal. Like when you boot up a PC and press F12 (or
some other key) to enter the bios menu, u-boot looks for any input on
the uart to break out of the boot sequence and enter the 'u-boot
menu'.

The fix involves two steps. Firstly, u-boot can be recompiled to look
for a specific character sequence (instead of any input) before
entering the u-boot terminal. The files Guillermo linked to are for
this effect. This solves the problem of random noise causing the boot
sequence to stop at u-boot, unless some miracle the random noise
spells out your specific character sequence, which I for one am happy
to allow for as a possible corner case.

Secondly, the boot sequence of the processor looks at the eMMC first
for an MLO file to boot with. So by deleting the MLO file on the eMMC
you stop the processor trying to boot from there. By simply copying
the same boot files to the eMMC you'll also solve the problem, I just
thought it better to have nothing there.

Regards,
Andrew.

> --
> 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/aXv6An1xfqI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[mak...@gmail.com]

Problem still exist on Revision B. The solution proposed by AndreTaneGlen by recompiling

to make it look for a sequence works like a charm. I've mended all my BBB from revision

A5 to B with this fix and they have since then never failed to boot.

Just to be clear, this is how I edited the u-boot source to make it work:

u-boot/include/configs/am335x_evm.h:

#define CONFIG_AUTOBOOT_PROMPT "Type <delay> in %d seconds to get to U-boot-prompt\n", bootdelay
#define CONFIG_AUTOBOOT_DELAY_STR "delay"

u-boot/include/configs/ti_armv7_common.h:

 #define CONFIG_BOOTDELAY 3

Best regards,

Marcus

[Guillermo A.]

Hello,

Shared files in the dropbox works for me in beaglebone black rev the A6, the only changes I made was in "u-boot/include/config.h" in lines:

#define CONFIG_AUTOBOOT_KEYED 1
#define CONFIG_AUTOBOOT_DELAY_STR "uboot"

Regards

[verster...@gmail.com]

Hello Andrew

Thank you so much for this post! I'm having the exact same problem, and am in need of getting the golden 100% boot ratio :)
I've been using linux for about a year, but am still not trusted with the building of kernels and modules. I had a look at the link that you posted, but am still not trusted with what is going on exactly.
Will it be possible for you to give me more detail about what exactly we are doing by rebuilding the u-boot and the neccessary steps?
Also, about any other steps that need to be taken (deleting the MLO file on the eMMC -> what is it and what are the effects of deleting it).

Or refer me to somewhere where I can learn more?

Kind Regards
Cornel Verster

On Monday, 28 October 2013 23:18:20 UTC+2, AndrewTaneGlen wrote:

RESOLVED:

Upon investigating the u-boot output we found we were facing the same problem reported earlier in this thread by duckhunter: u-boot was detecting spurious data on uart0 and entering the u-boot console on about 1/20 power-ups.

Rather than making any hardware mods I decided to reconfigured u-boot to look for a specific key sequence before entering the u-boot console. To do this I firstly downloaded and rebuilt u-boot following instructions here: http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot. (Testing with the default config produced the same 'failure' rate)

I then modified '/include/config.h' in the u-boot source files, adding the following:

#define CONFIG_AUTOBOOT_KEYED 1 
#define CONFIG_AUTOBOOT_DELAY_STR "uboot"

This now forces a user to enter the string 'uboot' before entering the u-boot console, otherwise the device will boot up normally.

Rebuilding with this configuration still gave the same failure rate however. This is when I learned that the boot files on the eMMC flash are still loading before jumping to the files on the sd card I am using. So upon deleting the MLO file on the eMMC flash I had more luck.

We setup a programmable power supply and a script looking at the output of uart0 to detect whether the device had successfully booted or had become stuck in u-boot, and then left it cycling power. We were then able to get many hundreds of consecutive successful boots - we only stopped the test because we decided it would probably never fail.

So in the end it all came down to spurious data on uart0 - along with disabling booting from the eMMC. (we could have simply reconfigured u-boot on the eMMC in the same way, but disabling it drops a few seconds off the boot time).

Thanks for all your help Gerald (and duckhunter).

Regards,

Andrew Glen.

On Friday, 25 October 2013 10:00:44 UTC+13, Gerald wrote:

That is correct. The power button is only good for shutting it down with power attached and turning it back on with power still attached.

UBoot uses the UART0 debug port on the header, J1, on the board.

Gerald

On Thu, Oct 24, 2013 at 3:57 PM, AndrewTaneGlen <andrewt...@gmail.com> wrote:

When it fails to boot after connecting 5V, a short press of the power switch has no effect. The kernel has not booted, so the button press event is going nowhere.

From this failure mode, pressing and holding the power switch until the power led goes off and then releasing it causes the device to boot - as does a short press of the reset switch. This is what has led me to the conclusion that the only way to guarantee the device boots after applying power is to control the reset signal with a watchdog circuit triggered off a transition of the heart-beat signal (or something similar).

I'm wondering if it possibly is getting to u-boot under this failure mode. Do you know if any of the uarts available on P9 are configured by default for u-boot?

Cheers,

Andrew.

On Friday, 25 October 2013 09:14:18 UTC+13, Gerald wrote:

You must just press the power button once. Not hold it. If you do it just power cycles. Pressing the button once let's the Linux kernel shutdown after a 60 second time out.

Try it again using the power button as it was intended.

Gerald

On Thu, Oct 24, 2013 at 3:05 PM, AndrewTaneGlen <andrewt...@gmail.com> wrote:

Hi Gerald, thank you for your response.

I tried the following (Using a new BBB with no SD card inserted, and nothing else connected to it at all):

Firstly, plug in 5V barrel connector (connected to regulated 5V, measured with good multimeter as 5.0001V), then:

1) Wait to see he heartbeat led (D2) come on.

2) Press and hold the power key until the power led (D1) goes off.

3) Release the power key

Repeating this process (with 5V connected the entire time) the device failed to boot (the heartbeat led failed to come on) on the 14th try, and continues to do so about 1/20.

I'm using the BBB in a location away from any regular user interaction and with a power supply that can come on and go off randomly (it functions as a wifi client I connect to and control/monitor with an ipad), so unfortunately I don't have the ability to manually press the power or reset buttons to ensure the device always comes on when power is applied (at least as I intend to use it).

What I will do, as a kind of nuclear option, is reassign the heart-beat led to a spare gpio on P9, and implement a basic watchdog circuit that will pull the 'SYS_RESETn' low for a couple of hundred milliseconds if it doesn't see a change in state of the heart-beat signal within about 10 seconds. This should give a 100% guarantee that (as long as the hardware is ok) the kernel will eventually get booted whenever power is applied.

There is a TI part, the TPS382x that is nearly perfect for this task, but has a non-configurable delay time of 1.6s - I'll try to find something like this.

Cheers,

Andrew.

On Friday, 25 October 2013 02:01:51 UTC+13, Gerald wrote:

I don't see that fix as being the issue you are seeing. But, when they are available, you can certainly give it a try.

The reset button is a warm reset button. It is not the power on reset for the board.

I suggest that you use the power button as it is intended and use it to power off the board and then power on the board. See what sort of results you get in that use case.

Gerald

On Wed, Oct 23, 2013 at 9:41 PM, AndrewTaneGlen <andrewt...@gmail.com> wrote:

Hello All,

I am also having this problem - with a bench top power supply set to 5V and 5A, plugging into the barrel connector with no SD card inserted, so running the default Angstrom image from flash, the device will fail to boot at least 1 in 20 tries. A similar failure rate was observed on my two other boards.

I noticed a new board revision has been a released - the A6. The list of revisions included a reference to fixing a random glitch in the SYS_RESETn signal. Could this possibly address the problem I have been seeing - I would be more than happy to buy more boards if this is the case.

Regardless of the new release, I have tried various experiments to find a 100% reliable way of making the A5C board boot, as follows:

1) Hold reset button, connect power, release reset button after ~1 second.

2) Connect power, press and hold reset button, then release after ~1 second.

3) Hold Power button, connect power, wait till power led goes off, then release power button.

All of these also failed at varying rates, but all showing at least one failure out of 40 tries - which is unfortunate as I am building a custom cape that will have access to the reset and power signals, so I there was some sure fire way of making it boot this would have been fairly easy to include in my design.

Any further info would be greatly appreciated.

Regards,

Andrew.

On Saturday, 28 September 2013 10:04:06 UTC+12, gmbe...@gmail.com wrote:

Same problem here, its showing up in 2 ways. The Beagle Board Black has a power control IC that is sensitive to 5 volt rise time and has frozen up under short brownout situations..in fact, I can freeze it up at will by dropping out 5 V for about 100mS, it will lock up with 3.3 volts turned off even though the 5 volt input is good. Removing the 5 volt input for more than 1 second restores normal 3.3 Volt power and all is good. The other way..I'm still investigating, it refuses to boot about 1 in 20 tries for reasons that are so far unknown. In this instance I have power supply monitoring instruments all over this board, and the power supply controller is working even when the lockup occurs. So I'm mainly interested in the situation where the blue lights are on but the board is not booting. We are running a port of Debian Linux.

On Wednesday, July 31, 2013 5:48:54 PM UTC-4, duckhunt...@gmail.com wrote:

Hi guys,

we have a problem with our Beagle Bone Black (A5C). We are using Ubuntu Raring 13.04 armhf v3.8.13-bone21 (2013-06-14) on the eMMC (no SD Card). The Beagle Bone is placed in a case and we have connected it to a DC power supply. Sometimes (I would say every 5 to 10 times), when we are plugging in our power supply, the BeagleBone powers on (Power LED is on), but nothing more happens (none of the other four LEDs is on). If we are now removing the power supply and putting it in again, the BBB starts normally. I guess the power supply is strong enough: 5A@5V.

Thanks for your help in advance.

Regards,

duckhunter

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

[verster...@gmail.com]

From Andrew's answer:

If I hard-ground uart0, will that solve the problem?

Thanks in advance
Cornel

[vag...@gmail.com]

Hi, I don't know if my issue is the same described here, my BBB never boots with something connected to I/O lines, if I disconnect, boots BBB and then reconnected I/Os everything works fine.

Andrew.

On Wednesday, July 31, 2013 5:48:54 PM UTC-4, duckhunt...@gmail.com wrote:

Hi guys,

we have a problem with our Beagle Bone Black (A5C). We are using Ubuntu Raring 13.04 armhf v3.8.13-bone21 (2013-06-14) on the eMMC (no SD Card). The Beagle Bone is placed in a case and we have connected it to a DC power supply. Sometimes (I would say every 5 to 10 times), when we are plugging in our power supply, the BeagleBone powers on (Power LED is on), but nothing more happens (none of the other four LEDs is on). If we are now removing the power supply and putting it in again, the BBB starts normally. I guess the power supply is strong enough: 5A@5V.

Thanks for your help in advance.

Regards,

duckhunter

--

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

[Gerald Coley]

Are the I/O lines the boot pins? Check the System Reference Manual for more information.

Gerald

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

[vag...@gmail.com]

That's it, I was using the boot pins, the System Reference Manual says that I can use this pins after Reset signal, how can I do this?

Valdir

[John Syn]

From: <vag...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Date: Thursday, August 28, 2014 at 6:00 PM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Re: BeagleBone Black doesn't sometimes start. Only Power LED is on

That's it, I was using the boot pins, the System Reference Manual says that I can use this pins after Reset signal, how can I do this?

If you power your board from the 3V3B rail or use this power rail to enable power on your own board, then you should be OK. If you power your board before the 3V3B pin is powered, you will damage the processor and you will most likely have a boot problem. 

Regards,

John

[DEEPAK KESWANI]

Hello everybody,

I am facing the same problem...in my BBB all led are completely shut down....i am trying to build new os then trying to boot my bbb form my sd card but i am not able to do it...please help me regarding it to how to boot my sd card from BBB...

[Gerald Coley]

Is the power LED shutoff too?

Gerald

--

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

[mi...@mikini.dk]

On October 16th 2014 21.26.23 UTC+2 Gerald wrote:

Is the power LED shutoff too?

Gerald

Hi Gerald.

I'm also affected by the OP's issue of periodic failing boots on BBB (I got all REV Bs).

My experience has always been with the power led lighting up and the system stuck without booting. Pressing the reset switch takes the system out of this locked up state, but neither boot switch or power switch has any effect.

I am very interested in your input on the successful experiences put forward by Andrew and Marcus in May, about modifying uboot to remedy noise input on UART0_RXD (pin E15 of AM3358).

I have done some tests today documenting the basic issue and some followup experiments investigating this specific cause, and I would appreciate if you could take a look and comment on the resulting speculations. You can find the details here; http://www.mikini.dk/index.php/2014/10/beaglebone-black-periodic-boot-failure-establishing-failure-rate-and-possible-cause.

Executive summary; removing U15 (SN74LVC2G241: UART0 powerdown isolation) seems to remedy the boot issue on a CircuitCo-produced BBB in my possession.

Although my result is inconclusive, as I was careless enough to rush myself into omitting a pre-modification test, verifying the failure rate of the unmodified BBB.


Thanks in advance for your help, and for my Beagle puppies ;).
Mikkel

[Shu Liu]

Mikkel,

You don't have to remove the whole U15. You can just give a 3.3V pull-up to the 4th PIN on the J1 connector. Then the board will not be stuck at the UBOOT anymore.

My question is how to fix it from software perspective? In u-Boot source, how can we make sure it is not stuck? 

If anyone can answer my question, i would really appreciate it. 

Regards,

Shu

[Andrew Glen]

Hi Shu,

I think I answered this in an earlier post, cut/pasted below:

Rather than making any hardware mods I decided to reconfigured u-boot to look for a specific key sequence before entering the u-boot console. To do this I firstly downloaded and rebuilt u-boot following instructions here: http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot. (Testing with the default config produced the same 'failure' rate)

I then modified '/include/config.h' in the u-boot source files, adding the following:

#define CONFIG_AUTOBOOT_KEYED 1 
#define CONFIG_AUTOBOOT_DELAY_STR "uboot"

This now forces a user to enter the string 'uboot' before entering the u-boot console, otherwise the device will boot up normally.

Rebuilding with this configuration still gave the same failure rate however. This is when I learned that the boot files on the eMMC flash are still loading before jumping to the files on the sd card I am using. So upon deleting the MLO file on the eMMC flash I had more luck.

We setup a programmable power supply and a script looking at the output of uart0 to detect whether the device had successfully booted or had become stuck in u-boot, and then left it cycling power. We were then able to get many hundreds of consecutive successful boots - we only stopped the test because we decided it would probably never fail.

So in the end it all came down to spurious data on uart0 - along with disabling booting from the eMMC. (we could have simply reconfigured u-boot on the eMMC in the same way, but disabling it drops a few seconds off the boot time).

Thanks for all your help Gerald (and duckhunter).

Regards,

Andrew Glen

--

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/aXv6An1xfqI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Shu Liu]

Andrew,

I tried that already. The file ../include/config.h is automatically generated when recompiling. I added the two lines which I marked red below. After I recompiled the uboot source again, the new generated config.h file replaces the old one that i modified and does not have the two lines. 

My question is that have the two lines got recompiled into the u-boot.img? Or am I missing something here?

/* Automatically generated - do not edit */
#define CONFIG_SERIAL1    1
#define CONFIG_CONS_INDEX    1
#define CONFIG_NAND    1
#define CONFIG_SYS_ARCH  "arm"
#define CONFIG_SYS_CPU   "armv7"
#define CONFIG_SYS_BOARD "am335x"
#define CONFIG_SYS_VENDOR "ti"
#define CONFIG_SYS_SOC    "am33xx"
#define CONFIG_BOARDDIR board/ti/am335x

#define CONFIG_AUTOBOOT_KEYED 1
#define CONFIG_AUTOBOOT_DELAY_STR "uboot"

#include <config_cmd_defaults.h>
#include <config_defaults.h>
#include <configs/am335x_evm.h>
#include <asm/config.h>
#include <config_fallbacks.h>
#include <config_uncmd_spl.h>

[Mikkel Kirkgaard Nielsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there Shu et al.

On 2014-11-03 22:12, Shu Liu wrote:
> You don't have to remove the whole U15. You can just give a 3.3V
> pull-up to the 4th PIN on the J1 connector. Then the board will not
> be stuck at the UBOOT anymore.

Really?
My first hunch after reading Andrew and Marcus' posts was also that
the RX line just needed to be tied down. But after seeing that R165
already does this, my suspicion was that it might be caused by the
SN74LVC2G241 doing some hiccups on the CPU during early power because
of OE and _OE being constantly active.

This is contradicted of your above experience, or at least also makes
the noise dependent on the 241's 1A input, which agreed does also seem
plausible. Inserting a "pull up" as you suggest, however does make
this and R165 a voltage divider keeping the B_UART0_RX input on ~1.4V
(at least when 3V3 and DGND has stabilized). Have you tried if the
uart0 port is functional after this modification?

Inspired by your input I've now done more tests which confirms your
experiences. Find them here;
http://www.mikini.dk/index.php/2014/11/beaglebone-black-periodic-boot-failure-fixing-b_uart0_rx-with-voltage-divider

Funny thing though, I tried increasing the pull down done by R165
(100k->45k), that didn't alleviate the problem as I kind-of expected.
Could the issue be that DGND and/or 3V3 actually isn't stable in
periods where the 241 has power and is gating 1A through to 1Y?

> My question is how to fix it from software perspective? In u-Boot
> source, how can we make sure it is not stuck?

I've yet only skimmed the posts about the software fix, as I prefer
understanding the problem fully before settling on a fix.

I regard issues like this as a hardware flaw, and it needs to be fixed
in hardware. There might be software workarounds that can mend the
symptoms on already existing boards, but that is part 2 for me so I'm
not there, yet.

One suggestion could be that the uart driver/uboot itself flushes the
uart fifo during initialization, so that uboot only reacts on input
made during the execution of the code that checks for interactivity.
My guess is that the fifo gets filled with characters generated from
noise early during power up, and it just sits there until uboot comes
around yanking it out and interpreting it. I haven't looked at the
uboot code yet, so this is pure speculation.

Regards,
- --
Mikkel
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUWLpWAAoJEJ2luFWzaTSaMEIIALOoGbABZn5F8Vbi9FQI92P/
I8PFMNp06ybldLHDORJpWpXRnOjIm2Ix5xSFKH5loyUqatoTjeg9ASfAB8m0AeKl
JcD/c8lkzC8Z91Ygm7vZtx6SC/09VXuWSd6x6mWvzf1tI9NmCaMReGMalvrLN58X
CxfFriqliE9qouI3kOHIJp8FVAmyMFnzxOukgIpU56LV8xTOWwNIot7Q4dK9GXIg
Twv+VPzKtSfW5mqKZKP6fhHqGmifWYcV19VI5onue0/rpBrPQM6w4NoJFOcRjTVA
ijAuWiDTsgh5/949VOHJl5ansB9KqMn8DJe/2cBrCREUgBSB1B3yKxNa1kzDP2I=
=SB8K
-----END PGP SIGNATURE-----

[Shu Liu]

Mikkel,

You can give a 3.3v directly or use a small resistor to make the voltage on the 4th pin of J1 higher than 3V. That should work. We rebooted a board over hundreds of time by using an app on Linux. It did not fail a single time. 

We found this accidently by using serial cable and the board never fails to boot when the cable is connected. The serial cable gives the 3.3v to the 4th pin which is the UART0_RX.

We tried to figure out what cause the problem and found a weird thing. We measured the UART3_RX(D16), UART3_TX(D15), UART4_RX(pin11 on header P9) and UART4_TX(pin13 on header P9). They are all 3.3V and they are in UART mode. We removed the R165 which is the pull down resistor on the UART0_RX line. The UART0_RX is around 1.4V and sometimes floating. We also checked the device tree. The internal pull up of the UART0_RX is turned on.

uart0_pins: pinmux_uart0_pins {

pinctrl-single,pins = <

0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /* uart0_rxd.uart0_rxd */ 

We do not know why the UART0_RX is not getting 3.3V, can you please check the voltage on both UART0_TX and UART0_RX when U15 is removed?

Again, If somebody can tell me how to fix it in uboot or from software perspective, I would really appreciate it. 

Regards,

Shu

[Mikkel Kirkgaard Nielsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Chu,

On 2014-11-04 21:40, Shu Liu wrote:
> You can give a 3.3v directly or use a small resistor to make the
> voltage on the 4th pin of J1 higher than 3V. That should work. We
> rebooted a

Well, that is interesting, as it isn't consistent with my findings. I
guess you missed that I use a 82k5 ohms resistor as pull up. That's
where the 3,3V*(100k/(100k+82,5k)= 1.81V level on B_UART0_RX/J4.1 is
from (which I misstated as the 82k2's voltage drop of 1.4V in previous
post).

This is close to, but not surpassing, the high level voltage of U15
which is 2V at 3.3V VCC (datasheet p. 3), thus it will interpret my
B_UART0_RX as a low level. As my modification also solves the issue,
your assumption about your fix (a high level at J4.1/B_UART0_RX
(U15.2/1A)) is not true.

> board over hundreds of time by using an app on Linux. It did not
> fail a single time.

Nice, thought about doing something like that too while manually
plug/unplugging ;). Is that application available somewhere? It would be
nice to fully automate the test to really hammer this issue.
How do you notify the application of successful boot? Another BBB and
some IO's?

> We found this accidently by using serial cable and the board never
> fails

No-one can plan for good stuff, it just shows up. Nice find, I remember
having read your posting about it somewhere.

> We measured the UART3_RX(D16), UART3_TX(D15), UART4_RX(pin11 on
> header P9) and UART4_TX(pin13 on header P9). They are all 3.3V and
> they are in UART mode.

Pins configurable for UART3 is used for MMC/MII, so I guess it is UART1
on TX;D15/P9.24 and RX;D16/P9.26 you have measured?

> We removed the R165 which is the pull down resistor on the UART0_RX
> line. The UART0_RX is around 1.4V and sometimes floating. We also
> checked the device tree. The internal pull up of the UART0_RX is
> turned on.

Peculiar, as it should never float.

> We do not know why the UART0_RX is not getting 3.3V, can you please
> check the voltage on both UART0_TX and UART0_RX when U15 is
> removed?

I'll definitely look into this tomorrow. Including taking this
measurement.

> Again, If somebody can tell me how to fix it in uboot or from
> software perspective, I would really appreciate it.

Got hints or pointers on bulding uboot for BBB? There's a lot of
different how-tos/blogs out there.

Regads,

- --
Mikkel
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUWY+ZAAoJEJ2luFWzaTSaM34H/1SOSvouAWoFQcngSqhuw6Z0
TjLhyZpfNmhRc4/Ykh4Wn4iW1oPL4WXYXJ35ePY5TAt69eQbuvDGhkpN2FMz/Seb
n1tbz4jz1fhXS1UYFT9ogJ4KuzE1YdQe4+GeTThEfsHCglTJGGuKSYVA4A/0uw0k
wRb7URXZYZ2JKAklPu+349UCJc+7oNBWtLiFV6CV/psuLq25wpwcmoq5qYnepOVK
BtKG+clu3IIXKlT+lzQb043KdAnCWOnKbs434robS1HUAQyuUBxrDz5+yu+2RW2B
LX2jfDXFHRjQ5dxR/WRdbk2MGJdlBkynV78vvYKi7IOWP9mSwQMm7sdGTIvIhNE=
=m/NP
-----END PGP SIGNATURE-----

[Mikkel Kirkgaard Nielsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Chu.

On 2014-11-05 11:47, Mikkel Kirkgaard Nielsen wrote:
> As my modification also solves the issue, your assumption about
> your fix (a high level at J4.1/B_UART0_RX (U15.2/1A)) is not true.

Sorry, J1.4 is the correct pin.
I've now done tests with a stronger pulldown (1k in parallel with R165=
990 ohm) and a short directly to DGND/VDD_3V3B (I'll post details later,
find them at http://www.mikini.dk/index.php/category/beaglebone-black).

These tests confirm that B_UART0_RX can't be pulled down/up, to prevent
the failure to occur. But forming a stable voltage on the input using a
voltage divider (also using 0 ohm= short circuit!) does solve the
problem. That is; whether we form a stable 0.58V or a stable 3.3V on
B_UART0_RX the system will always boot.

Does anybody have definite confirmation (by scope measurements) that
U15.6 (1Y) really is flickering during early power? It would be exiting
to do some experiments showing how it is affected by the U15.3 (1A)
input. I think that is the core of this issue.

>> We removed the R165 which is the pull down resistor on the
>> UART0_RX line. The UART0_RX is around 1.4V and sometimes
>> floating. We also checked the device tree. The internal pull up
>> of the UART0_RX is turned on.

[UART0_RX on 1.4V or floating]

> Peculiar, as it should never float.

I haven't been able to replicate that measurement. I got 3V3 on
UART0_RX (the one without B_, on the cpu side), except in early power
up. I see the voltage flickering shortly just after power is applied,
and in the same instance that kernel is loaded (USR0-USR3 leds starts
lighting up) there also some activity.

Are you sure that you actually did measure on U15.6? It isn't easy to
place the probes right on those small pads.

>> We do not know why the UART0_RX is not getting 3.3V, can you
>> please check the voltage on both UART0_TX and UART0_RX when U15
>> is removed?
> I'll definitely look into this tomorrow. Including taking this
> measurement.

Here they are, I see nothing unexpected here when things are static. I
also checked the U15 supply, which seems to be ok.

* BBB measurements on terminals of removed U15

** Device Under Test:
Modified Beaglebone Black produced by CircuitCo (PCB REV B6, serial
007142901445, marked "beaglebone"+ beagle logo and
"beagleboard.org").
Modified by removing U15 (uart0 buffer chip: SN74LVC2G241) and its
decoupling capacitor C155.

** Equipment
*** Multimeter
Brymen Elma BM515CF MOBILE LOGGER, MFG.#: 063391676.

*** Power Supply Unit
Huawei HW-050200E3W, output 5V 2A, USB A-connector. Danish plug.
Sourced from Huawei E589 mobile wifi.

*** Power Cable
20 cm no-name USB A male connector to USB Mini-B male connector.

** Procedure
Apply power to BBB through USB Mini-B connector.
Use multimeter to measure voltage levels on exposed U15 terminals
and related supply lines to check possible supply voltage drop.
COM probe fixed at DGND on decoupling capacitor (terminal C155.DGND
farthest from PCB edge).

** Measurements
C155.VDD_3V3B: 3.352V (terminal nearest to PCB edge)

U15.1: _1OE = 0V
U15.2: 1A = 0V
U15.3: 2Y = floating (flickering +-0.000,50V)
U15.4: GND = 0V
U15.5: 2A = UART0_RX = 3.335V
U15.6: 1Y = UART0_TX = 3.195V
U15.7: 2OE = 3.352V
U15.8: VCC = 3.352V

J1.1 = DGND = 0.000,02 V
P2.20 = GND5 = 0.000,02 V
FB4.1 = VDD_3V3B = 3.351 V


> Regads,
Even more regads,

- --
Mikkel
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUW47fAAoJEJ2luFWzaTSanH0H+gKv5DcQ/9NeX0vuf+9eIE3r
6mNho8sKbpWtx6uGcLRZzxEBLbU0NWnq/ePzhCzbWq7c/nEyXlYwtoa7hagJl7VT
OGaqjxxvt3Ti/iVTLp1rtiCm97Uyi0DzOKxuM8SwFTQDXTjWdmp/2ArApJqETZUD
PkpBABtfvFFWenks5rEpUYvQlI+a3SGL6nBHDmYdfD1bLExlM3ceKZ/rlCiIuHQa
8+Gj8BnoSfXO7FYk/3zUX13bBxEne2tdFgNtkOsqZK8/ut8G72jsrQwi2HmA1i1j
77CcoyTKUUeVwThcqx544pWDCvYx4FuAJz7dqIuTp3eNjHDN0JHcjNdemaL6O1M=
=LasS
-----END PGP SIGNATURE-----

[Shu Liu]

Mikkil,

Thanks for you detailed answer. 

   U15.1: _1OE          = 0V 
   U15.2: 1A            = 0V 
   U15.3: 2Y            = floating (flickering +-0.000,50V) 
   U15.4: GND           = 0V 
   U15.5: 2A = UART0_RX = 3.335V 
   U15.6: 1Y = UART0_TX = 3.195V 
   U15.7: 2OE           = 3.352V 
   U15.8: VCC           = 3.352V 

Based on the voltages that when U15 is removed, the UART0_RX is at its proper voltage level (3V3) that is defined in the device tree.

The strange thing is that when U15 is there, the UART0_RX is not getting 3V3.  _1OE is low and 2OE is high. Then the voltage on the j4.4 should be the same as UART0_RX. But J4.4 is not 3.3V (it was 1.4 on my board) even when R165 is removed, therefore, UART0_RX is not 3.3V.

 

How did you get the 0.58V on J4.4 using 1K resistor?  I do not why 0.58V works.

To my understanding, the default idle state should be high on both TX and RX lines for UART0. 

Regards,

Shu

[Chandu D]

i have the same problem, could you tell me the how to get the device back ..
thank

[Mikkel Kirkgaard Nielsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Chandu.

On 2014-11-20 08:45, Chandu D wrote:
> i have the same problem, could you tell me the how to get the
> device back ..

If you are experiencing the issue where uboot is put in interactive
mode by noise on UART0_RX during power up (see rest of this thread for
more details), then pushing the reset button will likely bring it
back. In the many many test I have done I've never seen the board not
recover from a reset in this situation.

The UART0_RX power up issue is periodic (in my tests failure rate was
24/555~4.3%).
If your board permanently starts up in this state (only pwr led is
lit) then my guess is that uboot is not loaded at all. Could your
image be corrupt? Have you attempted to reflash the emmc before seeing
this? Have you tried booting from a stock uSD image (holding down uSD
BOOT switch)?

A fix to the periodic UART0_RX issue is stabilizing B_UART0_RX which
can easily be done on the backside of the board. This doesn't affect
the functionality of UART0 (serial console).
See details about the fix here;
http://www.mikini.dk/index.php/2014/11/beaglebone-black-periodic-boot-failure-no-high-required-just-stable-voltage

Good luck.
- --
Mikkel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUbgEoAAoJEJ2luFWzaTSam4sIAJ1lA80WkROE89x6Yf8QWZ/7
1/3G0Uuh9dcx8V+xTmTHC+VX/FpWm765K7MOnK0QirSl45qaDGQMWCN8suOn+k22
HsuMB1dLQgE9XzY9adIPKRQzOAV69/gUnJX3EjVWTvA7UMZu5dE1OySYZrdCg5+n
9rRQNXPSR4SRdVAGrE2HAhFjMud6obAVmymt2k1ggfDHAWy0xGNZKIY6EXboMEC8
0kGoH9vEkZJQllrPF0B7X87xSJKKYRJ2/XSYoH1maebQLHjUJgETnYmDDVpuZlpK
mhr/zEXEljjc+5p9X8+qj7B1cylUBK40OECK9cigc7qHMTYADCz6c/S6KX7Eym8=
=GhZo
-----END PGP SIGNATURE-----

[martin...@spotme.com]

Hi,

Just as a +1 to Andrew's findings:

I have done a simple test with two BBBs to verify the presence and fix of the boot issue. The BBB under test had pins 1 and 5 of its UART0 port connected to an FTDI converter cable, which was plugged into the second BBB's USB port. The system reset pin (P9_10) of the BBB under test was wired to a GPIO pin on the other BBB. I then ran a shell script that pulled the reset pin high whenever "Starting kernel ..." was being printed on the serial console, and counted the number of resets. After some cycles the board would enter the U-Boot console and get stuck there. In three attempts with an A6A board, it took 3, 64 and 37 resets respectively for the board to get stuck. On a rev. C board, the problem occurred after 24, 31 and 3 resets. The U-Boot version used for these tests is fairly old (U-Boot SPL 2013.04-rc1-14237-g90639fe-dirty (Apr 13 2013 - 13:57:11) / U-Boot 2013.04 (Apr 23 2013 - 18:26:39))

I then copied the fixed u-boot provided by Guglielmo (https://www.dropbox.com/sh/98xacnk466xfpza/uTlii1hrsg) to the board's eMMC. When repeating the test, I now got past 1000 cycles on both BBBs (rev. A6A and rev. C) without a single boot failure.

In summary, this software fix is still highly useful.

Thank you Andrew and Guglielmo for your work!

Martin

[Mikkel Kirkgaard Nielsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there Martin.

On 2015-01-14 18:05, martin...@spotme.com wrote:
> Just as a +1 to Andrew's findings: In summary, this software fix is
> still highly useful.

Glad you were able to solve your issue.
I'm just wondering if Andrew's autoboot solution/hack hasn't
propagated to the official software yet?

Seems odd if not, since so many has been bitten by it and it is now 15
months since it was first described (2013-10-28:
https://groups.google.com/forum/#!msg/beagleboard/aXv6An1xfqI/2_tLa7oWQBIJ).


I haven't studied the u-boot source before but I just took a sniff at
the mainline repository (http://git.denx.de/u-boot.git).
I found that for BBB (really am335x) u-boot still defaults to aborting
autoboot if any characters are received on the serial console and then
waiting forever for further commands.

Below is a patch mitigating this situation in mainline master
(binaries at
http://www.mikini.dk/wp-content/uploads/2015/01/u-boot_mainline_BBB-autoboot-patch_201501151.zip).
It requires typing more characters ("stop") to abort and uses a new(?)
config feature to reset the board if autoboot is aborted but no
commands are entered (for 30 sec).
Except for the 30 sec timeout, which doesn't kick in for some unknown
reason, it seems to behave ok.

Disclaimer: this is mostly an experiment, there is a lot of u-boot
trees and patches floating around for the BBB (like
https://github.com/beagleboard/u-boot), so probably mainline hasn't
got the most recent stuff for BBB yet.


diff --git a/include/configs/ti_am335x_common.h
b/include/configs/ti_am335x_common.h
index 5ed86d9..c58f467 100644
- --- a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -12,6 +12,12 @@
#ifndef __CONFIG_TI_AM335X_COMMON_H__
#define __CONFIG_TI_AM335X_COMMON_H__

+#define CONFIG_AUTOBOOT_KEYED
+#define CONFIG_AUTOBOOT_STOP_STR "stop"
+#define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds (type '%s' to
abort)\n",bootdelay,CONFIG_AUTOBOOT_STOP_STR
+#define CONFIG_BOOT_RETRY_TIME 30
+#define CONFIG_RESET_TO_RETRY
+
#define CONFIG_AM33XX
#define CONFIG_ARCH_CPU_INIT
#define CONFIG_SYS_CACHELINE_SIZE 64
@@ -102,4 +108,7 @@
/* Now bring in the rest of the common code. */
#include <configs/ti_armv7_common.h>

+#undef CONFIG_BOOTDELAY
+#define CONFIG_BOOTDELAY 5
+
#endif /* __CONFIG_TI_AM335X_COMMON_H__ */

> Thank you Andrew and Guglielmo for your work!

Thumbs up, also for Guillermo ;).

- --
Mikkel
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/

keybase.io/mikini

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUt9HnAAoJEJ2luFWzaTSaqCoH/2cuFepOVkHGM0gGaGV5U8Dg
/Z3O4Cb1zGyasSeYLZbU5XfOms6k66hbLmbQiDYIKkMv/KS0gcjjkuFaZBE2NdVJ
xFnaPS/XPd8MJcwWQMVScFafNJE1E4KLHe437FeenPZLEBcgtZc/AsTFX+mybKhC
oQfaUmrA9gT2KGmFoGB8Sp+4q4reciXicHRfet78aEF8g9FdqprQvf4xjfcZYgxL
0cNNbXh+mmT+AjSCB4CEze25V5yitvfT744WUUHFznfRWXkRVvKpiVeiDwdswKcs
AaV5yjCqxb0F3iM4leRxdDy3FhuMjxmyZxk9HpwO/sLKExigNktpd3aRjuHO7ds=
=jU44
-----END PGP SIGNATURE-----

[martin...@spotme.com]

Hi Mikkel,

I'm just wondering if Andrew's autoboot solution/hack hasn't
propagated to the official software yet?

It's been a while that I haven't looked at the preinstalled software of a BBB since I get them pre-flashed with my own image...

The official Angstrom image releases for BBB seem to be at http://elinux.org/Beagleboard:Updating_The_Software (the page title is slightly misleading).

The most recent image dates from 2013-09-04, and the u-boot files on its boot partition are from 2013-06-19. This corresponds to the latest modification of [1], where apparently the u-boot patches for BBB are stored.

Clearly there is no fix yet! It looks like that repository is maintained by Koen Kooi, so maybe you can send him your patch.

Changing the upstream u-boot source probably doesn't make sense since the issue does not apply to other am335x-based systems.

Thumbs up, also for Guillermo ;).

Indeed, I noticed that typo this morning. My apologies!

Thanks,

Martin

[1] - https://github.com/beagleboard/meta-beagleboard/tree/master/common-bsp/recipes-bsp/u-boot/u-boot-denx

[patc...@gmail.com]

Mikkel,

I just found this forum after having these same boot problems with a couple beaglebones I have. I figured I would reply to you since I noticed you just posted a reply. I am a little confused on how to apply the fix Andrew provided. I am able to follow the instructions on downloading and building the u-boot, everything seems to work fine there. Then I have a MLO and u-boot.img file that I copy to the /boot/uboot directory ( I am using Debian booting off the eMMC). My question is when are the #DEFINES suppose to be added to the config.h file? Andrew mentions that he made the changes to the config.h file and rebuilt the u-boot, but when I do that it just overwrites the config.h file back to the original. So I assume the process should be first download and build the u-boot, then move MLO and u-boot.img into the uboot directory (/boot/uboot), then modify the config.h file adding in the #DEFINES Andrew provides. Is this correct? I have tried everything I can think of, but I you will have to forgive me because I am not too familiar with Debian. Thank you for any help you can provide! 

[Patrick Schmidt]

Mikkel,

I just found this forum after a couple beaglebones I have starting displaying the same problem discussed here. I figured I would reply to you since I saw you just posted. I have a question on how to implement Andrew's solution. I am able to download and build the u-boot, everything is working fine there. Then I have two files, MLO and u-boot.img that I can copy into the boot directory (/boot/uboot I am using Debian and booting from the eMMC). My question is when are we suppose to edit the config.h file? After I build and move the 2 files? I'm wondering because in Andrew's post he mentions that he edited the config.h file then rebuilt the u-boot. But when I try this it just overwrites the config.h file back to the original. So I assume the process should be first download and build the u-boot, then move the MLO and u-boot.img to the boot directory, finally edit the config.h file. Is this correct? I have tried everything I can think of but my board is still hanging on boots about 1 out of 20. Forgive me because I am not too familiar with Debian. Thank you for any help you can provide!

On Thursday, January 15, 2015 at 8:43:07 AM UTC-6, Mikkel Kirkgaard Nielsen wrote:

[Andrew Glen]

Hi Patrick,

Ensure you modify config.h after running the clean and configure steps before compiling, otherwise it will re-copy the default configuration file.

Only once you have compiled with the correct config file should the u-boot image be copied over.

BTW there is a run-time config file for u-boot that can be used to achieve the same effect (i.e. without the need to rebuild and copy over u-boot) - this might be worth investigating as a lower-risk option.

Cheers,

Andrew.

--

[Patrick Schmidt]

Hi Andrew,

Thank you for your reply. I feel like this is steering me in the right direction but I have one more question. After I do the clean and configure steps, I am looking for the /include/config.h file but I don't see it anywhere. I do see it after I do the compile step so it must be created after the compilation. Maybe I am missing something and looking for the wrong thing. Once I get this worked out it is going to save me a lot of frustration so thank you for all your help. Oh and also the runtime config file sounds like something I want to check out but a google search didn't help me much. Which file would I be editing for this? Thank you!

 

[Mikkel Kirkgaard Nielsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again Patrick.

On 2015-01-16 16:01, Patrick Schmidt wrote:
> After I do the clean and configure steps, I am looking for the
> /include/config.h file but I don't see it anywhere.

You could do like in my mainline patch, add the options to a specific
am335x file (I used /include/configs/ti_am335x_common.h). What tree
are you building from?

> Oh and also the runtime config file sounds like something I want to
> check out but a google search didn't help me much. Which file
> would I be editing for this? Thank you!

This option puzzled me too, hadn't thought this was possible, mostly
because in the boot sequence it seems like the environment is loaded
after the autoboot prompt.

I haven't tried it yet, but if you got the full source tree look for the
autoboot documentation in README and doc/README.autoboot.

In Denx's master you can use the env vars "bootdelaykey" or
"bootstopkey" to disable "any key" autoboot abort. But be sure u-boot is
built with CONFIG_AUTOBOOT_KEYED defined or else these options will not
be enabled.


Environment vars are what can be used at boot time to define how u-boot
should commence booting the OS, besides the options set at compile time.
The environment is read from the uEnv.txt file residing besides MLO and
u-boot typically on eMMC/flash or the SD-card. Normally BBB first tries
the eMMC, then SD. If the boot switch is depressed at powerup (not
reset) eMMC is skipped (actually SPI is tried instead) and u-boot on
the SD-card is used.


Anybody know if these options are available and enabled in u-boot on the
stock BBB images?

- --
Mikkel
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/
keybase.io/mikini
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUuTIFAAoJEJ2luFWzaTSans8IAOqtPsx4kfmA/gs8tDpw5/7r
UxNa0GK/jMyNSZTZraaJEjA9tUQRJw+f23i3Yj9SLzncpQ8l7f8sHKl7JcCrsbNi
8P+G/QWnvDq2mZdlW8VjB+OwO6tqlYTna0xy72tQJlY8CpVcUVneKjqMFMJxV60E
yLlHGCLF+NGiMDPW+AlqaqhQz0+iE6rnUZYTPOyAvHXl/yyAA3rFlgKa+zhFGVEG
QAvvMB95ljTpl7Z3cJdUFe/9L+IKPKiFHPUb4XzJAAjGP44UiiCkXUye1cJzO6vj
jL7Bv1lJh7qwuWXlghKv69Iz917hblNxXgqR//ZzGS4wCDbT26kGPSR3A4hmVVI=
=Pz4n
-----END PGP SIGNATURE-----

[Robert Nelson]

The patch-delta used in the BBB images is available here:

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

It's built against the "am335x_evm" u-boot target..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Patrick Schmidt]

Hi Mikkel,

I am trying to follow Andrew's post as close as I can. The tree I am building from is git://git.denx.de/u-boot.git, the one provided in Andrew's post.

RESOLVED:

Upon investigating the u-boot output we found we were facing the same problem reported earlier in this thread by duckhunter: u-boot was detecting spurious data on uart0 and entering the u-boot console on about 1/20 power-ups.

Rather than making any hardware mods I decided to reconfigured u-boot to look for a specific key sequence before entering the u-boot console. To do this I firstly downloaded and rebuilt u-boot following instructions here: http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot. (Testing with the default config produced the same 'failure' rate)

I then modified '/include/config.h' in the u-boot source files, adding the following:

#define CONFIG_AUTOBOOT_KEYED 1 
#define CONFIG_AUTOBOOT_DELAY_STR "uboot"

This now forces a user to enter the string 'uboot' before entering the u-boot console, otherwise the device will boot up normally.

Rebuilding with this configuration still gave the same failure rate however. This is when I learned that the boot files on the eMMC flash are still loading before jumping to the files on the sd card I am using. So upon deleting the MLO file on the eMMC flash I had more luck.

We setup a programmable power supply and a script looking at the output of uart0 to detect whether the device had successfully booted or had become stuck in u-boot, and then left it cycling power. We were then able to get many hundreds of consecutive successful boots - we only stopped the test because we decided it would probably never fail.

So in the end it all came down to spurious data on uart0 - along with disabling booting from the eMMC. (we could have simply reconfigured u-boot on the eMMC in the same way, but disabling it drops a few seconds off the boot time).

Thanks for all your help Gerald (and duckhunter).

Regards,

Andrew Glen.