Saturday, July 9, 2016

Knowledge Vacuums

As the title of this blog would imply I'm generally pretty happy to talk tech with people when the opportunity presents itself.  I also don't mind showing someone new how to do something if they ask about it.  This is a great way to meet new people and get folks who are on-the-fence about electronics or computer technology to start getting interested.

There are, however, people who can best be described as knowledge vacuums.  If you've ever encountered one, you will instantly know what I mean.  These are people who ask question after question after question on a topic without ever doing any requisite discovery of their own.  In fact, if they're like the person I encountered recently, they will freely admit that they "don't have the time to read all that stuff."  I thought I would take a moment to identify the behavior and why it is bad.  It will hopefully help arm those who have been victim to this situation to understand the dynamics, and hopefully deflect it to a more productive place (or at least, more than likely, to some other unsuspecting victim).  If you're actually one of these people (and it's not likely you are, since you wouldn't take the time to read this), it will help you better communicate with someone who knows something you would like to know.

To help protect the guilty, I am going to choose a different topic from the one I was asked, but it won't be difficult to reconstruct the dialogue in a similar way.

To set-up the scenario:  I am having a casual conversation with someone I see about once a month, in a place where I will be be speaking one-on-one for about 15 to 30 minutes.  I am there because I am doing a favor for them.  Let's call this person V (for vacuum).

During the conversation, V asks me, out of the blue, "What can you tell me about microcontrollers?"

Now it happens I know a fair amount about microcontrollers.  Not everything, but I know my way around the block.  The problem is that there is no possible way I can answer this question.  So I reply, "That's a pretty big topic.  What do you need to know?"

V responds, "Well, I don't know a lot about microcontrollers, but we're using one at work and I have to know how to connect a LED to it and make it blink on and off."

In this short period of time I have now gotten several good pieces of information that I will likely ignore.  First is that V has been unwilling to do any basic research to find more information about the task they are being asked to do.  Second is that they are not at all competent with the topic at hand, since making a LED blink is a pretty basic operation that a microcontroller can do.  Finally, I am being asked to convey, in a casual setting, a piece of information that is more appropriate for a white board and maybe even a solderless breadboard for demonstration.  The conversation continues.

I ask, "What kind of microcontroller are you using?"  V says, "Well, they say it's like the one used in the Arduino, but I don't really know.  All I really need to know is how to get the LED connected to it and make the LED blink."

I ask, "Well, do you know the drive capability of the GPIO pin that will be used to control the LED?"  V responds, "I'm not sure I know what you mean."  "Well, for example, if the GPIO pin can only provide 2 milliamps of drive current and the LED needs around 15 milliamps, then you'll need a transistor or such to drive the LED," I respond.  V appears more confused, and asks, "How would I know if the LED needs more current than the GPO pin needs?" (note:  V says GPO instead of GPIO).

It is now clear that V not only does not understand much at all about microcontrollers, but V also doesn't really understand how devices are electrically interfaced to circuits in a digital system.

At this point, it is clear to me that this conversation will require more than the 15-20 minutes that I am going to have with V.  I respond, "Look, this is actually a pretty in-depth conversation.  Would you have some time later to talk about it?"  This is a polite way of saying, well, that it's going to take more than 15-20 minutes, and maybe you're needing a tutorial from somewhere.  V says, "Well, I don't really have time because I'm so busy doing work and caring for my sick father."

This is where the conversation has clearly crossed the boundary between showing someone how to do something and a knowledge vacuum situation.  With this said, here are some of the tell-tale behavior patterns associated with knowledge vacuums (and why it is bad):
  1. They know so little about the subject matter they're inquiring about that they don't know how to ask an intelligent question.  What isn't obvious is that they really don't want to know any more, either.  They just want enough to solve their problem so that they can declare themselves as subject matter experts.
  2. There is no desire to take the discussion from the casual realm into a teacher/student realm, generally due to some kind of emergency circumstance.  The person assumes that you are just trying to make the subject more complicated than it really is, and that you could just answer their question in the short time available and they would know what they need.
  3. There is no desire to read any material prior to the discussion, to become familiar with basic concepts.  This implies that your time is not important and that it is perfectly acceptable for you to do the reading and understanding of the subject at hand, and then process and regurgitate what you learned to others.  This is just rude.
  4. This person is not really interested in the subject, but rather is trying to get enough information to appear that they know more than they do to someone else.  It indirectly belittles the passion that you have for the subject.
