Here is the BeagleBone Debian (beta) image you want to test

The latest BeagleBone Debian images are now posted at: http://beagleboard.org/latest-images/

If you’ve upgraded the firmware on your BeagleBone or BeagleBone Black in the past, the experience will be quite similar, but you might find the eMMC flashing times a bit faster (~15 minutes rather than ~45 minutes) due to less post-installation processing. Using the 2GB uSD card image also flashes a bit faster and can be resized to whatever your uSD card size is using some scripts under /opt/scripts/tools.

Many, many thanks to Robert Nelson, Rob Rittman, Dave Anders, Cody Lacey, the Cloud9 IDE team and so many others in getting us this far.

Please take the time to give a detailed look over this image and report any issues to the bug tracker on elinux.org:

http://bugs.elinux.org/projects/debian-image-releases

While plugged in over USB, you’ll see the familiar BEAGLE_BONE drive with START.htm to tell you how to get the drivers configured if you haven’t already done so:

Google ChromeScreenSnapz095.png

Clicking the link or visiting http://192.168.7.2, you’ll see the familiar on-board served documentation:

Google ChromeScreenSnapz094.png

I’ve introduced a few bugs to the documentation (http://github.com/beaglebone/bone101 and http://beagleboard.github.io/bone101), so expect to find a lot of issues there. Patches are welcome as are notes in the bug tracker to make sure I don’t miss dotting any i’s or crossing any t’s. This is your chance to try to get some documentation into the system you’d like to see. I felt it was pretty safe to save the documentation as an in-beta item because it shouldn’t impact functionality.

One of the biggest new features you’ll see is when you click on the Cloud9 IDE link:

Google ChromeScreenSnapz096.png

This is a pre-open-source-beta-only release of version 3 of their IDE. Down at the bottom of the Cloud9 IDE you’ll see a new terminal window that runs a full ‘tmux’ session. You can open up a bunch of these and it makes logging into the board and executing command-line operations super simple.

Cloud9 IDE version 3 now includes support for Python and the Adafruit_BBIO library is included in these Debian images. That means you can simply paste in your Python code and hit the “run” button, without any additional download. I checked this out myself by doing a quick LED blink using the Adafruit tutorial (http://learn.adafruit.com/blinking-an-led-with-beaglebone-black/writing-a-program):

Google ChromeScreenSnapz097.png

You should also note that the /var/lib/cloud9 directory now contains a git clone of that bone101 repo (http://github.com/beagleboard/bone101), so you can start using the Cloud9 IDE to edit the content live. What I recommend is creating your own fork of the repo and sending me pull requests of any changes you’d like to see.

You can also edit C/C++ code in the Cloud9 IDE, but no ‘builder’ or ‘runner’ plug-ins are provided. You will, however, find the Userspace-Arduino (http://elinux.org/Userspace_Arduino) code in /opt/source/Userspace-Arduino. Here’s a quick little exercise you can do to blink LED0:

root@beaglebone# cd /opt/source/Userspace-Arduino/arduino-makefile/examples/Blink

root@beaglebone# perl -i -pe ‘s/13/14/g’ Blink.ino

root@beaglebone# make
root@beaglebone# ./build-userspace/Blink.elf

For more advanced C/C++ developers, future releases should include https://github.com/jackmitch/libsoc.

Those familiar with Linux will also note that the init system is ‘systemd’, which has been helpful in providing reasonable boot times. If you are looking for the journal, you can explore it using ‘systemd-journalctl’.

I use a Mac and despite the latest version of HoRNDIS fixing issues with Internet Connection Sharing, getting on the WIFI at home makes getting my BeagleBones on the network much easier, further making grabbing new packages with ‘sudo apt-get install’ much simpler. Drivers and firmware for many common USB WiFi dongles are included, so be sure to report any that you find missing. These latest images include the drivers for the popular UWN200 adapters provided by Logic Supply. To test it out myself, I uncommented and edited the wlan0 entry in /etc/network/interfaces (including replacing wlan0 with ra0), shutdown, plugged in the adapter and powered up the board again. I’m seeing the issue “rt28xx_open return fail!”, but I’m sure this is something we can fix in a few days and provide an updated image. I removed that adapter and plugged in an adapter I bought from Adafruit (and switched ra0 back to wlan0) and got the issue “rtl8192cu:_rtl92cu_init_power_on():<0-0> Failed to polling REG_APS_FSMCO[APFM_ONMAC] done!”. Finally, I plugged in a TL-WN822N adapter I bought from Amazon and BINGO—WiFi!!! Anyway, getting reports on what adapters work and don’t work would be really helpful at this point as we’ll be trying to get a very full set of WiFi drivers included.

This is just a quick intro to some of the experience and what we are focused on fine tuning. Please take the time to check it out and let us know about your experience. It should be known that Koen has continued to advance the state of the Angstrom Distributions images he provides and those continue to serve as a more flexible base for building truly custom Linux distributions needed by many embedded systems developers. However, as our user base has grown, getting a Debian image that feels a bit more familiar to Linux novices is something for which I’ve heard tremendous demand. If feedback from the community is positive, there will be a switch as to what distribution comes loaded in the eMMC flash on the boards. I hope you enjoy it!

I use a Mac and despite the latest version of HoRNDIS fixing issues with
Internet Connection Sharing, getting on the WIFI at home makes getting my
BeagleBones on the network much easier, further making grabbing new
packages with 'sudo apt-get install' much simpler. Drivers and firmware for
many common USB WiFi dongles are included, so be sure to report any that
you find missing. These latest images include the drivers for the popular
UWN200 adapters provided by Logic Supply. To test it out myself, I
uncommented and edited the wlan0 entry in /etc/network/interfaces
(including replacing wlan0 with ra0), shutdown, plugged in the adapter and
powered up the board again. I'm seeing the issue "rt28xx_open return
fail!", but I'm sure this is something we can fix in a few days and provide
an updated image. I removed that adapter and plugged in an adapter I bought
from Adafruit (and switched ra0 back to wlan0) and got the issue
"rtl8192cu:_rtl92cu_init_power_on():<0-0> Failed to polling
REG_APS_FSMCO[APFM_ONMAC] done!". Finally, I plugged in a TL-WN822N adapter
I bought from Amazon and BINGO---WiFi!!! Anyway, getting reports on what
adapters work and don't work would be really helpful at this point as we'll
be trying to get a very full set of WiFi drivers included.

Talking with the guys at Logic Supply, it's just a small goof in the
directory location of the RT2870STA.dat file.

Quick fix via:
cd /opt/scripts/
git pull
./fixes/debian-2014-03-04-to-HEAD.sh

or:
sudo mv /etc/Wireless/RT2870/RT2870STA.dat
/etc/Wireless/RT2870STA/RT2870STA.dat

Regards,

I can confirm that the UWN200 (and UWN100) are working well with the fix Robert mentioned. I’m getting a solid connection with WPA2 encryption.

If you have a BeagleBone Black and are able to try out this image, it might be good to propose fixing any short-falls you see in what is provided on the image.

Jason and Robert: well done for this fine upgrade! Seems like a lot of things are really coming together very quickly.

Hardware: BBB A5C; OS Version: Linux beaglebone 3.8.13-bone41 #1 SMP Tue Mar 4 22:51:47 UTC 2014 armv7l GNU/Linux

Tried it last night and a lot of things are working well.
Cloud9 IDE debugging works perfectly for javascript. Just have to remember to hit the > button to start the debug running.
I tried the python sample also, but could not get that to work. I’ll investigate more.

My trusty WNA1100 works out of the box with the addition of:

wpa-ssid “MySSID” #SSID name
wpa-psk “xxxxxxxxxxxxxxx…xx” #PSK hex string
into /etc/network/interfaces under wlan0 section.

The Netgear WNA1100 (Atheros chipset) is indeed the most reliable Wifi adapter I have found yet.

My UWN200 (which was very reliable under later Angstrom versions) now works on debian after modifying the /etc/Wireless/RT2870STA directory name and adding the wpa-ssid/wpa-psk to the ra0 section of /etc/network/interfaces.
However, I notice that the UWN200 pumps out a lot of DMESGs every 2 seconds or so. I had the same problem in 3.8.13-bone40 after compiling the kernel module from the Mediatek sources. I think there may be a debug flag turned on in the driver config, causing the frequent DMESGs. I’ll check this out and see if they can be easily stopped.
The WNA1100 driver is very quiet in comparison.

I have a TP-Link TL WN725N lying around somewhere (Realtek chipset) that I’ll try out also. (I could not get this working reliably in Angstrom - flung in a drawer somewhere!)

One question springs to mind: if I want to run the BBB as a headless server with Node.js and Cloud9, is there anything I can remove from the installed software packages that would be superfluous if I’m not using HDMI, lxde and so on?

Thanks for all the effort. Great software to match Gerald’s fine hardware!
-Eamonn

Jason and Robert: well done for this fine upgrade! Seems like a lot of
things are really coming together very quickly.

Hardware: BBB A5C; OS Version: Linux beaglebone 3.8.13-bone41 #1 SMP Tue Mar
4 22:51:47 UTC 2014 armv7l GNU/Linux

Tried it last night and a lot of things are working well.
Cloud9 IDE debugging works perfectly for javascript. Just have to remember
to hit the > button to start the debug running.

I'd love to disable this "debug" feature by default, if you happen to
find a fix, I'll add it to the image.

I tried the python sample also, but could not get that to work. I'll
investigate more.

My trusty WNA1100 works out of the box with the addition of:
    wpa-ssid "MySSID" #SSID name
    wpa-psk "xxxxxxxxxxxxxxx...xx" #PSK hex string
into /etc/network/interfaces under wlan0 section.
The Netgear WNA1100 (Atheros chipset) is indeed the most reliable Wifi
adapter I have found yet.

My UWN200 (which was very reliable under later Angstrom versions) now works
on debian after modifying the /etc/Wireless/RT2870STA directory name and
adding the wpa-ssid/wpa-psk to the ra0 section of /etc/network/interfaces.
However, I notice that the UWN200 pumps out a lot of DMESGs every 2 seconds
or so. I had the same problem in 3.8.13-bone40 after compiling the kernel
module from the Mediatek sources. I think there may be a debug flag turned
on in the driver config, causing the frequent DMESGs. I'll check this out
and see if they can be easily stopped.

For reference, I'm using this Mediatek source version:
http://rcn-ee.net/deb/thirdparty/MT7601/DPO_MT7601U_LinuxSTA_3.0.0.4_20130913.tar.bz2

So If you find the config flag to quiet dmesg, i'll add it to the build snipit.

https://github.com/rcn-ee/farm/blob/master/thirdparty/MT7601.sh

The WNA1100 driver is very quiet in comparison.

I have a TP-Link TL WN725N lying around somewhere (Realtek chipset) that
I'll try out also. (I could not get this working reliably in Angstrom -
flung in a drawer somewhere!)

One question springs to mind: if I want to run the BBB as a headless server
with Node.js and Cloud9, is there anything I can remove from the installed
software packages that would be superfluous if I'm not using HDMI, lxde and
so on?

This should clear most of the lxde/xorg package set:

apt-get remove -y x11-common ; apt-get autoremove

Regards,

Hi Robert,

First, thanks for the instruction to remove x11… that gets my rootfs usage down from about 83% to 69%. More room for building stuff!

The Mediatek driver software has a define in os/linux/rt_linux.c line 54:

  • ULONG RTDebugLevel = RT_DEBUG_TRACE;
    +ULONG RTDebugLevel = RT_DEBUG_WARN; //Fix annoying dmsgs; was RT_DEBUG_TRACE;

I’ve rebuilt the driver with the bone41 headers, and that seems to eliminate most of the dmesgs.

Hope that’s useful.

Many thanks - Eamonn

Dittos on the Kudos. With the 3.13 kernel works very nicely: all 7 of my weird USB gadgets work, Networking is good, Chrome on lxde is nice. Node 10 all looks good. Even rebuilding the kernel wasn’t too painful (though still not fast enough to ditch the cross-compiler). I’m not an IDE guy so I can’t comment on Cloud9, but I’m happy with gvim… (sorry for the cross-thread snark).

Awsome, thanks!

https://github.com/rcn-ee/farm/commit/47a4acff774280b55772d02fccab4ad2ef63212f

builder are back up and running, so the next kernel image test will
have the fix..

Thanks!

My Edimax rtl8192cu works out of the box, well, sort of… I’m getting seemingly horrible packet loss with the adapter. I’ve got a Raspberry Pi with the exact same adapter sitting directly next to it that has no issues.

timb@woodpi ~ $ iwconfig

wlan0 IEEE 802.11bgn ESSID:“Timothy & Star” Nickname:“WIFI@REALTEK

Mode:Managed Frequency:2.412 GHz Access Point: 60:33:4B:E8:18:AB

Bit Rate:72.2 Mb/s Sensitivity:0/0

Retry:off RTS thr:off Fragment thr:off

Power Management:off

Link Quality=100/100 Signal level=75/100 Noise level=0/100

Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0

Tx excessive retries:0 Invalid misc:0 Missed beacon:0

root@beaglebone:~# iwconfig

wlan2 IEEE 802.11bgn ESSID:“Timothy & Star”

Mode:Managed Frequency:2.412 GHz Access Point: 60:33:4B:E8:18:AB

Bit Rate=72.2 Mb/s Tx-Power=20 dBm

Retry long limit:7 RTS thr=2347 B Fragment thr:off

Encryption key:off

Power Management:off

Link Quality=47/70 Signal level=-63 dBm

Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0

Tx excessive retries:0 Invalid misc:109 Missed beacon:0

Tons of “Invalid misc” errors on the BBB. I thought it might be the adapter itself, but swapping the Pi’s adapter for the BBB’s yielded the same results. I thought the Pi might be interfering with the signal somehow but that’s not the issue either. At least I can actually get this online, unlike Angstrom…

Hi Robert,

The fix I suggested yesterday still leaves some debug dmesgs.

I tried to eliminate DBG entirely.
However, make with -DDBG removed from os/linux/config.mk lines 290:293

config for STA mode

ifeq ($(RT28xx_MODE),STA)
–WFLAGS += -DCONFIG_STA_SUPPORT -DSCAN_SUPPORT -DDBG
++WFLAGS += -DCONFIG_STA_SUPPORT -DSCAN_SUPPORT

causes build errors in /sta/sta_cfg.c:
/home/tmp/DPO_MT7601U_LinuxSTA_3.0.0.4_20130913/os/linux/…/…/sta/sta_cfg.c:8278:4: error: implicit declaration of function âRTMPIoctlMACâ [-Werror=implicit-function-declaration]
/home/tmp/DPO_MT7601U_LinuxSTA_3.0.0.4_20130913/os/linux/…/…/sta/sta_cfg.c:8282:4: error: implicit declaration of function âRTMPIoctlE2PROMâ [-Werror=implicit-function-declaration]
/home/tmp/DPO_MT7601U_LinuxSTA_3.0.0.4_20130913/os/linux/…/…/sta/sta_cfg.c:8286:4: error: implicit declaration of function âRTMPIoctlRFâ [-Werror=implicit-function-declaration]

This can be fixed by adding in an #ifdef DBG…#endif wrapper into:
sta/sta_cfg.c line 8276:8288


++#ifdef DBG //Include if DBG on
case CMD_RTPRIV_IOCTL_MAC:
RTMPIoctlMAC(pAd, pRequest);
break;

case CMD_RTPRIV_IOCTL_E2P:
RTMPIoctlE2PROM(pAd, pRequest);
break;

case CMD_RTPRIV_IOCTL_RF:
RTMPIoctlRF(pAd, pRequest);
break;

++#endif

The above case statements need to be wrapped in an #ifdef DBG … #endif,
same as sta/sta_ioctl.c lines 2622:2638:

#ifdef DBG
case RTPRIV_IOCTL_MAC:
RTMP_STA_IoctlHandle(pAd, wrq, CMD_RTPRIV_IOCTL_MAC, 0,
NULL, 0, RT_DEV_PRIV_FLAGS_GET(net_dev));
/* RTMPIoctlMAC(pAd, wrq); /
break;
case RTPRIV_IOCTL_E2P:
RTMP_STA_IoctlHandle(pAd, wrq, CMD_RTPRIV_IOCTL_E2P, 0,
NULL, 0, RT_DEV_PRIV_FLAGS_GET(net_dev));
/
RTMPIoctlE2PROM(pAd, wrq); /
break;
case RTPRIV_IOCTL_RF:
RTMP_STA_IoctlHandle(pAd, wrq, CMD_RTPRIV_IOCTL_RF, 0,
NULL, 0, RT_DEV_PRIV_FLAGS_GET(net_dev));
/
RTMPIoctlRF(pAd, wrq); /
break;
#endif /
DBG */

By the way, a quick compare of the WNA1100 (22% RX dropped) and UWN200 (<4% RX dropped).
Looks like the big antenna makes a difference!

Thanks - Eamonn

Trying to run i2cdetect but keep getting:

Error: Can’t use SMBus Quick Write command on this bus

Well you need to add the optional "-y -f" commands.. (off the top of my
head, --help to get the correct options)

Regards,

I am having issues with this image and mmcqd daemon, X crahes often and I end up with an empty console on my LCD 4.3:

[ 180.537526] INFO: task mmcqd/0:74 blocked for more than 60 seconds.
[ 180.544275] “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message.
[ 180.552668] Kernel panic - not syncing: hung_task: blocked tasks
[ 180.559071] [] (unwind_backtrace+0x1/0x8a) from [] (panic+0x51/0x148)
[ 180.567727] [] (panic+0x51/0x148) from [] (watchdog+0x14f/0x194)
[ 180.575937] [] (watchdog+0x14f/0x194) from [] (kthread+0x67/0x74)
[ 180.584234] [] (kthread+0x67/0x74) from [] (ret_from_fork+0x11/0x34)
[ 180.592778] drm_kms_helper: panic occurred, switching back to text console

I saw this post:

https://groups.google.com/forum/#!topic/beagleboard/g8JQWFmw4_w

is this backport from 3.12 part of the image?

Yeap:

https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patch.sh#L845

Doesn't really make a difference for 3.8 thou, as you see..

Best to just switch to v3.13.x

Regards,

Hello all!
I have been testing the new official Debian eMMC flasher image for the BBB…
http://beagleboard.org/latest-images/
(…in particular this one Debian (BeagleBone Black - 2GB eMMC) 2014-03-04)

root@vBBB5studioS:/var/lib/cloud9# uname -a
Linux vBBB5studioS 3.8.13-bone41 #1 SMP Tue Mar 4 22:51:47 UTC 2014 armv7l GNU/Linux

Regarding available space on the eMMC, I am seeing this after a fresh flash…
root@vBBB5studioS:/var/lib/cloud9# df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 1.7G 1.3G 284M 83% /
udev 10M 0 10M 0% /dev
tmpfs 100M 788K 99M 1% /run
/dev/disk/by-uuid/57e2c7bb-2b31-488e-b9b4-92e3e4c6af20 1.7G 1.3G 284M 83% /
tmpfs 249M 0 249M 0% /dev/shm
tmpfs 249M 0 249M 0% /sys/fs/cgroup
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 100M 0 100M 0% /run/user
/dev/mmcblk0p1 96M 80M 17M 83% /boot/uboot

Does this look right? Is it really supposed to be 83% full from the start with only 284MB remaining? I was trying to build some software from source (OLA framework) and during the make process I got some errors about running out of disk space. If I was to start looking for space to free up, where would I start? (I have several BBBs and some of them I was hoping to use a GUI on, but most I just use SSH)

Thanks!
-frenchy

Correct, to meet everyone's out of box pkg requirements, the eMMC is
mostly full. If you drop opencv/python/chromium you'll gain a lot of
space back.

Otherwise, it's just easier to just use the non-flasher image on a
4GB/8GB microSD card.
(making sure to use the "grow_partition.sh" script under
/opt/scripts/tools/ to fully resize the drive)

Regards,

Hello,

this was one of the problems with BBB. I managed to install Debian with “BBB-eMMc-flasher-debian-7.4-2014-02-16-2gb.img” installed only Xfce (needed an graphical output) and had about 450 MB left. Beside that I had to install a swap file 128 MB I’m down to 211156. That’s not a lot. Under Angstrom I managed to use the sd card with the uEnv.txt as additional storage, but I forgot to withdraw the card when finished and waited while booting up until I noticed that the BBB got stuck.

My question to Robert: Is there a clean way under Debian to format or mount the sd card as additional storage or even better: Is it possible to mount e.g. homedirectories to that card, so that we are not stuck to that damned 2 GB. I know, I could use the card to boot from, but …

Regards
Hajo DL1SDZ

Hello,

this was one of the problems with BBB. I managed to install Debian with
"BBB-eMMc-flasher-debian-7.4-2014-02-16-2gb.img" installed only Xfce (needed
an graphical output) and had about 450 MB left. Beside that I had to install
a swap file 128 MB I'm down to 211156. That's not a lot. Under Angstrom I
managed to use the sd card with the uEnv.txt as additional storage, but I
forgot to withdraw the card when finished and waited while booting up until
I noticed that the BBB got stuck.

You can also dump all the man pages, locales, etc. There is a lot of
documentation installed by default in debian that wasn't in the
Angstrom images's..

My question to Robert: Is there a clean way under Debian to format or mount
the sd card as additional storage or even better: Is it possible to mount
e.g. homedirectories to that card, so that we are not stuck to that damned 2
GB. I know, I could use the card to boot from, but ...

Yes, usually any tools fdisk/sfdisk/gparted reformat the microSD card.
As long as there isn't an "uEnv.txt" file with the variable "uenvcmd"
set in the first partition the bootloader will ignore the microSD
card. Just add it to /etc/fstab and create a new home diretory on it.

Regards,

Hello Robert,

thanks for your advice. I deleted the man pages and some other stuff.
It helped. Now I have about 15 % available. Great. I noticed, that
most of the non-critical packages (from: Reduce Debian) were already
missing.

But bare with me, I'm not a Linux Guru like you.
I reformatted the sd card using a script that I found: mkcard.sh found
in an Angstrom discussion.

It created:

Device Boot Start End #cyls #blocks Id System
/dev/mmcblk0p1 * 0+ 8 9- 72261 c W95 FAT32 (LBA)
/dev/mmcblk0p2 9 965 957 7687102+ 83 Linux

And I found the mmcblk0p2 partition named rootfs with a Lost and found
directory.
My uEnv.txt (found in an Angstrom-discussion) looks like:

bootpart=1:2
mmcroot=/dev/mmcblk1p2

I didn't find the vriable " uenvcmd". Perhaps there is something
missing in the uEnv.txt.
The I create on rootfs a directory and an fstab file? And write ?
And should I create the home etc. directories in that partition?

Sorry for bothering you again. Next time we meet , the bottle of wine is on me.

Thanks and regards
Hajo
Gruss
Hajo

mkcard.sh (1.11 KB)