[beagleboard] Re: Beaglebone Green - Experience and Notes

[Chris M]

10) installing flask/ flaskio, etc.

pip install 

On Sunday, November 13, 2016 at 4:09:06 PM UTC-6, Chris M wrote:
>
> Some thoughts and findings as I begin to learn the BBG (Beaglebone Green) 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4e743484-f378-4ada-bf6d-7c2beb27cca4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Green - Experience and Notes

[Chris M]

mount them. 

Field definitions 

/etc/fstab contains the following fields separated by a space or tab: 

 


   - 
   
   ** - defines the storage device (i.e. /dev/sda1). 
   - 
   
   ** - tells the mount command where it should mount the  to. 
   - 
   
   ** - defines the file system type of the device or partition to be 
   mounted. Many different file systems are supported. Some examples are: 
   ext2, ext3, reiserfs, xfs, jfs, smbfs, iso9660, vfat, ntfs, swap, and auto. 
   The 'auto' type lets the mount command to attempt to guess what type of 
   file system is used, this is useful for removable devices such as CDs and 
   DVDs. 
   - 
   
   ** - define particular options for filesystems. Some options 
   relate only to the filesystem itself. Some of the more common options are: 
   - 
  
  *auto* - file system will mount automatically at boot, or when the 
  command 'mount -a' is issued. 
  - 
  
  *noauto* - the filesystem is mounted only when you tell it to. 
  - 
  
  *exec* - allow the execution binaries that are on that partition 
  (default). 
  - 
  
  *noexec* - do not allow binaries to be executed on the filesystem. 
  - 
  
  *ro* - mount the filesystem read only. 
  - 
  
  *rw* - mount the filesystem read-write. 
  - 
  
  *sync* - I/O should be done synchronously. 
  - 
  
  *async* - I/O should be done asynchronously. 
  - 
  
  *flush* - specific option for FAT to flush data more often, thus 
  making copy dialogs or progress bars to stays up until things are on the 
  disk. 
  - 
  
  *user* - permit any user to mount the filesystem (implies 
  noexec,nosuid,
  

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8e8cba3d-8cd8-49e5-9996-8e3a1e2bd834%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Green - Experience and Notes

[Chris M]

http://www.tecmint.com/useful-basic-commands-of-apt-get-and-apt-cache-for-package-management/

more commds to upgrade your installed software packages

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d01710b7-638c-45ef-a34e-0af511974748%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Green - Experience and Notes

[Chris M]

spent the weekend trying to get a usb web cam to work with python
there are many false trails on the internet. ended up following

http://www.chioka.in/python-live-video-streaming-example/
https://github.com/log0/video_streaming_with_flask_example
and
https://blog.miguelgrinberg.com/post/video-streaming-with-flask

installed pythons opencv

took some time to get things too work.
 time out error was solved by
http://stackoverflow.com/questions/27769561/opencv-python-cv2-videocapture0-grab-and-cv2-videocapture0-read-hangs

using mjpeg compression relies on the BBB to decode (tobyte() command is 
really tostring() command. making live streaming very slow and laggy.

began to explore opencv with neon per

http://blog.lemoneerlabs.com/3rdParty/Darling_BBB_30fps_DRAFT.html
and
http://vuanhtung.blogspot.com/2014/04/and-updated-guide-to-get-hardware.html

after installing opencv per their instructions i kept getting a file too 
small error when importing cv2
decide try to reinstall debian image and start over.







On Sunday, November 13, 2016 at 4:09:06 PM UTC-6, Chris M wrote:
>
> Some thoughts and findings as I begin to learn the BBG (Beaglebone Green) 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/dab559b0-680f-4eb4-99a1-6031f29dd488%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBB with cape 7inch LCD faulty screen

[Kevin Gordon]

What is the best method to automatically ensure that the display backlight 
is on after boot? Initially the screen is white then switches to faint 
graphics (backlight off). Thank you! Kevin.

On Wednesday, 23 November 2016 02:33:47 UTC+13, Kevin Gordon wrote:
>
> I have built a new host from debian-8.6.0-amd64-CD-1.iso and included 
> eclipse mars.2 with debugging for 
> bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz installed on a BBB 
> with a 7 inch LCD cape.
> At the beginning of uEnv.txt I included as a first line:
> dtb=am335x-boneblack-emmc-overlay.dtb
> For file capemgr:
> root@beaglebone:/etc/default# nano capemgr
>   GNU nano 2.2.6   File: capemgr
> # Default settings for capemgr. This file is sourced by /bin/sh from
> # /etc/init.d/capemgr.sh
> # Options to pass to capemgr
> CAPE=BB-BONE-LCD7-01:00A3
> I added the above last line: CAPE=BB-BONE-LCD7-01:00A3
> root@beaglebone:/# cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A3,Override Manuf,BB-BONE-LCD7-01
> Which I believe means the cape is loaded.
> The above is working satisfactorily except the display is very faint. I 
> can turn on the backlight with:
> Manually:
> root@beaglebone:~# echo 1 > /sys/class/backlight/backlight/bl_power
> Or:
> echo 1 | sudo tee /sys/class/backlight/backlight/bl_power
> Placed in .bashrc
> These turned the backlight on but seemed to cause some mouse and screen 
> instability. If I don't do this everything is stable but so faint that the 
> display is almost unreadable.
> This is a first attempt by me. Any comments or improvements would be much 
> appreciated.
> Many thanks,
> Kevin.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/99b96d90-081c-4695-8f67-e02b7e82431c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Green - Experience and Notes

[Chris M]

9) things to install and update after image is installed.

Mount an external sd card for extra storage.

# df -h 
tells you what is  mounted

# fdisk -l | grep '^Disk'
Disk /dev/mmcblk1: 3.7 GiB, 3909091328 bytes, 7634944 sectors
Disk /dev/mmcblk0: 7.4 GiB, 7948206080 bytes, 15523840 sectors
tells you all the storage devices

manage partitions
# fdisk /dev/mmcblk0

format partition (mmcblk0p1)can change depending on situation

# mkfs.ext3 /dev/mmcblk0p1 

mount the disk at a new folder
# mkdir /extsd
# mount /dev/mmcblk0p1 /extsd

update apt-get
# apt-get update

install cmake again




-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/83bfd5ac-11ef-40b9-9a16-d19ddc6b4810%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] dtb-rebuilder