So how would this situation work better?

V should have done some basic reading about microcontrollers.  Do a search on interfacing LEDs to microcontrollers, and look at Wikipedia pages about microcontrollers.  As V was reading the text, it would become clear that there were additional topics that needed investigation, and that process could be repeated recursively.

Don't begin the conversation with, "What do you know about microcontrollers?"  Begin with, "I'm trying to interface a LED to a microcontroller and am completely lost.  Where should I start looking to figure out what to do?"  While this is still a bit difficult to answer, it better sets the scope and tone of the conversation, and immediately jumps to the inevitable questions about drive current and GPIO pins.

If V was further confused, it would be appropriate to realize that they were over their head and say, "I think I need to look at this a bit more.  I will come back with more questions later, but now I have a place to start looking."  This indicates a willingness to do the work required to learn about the topic, and is respectful of the time of the person being asked.

FInally, if it is clear that the topic is too complicated for casual discussion, V should have accepted the invitation to discuss the topic further at a later time, and offered to buy dinner or provide reciprocal help in return.  This conveys an understanding that the time and knowledge of the person being asked is valuable.

Sometimes, while it may seem rude, the best response to this is to derail the conversation (as hard as it is when you're passionate about a topic) as soon as possible with, "I know you're busy but this topic is a bit too complicated for casual discussion.  I don't think I can help you."

I need to remember this next time it happens...  Ugh.

Wednesday, June 8, 2016

It's NOT My Fault

Imagine if someone you didn't know - or maybe that you did know - walked up to you and said, "It's because of your kind that I've been repressed all my life, and me and my kind are going to turn the tables and make you suffer for what you did."  How would you feel about that?  Unless you were truly some kind of psychopathic lunatic, it's not likely you were really responsible for this.  You'd say, "Huh?  It's not my fault!"

I reached the upper limits of my patience today when one of my facebook "friends" and an unrelated Atheist celebrity both made yet another declaration of oppression and atrocities against women perpetrated by the white, male patriarchy.  They didn't say it quite that way, but I like calling it as I read it.  I've had women declare these things in front of me, and then say, "Oh, but we know you're not like that."  Seriously?  You just blamed an entire gender of people for everything that ever went wrong in your life, and you expect me to feel better because you exempted me from that group?

It's past time for me to make my own rant.  Listen carefully.

I was born a white, male in the United States of America.  I don't oppress women.  I don't discriminate against people of other races.  Do I laugh at some of the stereotypical comments made, some even a bit off-color?  Sure.  Just like you holier-than-thou, politically-correct, social justice "warriors" take every opportunity to make fun of nerdy, geeky people whenever you get a chance.  There are times when I'm just a bit peeved at the comments tossed-about with an utter lack of consideration, but in most cases I interpret it for what it is - a joke at the expense of the stereotype.  No harm, no foul.  Humor can diffuse some very tense situations at times.

I was not born "privileged."  At least no more privileged than anyone else born in this country.  The only privilege I can say I have is that my parents, who didn't come from privilege either, gave a damn about me and raised me with a good set of core values and to be considerate of others.  I can't say I've been a perfect specimen of a person, but I do make an effort to uphold those values.  This is more than I can say for some people I encounter in my everyday life.

When women of the "new feminist" movement and the perpetrators of the "black lives matter" movement decide to round-up everyone of my gender and/or race and group us all into one class of people, saying that we have and continue to oppress, objectify, or harm them, I take great offense to that.  I didn't do anything to you.  In point of fact, generally speaking, I would tend to be (and have been) one of the first to stand-up against someone who would act in that manner.  The only thing you have accomplished by lumping me in with the people you don't like is to sour my otherwise positive attitude toward you and cause me to dismiss anything you stand for, even if it may be legitimate.

These activist groups take statistics, pervert them to support their point of view, and shove them down everyone's throat.  I agree that there was once a time when attitudes toward women and people of color were downright poor, but those attitudes have long since become socially disgraceful.  Yes, there are still instances of injustice and discrimination, but these are individual issues and should be addressed as such.  In no way is it a systemic problem, in spite of the perverted statistical results.

I get invitations from meetup.com constantly for technology-oriented meetups that are only open to women.  Obviously, not being one, I am not welcome.  If I were to make a men-only technology meetup, the poop would hit the proverbial fan.  I've never been at a technical meetup that was not welcoming of women.  I've never been in a grade-school or college computer class where women were not given the exact same opportunities to learn that I did.  The awkward nerdy introvert that I was, I would have been absolutely elated to meet a woman with whom I could share my enthusiasm for computers and electronics technology and who actually knew what I was talking about.  I actually would do so now, as well.  I haven't yet encountered a woman in my travels who has the same passion and competency  that I have about this stuff (that's not to say they're not out there, it's just our paths have not crosssed).  This is not because they didn't have the opportunity to get to that point, but because they're simply not that interested.  I can handle that.  But please don't say it was because I, or all the men in the world, told you that you couldn't do this, because it simply is not true.  That goes for anyone else who says they can't do this stuff.  If you have an aptitude for technology and are willing to learn, you can do it, even without a lot of money or so-called "privilege."

