FreeBSD on a BBG

Here’s the situation after installing FreeBSD on my BBG (BeagleBone Green), using an image published by the raspBSD project. No custom configuration or installing additional software has been done, although I have updated the package database. There’s more information on the install in a previous post.

For background, a BeagleBone Green (BBG) has a TI Sitara AM335x (1GHz ARM Cortex-A8) with 512MB DDR3 and 4GB eMMC (primary boot device), a micro SD socket (alternate boot device and additional storage), two USB connectors (one client and one host), ethernet, two Grove 4-pin connectors and two 46-pin 2×23 0.100″ pin headers with GPIO, SPI, I2C and other signals. 

Identification & Disk Use

Active Processes

I have two remote ssh sessions open.

Memory use

BeagleBone and FreeBSD

I recently purchased a BeagleBone Green (BBG) to experiment with FreeBSD on an embedded platform. The BBG has been available for a couple of years, and while I was tempted to get a BBG Wireless (BBGW), it would have meant ordering on-line and waiting for delivery. At least for initial development work I prefer a hard-wired connection, but also prefer to support local when possible.

BeagleBone Green

A BeagleBone Green (BBG) is a TI Sitara AM335x (1GHz ARM Cortex-A8 processor) with 512MB DDR3 and 4GB eMMC (which is the standard boot device), a micro SD socket (the alternate boot device and data storage memory), two USB connectors (one client and one host), ethernet, two Grove 4-pin connectors and two 46-pin 2×23 0.100″ pin headers. The original BeagleBoard emerged around 2010, and in 2013 was a winner in Embedded Computing Design’s “2013 Top Embedded Innovator award” in the Top Products Silicon category. The BeagleBone Black (BBB) was launched in 2013 as a lower-cost barebones BeagleBoard, and the BBG was launched in 2015 with two Grove connectors replacing the BBB’s HDMI connector.

Open-Source Hardware

A significant advantage of the BBG (and the other BeagleBoards and BeagleBones) for that the physical design (the schematics and pcb layout files) are provided under an open-source license. The BBG files are in a GitHub project using the MIT license. For someone designing a similar-but-different product, this can be a significant time saver.  The openness reportedly continues to other technical details of the design, such as the low-level details of power management.

FreeBSD

The RaspBSD project provides pre-built images for the BBG. The project originally provided FreeBSD images for the Raspberry Pi, but has expanded their scope to include the BBG (and BBGW). Once I sorted out how to select the alternate boot device (to boot from the micro SD card I had copied the RaspBSD image to) everything started falling into place.

The RaspBSD image is based on Head, which is new for me as I’m running 10.3-RELEASE on my web server. However, I’m looking forward to experiencing life on the edge.

I’m not sure if this is correct, but it seemed to work consistently. To boot from the micro SD card instead of eMMC, disconnect power then hold down the switch beside the micro SD slot, apply power and continue holding the switch for a count of three. After some testing (and being sure I could re-load the bundled Ubuntu-based system if I wanted), I used the script provided with RaspBSD to copy the FreeBSD image to the eMMC. This significantly improved boot time and also freed up the micro SD card for data storage.

Conclusion

For me, the BBG is the superior single-board unix computer for basing a new product design on. The openly provided design files and technical documentation, as well as easy access to GPIOs and other hardware resources on the two pin headers, provide a significant head start compared to having to start from scratch.

Staying Current

I’m commuting again and listening to podcasts for current tech trends.

  • FLOSS Weekly is interviews with free and open source project leaders. The host is Randall Schwartz, co-author of several popular books on Perl (the correct answer to the final interview question is Perl and Emacs). 
  • Software Engineering Radio is an interview show sponsored by IEEE Software Magazine.  Topics are largely technical, and the discussion can follow the rabbit hole down pretty deep sometimes.
  • The Changelog bills itself as “A weekly conversation that gets to the heart of open source technologies and the people who create them.” I recently added this back to the mix after an extended absence and now seems to concentrate more on social aspects of the craft than purely technical.
  • The Stack Overflow Podcast is another return to the rotation after an extended absence, and is a mixed bag conversation of technical and social topics. 
  • BSD Talk is interviews with people active in the BSD or general unix community, many recorded at a BSD conference, and largely technical.
  • BSD Now is another BSD oriented podcast, this one sponsored by IX Systems whose roots can be traced back to the beginning (4.3BSD Networking Release 2).
  • Embedded.fm is a discussion and interview program concentrating on embedded devices and firmware development.
  • The Amp Hour is the arch nemesis of Embedded.fm, providing discussion and interviews relating to embedded devices from a hardware perspective.

A Gated Product Development Process

The gated product development process has been discounted of late due to a perception of it being too rigid and inappropriate in an age of continuous integration and deployment. However, people are not continuous beings, and a continuous process is discrete at some level, such as effort measured in person days, or releases measured according to the rules of semantic versioning (version x.y.z). Discretizing can also be a mental aid, providing sign posts for the stakeholders to focus on during the continuous drive from Point A to Point B.  

Product development can be discretized by dividing a project into phases, moving from concept to production, and finally retirement. I have developed a model useful for understanding product development within Small to Medium Enterprises (SMEs). It is based on how the involvement of resource groups changes over the life of the project, and which group provides leadership (or ownership) during each phase (leadership for a phase identified in bold).

Although Product Management is identified as a resource group, it is often not formalized in an SME and instead provided through the combined leadership of the organization, typically led by either the CEO/President/Founder, the head of Sales or the head of Engineering. The essence of a small organization is that people wear many hats, which is not an issue so long as leaders are aware which hat they need to wear when making a decision. For example, if the head of engineering is also the product domain specialist and major contributor to product management, they must be careful not to let decisions regarding which features are necessary from a customer perspective be driven by which features are attractive from a development perspective.

Download PDF.