[Neil Jubinville]

Thx!  nice commit :) 

so I could then do make *KERNEL_VERSION=4.4.27-ti-r62* install

Neil

On Tuesday, November 22, 2016 at 1:49:37 PM UTC-7, RobertCNelson wrote:
>
> Hi Neil, 
>
> On Tue, Nov 22, 2016 at 12:59 PM, Neil Jubinville 
>  wrote: 
> > In this repo https://github.com/RobertCNelson/dtb-rebuilder 
> > 
> > The make script allows us to rebuild then make install the files. 
> > 
> > This is all fine. 
> > 
> > I am curious if the make script can take a parameter such as a kernel 
> > version. 
> > 
> > In my automation I run  "/opt/tools/update_kernel.sh   " 
> > which works great. 
> > 
> > After that step I want to rebuilt the DTBs and install them.  The 
> problem 
> > however is that the beaglebone has not yet rebooted at that point so the 
> OS 
> > runtime at that moment is on the previous kernel. 
> > 
> > The make script uses 'uname -r' to fill in the spots where things are 
> built 
> > / installed. 
> > https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/Makefile 
> > 
> > What is the method to pass in a kernel version into this script?   I am 
> not 
> > a pro at Make files so knowing all about what is going on in that 
> particular 
> > script is a work in progress.  I can see where uname -r is used . 
> > 
> > My goal is to rebuild and place the dtbs before the reboot so it can 
> boot 
> > with the proper base dtb. 
>
> Yeah, we will need to patch the makefile for that... 
>
> How about this: 
>
>
> https://github.com/RobertCNelson/dtb-rebuilder/commit/5e25af5781a31672a919ed63c34c5eca9df66e6b
>  
>
> sudo make KERNEL_VERSION=4.5 install 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/88dc4e2d-6409-4afb-a68b-06a8253a8561%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: debian testing: 2016-11-22 (nodejs v4.x)

[Robert Nelson]

On Tue, Nov 22, 2016 at 2:29 PM, Robert Nelson  wrote:
> Howdy!
>
> So there's a little something new and special in this week's snapshot:
>
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-11-21
>
> First, nodejs v0.12.x is almost EOL: https://github.com/nodejs/LTS
>
> LTS Status   : Release: Active LTS Start: Active LTS End/Maintenance
> Start: Maintenance End:
> Maintenance: v0.12.x:-:
> 2016-04-01:  2016-12-31:
> Active  :  v4:   2015-10-01:
> 2017-04-01:  2018-04-01:
>
> Yeah... We really need to move to v4. So last week I convert our
> default nodejs packages to, v0.12.x/v4.x/v6.x archives, so they'll
> install the proper set of binaries on the version of nodejs:
>
> cloud9
> bonescript
> bone101
> node-red
> google-iot
> wificonfig
>
> For users who do not want the v4 nodejs, the 2016-11-06 image here:
> http://beagleboard.org/latest-images is still v0.12.x
>
> Second for X15 users, a little gift from Julien, he got the
> gc320/etnaviv open source 2D working on the X15. ;)

One, oddity, that doesn't make sense on this..  2D acceleration isn't
working when booting off the eMMC... (even if you place the microSD
into the slot early on bootup)..

So, microSD only rootfs,  (BeagleBoard X15 - B1 board)

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYg8CoGuu_LXSOf8bB2xg9CCyjf2CCU2q0KZooQ9qHABCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] dtb-rebuilder

[Robert Nelson]

Hi Neil,

On Tue, Nov 22, 2016 at 12:59 PM, Neil Jubinville
 wrote:
> In this repo https://github.com/RobertCNelson/dtb-rebuilder
>
> The make script allows us to rebuild then make install the files.
>
> This is all fine.
>
> I am curious if the make script can take a parameter such as a kernel
> version.
>
> In my automation I run  "/opt/tools/update_kernel.sh   "
> which works great.
>
> After that step I want to rebuilt the DTBs and install them.  The problem
> however is that the beaglebone has not yet rebooted at that point so the OS
> runtime at that moment is on the previous kernel.
>
> The make script uses 'uname -r' to fill in the spots where things are built
> / installed.
> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/Makefile
>
> What is the method to pass in a kernel version into this script?   I am not
> a pro at Make files so knowing all about what is going on in that particular
> script is a work in progress.  I can see where uname -r is used .
>
> My goal is to rebuild and place the dtbs before the reboot so it can boot
> with the proper base dtb.

Yeah, we will need to patch the makefile for that...

How about this:

https://github.com/RobertCNelson/dtb-rebuilder/commit/5e25af5781a31672a919ed63c34c5eca9df66e6b

sudo make KERNEL_VERSION=4.5 install

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYj7Ub7YTvVX8gOOnJoqdF8hOCgg1PbLx_vVUH-KJC3NBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] debian testing: 2016-11-22 (nodejs v4.x)

