Simple Led Nameplates for coworkers -- Kicad/PL9823/Atmega8/Arduino/NeoPixel /w github

This was a quickie that came out really cool...

I designed this project around parts I have mass quantities of... Mainly leftovers from other projects. This kind of thing is a great way to pare down your parts hoard!  This why the PCB is a mishmash of odd components... I have a crap load of ATMega8 PDIP package chips... like seriously 300 or so of them. (Dont ask)  So I tend to use them everywhere.

I designed these around http://dirtypcbs.com/ prototype service which is 10 boards 10x10cm for around 16 bucks. This means my friends get one sign and about 9 personalized coasters ;-)

 In kicad I simply plopped my prebuilt ATMega8 MCU board sck file as a hierarchical sheet then broke out nets for the brightness knob analog input, button input and PL9823 pixel data output (A ws2812 compatible in a 8MM T package LED... I LOVE These things!).


Using 12 of these PL9823 8mm devices is way overkill but you can control the brightness with the pot, I didn't really know how it would cast through the PCB so I figured better to be too bright than too dim.  It sure is pretty though.  I do the fronts in 1.2mm thickness and the back in 1.6mm.

 I put the footprint for two POTs since i have lots of both. Also my original ATMega board needed timekeeping it had footprints for crystal oscillator, this design didn't so I did not populate the crystal and even left out some of the bulk and bypass caps... simply not needed.

The pixels are arranged in a string of course, and I added headers for the input and output data... This way I can chain them to another neopixel board or another one of these that simply does not have the MCU populated.  With things like this I try to make the boards are re-usable as possible.  Adding extra footprints is free!




The whole design took a couple hours since I was re-using huge parts of previous designs. If i had it all to do again I probably would have added a serial header to allow easier re-programming. As it is, I am using an ISP programmer which most people will not have on hand. But this was a carry over from the reused block.  If i had done that, this board would look like a Arduino UNO in the Arduino UI. But oh well, that will be V2.5 I guess...

For the logos and graphics i used KiCad's Bitmap2Component and put them on the solder mask layer.  The front has most of the solder mask removed on the back and selectively removed on the front.  This combined with copper layers determines where and how the light passes through the PCB.  The red soldermask completely absorbs some wavelengths of light while the fiberglass PCB transmits everything. So you get a great alternating effect as a given color reacts to the different materials. You really have lots of options to get some cool effects.

I have posted all the design files and code to github.  Links below! Enjoy!

Sources:  https://github.com/sysmatt-industries/SYSMATT-PL9823-SIGN-10X10

IoT Stranger Danger! -- From an IT Professional and Electronics Hobbyist / Ramble-n-Rant

I sit on two sides of this problem. I am an IT Professional, currently Enterprise Architect at New Jersey Institute of Technology.   My Department manages everything server, storage and network on our campus. We see every manner of device installed (or attempted to be installed) on our network. Consumer devices, smartphones, industrial control devices, PLCs, cameras ... Everything (Even a internet connected fish tank! Seriously.)

On the other hand, because of my embedded/electronics background, I am intimately familiar with the microprocessors, firmware complexities, networking stacks and protocols at play in these devices. Quite simply when you build a device, try to make it as cheap as possible, then make it participate in an increasingly complex network jungle, you are asking for trouble.

Consumer devices are built down to a cost, which means they will often use the smallest microcontroller possible and offload complexity "elsewhere". This means devices like WiFi light bulbs and thermostats often depend on a service running in the cloud for advanced functionality. The simpler you can make a hardware device the less likely there will be show stopping bugs. By using a cloud service the product designer moves some of that bug risk to something under their direct control. A server run in the cloud is capable of giving the user a lush App/GUI, complex functionality and integration with an ever changing field of other devices.

The IoT ecosystem is rapidly evolving, making sure that a consumer device works with IFTTT, twitter, gmail, facebook etc is a minefield of APIs. Putting that complexity directly in the device would be expensive and require frequent firmware updates. (more on that later!)

So, these devices often depend on a cloud service, Does the owner need to know? Most will not care until it stops working. But the design of the device and how it communicates with the owner will largely determine it's lifespan.

From a user's perspective, if it stops working, it's broken and when it's broken, it's trash. Many of these devices will have a direct and short path to the landfill if the company goes belly up and/or shuts down the cloud components. For example, NEST, now owned by Google, announced they would be shutting down their "Revolv" cloud service making the hardware devices junk. To their credit they offered the users a refund. But it's a good example of how a physical device's functionality depends on stuff outside the control of the user.

Let's talk about security... It's a jungle out there. We often think that our local network (home or corporate) is a walled off garden. But this is not really the case. The jungle creeps in...

Consider small embedded device... Let's say a consumer WiFi controlled lightbulb... camera, or a network connected alarm panel. Believe it or not, they are remarkably similar. All have a small microcontroller running a minimal (but complicated!) network stack. They are both likely to be "stuck in time" and forgotten after being installed. Meaning, once the owner "gets it working" it will rarely (or never) have it's firmware updated, at least as long as it continues to work. And finally, after some duration, sometimes remarkably short for consumer items, the company that produced this device will stop supporting it, or worse completely disappear. From the above cloud discussion we know this can spell certain doom for the complex functionality, but lets assume that this device allows you to directly control it and does not rely on a cloud service.

When network connected devices get "stuck in time" they become a hazard to the network owner.  (this means you) This can be a campus with 10,000 deices or your home network with ~10 devices. The scale is different but the hazard is the same.

In some cases the device firmware is vulnerable to direct attack. Perhaps a OpenSSL or HTTPD vulnerability, maybe combined with a Linux kernel hole that allows arbitrary code execution. This can mean that another peer device on the same network can gain access to and control or adulterate firmware on a device. This can be a toehold for a larger attack or simply become a "bot" used to attack elsewhere on the network.