What I'm trying to say is that we truly are all people.  If you really are for equal opportunity and treating everyone with the same respect as the people of your same social, racial, political, economic, intelligence, sexual, or any other classification, then it starts by not being offensive or exclusionary in the same way yourself.  You know something:  ALL lives matter.  We should be just as appalled when a white cop kills a black kid as we do when anyone of any color kills someone else without reasonable justification, or is the perpetrator of any other form of violence.  People of all kinds should be paid according to the work they provide and the value they give the organization, no matter what their gender, skin color, sexual preference, or anything else.  Sometimes a humorous comment is just that, and doesn't imply some form of oppression.  If you think that bashing a whole gender or race of people you claim has oppressed you will bring anything other than conflict and bitterness between groups of people, then you are an ignorant and toxic person.  Your attitude and actions will not improve interpersonal relationships.  You have learned absolutely nothing from history.  You are the problem.  It's most definitely not my fault.

That is all I have to say.

Saturday, May 7, 2016

My New Moto X Pure Edition Is Slow

It seems that this blog isn't getting a whole lot of publicity lately, but I wanted to give back to the community and provide this info, because there are a lot of people frustrated by this apparently.

TL;DR:
Q:  "My new Moto X Pure Edition/Style web browsing is REALLY SLOW on Android 6.0 ("Marshmallow") and I have no idea why (particularly with Chrome).  What's wrong?"

A:  It is because you enabled full disk encryption (FDE).  The good news is that you can disable FDE.  The bad news is that the only way to do it is to do a factory reset of your device, which will wipe out your phone and you will be starting again from scratch.

More Information:
The reason why your browsing is slow is that the mobile web browsers cache pages to the storage on your smartphone.  For some reason, one that I have not been able to determine, the Moto X Pure Edition (MXPE) doesn't seem to have crypto acceleration or it is implemented poorly, so the cryptography needed to support FDE significantly slows down storage access.  This isn't apparent with most applications ("apps") because they don't do the same kind of storage access that a browser does.