[Robert Nelson]

Howdy!

So there's a little something new and special in this week's snapshot:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-11-21

First, nodejs v0.12.x is almost EOL: https://github.com/nodejs/LTS

LTS Status   : Release: Active LTS Start: Active LTS End/Maintenance
Start: Maintenance End:
Maintenance: v0.12.x:-:
2016-04-01:  2016-12-31:
Active  :  v4:   2015-10-01:
2017-04-01:  2018-04-01:

Yeah... We really need to move to v4. So last week I convert our
default nodejs packages to, v0.12.x/v4.x/v6.x archives, so they'll
install the proper set of binaries on the version of nodejs:

cloud9
bonescript
bone101
node-red
google-iot
wificonfig

For users who do not want the v4 nodejs, the 2016-11-06 image here:
http://beagleboard.org/latest-images is still v0.12.x

Second for X15 users, a little gift from Julien, he got the
gc320/etnaviv open source 2D working on the X15. ;)

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYjrWGw%2BJ-QQbC6SNifu%2BDz6raGakZ8eumOA%3Ds6B2E_-9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: EMMC Flasher not working, hangs on rsync

[Robert Nelson]

On Tue, Nov 22, 2016 at 1:57 PM, Dennis Lee Bieber
 wrote:
> On Tue, 22 Nov 2016 11:01:04 -0600, Robert Nelson
>  declaimed the
> following:
>
> 
>
>>
>>usr0 - turn on - on boot starting
>>usr1 - turn on - starting scan of mmc0 (microSD)
>>
>>/uEnv.txt (boot) *default use for comparability with old images..
>>usr2 - turn on - found /uEnv.txt
>>usr3 - turn on - running u-boot cmd: uenvcmd
>>
> 
> So if I understand the description from Mr. Watts, his board is never
> finding anything after looking at the non-installed SD card.
>
>>/boot/uEnv.txt  *default set by "eMMC flasher"
>>usr2 - turn on - found /boot/uEnv.txt
>>usr3 - turn on - running u-boot cmd: uname_boot
>>
>>usr3 - turn off
>>usr2 - turn off
>>usr1 - turn off
>>Starting Scan off mmc1 (eMMC)
>>
> Either mine boots too fast too tell, or it follows a different 
> sequence
> ... This implies that after the scan of SD card it drops back to usr0
> on, usr1 off, and then should go usr2 on, usr3 on... But I don't see it
> when booting without an SD card -- appeared to cycle to all 4 on, then jump
> to off/on/off/on (0/1/2/3), before normal activity (heartbeat, eMMC, cpu
> flickers)
>
> In either case, it would seem that the problem board is never finding
> /a/ boot configuration file when booting from eMMC. Since the problem board
> also seems to never be recognized by the Mac OS even when booting from SD
> card, I have no further ideas... either a debug serial adapter, or USB
> keyboard/mouse and HDMI cable to a TV, to try examining the eMMC contents
> after booting from SD card.

A serial cable would help. ;)

>
>>/uEnv.txt (boot) *default use for comparability with old images..
>>usr2 - turn on - found /uEnv.txt
>>usr3 - turn on - running u-boot cmd: uenvcmd
>>
>>/boot.scr (for debian)
>>usr2 - turn on - found /boot.scr
>>usr3 - turn on - running u-boot cmd: bootscript
>>
>>/boot/boot.scr (for debian)
>>usr2 - turn on - found /boot/boot.scr
>>usr3 - turn on - running u-boot cmd: bootscript
>>
>>/boot/uEnv.txt  *default set by "eMMC flasher"
>>usr2 - turn on - found /boot/uEnv.txt
>>usr3 - turn on - running u-boot cmd: uname_boot
>>
>>aka... it doesn't actually tell you much, unless it get's stuck..
>>
>
> HEH... Especially when my eMMC (running Wheezy
> debian@beaglebone:/$ uname -a
> Linux beaglebone 3.8.13-bone80 #1 SMP Wed Jun 15 17:03:55 UTC 2016 armv7l
> GNU/Linux ) doesn't seem to have /uEnv.txt, /boot.scr, or /boot/boot.scr,
> just /boot/uEnv.txt -- SDcard image does have /uEnv.txt though... You've
> actually got me wondering how mine even boots...

the first three are optional:

http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

the first one /uEnv.txt allows us to support the really really old
angstrom version of u-boot.. If you look very close at your /uEnv.txt
so you'll see actually reading /boot/uEnv.txt .;)

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYihqLvqyDzC1t3Ukr2Jb4U7_LrCyFrJPns%2Bv%3D7TeA6Kcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Issue with WiFi USB adapter on BBB

[Robert Nelson]

On Tue, Nov 22, 2016 at 1:20 PM,   wrote:
> Hello All,
>
> I'm using BeagleBone Black as a TCP client which sends a TCP packet every 5
> seconds and the same packet is echoed by the server immediately and I'm
> measuring the RTT (Round Trip Time). I'm using Edimax WiFi USB adapter. The
> RTT measured was ridiculously high (400ms) and I eventually found out its
> because the BBB suspends power to the adapter every few milliseconds (if
> there is no activity). I can see the current toggling between 80mA and 0
> through an ammeter. Its because of this toggle, the RTT shoots up. I have
> disabled the auto suspend for the USB. Some observations
>
> The same WIFI adapter plugged into a computer (Linux and windows) running
> the same code works fine (with and without change to the autosuspend
> settings). No toggling of power and a steady 40ms RTT is observed. Also blue
> LED on adapter is stable.
> I powered the the USB through a hub(powered externally) and connected it to
> BBB and it still exhibits the issue
> The toggling of power can be observed with the blue led on the edimax
> adapter which remains constant when connected to other computers but blinks
> when connected to BBB. Cross checked with an ammeter.
> When I keep the adapter busy on BBB (by sending the packet every 500ms
> instead of 2s), the adapter consumes a steady 80mA and the RTT is stable at
> 40ms
>
>
> I have played around with the autosuspend settings (by writing -1 to
> autosuspend for the usb device), powered through hub etc. but the problem
> persists.

