BeagleBone Bugs

I've been fighting with the BeagleBone (white) for the last couple weeks, and wanted to point out a couple issues I've had.

• First, the board behaves differently depending on how you power it!  If you power it from the USB connector, some parts of it don't run at full speed (at least the PRU/DMA), which completely breaks projects like LEDscape (it doubles the length of the waveform generated, which causes random flickering on the LEDs).  The only thing I could find that might shed some light on it is in this code, line 272.  Ridiculous.


• I had a lot of problems with the SD card reader.  Mostly, I keep getting kernel panics from mmcqd, but I also had multiple corrupted SD cards, and even one die.  I'm not sure if the corruption and failure are related to the kernel issues, but it has made the beaglebone basically unusable for me.  Some mailing lists suggested the kernel panics were fixed in newer versions of linux (3.12+?  if I find the link I'll update this), but unfortunately no kernels past 3.8 support the beaglebone cape manager (device tree overlays), so you can't really use it with any peripherals (or LEDscape).


• On that note, it sounds like newer versions of linux do support peripherals, but can only be configured at run-time.  This would be fine, but documentation is scarce (e.g. I'm not going to waste time figuring it out).  (A bit more info here.)


• I was intrigued by the armhf builds, and even used the 14.04 Ubuntu build briefly, but didn't see a way to easily add the RNDIS usbnet (usb0) drivers to it, which made it much less useful for me.  (And even if I could, I couldn't get the dtos working anyway...)

In short, they really need to release a new official linux build for the beaglebone which is stable and standardizes the way capes are managed.

Update:  Because of these issues I ended up buying a BeagleBone Black, mainly to bypass the need for an external SD card.  It does seem much more stable and faster (I was getting random lockups on the white), but even the first thing I tried to do, backup the onboard eMMC, was a hassle.

While there is a nifty tool for extracting the eMMC contents, I had a lot of problems getting it to work:

• You have to power it off the barrel jack and only hold the s2 button for a few seconds while plugging it in (neither of which were documented).



• It only writes a 2GB file!  I verified this was not a format or filesystem issue (I tested on multiple SD cards and filesystems, e.g. EXT2, EXT4, and FAT32, all of which could handle 4GB files just fine with the stock kernel), nor was it a ulimit issue.  It seems the OS used for the extractor image doesn't have large file support (LFS) built in, or the tools were not compiled with the _FILE_OFFSET_BITS=64.  Since no one else has complained about this problem it makes me think it's something I'm doing, but I'm stumped...  I tried both dd and cat, which complained about "File too large" when it reached 2GB (I don't recall the cat error message).

The temporary fix was to just to copy one of the stock images to the SD card, boot to it, and manually dd the eMMC over to a file.  This seems simple enough, but if you want to be able to read the images from Windows it's a bit trick since the FAT partition is FAT16 and only 96MB, and you can only increase the size of the ext4 partition (which has no free space).  You'd think you could just create a 3rd partition with a FAT32 format, but Windows is ridiculously stupid, and for some reason doesn't read more than on partition on removable media (or so it seems, there are driver hacks to do more, but I didn't think it was worth it).  Thus the fix is to move the ext4 partition to the end of the disk and replace the small FAT16 with a large FAT32 partition at the beginning of the disk, mark it bootable, and copy the contents back over.  It requires some fdisk aerobics, but the rough process is below, which ended up working great.  After that you just boot to the sdcard and run something like "dd if=/dev/mmcblk1 of=/boot/uboot/images/BeagleBone.img bs=16M", which will make the image show up in the images folder when you put the sdcard back in to windows.

Note this is done on a 32GB disk, which already had the stock image written to it, and is being manipulated from a BeagleBone running off the eMMC.  This is for reference only; you should backup all data before doing anything with fdisk!

root@beaglebone:~# mkdir stock-boot root@beaglebone:~# cp-r /media/9F8D-4438/ stock-boot root@beaglebone:~# umount /dev/mmcblk1* umount: /dev/mmcblk1: not mounted root@beaglebone:~# fdisk /dev/mmcblk1 Command (m for help): p Disk /dev/mmcblk1: 31.9 GB, 31914983424 bytes 4 heads, 16 sectors/track, 973968 cylinders, total 62333952 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/mmcblk1p1 * 2048 198655 98304 e W95 FAT16 (LBA) /dev/mmcblk1p2 198656 3481599 1641472 83 Linux Command (m for help): n Partition type: p primary (2 primary, 0 extended, 2 free) e extended Select (default p): p Partition number (1-4, default 3): 4 First sector (3481600-62333951, default 3481600): 58139648 Last sector, +sectors or +size{K,M,G} (58139648-62333951, default 62333951): Using default value 62333951 Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. root@beaglebone:~# dd if=/dev/mmcblk1p2 of=/dev/mmcblk1p4 bs=16M 100+1 records in 100+1 records out 1680867328 bytes (1.7 GB) copied, 241.851 s, 7.0 MB/s root@beaglebone:~# umount /mnt root@beaglebone:~# fdisk /dev/mmcblk1 Command (m for help): d Partition number (1-4): 1 Command (m for help): d Partition number (1-4): 2 Command (m for help): d Selected partition 4 Command (m for help): Command (m for help): n Partition type: p primary (0 primary, 0 extended, 4 free) e extended Select (default p): p Partition number (1-4, default 1): 1 First sector (2048-62333951, default 2048): Using default value 2048 Last sector, +sectors or +size{K,M,G} (2048-62333951, default 62333951): 58139647 Command (m for help): n Partition type: p primary (1 primary, 0 extended, 3 free) e extended Select (default p): p Partition number (1-4, default 2): Using default value 2 First sector (58139648-62333951, default 58139648): Using default value 58139648 Last sector, +sectors or +size{K,M,G} (58139648-62333951, default 62333951): Using default value 62333951 Command (m for help): p Disk /dev/mmcblk1: 31.9 GB, 31914983424 bytes 4 heads, 16 sectors/track, 973968 cylinders, total 62333952 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/mmcblk1p1 2048 58139647 29068800 83 Linux /dev/mmcblk1p2 58139648 62333951 2097152 83 Linux Command (m for help): t Partition number (1-4): 1 Hex code (type L to list codes): c Changed system type of partition 1 to c (W95 FAT32 (LBA)) Command (m for help): a Partition number (1-4): 1 Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. Syncing disks. root@beaglebone:~# resize2fs /dev/mmcblk1p2 resize2fs 1.42.5 (29-Jul-2012) Resizing the filesystem on /dev/mmcblk1p2 to 524288 (4k) blocks. The filesystem on /dev/mmcblk1p2 is now 524288 blocks long. root@beaglebone:~# mkfs.vfat /dev/mmcblk1p1 mkfs.vfat 3.0.13 (30 Jun 2012) root@beaglebone:~# mount /dev/mmcblk1p1 /mnt root@beaglebone:~# cp -r stock-boot/* /mnt

Update 2: I also noticed that while configuring a static IP address through /etc/network/interfaces works on boot, it gets lost any time you disconnect the ethernet cable, even if you plug it back in! The solution is to remove wicd (apt-get remove wicd), or to configure wicd via wicd-ncurses.
Update 3: I also had this issue (Element 14 image specific).