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

[Jason Kridner]

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:

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

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:

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):

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!

[Robert Nelson]

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,

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

[Casey Atherton]

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.

[Jason Kridner]

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.

On Wednesday, March 5, 2014 5:51:19 PM UTC-5, Jason Kridner wrote:

[bothering...@gmail.com]

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

[Robert Nelson]

On Thu, Mar 6, 2014 at 10:04 AM, <bothering...@gmail.com> wrote:
>> 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

[bothering...@gmail.com]

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

[l...@ansync.com]

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

[Robert Nelson]

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!

[m...@timb.us]

On Wednesday, March 5, 2014 5:51:19 PM UTC-5, Jason Kridner wrote:

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

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

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…

[bothering...@gmail.com]

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 

[sfuga...@gmail.com]

Trying to run i2cdetect but keep getting:

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

[Robert Nelson]

On Fri, Mar 7, 2014 at 3:22 PM, <sfuga...@gmail.com> wrote:

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, 

[michae...@swisscom.com]

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] [<c0010443>] (unwind_backtrace+0x1/0x8a) from [<c0455ced>] (panic+0x51/0x148)
[  180.567727] [<c0455ced>] (panic+0x51/0x148) from [<c006770b>] (watchdog+0x14f/0x194)
[  180.575937] [<c006770b>] (watchdog+0x14f/0x194) from [<c003fb8f>] (kthread+0x67/0x74)
[  180.584234] [<c003fb8f>] (kthread+0x67/0x74) from [<c000c0dd>] (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?

[Robert Nelson]

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

[Steve French]

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

[Robert Nelson]

On Tue, Mar 11, 2014 at 10:21 AM, Steve French <voltv...@gmail.com> wrote:
> 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?

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)

[Hajo Dezelski]

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

[Robert Nelson]

On Tue, Mar 11, 2014 at 2:07 PM, Hajo Dezelski <dl1...@gmail.com> wrote:
> 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.

[Hajo Dezelski]

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

---
... indessen wandelt harmlos droben das Gestirn
... http://hajos-kontrapunkte.blogspot.com/

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/VRqGZbXBK1Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Wed, Mar 12, 2014 at 7:39 AM, Hajo Dezelski <dl1...@gmail.com> wrote:
> 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

With my image, don't worry about this. ^^^ As long as there is no
"uEnv.txt" file on the microSD, u-boot will always use the factory one
i installed in the eMMC. And since it uses uuid's instead of the raw
partition name, it'll always find the "rootfs" partition no matter
what. So just blank/format your microSD as a simple ext4 partition.

[Robert Nelson]

On Wed, Mar 12, 2014 at 7:43 AM, Robert Nelson <robert...@gmail.com> wrote:
> On Wed, Mar 12, 2014 at 7:39 AM, Hajo Dezelski <dl1...@gmail.com> wrote:
>> 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.

PS: if you want to get crazy, the same script that generated this
image, can also build a version of debian that'll fit in 64MB. But at
that point all you have is perl/apt-get/dpkg..

[Hajo Dezelski]

Robert,

that was a fast one. Thanks again - discussions in other groups can
sometimes lead you to nowhere and you get lost. (There was written
that the uEnv.txt was mandatory) So I will not use your 64 MB image.
Sorry, I am happy that this one is running.

Have a nice day
and so long from Nowhere man

Hajo

---
... indessen wandelt harmlos droben das Gestirn
... http://hajos-kontrapunkte.blogspot.com/

[Robert Nelson]

On Wed, Mar 12, 2014 at 7:49 AM, Hajo Dezelski <dl1...@gmail.com> wrote:
> Robert,
>
> that was a fast one. Thanks again - discussions in other groups can
> sometimes lead you to nowhere and you get lost. (There was written
> that the uEnv.txt was mandatory) So I will not use your 64 MB image.
> Sorry, I am happy that this one is running.

Yeah, this requirement was a bug in the version of u-boot shipped with
the board.

You can see how i worked around the issue here:

https://github.com/eewiki/u-boot-patches/blob/master/v2013.10/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L154

Essentially the original factory u-boot, only checked for the presense
of the microSD, if found it would try to boot with it no matter what.

Instead, I set it up, to search for a uEnv.txt, try to load it and
test if "uenvcmd" was set. Thus a little more error proof..

[Steve French]

Robert,

Thanks for your response!  I have 15 BBBs and one uSD card, so I am kinda leaning toward using the eMMC on each.  

Robert said: 

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.

Pardon my ignorance, but is there a "magic scalpel" command to free up all space related to Opencv?   ...and then separately, Chromium?  Something is not right with the approach I tried...