Have you disable power management?

sudo iwconfig wlan0 power off


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYguq%2B%3DbuVYawp6M9g8TsMwbxsJ9cROsXPrZwN_KSkD8nA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Issue with WiFi USB adapter on BBB

[agm6274]

Hello All,

I'm using BeagleBone Black as a TCP client which sends a TCP packet every 5 
seconds and the same packet is echoed by the server immediately and I'm 
measuring the RTT (Round Trip Time). I'm using Edimax WiFi USB 
adapter.
 
The RTT measured was ridiculously high (400ms) and I eventually found out 
its because the BBB suspends power to the adapter every few milliseconds 
(if there is no activity). I can see the current toggling between 80mA and 
0 through an ammeter. Its because of this toggle, the RTT shoots up. *I 
have disabled the auto suspend for the USB.* Some observations

   1. The same WIFI adapter plugged into a computer (Linux and windows) 
   running the same code works fine (with and without change to the 
   autosuspend settings). No toggling of power and a steady 40ms RTT is 
   observed. Also blue LED on adapter is stable. 
   2. I powered the the USB through a hub(powered externally) and connected 
   it to BBB and it still exhibits the issue 
   3. The toggling of power can be observed with the blue led on the edimax 
   adapter which remains constant when connected to other computers but blinks 
   when connected to BBB. Cross checked with an ammeter. 
   4. When I keep the adapter busy on BBB (by sending the packet every 
   500ms instead of 2s), the adapter consumes a steady 80mA and the RTT is 
   stable at 40ms
   

I have played around with the autosuspend settings (by writing -1 to 
autosuspend for the usb device), powered through hub etc. but the problem 
persists. 

Can anyone suggest if I'm missing something obvious. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b353a7b5-38a5-416f-a4a1-096f7b7c2ee7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] writing to [/dev/mmcblk1] failed using bbb-eMMC-flasher-eewiki-ext4.sh

[Matt]

Hi RC,

Thanks for the confirmation.

I too have since gotten it to work on a number of BBBs, however one it 
doesn't like.  The serial output is what I have above ending with the 
busybux and the initramfs prompt.  Not sure what is going on with that 
particular one. 

I'll investigate it more and get back to you.

Thanks again.


On Monday, November 21, 2016 at 8:02:17 PM UTC-8, RobertCNelson wrote:
>
> https://gist.github.com/RobertCNelson/6032eb4a2e3a35de7bce8dd239661605 
>
> Just tested it.. 
>
> Works fine.. 
>
> 1 - flashed emmc old bbb 
> 2 - setup it to run with am335x-boneblack-emmc-overlay.dtb 
> 3 - created eMMC flasher microSD 
> 4 - used the flasher microSD to flash eMMC 
> 5 - succes.. 
>
> So... it's either: 4.4.16-bone-rt-r11 or your 
> am335x-boneblack-emmc-overlay.dtb 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6a331a25-98a1-4807-99dd-033934eeb783%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] dtb-rebuilder

[Neil Jubinville]

In this repo https://github.com/RobertCNelson/dtb-rebuilder

The make script allows us to rebuild then make install the files.

This is all fine.

I am curious if the make script can take a parameter such as a kernel 
version.

In my automation I run  "/opt/tools/update_kernel.sh   " 
which works great.

After that step I want to rebuilt the DTBs and install them.  The problem 
however is that the beaglebone has not yet rebooted at that point so the OS 
runtime at that moment is on the previous kernel.

The make script uses 'uname -r' to fill in the spots where things are built 
/ installed.
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/Makefile

What is the method to pass in a kernel version into this script?   I am not 
a pro at Make files so knowing all about what is going on in that 
particular script is a work in progress.  I can see where uname -r is used .

My goal is to rebuild and place the dtbs before the reboot so it can boot 
with the proper base dtb.

Thx,

Neil

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4fe35890-df12-49b3-b12c-79070d9937b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: EMMC Flasher not working, hangs on rsync

[Robert Nelson]

On Tue, Nov 22, 2016 at 10:47 AM, Dennis Lee Bieber
 wrote:
> On Tue, 22 Nov 2016 06:24:10 -0800 (PST), "'Ian Watts' via BeagleBoard"
>  declaimed the
> following:
>
>
>>cycle simply results in the BBB 'hanging' with Usr LEDs 0 and 1 permanently
>>ON and nothing else happening !
>>
> LED-1 normally indicates SD card access, while -0 is a "heartbeat"...
> If nothing has corrupted the normal pin configuration and thereby
> preventing the back-ground tasks from activating...
>
> However... As I recall, a normal boot sequence is to light each LED in
> sequence before it gets to the heartbeat stage. Does the unit get to the
> all-on stage and THEN lock on 0&1, or is it only starting with 0, 1, and
> never getting to 2 and 3?
>
> Unfortunately, I haven't seen any documentation for what each stage of
> the LED sequence represents -- and can't find anything obvious that might
> toggle them... May be built into the uboot image, or the various other
> memory images that get loaded to start the system.

in u-boot:

usr0 - 53
usr1 - 54
usr2 - 55
usr3 - 56

