[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

[Matthijs van Duin]

The PMIC is not the problem here, it properly shuts down all DCDC and LDO 
supplies, and requires no configuration other than voltage adjustments when 
desired, and setting the OFF bit before using the RTC to request shutdown. 
("SLEEP state" of the PMIC, aka "RTC-only sleep", is not supported since 
vdds was moved from LDO3 to LDO1 in rev A6A.)

The issue is the interconnection of the 3v3a and 3v3b power domains, 
resulting in significant leakage current between them (e.g. via protection 
diodes) whenever one is powered while the other is not. The 3v3b -> 3v3a 
leakage was of course exactly the reason for moving the enable-signal of 
the 3v3b regulator (U4) from 3v3aux (LDO2) to 3v3a. However, while this 
resolved the issue at boot, it did not resolve it at shutdown when running 
on dc power, and made it far worse when running on battery.

The problem is that when the 3v3a supply (LDO4) is disabled, the 3v3b 
regulator remains enabled until 3v3a drops below the threshold voltage of 
the enable-input of U4, which is far below 3.3V (specified to be somewhere 
between 0.4V (at 25 ͏°C) and 2V). As a result, current will start to flow 
from 3v3b to 3v3a, and apparently enough current to keep it logic-high in 
the opinion of the 3v3b-regulator (despite the ~375 ohm discharge resistor 
the PMIC applies when LDO4 is disabled!).

Thus, once turned on, the 3v3b regulator manages to keep itself enabled 
indefinitely as long as it is supplied from SYS_5V. When entering 
off-state, the PMIC automatically connects SYS to battery power rather than 
DC- or USB-supply. If there's no battery, then the capacitors on SYS will 
drain pretty fast hence the 3v3b shutdown is not delayed much. If there's a 
battery, then you're pretty screwed.

It is very important to note that this issue is not merely one of battery 
lifetime; this leakage current may *damage the processor*.

To illustrate all this, let's stare at some pretty pictures.

Here's a capture of various power terminals during boot and shutdown while 
on DC power (click to zoom):



I've marked the PMIC sequencer "strobes" with vertical dashed lines, 
partially cut away when irrelevant or visually interfering with the signal 
plots. Unless noted otherwise, the interval between strobes is 1 ms.

As I mentioned, in off-state SYS is tied to BAT, and when DC-powered they 
hover around 1V for some reason (they'll drop if you try to drain power 
from either, but once you stop they bounce back to 1V). All regulated 
supplies are off. Once the PMIC has detected a wakeup event, it connects 
SYS to the DC power supply, asserts the wakeup signal, and the sequencer 
powers up the "always-on" supplies:


   - strobe 15: LDO1 (rtc, vdds)
   - strobe 14: unused

The AM335x RTC asserts PW_EN and once debounced by the PMIC (~50 ms) the 
sequencer completes the power-on sequence:


   - strobe 1: DCDC1 (ddr)
   - strobe 2: LDO3 (1v8)
   - [5 ms delay]
   - strobe 3: LDO2 (3v3aux = power led)
   - strobe 4: LDO4 (3v3a, enables 3v3b)
   - strobe 5: DCDC2 (mpu), DCDC3 (core)
   - strobe 6: unused
   - strobe 7: unused

Meanwhile, since BATMON isn't connected to BAT, the PMIC doesn't really get 
what's going on there. It seems to attempt to charge it for a while, then 
gives up, and later BAT somehow manages to drop below 0V and stay there 
(behaviour is quite different if BATMON is connected to BAT, in which case 
it's pulsed a few times then drops to about 0.2V - 0.4V, apparently 
depending on system load).

When reentering off-state the PMIC shuts down the supplies in reverse 
order, with 1 ms between strobes 1 and 14. Strobe 7 is relevant this time 
because it marks when shutdown is initiated, and as a result SYS is 
disconnected from DC power and connects to BAT, which immediately shoots up 
to SYS level. Note however that 3v3b is *not* disabled at strobe 4 but 
stays slightly below SYS until long after the PMIC has completed shutdown. 
About 20 ms after it was supposed to, it finally begins to drop to zero 
while SYS, now unloaded and heavily supported by fat capacitors, begins its 
long and slow journey back towards the 1V.

For comparison, the same plot but now powered at 3.6V through BAT (using a 
variable power supply).
  


When BAT was powered up, SYS started tracking it once it reached 1V (hmm, 
sounds familiar), but the PMIC initially remains in off-state. The boot and 
shutdown are essentially the same, except SYS follows BAT continuously. As 
a result, once 3v3b is turned on, it remains on until power to BAT is cut.


Bottom line: if you want to run on battery power, this is a serious 
problem. You'll need to keep the PMIC in active-state, though you can 
minimize power by commanding the ethernet phy and hdmi framer to power 
themselves down, and then enter a deepsleep mode. Alternat

[beagleboard] Incorrect pinout in Beagleboard xM SRM

[Gergő Horváth]

Hi everyone!

While developing an expansion board which houses an audio codec interfacing 
through the audio expansion header i found out that the signals are not on 
the pins they should be. Then i checked the gerbers and it seems like the 
SRM of Beagleboard xM is not correct regarding the pinout of this header. 

The SRM shows this pinout (bottom view):
_
 3 1|  
 4 2

But the the real pinout is this:
_
 2 1|
 4 3

Can somebody verify this, and maybe correct the SRM?

Regards
Gergő Horváth

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

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

[Andrew Bradford]

Hi Matthijs,

On Wed, Apr 29, 2015, at 03:10 AM, Matthijs van Duin wrote:
> The PMIC is not the problem here, it properly shuts down all DCDC and LDO 
> supplies, and requires no configuration other than voltage adjustments
> when 
> desired, and setting the OFF bit before using the RTC to request
> shutdown. 
> ("SLEEP state" of the PMIC, aka "RTC-only sleep", is not supported since 
> vdds was moved from LDO3 to LDO1 in rev A6A.)
> 
> The issue is the interconnection of the 3v3a and 3v3b power domains, 
> resulting in significant leakage current between them (e.g. via
> protection 
> diodes) whenever one is powered while the other is not. The 3v3b -> 3v3a 
> leakage was of course exactly the reason for moving the enable-signal of 
> the 3v3b regulator (U4) from 3v3aux (LDO2) to 3v3a. However, while this 
> resolved the issue at boot, it did not resolve it at shutdown when
> running 
> on dc power, and made it far worse when running on battery.
> 
> The problem is that when the 3v3a supply (LDO4) is disabled, the 3v3b 
> regulator remains enabled until 3v3a drops below the threshold voltage of 
> the enable-input of U4, which is far below 3.3V (specified to be
> somewhere 
> between 0.4V (at 25 ͏°C) and 2V). As a result, current will start to flow 
> from 3v3b to 3v3a, and apparently enough current to keep it logic-high in 
> the opinion of the 3v3b-regulator (despite the ~375 ohm discharge
> resistor 
> the PMIC applies when LDO4 is disabled!).
> 
> Thus, once turned on, the 3v3b regulator manages to keep itself enabled 
> indefinitely as long as it is supplied from SYS_5V. When entering 
> off-state, the PMIC automatically connects SYS to battery power rather
> than 
> DC- or USB-supply. If there's no battery, then the capacitors on SYS will 
> drain pretty fast hence the 3v3b shutdown is not delayed much. If there's
> a 
> battery, then you're pretty screwed.
> 
> It is very important to note that this issue is not merely one of battery 
> lifetime; this leakage current may *damage the processor*.
> 
> To illustrate all this, let's stare at some pretty pictures.
> 
> Here's a capture of various power terminals during boot and shutdown
> while 
> on DC power (click to zoom):
> 
> 
> 
> I've marked the PMIC sequencer "strobes" with vertical dashed lines, 
> partially cut away when irrelevant or visually interfering with the
> signal 
> plots. Unless noted otherwise, the interval between strobes is 1 ms.
> 
> As I mentioned, in off-state SYS is tied to BAT, and when DC-powered they 
> hover around 1V for some reason (they'll drop if you try to drain power 
> from either, but once you stop they bounce back to 1V). All regulated 
> supplies are off. Once the PMIC has detected a wakeup event, it connects 
> SYS to the DC power supply, asserts the wakeup signal, and the sequencer 
> powers up the "always-on" supplies:
> 
> 
>- strobe 15: LDO1 (rtc, vdds)
>- strobe 14: unused
> 
> The AM335x RTC asserts PW_EN and once debounced by the PMIC (~50 ms) the 
> sequencer completes the power-on sequence:
> 
> 
>- strobe 1: DCDC1 (ddr)
>- strobe 2: LDO3 (1v8)
>- [5 ms delay]
>- strobe 3: LDO2 (3v3aux = power led)
>- strobe 4: LDO4 (3v3a, enables 3v3b)
>- strobe 5: DCDC2 (mpu), DCDC3 (core)
>- strobe 6: unused
>- strobe 7: unused
> 
> Meanwhile, since BATMON isn't connected to BAT, the PMIC doesn't really
> get 
> what's going on there. It seems to attempt to charge it for a while, then 
> gives up, and later BAT somehow manages to drop below 0V and stay there 
> (behaviour is quite different if BATMON is connected to BAT, in which
> case 
> it's pulsed a few times then drops to about 0.2V - 0.4V, apparently 
> depending on system load).
> 
> When reentering off-state the PMIC shuts down the supplies in reverse 
> order, with 1 ms between strobes 1 and 14. Strobe 7 is relevant this time 
> because it marks when shutdown is initiated, and as a result SYS is 
> disconnected from DC power and connects to BAT, which immediately shoots
> up 
> to SYS level. Note however that 3v3b is *not* disabled at strobe 4 but 
> stays slightly below SYS until long after the PMIC has completed
> shutdown. 
> About 20 ms after it was supposed to, it finally begins to drop to zero 
> while SYS, now unloaded and heavily supported by fat capacitors, begins
> its 
> long and slow journey back towards the 1V.
> 
> For comparison, the same plot but now powered at 3.6V through BAT (using
> a 
> variable power supply).
>   
> 
> 
> When BAT was powered up, SYS started tracking it once it reached 1V (hmm, 
> sounds familiar), but the PMIC initially remains in off-state. The boot
> and 
> shutdown are essentially the same, except SYS follows BAT continuously.
> As 
> a result, once 3v3b is turned on, it remains on unt

Re: [beagleboard] Issues while eMMC partitioned using sfdisk

[Ankur Tank]

Hi Mr. Nelson,

I made some progress,

mdev was auto-mounting /dev/mmcblk0* partitions, i changed following line 
in the mdev.conf file.

*#mmcblk[0-9]p+[0-9]* root:root 660 */etc/mdev/mount.sh $MDEV*
*mmcblk[0-9]p+[0-9]* root:root 660 *

But i don't understand why auto-mounting was creating problem,
Because before erasing the partition, I was checking if partition is 
mounted or not and if mounted i was umounting it.

Is it right change ?

Thank you 

On Monday, 27 April 2015 20:20:17 UTC+5:30, Ankur Tank wrote:
>
> Hi Mr. Nelson,
>
> Problem in short
> I changed partitioning command but with help,
> Here is my sfdisk commad,
>
>
> #Partition 
> drive
> sfdisk --force --in-order --Linux ${DRIVE} -uM 
> <<-__EOF__   
> 
> 1,32,C,*
> 
> ,200,L  
> 
> ,200,L  
> 
> ,,E 
> 
> ,100,L  
> 
> ,60,L   
> 
> ,200,L  
> 
> ,1269,L 
> 
> ,,,-
> __EOF__ 
>
> After above command i sync and flush buffers using blockdev command.
> and then run "mdev -s" but 
>
> I get following output,
>
> *sfdisk: ERROR: sector 184348 does not have an msdos signature*
> sfdisk:  /dev/mmcblk0: unrecognized partition table type
>
> Old situation:
> sfdisk: No partitions found
>
> New situation:
> Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0
>
>Device Boot Start   EndMiB#blocks   Id  System
> /dev/mmcblk0p1   * 1 32 32  32768c  W95 FAT32 (LBA)
> /dev/mmcblk0p233232200 204800   83  Linux
> /dev/mmcblk0p3   233432200 204800   83  Linux
> /dev/mmcblk0p4   433   3663   323133085445  Extended
> /dev/mmcblk0p5   433+   532100-102399+  83  Linux
> /dev/mmcblk0p6   533+   592 60- 61439+  83  Linux
> /dev/mmcblk0p7   593+   792200-204799+  83  Linux
> /dev/mmcblk0p8   793+  2061   1269-   1299455+  83  Linux
> /dev/mmcblk0p9  2062+  3663   1602-   1640447+  83  Linux
> Successfully wrote the new partition table
>
> Re-reading the partition table ...
>
> If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
> to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
> (See fdisk(8).)
> Auto-mount of [/media/mmcblk0p5] successful
> Auto-mount of [/media/mmcblk0p6] successful
> Auto-mount of [/media/mmcblk0p7] successful
> Auto-mount of [/media/mmcblk0p8] successful
> *Error: Error informing the kernel about modifications to partition 
> /dev/mmcblk0p5 -- Device or resource busy.  This means Linux won't know 
> about any changes you made to /dev/mmcblk0p5 until you reboot -- .*
> Error: Failed to add partition 5 (Device or resource busy)
> mount: mounting /dev/mmcblk0p1 on /media/mmcblk0p1 failed: Invalid argument
> rm: can't remove '/tmp/.automount-mmcblk0p1': No such file or directory
> mount: mounting /dev/mmcblk0p2 on /media/mmcblk0p2 failed: Invalid argument
> rm: can't remove '/tmp/.automount-mmcblk0p2': No such file or directory
> mount: mounting /dev/mmcblk0p3 on /media/mmcblk0p3 failed: Invalid argument
> rm: can't remove '/tmp/.automount-mmcblk0p3': No such file or directory
> mount: mounting /dev/mmcblk0p4 on /media/mmcblk0p4 failed: Invalid argument
> rm: can't remove '/tmp/.automount-mmcblk0p4': No such file or directory
> rm: can't remove '/tmp/.automount-mmcblk0p6': No such file or directory
> rm: can't remove '/tmp/.automount-mmcblk0p7': No such file or directory
> rm: can't remove '/tmp/.automount-mmcblk0p8': No such file or directory
> rootfs on / type rootfs (rw)
> 192.168.1.3:/nfsboot on / type nfs 
> (rw,relatime,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.1.3,mountvers=1,mountproto=udp,local_lock=all,add)
> proc on /proc type proc (rw,relatime)
> sysfs on /sys type sysfs (rw,relatime)
> tmpfs on /tmp type tmpfs (rw,relatime)
> none on /dev/pts type devpts (rw,relatime,mode=600)
> tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777)
> tmpfs on /var/run type tmpfs (rw,relatime,mode=777)
> tmpfs on /var/spool/cron type tmpfs (rw,relatime,mode=755)
> tmpfs on /var/sftp type tmpfs (rw,relatime,mode=755)
> + sfdisk -R /dev/mmcblk0
> + 
> + [ 0 -ne 0 ]
> + echo Nothing is mounted on /dev/mmcblk0
> Nothing is mounted on /dev/mmcblk0
> + RETRY=50
> + NO_OF_P

