Graphics Muse Issue Tracker

bui-network-config has a simple use case: Provide simple network configuration for a home user who likely uses WPA 2 Personal security on a single wireless router or is connected through a wired connection to a single router. To support this, bui-network-config simply edits configuration files used at start up for PiBox and BeagleBox using a graphical interface based on GTK+. It does not depend on dbus or other external libraries since it simply edits network configuration files used by Busybox/Buildroot to start up a network on an embedded platform. It doesn't get any simpler than this for network configuration. The drawback: if you have a complex network configuration or you need to jump easily or automatically between network connections then this is not the tool for you.

1. Edit /etc/network/interfaces (network interfaces) via UI
2. Edit /etc/wpa_supplicant.conf (wireless configuration) via UI
3. Edit /etc/resolv.conf (nameserver configuration) via UI
4. Manual edit of interfaces file.
5. Manual edit of wpa_supplicant.conf file.
6. Allow saving to alternate file names.
7. Context sensitive save operations
8. Restart network option (File->Restart) calls /etc/init.d/S40network
9. No external requirements other than GTK+
   1. No dbus requirement
   2. No NetworkManager overhead
   3. Easier to build and use than connman
10. Debug option (-t) allows use of debug data files and saving to .bak files for analysis.

1. Wireless configuration using the UI assumes (these can be overridden using manual edit)
   1. Key Management is hard coded to WPA-PSK
   2. Pairwise and Group configuration options are hard coded to TKIP
• IP address validation checking is not performed.

After much time wasting with connman, I've made some decisions about networking. Connman is nice for mobile devices, but my little board is not intended to be another cell phone or tablet. It's initial purpose is to support XBMCBox, which will sit unmoving connected to a TV. So that simplifies this problem. Future uses can add customized packages to support more complex and/or user friendly network configuration.

First, I can drop connman. It doesn't work easily out of the box and there is little information that I can google that tells me how to configure it. There are test tools you can use but these don't seem to provide me anything useful. The whole project makes it look like connman is just a library for controlling things, which means you have to write your own app. Since XBMCBox will be stuck writing an XBMC plugin in Python (yet another thing I don't know yet), I'd rather not slide my way down that rabbit hole.

So back to KISS - keep it simple, stupid.

I can use wpa-supplicant to manually configure my wifi connections. This seems complex when you first start reading the wpa-supplicant documentation, but you can handle the two most likely cases very simply: no security and WPA2 security. And that will be the first goal of the XBMCBox configuration utility, and it doesn't require anything in PiBox that isn't already there. And I can remove connman to clean things up.

Next, the wired port takes a long time to time out on boot right now. That's because there is no wired connection at the moment. This delay is caused by the S45network init script that tries to dhcp on the wired and wifi ports no matter what. I can fix this by using /etc/network/interfaces to tell me which ports to configure. If the port is not specified in that file, then don't try to configure it on boot up. The XBMCBox configuration utility will have to make updates to that file.

1. Pull connman, but push patch for tests enabling to buildroot project first
2. Return to to XBMCBox's issue #160

The build process is essentially working though the resulting installed package does not work quite right. The biggest problem is lack of keyboard/mouse input. There are also issues with some plugins scarfed from Raspbmc. But at least the build is stable enough to allow XBMC to start up and even start pulling in automated updates.

Since the build is stable I can now start meaningful discussions on XBMC forums about how to fix some of the remaining issues. I think the keyboard/mouse issue may be an issue with how vchiq is either used or not used. But that's a guess as this point.

Still, it is nice to see the XBMC start up graphic show up and the menus displayed and the automated updates start running. That's a big step forward.

I've pushed the first public release of PiBox to Ubuntu One. It's only about 258.6 MB so should be an easy download. It contains all binaries required to build the SD card and scripts for formatting (mksd.sh) the card and then installing (mkinstall.sh) the software to the card.

Be sure to read the wiki page for information on how to use the format and install scripts.

1. Cross toolchain build works and generates a working toolchain.
2. Bootloader build generates a working second stage bootloader. The MLO from the original BeagleBoard software distribution is still used in BeagleBox.
3. Linux kernel build works and boots the board.
4. Root file system build works and can bring up a neon-enabled X.org display.
5. SGX build works and generates OpenGLES samples that work correctly.
6. DSP build works but running Big Buck Bunny sample video locks up a C4 board.

This work is complete for BeagleBox 1.0, but wiki and issue tracker cleanup is in progress before moving on to XBMC integration.

BeagleBox 1.0 is essentially ready, but I need to clean up the bug db and the web site first.

1.0 will support SGX and DSP, though the DSP isn't working ideally on a C4. I don't have an XM so I can't try it on that board. Also, I want to skip over the BUI idea and move straight to getting XBMC working on this build.

This announcement just moves the status information from the wiki to the issue tracker. The official announcement of 0.4.0 will come after a release package is finalized and pushed to an offsite publicly available archive.

PiBox V0.1 was the initial stable release. It will generate a working cross toolchain, kernel, gles utilities and root file system onto a bootable SD card. The boot goes into X.org with a single terminal window. This release is suitable for use with XBMCBox when that build is ready, which I think it may be close to.

PiBox v0.2 is also ready. This is a only slightly modified version that was tested to build on Ubuntu 12.10. Now builds on Fedora 16, CentOS 6.3 and Ubuntu 12.10.

In order to correctly map git tags to the preset versions in the issue tracker, PiBox v0.3 and v0.4 are the same as v0.2.

Note: If you intend to build XBMCBox for use with PiBox you must build PiBox on a 32bit host due to problems with Python builds in XBMC.

• userid: root
• password: pibox

This announcement just moves the status information from the wiki to the issue tracker. The official announcement of 0.4.0 will come after a release package is finalized and pushed to an offsite publicly available archive.

BeagleBox was put on hold for the past year in order for the lead developer, Michael J. Hammel, to complete work on other projects (primarily, a 2nd edition of his last book). But that work is completed, so now its time to reboot BeagleBox.

BeagleBox has been updated to use the latest mainline kernel and bootloader along with updated root file system and cross toolchain. After a few bumps in the process, the build is now back to booting to logins on the serial console and DVI-D output. X.org also works though it is not yet enabled in the boot process (but coming soon).

Joining the project this year is Dominic Reynolds. Dominic will be working on adding support for PandaBoard.

BeagleBox also has a slightly different goal with this reboot: to provide a core platform on which application-target projects can be built. More on this will be coming with updates to the project wiki and issue tracker.

The Graphics Muse issue tracker has been migrated to Redmine. Flyspray served me well, but it's no longer actively maintained and Redmine offers lots of modern features.

Now its time to get back to BeagleBox.