usr0 - turn on - on boot starting
usr1 - turn on - starting scan of mmc0 (microSD)

/uEnv.txt (boot) *default use for comparability with old images..
usr2 - turn on - found /uEnv.txt
usr3 - turn on - running u-boot cmd: uenvcmd

/boot.scr (for debian)
usr2 - turn on - found /boot.scr
usr3 - turn on - running u-boot cmd: bootscript

/boot/boot.scr (for debian)
usr2 - turn on - found /boot/boot.scr
usr3 - turn on - running u-boot cmd: bootscript

/boot/uEnv.txt  *default set by "eMMC flasher"
usr2 - turn on - found /boot/uEnv.txt
usr3 - turn on - running u-boot cmd: uname_boot

usr3 - turn off
usr2 - turn off
usr1 - turn off
Starting Scan off mmc1 (eMMC)

/uEnv.txt (boot) *default use for comparability with old images..
usr2 - turn on - found /uEnv.txt
usr3 - turn on - running u-boot cmd: uenvcmd

/boot.scr (for debian)
usr2 - turn on - found /boot.scr
usr3 - turn on - running u-boot cmd: bootscript

/boot/boot.scr (for debian)
usr2 - turn on - found /boot/boot.scr
usr3 - turn on - running u-boot cmd: bootscript

/boot/uEnv.txt  *default set by "eMMC flasher"
usr2 - turn on - found /boot/uEnv.txt
usr3 - turn on - running u-boot cmd: uname_boot

aka... it doesn't actually tell you much, unless it get's stuck..

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhDHm2EojEgswgpr8Wfj49wrVRVTm-xKHcoZtgqxFHQkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] LCD7 doesn't work on latest debian lxqt image

[Robert Nelson]

On Tue, Nov 22, 2016 at 10:40 AM, IZYBoard  wrote:
> bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img on a beaglebone white:
>
> the same lcd7 cape  that worked in older kernels is absolutely dead
>
>
>
> At power on , on old kernels TUX penguin appears before booting up, with
> last image, display is black from start.
>
>
> Old Kernel :
>
> root@arm:~# cat /sys/devices/bone_capemgr.8/slots
>  0: 54:P---L BeagleBone LCD7 CAPE,00A2,Beagleboardtoys,BB-BONE-LCD7-01
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>
>
> New one:
>
> root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots
>  0: P---L-   0 BeagleBone LCD7 CAPE,00A2,Beagleboardtoys,BB-BONE-LCD7-01
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>
> Display is detected ,anyway
>
> Played for long time with uEnv.txt with no results..
>
> Any suggestion please ??

dtb=am335x-boneblack-overlay.dtb

display is black till drm/tilcd comes up..   video is very racy,
planning to shove all the lcd capes into u-boot..

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYh8XSt3VAFeEQm5uGzOet-jBq3U5L4VvJECyXa0PyrjNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] LCD7 doesn't work on latest debian lxqt image

[IZYBoard]

bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img on a beaglebone white:

the same lcd7 cape  that worked in older kernels is absolutely dead



At power on , on old kernels TUX penguin appears before booting up, with 
last image, display is black from start.


Old Kernel :

root@arm:~# cat /sys/devices/bone_capemgr.8/slots
 0: 54:P---L BeagleBone LCD7 CAPE,00A2,Beagleboardtoys,BB-BONE-LCD7-01
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---


New one:

root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots
 0: P---L-   0 BeagleBone LCD7 CAPE,00A2,Beagleboardtoys,BB-BONE-LCD7-01
 1: PF  -1 
 2: PF  -1 
 3: PF  -1 

Display is detected ,anyway

Played for long time with uEnv.txt with no results..

Any suggestion please ??


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/454d8f9c-38c3-4bb6-a672-b455f1a35dc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: EMMC Flasher not working, hangs on rsync

[Graham]

On Tuesday, November 22, 2016 at 10:33:32 AM UTC-6, Graham wrote:
>
> Ian:
>
> Go to:
>
> http://rcn-ee.net/rootfs/bb.org/testing/2016-05-13/lxqt-4gb/
>
> And download:
>
> BB-blank-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz
>
> "blank" means flasher.
>
> This is the eMMC flasher version of a previous release that I run.
>
> --- Graham
>
> ==
>
> Correction:
Should be:

BBB-blank-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz 

--- Graham

==

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b93bfe02-1e18-4743-980e-4180b2b2d69b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: EMMC Flasher not working, hangs on rsync

[Graham]

Ian:

Go to:

http://rcn-ee.net/rootfs/bb.org/testing/2016-05-13/lxqt-4gb/

And download:

BB-blank-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz

"blank" means flasher.

This is the eMMC flasher version of a previous release that I run.

--- Graham

==