[beagleboard] Linux beaglebone 4.0.0-bone0 - problem with clkout2_pin

[festyn]

Hi all.
Once I upgraded BBB to 4.0 I have noticed section below, which configures 
P9_41.

&am33xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&clkout2_pin>;
};

I need this pin to work as gpio output.
Is it safe to disable this and release the P9_41 pin?

What does clkout2 do?
Why this section is almost everywhere in .dts, dtsi files?

Kind Regards




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

[beagleboard] Linux beaglebone 4.0.0-bone0 - Problem with I2C

[festyn]

Hi all.
After BBB boots up there is no /dev/i2c-0 nor /dev/i2c-1.
Even if I use modprobe and the do appear, I can't see eeprom in appropriate 
folder.
Is it my fault or it will be fixed in bone1 version of 4.0 kernel?

root@beaglebone:~# ls /dev/i
iio:device0  initctl  input/
root@beaglebone:~# modprobe i2c_dev
root@beaglebone:~# ls /dev/i2c-
i2c-0  i2c-1
root@beaglebone:~# i2cdetect -r -y 0
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
root@beaglebone:~# ./beaglebone-black-g-ether-load.sh
hexdump: /sys/bus/i2c/devices/0-0050/eeprom: No such file or directory
hexdump: /sys/bus/i2c/devices/0-0050/eeprom: No such file or directory
hexdump: /sys/bus/i2c/devices/0-0050/eeprom: No such file or directory
cpsw.0: D0:39:72:40:02:0D
cpsw.1: D0:39:72:40:02:0F
Stopping very small Busybox based DHCP server: Stopped /usr/sbin/udhcpd 
(pid 992).
udhcpd.
Starting very small Busybox based DHCP server: Starting /usr/sbin/udhcpd...
udhcpd.
root@beaglebone:~#

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

[beagleboard] ADconveter

[tosako]

 I am testing the Beaglebone black C and LCD 4DCAPE-70T  that provides 
touch panel. I am eager to use ADconveters on the BBB. But the touch panel 
can not work well when AD convters work. Sometimes CPU halts at all. 

 For example

*root@beaglebone* 
mailto:root@beaglebone>:
 
~# echo cape-bone iio>/sys/devices/bone_capemgr.*/slots

*root@beaglecone:~# cat* 
mailto:root@beaglecone:~#%20cat>
 /sys/devices/ocp.*/helper.*/AIN4

1683

*root@beaglebone:* 
mailto:root@beaglebone>~#
 
cat /sys/bus/iio/devices/iio! :device*/in_voltage7_raw

3829

*root@beaglebone:~#* 
mailto:root@beaglebone:~#>

 

If the above command is executed, the touchpanel work very slowly and CPU 
holts at all. Please give me solution.

Teruaki Osako

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

[beagleboard] Linux beaglebone 4.0.0-bone0 - problem with g_multi

[festyn]

Hi all.
When I connect BBB with 4.0 kernel to Windows 7 it detects only Gadget USB 
network card. It doesn't detect USB mass storage.
Everything works as it should when connected to laptop running Debian.
Same BBB loaded with 3.8.13 doesn't have that problem. Works fine on both 
Windows and Debian.
I have noticed a difference between 3.8.13 and 4.0 in parameters for 
g_multi .
Is it possible that is the problem?
Where can I change g_multi parameters so 4.0 matches 3.8.13.
Are they compiled into the kernel?
Kind Regards

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

[beagleboard] Re: Failed to install the new Debian image. 4 LEDs blinking together.

[nilesh . tekale]

Hi,

Same problem here. Have you checked md5sum of latest Debian image ? I have 
downloaded the same latest image 3 times, but every time my md5sum was 
giving checksum = 725d3fa63c0b1b0cc47b44f5c3f56238 which is different as 
per the website. So its not booting from sd card.

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

[beagleboard] confuguration of SPI using PRU

[ciesla . tomasz]

I've got a problem with configuration of SPI1 of BeagleBone White using 
PRU. The SPI works with external ADC in receive only mode
during boot (ubuntu minimal) I do pin mux:

//SPI CLK (output, mode3)
echo 13 > /sys/kernel/debug/omap_mux/mcasp0_aclkx
//D1 (input, pull-up, mode3)
echo 33 > /sys/kernel/debug/omap_mux/mcasp0_axr0

then using PRU I configure SPI:

//enable clock for SPI1
0x44e0_0050 = 0x2
//reset SPI1
0x481a_0110 = 0x2
then I wait till the reset is done

//configure channels
0x481a_012c = 0x7188a (d1 - input, no trans on d0&d1, receive only mode,  
18-bit world, ADC SPI polarity)
0x481a_0140 = 0x6188a (not used)
0x481a_0154 = 0x6188a (not used)
0x481a_0168 = 0x6188a (not used)
//module configuration
0x481a_0128 = 0x0
//system configuration (order recommended in datasheet)
0x481a_0110 = 0x15
//enable ch0
0x481a_0134 = 0x1
//write dummy TX data to enable receive only mode
0x481a_0138 = 0x3

then when I read RX register (0x481a_013c) I can see the clock and data on 
the lines using oscilloscope, but the value of RX register is always 0?

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

[beagleboard] SPI configuration via PRU

[ciesla . tomasz]

hi,
I got problem with SPI configuration (receive only mode for ADC) using PRU, 
first the system setup:

during boot (ubuntu minimal) does:

#SPI CLK - output, mode 3
echo 13 > /sys/kernel/debug/omap_mux/mcasp0_aclkx
#D1 - input, mode 3, pulled-up
echo 33 > /sys/kernel/debug/omap_mux/mcasp0_axr0

then I wrote using PRU SPI configuration (receive only mode)

