Flashing a BBB's EMC from uSD Card - problems

Hi,
I’m new to the BeagleBoneBlack - sorry !!
I do have a lot of experience with embedded Atmel processors and programming in general.
I have spent hours Googling and trying just about everything I can think of to re-falsh my BBB with Debian 8.4 (Jessie 2016-05-13) with no luck.
I’ll try and explain; please forgive my newbie-ness to the BBB, my utter frustration and, probably, not providing enough info at this time. Here goes.

I have a BBB running a 2014 Linux Distro (the one the BBB came with).
I run on both a Mac mini and a MacBookPro (both 2014 with OSX-Sierra).
I can connect to the BBB; mini-USB to Mac (SSH via Terminal) and web-browser (192.168.7.2).
I downloaded bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz from BB.org.
I unzipped it.
I used Raspberry Pi Baker to write the image file to my 4GB uSD card.
I managed to boot the BBB from the new Linux Distro (Debian 8.4 - Jessie 2016-05-13). I know this to be the case because a successful login responds with the current Distro version.

To my problem :
I have tried a lot over the past few weeks and may be little mixed up but :
To boot from the uSD card (once I had a new Linux Distro - 2016) on it) I simply held the Boot button depressed whilst cycling the Rest button, waiting till all 4 Usr LEDs lit and releasing the Boot button. Took me a while to get there but… pretty simple in the end.
I was under the misconception that this would flash the eMMC. Naturally, upon removal of the uSD card and resetting the BBB I simply ended up with the original (as shipped - 2014) version of the Distro. Repeat the boot-from-uSD sequence again and I was back to the new 2016 Distro. Sweet - kind of ! But not flashing of the eMMC…

So, to be fair there is rather a lot of mixed up info on the web. I put this down to the various versions of BBBs and the various Distros etc but… confusing to a total newbie…
So, what I THINK I have to do is modify the uEnv.txt file (on my BBB, this is found in the /Boot/uBoot directory) by removing the “#” at the beginning of the line cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh.
To be fair my uEnv.txt file doesn’t have this line so I copied and pasted it as the last line of the file. I used ‘nano’ from within Terminal to accomplish this… Unfortunately, rebooting the BBB did not result in an EMC flash - at least no obvious difference in Usr LEDs (no cylon-style ‘swiping’, no automatic reboot and more and no all-4 Usr LEDs lit - even after an hour or more).

I now also find that :
-1- rebooting the BBB without uSD card inserted results in the original 2014 Distro (eMMC) being loaded, whilst
-2- rebooting the BBB with uSD card inserted (new Linux 8.4 2016 Distro) results in the BBB’s network service (SystemPreferences/Network pane) reporting the BBB trying to connect (it doesn’t in fact) with some wierd but fixed IP address. Logging in via Terminal is refused as is trying to land the 192.168.7.2 page from my web browser (both Safari and Chrome)…

I have struggled with this for days…

Would somebody be able to assist please. Any / all pointers and help will be greatly appreciated.

Thanks a million in advance - if only for reading this right to the end !

On Wed, 9 Nov 2016 15:16:44 -0800 (PST), "'Ian Watts' via BeagleBoard"
<beagleboard@googlegroups.com> declaimed the
following:

I have a BBB running a 2014 Linux Distro (the one the BBB came with).

  First question: what variation of the BBB... As I recall, only the rev
C have a 4GB eMMC; older BBBs can't be flashed with the full 4GB releases,
you have to use a 2GB reduced OS for flashing.

So, what I THINK I have to do is modify the uEnv.txt file (on my BBB, this
is found in the /Boot/uBoot directory) by removing the "#" at the beginning
of the line cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh.
To be fair my uEnv.txt file doesn't have this line so I copied and pasted
it as the last line of the file. I used 'nano' from within Terminal to
accomplish this... Unfortunately, rebooting the BBB did not result in an

  You have to edit the line in the copy of uEnv.txt ON THE SD CARD, not
the one on the eMMC... Which essentially means booting with the SD card,
THEN editing the file, followed by rebooting.

  Note that once you've edited that file on the card, the card will
always start a flash operation when used for booting (you might be able to
install/mount it after booting off the eMMC and editing the card's uEnv.txt
again to disable flashing, though it may be easier to just use the computer
to reimage the card).

  Second note: once you succeed, you may find you don't have to use the
boot select button -- the newer images seem to be rigged so that if the SD
card is installed at boot time, they make the card the file system root for
the rest of the boot process.

I have spent hours Googling and trying just about everything I can think of to re-falsh my BBB with Debian 8.4 (Jessie 2016-05-13) with no luck.

In case this helps, I documented how I got started a little while ago. You can find my ramblings here: Programming Comments - BeagleBone Black, BeagleBone Green, and Ubuntu

Stéphane

Thanks Stephane. Going to look at that now…

In case this helps, I documented how I got started a little while ago. You can find my ramblings here: https://www.ccoderun.ca/programming/2015-06-07_BeagleBoneBlack/index.html

Appreciated. I’ll revert with my findings.

On Thu, 10 Nov 2016 13:51:10 -0800 (PST), "'Ian Watts' via BeagleBoard"
<beagleboard@googlegroups.com> declaimed the
following:

On Wed, 9 Nov 2016 15:16:44 -0800 (PST), "'Ian Watts' via BeagleBoard"
<beagl...@googlegroups.com <javascript:>> declaimed the
following:

  <SNIP>