On Tuesday, November 22, 2016 at 8:24:10 AM UTC-6, Ian Watts wrote:
>
>
> Felipe,
> Thanks for that.
> I'm pretty new to the BBB (mine's a 4GB Rev C unit) and was using the 
> Network-over-USB method to ssh into it via Terminal on one of my Macs. I 
> run 2 x Macs on Sierra with the necessary HoRNDIS and FTDI drivers 
> installed. All was good - until I managed to flash the eMMC with the latest 
> Debian image (to be fair I did mess around quite a lot initially trying to 
> follow various posts on the topic until I realised that the uEnv.txt file I 
> was looking for was on the uSD card and NOT in the eMMC root folder... I 
> mention this because I may have screwed something up in getting there !)
>
> However, the fact is that now that the update is complete I cannot log 
> back in to the BBB. Neither does it present itself anymore as a Network 
> device... Driving me mad...
> It does, however, power up and appears (from the Usr LEDs) to be booting 
> correctly with Debian 8 installed from the uSD card... but I can't 'see' 
> the BBB anymore from my Mac over USB.
>
> OK... so, not having a serial/USB adapter I though the simplest method 
> would be to re-flash the eMMC with a 'Flasher image' -ie- one that does NOT 
> require me to modify the uEnv. txt file (because I can't log in to 
> accomplish this). Seemed a pretty simple idea - restore my semi-bricked BBB 
> to default condition. My problem now is I can't find a Flasher image (one 
> where the uEnv.txt file is already modified to auto-flash the eMMC) to work 
> with that works.
>
> I've located and downloaded two images, formatted my uSD card and bit 
> copied over the image to the uSD card, powered down the BBB (external 2A 
> PSU), inserted the uSD card and powered on to have the Usr LEDs do their 
> cylon scan 'thing' and stop with all LEDs lit. A subsequent power down / up 
> cycle simply results in the BBB 'hanging' with Usr LEDs 0 and 1 permanently 
> ON and nothing else happening !
>
> If I power down, switch the uSD card for a Debian 8 (non-auto flasher) 
> image and power up, all, once again, appears well with the BBB - Usr LEDs 
> wise - BUT I still can't log in via Terminal or see the BBB as an available 
> network device or log in via a browser...
>
> I have ordered a suitable Serial/USB adapter but it won't be here for a 
> week or so and I'm getting very frustrated and impatient to make some 
> progress - even if it's just to be able to log in again via ssh / browser !!
>
> So, I guess where I think I'm at is that I need a verified (auto - already 
> modified uEnv.txt file) 4GB Flasher image (any age / version of Debian) so 
> that I can re-start with the BBB... without making whatever mistake I made 
> in the process of getting as far as I got to the last time !!
>
> I do have a windows laptop that I could also use but haven't used Win 
> (it's XP) for years now.
>
> Anyone have any ideas on where to get a verified working auto FLASHER 
> image form please ?
>
> My logic is that flashing that image back into the eMMC would fix any/all 
> of my cock-ups and enable me to log in once more from Terminal / a 
> browser...
>
> Open to any and all thoughts. Thanks again for your help.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fe890308-23e4-46ac-9dcc-eefae04b9d9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Flashing a BBB's EMC from uSD Card - problems

[Robert Nelson]

On Tue, Nov 22, 2016 at 10:21 AM, Stéphane Charette
 wrote:
> On Tue, Nov 22, 2016 at 7:36 AM, 'Ian Watts' via BeagleBoard
>  wrote:
>>
>> ...
>> although it will not complete a boot sequence via the built-in eMMC (not
>> so good news)
>> it WILL complete a boot sequence via the uSD card (-2-) (good news) and it
>> does appear to (re-) flash the eMMC from uSD card (-1-) when a Flasher image
>> is inserted.
>>
>> My questions :
>> Why ? Anyone with any bright ideas ?
>
>
>
> Two ideas that may help you.  Both of these have saved me in the last few
> months:
>
> (1)
> Instead of using dd to write the image to the uSD card, I now use Etcher.
> It verifies that the image has been written correctly.  This has solved a
> number of strange problems that I was seeing every once in a while.
> https://etcher.io/

Yeah, etcher is a + ;)