Even if an attacker is not a peer on your local network, these devices are often allowed to make unfettered outgoing connections. If you can induce a device to make an outgoing call to a malicious site, perhaps a malicious DNS server, you may be able to exploit a hole which gives you access an attacker can build on. This means an attacker need not already be on your network. You at home, could browse a malicious website, your computer gets infected and looks for other vulnerable devices on your network. This really does happen and it means your DVR or IP Camera may be quietly participating on a Distributed denial of service (DDoS) attack controlled by a BOTnet.  (See: http://arstechnica.co.uk/information-technology/2016/10/inside-the-machine-uprising-how-cameras-dvrs-took-down-parts-of-the-internet/)

Ok, So we have the cloud service evaporation risk, the "Stuck in time" risk, and all those security risks. What should we do? Simply keep using normal light switches? (Well yes, but don't get me started on that...)

I think we all just need to understand where we are in IoT's hypecycle (See: https://en.wikipedia.org/wiki/Hype_cycle) ... We are firmly, I think, on the roller coaster headed down toward the "Trough of Disillusionment". There are going to be some big IoT casualties, some big security exploits, and a LOT of junk in landfills. Understand the risks and proceed with caution. Some suggestions:

• Don't buy expensive crap -- This might sound obvious but the wording is specific.  If your going to spend a wad of cash on a gadget, try to understand the parent companies commitment to being in business and product support in comparison to how bid the wad is.  If you are buying a whiz-bang cheapo ~$20 IoT gizmo, it's not too difficult to recoup that value even if it doesn't last that long.  (putting landfill ecology aside)  
• Build a wall -- You might consider setting up a isolated WiFi WAP dedicated to un-trusted IoT devices.  Decent consumer access points are sub $50 these days, and most will intelligently select non-conflicting channels.  This can offer a lot of protection but can also break funcationality, its a trade off.
• Keep on top of firmware -- Some IoT devices will tell you wen new firmware is available... but that only works if you actually look at the app from time to time.  Lots of these gizmos are set-and-forget, well try not to forget them for too long.   
• Keep on top of the vendor -- If the company is out of biz or if the product is abandoned/end-of-life'ed it is likely that firmware updates will dry up and you will not know.  If this happens it is important to consider taking those devices off the network.   They become a growing risk as new security vulnerabilities are found. 
• Buy devices that have direct control -- Some devices have direct control in addition to a more luscious IoT API.    This means, for instance, even if IFTTT support evaporates you can still have some level of control using direct communication with the IoT device.   This is usually a web interface running right on the device, or a app that does not require a cloud service.

In the coming years there will be lots of development of IoT security.  There is a gaping hole for some enterprising developer to fill with a intelligent stateful firewall aimed at IoT devices.   Think of this as a virus/malware protection for your home network that prevents IoT devices from doing bad things based on signatures and heuristics.   I think this will be a growth area for consumer home networking in the next couple years.  Until then, keep safe!

Allow me to wax philosophical for a moment... On yesterday

(warning, this is not a typical nerd post!)

Children are not born knowing hate.   They are born into a language-less world knowing only love, friendship and cooperation.  Their young minds and bodies need the cooperation of parents to survive and grow.  They don’t know division, bias or hate.  Over time these concepts are absorbed, hopefully not intentionally, but they sneak in.  The idea that people deserve judgement.  That knowing a single fact about a person means you do not need to know anything else.  Sometimes these ideas, ingrained in adults, become reinforced by societal structures.  But we adults make the rules, and we can change them.  

Yesterday, another one of those societal structures was corrected.   That arc of justice was bent just a little more toward that childish ideal world without bias or division.  It’s a long arc, and there is a lot more bend left to go, but it moved.  We all felt it.   

Today, I am proud of my fellow adults.  

Children of today will likely know nothing of rotary telephones or the horrors of dialup internet.  They belong in museums too.  It is exciting to think that, now, maybe, if we just stay out of their way, they will also never know limits to who they can love. 

The Novena Motherboard / And a post because I was told I should...

Much to my (@sysmatt) delight, my Novena motherboard was waiting on my doorstep when I got home friday night.  Bunnie Huang and (@bunniestudios) Sean Cross's (@xobs) open source motherboard.

At first glance it's simply beautiful.  I knew the dimensions ahead from the mechanical drawings, but it is still surprising how small it is for what is packed into it.  There is a lot of art and engineering that goes into laying out a board of this complexity.

And when was the last time you got anything (that wasn't test gear, and even that is rare today!) that included schematics?  On paper no less!

After making the customary backup copy of the included 4gb SD card, we plug in the very nice 18v 3.4a power brick... (Novena branded, nice touch) and we get linux kernel boot goodness.  I feel at home.  

I think it is pretty safe to say the Novena project is the first of its kind.  There have been many linux devboards over the years, but this one seems special.  It is targeted and tuned for a very specific hacking/fuzzing/etc audience, but also generic enough to be useful for a very broad hobbyist community.  The inclusion of the FPGA just blows the doors off the possibilities.  

That is all for now, Expect more posts a about Novena, and watch my @sysmatt twitter for micro updates!

Enough gushing, time to dig in.
-Matt

Manage your Raspberry Pi with a shell session in a web browser -- Introducing ShellInABox

Image Credit:" Raspberry Pi B+ top" by Lucasbosch - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons
.
Sometimes you need to log into a Pi (Or any Linux system for that matter) and you do not have a SSH client installed on the machine you happen to be behind. I have built lots of Raspberry Pi based gizmos and sent them on their way to parts unknown. Using a little chunk of software called "shellinabox" you can use any modern web browser to get a shell session. No plugins, no Flash, no Java applets, no putty, no trying to find the terminal app on a mac. Just point your browser and login. Shellinabox is remarkably fully featured, supporting full VT terminal, colors, copy/paste clipboard, and more. Running VIM and other full screen applications work perfectly. This awesome software has had a long lineage, originally based on a Java Applet the creator Markus Gutschke recently rewrote it to only use javascript, css and AJAX. All standard in modern browsers.

Shellinabox is completely self contained and does all it's work over one port (tcp/4200 by default). It is also relatively light weight, using about 5MB of memory on my systems. The default configuration does exactly what you would expect, when you point a web browser at it it will ask you for a username and password and logs you in to a shell session. Under the hood there are a lot more capabilities. You can actually substitute any interactive program in place of the login shell.

Installing Shellinabox

If you happen to be running Raspbian this is going to be really easy. Shellinabox is a standard package. All we need to do is install it and optionally do some customization.

pi$ sudo apt-get install shellinabox

If you want to install from source code or just explore how Shellinabox works, visit http://code.google.com/p/shellinabox.

Customize Shellinabox

You can completely skip this section if you like the default look and feel. Personally black text on white background makes my eyes bleed, so below I will include the steps to customize the colors. I prefer black background, call me old school, but I like the CRT type experience for shell sessions. White on black is acceptable, green on black is preferable.

All configuration for Shellinabox happens in /etc/shellinabox and /etc/default/shellinabox. The color themes are all handled by regular CSS so they are easy to modify. Style sheets are stored in files under /etc/shellinabox/options-available and use filenames that define their precidance with a number. This determines the order in which they are interpreted and the underscore (_) or plus (+) determines if they are enabled by default. These files are then symlinked into /etc/shellinabox/options-enabled to make them available to the user. To give me green on black, I create a file /etc/shellinabox/options-available/00+Green On Black.css which contains:

#vt100 #cursor.bright { background-color: white; color: black; } #vt100 #scrollable { color: #00ff00; background-color: #000000; } #vt100 #scrollable.inverted { color: #000000; background-color: #00ff00; } #vt100 .ansi15 { color: #000000; } #vt100 .bgAnsi0 { background-color: #00ff00; }

Then, I make the symlinks:

pi$ cd /etc/shellinabox/options-enabled pi$ sudo rm -f 00* pi$ sudo ln -s ../options-available/00+Green\ On\ Black.css . pi$ sudo /etc/init.d/shellinabox restart

This will leave you with:

ls -l total 4 lrwxrwxrwx 1 root root 42 Nov 18 12:10 00+Green On Black.css -> ../options-available/00+Green On Black.css lrwxrwxrwx 1 root root 42 May 3 2012 01+Color Terminal.css -> ../options-available/01+Color Terminal.css lrwxrwxrwx 1 root root 38 May 3 2012 01_Monochrome.css -> ../options-available/01_Monochrome.css -rw-r--r-- 1 root root 189 May 3 2012 README

Connecting

To connect to your Pi, aim your web browser at port 4200. Use the URL: http://nnn.nnn.nnn.nnn:4200/ where nnn.nnn.nnn.nnn is the IP address or hostname of your Raspberry Pi. You will likely be prompted with a SSL Certificate warning similar to the one below which is from Google Chrome. You can create real certificates for shellinabox, check the documentation if you want to. For now we will proceed by clicking the dialog as shown.

Once past the SSL warning you will be requested to login with a username and password. Do it. Once you are in, you are free to shell around to your hearts content.

Conclusion

Shellinabox is a great little tool to have in your toolbox. When you need to deploy a Raspberry Pi and might need to log in from a station that might not have a SSH client. Use them together, use them in peace.

Thanks for reading, Feedback to @sysmatt on twitter or comment below!

Like this article? Maybe you would like some of my other tutorials and articles: http://sysmatt.blogspot.com/

Busy Beaver Turing Machines - Computerphile

Raspberry Pi Backup/Restore scripts and tutorial updated for NOOBs based SD cards!

Image Credit:" Raspberry Pi B+ top" by Lucasbosch - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons
.
Hi friends, I have made changes to the original article and scripts on github to support NOOBs SD cards. These SD cards can contain one or more raspberry PI operating systems. My scripts will backup one of those (linux based) OSs and allow you to restore it to a fresh SD. Note, it will only backup whichever OS is booted, and only that OS. During the restore script run, it will grow the partitions to fill the entire SD card. I have tested it with Raspbian and Pidora. Thanks and Enjoy!

Quick note of thanks to @KevinSidwar who pointed this out to me, I had never used NOOBs and it's an important feature for my scripts to support since a lot of new Rapsberry Pi come with a NOOBs card these days. Thanks Kevin!
You can find the article at: http://sysmatt.blogspot.com/2014/08/backup-restore-customize-and-clone-your.html

Classroom (mini) Supercomputer using Raspberry Pi

Ok, so it will not solve the next quantum physics conundrum, but it might just ignite a spark in the next comp sci or physics genius.  This is "Tiny Titan" designed at Oak Ridge National Laboratory specifically to get students thinking parallel.  Writing software for massive high performance computing (HPC) systems is no easy task.  With the simple hardware design built from low cost $35 Raspberry Pi boards and example projects a student can get their feet wet.  On the Tiny Titan github there is example code in C and Python and lots of documentation.

Tiny Titan: https://www.olcf.ornl.gov/2014/06/02/titans-tiny-counterpart-engages-educates/
GitHub: https://github.com/TinyTitan

UNIX: Old School (updated for Raspberry Pi!)

Preface

It's been a long time since I originally wrote this article back in 2005 for Linux Journal. Do people even read paper any more? *smirk* I figured it needed a little update. I will walk you through all the steps necessary to boot up ancient UNIX (ancient as in 1970s) on your very own computer using the SIMH simulator. I also include special notes if you want to run the examples on the Raspberry Pi and Raspbian. (Which didn't even exist in 2005!). Enjoy!

Image Credit: "Pdp-11-40" by Stefan_Kögl - Own work.
Licensed under CC BY-SA 3.0 via Wikimedia Commons.

I have been called “nostalgic beyond my years” by some, and I suppose that is accurate. I was born in 1976 during UNIX's childhood. Little did I know we would grow up together and meet later in life.

I have always had a voracious appetite for early minicomputer and mainframe history. I believe recorded history itself is the single-most important innovation of human existence. We humans seem to have a hard-wired compulsion to record, pass on and learn from the mistakes and successes of those before us. Open-source software and hardware is the natural evolution of this concept applied to technology. In the Open Source philosophy, we are all free to learn from the wealth of software created by the masses that came before us. By examining the evolution of a project, we can learn from the mistakes of others and, perhaps most important, copy verbatim from their successes. By harnessing this freely available history as well as unfettered cooperation, we advance the common good.

Recently, some companies have begun to loosen their grip on the early computing “intellectual property”. Although some have not fully embraced open source, these sometimes small, token gestures offer us a wealth of knowledge. In this article, I focus on how we can explore early operating system history by running “historic” UNIX releases on our very own Linux boxes using a simulator. The SCO Group (Yes, “them”, previously Caldera, Inc.) claims current ownership of early UNIXes and has released them under an “Ancient Unix” license, which allows for noncommercial use.

I focus here on the UNIX V5 release, because it is the earliest available UNIX. UNIX V6, V7 and various early BSD releases are also available. If you plan on trying out any of these OSes, examine the licenses included with each before booting them up.

Stranger in a Strange Land: the UNIX V5 User Environment

The UNIX V5 system provided in the disk image we will use is rather stark and unfriendly compared to modern, lush UNIX/Linux systems. Here are a few pointers before we get started:

• sh is the shell. It's only 858 lines of C; don't expect it to work like the /bin/bash shell.
• Use chdir to change the default directory.
• Backspace and arrow keys rarely work.
• ed is the text editor; see en.wikipedia.org/wiki/Ed.
• bas is a basic interpreter.
• fc is a FORTRAN interpreter.
• cc is the C compiler.
• Source code is in /usr/source.
• There are not many files (528), so use find / -print to see what else is included. It should scroll by just fast enough to read it ;-)

In order to explore these OSes, we need to be able to run them on commonly available computing hardware. Luckily, we have simulators for this purpose. Because of its quality and depth of support, one of the most popular simulators is SIMH, It was created in 1993. SIMH is available from the SIMH Web site (see the Resources below). SIMH is available as source code and compiles and runs on every popular *nix OS, as well as Microsoft Windows. It is capable of simulating a wide range of early computer systems, including Digital Equipment Corp.'s PDP and VAX systems, the MITS Altair, early IBM systems and many more. Some of the most historically significant systems are DEC's PDP series, the birth-system of UNIX.

SIMH is a ground-up system simulator; it simulates the CPU, memory, firmware and devices of a number of early computer systems. This means that original distributed software can run unmodified on these simulated systems. SIMH successfully simulates devices such as disks, tape drives, printers and networking devices. This means that not only can we run these historic systems, but we can communicate and transfer data to and from them using modern technologies and protocols. A great deal of thanks is owed to the authors and contributors of SIMH. Their decision to release under open source furthers all our understanding of our history and guarantees that this history will always be free.

Getting Started: Installing SIMH

Raspberry Pi Note If you are running this on a Raspberry Pi running Raspbian you are in luck, SIMH is available as pre-built software. Skip the compile in this section and just install simh using apt-get: sudo apt-get install simh Then just skip to Running UNIX V5

Below I will detail the command line steps needed to download and compile the SIMH source code. The latest SIMH release is V3.9-0 at the time of this writing.

If you want to use Ethernet emulation, you will need to install the PCAP development packages for your OS. The SIMH installation documents explain how to do this, and you can skip this step if you're not going to be using networking support on your simulated machines. If you are running Fedora or similar you can simply run:

$ sudo yum -y install libpcap-devel

The stuff you type to compile SIMH is below in bold.

$ mkdir simh $ cd simh $ wget http://simh.trailing-edge.com/sources/simhv39-0.zip $ unzip simhv39-0.zip $ mkdir BIN (Note all CAPS) $ gmake USE_NETWORK=1 all (Note: Only include USE_NETWORK=1 if you have PCAP development libs installed) (compilation chatter omitted, go get a cup of coffee, this will take a moment... You can ignore any WARNINGs) $ ls -l ./BIN/ total 11624 -rwxrwxr-x 1 matt matt 301959 Jul 16 18:45 altair -rwxrwxr-x 1 matt matt 482274 Jul 16 18:45 altairz80 -rwxrwxr-x 1 matt matt 529317 Jul 16 18:44 eclipse -rwxrwxr-x 1 matt matt 297590 Jul 16 18:45 gri -rwxrwxr-x 1 matt matt 375737 Jul 16 18:44 h316 -rwxrwxr-x 1 matt matt 577678 Jul 16 18:44 hp2100 -rwxrwxr-x 1 matt matt 355225 Jul 16 18:44 i1401 -rwxrwxr-x 1 matt matt 381672 Jul 16 18:45 i1620 -rwxrwxr-x 1 matt matt 441079 Jul 16 18:46 ibm1130 -rwxrwxr-x 1 matt matt 502037 Jul 16 18:46 id16 -rwxrwxr-x 1 matt matt 508378 Jul 16 18:46 id32 -rwxrwxr-x 1 matt matt 294614 Jul 16 18:46 lgp -rwxrwxr-x 1 matt matt 434940 Jul 16 18:44 nova -rwxrwxr-x 1 matt matt 345034 Jul 16 18:41 pdp1 -rwxrwxr-x 1 matt matt 752055 Jul 16 18:43 pdp10 -rwxrwxr-x 1 matt matt 1055376 Jul 16 18:43 pdp11 -rwxrwxr-x 1 matt matt 474153 Jul 16 18:42 pdp15 -rwxrwxr-x 1 matt matt 459203 Jul 16 18:41 pdp4 -rwxrwxr-x 1 matt matt 460363 Jul 16 18:41 pdp7 -rwxrwxr-x 1 matt matt 499473 Jul 16 18:42 pdp8 -rwxrwxr-x 1 matt matt 467662 Jul 16 18:42 pdp9 -rwxrwxr-x 1 matt matt 352233 Jul 16 18:45 s3 -rwxrwxr-x 1 matt matt 429312 Jul 16 18:46 sds -rwxrwxr-x 1 matt matt 982694 Jul 16 18:43 vax

This builds all possible system simulators. Each simulator becomes a separate binary in the ./BIN/ directory. SIMH can be run as any normal user, but if you want to use Ethernet network simulation, you need to execute it as root (under UNIX) to allow libpcap access to the Ethernet device. Otherwise, continue as any non-root user. Our particular example of UNIX V5 does not use networking.

Running UNIX V5

Raspberry Pi Note If you are running this on a Raspberry Pi running Raspbian you can perform all these steps as the "pi" user in it's home directory. Make sure you have at least 4MB of free space. (Yes, You read the correct. The entire UNIX V5 is less then 4MB.)

UNIX V5, released in June 1974, was still very early in UNIX development at Bell Labs. Much of the system was still written in assembler. This disk image includes a working C compiler (cc) and a great deal of interesting source code under /usr/source.

To begin our exploration, we must download the UNIX V5 disk image. In the same shell as you compiled SIMH, run the following:

$ mkdir uv5 $ cd uv5 $ wget http://simh.trailing-edge.com/kits/uv5swre.zip $ unzip uv5swre.zip

This zip archive contains the pre-installed image file as well as a README and file containing license information. The disk image is a snapshot of a working installed system. In this case, it is simulating an RK05 disk drive. We must now collect the pieces we need to get this system booted. Begin by copying the BIN/pdp11 binary from under the SIMH build into our uv5 directory, then we will create a small config file "pdp11.ini" that tells the simulator how to boot UNIX.

Raspberry Pi Note If you are running this on a Raspberry Pi running Raspbian skip the next step where you copy (cp) the pdp11 binary and instead, run the following: ln -s /usr/bin/pdp11 .

$ cp ../BIN/pdp11 .

Create a file pdp11.ini with your favorite editor and place the following lines in it.

set cpu U18 attach rk0 unix_v5_rk.dsk boot rk0

This tells the simulator what kind of CPU to emulate and to attach the unix_v5_rk.dsk file as a simulated RK-style disk using the rk0 device name. Finally, this file tells the simulator to boot the OS image on that disk.

Your uv5 simulator directory should look like the following:

$ ls -l total 3916 -rw-rw-rw- 1 matt matt 12299 Jan 24 2002 AncientUnix.pdf -rwxrwxr-x 1 matt matt 681169 Aug 16 20:13 pdp11 -rw-rw-r-- 1 matt matt 47 Aug 16 20:18 pdp11.ini -rw-rw-rw- 1 matt matt 263 Nov 25 1996 README.txt -rw-rw-rw- 1 matt matt 2494464 Sep 8 1998 unix_v5_rk.dsk -rw-rw-r-- 1 matt matt 806708 Jan 31 2002 uv5swre.zip

We are ready. Let's boot UNIX V5 and have some fun! Follow the example session below or go off on your own exploring. Note, you will likely need to use CTRL-h as backspace if you make a mistake.

$ ./pdp11 PDP-11 simulator V3.9-0 Disabling XQ @unix login: root # ls -l / total 60 drwxr-xr-x 2 bin 944 Nov 26 18:13 bin drwxr-xr-x 2 bin 80 Nov 26 18:13 dev drwxr-xr-x 2 bin 240 Mar 21 12:07 etc drwxr-xr-x 2 bin 224 Nov 26 18:13 lib drwxr-xr-x 2 bin 32 Nov 26 18:13 mnt drwxrwxrwx 2 bin 112 Mar 21 12:11 tmp -rwxrwxrwx 1 bin 25802 Mar 21 12:07 unix drwxr-xr-x 14 bin 224 Nov 26 18:13 usr

Let's look at some source code, starting with the "echo" program. It's small and simple.

# chdir /usr/source/s1 # cat echo.c main(argc, argv) int argc; char *argv[]; { int i; argc--; for(i=1; i<=argc; i++) printf("%s%c", argv[i], i==argc? '\n': ' '); }

Let's compile the echo program, rename it and run a "Hello World"

# cc echo.c # mv a.out newecho # ./newecho Hello World Hello World

Nice! Now, let's create, compile and run our own hello world C program. We will use "cat" as a poor man's editor to create the source file.

# chdir /tmp # cat >hello.c main() { printf ("Hello World!\n"); } Hit CTRL-d here # cc hello.c # ./a.out Hello World!

Let's try a basic program next, use cat to create hello.b with some basic source

# cat >hello.b 10 print "Hello World!" Hit CTRL-d here # bas hello.b run Hello World!

All done for now, Let's HALT the system. In true historical UNIX style, we will run sync three times, then push the HALT button. Or in our case, the SIMH equivalent which is CTRL-e

# sync; sync; sync # Hit CTRL-e here Simulation stopped, PC: 001726 (MOV (SP)+,177776) sim> exit Goodbye

That's it! You're up and running. You have officially set your fingers on a “real” historical UNIX system. As you can see, there is plenty of source code to look over and a working compiler to play with. UNIX V5 is only one of the early operating systems you can explore with SIMH. On the SIMH Web site, you will find a repository of disk images for lots of other systems. The learning curve can be quite steep on these older OSs but there is a lot to learn from them. You can find conceptual bit and pieces of them strewn about inside all modern systems. It's living history at your fingertips.

If you are interested in seeing what a PDP-11 system and RK05 disk actually looked like, take a look at the photo gallery on the SIMH Web site (see Resources). Also, try searching Google Images for a wealth of great photographs.

Resources

• SIMH Web Site: simh.trailing-edge.com
• SIMH Users Guide: http://simh.trailing-edge.com/pdf/simh_doc.pdf
• SIMH Photo Gallery: simh.trailing-edge.com/photos.html
• SIMH Contributors: simh.trailing-edge.com/contrib.html
• PDP-11 History and Photos: www.pdp11.org
• UNIX History Timeline (Printable!): www.levenez.com/unix/
• Open Group UNIX History: www.unix.org/what_is_unix
• The Unix Heritage Society: www.tuhs.org
• PDP Unix Preservation Society: minnie.tuhs.org/PUPS

About the author

Matthew is the Senior Enterprise Architect at the New Jersey Institute of Technology (NJIT). When he is not working, he enjoys hacking on electronics, microcontrollers and embedded systems. He can also make a mean falafel when the circumstances call for it. Matthew is a total nerd and thus completely useless in conversations regarding "sports". Matthew also greatly dislikes talking about himself in the third person in author biographies.

For more random nonsense from Matthew he suggests following him on twitter: @sysmatt

Like this article? See more of Matt's published works

So, That was interesting.   I've written articles for print media, Quite a few for the likes of Linux Journal.   My recent blog post http://sysmatt.blogspot.com/2014/08/backup-restore-customize-and-clone-your.html was somewhat of an experiment.  

The response has been really cool.  It got picked up by Hackaday and Lifehacker.  It was also re-tweeted by Adafruit and a dozen others.   And heck of a lot more feedback when when my stuff ended up on dead trees.

Anyway, this was sort of a ramble, but i think there will be more posts like the last one.   It's been a ride!

Novena Open Source Board and Laptop / Linux / Bunnie Huang et al -- Collected Videos

I'm a backer. Very excited. Here is a collection of good videos covering the Novena board and laptop

---

---

---

---

Great blog post about NAND storage, reverse engineering and recovery

Amazing stuff: http://joshuawise.com/projects/ndfslave

Joshua Wise accidentally destroys his SD card, rather be content with data loss and move on -- He pulls out a FPGA devboard and de-solders the NAND chip. This great blog post walks us through the entire process from smashed SD card to files recovered.

Backup, Restore, Customize and Clone your Raspberry Pi SD Cards (tutorial) [Updated 8/30 for NOOBs SD]

Image Credit:" Raspberry Pi B+ top" by Lucasbosch - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons
.
NOOBs Users: Note, My scripts on github have now been updated to support NOOBs distribution SD cards. See below in the script section for more details.

Ladies and gentlemen, if you are like me, you probably have a few raspberry pi. (Piis?) I have found them to be great little Linux development boards supported by a huge community. Whenever I need a net connected microprocessor project, the pi is an easy win. I have used it in internet connected clocks, LED signs, RGB lighting projects and so many other crazy projects. They make a great internet gateway for Arduino projects. This use is the very definition of "embedded", a raspberry pi with no keyboard, mouse or monitor. It boots, connects and does it's programmed task. It would be a huge inconvenience to manually configure every one of these starting from a raspbian .img file. Even if your not into electronics, manipulating the SD cards directly will make your life a little easier.
Now would be a great time to introduce my "day job". I am a professional *NIX system administrator and system architect. So when I see a raspberry pi I see a Linux box. UNIX/Linux systems are very easy to clone, it's just a pile of files. I will start with some basic theory and how to work with the SD card from the command line. Then, I will introduce you to my scripts which automate the process.

No Magic here

Exactly how the raspberry pi boots is widely misunderstood. And no wonder, it's ummm, complicated. In almost every computer architecture "bootstrap" is messy and complicated. For the user though, the raspberry pi has kept it pretty simple, its just files on the SD. Interface wise, the SD card looks like a disk. Upon that disk are two partitions, a DOS (vfat) partition which contains almost everything necessary for booting, configuration, firmware, and kernel images. Why FAT? Well, when constructing a bootstrap process, the name of the game is simplicity and small code size. The DOS FAT filesystem is very simple compared to modern filesystems, it's also very well understood and pretty universal. The "userland" part of the Linux operating system lives in the second partition which is usually ext4. When the raspberry pi powers on, small chunks of firmware step by step load code into the GPU and CPU until it can eventually load the Linux kernel. This finally makes the system smart enough to mount the slash "/" partition and do all the userland linuxy stuff.So once we understand how it's using the SD card, we can duplicate it and pre-configure if before we even power it on. No magic, It's all just regular files and some *NIX know-how.
Why not just use "dd"? The problem with the standard unix dd utility is it only copies raw disk blocks. For one, your average SD card is mostly unused disk blocks. But dd just copies them sequentially and wastes a lot of time. If you store just the OS files, you get automatic resizing when you restore your archive to a different size SD card. As long as the destination SD is big enough to hold the image, it doesn't matter what size the source card was. Finally, the tar approach allows you to untar and re-tar the archive to modify the archive without it ever booting.

Basic Manual Cloning

The first use case we will explore cloning a running raspberry pi to a fresh SD card. To make things easy, we will do all these steps on the actual raspberry pi. You will need to have one free USB port and a USB SD card reader. We will do this step-by-step from the command line, this will give you a good idea how my scripts are constructed later.Power on your Raspberry pi, and log in by whatever means you prefer (graphical, ssh, etc). Get to a command prompt and sudo to a root shell, everything we are going to do needs root privilege. You will also need to install the dosfstools package which is used later. Then, plug in your SD card to any free USB port. Use the "dmesg" utility to dump the kernel log, look at the output to determine what scsi device your new SD card has been assigned. (stuff you type is underlined)

pi$ sudo su root# apt-get install dosfstools root# apt-get install rsync root# dmesg [ 147.590292] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 147.977885] sd 0:0:0:0: [sda] 15759360 512-byte logical blocks: (8.06 GB/7.51 GiB) [ 147.978590] sd 0:0:0:0: [sda] Write Protect is off [ 147.978623] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 147.979287] sd 0:0:0:0: [sda] No Caching mode page found [ 147.979314] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 147.982973] sd 0:0:0:0: [sda] No Caching mode page found [ 147.983007] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 147.986412] sda: sda1 sda2 [ 147.990030] sd 0:0:0:0: [sda] No Caching mode page found [ 147.990064] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 147.990089] sd 0:0:0:0: [sda] Attached SCSI removable disk

From the above, we can see that our SD card has been assigned "sda" which means /dev/sda is how we will get to it.
First, we need to create the two partitions to hold our /boot and / (slash) filesystems. We do this with the GNU parted utility.

root# parted /dev/sda GNU Parted 2.3 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mklabel msdos Warning: The existing disk label on /dev/sda will be destroyed and all data on this disk will be lost. Do you want to continue? Yes/No? y (parted) mkpart primary fat16 1MiB 64MB (parted) mkpart primary ext4 64MB -1s (parted) print Model: Single Flash Reader (scsi) Disk /dev/sda: 8069MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 64.0MB 62.9MB primary fat16 lba 2 64.0MB 8069MB 8005MB primary (parted) quit

To summarize what we just did. First we use the "mklabel" to create a fresh msdos style partition table on /dev/sda, you will have to answer "y" to the warning. Next we create the partition to hold our FAT /boot filesystem, with a size of 64MB. Next we tell parted to create another partition to hold our slash (/) filesystem starting at the 64MB mark, and ending at the last available sector of the disk (-1s). We tell parted that these two partitions will be fat16 and ext4 respectively so it will set the correct partition type on each.
Finally we "print" the resulting partition table so we can see it, then exit with "quit"
The two partitions we just created are now available as devices /dev/sda1 and /dev/sda2. Next we need to format them. This is done with the mkfs.vfat and mkfs.ext4 commands:

root# mkfs.vfat /dev/sda1 mkfs.vfat 3.0.13 (30 Jun 2012) root# mkfs.ext4 -j /dev/sda2 mke2fs 1.42.5 (29-Jul-2012) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 488640 inodes, 1954304 blocks 97715 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=2004877312 60 block groups 32768 blocks per group, 32768 fragments per group 8144 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done

Excellent! Now we need to mount these two partitions somewhere so we can copy data to it. Let's make a temporary directory under /tmp/newpi and do all our work under it. Below are the commands to mount our SD cards:

root# mkdir /tmp/newpi root# mount /dev/sda2 /tmp/newpi root# mkdir /tmp/newpi/boot root# mount /dev/sda1 /tmp/newpi/boot root# df -h Filesystem Size Used Avail Use% Mounted on rootfs 15G 2.3G 12G 17% / /dev/root 15G 2.3G 12G 17% / devtmpfs 215M 0 215M 0% /dev tmpfs 44M 248K 44M 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 88M 0 88M 0% /run/shm /dev/mmcblk0p1 60M 9.4M 51M 16% /boot tmpfs 10M 0 10M 0% /tmp /dev/sda2 7.3G 17M 6.9G 1% /tmp/newpi /dev/sda1 60M 0 60M 0% /tmp/newpi/boot

Nice! The output of the "df" command will show us that both slash and boot have been mounted and are the expected sizes. In my case I am using a 8gb SD card. Next, we will execute a command to copy our existing raspbian OS installed on our running pi into our mounted SD card. Now, a couple notes about live cloning. If you are running any services that keep data files open (like mysql, postgresql, apt-get, or other applications) these should be shutdown to insure you get a clean copy. We will use the rsync utility for this copy, we will tell it to only copy / (slash) and /boot, further, we will also tell rsync not to cross filesystem boundaries (--one-file-system).
Why do we specify slash (/) and boot separately? If you look above at the df listing you can see lots of other filesystems mounted. Some of these are ramdisks and virtual filesystems (/sys, /dev, /tmp, and /proc for instance). We do not want to copy these at all. By using the --one-file-system and specifying explicitly slash (/) and /boot, we only capture the OS tree of files. ( Note, the rsync is sensitive to trailing slashes on the source and destination directory names, make sure you run it exactly as below)

root# rsync -av --one-file-system / /boot /tmp/newpi/ (lots and lots of files print out...) var/log/news/news.notice var/log/ntpstats/ var/log/samba/ var/mail/ var/opt/ var/spool/ var/spool/rsyslog/ var/tmp/ var/www/ sent 2204324795 bytes received 1303348 bytes 2608667.23 bytes/sec total size is 2199215758 speedup is 1.00 root# df -h Filesystem Size Used Avail Use% Mounted on rootfs 15G 2.3G 12G 17% / /dev/root 15G 2.3G 12G 17% / devtmpfs 215M 0 215M 0% /dev tmpfs 44M 248K 44M 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 88M 0 88M 0% /run/shm /dev/mmcblk0p1 60M 9.4M 51M 16% /boot tmpfs 10M 0 10M 0% /tmp /dev/sda2 7.3G 2.3G 4.6G 33% /tmp/newpi /dev/sda1 60M 9.4M 51M 16% /tmp/newpi/boot

Cool, after the copy completes, we run "df -h" again and can see that the destination slash mounted on /tmp/newpi matches in size our running system's slash, at about 2.3G. So now, what else can we do? Well the sky is the limit really. We have a ready to roll raspbian SD card mounted and ready to customize!

Just a couple examples of things you can customize... Change the hostname root# vim /tmp/newpi/etc/hostname (or without using an editor) root# echo "mynewhostname" > /tmp/newpi/etc/hostname Change the network interface settings, or set a different static IP: root# vim /tmp/newpi/etc/network/interfaces Example: Wireless /w DHCP: auto lo iface lo inet loopback iface eth0 inet dhcp iface default inet dhcp auto wlan0 allow-hotplug wlan0 eth0 iface wlan0 inet dhcp wpa-passphrase MY-WIRELESS-PASSPHRASE wpa-ssid MY-WIRELESS-SSID Example: Wireless /w static IP: auto lo iface lo inet loopback iface eth0 inet dhcp iface default inet dhcp auto wlan0 allow-hotplug wlan0 eth0 iface wlan0 inet static wpa-passphrase MY-WIRELESS-PASSPHRASE wpa-ssid MY-WIRELESS-SSID address 192.168.1.22 netmask 255.255.255.0 network 192.168.1.0 gateway 192.168.1.1

(NOOBs Users: If you are running a SD card created with NOOBs, you will need to manually modify the boot/cmdline.txt and etc/fstab files on your new SD card before you can boot. You must edit and substitute the mmcblk0p* device names for the proper ones. In the fstab, slash (/) should be /dev/mmcblk0p and /boot should be /dev/mmcblk0p1. In the cmdline.txt file, root= part should be root=/dev/mmcblk0p2. Once you have done that the OS that you backed up will be the only OS on the new SD card event if your NOOBs SD had multiple flavors of raspberry pi OS installed. My scripts on github discussed in the next section handle all of this automatically, which makes things a bit easier.)These are just a few examples. When your ready to try out your cloned SD card, you should unmount it using the following commands. Make sure you close any shells or change your current working directory (cd) off the new devices or you will get an error when you try to unmount.

root# umount /tmp/newpi/boot root# umount /tmp/newpi

You can now safely pull the SD card out and put it in your destination raspberry pi. It should boot and work just like any other SD card.

Sysmatt's Scripts

Now that we have the basic concepts down, Let me show you some of my scripts to automate creating SD cards. These scripts allow you to create and store backup copies of your running raspberry pi systems. You can use this to construct a library of standard, tested, known good images. Very useful when someone wants you to build them a copy of your next talking clock project!We need to retrieve and install the scripts. You will find a link at the end of this article to the current version of the scripts. Download the latest tar archive and untar it into /usr/local/bin as shown below
Download the latest zip from github

root# cd /tmp root# wget -O sysmatt-rpi-tools.zip https://github.com/sysmatt-industries/sysmatt-rpi-tools/archive/master.zip

Install to /usr/local/bin or any other location you prefer

root# unzip sysmatt-rpi-tools.zip root# cd sysmatt-rpi-tools-master/ root# chmod +x sysmatt.rpi.* root# mv sysmatt.rpi.* /usr/local/bin

(NOOBs Users: These scripts have been updated to work with NOOBs SD cards. NOOBs is the SD card image that allows you to have multiple raspberry pi OS installed in different partitions. The way this is handled by the scripts is the OS you are running when you run the backup script is the ONLY os that is backed up. When you run the restore script it will automatically modify the files in /etc and /boot to reflect the changed partition numbers. Essentially this "peels out" one OS from your NOOBs SD and makes it the only OS running on the new (restored) SD. This also automatically grows the restored OS to fill the entire SD card.)

Making a backup archive

In these scripts I just use a tar archive to store the image. This makes them nicely portable and easy to modify. The first script is used to create the backup copy of the running raspberry pi. This script, "sysmatt.rpi.backup.gtar", by default creates it's backup file under the pi user's home directory with a default filename containing the hostname of the raspberry pi and the datestamp. You can override this filename by specifying an alternate on the command line. Below, I will run this script on the new pi we just cloned.If you so not have enough free disk space on your SD card to hold the tar archive you might want to write it to a flash drive or network mounted filesystem. You should be fine if your SD card is 8gb or larger and have not downloaded too much software/data.
To write the tar archive to /home/pi/backups:

root# mkdir -p /home/pi/backups root# sysmatt.rpi.backup.gtar (Lots and lots of files listed...)

Or, to specify an alternate location, run it with a filename argument:

root# sysmatt.rpi.backup.gtar /root/my.pi.backup.tar.gz

Either of the above will result in a backup copy of the running system being stored in a tar archive file. Again, a note of caution, if you have any programs that are actively writing to data files (mysql/postgresql/apt-get/etc) these should be not run while you make this clone so you get a clean copy.

Restoring / Cloning

The next script in the arsenal is a little more complicated. It is called "sysmatt.rpi.restore.sd.card", it automates all the steps we did above with partitioning, creating filesystems, and copying the raspbian image (in the tar archive we just created). This script will destroy everything on the destination SD card, so be careful! First, we insert our destination SD card into a free USB port and discover what /dev/sd? device it has been assigned. You should never assume without checking dmesg!Tip: This script will also work just fine on any Linux box, so you can create SD cards from a workstation also.

root# dmesg (removes lots of lines...) [ 6832.265765] scsi1 : usb-storage 1-1.2:1.0 [ 6833.262698] scsi 1:0:0:0: Direct-Access Single Flash Reader 1.00 PQ: 0 ANSI: 0 [ 6833.265306] sd 1:0:0:0: Attached scsi generic sg0 type 0 [ 6833.772774] sd 1:0:0:0: [sda] 15644672 512-byte logical blocks: (8.01 GB/7.45 GiB) [ 6833.773480] sd 1:0:0:0: [sda] Write Protect is off [ 6833.773513] sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 6833.774183] sd 1:0:0:0: [sda] No Caching mode page found [ 6833.774211] sd 1:0:0:0: [sda] Assuming drive cache: write through [ 6833.777814] sd 1:0:0:0: [sda] No Caching mode page found [ 6833.777846] sd 1:0:0:0: [sda] Assuming drive cache: write through [ 6833.779191] sda: sda1 sda2 [ 6833.785295] sd 1:0:0:0: [sda] No Caching mode page found [ 6833.785330] sd 1:0:0:0: [sda] Assuming drive cache: write through [ 6833.785360] sd 1:0:0:0: [sda] Attached SCSI removable disk

Ok, looks like this was assigned /dev/sda also. Don't assume!
Now we run the sysmatt.rpi.restore.sd.card script passing the name of the SD device and the tar archive to restore from. Note, your specific filename will be different.

root# ls -l /home/pi/backups/pi.mynewhostname.20140804162905.backup.tar.gz -rwxr-xr-x 1 root root 1431671079 Aug 4 17:49 /home/pi/backups/pi.mynewhostname.20140804162905.backup.tar.gz

Above listed is the tar archive we just created. We will now restore it using the next script. Note, it is interactive and will ask you for confirmation. Before the script exits it will give you the opportunity to modify the resulting SD card before it unmounts it.

root# sysmatt.rpi.restore.sd.card /dev/sda /home/pi/backups/pi.mynewhostname.20140804162905.backup.tar.gz === /dev/sda Current Partition Table - To be destroyed! === Model: Single Flash Reader (scsi) Disk /dev/sda: 8010MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 64.0MB 62.9MB primary fat16 lba 2 64.0MB 8010MB 7946MB primary ext4 PRESS ENTER to DESTROY /dev/sda, Press CTRL-c to abort Model: Single Flash Reader (scsi) Disk /dev/sda: 8010MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 64.0MB 62.9MB primary fat16 lba 2 64.0MB 8010MB 7946MB primary ext4 mkfs.vfat 3.0.13 (30 Jun 2012) mke2fs 1.42.5 (29-Jul-2012) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 485760 inodes, 1939968 blocks 96998 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=1988100096 60 block groups 32768 blocks per group, 32768 fragments per group 8096 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done Filesystem Size Used Avail Use% Mounted on /dev/sda2 7.2G 17M 6.8G 1% /tmp/pi.sd.324943213 Filesystem Size Used Avail Use% Mounted on /dev/sda1 60M 0 60M 0% /tmp/pi.sd.324943213/boot Press ENTER To begin image restore (lots and lots of files listed here ...) boot/fixup_cd.dat boot/fixup_x.dat boot/kernel.img boot/start.elf boot/start_cd.elf boot/start_x.elf boot/issue.txt boot/LICENSE.oracle boot/kernel_emergency.img tar: boot: implausibly old time stamp 1970-01-01 00:00:00 =DONE= The SD is mounted at: /tmp/pi.sd.324943213 Now would be a good time to make modifications in another shell session... Press ENTER To unmount or CTRL-c to exit leaving mounted.

Now here, the script is paused waiting for input, and you have a choice. If you wish to make changes to the SD card you can open another terminal and modify it under the mountpoint shown (/tmp/pi.sd.324943213 in this example), for instance, change the hostname like we did previously:

root# echo "yetanotherpi" > /tmp/pi.sd.324943213/etc/hostname

When you are done with your modifications, you can return to the session running the script and hit enter. It will unmount the SD card from it's temporary mountpoint. Make sure you have closed any programs or shells that might be holding the filesystems open. You can always try unmounting again with the "umount" command if necessary.
After it is unmounted, you can pull and insert it into your raspberry pi and boot it up. If you want to make the script non-interactive, feel free to remove or comment out the "read" lines that ask for confirmation. But do so at your own risk!
I hope you found this little tutorial helpful. Using these utilities and scripts you can build your own library of standard OS images, preconfigured for particular applications. This makes duplicating projects very easy and quick! If you have feedback on the tutorial or any of the scripts please let me know at matthoskins @ gmail.com or on twitter @sysmatt.

About the author

Matthew is the Senior Enterprise Architect at the New Jersey Institute of Technology (NJIT). When he is not working, he enjoys hacking on electronics, microcontrollers and embedded systems. He can also make a mean falafel when the circumstances call for it. Matthew is a total nerd and thus completely useless in conversations regarding "sports". Matthew also greatly dislikes talking about himself in the third person in author biographies. For more random nonsense from Matthew he suggests following him on twitter: @sysmatt Like this article? See more of Matt's published works

Resources:

GitHub: https://github.com/sysmatt-industries/sysmatt-rpi-tools/Good article about the Raspberry Pi's bootstrap process: http://thekandyancode.wordpress.com/2013/09/21/how-the-raspberry-pi-boots-up/

Hold on to your hats people...

Greetings all, I am putting the finishing touches on a few new full length articles which will be published on this blog. Hold on to your hats, Matt is publishing again! The first one will be titled: "Backup, Restore, Customize and Clone your Raspberry Pi SD Cards"... These are mostly Raspberry Pi from a pure Linux perspective.

Time for a post... Follow me on twitter! @sysmatt

Do it!

7-Segment LED Arduino Conway's Game of Life Display (UPDATE1)

Update.  Enclosed now, in beautiful ruby red plexi from eStreet plastics.  Also added two relays, simply for sound effects.  See video below.  Life generations progress faster upon every iteration, speed maxes out at 100 generations.   Max generations are 65k, upon which an integer rolls over and a new simulation is started.

Arduino based Network NTP Clock (Update2)

Progress... Started building case.  Ruby red plexi from eStreet Plastics.  Looks really slick.  Yes, that IS masking tape holding part of the 7-segment display in... I am still waiting for some IPS weld-on #3 glue... Damn ebay.

Arduino based Network NTP Clock (Update1)

More progress, Added a Sure Electronics 0832 Green Matrix LED Display for continuous time display.  Crappy video posted to youtube, http://www.youtube.com/watch?v=6AZAUVIAZak

Code almost done, still some tweaking needed.  Enclosure is next.

Arduino based Network NTP Clock

Ethernet, DHCP, IP, NTP, and all under 16k.   Sets software RTC in sync to an NTP server.  Displays time in seconds since 1970 (ala UNIX), 24hr format, Day of week, and full date.  Red LED 7-Segment displays using 74HC595 shift registers.

Video:  http://www.youtube.com/watch?v=QFSf9rBVMDY

7-Segment LED Shift Register detail

While building another 7-Segment LED display for a project I took some photos.  I've been asked by some for more detail on how those things are build and chained together.  This is the same style display I used in the Game of Life display from an earlier post.   These modules are assembled each with a 74HC595 shift register glued to the back "dead bug" style.  Each segment is driven by a output bit thru a resistor.   It makes for a very simple static (no scanning or multiplexing) display and very simply programming in the microprocessor.   I really have to make a circuit board for this!  Displays by the inch anyone?

Full Photo Album:  http://picasaweb.google.com/matthoskins/ProjectsArduinoLED7SegmentShiftRegisterDisplaysDeadBugStyle?feat=directlink