There is only one way to accomplish the factory reset that will disable FDE on your MXPE  (Disclaimer: I take no responsibility for you losing your data or the use of your phone):
  1. Make sure that you have been backing-up your device to the Google.  If you haven't, you probably want to do that.  I thought I was, but I wasn't, and still can't figure out what I did wrong.  The place to look is Settings -> Accounts -> Google.  Since this didn't do anything for me, please assume after you do this reset all your settings, apps, and data will be gone.  They were for me.
  2. Back-up ALL the personal data you stored on the device to your personal computer.  I CANNOT STRESS THIS ENOUGH!  DO IT NOW!  Get your photos, videos, music, and all that stuff off the device.
  3. If you haven't backed-up and saved your personal information listed in #2, you're not listening to me, and you should do it right now, because you're about to lose all of it.  Seriously.
  4. I recommend that you disable any network access (WiFi or carrier Internet) from here forward.  This will prevent your phone from being able to contact Google and potentially sync an empty phone.
  5. Write down a list of all the apps you have installed and any settings you think you may forget later.   You will want to do this so you can install everything again later.
  6. If you have set-up your SD-Card to be additional internal storage, set it back to Personal Storage.
  7. Power off your phone and remove any SD-Cards or SIM cards in the phone.  This is to prevent any part of the factory reset from possibly affecting these.  It is probably not mandatory, but I like to be safe.
  8. Power-on the phone and go to Settings -> Backup & Reset and select "Factory data reset."
  9. Wait a while.  The phone should eventually reset and power-on as though you just received it from the factory.  Verify through Settings -> Security that under "Encryption" it says "Encrypt phone" (meaning that your phone is not encrypted).
At this point, you will want to try to get your Google account re-associated with your device and hopefully it will recover many of your settings.  Again, it didn't do this for me, but I could have done something wrong.

Do not encrypt your phone's storage again.  While this is a nice security feature, it makes the device virtually unusable.

After doing the factory data reset, the browsing using Chrome was very fast again, just like when I first got my  phone.  I came upon this after reading the testimonials from many confused people on the web who were having problems with their MXPE browsing being really slow and not knowing why.  I started thinking what I did that led to it being slow, and when I enabled encryption (FDE) was when it started.

Not using FDE is not generally going to put your data at risk. It's good for protecting your data from someone who has physical access to your device from being able to reset it and gain access to the data in the storage.  If you're really worried about someone getting access to your lost device, there are ways to remotely wipe the device if it is lost.  If you're worried about government access to your device, then the MXPE is probably not the right phone for you.

Hopefully this helps someone avoid the frustration that I and so many others seem to have been experiencing.

A note about SD-Card storage:
While you're wiping out your phone, you should probably think about your SD-Card storage with Android Marshmallow.  While it is possible to use the SD-Card as extra "internal storage," I don't recommend doing this.  Using the SD-Card as internal storage makes your entire device dependent upon keeping the SD-Card in the device.  If you remove it, you can end up with lost data or corrupted settings.  The only time it makes sense to use the SD-Card as internal storage is if you cheaped-out and ordered the 16 GB model and now are tight on space for apps and games.  If you're a typical user and have a 32 GB or 64 GB model, then you've got plenty of app/game storage.

Instead, format the SD-Card as "Portable storage."  This will still allow you to keep music, movies, and photos on your SD-Card.  You can take the SD-Card out of your phone and access it on your computer if you need to do that.  If the SD-Card goes bad for some reason, you won't start having problems with the rest of the phone (you'll just lose your media, which you should be backing-up anyway).

It seems like a good idea to extend your internal storage, but everything I've read online and experienced personally after trying it says not to do it.

Monday, January 18, 2016

C.H.I.P. Flashing under Gentoo Linux

Well, it's time to give some credit where credit is due -- the people at Next Thing Co. have been pretty responsive about the boot issues with the C.H.I.P. $9 computer.  They are actively looking into ways to make reflashing the device easier, and have given some updated instructions about how to do the reflash.

In the name of hoping to help someone rather than complain, I would like to give some instructions on how to reflash the C.H.I.P. under Gentoo Linux without the need to install the entire SDK.  This should also give those who are interested in some of the particulars of the flash process a starting point to how it all works.

Step 1:  RTFWP (Read The Fine Web Pages)

Next Thing Company (NTC) has two web pages that you should familiarize yourself with before going through this process.  Don't do anything just yet - just read over how the process works.  It will help to understand why this process is actually a bit easier.

http://docs.getchip.com/#flash-chip-firmware
https://bbs.nextthing.co/t/solution-for-c-h-i-ps-that-do-not-boot/1973