//enable clock for SPI1
0x44e0_0050 = 0x2

//reset spi1
0x481a_0110 = 0x2
then I wait till reset is done

//module config
0x481a_0128 = 0x0
//system config - this order is recommended in datasheet
0x481a_0110 = 0x15

//configure channels - only ch0 is used, but when I don't configure 1,2,3 
there's no clock on ch0
0x481a_012c = 0x7188a  (d1 - input, transm on d1&d0 not used, receive only, 
18-bit word, ADC SPI polarity)
0x481a_0140 = 0x6188a
0x481a_0154 = 0x6188a
0x481a_0168 = 0x6188a

//enable ch0
0x481a_0134 = 0x1

//write dummy data to enable transmission
0x481a_0138 = 0x3
then I wait again a bit

the problem is that each readback of RX register (0x481a_013c) starts the 
SPI clock, there's a data od D1 line but the value of RX register is always 
0

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

Re: [beagleboard] Re: Failed to install the new Debian image. 4 LEDs blinking together.

[Robert Nelson]

On Wed, Apr 29, 2015 at 7:43 AM,   wrote:
> Hi,
>
> Same problem here. Have you checked md5sum of latest Debian image ? I have
> downloaded the same latest image 3 times, but every time my md5sum was
> giving checksum = 725d3fa63c0b1b0cc47b44f5c3f56238 which is different as per
> the website. So its not booting from sd card.

Please confirm this file with the complete output off:

md5sum 

Regards,

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

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

Re: [beagleboard] BBB does not recognise USB connected Arduino2009 if this is self powered

[agata10]

Using RevC produce similar problems.

New power adaptors, same problems.

On Sunday, February 2, 2014 at 11:18:36 AM UTC+1, MV wrote:
>
> With a new power adaptor (BBB side) no more noise, but same problems.
> When reboot BBB does not more recognize USB port, and the connected 
> arduino USB-serial.
>
> Unplug arduino power and reboot via software: BBB does not reboot.
> Press reset button: BBB restart, recognize USB, exchange data with arduino.
>
> But I need Arduino self powered.
>
> Nobody else had the same problem ?
>
>
> On Friday, December 20, 2013 2:45:42 PM UTC+1, MV wrote:
>>
>> Hi!
>>
>> It is a noise from a socket type power adaptor.
>> What really matter is that BBB does not more recognise USB, even if 
>> reboot. 
>>
>> I tryied many USB-RS232 adapters (without external powering USB slaves).
>> The connection is unstable.
>> dmesg show ftdi related problems (unable to change speed or other iocntl).
>>
>> BBB is powered with only 1A adaptor.
>> I'll try a better one.
>>
>> Il giorno giovedì 12 dicembre 2013 20:44:39 UTC+1, Gerald ha scritto:
>>>
>>> I have not heard that noise before.
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Thu, Dec 12, 2013 at 12:33 PM, MV  wrote:
>>>
 Problems arise anyway after random time with ftdi USB-RS232 adapters. 

 If I connect a self powered HUB or self powered Arduino I can ear 
 something become noisy: "zzz...".

 Is this a known problem ?

 Thanks

  
  

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

[beagleboard] Matplotlib Setup ImportError on Angstrom

[exotic . yasam]

 
   
I am trying to setup Matplotlib for my Angstrom Beaglebone. I followed 
instructions here: 
http://matplotlib.org/faq/installing_faq.html#install-from-git and 
downloaded matplotlib succesfully. 

python setup.py install

it results with following error. I installed numpy. Why do I get this 
error? Please help me.

File "/usr/lib/python2.7/site-packages/numpy/core/__init__.py", line 6, in 

from . import multiarrayImportError: cannot import name multiarray

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

Re: [beagleboard] Power Management - Suspend

[mjmcclary]

On Sunday, January 18, 2015 at 4:08:15 PM UTC-8, Robert Fisher wrote:
>
> OK, I found your apt repository.  I got that set up and the installation 
> seemed successful, but upon reboot I'm still running my original 3.18 
> according to uname -a.
>

I am trying to install that kernel and have not found the repository.  
Could you tell me where it is?

I though I'd found and added it.  My /etc/apt/sources.list is currently:

deb http://ports.ubuntu.com/ubuntu-ports/ trusty main universe multiverse
> deb-src http://ports.ubuntu.com/ubuntu-ports/ trusty main universe 
> multiverse
>
> deb http://ports.ubuntu.com/ubuntu-ports/ trusty-updates main universe 
> multiverse
> deb-src http://ports.ubuntu.com/ubuntu-ports/ trusty-updates main universe 
> multiverse
> deb [arch=armhf] http://repos.rcn-ee.net/debian wheezy main
> #deb-src [arch=armhf] http://repos.rcn-ee.net/debian wheezy main
>
> but this gives me:

E: Unable to locate package linux-image-3.14.26-ti-r44
> E: Couldn't find any package by regex 'linux-image-3.14.26-ti-r44'
>

So I'm wondering if I installed the wrong repository or if it just got 
broken
as part of the EOLing.

michael

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

[beagleboard] Fwd: We cannot synchronized the Tx data for McBSP in C6748

[Sinan Lezgioğlu]

>
> We are using LCDK C6748.
>
>  Code Composer Studio Version: 5.5.0.00077
> SYS/BIOS 6.35.4.50
> Compiler version: v7.7.4
>
> For TDM signaling we use McBSP1
> Both the clock and frame signals are external.
> clock is 2.048 MHz.
> frame is synchronized with the clock and it is 8kHz.
> We have 32 channels with 8 bits of words each.
> Attached is the project for Tx.
> We cannot send stable data. It is not synchronized.
> We couldn't understand where the problem is.
> Attached also the clock and frame timings in the pdf file.
>
> www.telsam.com.tr/ti/McBSP1.zip
> www.telsam.com.tr/ti/video.rar
>
> ​
> https://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/419108
> ​
>
>
> --
>
> İyi Çalışmalar,
>
> *Sinan LEZGİOĞLU*| Sales Manager
>
>
> Demetevler 408 Cad 134/2
>
>  Yenimahalle ANKARA
>
> T: 0312 332 04 04| M: 0 541 345 06 53
>
>  w ww.telsam.com.tr |
>


-- 

İyi Çalışmalar,

*Sinan LEZGİOĞLU*| Sales Manager


Demetevler 408 Cad 134/2

 Yenimahalle ANKARA

T: 0312 332 04 04| M: 0 541 345 06 53

 w ww.telsam.com.tr |

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

[beagleboard] BeagleBone Black with Android OS Board Peripherals

[abdulmanan978]

Hi, I am planning of using BeagleBone in my Project..I plan to install 
Android OS and develop and Android Application to run on the BeagleBone 
with a TouchScreen in place for the GUI

There will be an xBEE module connected to the Board...What if i want to use 
the Rx-Tx peripherals present on the board in the android app i'm going to 
build..

I personally having a feeling that its not gonna happen...But would surely 
appreciate any suggestion...

Feel free to ask for any details...

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

Re: [beagleboard] Power Management - Suspend

[Robert Nelson]

On Mon, Apr 27, 2015 at 8:34 PM,   wrote:
>
> On Sunday, January 18, 2015 at 4:08:15 PM UTC-8, Robert Fisher wrote:
>>
>> OK, I found your apt repository.  I got that set up and the installation
>> seemed successful, but upon reboot I'm still running my original 3.18
>> according to uname -a.
>
>
> I am trying to install that kernel and have not found the repository.  Could
> you tell me where it is?
>
> I though I'd found and added it.  My /etc/apt/sources.list is currently:
>
>> deb http://ports.ubuntu.com/ubuntu-ports/ trusty main universe multiverse
>> deb-src http://ports.ubuntu.com/ubuntu-ports/ trusty main universe
>> multiverse
>>
>> deb http://ports.ubuntu.com/ubuntu-ports/ trusty-updates main universe
>> multiverse
>> deb-src http://ports.ubuntu.com/ubuntu-ports/ trusty-updates main universe
>> multiverse
>> deb [arch=armhf] http://repos.rcn-ee.net/debian wheezy main
>> #deb-src [arch=armhf] http://repos.rcn-ee.net/debian wheezy main

Umm... trusty is available..

https://github.com/rcn-ee/repos/blob/master/README.md

deb [arch=armhf] http://repos.rcn-ee.net/ubuntu/ trusty main
#deb-src [arch=armhf] http://repos.rcn-ee.net/ubuntu/ trusty main

> but this gives me:
>
>> E: Unable to locate package linux-image-3.14.26-ti-r44
>> E: Couldn't find any package by regex 'linux-image-3.14.26-ti-r44'
>
>
> So I'm wondering if I installed the wrong repository or if it just got
> broken
> as part of the EOLing.

It's a space issue with weekly kernel image updates, i only keep "10"
kernel release per channel.. So today use:

sudo apt-get update ; sudo apt-get install linux-image-3.14.39-ti-r61
; sudo reboot

Regards,

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

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

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

[Matthijs van Duin]

On Wednesday, 29 April 2015 14:00:17 UTC+2, Andrew Bradford wrote:
>
> You seem to be talking about the BBB, correct?
>

Correct, though it seems nearly all posts in this thread are referring to 
the BBB issue?

My initial work was on BBW back in 2012 (prior to BBB release). 
>
> It sounds like BBB has similar issues to BBW with running on battery but 
> that the issues are slightly different.
>

Well the similarity is that the regulator was being kept alive by leakage 
currents.

Your original question is actually very easy to answer: disabling 3V3A like 
you were is really really not allowed, and if leakage currents didn't keep 
it logic-high then the result would have been pulling nRESET low, game over.

Shutting down 3V3B is something you may be able to do if appropriate pad 
configuration is done (high-Z with receiver disabled, pull-up disabled, 
maybe pull-down enabled) depending a bit on the rest of the BBW schematic 
(I didn't study it in any detail), but that doesn't help you since it 
doesn't control 3V3EXP.

Bottom line: shutting down 3V3EXP on the BBW (other than in off-state or 
rtc-only sleep) is not going to happen without a hardware patch.

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

[beagleboard] Re: Replacing Robotis robot controllers with BBB

[Bill M]

Greetings Dimitar,

I can't thank you enough for the direction (I was afraid no one would want 
to slog through all that). I'm also interested in the hardware part of it. 
Are there any schematics for interfacing the camera to the board (will I 
need caps, resistors, voltage translations)? The few I have found online 
aren't completely clear. I may still go the OS route if the learning curve 
isn't too steep. I would still love to learn how to handle the PRU stuff in 
bare metal, though, so I need to get busier with the Starterware. Again, 
thanks for the help!

