Friday, October 4, 2013

Whoops. Fresh start!

For some reason when I power cycled the Beaglebone it wasn't getting a DHCP address, and I couldn't connect to it. Worse, I never did get the 'networked USB' thing to work ever, so I was locked out! Arrgh.

So I thought it would be good for my own reference to reinstall before I got too far along and record the steps this time.

Base Angstrom Install

First off, I loaded and SD card with the .img file and instructions from the beaglebone.org site:

http://beagleboard.org/Getting%20Started#update

Basically put the .img file on the SD, hit the reset button then power up, and wait. Go make a sandwich or something. On reboot it picked up it's old IP address from my DHCP server, and I could log in via ssh right away. Nice.

Then, being clever, I decided to do this:

opkg update
opkg upgrade

Whoops again... this time I was getting all kinds of 'no space left on device' errors. Aggrrrh, again.

A quick check with Google found this page:

http://kaskavalci.com/?p=92

I'm not sure I didn't have this issue the first time and maybe didn't notice, but the commands to work around the bug are to specify a temp directory, instead of ram:

opkg -t ~ update
opkg -t ~ upgrade

Sit back, enjoy a coffee and light reading while opkg -t ~ upgrade chugs along. It takes a while. Then you get this:


.
.
.
Configuring florence.
Configuring e2fsprogs-mke2fs.
Configuring angstrom-packagegroup-gnome.
WARNING: could not open /lib/modules/3.8.13/modules.order: No such file or directory
WARNING: could not open /lib/modules/3.8.13/modules.builtin: No such file or directory
WARNING: could not open /lib/modules/3.8.13/modules.order: No such file or directory
WARNING: could not open /lib/modules/3.8.13/modules.builtin: No such file or directory
Collected errors:
 * pkg_run_script: package "bonescript" postinst script returned status 1.
 * opkg_configure: bonescript.postinst returned 1.
root@beaglebone:/dev#

All indications I've been able to find are that these are indeed warnings, and can be ignored. Moving on...

NTP

I like to have useful timestamps on things, so set the time to pull from ntp. The BBB doesn't have an RTC, but I'll be adding at least one, possibly two time sources; one is on the Adafruit SD1307 kit, which I'd built for a previous project and I know works. It doesn't have a reference time source, but it's ok for most applications. The other is time encoded from GPS, again from Adafruit; the Ultimate GPS Logger Shield kit. It's an Arduino shield, but it's happy to put serial data to the BBB, which I tested at the console level via some jumper wires so at least I know that works.

But while it's sitting on my desk I need some good time sources, so let's configure NTP, Network Time Protocol. Start with the basics. Since NTP is in the base Angstrom image that we just loaded, we don't have to update it, but we do have to configure it.  The instructions here are a good start and have additional info that might be useful:

http://derekmolloy.ie/automatically-setting-the-beaglebone-black-time-using-ntp/

Start with:

opkg install ntp

Which will set the ntpd to start at boot.

There is some light config required, depending on your location. I'm in Canada, so we have a couple of time servers that are publicly available. Add those to /etc/ntp.conf

The timezone is a file; /etc/localtime, so delete that file and link to the correct file in /usr/share/zoneinfo (MST, in my case):

root@beaglebone:/etc# rm localtime
root@beaglebone:/etc# ln -s /usr/share/zoneinfo/MST /etc/localtime

There are a few tweaks to the service file in Derek Molloy's page, seems reasonable...

Remove this line
ExecStart=/usr/bin/ntpdate-sync silent
from /lib/systemd/system/ntpdate.service

and add these two lines:
ExecStart=/usr/bin/ntpd -q -g -x
ExecStart=/sbin/hwclock --systohc

Before starting the services, issue the ntpdate command against your ntp server to test it, and set the initial time:

root@beaglebone:/etc# ntpdate time.nrc.ca
 4 Oct 10:36:57 ntpdate[5558]: step time server 132.246.11.229 offset 37881.192694 sec

You should be good to now enable those services:


root@beaglebone:/etc# systemctl enable ntpdate.service
root@beaglebone:/etc# systemctl enable ntpd.service