Step 2:  Choose a location to work - make a new subdirectory, and make that a nice clean workspace.  Get into that directory.

Step 3:  Get the sunxi-tools and compile them, as specified in the instructions.  Note that Gentoo has a masked version of sunxi-tools which may work (I didn't bother trying this, but it may work for you).  This was relatively simple:

(from your "working directory")
$ git clone https://github.com/linux-sunxi/sunxi-tools.git sunxi-tools
$ cd sunxi-tools ; make
$ for i in bootinfo fel fexc nand-part pio ; do ln -s sunxi-$i $i ; done


The last line is needed because the utilities are all prefixed by "sunxi-" but the C.H.I.P. flashing tools reference them unprefixed.

The sunxi-tools are utilities that are designed to speak to the Allwinner ARM-based SoC that is used in the C.H.I.P.  The "FEL" mode is, as I understand it, a diagnostic mode of the SoC that allows it to be manipulated in various ways outside of its normal operation (kind of like JTAG, but more powerful and less mysterious).

Step 4:  Get CHIP-tools -- These are the shell scripts that actually orchestrate the firmware flashing.  You'll want to look at these sometime as it provides some insight on the flash process.

(also from your "working directory")
$ git clone https://github.com/NextThingCo/CHIP-tools

You'll note that in the README.md file, the folks at NTC said all you'll need are the sunxi-tools and U-boot tools.  Well, as you'll see in the next step, that isn't entirely correct...

Step 5:  Install the Android tools and an extra thing...  The scripts that do the flashing need to put the binaries in the proper format and talk to the SoC in a way that I'm still not sure about.  Suffice to say that two utilities are needed in this process, and that's fastboot and img2simg.  The fastboot utility seems like a swiss-army knife for talking to Android devices, and apparently the C.H.I.P. as well.  The img2simg utility converts a boot image into a "sparse" image, in 2M chunks.  I'm not sure why this is done this way, but it's needed.

On Gentoo, you'll first want to create/edit a package.keywords file to permit the newer version of android-tools to be built (dev-util/android-tools-5.1.1_p13).  You'll have something like this:

=dev-util/android-tools-5.1.1_p13       ~amd64 ~x86 ~arm

Then emerge android-tools normally.

Unfortunately, the img2simg utility is not compiled in the Gentoo ebuild, so you'll need to do this by hand.  The easiest (not the most efficient) way to do this is:

# cd /usr/portage/dev-util/android-tools
# ebuild android-tools-5.1.1_p13 unpack
# cd /var/tmp/portage/dev-util/android-tools-5.1.1_p13/work/core/libsparse
# cc -I include -lz -o img2simg img2simg.c backed_block.c \
         output_file.c sparse.c sparse_crc32.c sparse_err.c sparse_read.c

You will end up with a nicely compiled img2simg utility, which I moved to the CHIP-tools working directory because it will be in the path in a moment...  Remove the /var/tmp/portage/dev-util/android-tools tree when you're done (it just consumes unnecessary space).

Step 6:  Install u-boot-tools.  These are used to format some of the boot images into the proper format for flashing, since the C.H.I.P. uses U-Boot as its bootloader.  Again, since we'd like to use a newer version of U-Boot tools than Gentoo has agreed is stable, we'll add this to a package.keywords file:

=dev-embedded/u-boot-tools-2015.04     ~amd64 ~x86 ~arm

Then emerge u-boot-tools normally...

Important note:   If you're planning on doing the flashing as an unprivileged (non-root) user, you'll want to add that user to the usb group in /etc/group (and that user will need to do a fresh login for it to take effect) so that the user can access raw USB devices.  Doing this as an unprivileged user isn't a bad idea - especially since you'll be running shell scripts you're probably not too familiar with.  If you are comfortable doing this as root, then you won't need to add that user to to the usb group.

Step 7:  Let's get ready to flash the board.  Become the user you wish to do all the flashing as, and get to your CHIP-tools directory.  Then make sure that the sunxi-tools and current directory are in your PATH:

$ cd CHIP-tools
$ export PATH=".:../sunxi-tools:$PATH"

Then prepare the board for flashing.  Connect GND (pin 39) to FEL (pin 7) on connector U14 (this is one of the two large DIL connectors on the board).  This can be done with a small piece of 24 gauge solid wire, although using a proper solderless breadboard-style jumper would be better.  This jumper places the SoC into FEL mode, and allows all the sunxi-utilities to do their magic.

Then connect the C.H.I.P. to your computer using a micro-USB to standard USB ("USB-B") cable.  The C.H.I.P. will power-on (and be powered by your computer).

Step 8:  Flash the board with the new firmware and fresh copy of Linux

$ ./chip-update-firmware.sh -d -b stable-gui -f

VERY IMPORTANT NOTE:  This will completely wipe-out whatever you had on your CHIP.

The NTC documentation in the web pages referenced above explains the other flashing options that are available.  These may be handy to know if you want to put a different OS onto the C.H.I.P. or use it in text-only mode.  I'm actually thinking of installing Gentoo Linux on the thing at some point, because I loathe systemd (as I said in my previous rant).

If you follow the above procedure, you will see a dialog similar to the following (similar because the scripts already downloaded the firmware during a previous, unsuccessful, run):

$ ./chip-update-firmware.sh -d -b stable-gui -f
waiting for fel..........OK
debian selected
BRANCH = stable-gui
fastboot enabled
ROOTFS_URL=http://opensource.nextthing.co.s3.amazonaws.com/chip/debian/stable-gui/3
BUILD=3
BR_URL=http://opensource.nextthing.co/chip/buildroot/stable/73/images
BR_BUILD=73
/mnt/ed1/CHIP-FLASH/CHIP-tools/.firmware/images/rootfs.ubi exists... comparing to http://opensource.nextthing.co.s3.amazonaws.com/chip/debian/stable-gui/3/rootfs.ubi
MD5: 201a36e60168e2db514b220024b10cd3
S3_MD5: 201a36e60168e2db514b220024b10cd3
file already downloaded
/mnt/ed1/CHIP-FLASH/CHIP-tools/.firmware/images/sun5i-r8-chip.dtb exists... comparing to http://opensource.nextthing.co/chip/buildroot/stable/73/images/sun5i-r8-chip.dtb
MD5: 09707eb7aa4709365cc14aa0314e4716
S3_MD5: 09707eb7aa4709365cc14aa0314e4716
file already downloaded
/mnt/ed1/CHIP-FLASH/CHIP-tools/.firmware/images/sunxi-spl.bin exists... comparing to http://opensource.nextthing.co/chip/buildroot/stable/73/images/sunxi-spl.bin
MD5: 1dd925fa15a21bc60dd2172fe3ac40ad
S3_MD5: 1dd925fa15a21bc60dd2172fe3ac40ad
file already downloaded
/mnt/ed1/CHIP-FLASH/CHIP-tools/.firmware/images/sunxi-spl-with-ecc.bin exists... comparing to http://opensource.nextthing.co/chip/buildroot/stable/73/images/sunxi-spl-with-ecc.bin
MD5: f96fc379e59673e23b3fc1b99a89f569
S3_MD5: f96fc379e59673e23b3fc1b99a89f569
file already downloaded
/mnt/ed1/CHIP-FLASH/CHIP-tools/.firmware/images/uboot-env.bin exists... comparing to http://opensource.nextthing.co/chip/buildroot/stable/73/images/uboot-env.bin
MD5: 6f2b79a781f9f490911012ec3aa653e9
S3_MD5: 6f2b79a781f9f490911012ec3aa653e9
file already downloaded
/mnt/ed1/CHIP-FLASH/CHIP-tools/.firmware/images/zImage exists... comparing to http://opensource.nextthing.co/chip/buildroot/stable/73/images/zImage
MD5: 91614d8d67bd87987ea5bc958e61cfc3
S3_MD5: 91614d8d67bd87987ea5bc958e61cfc3
file already downloaded
/mnt/ed1/CHIP-FLASH/CHIP-tools/.firmware/images/u-boot-dtb.bin exists... comparing to http://opensource.nextthing.co/chip/buildroot/stable/73/images/u-boot-dtb.bin
MD5: a9051ff21d462ecc66d7ee9ded2ebe0a
S3_MD5: a9051ff21d462ecc66d7ee9ded2ebe0a
file already downloaded
fastboot enabled
BUILDROOT_OUTPUT_DIR = /mnt/ed1/CHIP-FLASH/CHIP-tools/.firmware
== preparing images ==
PADDED_SPL_SIZE=0x000000c4
0+1 records in
1+0 records out
4194304 bytes (4.2 MB) copied, 0.00341595 s, 1.2 GB/s
UBOOT_SIZE=0x00400000
PADDED_UBOOT_SIZE=0x400000
0+0 records in
0+0 records out
0 bytes (0 B) copied, 4.2427e-05 s, 0.0 kB/s
echo Configuring Video Mode
Image Name:   flash CHIP
Created:      Mon Jan 18 18:25:40 2016
Image Type:   ARM Linux Script (uncompressed)
Data Size:    1012 Bytes = 0.99 kB = 0.00 MB
Load Address: 00000000
Entry Point:  00000000
Contents:
   Image 0: 1004 Bytes = 0.98 kB = 0.00 MB
== upload the SPL to SRAM and execute it ==
waiting for fel...OK
== upload spl ==
== upload u-boot ==
== upload u-boot script ==
== execute the main u-boot binary ==
== creating sparse image ==
== waiting for fastboot ==
waiting for fastboot.................OK
target reported max download size of 33554432 bytes
sending sparse 'UBI' (30720 KB)...
OKAY [  2.668s]
writing 'UBI'...
OKAY [  2.034s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.632s]
writing 'UBI'...
OKAY [  8.398s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.609s]
writing 'UBI'...
OKAY [  8.398s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.651s]
writing 'UBI'...
OKAY [  8.396s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.596s]
writing 'UBI'...
OKAY [  8.397s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.605s]
writing 'UBI'...
OKAY [  8.395s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.642s]
writing 'UBI'...
OKAY [  8.398s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.652s]
writing 'UBI'...
OKAY [  8.397s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.732s]
writing 'UBI'...
OKAY [  8.398s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.768s]
writing 'UBI'...
OKAY [  8.402s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.804s]
writing 'UBI'...
OKAY [  8.394s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.615s]
writing 'UBI'...
OKAY [  8.395s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.689s]
writing 'UBI'...
OKAY [  8.394s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.635s]
writing 'UBI'...
OKAY [  8.395s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.652s]
writing 'UBI'...
OKAY [  8.391s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.658s]
writing 'UBI'...
OKAY [  8.395s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.681s]
writing 'UBI'...
OKAY [  8.394s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.670s]
writing 'UBI'...
OKAY [  8.394s]
sending sparse 'UBI' (30720 KB)...
OKAY [  2.712s]
writing 'UBI'...
OKAY [  8.398s]
sending sparse 'UBI' (28672 KB)...
OKAY [  2.505s]
writing 'UBI'...
OKAY [  6.671s]
finished. total time: 213.024s
resuming boot...
OKAY [  0.000s]
finished. total time: 0.000s

Step 9:  Once this is complete, you can unplug the C.H.I.P. from your computer, remove the FEL jumper from the connector, and boot the C.H.I.P. normally.  You should see an updated version of Linux as well as a nicely functioning board.

After this procedure, I rebooted the device several times, and it had no more problems booting (as it did previously).  I have not tried to actually do anything with it yet, since I had other things I needed to do this evening.  I expect, though, that I'll be pretty much back to where I was when I first got the device.

Now that I've gotten past this hurdle, I'm hoping to try doing "computer things" with the C.H.I.P., and maybe even some geeky stuff connected up to the thing.  It looks like it could be a nice device, but given how fragile the flash memory is on the unit so far, I'm a bit gun-shy about doing too much tinkering with the OS yet...

Hopefully, this will help someone get through the reflashing process - especially those who are familiar with Linux or who are using Gentoo Linux, and don't want to install a whole VM and development environment.