On Tuesday, April 28, 2015 at 4:13:59 PM UTC-4, din...@gmail.com wrote:

> Hi,
>
> The servo control sounds like a job for the PRU. PRU I/O is also suitable 
> for interfacing OV7670. Here is a rough but working example for Beaglebone 
> White: 
> https://github.com/dinuxbg/pru-gcc-examples/tree/master/ov7670-cam/pru . 
> Note that the example loader uses Linux and uio_pruss driver instead of 
> Starterware.
>
> Regards,
> Dimitar
>
>
> понеделник, 27 април 2015 г., 16:28:40 UTC+3, Bill M написа:
>>
>> Greetings all, 
>>
>>
>> I'll apologize for the big lead up, I just want everyone to know where 
>> I'm coming from. I also apologize if I posted this to the wrong place or 
>> reposted it. I'm new here and still finding my way around.
>>
>>
>> I am considering getting a BBB to use with my Robotis robot kit to 
>> replace the CM-5 and CM-530 I've been using, and was hoping people here 
>> could give me help/advice/guidance, or direct me to those who can, as I 
>> have a million questions. I will start to list them here. Any help greatly 
>> appreciated in advance.
>>
>>
>> I've already written firmware for both the CM-5 (which is Atmega128 
>> powered) and the CM-530 (which uses an STM32F103, an ARM Cortex M3), You 
>> can see the source for these here: 
>> http://sourceforge.net/projects/bioloidfirmware/ Obviously these are 
>> bare metal firmware given that the extremely limited platform in both cases 
>> couldn't practically support an OS. I would like to port my code to the 
>> BBB. I want to stick with the bare metal approach, so I can go real time 
>> without having to use a patch for the OS or Xenomai, and since I won't be 
>> interested in a good part of the functionality of the board initially (also 
>> I'm kind of a big Linux noob). I have already downloaded StarterWare and 
>> started poking around. The big draw for me to BBB is the processor clock 
>> speed (the CM-5 is just 16Mhz, the CM-530 not much better at 72), the huge 
>> memory (for the controllers I'm using now, we're measuring in Kb), and the 
>> huge number for GPIOs (the CM-5 has none, the CM-530 only has a few). So 
>> here are some of my initial questions:
>>
>>
>> •Is anything special required to use the full 512MB memory? In other 
>> words, can I directly address all the available memory without having to go 
>> through any special procedures? Could I theoretically declare a really big 
>> structure (iike a MB or 2) or array and be able to handle it in code like I 
>> always have?
>> •With the code I've written thus far, the servos are updated 128 times a 
>> second. I have everything for doing that interrupt driven. I have a timer 
>> fire an interrupt every 8ms that calculates the next servo target positions 
>> and creates a packet to put in a buffer that feeds the shift register of 
>> the serial bus. The serial bus is also interrupt driven. When the buffer is 
>> loaded, an interrupt is enabled that fires whenever the shift register is 
>> empty. Every time it fires, it loads the next byte from the buffer. If the 
>> buffer is empty, it disables the interrupt. Receiving bytes is handled 
>> similarly, firing an interrupt every time a byte is received to put it in a 
>> buffer and empty the shift register. This allows the packets to be consumed 
>> as quickly as the 1Mb serial bus can consume them. Could I do something 
>> comparable on the BBB?
>> •My third, and heaviest question, is one of the main motivators for 
>> considering the BBB (and moving away from the above mention controllers). I 
>> would like to get into vision processing, so I would like to hook a camera 
>> (maybe two) to the BBB. I don't want to use the camera cape (since I want 
>> to be able to position the camera somewhere else on the robot). Could I use 
>> something like the OV7670 hooked up to some GPIO pins? I was thinking 
>> something along the lines of having one pin output a clock to the camera 
>> (along with a pin for power and ground), and then have an input pin for the 
>> HREF, VSYNC, and pixel clock, and have the pixel clock pin set to fire an 
>> interrupt that would read the input pins that D0-D7 from the OV7670 are 
>> connected to and push them into a big buffer in memory. I figure for a 640 
>> x 480 RGB565 image at 15 FPS, it would be about 9MB a second, and even if 
>> every byte was taking 20 to 30 clock cycles to handle (I think each 
>> interrupt could be handled much more

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

[Matthijs van Duin]

On Wednesday, 29 April 2015 17:30:14 UTC+2, Matthijs van Duin wrote:
>
> Your original question is actually very easy to answer
>

I posted a bit too hastily since I missed the second half of your original 
post.

If external hardware unconditionally drives or pulls up to 3V3EXP (in case 
of BBW) or 3V3B (in case of BBB) then at shutdown they are indeed applying 
power to IOs while the corresponding power domain has already been shut 
down, which is not allowed.

The BBB SRM (but not the BBW SRM) warns that "no pins are to be driven 
until after the sys_reset line goes high" but this statement isn't quite 
right since it only addresses boot and not shutdown (it should say "unless 
the sys_reset line is high") and pull-ups can also cause problems. Powering 
processor IO banks and attached hardware using separate supply lines is 
tricky to get right, all versions of beaglebones get it wrong, and it was 
wrong to dump responsibility for these issues onto CAPE developers by 
putting a statement like that in the SRM. The mandate given in the SRM is 
actually also violated by on-board peripherals of the BBB, for example by 
the UART level shifter.

I think the best solution would have been to have the regulator controlled 
by the PMIC_PGOOD output which also controls the power-on-reset input of 
the AM335x, but this too would need to be carefully analyzed to verify it 
doesn't cause issues.

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

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

[Andrew Bradford]

On Wed, Apr 29, 2015, at 01:07 PM, Matthijs van Duin wrote:
> On Wednesday, 29 April 2015 17:30:14 UTC+2, Matthijs van Duin wrote:
> >
> > Your original question is actually very easy to answer
> >
> 
> I posted a bit too hastily since I missed the second half of your
> original 
> post.
> 
> If external hardware unconditionally drives or pulls up to 3V3EXP (in
> case 
> of BBW) or 3V3B (in case of BBB) then at shutdown they are indeed
> applying 
> power to IOs while the corresponding power domain has already been shut 
> down, which is not allowed.
> 
> The BBB SRM (but not the BBW SRM) warns that "no pins are to be driven 
> until after the sys_reset line goes high" but this statement isn't quite 
> right since it only addresses boot and not shutdown (it should say
> "unless 
> the sys_reset line is high") and pull-ups can also cause problems.
> Powering 
> processor IO banks and attached hardware using separate supply lines is 
> tricky to get right, all versions of beaglebones get it wrong, and it was 
> wrong to dump responsibility for these issues onto CAPE developers by 
> putting a statement like that in the SRM. The mandate given in the SRM is 
> actually also violated by on-board peripherals of the BBB, for example by 
> the UART level shifter.
> 
> I think the best solution would have been to have the regulator
> controlled 
> by the PMIC_PGOOD output which also controls the power-on-reset input of 
> the AM335x, but this too would need to be carefully analyzed to verify it 
> doesn't cause issues.

If you take a BBW and cut the trace coming from U8 pin 5 (the LDO enable
line) and then wire U8 pin 5 to the PWR_LED net on page 2 of the
schematic, then the U8 LDO will shutdown correctly when on battery. 
This fix was incorporated into BBB but apparently there are other
problems, too.

This is the only mod required to fix my original problem.  No fancy
software needed.

Thanks,
Andrew

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

Re: [beagleboard] Re: 3.19 versus 4.0 dtb-rebuilder

[Peter Hurley]

On Tue, Apr 28, 2015 at 9:20 PM, Robert Nelson 
wrote:

> > Oh, it doesn't bother me; I reviewed the 8250_omap driver for
> > inclusion in mainline.
>
> With all the generic improvements done to the base 8250 since the
> omap_serial driver came out, it is a big improvement.  But with v4.0.x
> + 8250_omap does has some issues with omap3/dm3730 thou... Haven't had
> a chance to test v4.1-rc1 yet to see that's fixed with the xM,
> hopefully give that a test tomorrow...


There were a couple of issues during development that required
alternate DMA handling.  Although it wasn't clear at the time, this may
have been
a driver bug. A set of 3 patches was recently posted to linux-serial which
I haven't had time to review or test, but it may be related.

In any event, please let us know your test results on linux-omap and
linux-serial
so that we can resolve outstanding driver issues.

Regards,
Peter Hurley

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

[beagleboard] Re: Bone VDD_3V3EXP Disable Issues

[Matthijs van Duin]

On Wednesday, 29 April 2015 20:18:51 UTC+2, Andrew Bradford wrote:
>
> If you take a BBW and cut the trace coming from U8 pin 5 (the LDO enable 
> line) and then wire U8 pin 5 to the PWR_LED net on page 2 of the 
> schematic, then the U8 LDO will shutdown correctly when on battery.
>

It will shut down.
It will however not shut down *correctly*, neither on battery nor on dc 
power.

So, the BBW has a slightly different power scheme, including a different 
variant of the PMIC which affects timing and use of strobes. For reference, 
the relevant changes are:

   - strobe 15: LDO1 (rtc)

and

   - strobe 1: DCDC1 (vdds, 1v8, ddr)
   - [5 ms delay]
   - strobe 2: LDO2 (power led)
   - strobe 3: LDO3 (3v3a, enables 3v3exp)
   - strobe 4: LDO4 (3v3b)

This works for boot, and it may have been okay for shutdown if strobe 3 
directly controlled 3v3exp (some other TI PMICs have GPIOs in the power 
sequence for such purposes), though it'd still make me slightly nervous and 
I would have preferred a later strobe. Using 3v3b to enable 3v3exp would 
certainly have made more sense to me than 3v3a, and I think has a decent 
chance of working correctly.

In all cases it would be highly desirable to have the 3v3exp actively 
discharged when disabled like the PMIC LDOs do, but neither the BBW 3v3exp 
regulator nor the BBB 3v3b regulator does this. This means that even if 
they are shutdown before the 3v3a, their output rails may not discharge 
quickly enough and still end up getting (partially) discharged via 
processor IOs when the 3v3a shuts down. This is of course highly dependent 
on CAPE(s) present (if any), especially on the BBW.

Moving the enable to strobe 2 as you're suggesting however means that 
3v3exp gets powered up a full milisecond before the 3v3a at boot. Any pins 
driven or strongly pulled high to 3v3exp by an external CAPE will heavily 
leak to the 3v3a through processor IOs. During shutdown the same thing 
happens again, plus some remaining discharge after the 3v3exp is disabled. 
This is not good for the long-term health of the processor.

This fix was incorporated into BBB but apparently there are other problems, 
> too.
>

It was incorporated into BBB, and then undone in rev A6 for exactly the 
reason stated above. Unfortunately, instead of actually fixing the problem 
they reverted to using the 3v3a as enable-signal, even though the early 
posts in this thread show they knew about the problems this causes for 
battery-powered operation (though maybe they forgot).

To make matters worse, while the BBW needs a CAPE to trigger the problem 
since the 3v3exp is used exclusively for those, on the BBB the 3v3b and 
3v3exp have been merged and the on-board peripherals powered by it already 
get the job done.

Matthijs

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

Re: [beagleboard] Re: Beaglebone Black won't boot from Micro SD, all LEDs remain lit

[Tim M]

>
> I've held down the button you're suggesting for nearly 2mins and no change 
>> from booting from uSD. Once I eject the uSD and reboot the BBB i'm able to 
>> boot into to the eMMC, which is running the flashed version of ubuntu. I'm 
>> simply attempting to run the ubuntu desktop now(from uSD), instead of the 
>> console version (on eMMC). 
>>
>  
I'm having the same problem as A M Kent. I have a BBB rev C. I've installed 
Ubuntu 12.04.2 on a microSD card, and the card is inserted in my BBB. When 
I turn on the power while holding down the boot switch, all 4 LEDs come on 
and remain lit. The BBB does not boot. I held down the boot switch a long 
time (about 60 seconds). Once I eject the microSD and reboot the BBB I'm 
able to boot into to the eMMC, which still contains the Debian that came 
installed on the BBB.


I have 5 other Beaglebone Blacks, all rev C, and they all boot just fine 
from a microSD card with Ubuntu 12.04.2. In fact, I took the microSD card 
from one of these BBBs and inserted it in my new BBB, and it doesn't boot.

This seems to indicate that my new BBB is defective. Do you guys agree?

Tim M

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

Re: [beagleboard] Re: Beaglebone Black won't boot from Micro SD, all LEDs remain lit

[Robert Nelson]

On Wed, Apr 29, 2015 at 3:50 PM, Tim M  wrote:
>>> I've held down the button you're suggesting for nearly 2mins and no
>>> change from booting from uSD. Once I eject the uSD and reboot the BBB i'm
>>> able to boot into to the eMMC, which is running the flashed version of
>>> ubuntu. I'm simply attempting to run the ubuntu desktop now(from uSD),
>>> instead of the console version (on eMMC).
>
>
> I'm having the same problem as A M Kent. I have a BBB rev C. I've installed
> Ubuntu 12.04.2 on a microSD card, and the card is inserted in my BBB. When I
> turn on the power while holding down the boot switch, all 4 LEDs come on and
> remain lit. The BBB does not boot. I held down the boot switch a long time
> (about 60 seconds). Once I eject the microSD and reboot the BBB I'm able to
> boot into to the eMMC, which still contains the Debian that came installed
> on the BBB.
>
>
> I have 5 other Beaglebone Blacks, all rev C, and they all boot just fine
> from a microSD card with Ubuntu 12.04.2. In fact, I took the microSD card
> from one of these BBBs and inserted it in my new BBB, and it doesn't boot.
>
> This seems to indicate that my new BBB is defective. Do you guys agree?

You could prove it easily by plugging in a ftdi usb-serial cable into
the debug port.

Regards,

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

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

Re: [beagleboard] Re: Beaglebone Black won't boot from Micro SD, all LEDs remain lit

[Tim M]

Robert,

Unfortunately I don't have a ftdi usb-serial cable. But if I get one, can 
you refer me to instructions on how to use it?

Thanks,
Tim

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

Re: [beagleboard] Re: Beaglebone Black won't boot from Micro SD, all LEDs remain lit

[William Hermans]

What is it you do not know about using a serial debug cable Tim ?

On Wed, Apr 29, 2015 at 2:05 PM, Tim M  wrote:

> Robert,
>
> Unfortunately I don't have a ftdi usb-serial cable. But if I get one, can
> you refer me to instructions on how to use it?
>
> Thanks,
> Tim
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[beagleboard] kernel 3.14.39-ti-r61 panic

[Dan Lipsitt]

Got a kernel panic on Jessie running kernel 3.14.39-ti-r61:
BBB rev C.
TP-Link TL WN722N.
Wall wart power.
No capes.

Is there anywhere else I should post this?

[  439.103374] Unable to handle kernel paging request at virtual address 
01010241
[  439.111041] pgd = c0004000
[  439.113910] [01010241] *pgd=
[  439.117729] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[  439.123312] Modules linked in: ctr ccm usb_f_acm u_serial usb_f_ecm 
g_multi usb_f_mass_storage usb_f_rndis u_ether libcomposite arc4 ath9k_htc 
ath9k_common ath9k_hw ath mac80211 pruss_remoteproc cfg80211 c_can_platform 
c_can can_dev rfkill uio_pdrv_genirq uio mt7601Usta(O)
[  439.149565] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G   O 
3.14.39-ti-r61 #1
[  439.157676] task: dd8de6c0 ti: dd942000 task.ti: dd942000
[  439.163371] PC is at tick_sched_handle.isra.14+0x4c/0x6c
[  439.168946] LR is at tick_sched_timer+0x5c/0x88
[  439.173706] pc : []lr : []psr: 60010093
[  439.173706] sp : dd943d80  ip : dd943d98  fp : dd943d94
[  439.185695] r10: c00b6340  r9 : dd943e40  r8 : df9b53b0
[  439.191195] r7 : 0066  r6 : 38d6fa3e  r5 : df9b5ba0  r4 : 01010241
[  439.198027] r3 : c0cac658  r2 : 01010241  r1 : df9b5ba0  r0 : 
[  439.204860] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM 
 Segment kernel
[  439.212601] Control: 10c5387d  Table: 9cfdc019  DAC: 0015
[  439.218614] Process ksoftirqd/0 (pid: 3, stack limit = 0xdd942240)
[  439.225082] Stack: (0xdd943d80 to 0xdd944000)
[  439.229670] 3d80: df9b5b40 01010201 dd943dc4 dd943d98 c00b639c c00b62e0 
 df9b5b40
[  439.238230] 3da0: 38d6fa3e 0066 df9b5b40 0066 df9b53b0 df9b53e8 
dd943dfc dd943dc8
[  439.246802] 3dc0: c006d800 c00b634c 74242767 0002 000d 38d6e4ec 
0066 df9b53b0
[  439.255366] 3de0:  df9b53b0 0003 df9b53b0 dd943e74 dd943e00 
c006e6d4 c006d794
[  439.263930] 3e00: 38d6e4ec 0066 df9b7fc0 df9b54c0 df9b5488 df9b5450 
 7fff
[  439.272486] 3e20:   38d6e4ec 0066  7fff 
38d6e4ec 0066
[  439.281045] 3e40: 38d6e4ec 0066 dd943e74 c0ca0b38 0008 dd942000 
 0100
[  439.289602] 3e60: 0009 0100 dd943e8c dd943e78 c006e8d8 c006e594 
c006ebac 20010013
[  439.298164] 3e80: dd943ea4 dd943e90 c006eba4 c006e88c c006ebac c0ca60a0 
dd943eb4 dd943ea8
[  439.306764] 3ea0: c006ebc4 c006eb90 dd943f1c dd943eb8 c004d8e4 c006ebb8 
c0d53f24 dd943ef0
[  439.315329] 3ec0: 04208040 c0ca60c0 3650 000a c08df874 c0d54c40 
dd942038 c0d3a950
[  439.323884] 3ee0: c0ca0538 c0ca6080  0020   
dd8cbb80 c0ccc4ec
[  439.332439] 3f00:  0001   dd943f34 dd943f20 
c004db10 c004d780
[  439.340993] 3f20: c004dad0 dd942000 dd943f5c dd943f38 c0072764 c004dadc 
dd8de6c0 
[  439.349569] 3f40: dd8cbb40 dd8cbb80 c0072618  dd943fac dd943f60 
c006a808 c0072624
[  439.358123] 3f60: c08d3b70 0001  dd8cbb80  00030003 
dd943f78 dd943f78
[  439.366680] 3f80:   dd943f88 dd943f88 dd8cbb40 c006a72c 
 
[  439.375245] 3fa0:  dd943fb0 c000fa78 c006a738   
 
[  439.392915] 3fc0:       
 
[  439.410451] 3fe0:     0013  
 
[  439.427955] Backtrace: 
[  439.439734] [] (tick_sched_handle.isra.14) from [] 
(tick_sched_timer+0x5c/0x88)
[  439.458396]  r5:01010201 r4:df9b5b40
[  439.471645] [] (tick_sched_timer) from [] 
(__run_hrtimer+0x78/0x294)
[  439.489667]  r7:df9b53e8 r6:df9b53b0 r5:0066 r4:df9b5b40
[  439.505446] [] (__run_hrtimer) from [] 
(hrtimer_interrupt+0x14c/0x2f8)
[  439.523861]  r10:df9b53b0 r9:0003 r8:df9b53b0 r7: 
r6:df9b53b0 r5:0066
[  439.542089]  r4:38d6e4ec
[  439.554574] [] (hrtimer_interrupt) from [] 
(__hrtimer_peek_ahead_timers+0x58/0x60)
[  439.574059]  r10:0100 r9:0009 r8:0100 r7: 
r6:dd942000 r5:0008
[  439.592350]  r4:c0ca0b38
[  439.605078] [] (__hrtimer_peek_ahead_timers) from [] 
(hrtimer_peek_ahead_timers+0x20/0x28)
[  439.625481]  r4:20010013 r3:c006ebac
[  439.639234] [] (hrtimer_peek_ahead_timers) from [] 
(run_hrtimer_softirq+0x18/0x1c)
[  439.658769]  r4:c0ca60a0 r3:c006ebac
[  439.672498] [] (run_hrtimer_softirq) from [] 
(__do_softirq+0x170/0x35c)
[  439.691180] [] (__do_softirq) from [] 
(run_ksoftirqd+0x40/0x54)
[  439.709203]  r10: r9: r8:0001 r7: 
r6:c0ccc4ec r5:dd8cbb80
[  439.727703]  r4:
[  439.740553] [] (run_ksoftirqd) from [] 
(smpboot_thread_fn+0x14c/0x290)
[  439.759410]  r4:dd942000 r3:c004dad0
[  439.773621] [] (smpboot_thread_fn) from [] 
(kthread+0xdc/0xf4)
[  439.791973]  r8: r7:c0072618 r6:dd8cbb80 r5:dd8cbb40 r4: 
r3:dd8de6c0
[  439.810835] [] (kthread) from [] 
(ret_from_fork+0x14/0x20)
[  439.828955]  r7: r6: r5:c006a72c r4:dd8cbb40
[  439.84

[beagleboard] Re: kernel 3.14.39-ti-r61 panic

[Dan Lipsitt]

Another:

[   65.549033] Unable to handle kernel paging request at virtual address 
0101020d
[   65.556700] pgd = c0004000
[   65.562498] [0101020d] *pgd=
[   65.567712] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[   65.573493] Modules linked in: ctr ccm usb_f_acm u_serial usb_f_ecm 
g_multi usb_f_mass_storage usb_f_rndis u_ether libcomposite arc4 ath9k_htc 
ath9k_common ath9k_hw ath mac80211 pruss_remoteproc c_can_platform cfg80211 
c_can can_dev rfkill uio_pdrv_genirq uio mt7601Usta(O)
[   65.599753] CPU: 0 PID: 25 Comm: kworker/u2:1 Tainted: G   O 
3.14.39-ti-r61 #1
[   65.608224] Workqueue: phy0 ieee80211_scan_work [mac80211]
[   65.614013] task: ddaa3540 ti: ddaa4000 task.ti: ddaa4000
[   65.619692] PC is at memcpy+0xf0/0x330
[   65.623651] LR is at 0x98
[   65.626425] pc : []lr : [<0098>]psr: 20010013
[   65.626425] sp : ddaa5cc4  ip : 0003  fp : ddaa5cf4
[   65.638414] r10: dcfc0020  r9 : dcfc  r8 : dcee5300
[   65.643889] r7 : ddaa5d0c  r6 : 0004  r5 : 0014  r4 : 
[   65.650719] r3 :   r2 :   r1 : ddaa5d0f  r0 : 0101020d
[   65.657557] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[   65.665204] Control: 10c5387d  Table: 9c8e8019  DAC: 0015
[   65.671220] Process kworker/u2:1 (pid: 25, stack limit = 0xddaa4240)
[   65.677866] Stack: (0xddaa5cc4 to 0xddaa6000)
[   65.682454] 5cc0:  0101020d dcd75000 bf299c24 0004 fffe 
a814 dcfc
[   65.691047] 5ce0: 9814  ddaa5d1c ddaa5cf8 bf29f6d8 bf299b00 
ddaa5d08 0004
[   65.699611] 5d00: 0064 000a000a 7498 1498 ddaa5d3c ddaa5d20 
bf29f724 bf29f694
[   65.708173] 5d20: dcfc 6400 005e8add dcfc1000 ddaa5d6c ddaa5d40 
bf232fd8 bf29f708
[   65.716729] 5d40: 0003 540a 0985 09850985   
dcfc01d0 dcfc1000
[   65.725285] 5d60: ddaa5dd4 ddaa5d70 bf22d960 bf232f58 ddaa5d9c dcd75000 
 
[   65.733842] 5d80: dcd75078 c08d3808 ddaa5dac c08d3b0c  ddaa5da0 
dcfc01d0 dcfc1000
[   65.742436] 5da0: ddaa5d00 ddaa5db0 bf299a50 ddc54e20 0040  
ddc543c0 ddaa5e06
[   65.750999] 5dc0: dcfc ddc5559c ddaa5e54 ddaa5dd8 bf29d938 bf22cb74 
ddaa5e06 0001
[   65.759559] 5de0: 00c8 c08d37a0 ddaa5e0c ddc552f8 bf2a1fc4 dcfc 
0001 dcfc01d0
[   65.768116] 5e00: c0ca4000 c001663c ddaa5e3c ddaa5e18 c08d663c c00172ec 
c0ca4000 0002
[   65.776673] 5e20: c0d53610 c08d3b70 ddaa5e44 ddc543c0 0014 0040 
0040 0001
[   65.785236] 5e40: ddc54bc0 bf2a1fc4 ddaa5ea4 ddaa5e58 bf18a7d4 bf29d7a0 
ddaa5f14 ddaa5e68
[   65.793807] 5e60: c08d0214 c08d6874 0003 ddc54afc bf2a1fc4  
0985 
[   65.802360] 5e80: c0d3a6e0 ddc54b34 ddc543c0 dcd43500 c0ca60c0 0001 
ddaa5ee4 ddaa5ea8
[   65.810917] 5ea0: bf192ce8 bf18a780  0001   
ddaa5ee4 ddc54bc0
[   65.819501] 5ec0: dda74380 dd8ca400 dd8d5200  ddaa4028 dd8d5205 
ddaa5f24 ddaa5ee8
[   65.837107] 5ee0: c00635c8 bf192b18 dd8ca400 dda74380 dd8ca400  
dd8ca414 dda74380
[   65.854697] 5f00: dd8ca400 dda74398 dd8ca414 ddaa4028 ddaa4000 c0d3a6a2 
ddaa5f5c ddaa5f28
[   65.872333] 5f20: c0064420 c00634a4 dda82780 dda74380 c00642dc  
dda82780 dda74380
[   65.890069] 5f40: c00642dc    ddaa5fac ddaa5f60 
c006a808 c00642e8
[   65.907905] 5f60: c08d3b70  ddaa5f94 dda74380   
ddaa5f78 ddaa5f78
[   65.925830] 5f80:   ddaa5f88 ddaa5f88 dda82780 c006a72c 
 
[   65.943825] 5fa0:  ddaa5fb0 c000fa78 c006a738   
 
[   65.961804] 5fc0:       
 
[   65.979762] 5fe0:     0013  
 
[   65.997657] Backtrace: 
[   66.009642] [] (ath9k_wmi_cmd [ath9k_htc]) from [] 
(ath9k_regread+0x50/0x74 [ath9k_htc])
[   66.029194]  r8: r7:9814 r6:dcfc r5:a814 r4:fffe 
r3:0004
[   66.047012] [] (ath9k_regread [ath9k_htc]) from [] 
(ath9k_reg_rmw+0x28/0x48 [ath9k_htc])
[   66.066990] [] (ath9k_reg_rmw [ath9k_htc]) from [] 
(ar5008_hw_set_delta_slope+0x8c/0x11c [ath9k_hw])
[   66.087833]  r7:dcfc1000 r6:005e8add r5:6400 r4:dcfc
[   66.103444] [] (ar5008_hw_set_delta_slope [ath9k_hw]) from 
[] (ath9k_hw_reset+0xdf8/0x13fc [ath9k_hw])
[   66.124396]  r7:dcfc1000 r6:dcfc01d0 r5: r4:
[   66.140042] [] (ath9k_hw_reset [ath9k_hw]) from [] 
(ath9k_htc_config+0x1a4/0x5bc [ath9k_htc])
[   66.160369]  r10:ddc5559c r9:dcfc r8:ddaa5e06 r7:ddc543c0 
r6: r5:0040
[   66.178516]  r4:ddc54e20
[   66.191188] [] (ath9k_htc_config [ath9k_htc]) from 
[] (ieee80211_hw_config+0x60/0x39c [mac80211])
[   66.212333]  r10:bf2a1fc4 r9:ddc54bc0 r8:0001 r7:0040 
r6:0040 r5:0014
[   66.230939]  r4:ddc543c0
[   66.244017] [] (ieee80211_hw_config [mac80211]) from 
[] (ieee80211_scan_work+0x1dc/0x4

Re: [beagleboard] kernel 3.14.39-ti-r61 panic

[Robert Nelson]

On Wed, Apr 29, 2015 at 4:53 PM, Dan Lipsitt  wrote:
> Got a kernel panic on Jessie running kernel 3.14.39-ti-r61:
> BBB rev C.
> TP-Link TL WN722N.

I have this one too, so i can test it at home.. DOes the opps go away
when it's not plugged in?

> Wall wart power.
> No capes.

Regards,

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

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

Re: [beagleboard] kernel 3.14.39-ti-r61 panic

[Dan Lipsitt]

On Wednesday, April 29, 2015 at 3:08:05 PM UTC-7, RobertCNelson wrote:
>
> DOes the opps go away 
> when it's not plugged in? 
>
 
Hard to tell because it's intermittent. I'm currently trying to trigger it 
with the wifi adaptor still plugged in. I got two panics in a row and now I 
can't reproduce with 20 minutes of uptime.

One factor that might be relevant is that I'm having constant reconnects on 
wlan0 every 15 seconds or so. We have problems with other types of machines 
on the same network, so it probably doesn't have the same cause as the 
panic, but it may be triggering it. Here's a log snippet:

[Apr29 22:27] wlan0: authenticate with 0a:18:d6:87:c5:da
[  +0.229440] wlan0: send auth to 0a:18:d6:87:c5:da (try 1/3)
[  +0.009291] wlan0: authenticated
[  +0.012308] wlan0: associate with 0a:18:d6:87:c5:da (try 1/3)
[  +0.004013] wlan0: RX AssocResp from 0a:18:d6:87:c5:da (capab=0x31 
status=0 aid=26)
[  +0.005033] wlan0: associated
[ +14.790906] wlan0: disassociated from 0a:18:d6:87:c5:da (Reason: 1)
[  +0.279513] wlan0: deauthenticating from 0a:18:d6:87:c5:da by local 
choice (reason=3)
[  +0.02] cfg80211: Calling CRDA to update world regulatory domain
[  +1.276327] wlan0: authenticate with 0a:18:d6:87:c5:da
[  +0.219103] wlan0: send auth to 0a:18:d6:87:c5:da (try 1/3)
[  +0.001968] wlan0: authenticated
[  +0.011422] wlan0: associate with 0a:18:d6:87:c5:da (try 1/3)
[  +0.005604] wlan0: RX AssocResp from 0a:18:d6:87:c5:da (capab=0x31 
status=0 aid=12)
[  +0.006586] wlan0: associated
[  +5.191594] wlan0: disassociated from 0a:18:d6:87:c5:da (Reason: 1)
[  +0.255573] wlan0: deauthenticating from 0a:18:d6:87:c5:da by local 
choice (reason=3)
[  +0.010240] cfg80211: Calling CRDA to update world regulatory domain
[  +1.288695] wlan0: authenticate with 0a:18:d6:87:c5:da
[  +0.226962] wlan0: send auth to 0a:18:d6:87:c5:da (try 1/3)
[  +0.004037] wlan0: authenticated
[  +0.010564] wlan0: associate with 0a:18:d6:87:c5:da (try 1/3)
[  +0.008865] wlan0: RX AssocResp from 0a:18:d6:87:c5:da (capab=0x31 
status=0 aid=12)
[  +0.007288] wlan0: associated

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

Re: [beagleboard] kernel 3.14.39-ti-r61 panic

[Dan Lipsitt]

Robert, is there a 3.14 kernel you consider stable? Have you tested the 
previous one (3.14.38-ti-r60) much?
We also want compatibility with the Logicsupply UWN-200 (MediaTek MT7601) 
adaptor, but it looks like we may be better off with kernel 3.8 for that.

Thanks,
Dan

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

Re: [beagleboard] Re: Beaglebone Black with Ubuntu flasher hanging unpredictably?

[Andris Bjornson]

Thank you for the response (and sorry for my lack of update!been 
traveling).

I'll update and let you know if there's an improvement.

Thanks!



On Tuesday, April 7, 2015 at 6:51:38 AM UTC-7, RobertCNelson wrote:
>
> On Mon, Apr 6, 2015 at 11:25 PM, Andris Bjornson  > wrote: 
> >> uname -r ? 
> > 
> > 
> > 3.14.22-ti-r31 
>
> Yuck, yeah there are some issues with that old version... 
>
> Please upgrade to 3.14.37-ti-r57 
>
> sudo apt-get update ; sudo apt-get install linux-image-3.14.37-ti-r57 
> ; sudo reboot 
>
> and retest one of your units in those conditions. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

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

Re: [beagleboard] kernel 3.14.39-ti-r61 panic

[Dan Lipsitt]

Here's another, from different BBB with the same setup: 

[Apr29 23:08] hrtimer: interrupt took 387492 ns
[Apr29 23:15] INFO: task kworker/0:1:15 blocked for more than 120 seconds.
[  +0.006971]   Tainted: G   O 3.14.39-ti-r61 #1
[  +0.017714] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[  +0.015542] kworker/0:1 D c08d01d8 015  2 0x
[  +0.000227] Workqueue: ipv6_addrconf addrconf_verify_work
[  +0.66] Backtrace:
[  +0.94] [] (__schedule) from [] 
(schedule+0x40/0x90)
[  +0.59]  r10:c0d2f3cc r9:dd9e6030 r8:dd984780 r7:0002 r6: 
r5:c0d2f3c8
[  +0.000184]  r4:c0d2f3c4
[  +0.54] [] (schedule) from [] 
(schedule_preempt_disabled+0x20/0x2c)
[  +0.80] [] (schedule_preempt_disabled) from [] 
(__mutex_lock_slowpath+0x174/0x26c)
[  +0.93] [] (__mutex_lock_slowpath) from [] 
(mutex_lock+0x58/0x5c)
[  +0.75]  r10:feff7205 r9:dd9e6028 r8: r7:feff7200 r6:df9b7b40 
r5:dd9d0e80
[  +0.000149]  r4:c0d2f3c4
[  +0.58] [] (mutex_lock) from [] 
(rtnl_lock+0x20/0x24)
[  +0.49]  r4:c0d33570 r3:c085fae4
[  +0.000112] [] (rtnl_lock) from [] 
(addrconf_verify_work+0x18/0x24)
[  +0.000115] [] (addrconf_verify_work) from [] 
(process_one_work+0x130/0x454)
[  +0.88] [] (process_one_work) from [] 
(worker_thread+0x144/0x3d4)
[  +0.78]  r10:c0d3a6a2 r9:dd9e6000 r8:dd9e6028 r7:df9b7b54 r6:dd9d0e98 
r5:df9b7b40
[  +0.000127]  r4:dd9d0e80
[  +0.000107] [] (worker_thread) from [] 
(kthread+0xdc/0xf4)
[  +0.67]  r10: r9: r8: r7:c00642dc r6:dd9d0e80 
r5:dd9cd280
[  +0.000126]  r4:
[  +0.000113] [] (kthread) from [] 
(ret_from_fork+0x14/0x20)
[  +0.63]  r7: r6: r5:c006a72c r4:dd9cd280
[  +0.000191] INFO: task octoprint:1211 blocked for more than 120 seconds.
[  +0.025893]   Tainted: G   O 3.14.39-ti-r61 #1
[  +0.034184] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[  +0.041472] octoprint   D c08d01d8 0  1211  1 0x
[  +0.000161] Backtrace:
[  +0.92] [] (__schedule) from [] 
(schedule+0x40/0x90)
[  +0.63]  r10:c0d2f3cc r9:ddb86028 r8:dd94ed80 r7:0002 r6: 
r5:c0d2f3c8
[  +0.000131]  r4:c0d2f3c4
[  +0.000100] [] (schedule) from [] 
(schedule_preempt_disabled+0x20/0x2c)
[  +0.94] [] (schedule_preempt_disabled) from [] 
(__mutex_lock_slowpath+0x174/0x26c)
[  +0.97] [] (__mutex_lock_slowpath) from [] 
(mutex_lock+0x58/0x5c)
[  +0.76]  r10: r9:006b r8: r7:0014 r6:dcaac000 
r5:dde0c3c0
[  +0.000131]  r4:c0d2f3c4
[  +0.000110] [] (mutex_lock) from [] 
(rtnetlink_rcv+0x24/0x3c)
[  +0.56]  r4:dde0c3c0 r3:c07c9c30
[  +0.94] [] (rtnetlink_rcv) from [] 
(netlink_unicast+0x10c/0x1c8)
[  +0.56]  r4:dd9c1400 r3:c07c9c30
[  +0.61] [] (netlink_unicast) from [] 
(netlink_sendmsg+0x318/0x5ec)
[  +0.48]  r8:0008 r7:ddb87e70 r6: r5:dcaac000 r4:ddb87ee0
[  +0.000162] [] (netlink_sendmsg) from [] 
(sock_sendmsg+0xc8/0xf0)
[  +0.81]  r10: r9:ddb86000 r8:b24fe454 r7:ddb87ee0 r6:0014 
r5:da8d0ac0
[  +0.000148]  r4:dd94ed80
[  +0.49] [] (sock_sendmsg) from [] 
(SyS_sendto+0xd4/0x10c)
[  +0.51]  r7:da8d0ac0 r6: r5:0014 r4:c0cac50c
[  +0.000142] [] (SyS_sendto) from [] 
(ret_fast_syscall+0x0/0x30)
[  +0.61]  r8:c000fc04 r7:0122 r6:b24fe4dc r5:000c r4:b24fe448
[  +0.000166] INFO: task dnsmasq:1459 blocked for more than 120 seconds.
[  +0.049063]   Tainted: G   O 3.14.39-ti-r61 #1
[  +0.029581] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[  +0.045189] dnsmasq D c08d01d8 0  1459  1 0x
[  +0.000151] Backtrace:
[  +0.92] [] (__schedule) from [] 
(schedule+0x40/0x90)
[  +0.62]  r10:c0d2f3cc r9:dc8e r8:ddd81600 r7:0002 r6: 
r5:c0d2f3c8
[  +0.000134]  r4:c0d2f3c4
[  +0.000101] [] (schedule) from [] 
(schedule_preempt_disabled+0x20/0x2c)
[  +0.93] [] (schedule_preempt_disabled) from [] 
(__mutex_lock_slowpath+0x174/0x26c)
[  +0.97] [] (__mutex_lock_slowpath) from [] 
(mutex_lock+0x58/0x5c)
[  +0.75]  r10:0015 r9:c0d2e380 r8:f20010ac r7: r6:be852920 
r5:c0cac50c
[  +0.000130]  r4:c0d2f3c4
[  +0.000109] [] (mutex_lock) from [] 
(rtnl_lock+0x20/0x24)
[  +0.59]  r4:0001 r3:0002
[  +0.88] [] (rtnl_lock) from [] 
(devinet_ioctl+0x138/0x76c)
[  +0.86] [] (devinet_ioctl) from [] 
(inet_ioctl+0x1a4/0x1d0)
[  +0.75]  r10: r9:0004 r8:8915 r7:c0d2e380 r6:be852920 
r5:ff25
[  +0.000149]  r4:8915
[  +0.63] [] (inet_ioctl) from [] 
(sock_ioctl+0x1e4/0x2b4)
[  +0.71] [] (sock_ioctl) from [] 
(do_vfs_ioctl+0x410/0x5d4)
[  +0.67]  r7:be852920 r6:ddc90140 r5:be852920 r4:dd7230a0
[  +0.97] [] (do_vfs_ioctl) from [] 
(SyS_ioctl+0x7c/0x8c)
[  +0.54]  r9:0004 r8:8915 r7:be852920 r6:ddc90140 r5:ddc90140 
r4:
[  +0.000178] [] (SyS_ioctl

Re: [beagleboard] kernel 3.14.39-ti-r61 panic

[Dan Lipsitt]

[  +8.711840] [ cut here ]
[  +0.004777] kernel BUG at mm/slab.c:2919!
[  +0.004088] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[  +0.005940] Modules linked in: ctr ccm usb_f_acm u_serial usb_f_ecm 
g_multi usb_f_mass_storage usb_f_rndis u_ether libcomposite arc4 ath9k_htc 
ath9k_common ath9k_hw ath mac80211 c_can_platform pruss_remoteproc c_can 
cfg80211 can_dev rfkill uio_pdrv_genirq uio mt7601Usta(O)
[  +0.024944] CPU: 0 PID: 329 Comm: octoprint Tainted: G   O 
3.14.39-ti-r61 #1
[  +0.007872] task: dcd2b0c0 ti: dc818000 task.ti: dc818000
[  +0.005505] PC is at cache_alloc_refill+0x274/0x544
[  +0.004976] LR is at _raw_spin_lock+0x20/0x60
[  +0.004431] pc : []lr : []psr: 60010093
sp : dc819ca8  ip : dc819c90  fp : dc819ce4
[  +0.011657] r10: dd9a9580  r9 : 0010  r8 : dfd89c74
[  +0.005307] r7 : 00100100  r6 : dd81d480  r5 : dd9c2dc4  r4 : dd9c2dc0
[  +0.006638] r3 : 0009  r2 : 0009  r1 :   r0 : 0001
[  +0.006632] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
user
[  +0.007339] Control: 10c5387d  Table: 9df84019  DAC: 0015
[  +0.005838] Process octoprint (pid: 329, stack limit = 0xdc818240)
[  +0.006281] Stack: (0xdc819ca8 to 0xdc81a000)
[  +0.004433] 9ca0:   c006f678  009] cfg80211: 
Calling CRDA to update world regulatory domain
0d00 00200200 00067b2e 00d0
[  +0.008307] 9cc0[0m: 06d8 00d0 dd81d480 c07a8a04 20010013 
0001a0ef dc819d1c dc819ce8
[  +0.008312] 9ce0: c0162b58 c0162c18 c0809cc0 c08101f8 dc88c5c0  
06d8 00d0
[  +0.008309] 9d00: 0001 dd81d480 dc818000 0001a0ef dc819d4c dc819d20 
c07a8a04 c0162a88
[  +0.008309] 9d20: 0200   05a8 dc88c5c0 01c45a4c 
dc88c5c0 dc818000
[  +0.008309] 9d40: dc819d6c dc819d50 c07fde84 c07a89cc   
05a8 
[  +0.008308] 9d60: dc819df4 dc819d70 c07fe88c c07fde54 dc819e90 c00b6340 
dc819dac c006dd4c
[  +0.008310] 9d80: 00989680     dc819ec8 
c006dd4c 
[  +0.008308] 9da0: 00989680 dc818000  0040 dc88c690 05a8 
2c2499a1 05a8
[  +0.008308] 9dc0:   0210 dc88c5c0 0001a0ef dc819ec8 
dc819e20 
[  +0.008318] 9de0: dc818000  dc819e1c dc819df8 c0827024 c07fe598 
0001a0ef dcd2b0c0
[  +0.008309] 9e00: dd7c19c0 0001a0ef dc819ec8 01c45a4c dc819eb4 dc819e20 
c079e108 c0826f8c
[  +0.008308] 9e20:    dc819e58 dcd2b0c0  
 
[  +0.008307] 9e40:       
c018f1d8 c00a45ac
[  +0.008310] 9e60: ddf02bc0 0001a0ef dd7c19c0   dc819ec8 
c018f25c c018f134
[  +0.008316] 9e80: dc819e9c dc819e90 c018f2c0 c018f22c dc819eb4 dc819ea0 
c0cac50c 0001a0ef
[  +0.008308] 9ea0:  dd7c19c0 dc819f8c dc819eb8 c07a0634 c079e04c 
fff7 0001
[  +0.008309] 9ec0: 01c45a4c 0001a0ef   dc819ec0 0001 
 
[  +0.008309] 9ee0: 0040 dc819ef0 c004da54 c004d52c c08d3aa8 c08d6874 
00404100 c0ca60c0
[  +0.011023] 9f00: 593c 000a c08df874 c0d54c40 dc818018 0054 
6193 0054
[  +0.011010] 9f20: dc819f54 dc819f30 c00a8a18 c04c8994 df9b7fc0 dc818018 
0054 
[  +0.011042] 9f40: 0054 002439f8 dc819f6c dc819f58 c004dd60 c00a8a04 
0110 c0ca2368
[  +0.011062] 9f60: dc819f8c bd943609 c00103a0 0029c490 b5794500  
0121 c000fc04
[  +0.011080] 9f80: dc819fa4 dc819f90 c07a0694 c07a056c   
 dc819fa8
[  +0.01] 9fa0: c000f9e0 c07a0678 0029c490 b5794500 000c 01c45a4c 
0001a0ef 
[  +0.011142] 9fc0: 0029c490 b5794500  0121 b6f134d0 0163a050 
01c45a4c 0001a0ef
[  +0.011164] 9fe0:  be997e48 b6edea49 b6edea50 80010030 000c 
 
[  +0.011169] Backtrace: 
[  +0.005418] [] (cache_alloc_refill) from [] 
(kmem_cache_alloc+0xdc/0x190)
[  +0.011570]  r10:0001a0ef r9:20010013 r8:c07a8a04 r7:dd81d480 r6:00d0 
r5:06d8
[  +0.010925]  r4:00d0
[  +0.005538] [] (kmem_cache_alloc) from [] 
(__alloc_skb+0x44/0x13c)
[  +0.010945]  r10:0001a0ef r9:dc818000 r8:dd81d480 r7:0001 r6:00d0 
r5:06d8
[  +0.010895]  r4:
[  +0.005428] [] (__alloc_skb) from [] 
(sk_stream_alloc_skb+0x3c/0x100)
[  +0.011136]  r9:dc818000 r8:dc88c5c0 r7:01c45a4c r6:dc88c5c0 r5:05a8 
r4:
[  +0.010792] [] (sk_stream_alloc_skb) from [] 
(tcp_sendmsg+0x300/0xcf4)
[  +0.011267]  r6: r5:05a8 r4: r3:
[  +0.008724] [] (tcp_sendmsg) from [] 
(inet_sendmsg+0xa4/0xc4)
[  +0.010521]  r10: r9:dc818000 r8: r7:dc819e20 r6:dc819ec8 
r5:0001a0ef
[  +0.010966]  r4:dc88c5c0
[  +0.005578] [] (inet_sendmsg) from [] 
(sock_sendmsg+0xc8/0xf0)
[  +0.010687]  r8:01c45a4c r7:dc819ec8 r6:0001a0ef r5:dd7c19c0 r4:dcd2b0c0 
r3:0001a0ef
[  +0.010961] [] (sock_sendmsg) from [] 
(SyS_sendto+0xd4/0x10c)
[  +0.010628]  r7:dd7c19c0 r6: r5:0001a0ef r4:c0cac50c
[  +0.0

Re: [beagleboard] Re: Beaglebone Black won't boot from Micro SD, all LEDs remain lit

[Tim M]

I meant that I've never used the debug port and an FTDI cable on the BBB. I 
assume I would connect to the BBB using a serial terminal program (in my 
case I would be connecting from Windows).  When Robert said I could prove 
it easily by plugging in a ftdi usb-serial cable into the debug port, I 
assume he means that I can get an idea of what's happening by watching the 
messages on the serial terminal. Am I right?

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

RE: [beagleboard] Re: Beaglebone Black won't boot from Micro SD, all LEDs remain lit

[William Pretty Security]

Yes

 

It should boot from the onboard emmc.

Type “debian” as the username and “temppwd” as the password.

 

Then try “dmesg” to see all of the boot messages.

 

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

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

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

http://ca.linkedin.com/pub/bill-pretty/2b/b07/602

 

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Tim M
Sent: Wednesday, April 29, 2015 10:12 PM
To: beagleboard@googlegroups.com
Subject: Re: [beagleboard] Re: Beaglebone Black won't boot from Micro SD, all 
LEDs remain lit

 

I meant that I've never used the debug port and an FTDI cable on the BBB. I 
assume I would connect to the BBB using a serial terminal program (in my case I 
would be connecting from Windows).  When Robert said I could prove it easily by 
plugging in a ftdi usb-serial cable into the debug port, I assume he means that 
I can get an idea of what's happening by watching the messages on the serial 
terminal. Am I right?

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

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5863 / Virus Database: 4339/9646 - Release Date: 04/28/15

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

[beagleboard] Touch panel can not work well when AD conveter works

[Teruaki Osako]

 I am testing the Beaglebone black C and LCD displayer 4DCAPE-70T that is 
pruced by 4D-systems now. If ADconveter that is installed in the beaglebone 
black C works, the touch panel that is provided in 4DCAPE-70T works very 
slowly and sometimes CPU halts at all.

For example

*root@beaglebone* 
mailto:root@beaglebone>:
 
~# echo cape-bone iio>/sys/devices/bone_capemgr.*/slots

*root@beaglecone:~# cat* 
mailto:root@beaglecone:~#%20cat>
 /sys/devices/ocp.*/helper.*/AIN4

1683

*root@beaglebone:* 
mailto:root@beaglebone>~#
 
cat /sys/bus/iio/devices/iio! :device*/in_voltage7_raw

3829

*root@beaglebone:~#* 


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

Re: [beagleboard] Re: Beaglebone Black won't boot from Micro SD, all LEDs remain lit

[William Hermans]

@Tim


On Windows puTTY is probably your best bet. I'd say that *everyone* who
uses COMx devices on windows use it, but I'd probably be wrong. There are
many apps out there. But puTTY and the paralax serial app are the two most
prominent on my mind.

So basically, you get an adapter, be is cable, or otherwise. You install
the drivers for that cable on windows. Look in hardware manager find the
COM port the drivers reserved for the device. Then you install puTTY,
change the connection type to serial, and then you must configure the
connection ( COM port, baud rate, parity etc.)

Anyway, I'm sure there is a how to on the web somewhere. I used to have one
on a forums for the beaglebone black when it was first released. But it
seems now that forum is defunct. Just make sure you use a 3.3v TTL adapter
. . . otherwise you'll probably damage your BBB.

On Wed, Apr 29, 2015 at 8:07 PM, William Pretty Security <
bill.pre...@xplornet.com> wrote:

> Yes
>
>
>
> It should boot from the onboard emmc.
>
> Type “debian” as the username and “temppwd” as the password.
>
>
>
> Then try “dmesg” to see all of the boot messages.
>
>
>
> "No one could make a greater mistake than he who did nothing because he
> could do only a little."
>
> "All that is necessary for the triumph of evil is that good men do
> nothing" Edmond Burke *(1729 - 1797)*
>
>
> http://www.packtpub.com/building-a-home-security-system-with-beaglebone/book
>
> http://ca.linkedin.com/pub/bill-pretty/2b/b07/602
>
>
>
>
>
> *From:* beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com]
> *On Behalf Of *Tim M
> *Sent:* Wednesday, April 29, 2015 10:12 PM
> *To:* beagleboard@googlegroups.com
> *Subject:* Re: [beagleboard] Re: Beaglebone Black won't boot from Micro
> SD, all LEDs remain lit
>
>
>
> I meant that I've never used the debug port and an FTDI cable on the BBB.
> I assume I would connect to the BBB using a serial terminal program (in my
> case I would be connecting from Windows).  When Robert said I could prove
> it easily by plugging in a ftdi usb-serial cable into the debug port, I
> assume he means that I can get an idea of what's happening by watching the
> messages on the serial terminal. Am I right?
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> --
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.5863 / Virus Database: 4339/9646 - Release Date: 04/28/15
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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