--
        Wulfraed Dennis Lee Bieber AF6VN
    wlf...@ix.netcom.com <javascript:> HTTP://wlfraed.home.netcom.com/

  Did you have any additional comment? All that I saw is a quote of my
response.

Hi Dennis,

Thanks for your response (don’t know what happened the first time - I responded to you just before I did to Stephane… wierd - too late in the day I guess ! )

Firstly I thanked you.
Then I confirmed my BBB is a Rev C / 4GB.
Then I wrote about a new (but associated) issue I have and asked a question :
My BBB fires up just fine (presents itself to Network Services - the Network pane in System Preferences - just fine with 192.168.7.2, and allows me to SSH in via tTerminal). All good there !
However, when I power down, insert my 4GB uSD card (I made two identical flares of Debian 8.4 one after the other the other night) and power back up again (‘expecting’ to boot off the uSD card with the new 8.4 Distro on it I get :
-1- the BBB presents itself to Network Services - the Network pane in System Preferences - incorrectly with a ‘Self-Assigned IP’ of 169.254.137.203 and a Subnet Mack of 255.255.0.0 (in lieu of the, ‘more normal’, 192.168.7.2 / 255.255.255.255) and sits there with an orange LED (as opposed to the green one)
-2-

I guess, in my ‘fiddling about’ of the past few days/nights I’ve corrupted something but, for the life of me I can’t think what. As far as I recall I only ‘played’ with the uEnv.text file in /boot/uBoot on the eMMC - not knowing or thinking about mounting the uSD card ! ;-(

Any ideas as to where I should start to focus my attention now please ?

I do (NOW, after your initial response) see that I should be aiming my attention at the uEnv.txt file on the uSD card not on the eMMC (Oops !) but I now don’t have ace to the BBB when the uSD card is inserted… arrggghhh !

What am I, as a noobie - but not too dumb, be likely to have done to cause this please ? It’s difficult for me because I really don’t have a good enough appreciation of HOW this could occur and, therefore, have almost no idea as to where to even begin looking. To boot, I’m even more worried that that more ‘playing’ could make the situation even worse.
For now, I will re-blow the two uSD cards with the same Debian 8.4 image (just in case, although I have a feeling Ive managed to screw up the uEnv file somehow… so I’ll also go take another look at that…

2nd Q (while it occurs to me) is there a way to mount the uSD card from my Mac (I’m thinking I could update the uEnv.txt file from there !!

Regards,
IAN

Update:

I ‘located’ the uSD card - in the //dev (devices, I guess) folder; I simply by noted what changed as I inserted the uSD card and looking at the folder contents before (‘ls dev’ command) and after) In my case (pretty standard, I guess) I saw ‘mmcblk1p1’ was added as I inserted the card (for others having similar issue to myself : mmc=multimedia card, ‘blk1’ = block device 1 (the eMMC is, I think ‘blk0’) and the ‘p1’ = partition 1)

I then created a folder in //dev to ‘house’ the folder & file contents of the uSD. In fact I created a folder called ‘card’ in ‘media’ which was already within the root folder. So, I now have a folder : //media/card. Just for my future reference (and because it made me feel good to ‘own’ :slight_smile: the folder), I then created a realm.txt file within my new folder to remind me when and why I created the folder…

I then ‘mounted’ the uSD card and ‘linked’ its contents to my new folder with :
mount /dev/mmcblk1p1 on /media.card
Terminal responded with :
mount: you didn’t specify a filesystem type for /dev/mmcblk1p1 I will try ext4
/dev/mmcblk1p1 on /media/card type ext4 (rw)

When I then listed the contents of the uSD card with ‘ls /media/card’, Terminal returned the folders and files within the uSD card root folder - Yahaay !

OK… so far so good…

I then located the uEnv.txt file again (BUT, now on the uSD card) and opened it with a view to editing the required ‘flash the eMMC’ line. I was, however, confronted with :

GNU nano 2.2.6 File: uEnv.txt Modified

loadximage=echo debug: [/boot/vmlinuz-${uname_r}] … ; load mmc 0:1 ${loadaddr} /boot/vmlinuz-${uname_r}

loadxfdt=echo debug: [/boot/dtbs/${uname_r}/${fdtfile}] … ;load mmc 0:1 ${fdtaddr} /boot/dtbs/${uname_r}/${fdtfile}

loadxrd=echo debug: [/boot/initrd.img-${uname_r}] … ; load mmc 0:1 ${rdaddr} /boot/initrd.img-${uname_r}; setenv rdsize ${filesize}

loaduEnvtxt=load mmc 0:1 ${loadaddr} /boot/uEnv.txt ; env import -t ${loadaddr} ${filesize};

check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;

loadall=run loaduEnvtxt; run check_dtb; run loadximage; run loadxrd; run loadxfdt;

mmcargs=setenv bootargs console=tty0 console=${console} ${optargs} ${cape_disable} ${cape_enable} root=/dev/mmcblk0p1 rootfstype=${mmcrootfstype} ${cmdline}

uenvcmd=run loadall; run mmcargs; echo debug: [${bootargs}] … ; echo debug: [bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr}] … ; bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr};

cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

As you’ll see, the line was already un-remmed…

Anyways, I powered down the BBB with the ‘Boot’ button depressed and, still depressed, fired it back up again. When I saw all 4 Usr LEDs light up I removed my finger from the ‘Boot’ button. Nothing very different happen… same old heartbeat and sporadic others… no flashing occurred. After 45-60 seconds I’m confronted with ‘just’ the heartbeat LET and nothing else…

Ideas please ?

On Fri, 11 Nov 2016 03:03:30 -0800 (PST), "'Ian Watts' via BeagleBoard"
<beagleboard@googlegroups.com> declaimed the
following:

Hi Dennis,

Thanks for your response (don't know what happened the first time - I
responded to you just before I did to Stephane... wierd - too late in the
day I guess ! )

Firstly I thanked you.
Then I confirmed my BBB is a Rev C / 4GB.
Then I wrote about a new (but associated) issue I have and asked a question
:
My BBB fires up just fine (presents itself to Network Services - the
Network pane in System Preferences - just fine with 192.168.7.2, and allows
me to SSH in via tTerminal). All good there !

  Given your later mention of a Mac, I'm going to have to presume you are
referring to some Mac specific utilities here.

  I don't think I've had the USB 192.168.7.2 address work for me after
the first day setting up my BBB. But that may be because I normally hook a
cat-5 from a switch to the BBB -- and it takes that connection as the
primary IP address (I've got the router now assigning a fixed IP during
DHCP, so at least I don't have crawl through my router config to find the
current client list).

  I've never seen 192.168.7.2 on the Ethernet link.

However, when I power down, insert my 4GB uSD card (I made two identical
flares of Debian 8.4 one after the other the other night) and power back up
again ('expecting' to boot off the uSD card with the new 8.4 Distro on it I
get :
-1- the BBB presents itself to Network Services - the Network pane in
System Preferences - incorrectly with a 'Self-Assigned IP' of
169.254.137.203 and a Subnet Mack of 255.255.0.0 (in lieu of the, 'more
normal', 192.168.7.2 / 255.255.255.255) and sits there with an orange LED
(as opposed to the green one)

  Sorry -- I can't help with this... That 169.254.137.203 looks almost
like it might be ISP-assigned network address.

-2-

I guess, in my 'fiddling about' of the past few days/nights I've corrupted
something but, for the life of me I can't think what. As far as I recall I
only 'played' with the uEnv.text file in /boot/uBoot on the eMMC - not
knowing or thinking about mounting the uSD card ! ;-(

Any ideas as to where I should start to focus my attention now please ?

I do (NOW, after your initial response) see that I should be aiming my
attention at the uEnv.txt file on the uSD card not on the eMMC (Oops !) but
I now don't have ace to the BBB when the uSD card is inserted.... arrggghhh
!

  Try booting without the SD card -- then insert it. Though your eMMC may
be old enough not to automount the SD card; in which case you'll have to
find the instructions on making a mount point and mounting the card in the
file system.

{Booting from eMMC}
Last login: Fri Oct 28 15:14:01 2016 from 192.168.2.109
debian@beaglebone:~$ df
Filesystem 1K-blocks Used
Available Use% Mounted on
rootfs 3706992 2038132
1477220 58% /
udev 10240 0
10240 0% /dev
tmpfs 101668 592
101076 1% /run
/dev/disk/by-uuid/5ad07394-12c6-46b2-b5ff-f183847e90bf 3706992 2038132
1477220 58% /
tmpfs 254160 0
254160 0% /dev/shm
tmpfs 254160 0
254160 0% /sys/fs/cgroup
tmpfs 102400 0
102400 0% /run/user
tmpfs 5120 0
5120 0% /run/lock

{inserted SD card on live BBB}
debian@beaglebone:~$ df
Filesystem 1K-blocks Used
Available Use% Mounted on
rootfs 3706992 2036840
1478512 58% /
udev 10240 0
10240 0% /dev
tmpfs 101668 616
101052 1% /run
/dev/disk/by-uuid/5ad07394-12c6-46b2-b5ff-f183847e90bf 3706992 2036840
1478512 58% /
tmpfs 254160 0
254160 0% /dev/shm
tmpfs 254160 0
254160 0% /sys/fs/cgroup
tmpfs 102400 0
102400 0% /run/user
tmpfs 5120 0
5120 0% /run/lock
/dev/mmcblk1p1 7573848 2049448
5181500 29% /media/rootfs
debian@beaglebone:~$

  Note the new entry at the end. In my case, the card is automounted. If
you don't see a new entry, you may have to try

debian@beaglebone:~$ ls /dev
alarm input mmcblk0boot1 ram3 tty14 tty35
tty56 usbmon2
ashmem kmem mmcblk0p1 ram4 tty15 tty36
tty57 vcs
audio kmsg mmcblk1 ram5 tty16 tty37
tty58 vcs1
autofs log mmcblk1p1 ram6 tty17 tty38
tty59 vcs2
binder log_events mqueue ram7 tty18 tty39
tty6 vcs3
block log_main net ram8 tty19 tty4
tty60 vcs4
btrfs-control log_radio network_latency ram9 tty2 tty40
tty61 vcs5
bus log_system network_throughput random tty20 tty41
tty62 vcs6
char logibone_mem null root tty21 tty42
tty63 vcs7
console loop-control ppp rtc0 tty22 tty43
tty7 vcsa
core loop0 psaux shm tty23 tty44
tty8 vcsa1
cpu_dma_latency loop1 ptmx snd tty24 tty45
tty9 vcsa2
disk loop2 ptp0 sndstat tty25 tty46
ttyGS0 vcsa3
dri loop3 pts stderr tty26 tty47
ttyO0 vcsa4
dsp loop4 ram0 stdin tty27 tty48
ttyS0 vcsa5
fb0 loop5 ram1 stdout tty28 tty49
ttyS1 vcsa6
fd loop6 ram10 tty tty29 tty5
ttyS2 vcsa7
full loop7 ram11 tty0 tty3 tty50
ttyS3 watchdog
fuse mapper ram12 tty1 tty30 tty51
ubi_ctrl watchdog0
hwrng mem ram13 tty10 tty31 tty52
uinput xconsole
i2c-0 mixer ram14 tty11 tty32 tty53
urandom zero
i2c-1 mmcblk0 ram15 tty12 tty33 tty54
usbmon0
initctl mmcblk0boot0 ram2 tty13 tty34 tty55
usbmon1
debian@beaglebone:~$

  Without and with the card inserted to see if a new device entry
appears. You'd then have to mount that.

  {too many uEnv.txt files... one in the top level, one in /boot <G>}

debian@beaglebone:~$ ls /media/rootfs/boot
SOC.sh config-3.8.13-bone80 initrd.img-3.8.13-bone80
uboot
System.map-3.8.13-bone80 dtbs uEnv.txt
vmlinuz-3.8.13-bone80
debian@beaglebone:~$

  Yes, I'm still using the 7.11 Wheezy as primary -- I do have an SD card
with the 8.5 Jessie image too.

What am I, as a noobie - but not too dumb, be likely to have done to cause
this please ? It's difficult for me because I really don't have a good
enough appreciation of HOW this could occur and, therefore, have almost no
idea as to where to even begin looking. To boot, I'm even more worried that
that more 'playing' could make the situation even worse.
For now, I will re-blow the two uSD cards with the same Debian 8.4 image
(just in case, although I have a feeling Ive managed to screw up the uEnv
file somehow... so I'll also go take another look at that...

2nd Q (while it occurs to me) is there a way to mount the uSD card from my
Mac (I'm thinking I could update the uEnv.txt file from there !!

  Not a Mac person, so can't help with that.

  I did get it to mount on a VirtualBox Debian image -- but it was a pain
-- had to set it under the SATA controller, otherwise it tried to boot from
it and failed; and it had to be in the slot when booting too.

On Fri, 11 Nov 2016 04:33:21 -0800 (PST), "'Ian Watts' via BeagleBoard"
<beagleboard@googlegroups.com> declaimed the
following:

I then located the uEnv.txt file again (BUT, now on the uSD card) and
opened it with a view to editing the required 'flash the eMMC' line. I was,
however, confronted with :

GNU nano 2.2.6 File:
uEnv.txt
                           Modified

loadximage=echo debug: [/boot/vmlinuz-${uname_r}] ... ; load mmc 0:1
${loadaddr} /boot/vmlinuz-${uname_r}

loadxfdt=echo debug: [/boot/dtbs/${uname_r}/${fdtfile}] ... ;load mmc 0:1
${fdtaddr} /boot/dtbs/${uname_r}/${fdtfile}

loadxrd=echo debug: [/boot/initrd.img-${uname_r}] ... ; load mmc 0:1
${rdaddr} /boot/initrd.img-${uname_r}; setenv rdsize ${filesize}

loaduEnvtxt=load mmc 0:1 ${loadaddr} /boot/uEnv.txt ; env import -t
${loadaddr} ${filesize};

check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;

loadall=run loaduEnvtxt; run check_dtb; run loadximage; run loadxrd; run
loadxfdt;

mmcargs=setenv bootargs console=tty0 console=${console} ${optargs}
${cape_disable} ${cape_enable} root=/dev/mmcblk0p1
rootfstype=${mmcrootfstype} ${cmdline}

uenvcmd=run loadall; run mmcargs; echo debug: [${bootargs}] ... ; echo
debug: [bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr}] ... ; bootz
${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr};

cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

As you'll see, the line was already un-remmed...

  Remove that line totally.

  The rest of the file looks like the root uEnv.txt. You want the one in
the /boot directory... Given your (snipped) statements:

/media/card/boot/uEnv.txt

  Compare:

debian@beaglebone:/media/rootfs$ cat /boot/uEnv.txt
#Docs: Beagleboard:U-boot partitioning layout 2.0 - eLinux.org

uname_r=3.8.13-bone80
##uuid=
#dtb=

#beaglebone Black/Green dtb's for v4.1.x (BeagleBone White just works..)

#beaglebone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb

#beaglebone Black: eMMC disabled:
#dtb=am335x-boneblack-hdmi-overlay.dtb

<SNIP>

##Audio Cape (needs HDMI Audio disabled) (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

uuid=5ad07394-12c6-46b2-b5ff-f183847e90bf

vs

debian@beaglebone:/media/rootfs$ cat uEnv.txt
##These are needed to be compliant with Angstrom's 2013.06.20 u-boot.

loadaddr=0x82000000
fdtaddr=0x88000000
rdaddr=0x88080000

initrd_high=0xffffffff
fdt_high=0xffffffff

##These are needed to be compliant with Debian 2014-05-14 u-boot.

<SNIP>

mmcargs=setenv bootargs console=tty0 console=${console} ${optargs}
${cape_disable} ${cape_enable} root=/dev/mmcblk0p1
rootfstype=${mmcrootfstype} ${cmdline}

uenvcmd=run loadall; run mmcargs; echo debug: [${bootargs}] ... ; echo
debug: [bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr}] ... ; bootz
${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr};

Thanks for that.

Indeed, updating the uEnv.txt file (using nano) WITHIN the //boot/uboot/ folder ON the uSD card worked a treat (needed (obviously) USB-network access to achieve this) !
Cylon-style lights etc… followed by a reboot all good !
Wow, was I pleased !!

However, the sting, is that the BBB no longer presents itself to the network over USB. I tried pretty much everything to do with keyhosts, renewing DHCP leases etc… etc… nada… nothing… the BBB simply isn’t there anymore… It powers up OK, all looks to be OK form the flasher Usr LEDs but… nothing…
I never thought BBB development was going to be easy BUT, a couple of weeks (probably months on and off) into it and I’m still not doing anything apart from trying to log into the damn thing or flash it’s Distro… Arrrggghhh ! I do, however, console myself (but it’s wearing a little thin now) by remembering how hard it was to ‘get going’ with embedded processors at the very beginning - now they’re like old friends whilst the BBB seems intent on keeping me at arms length !!

So, how do I re-connect to a naughty / really peeved BBB ?
I’m happy to go Ethernet cable - no probs - but how ? I have an ethernet HP laser printer here in my office (years old, but faithful) so disconnected the RJ45 from its bottom and connected it to the BBB. Powered up the BBB (external power supply, not USB) but still nothing seems to be making itself available to the network… As I understand it, if it can 'see; the network, it should at least be saying something like, ‘Howdy, would someone like to assign me an IP address please ?’ and, if not getting one, then assign itself a self-assigned 169.254.x.x number. At least I should then be able to see the BBB if not properly communicate with it ! But in my case nothing.
Looking at my router’s assigned IP addresses etc. does not show up anything like a BBB or ‘unknown’ device, just verifiable devices (tablet, phone, laptop and work station). Turning each one off / on simply verifies it’s connection in the router’s connected devices list… No ‘odd’ connections / devices…

So, I guess, seeing as how the BBB no longer wants to talk over USB (to be fair, with all the messing about, this could be the BBB or the device drivers but re-installing the drivers (on two computers) hasn’t helped any) so in the interests of maintaining my sanity, I think I have to declare a retreat, regroup and investigate the two options remaining open to me :
-1- connect via Ethernet cable (c/w external power supply to the BBB). Is this possible ? Are there any hints, tips or pointers for me here please ?
-2- (my preferred option, simply because I don’t have to mess about with networks) modify the uEnv.txt file directly on the uSD card from my computer (not the BBB - no connection !) and re-flash. Is this possible ? Are there any hints, tips or pointers for me here please ?

Apologies for this going on so long ! And, thanks for the help so far - it’s much appreciated.
Rgds
IAN.

On Sun, 13 Nov 2016 03:49:58 -0800 (PST), "'Ian Watts' via BeagleBoard"
<beagleboard@googlegroups.com> declaimed the
following:

Thanks for that.

Indeed, updating the uEnv.txt file (using nano) WITHIN the //boot/uboot/
folder ON the uSD card worked a treat (needed (obviously) USB-network
access to achieve this) !
Cylon-style lights etc... followed by a reboot all good !
Wow, was I pleased !!

  Hmmm... /boot/uboot is empty on my SD card (and that's the "Jessie"
card rather than the "Wheezy").

  Oh, if you did activate the flasher mode, I presume you did remove the
SD card after flashing? Unless the flasher script turns off the flasher
line, booting with the card in place will just trigger another flash
operation.

However, the sting, is that the BBB no longer presents itself to the
network over USB. I tried pretty much everything to do with keyhosts,

  I haven't used the USB connection since the first time connecting to an
as-shipped card. Unless one has the host computer configured as a gateway
(M$ "Internet Connection Sharing") it doesn't give much -- the BBB can't
get out to access the world (not even a time-server to update the clock).
And with a cat-5 running from it to a router, the Ethernet connection seems
to take priority, effectively shutting down the USB Ethernet. (Though
ifconfig implies it is there)

debian@beaglebone:~$ ifconfig
eth0 Link encap:Ethernet HWaddr d0:39:72:18:3e:e5
          inet addr:192.168.2.105 Bcast:192.168.2.255 Mask:255.255.255.0
          inet6 addr: fdf2:d52e:b5c7:0:d239:72ff:fe18:3ee5/64 Scope:Global
          inet6 addr: fe80::d239:72ff:fe18:3ee5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
          RX packets:224 errors:0 dropped:0 overruns:0 frame:0
          TX packets:242 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:24717 (24.1 KiB) TX bytes:36824 (35.9 KiB)
          Interrupt:175

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:166 errors:0 dropped:0 overruns:0 frame:0
          TX packets:166 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:13548 (13.2 KiB) TX bytes:13548 (13.2 KiB)

usb0 Link encap:Ethernet HWaddr d0:39:72:18:3e:e0
          inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

debian@beaglebone:~$

renewing DHCP leases etc... etc... nada... nothing... the BBB simply isn't

  Sometime back I set my router up to reserve an address for the BBB (and
a Raspberry PI 3) so... while still DHCP assigned to the boards, they stay
the same value, so I don't have to hunt for them each time.

  As an experiment, I'm connecting my second BBB (which I think still has
the original OS, I'll check after it gets done loading drivers, which is
taking some time) over just USB, using a port directly on the computer.

  Hmmm -- interesting, it came up (eventually -- felt like 5 minutes to
get the drivers loaded from M$, and that was a few minutes after booting
using USB power) on USB with a 39MB Windows partition showing, but seems to
have had an updated OS

debian@beaglebone:~$ uname -a
Linux beaglebone 3.8.13-bone80 #1 SMP Wed Jun 15 17:03:55 UTC 2016 armv7l
GNU/Linux
debian@beaglebone:~$

(That's the misnamed image on Latest Software Images - BeagleBoard -- the
page says 2015, but it is this summer.)

  And cloud9 is reachable -- haven't seen that in over a year either <G>
But had a red popup about "language worker could not be loaded"

  The board I normally fiddle with has this on the SD card:

debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l
GNU/Linux
debian@beaglebone:~$

and is reachable over Ethernet, I haven't tried USB

So, how do I re-connect to a naughty / really peeved BBB ?
I'm happy to go Ethernet cable - no probs - but how ? I have an ethernet HP
laser printer here in my office (years old, but faithful) so disconnected
the RJ45 from its bottom and connected it to the BBB. Powered up the BBB

  Is that laser printer cable going through a DHCP router? If it isn't,
you likely have a fixed local IP on it. And... is it a straight through or
cross-over cable (if it has a router connection, it should be normal
straight-through). I'll admit I'm grabbing at straws here -- I don't know
if the BBB has an auto-sense Ethernet (mostly found on modern routers so
one doesn't need a cross-over cable to connect from router to router); a
straight through cable with no router would have the wrong "polarity" at
one end and without auto-sense the hardware won't negotiate a connection.

  Does the router have enough DHCP addresses left (mine is configured to
assign 192.168.2.100 through 192.168.2.114, and I show assignments on:
.100, .102 (Nook HD), .104 (RPi3), .105 (BBB #1), .106 (WII U), .107
(Blackberry), .108 (TV), .109 (computer), .110 (Epson printer), .111
(Samsung/Nook), .112 (Nook Glow), .113 (HP printer)... And that doesn't
account for my original Nook (kept at work) and the RPi3 WiFi (both of
which might be the unidentified addresses (Think I'll up the available
address range -- if I ever do something with the TIVA 1294 and 129E boards,
they'll need slots too)

(external power supply, not USB) but still nothing seems to be making
itself available to the network... As I understand it, if it can 'see; the
network, it should at least be saying something like, 'Howdy, would someone
like to assign me an IP address please ?' and, if not getting one, then
assign itself a self-assigned 169.254.x.x number. At least I should then be
able to see the BBB if not properly communicate with it ! But in my case
nothing.
Looking at my router's assigned IP addresses etc. does not show up anything
like a BBB or 'unknown' device, just verifiable devices (tablet, phone,
laptop and work station). Turning each one off / on simply verifies it's
connection in the router's connected devices list... No 'odd' connections /
devices...

  Okay, you do have a router. I'd ask about the MAC addresses it shows,
but since the MAC is not printed on the BBB it might not be useful. And
since I have fixed IP assignments on the MAC addresses with a user-defined
name, my router status page isn't useful (as you see above I have a few
items that don't show a name -- I had to check the TV for its MAC address).

  Do you have the Ethernet LEDs on the BBB and the router showing a
connection? Was the cable connected when you booted?

So, I guess, seeing as how the BBB no longer wants to talk over USB (to be
fair, with all the messing about, this could be the BBB or the device

  Do you have a microHDMI<>HDMI cable (and a TV/Monitor with HDMI input),
an available USB hub (preferably powered) and USB keyboard&mouse? (hub not
needed if you have, say, Logitech "Unifying" wireless keyboard&mouse). If
you do, you should be able to operate in stand-alone (no network or
computer connection) mode while attempting to debug the BBB. You will need
the wall wart to power the BBB.

  That should let you check "ifconfig" for status... THEN connect the
cat-5 cable and recheck (possibly with a reboot). You'll want to see if the
ethernet connection shows as UP, and what IP address it reports (I'd expect
none before connecting the cable).

  At this point, unless you have a bad Ethernet jack, I'd be tempted to
blame the host computer and/or firewalls. I recall seeing traffic about Mac
USB tethering drivers being problematic -- HoRNDIS being the main one
available (though the home page is focused on using it with an Android
phone to gain external internet access by tethering). OTOH: I did see both
RNDIS and CDC drivers being loaded on Windows when I tried.

  Maybe running Wireshark would let you see some if there is any traffic
from the BBB.

-1- connect via Ethernet cable (c/w external power supply to the BBB). Is
this possible ? Are there any hints, tips or pointers for me here please ?

  Well... that is my normal operating process... But I'm on Windows, and
haven't had any problems (other than finding the IP address before I set
the router to lock it to the MAC of the board). And my configuration is a
mess! DSL modem (192.168.1.x) to WiFi router (192.168.2.x) split to
computer and to an 8-port switch (switch does not assign DHCP addresses...
But might be one of the unknowns I list above since it does have a
configuration capability) with two printers, and two unallocated cat-5 (a
short one to my keyboard position when I hook the BBB up locally, and a
longer one used when it is across the room or for updating my laptop). I
tend to take the RPI3 upstairs and connect to a TV as it has WiFi; use
Logitech keyboard/mouse).

-2- (my preferred option, simply because I don't have to mess about with
networks) modify the uEnv.txt file directly on the uSD card from my
computer (not the BBB - no connection !) and re-flash. Is this possible ?

  Since I was able to mount the card on a Debian virtual machine running
on Windows (which doesn't do the ext# file systems at all), it should be
possible on a Mac. You may need to find the proper device entry to do the
mount with, specifying the proper filesystem (if it is a recent BBB image,
you no longer have a split partitioning to worry about).

  Though I'd recommend using a recent standard image

https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz

to write to the SD card... And ensure that you can get that to work BEFORE
trying to flash the eMMC with the image. Only after you can connect to the
BBB when booting off the SD card should you consider changing the card to a
flasher. As I mentioned above -- while I have a Jessie image on SD card,
I'm still running Wheezy in the eMMC.

  And again, debugging this could entail going stand-alone mode with a
TV/keyboard/mouse (or obtaining an adapter for the debug serial port --
pity the BBB is wired differently from the one that came with an RPi
accessory kit -- though it might be possible to use jumper wires to swap
the connections).

Talking to myself in public... a bad sign...

On Sun, 13 Nov 2016 12:07:05 -0500, Dennis Lee Bieber
<wlfraed@ix.netcom.com> declaimed the following:

As an experiment, I'm connecting my second BBB (which I think still has
the original OS, I'll check after it gets done loading drivers, which is
taking some time) over just USB, using a port directly on the computer.

Hmmm -- interesting, it came up (eventually -- felt like 5 minutes to
get the drivers loaded from M$, and that was a few minutes after booting
using USB power) on USB with a 39MB Windows partition showing, but seems to
have had an updated OS

  As an added data point, I shutdown my primary BBB, and took it to the
desk where I connected using just a USB cable (running to an unpowered hub
that was a built-in of this desk). It came up -- and I got the wait while
Windows again search M$ for RNDIS and CDC drivers. Apparently these need to
be "re-installed" for each USB port the BBB is ever connected to. Another
reason to not use the USB connection <G>

  After logging in, ifconfig showed that eth0 had no IP address
(strangely, it did show an IPv6 address, but not the IPv4 used on my LAN).
Connecting a cat-5 cable had no effect, even "ifconfig eth0 up" made no
changes. Issuing a reboot command, however, and waiting through the USB
reconnect, logging back in, NOW showed eth0 with an IP address. So, based
on that, the DHCP request is only performed during boot, and not on cable
connection. And, in a surprise to me (since I was unable to do this when I
first received the BBB) BOTH eth0 and usb0 links were active (though the
clock update only took place with the eth0 active).

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)

:wink: correct power up as per the UserLEDs
:slight_smile: the unit presented itself to the network (Network-ove-USB cable) on 192.168.7.2

:slight_smile: I could ssh in via Terminal (Mac)
:slight_smile: 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
:slight_smile: 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
:frowning: the unit does not present itself to the network (Network-ove-USB cable)
:frowning: 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) :
:wink: correct power up. After 45 s (or so) UsrLEDs stop flashing and begin the ‘cylon sweep’…
:slight_smile: 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
:frowning: the unit does not present itself to the network (Network-ove-USB cable)
:frowning: 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
:wink: correct (?) power up. Various UsrLEDs flash, flash, flash…
:frowning: the unit does not present itself to the network (Network-ove-USB cable)
:frowning: 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
:frowning: the unit does not present itself to the network (Network-ove-USB cable)
:frowning: 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

...
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.

*(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

...
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 + :wink:

(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,

On Tue, 22 Nov 2016 07:36:46 -0800 (PST), "'Ian Watts' via BeagleBoard"
<beagleboard@googlegroups.com> declaimed the
following:

:frowning: the unit does not present itself to the network (Network-ove-USB cable)
:frowning: 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.

  1) Did you connect the Ethernet cable /before/ booting the BBB?
  2) Did you disconnect the USB cable (ie; power from wall wart, only
communication channel is Ethernet, preferably before booting BBB)?

  Does your network have a DHCP server somewhere? Switches, themselves,
seldom do DHCP -- you need a NAT router of some sort (DSL/Cable "modem",
WiFi router).

  3) check the DHCP server status pages for assignments.

  BTW: at least for mine, every time I change OS (flash or just SD card),
I have to keep approving the change in SSH key that gets generated on boot
-- though that's after the device is seen by Putty. And as mentioned weeks
ago -- it seems Windows had to install the drivers for EACH USB PORT I ever
connected the BBB to. Change port, reinstall drivers... Even though the
driver code files are already on the machine it had to search M$ to
find/download them.

  There appears to be a 10-day trial version of Paragon's extfs for Mac

Full package appears to be $20 -- or, it appears, you can do the same thing
I did (though I'm on Windows); run a virtualization package (is Virtual Box
available for Mac), install a small Linux distribution into Virtual Box,
and then make the SD card "drive" available to Virtual Box.

Hi Dennis,

:frowning: the unit does not present itself to the network (Network-ove-USB cable)
:frowning: 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.

  1. Did you connect the Ethernet cable /before/ booting the BBB?
    To be fair (more desperation than knowledge) I tried both. Same result. Nada. I even tried both ways with a X0-over cable (just in case) same… frustrating…
  2. Did you disconnect the USB cable (ie; power from wall wart, only
    communication channel is Ethernet, preferably before booting BBB)?
    Yep, disconnected power, waited 10secs or so, connected ethernet, reconnected power…
    and disconnected power, waited 10secs or so, reconnected power, connected ethernet…
    same result - unit appears to boot (Usr LEDs flash and continue to do so) but no internet service - doesn’t even appear on the networkk
    Does your network have a DHCP server somewhere? Switches, themselves,
    seldom do DHCP – you need a NAT router of some sort (DSL/Cable “modem”,
    WiFi router).
    To be a fair, I use a Time Capsule bridged to a DHCP router (Orange)
  3. check the DHCP server status pages for assignments.
    Yep, did it. I do a check. All seems OK. To be fair I’m now out of my depth. I simply don’t understand why it’s not even presenting itself to the network
    BTW: at least for mine, every time I change OS (flash or just SD card),
    I have to keep approving the change in SSH key that gets generated on boot
    I’m the same, I have a BBGW too and it does the same thing.
    – though that’s after the device is seen by Putty. And as mentioned weeks
    ago – it seems Windows had to install the drivers for EACH USB PORT I ever
    connected the BBB to. Change port, reinstall drivers… Even though the
    driver code files are already on the machine it had to search M$ to
    find/download them.
    I believe that’s pretty standard for Windows. To be fait I used Serial over USB loads on a Windows project years ago and it was like that then; move the device to a new USB port and reload the driver…

I’m aware this sounds really dumb BUT, for me I’d like to get back to basics - is there a way to re-flash the eMMC with a ‘default’ / ‘as shipped’ Distro ? I’d need a ‘Flasher’ (I think it’s called) image that doesn’t need me to access the uEnv.txt file on the uSD to enable the re-flash. I can’t seem to find one. My logic is once I have reset the BBB to it’s out-of-the-box defaults then I can look elsewhere… as it is I could have a problem with my Mac drivers or with the network… (I don’t know why or what more I could do but if I KNOW it’s not the BBB then, well, you get the picture…).

Thanks for your suggestions anyways. Really appreciated.

There appears to be a 10-day trial version of Paragon’s extfs for Mac
https://www.paragon-software.com/home/extfs-mac/download.html
Full package appears to be $20 – or, it appears, you can do the same thing
I did (though I’m on Windows); run a virtualization package (is Virtual Box
available for Mac), install a small Linux distribution into Virtual Box,
and then make the SD card “drive” available to Virtual Box.

On Sat, 26 Nov 2016 14:12:57 -0800 (PST), "'Ian Watts' via BeagleBoard"
<beagleboard@googlegroups.com> declaimed the
following:

Hi Dennis,
       3) check the DHCP server status pages for assignments.
Yep, did it. I do a check. All seems OK. To be fair I'm now out of my
depth. I simply don't understand why it's not even presenting itself to the
network

  If you are finding an assignment to the BBB in the DHCP server status
pages, then the BBB IS known to that part of the network (caveat --
disconnect BBB and manually remove the DHCP assignment just in case you are
seeing something stale, then reconnect BBB to Ethernet and boot to; you
should get a new assignment in the DHCP server).

  Then try a simple PING to the assigned address.

  This does presume that all devices are getting DHCP addresses in the
same local/private network (eg: 192.168.1.X). If things are appearing in
different local networks, the router may be restricting traffic to be from
device to Internet only.

  My configuration is a bit complex... the DSL "modem" is configured to
issue DHCP addresses on 192.168.0.X. The only device it gives an address to
is my WiFi router. My WiFi router also issues DHCP addresses, and is
configured for 192.168.2.X. That is, in full

ISP DHCP to DSL Modem (at this moment: 108.73.117.23)
DSL Modem NAT to 192.168.0.1
DSL DHCP to WiFi Route (192.168.0.2)
WiFi Router NAT to 192.168.2.1
WiFi DHCP to multiple clients
       
Client Name Interface IPv4 Address MAC Address Expires Time
        LAN 192.168.2.100 28:C6:8E:FB:9D:7B 12:18:26
nook-6c4f6fd5-b1 LAN 192.168.2.102 58:67:1A:AC:E1:56 10:26:13
BLACKBERRY-1E6A Wireless 192.168.2.106 70:AA:B2:9A:F1:7F 17:31:06
        LAN 192.168.2.107 5C:A3:9D:08:4A:B9 05:21:03
Imperium LAN 192.168.2.109 B8:CA:3A:79:0C:36 22:47:13
android-50a89c435dfc72db LAN 192.168.2.110 10:D3:8A:EB:A8:89 00:17:17
        Wireless 192.168.2.112 64:C6:67:05:31:D3 23:57:49
HP507DC0 LAN 192.168.2.113 9C:B6:54:50:7D:C0 21:02:17

  Anything not on the 192.168.2.X will be gatewayed to the DSL Modem
(after NAT changes it to 192.168.0.2 and some other free port number),
which then gateways to the ISP (NAT changes to 108.73.117.23:some port).

I'm aware this sounds really dumb BUT, for me I'd like to get back to
basics - is there a way to re-flash the eMMC with a 'default' / 'as
shipped' Distro ? I'd need a 'Flasher' (I think it's called) image that

  "As shipped" may be so far out of date I'm not certain. Mine were
shipped with something pre-dating the 2015-03-01 version at
https://debian.beagleboard.org/images/bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz
(which is not a flasher image). Only older images on that site are 2GB
images for the pre-Rev C BBB.

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flasher:_.28lxqt-4gb.29_.28BeagleBone_Black.2FGreen_4GB_eMMC.29
has a (very) current Jessie flasher link.

I believe
https://debian.beagleboard.org/images/bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz
is supposed to be the new "as-shipped" as it is the image listed on the
"latest-images" page, but is not a flasher.

could have a problem with my Mac drivers or with the network... (I don't
know why or what more I could do but if I KNOW it's not the BBB then, well,
you get the picture...).

  Do you have other devices showing up on the router with DHCP addresses?
(tablet or smart phone with a WiFi connection) And can you ping them from
the computer? (I'm trying to avoid the USB connection as much as possible).
{I just tested, and got ping responses from my Blackberry phone, Nook HD,
and HP printer, using the addresses shown above}