• 
   apt-get autoremove opencv*

After this operation, 27.8 MB disk space will be freed.
Do you want to continue [Y/n]?

 

• apt-get autoremove chromium*

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Package 'chromium' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

...maybe I just need to learn how to use "aptitude" ?  I am guessing that an "uninstall" or "remove" or "autoremove" command is better than going through and deleting random directories full of opencv/chromium related things?

Thanks for any insights!!!

ps- I decided to remove all documentation on one of my BBBs, so I did this...

rm /usr/share/doc -R

...that seemed to free up 91MB, but it still wasnt enough!!!

Ran out of space again during "make"!!!!!!

ola-rdm-discover.cpp:232:1: fatal error: closing dependency file .deps/ola-rdm-discover.Tpo: No space left on device
compilation terminated.
The bug is not reproducible, so it is likely a hardware or OS problem.
make[2]: *** [ola-rdm-discover.o] Error 1
make[2]: Leaving directory `/usr/local/src/ola/examples'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/ola'
make: *** [all] Error 2

Thx!

-frenchy

[Robert Nelson]

On Wed, Mar 12, 2014 at 10:58 AM, Steve French <voltv...@gmail.com> wrote:
> Robert,
> Thanks for your response! I have 15 BBBs and one uSD card, so I am kinda
> leaning toward using the eMMC on each.
>
> Robert said:
>>
>> 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.
>>
>
> Pardon my ignorance, but is there a "magic scalpel" command to free up all
> space related to Opencv? ...and then separately, Chromium? Something is
> not right with the approach I tried...
>
>
> apt-get autoremove opencv*
>
> After this operation, 27.8 MB disk space will be freed.
> Do you want to continue [Y/n]?

apt-get remove libopencv-* --purge ; apt-get autoremove

> apt-get autoremove chromium*

So due to the build requirements, chromium is currently not a *.deb
package. I'd like to change this. But to give you an idea, it takes a
Quad Core Cortex A9, running at 1.2Ghz with 2GB of ram and a 7200rpm
sata drive 8 hours to build..

SO just:
rm -rf /usr/lib/chromium/
rm -f /usr/bin/chromium

> ...maybe I just need to learn how to use "aptitude" ? I am guessing that an
> "uninstall" or "remove" or "autoremove" command is better than going through
> and deleting random directories full of opencv/chromium related things?
>
> Thanks for any insights!!!
> ps- I decided to remove all documentation on one of my BBBs, so I did
> this...
> rm /usr/share/doc -R
> ...that seemed to free up 91MB, but it still wasnt enough!!!

you can also dump:

/usr/share/man/

[Dennis Cote]

On Monday, March 10, 2014 8:03:28 AM UTC-6, RobertCNelson wrote:

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

Best to just switch to v3.13.x

Robert,

How do you propose that users switch to v3.13.x (by which I assume you mean the Linux kernel version)? 

My BBB panics like this on every boot using the Debian 2014-03-04 image. I can't even log in to the text console.

Dennis Cote

[Robert Nelson]

"panics" on every boot?

Do you have any error log? I can't really help with that limited info.

Easitest thing to do is, grab the non-flasher:

https://s3.amazonaws.com/beagle-debian/bone-debian-7.4-2014-03-04-2gb.img.xz

flash it to a microSD card..

mount the first fat partition, edit "uEnv.txt" remove the "quiet" from
optargs.. save unmount..

Next using a usb-serial convert log the full serial boot log for me.

[Steve French of Volt Vision]

Dennis,

I am not sure what you mean by "BBB panics", but I can tell you that I have been upgrading my kernel using the new Debian eMMC flasher image.  I have done it on several BBBs so far with no problem....

Before the procedure:

uname -a
Linux beaglebone 3.8.13-bone41 #1 SMP Tue Mar 4 22:51:47 UTC 2014 armv7l GNU/Linux

Then Update Kernel:

• cd /opt/scripts/
  
• git pull
  
• ./tools/update_kernel.sh --beta-kernel
  
• reboot

And after the procedure:

uname -a
Linux beaglebone 3.13.6-bone7 #1 SMP Sat Mar 8 01:11:45 UTC 2014 armv7l GNU/Linux

Hope this helps....

-frenchy

--

Respectfully,
Steve French

800.664.7256.office

814.730.0003.cell

President, Volt Vision
www.voltvision.com

--

[Alexander Holler]

Am 12.03.2014 20:02, schrieb Robert Nelson:
> On Wed, Mar 12, 2014 at 1:45 PM, Dennis Cote <den...@harding.ca> wrote:
>>
>>
>> On Monday, March 10, 2014 8:03:28 AM UTC-6, RobertCNelson wrote:
>>>
>>> Doesn't really make a difference for 3.8 thou, as you see..
>>>
>>> Best to just switch to v3.13.x
>>>
>>
>> Robert,
>>
>> How do you propose that users switch to v3.13.x (by which I assume you mean
>> the Linux kernel version)?
>>
>> My BBB panics like this on every boot using the Debian 2014-03-04 image. I
>> can't even log in to the text console.
>
> "panics" on every boot?
>
> Do you have any error log? I can't really help with that limited info.

I'm not sure if you're talking about a non-patched 3.13.x, but I've
recently tried (plain) 3.13.6 and received a panic (oops) straight on
boot in musb (a bt-dongle was connected on boot). So I've just switched
back to some heavy patched 3.11 I haven't many problems with.

Sorry, no log too and I'm currently too lazy to fiddle with the bone and
produce one, but it might be a hint to try booting with some usb-device
connected.

Regards,

Alexander Holler

[William Hermans]

He has done something wrong, or has missed a step in setting up his media.

Having a serial debug cable on the board and working would clear things up in a hurry.

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Dennis Cote]

On Wednesday, March 12, 2014 1:02:55 PM UTC-6, RobertCNelson wrote:

"panics" on every boot?

Do you have any error log?  I can't really help with that limited info.

When I said "panics like this" I meant in the same way that as the user whose message you replied to. I have copied his log below. On my BBB it usually happens just after the 120 second mark, but I have also seen it happen at 180 seconds as below. The rest of the messages are identical (same addresses etc.).

[  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] [<c0010443>] (unwind_backtrace+0x1/0x8a) from [<c0455ced>] (panic+0x51/0x148)
[  180.567727] [<c0455ced>] (panic+0x51/0x148) from [<c006770b>] (watchdog+0x14f/0x194)
[  180.575937] [<c006770b>] (watchdog+0x14f/0x194) from [<c003fb8f>] (kthread+0x67/0x74)
[  180.584234] [<c003fb8f>] (kthread+0x67/0x74) from [<c000c0dd>] (ret_from_fork+0x11/0x34)
[  180.592778] drm_kms_helper: panic occurred, switching back to text console

Easitest thing to do is, grab the non-flasher:

https://s3.amazonaws.com/beagle-debian/bone-debian-7.4-2014-03-04-2gb.img.xz

flash it to a microSD card..

That is what I did, and what I am running.

 

mount the first fat partition, edit "uEnv.txt" remove the "quiet" from
optargs.. save unmount..

Next using a usb-serial convert log the full serial boot log for me.

Will do. 

[Robert Nelson]

On Wed, Mar 12, 2014 at 3:21 PM, Dennis Cote <den...@harding.ca> wrote:
>
>
> On Wednesday, March 12, 2014 1:02:55 PM UTC-6, RobertCNelson wrote:
>>
>> "panics" on every boot?
>>
>> Do you have any error log? I can't really help with that limited info.
>>
>
> When I said "panics like this" I meant in the same way that as the user
> whose message you replied to. I have copied his log below. On my BBB it
> usually happens just after the 120 second mark, but I have also seen it
> happen at 180 seconds as below. The rest of the messages are identical (same
> addresses etc.).
>
> [ 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] [<c0010443>] (unwind_backtrace+0x1/0x8a) from [<c0455ced>]
> (panic+0x51/0x148)
> [ 180.567727] [<c0455ced>] (panic+0x51/0x148) from [<c006770b>]
> (watchdog+0x14f/0x194)
> [ 180.575937] [<c006770b>] (watchdog+0x14f/0x194) from [<c003fb8f>]
> (kthread+0x67/0x74)
> [ 180.584234] [<c003fb8f>] (kthread+0x67/0x74) from [<c000c0dd>]
> (ret_from_fork+0x11/0x34)
> [ 180.592778] drm_kms_helper: panic occurred, switching back to text
> console

Yeah this annoyance..

What brand of microSD cards are you using?

We've back ported a few mmc tweaks from later kernels, yet some cards
still show this issue..

[Dennis Cote]

On Wednesday, March 12, 2014 2:31:13 PM UTC-6, RobertCNelson wrote:

Yeah this annoyance..

What brand of microSD cards are you using?

I'm using a 4GB Kingston Technology cards. Note, I have not expanded the partition to fill the card yet, I just to boot with it after copying the image.

I'll get you the complete boot log if that is still of use.

Dennis Cote