While you're poking around in /etc you might also want to edit resolve.conf and point it to a reasonable nameserver, or edit your networking if you don't want dhcp.
Now is probably a good time for a reboot, to see if it's all working...

Audio

I had audio working nicely via a powered USB hub (a generic 7 port powered USB hub) to a Sound Blaster Play! (model SB1140). Worked first time, the last time. Here is the detect info, first with nothing plugged in, then with just the hub, then with the SB USB audio device:


root@beaglebone:/# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@beaglebone:/# lsusb
Bus 001 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0409:005a NEC Corp. HighSpeed Hub


And aplay reports nothing interesting; audio is going out the HDMI port:

root@beaglebone:/etc# aplay -L
null
  Discard all samples (playback) or generate zero samples (capture)
default:CARD=Black
  TI BeagleBone Black,
  Default Audio Device
sysdefault:CARD=Black
  TI BeagleBone Black,
  Default Audio Device
root@beaglebone:/etc#


After plugging in the usb audio module (and rebooting, I'm not certain there is stable hotplug support in this kernel...) I get this in lsusb:

root@beaglebone:~# lsusb
Bus 001 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 004: ID 041e:30d3 Creative Technology, Ltd Sound Blaster Play!

Cool. Let's plug it in and check aplay...

root@beaglebone:~# aplay -L null  Discard all samples (playback) or generate zero samples (capture) default:CARD=Black
  TI BeagleBone Black,
  Default Audio Device
sysdefault:CARD=Black
  TI BeagleBone Black,
  Default Audio Device
default:CARD=U0x41e0x30d3
  USB Device 0x41e:0x30d3, USB Audio
  Default Audio Device
sysdefault:CARD=U0x41e0x30d3
  USB Device 0x41e:0x30d3, USB Audio
  Default Audio Device


Yup, that's it. Should be working. Let's see if we get something out of ffmpeg...
First, let's mount a USB stick with an mp3 on it...

root@beaglebone:/dev# mount /dev/sda1 /mnt/usb
root@beaglebone:/dev# cd /mnt/usb root@beaglebone:/mnt/usb# ls wagner2.mp3 root@beaglebone:/mnt/usb#
And play the file...
ffmpeg -i /mnt/usb/wagner2.mp3 -f alsa "default:CARD=U0x41e0x30d3" -vol 40 -re

Whoo hoo! Smells like victory...
Now lets grab some tar's from festivox and scp them to the beaglebone and compile...


Festival

The other thing I had tested on OSX was speech synthesis, from Festival (actually from Festivox, the north american mirror), and it worked great on my iMac.

I started with scp'ing the tar files over to the BBB and extracting them in usr/src/festival. Note that I'm doing everything here on the BBB flash storage; it does have it's limits for number of writes, but this shouldn't be an issue... yet.

There is one directory, speech_tools, that seems to want to compile separately, so I cd there, do a ./configure, and then a make on this first, before we make festival. It seemed ok, then kinda crapped out at the end, as if the source code was broken.

I decided to go back to festival and make that, since there could be some kind of circular dependancy going on... nope, very similar error, almost like a file was missing.

So no Festival, at least not now; 'make' just croaks. Maybe if I have time I'll see if I can cross-compile it from OSX. Worst case I'll have to pre-generate the audio samples as mp3's and store those on the USB key. Or use the sound library from Portal... all the voices (GladOS, turrets, and spheres) sound similar enough to use together. Except maybe Rick.

Go

Go has great documentation, but for whatever reasons the path structure is kinda... odd. Well, not odd as in 'this is stupid' but odd as in 'this makes sense once you understand it', since Go libraries get a path structure from where the repo they were fetched from, and this can vary per user.

First, I grabbed the latest version (Go 1.2) via wget, worked.
I then found a suggestion here:

https://groups.google.com/d/msg/beagleboard/vpqlyUsgN_s/R6E7BTuzISUJ

with a plausible install-from-source method... install a bunch of timezone files, and then run a bash script to bootstrap the tools. The tests are run at the end of the script, and at 1 Ghz they take forever...!



No comments:

Post a Comment