>
> (2)
> Before inserting the uSD card into the BB, edit these files on it:
> .../opt/scripts/tools/eMMC/*
> Look for all the places where "ext4_options" is defined.  Everywhere you see
> this:
> ext4_options="-c ...
> Change it to instead say this:
> ext4_options="-cc ...
>
> See man mkfs.ext4(8) which says this:
>
>> -c Check the device for bad blocks before creating the file
>> system.  If this option is specified twice, then a slower read-write test is
>> used instead of a fast read-only test.
>
>
> It takes about an hour (?) for flasher to run to completion with -cc, but
> this solved *all* my strange problems that only I was seeing.  Turns out
> some bad sectors on the eMMC would guarantee that the installation would
> fail in mysterious ways.

With how much "-c" and "-cc" slow things down, what would be a good
"manual" way to enable this...

Special variable in /boot/uEnv.txt ?

#eMMC_flashing="-c"
#eMMC_flashing="-cc"

???

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYiwPu-hWfv%2B6UixOP2nBq7MNTFAbCC8P9Jq5yrHefHJEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Flashing a BBB's EMC from uSD Card - problems

[Stéphane Charette]

On Tue, Nov 22, 2016 at 7:36 AM, 'Ian Watts' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> ...
> although it will not complete a boot sequence via the built-in eMMC (not
> so good news)
> it WILL complete a boot sequence via the uSD card (-2-) (good news) and it
> does appear to (re-) flash the eMMC from uSD card (-1-) when a Flasher
> image is inserted.
>
> My questions :
> Why ? Anyone with any bright ideas ?
>


Two ideas that may help you.  Both of these have saved me in the last few
months:

*(1)*
Instead of using dd to write the image to the uSD card, I now use Etcher.
It verifies that the image has been written correctly.  This has solved a
number of strange problems that I was seeing every once in a while.
https://etcher.io/

*(2)*
Before inserting the uSD card into the BB, edit these files on it:
 .../opt/scripts/tools/eMMC/*
Look for all the places where "ext4_options" is defined.  Everywhere you
see this:
ext4_options="-c ...
Change it to instead say this:
ext4_options="-cc ...

See man mkfs.ext4(8) which says this:

-c Check the device for bad blocks before creating the file system.
>  If this option is specified twice, then a slower read-write test is used
> instead of a fast read-only test.


It takes about an hour (?) for flasher to run to completion with -cc, but
this solved *all* my strange problems that only I was seeing.  Turns out
some bad sectors on the eMMC would guarantee that the installation would
fail in mysterious ways.

Stéphane

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BHxBULQ0Cc0GFsHEGc0-KLq1jwMjrMLGjwrSY36rxpCTa-ExA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Flashing a BBB's EMC from uSD Card - problems

['Ian Watts' via BeagleBoard]

Thanks Dennis, I appreciate your help / thoughts...

Hmmm... to summarise where I'm at :
I have a BBB (Rev C / 4GB) with an external 2A PSU and 2 x 4GB uSD Cards.
On Card-1- I have a 4GB FLASHER image (Debian 
8.6-lxqt-4gb-armhf-2016-11-06-4gb.img). To me this is an image that will 
effect an eMMC AUTOMATICALLY upon boot - i.e. it already has the uEnv.txt 
file modified to effect the flash, meaning I don't need to gain access to 
the BBB to modify the file myself.
On Card-2- I have a 'non-flasher' image of Debian 8 
(Debian-8.6-lxqt-4gb-armhf-2016-10-30-4gb.img)

So,
Powered UP : Brand new out-of-the-box BBB (no uSD card inserted, boot from 
eMMC with supplied 2014 Debian Distro)
;-)  correct power up as per the UserLEDs
:-)  the unit presented itself to the network (Network-ove-USB cable) on 
192.168.7.2
:-)  I could ssh in via Terminal (Mac)
:-)  I could browse to it via 192.168.7.2 from Safari and Chrome.

Updated the Image from the supplied 2014 Debian Distro to the 2016 8.6 
Debian Distro
:-)  All went well, Cylon lights -> all four UsrLEDs ON. a simple 'cat' of 
the ID.txt file indicated the new Distro

Powered DOWN... and my problems began...

Power UP : Debian 8.6 with no card inserted :
*;-(  incorrect power up. After 60 s (or so) UsrLEDs stop flashing leaving 
UsrLEDs 0 & 1 On and UsrLEDs 2 & 3 OFF*
:-(  the unit does not present itself to the network (Network-ove-USB cable)
:-(  the unit does not present itself to the network with an RJ45 Ethernet 
cable connected (I'm using my Lan Printer cable for this - just disconnect 
it from the printer and reconnect it to the BBB and cycle power on the 
network switch.
;-(  It's not possible to ssh in via terminal (Mac) or browse (192.168.7.2) 
to it via Safari or Chrome.
Unit appears to have stalled during boot...

Power UP : *Debian 8.6 with uSD Card-1- inserted* (no boot switch needed, 
simply apply power) :
;-)  correct power up. After 45 s (or so) UsrLEDs stop flashing and begin 
the 'cylon sweep'...
:-) correct (?) eMMC Flash completed - All 4 UsrLEDs ON

Power DOWN... Remove uSD Card

Power UP : *Debian 8.6 eMMC no uSD Card inserted*
;-(  incorrect power up. After 60 s (or so) UsrLEDs stop flashing leaving 
UsrLEDs 0 & 1 On and UsrLEDs 2 & 3 OFF
:-(  the unit does not present itself to the network (Network-ove-USB cable)
:-(  the unit does not present itself to the network with an RJ45 Ethernet 
cable connected (I'm using my Lan Printer cable for this - just disconnect 
it from the printer and reconnect it to the BBB and cycle power on the 
network switch.
;-(  It's not possible to ssh in via terminal (Mac) or browse (192.168.7.2) 
to it via Safari or Chrome.
Unit appears to have stalled during boot...

Power DOWN... Insert uSD Card-2-

Power UP : *Debian 8.6 eMMC and Debian 8.6 uSD Card-2- inserted*
;-)  correct (?) power up. Various UsrLEDs flash, flash, flash...
:-(  the unit does not present itself to the network (Network-ove-USB cable)
:-(  the unit does not present itself to the network with an RJ45 Ethernet 
cable connected (I'm using my Lan Printer cable for this - just disconnect 
it from the printer and reconnect it to the BBB and cycle power on the 
network switch.
;-(  It's not possible to ssh in via terminal (Mac) or browse (192.168.7.2) 
to it via Safari or Chrome.
Unit appears to be working (UsrLEDs flash away quite happily) BUT that's 
it...
*Note the difference between uSD card inserted (here, uSD card Boot) and 
uSD card absent (above, eMMC boot)*

Power DOWN... Remove uSD Card

Power UP : *Debian 8.6 eMMC no uSD Card inserted*
;-(  incorrect power up. After 60 s (or so) UsrLEDs stop flashing leaving 
UsrLEDs 0 & 1 On and UsrLEDs 2 & 3 OFF
:-(  the unit does not present itself to the network (Network-ove-USB cable)
:-(  the unit does not present itself to the network with an RJ45 Ethernet 
cable connected (I'm using my Lan Printer cable for this - just disconnect 
it from the printer and reconnect it to the BBB and cycle power on the 
network switch.
;-(  It's not possible to ssh in via terminal (Mac) or browse (192.168.7.2) 
to it via Safari or Chrome.
Unit appears to have stalled during boot (again)...

So, I conclude :
My BBB is NOT yet bricked (good news) because :
although it will not complete a boot sequence via the built-in eMMC (not so 
good news)
it WILL complete a boot sequence via the uSD card (-2-) (good news) and it 
does appear to (re-) flash the eMMC from uSD card (-1-) when a Flasher 
image is inserted.

My questions :
Why ? Anyone with any bright ideas ?

The way ahead ?
Try the BBB on a Windows machine ? (I'm thinking network issues - but on 
BOTH my Macs ? ? ?)
Wait for the Serial->USB adapter to arrive, connect it, power up and 
monitor the BBB's actions via a terminal ?

Anyone with any ideas at all ?

Thank you.
Ian

On Sunday, 13 November 2016 18:34:46 UTC+1, Dennis Lee Bieber wrote:
>
>
> Talking to myself in public... a bad sign... 
>
> On Sun, 13 Nov 2016 12:07:05 -0500, Dennis Lee Bieber 
> 

[beagleboard] Re: EMMC Flasher not working, hangs on rsync

['Ian Watts' via BeagleBoard]

Felipe,
Thanks for that.
I'm pretty new to the BBB (mine's a 4GB Rev C unit) and was using the 
Network-over-USB method to ssh into it via Terminal on one of my Macs. I 
run 2 x Macs on Sierra with the necessary HoRNDIS and FTDI drivers 
installed. All was good - until I managed to flash the eMMC with the latest 
Debian image (to be fair I did mess around quite a lot initially trying to 
follow various posts on the topic until I realised that the uEnv.txt file I 
was looking for was on the uSD card and NOT in the eMMC root folder... I 
mention this because I may have screwed something up in getting there !)

However, the fact is that now that the update is complete I cannot log back 
in to the BBB. Neither does it present itself anymore as a Network 
device... Driving me mad...
It does, however, power up and appears (from the Usr LEDs) to be booting 
correctly with Debian 8 installed from the uSD card... but I can't 'see' 
the BBB anymore from my Mac over USB.

OK... so, not having a serial/USB adapter I though the simplest method 
would be to re-flash the eMMC with a 'Flasher image' -ie- one that does NOT 
require me to modify the uEnv. txt file (because I can't log in to 
accomplish this). Seemed a pretty simple idea - restore my semi-bricked BBB 
to default condition. My problem now is I can't find a Flasher image (one 
where the uEnv.txt file is already modified to auto-flash the eMMC) to work 
with that works.

I've located and downloaded two images, formatted my uSD card and bit 
copied over the image to the uSD card, powered down the BBB (external 2A 
PSU), inserted the uSD card and powered on to have the Usr LEDs do their 
cylon scan 'thing' and stop with all LEDs lit. A subsequent power down / up 
cycle simply results in the BBB 'hanging' with Usr LEDs 0 and 1 permanently 
ON and nothing else happening !

If I power down, switch the uSD card for a Debian 8 (non-auto flasher) 
image and power up, all, once again, appears well with the BBB - Usr LEDs 
wise - BUT I still can't log in via Terminal or see the BBB as an available 
network device or log in via a browser...

I have ordered a suitable Serial/USB adapter but it won't be here for a 
week or so and I'm getting very frustrated and impatient to make some 
progress - even if it's just to be able to log in again via ssh / browser !!

So, I guess where I think I'm at is that I need a verified (auto - already 
modified uEnv.txt file) 4GB Flasher image (any age / version of Debian) so 
that I can re-start with the BBB... without making whatever mistake I made 
in the process of getting as far as I got to the last time !!

I do have a windows laptop that I could also use but haven't used Win (it's 
XP) for years now.

Anyone have any ideas on where to get a verified working auto FLASHER image 
form please ?

My logic is that flashing that image back into the eMMC would fix any/all 
of my cock-ups and enable me to log in once more from Terminal / a 
browser...

Open to any and all thoughts. Thanks again for your help.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6ff0633a-abb9-4b8c-aa6e-000ce9deb094%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone Green Wireless Wi-Fi

[devabhag]

Hi all,

I recently bought a BBGW and I am trying to send files from my laptop 
(running linux mint) to the BBGW and forth but I am experiencing very poor 
speeds - 9 Mbps. I have tried various methods such as rsync and scp but the 
speed does not change.

I tried using netcast to check the maximum throughput and got 3 MBps. 

Does anybody know the fastest way to send file from the BBGW to a laptop 
and vice versa? 

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/09067ea2-b256-47bb-bf78-a83f520ef845%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB with cape 7inch LCD faulty screen

[Kevin Gordon]

I have built a new host from debian-8.6.0-amd64-CD-1.iso and included 
eclipse mars.2 with debugging for 
bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz installed on a BBB 
with a 7 inch LCD cape.
At the beginning of uEnv.txt I included as a first line:
dtb=am335x-boneblack-emmc-overlay.dtb
For file capemgr:
root@beaglebone:/etc/default# nano capemgr
  GNU nano 2.2.6   File: capemgr
# Default settings for capemgr. This file is sourced by /bin/sh from
# /etc/init.d/capemgr.sh
# Options to pass to capemgr
CAPE=BB-BONE-LCD7-01:00A3
I added the above last line: CAPE=BB-BONE-LCD7-01:00A3
root@beaglebone:/# cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A3,Override Manuf,BB-BONE-LCD7-01
Which I believe means the cape is loaded.
The above is working satisfactorily except the display is very faint. I can 
turn on the backlight with:
Manually:
root@beaglebone:~# echo 1 > /sys/class/backlight/backlight/bl_power
Or:
echo 1 | sudo tee /sys/class/backlight/backlight/bl_power
Placed in .bashrc
These turned the backlight on but seemed to cause some mouse and screen 
instability. If I don't do this everything is stable but so faint that the 
display is almost unreadable.
This is a first attempt by me. Any comments or improvements would be much 
appreciated.
Many thanks,
Kevin.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7c6fe4e5-9757-47a4-9c24-2d7e5822978f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.