Brad For Dem Bedded

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Thursday, 29 December 2011

NameCheap and SOPA

Posted on 05:01 by Unknown
I'm now a fan (and customer) of NameCheap (that's an affiliate link, if you're interested in supporting Bradford Embedded).

NameCheap is running a special today on any domain transfers. Use the coupon code "SOPAsucks" (without the quotes) and transfers are only $6.99, plus NameCheap will donate $1 to the EFF for every transfer! Transfers include 1 year of renewal.

The target appears to be GoDaddy, who were supporting SOPA. I dislike GoDaddy (hence, no link) as well, but I had that opinion long before SOPA came about. NameCheap has been a fairly popular topic over on HN recently. That's where I heard about them. If you use the coupon code and my affiliate link, I don't get any money but that's OK (I encourage you to use the coupon! SOPA does suck, and supporting the EFF is way more important than supporting me).

NameCheap's also running a special where if you register a new domain (in at least .com and .net, and possibly others), you get the .org domain registration for free. No coupons required. The affiliate link should still pay me if you use this deal, and you won't pay a higher price because of it.

I've transferred my domains to NameCheap from Dyn. I liked Dyn, I have nothing against them, but NameCheap lives up to their name, they're cheaper, and I like supporting the EFF and companies who take stands.

A short while ago, I removed ads from my blog. I'm still against ads, even though this post may sound like one. It is, but only because I'm a very happy customer, wanted to share my experience, and if it can net me a few bucks, all the better. I'm also in a transparent mood today ;)
Read More
Posted in internet, SOPA | No comments

Tuesday, 27 December 2011

Set The World On Fire

Posted on 10:49 by Unknown
I like FAKEGRIMLOCK. You should get in on the KickStarter. I also like Seth Godin.

Put the two together:

If you want to set the world on fire, first, you must burn!
If you're not setting the world on fire, your house is burning. Do something about it, NOW!

I like these analogies for business.
Read More
Posted in business, work | No comments

BeagleBone Debian Squeeze armel Multistrap Config

Posted on 04:02 by Unknown
For those interested, here's my current Debian Squeeze armel multistrap configuration file that I'm using to build a Debian file system for my BeagleBones:



It's going to be a little rails server :)

EDIT: You'll probably want to use the backports version of multistrap if you want to verify package signatures and you have fakeroot installed. There's no support for this in the standard Squeeze multistrap version.
Read More
Posted in beagleboard, debian, embedded, linux, rails | No comments

BeagleBone Boot Time

Posted on 03:58 by Unknown
Apparently a lot of people want to know things about BeagleBone boot time...
Let me know if this is covering it or if you'd like more info. Most of my work is with CLFS and Debian.

I'm seeing about 8.5 seconds from kernel start to login prompt with a rather pared down Debian Sqeueze armel configuration and Linux 3.1. Add about two seconds for SPL, u-boot, and kernel decompression. Then add on the boot delay countdown (3 seconds in my case). That gets us to about 13.5 seconds to boot.

Let's be conservative and say 15 seconds. Completely respectable. Not a 1 second boot, but that's not my goal, anything under a minute is pretty good in my book.

To give you a sense of what I'm starting at boot time for services, here's some output:

Read More
Posted in beagleboard, debian, embedded, linux | No comments

Monday, 19 December 2011

BeagleBone Booting Debian Squeeze!

Posted on 07:39 by Unknown
I've got my BeagleBone booting Debian 6 Squeeze!
(The real Squeeze, not Emdebian)

I've used the u-boot and kernel sources (with only a few tiny modifications from the am335x_evm_defconfig) from the Arago project git repos. I'm using multistrap and qemu-static to build and configure Debian on my amd64 host, then copying over the files to the microSD card.

I'll be sure to post more info on steps in the near future. The partitioning and formatting of the microSD card is the first step.

Click through the jump to see output in a Gist.



Read More
Posted in beagleboard, debian, embedded, linux | No comments

Wednesday, 14 December 2011

Format an SD Card with 8 MiB Aligned Partitions

Posted on 08:34 by Unknown
SD cards generally have 2, 4, or 8 MiB (MiB = 1024 * 1024 bytes) erase blocks and 8 KiB write pages. Because of this, your partitions on an SD card should be aligned so that they begin and end at the edges of the erase blocks. This, of course, assumes the SD card isn't doing address translation and sticking data where ever it wants (which the low priced ones probably aren't, the high priced ones might be). So take this with a grain of salt :)

If you want to create a microSD card for use with the BeagleBone that uses partitions aligned to 8MiB bounds, you can use the below script. It's adapted from the eLinux.org Panda U-Boot instructions. It assumes you are using a microSD card that shows up as an mmc device where partitions are named /dev/mmcblk0p1 (and not a SCSI device, like some USB based SD readers do, where partitions are named /dev/sdb1). You'll destroy all data on the microSD card and you'll end up with a 64MiB FAT partition and the rest of the device as an ext3 partition.



Copy your MLO and u-boot.img onto the FAT partition and boot it up! The BeagleBone will boot this partition mapping, even though its different from TI's recommendations. I'm using the SPL and u-boot from the Arago repo.

I'd like to build in support for determining the partition type (mmc versus SCSI) automatically, but that's not done yet. My HP 8560w has a built in SD card reader that shows up as an mmc device.
Read More
Posted in beagleboard, embedded, flash | No comments

Thursday, 8 December 2011

ROC The Day!

Posted on 03:36 by Unknown
If you live near Rochester, NY, or if you know someone who does, please take a few minutes to visit ROCtheday.org and donate to one of our local not for profits. This is a one day (today!) only fundraising event for a huge number of Rochester groups.
Read More
Posted in community | No comments

Wednesday, 7 December 2011

SanDisk iNAND

Posted on 11:07 by Unknown
I stumbled upon SanDisk's iNAND products today while doing some searching about SD cards. The iNAND idea looks very appealing to me compared to raw flash from a board design perspective. Since iNAND looks just like a MMC device, you can hook up to it with a 4 or 8 bit data bus and your total useful pin count can stay around 11 pins, not counting power, ground, and decoupling caps for internally derived voltages. In terms of keeping pin count down, that's awesome!

Then, looking what appears to have been a leaked preliminary data sheet for an older version of the current iNAND devices, the speed is pretty good, and internally there's 512 byte pages, wear leveling, TRIM support, and a host of other features required in demanding storage applications (like industrial or smart phones).

I assume the controller internals are very similar to those found in SanDisk's high end SD cards, and so using iNAND may not give much of a performance difference. But in some cases, a removable SD card is a liability and soldered down memory would be preferred, such as if people might steal it or in environments with high vibration.

The only drawback I see is with the lack of removability. Either SanDisk needs to program your desired initial data into the iNAND at time of purchase, or you need a fixture to interface the iNAND on your own manufacturing line and engineering work bench. Not a big deal if you have the resources and design the board it mounts to correctly. And then if you create a situation where the board is unbootable (I'm looking at you, in the field software upgrades), you'll need either the fixture or a JTAG device, just like raw flash.

I don't know the costs associated with each iNAND family but I do have a request into SanDisk sales to get more info and data sheets. Not sure I'll be able to share that data, but if I am, I will.

UPDATE 20111208 1:45pm - After more research, the iNAND family of devices are a type of eMMC device. Basically it's MMC but in a soldered down package, usually BGA. Another handy bit is when developing hardware that will eventually use eMMC, you can lay down the footprint for both the eMMC device and a normal microSD card connector and only populate the one you wish to use (eMMC in production, microSD in development).
Read More
Posted in embedded | No comments

Friday, 2 December 2011

BeagleBone Hardware Desire - USB & FTDI Power Independence

Posted on 04:10 by Unknown
Now that I've got my BeagleBone, I'm still not happy :)

I'd like to be able to plug the USB cable into my host PC but not have the board power up. Since the USB cable is now also the serial cable, I'd like to have a few seconds after plugging the USB cable to get my serial port terminal up and running so I can watch the x-loader and u-boot data from a cold boot. Based on my read through the schematics, this isn't possible by just removing a resistor or a simple hack. I could probably cut some traces and solder up some jumpers, but it will look messy and I'm not sure it's worth the time, yet.

It would be nice to have the option of the micro USB connector's power only going to the USB hub and FTDI chip. That way, when USB is plugged to the host PC, the serial port can be set up before the ARM core boots. Then when DC power is applied to the 5V input, the ARM core and all other circuits would be powered and boot would occur. This would be behavior similar to how the BeagleBoard and BeagleBoard-xM work with their "real" serial ports. I could connect my serial term before boot.

I realize I can just push the rest button to get a glimpse of the x-loader and u-boot messages, but that's not what I want. The things I'm going to be building on my BeagleBone will have a rather quick boot (although nothing like the 1 second stuff) and while doing development, I'd like to be able to see the messages scroll. It's also not always a good idea to hit the hard reset button once Linux has mounted the file systems and started services (ext3/4 have journaling but it's still not a good thing to do often).

I'm not sure of the official procedure for requesting hardware changes for the BeagleBoards, but I'll probably stop by the Google Group and post this request there, as well.

EDIT 20111208 6:40am: I sent in a message to the BeagleBoard Google Group yesterday describing this.
Read More
Posted in beagleboard, embedded | No comments

Thursday, 1 December 2011

BeagleBones Arrived!

Posted on 10:26 by Unknown
2 BeagleBones were delivered by the friendly people at FedEx this morning!

I've got one of them booted up with the provided microSD card that came already inserted into the Bone. Oddly, there's another microSD card that was included in a separate packaging inside the BeagleBone box. I'm not yet sure what the difference is or why 2 were included, but both Bones came this way.

FedEx also delivered a pair of new SanDisk Mobile Ultra 8GB microSD cards this morning. I've run flashbench on them and mailed in my results. These look like pretty nice cards for Linux given my understanding.

Next up is building x-loader, u-boot, a kernel, and an Emdebian image for a Bone.

EDIT 20111201 4:30pm: On my machine, the FTDI serial port driver wasn't working without some help and being that I'm an engineer, I didn't read the directions :)
There's good info on making sure your virtual serial port is working on the BeagleBone info page.
Read More
Posted in beagleboard, embedded, linux | No comments

Wednesday, 30 November 2011

Dithering, NVIDIA Quadro 1000M, and HP ZR2440w

Posted on 05:28 by Unknown
My new laptop is an HP Elitebook Workstation 8560w. It's sweet and well supported by Debian 6. I also have a HP ZR2440w monitor, also sweet.

For some reason, with the NVIDIA proprietary drivers, version 290.10 with a 2.6.38 backports kernel on Debian Squeeze, when ever I have the monitor connected via DisplayPort, the NVIDIA driver turns on dithering for the external display. This is not what I want.

The HP ZR2440w is an 8 bit monitor, it doesn't need dithering, and with dithering enabled some colors flicker which is very annoying. The built in LCD on the Elitebook is only 6 bits and so dithering can help make it look like there's a wider color gamut.

To disable dithering on my ZR2440w but keep it enabled on the built-in LCD, my "Screen" section of my /etc/X11/xorg.conf looks like this (DFP-0 is the internal LCD, DFP-6 is the ZR2440w, and I have them mirrored so I only use the ZR2440w when it's connected):



With this config, now my ZR2440w is always non-dithered while the internal LCD always is dithered.
Read More
Posted in debian, linux | No comments

Saturday, 26 November 2011

Google AdWords - Gone

Posted on 07:38 by Unknown
I've removed Google AdWords from my blog and RSS feed. So not worth it to have ads. I've not yet made enough in ad impressions to get paid by Google and I've had ads up for almost 6 months.

For those of you using AdBlock, you shouldn't notice any difference. And yes, there were quite a few visitors blocking ads. For those of you not using AdBlock, the blog should load a little faster and there won't be any more ads.

Enjoy!
Read More
Posted in google | No comments

Google's New Look - It Sucks

Posted on 07:32 by Unknown
I'm not a fan of Google's new look for GMail or Blogger. I use GMail on a daily basis, many times per day. I use Blogger enough, almost daily, to at least check if any new comments came up on this blog or to write up some draft ideas rumbling around in my head.

Both GMail and Blogger complain now when I log in using Firefox / Iceweasel 3.5, which is what ships with Debian Squeeze. They tell me my browser is out of date and that my experience won't work well. This is for a browser that's not that old and is still supported with security updates from Debian. GMail also reverts to the old school plain HTML version which isn't pretty and for some reason keyboard shortcuts and priority inbox are disabled (very annoyed at that).

I'm taking my email to IMAP, goodbye GMail web interface, and I've rolled back Blogger's new look to the older version. If I'm on someone else's computer or using my wife's iPhone, I'll deal with GMail's web access. The worst part of this is before the new GMail and Blogger interfaces went live, neither complained about using Firefox / Iceweasel 3.5 and everything worked as I liked.

I'm seriously considering taking my email business elsewhere, possibly to FastMail where I can avoid ads and get my own domain for a very reasonable price. For blogging, in the past I had tried Tumblr but wasn't impressed. I'm going to take a serious look at Posterous. I do all my blog editing in the HTML mode on Blogger anyway, losing some editing features isn't a concern.

I'd love to say goodbye to Google. It's looking like it will be easier every day. I don't think that's a good thing.

PS: Google AdWords, not worth it. So far, with thousands of ad impressions on my blog, I've make a nice $2.50 over 6 months. Not even enough that Google will pay me (gotta hit $10 for that). Don't blog for the money, blog for the reputation, skills, to help others, and because you want to improve your writing. Future post on that ;)
Read More
Posted in computers, google, web 2.0, work | No comments

Wednesday, 23 November 2011

Debian 6 amd64 on HP Elitebook Workstation 8560w

Posted on 14:15 by Unknown
I got my new laptop this week, it's a spiffy HP Elitebook Workstation 8560w. Dual core i7 at 2.7 GHz, 8 GB ram, SSD, NVIDIA Quadro 1000M, all good stuff.

I've installed Debian Squeeze and found that I needed to do a few tweaks beyond what I expected in order to get the graphics and wifi working. First, get the wifi working, then deal with graphics.

You'll need to enable squeeze-backports. Follow the directions. Install the linux-kernel-2.6.38, linux-headers-2.6.38, and firmware-iwlwifi packages. Then modify your /etc/default/grub file, the 7th line should look like this:

GRUB_CMDLINE_LINUX_DEFAULT="nouveau.modeset=0 quiet"

Run update-grub2 to make the change permanent.

Now you can reboot and you should be running the 2.6.38 kernel. If you don't pass the nouveau.modeset line to your kernel when booting, it will hang. Mine likes to hang just after "hp_accel: driver loaded" which isn't very helpful.

Now, go grab the NVIDIA drivers from nvidia.com. Make sure you have gcc-4.4 installed. Go to a terminal with cmd-alt-F1 and log in as root. "killall gdm3" to shutdown X. Now run the NVIDIA installer.

Whamo! After another reboot you should be up and running with both wifi and graphics!
Sadly, with the stock kernel, the webcam worked awesomely. With 2.6.38, it's broken. If I determine the root cause I'll update.

UPDATE 20111123 5:30pm: To get webcam working again, don't use Camorama. Use something like cheese. Camorama wants the camera to be located at /dev/video0, it's not there any more. Things like Skype and cheese find the webcam with no issue. I'm happy! :)

UPDATE 20111126 10:00am: In order to get suspend working again with kernels newer than 2.6.35, you may need to blacklist a few modules, namely "firewire_ohci" and "firewire_core". Put the below in a file named /etc/modprobe.d/8560w-blacklist.conf, run and give the laptop a reboot. I've included here the pcspkr module as well to make that stupid beep go away ;) Now I have (I believe) all the hardware working on my 8560w except Firewire (I don't have any Firewire devices so I'm not that upset). Thanks go out to an Ubuntu bug report, scroll down to #50.



UPDATE 20111129 3:00pm: If you'd like ExpressCard hot plugging to work, you need to add "pciehp" to your /etc/modules and "options pciehp pciehp_force=1" to a new file called /etc/modprobe.d/pciehp. Both those are to be added without the quotes. Hat tip to Mark Lord on the LKML, part 1 and part 2.

UPDATE 20111208 7:00am: I'm going to recommend against encrypted LVM on an SSD with Debian Squeeze. The SSD in my 8560w says it supports TRIM but I'm having a hard time verifying that it's working, either automatically or manually. I have "discard" in my fstab and the 2.6.38 kernel supports it.
I'm thinking the way to go about encrypting important info is to just encrypt the directories I care about rather than the whole file system. I might do a backup, reformat, and restore, then enable just directory level encryption where needed (for example, I don't really care if my /usr directory is encrypted since it just has Debian sourced programs installed).
Read More
Posted in debian, linux | No comments

Monday, 21 November 2011

Embedded Linux Long Term - Part 3

Posted on 04:24 by Unknown
I wrote about long term support for embedded Linux before, a few times, but I'm back for more!

Recently in LWN, there have was another article about various embedded groups, like Linaro and LTSI, maintaining an official policy on long term support kernels. That's cool and all, if you're developing consumer electronics that will get replaced in 2 years (like cell phones in the US), but it's not that helpful for embedded industrial systems that will have lifetimes measured in decades. Especially industrial systems where the customer is scared to death of software upgrades because they've been burned before by past providers that assured them, "Nothing will go wrong." (It did)

Upgrading a kernel at one of these customers' sites will not happen. Security updates for the same kernel version, maybe. Beyond that, NO WAY!

So how does the embedded developer deal with this?

The best way I've thought up so far is to ride coat-tails for as long as possible and do extensive testing when absolutely forced to move to a new kernel version. That means grabbing sources from something like Red Hat or Ubuntu LTS at the beginning of a long term support cycle and riding that as far as it will go (usually 5 years). For example, Ubuntu 12.04 LTS is most likely going to have Linux 3.2 as the kernel for both the desktop and server versions. If your embedded system is supported by 3.2 (most established, non-cutting edge designs will be), grab that and let the Canonical team deal with the security updates for you. Be a good community supporter and send anything you can up-stream but otherwise just ride their coat-tail.

Another thing to keep in mind is your distribution. Although most embedded developers already keep installed packages to a minimum, you'll want to take this as far as you can. Once who ever's coat-tails you're riding for all your software, other than the kernel, goes end-of-life (i.e.: no more security updates for free), you've got two choices: 1) Ask your customer to upgrade (probably not going to happen), or 2) Backport security fixes yourself. Neither is much fun. Minimize this!

Don't pick something targeted towards mobile phones. Historically, everyone making mobile phones (ironically, except Apple) sucks at providing software updates beyond a year or two. The embedded Linux teams working to provide systems to compete with Android aren't much better. You're going to get stuck taking a server distribution and making it work on your embedded system (becoming less of an issue but still not as straight forward as something like OpenEmbedded).

Or you can pay... But that's no fun and you'll still deal with these issues down the road in about the same time frames.

It'd be cool to see a long term support version of Emdebian. Emdebian already has way less packages than real Debian so it's less daunting to apply security fixes. Debian has fairly long release cycles and is community driven. Lenny's already been around for a while and will be supported at least 1 year beyond Wheezy's release. Having a community support project to keep Squeeze and beyond supported for 5+ years would be cool...
Read More
Posted in community, debian, embedded, linux | No comments

Wednesday, 16 November 2011

Build the PandaBoard or BeagleBoard-xM x-loader on Debian Squeeze

Posted on 06:54 by Unknown
EDIT 20111116 15:37: This post and the git repo have been updated to include info on the BeagleBoard-xM.

I wrote up some quick instructions on building the PandaBoard and BeagleBoard-xM x-loader on a Debian Squeeze host this morning. You can find them below, but also in my GitHub x-loader repo. My x-loader repo is only slightly modified from mainline. Enjoy!


To build x-loader on Debian:

Install the emdebian-archive-keyring:
$ sudo aptitude install emdebian-archive-keyring

Add to your apt sources:
deb http://www.emdebian.org/debian/ squeeze main

Perform an aptitude update:
$ sudo aptitude update

Install the Emdebian cross compilers:
$ sudo aptitude install gcc-4.4-arm-linux-gnueabi g++-4.4-arm-linux-gnueabi

Install git and partitioning tools:
$ sudo aptitude install git parted

Clone the repo from github, this will create a directory called "x-loader":
$ git clone git://github.com/bradfa/x-loader.git

Enter the directory, make the configuration you desire, then compile the MLO
file (actual x-loader). For the PandaBoard use "omap4430panda_config" and
for BeagleBoard-xM use "omap3530beagle_config" in the second step
(example uses Panda):
$ cd x-loader
$ make CROSS_COMPILE=arm-linux-gnueabi- distclean
$ make CROSS_COMPILE=arm-linux-gnueabi- omap4430panda_config
$ make CROSS_COMPILE=arm-linux-gnueabi-

Now we'll partition and format an SDcard.

***************************************
* THIS PROCESS WILL DESTROY ALL DATA! *
***************************************

Make sure your SDcard is not mounted. Then run the partitioning script to
create a 64 MB FAT partition followed by an ext3 partition taking up the rest
of the SDcard space (SDcards are slow, this may take some time). The arugment
passed to the script is the device node of the SDcard itself (/dev/sdb in our
example), not a partition!:
$ sudo ./format_sd.sh /dev/sdb

Some systems may automatically mount the newly created file systems. If not,
mount the boot file system:
$ sudo mkdir -v /mnt/boot
$ sudo mount /dev/sdb1 /mnt/boot

The _VERY_FIRST_ file written to the FAT partition should be the MLO.
$ sudo cp -v MLO /mnt/boot/

Unmount the FAT partition and boot the board to verify operation!
Read More
Posted in embedded, git, linux, open source, pandaboard | No comments

Saturday, 12 November 2011

The BeagleBone!

Posted on 06:09 by Unknown
Somehow I missed the introduction of the BeagleBone! I don't know how that could be!

The BeagleBone looks like a really exciting little ARM board. It's a single core 720 MHz Cortex-A8 with 256 MB of RAM, gigabit Ethernet MAC built into the SoC with 10/100 PHY external, some very nifty USB on-the-go capabilities, and headers for expansion similar to Arduino (but not pin compatible). All for $89!

Hopefully the BeagleBone will be available for purchase later this month or, at the latest, early in December.

TI seems to be targeting a very wide audience with the BeagleBone this time. The expansion connectors pit it against some higher end applications for hobbyists where an Arduino may not have had enough power but where the expansion provided by Arduino is really handy.

The AM335x ARM SoC, however, throws the BeagleBone right up the alley of quite a few companies who are producing single board computers for various markets. The AM335x was also announced just over a week ago and TI already has high quality datasheets and reference manuals up online for free. [Side note, TI, you're awesome about this! Thanks!] The AM335x also has a reasonable 0.8mm ball pitch BGA package and is fairly low in pin count (around 300 pins depending on version). This makes designing systems with the SoC very easy for those with access to professional level schematic and layout tools (and even doable for those using Eagle, GEDA, or KiCad!).

I should be receiving at least one BeagleBone in the not-too-distant future. It's an exciting time!
Read More
Posted in beagleboard, community, embedded, linux | No comments

Thursday, 3 November 2011

Bootstrapping Fedora for ARMv7 Hard Float

Posted on 11:55 by Unknown
There's a great set of articles (part 1, part 2) from LWN discussing some of the processes and issues that were used / encountered when attempting to bootstrap a build environment for ARMv7-a hard float. Turns out, Fedora didn't really have a good set of infrastructure to do this and a lot of creativity was involved (including a 4.6GB git repo).

After a bit of reading, even Debian doesn't have a great set of infrastructure for bootstrapping onto a new architecture or ABI, although the Emdebian team is working on it.

This is awesome to see from both the Fedora and Debian teams. As much as Cross Linux From Scratch is a neat exercise, having the ability to bootstrap a "real" Linux distribution is very handy. Being able to base an embedded system on a well supported community distribution that can be customized through a well documented bootstrap process is an awesome thing. I'm looking forward to learning more about these methods.
Read More
Posted in debian, embedded, fedora, linux, open source | No comments

Calendar Interface

Posted on 05:30 by Unknown
Scott Adams recently wrote about calendar interfaces. Short version: Outlook and Google Calendar suck, they're too complex and require you to change your mental reference too many times when setting up an appointment. I got about half way though and lost interest in the article. Even his idea is too complex.

When I type something, anything, into Google, it corrects my spelling, recommends choices, and interprets my shorthand into useful search results. It does this across things like maps, email, web, patents, etc. I can help Google out by giving hints, like going to the maps interface when I'm looking for a location but even if I don't, often Google knows that's what I really want when searching for a business or address and the maps results come up first.

Why can't I just select the day for an appointment and type in "Doctor's appointment at 3pm." The calendar will parse that, pull out the time, and make the appointment in my calendar. If I've got my doctor's office in my address book, the calendar will even link that data along with doing a map lookup on my doctor's office phone number to find the location. The calendar can even ask me, after I enter this, if it got the choices right for location and other info with a listing like a Google search. Then, most likely, I'll just pick the first result (since it will be correct) and that confirms the calendar event and sticks it in my calendar. Done!

No, I can't write code to do this (not yet at least), but the infrastructure already in existence in Google's searching products, when combined, can almost do exactly this!

So, Google, why is your calendar interface so complex?
Read More
Posted in software, web 2.0 | No comments

Thursday, 27 October 2011

New Beginnings

Posted on 13:26 by Unknown
I attended a retirement lunch today for a former coworker. Previously in my life I've attended a reasonable number of similar events, either people retiring or people leaving for other opportunities. Sometimes the people leaving get emotional and I had a hard time understanding why. I always thought, "It's just a job." Today, it's hitting me as to why.

Friday November 4, 2011 will be my last day at my current job. The following Monday I'll be starting at a much smaller company with huge aspirations to do amazing things for their customers. I'll be building embedded Linux systems and developing the software that runs on them. It's going to be an awesome challenge. I'm very excited.

I spent most of today organizing my notes and cleaning out my office. Over the next week, I'll be transferring my notes, responsibilities, and everything I've worked on to the rest of my group. Looking at things I've done, it's astounding. I've gotten a lot accomplished. I didn't realize how much work I've actually done in the past six and a half years and three different roles within the company. The amount of time, effort, and personal investment I've put in astounds me. Others feel the same way when they leave a company, that's what drives the emotions.

Looking at my resume, sure, I've done a lot. But when I found a directory full of minutes from meetings I ran 5 years ago and I can remember the details surrounding decisions that were made, problems that were solved, and bureaucracy that was dealt with, it's way more impressive. I've had quite a few other experiences like this, just today.

People spend a huge portion of their non-sleeping life at work. The relationships that are developed, the work that's accomplished, the situations that are dealt with, and the impact on the world that is made is non-trivial. It's a big deal to stop working somewhere that you've been for a significant amount of time. Work reflects a good chunk of life, leaving it, even for something better, is a big deal and shouldn't be taken lightly.
Read More
Posted in embedded, linux, next steps, work | No comments

Monday, 24 October 2011

Management and Leadership - Startup versus Established?

Posted on 05:08 by Unknown
I like Seth, his blog is in my Google Reader. His books are good, too. He recently wrote about leadership and management. It inspired me to come up with a question:

Does the relationship between leadership/management and startup/established business exists in a meaningful and measurable way?

I think it exists, and I'm sure it's meaningful, but I'm not sure it's measurable. How can you measure leadership or management in the way that Seth describes them? There's no easy metrics that spring to my mind. It's mostly one of those, "You'll know it when you see it" kind of things. That's too bad.

There's probably a whole industry out there claiming that they can offer insight into how to perform this measurement. These consultants probably make good money. Sadly, it's most likely all for naught. Unless you can see it plain as day, the person you're looking at isn't a leader.
Read More
Posted in work | No comments

Friday, 21 October 2011

Embedded Linux and Long Term Support / Updates - Part 2

Posted on 10:08 by Unknown
In my previous post about embedded Linux long term support, I neglected Ubuntu. I had not realized how much effort Canonical are putting into their ARM platform products. After doing a little reading today, it appears that within the next year, Ubuntu's long term support server distribution should be a very high quality product on ARM platforms. That's awesome!

Ubuntu LTS server releases are already supported for 5 years. Starting with version 12.04, the desktop LTS release will also be supported for 5 years. Combined with prebuilt images for various ARM development kits, that's an awesome starting point for higher powered, ARM based, embedded systems.

Ubuntu seems primed to completely take over the Linux distro landscape. I think that's awesome if you're looking to develop any new Linux based device on a platform they support. It'll make your life that much easier. Thanks, Canonical!
Read More
Posted in beagleboard, embedded, linux | No comments

Monday, 17 October 2011

An Unknown Error Has Occurred

Posted on 05:54 by Unknown
In software, don't ever tell a user that an "unknown error" has occurred. It does nothing but hurt the relationship between user and software.

This weekend I upgraded our iPad and my wife's iPhone4 to iOS5. The iPad went super smooth other than taking forever to download the update. The iPhone update did not go nearly as smooth. After downloading the update, backing up the iPhone, and erasing the flash, iTunes errored out with an "unknown (14) error." There was a nice link provided to an Apple knowledge base article telling me to try another USB port, reboot, or update iTunes (again? I just did!).

Lacking from all of this was any indication of what the heck caused the error!

Clearly, iTunes knows what caused the error, it raised an error message because of some event happening in a way that wasn't expected. But I have no idea what that event was so that I can try to prevent it from happening again or so I can write a bug report. It also left the iPhone in an uninitialized state, requiring a restore (which in itself was over an hour in duration).

Don't ever tell me that an "unknown" error has occurred. Either just tell me that "an error has occurred preventing" a task from completing or tell me what the heck the error was! The "UNKNOWN" part of the error is the most frustrating part, then Apple kicked me when I was down by providing a knowledge base article with stupid answers that didn't provide any insight into what the problem actually was. Yeah, I've used Windows before, rebooting is the knee jerk reflex, I don't need to be told that.

And to top it all off, iOS5 is noticeably slower than iOS4 was on both the iPad and iPhone4. The updated features are almost unnoticeable but the slowness is easily seen. Overall, I'm unimpressed.
Read More
Posted in iOS, software | No comments

Friday, 14 October 2011

Embedded Linux and Long Term Support / Updates

Posted on 08:39 by Unknown
If you are building a non-consumer commercial system that uses embedded Linux, you will probably be interested in long term support. Now, what I mean by long term support is: Two (or five) years from now, will someone be providing me with security updates to the same version of software that I use today?

For example, if you run RedHat Enterprise on a desktop or server, you can be sure that 5 years from when a new release comes out, RedHat will still be providing you with security updates for the exact same versions of all the software you run. You won't be forced to upgrade to some new version of software provided by RHEL in order to continue getting security updates. Your kernel will stay the same version, your Apache will stay the same version, your Bash will stay the same version, and you'll only get little tiny changes that 99% of the time are due to security issues being fixed. The other 1% of the time is things that are actually seriously broken and need to be fixed. But overall, NO NEW VERSIONS OR FEATURES!

For desktop and server distributions, there's a lot of choice between paid for setups like this and community supported setups. You've got RedHat and Suse as the major players in the paid for sector, and Debian stable, Ubuntu LTS, and Scientific / CentOS in the community sector.

In the embedded landscape, there's companies like MontaVista and Wind River that supply longish term supported embedded Linuxes, much the same way RedHat does. But the on the community side, other than Emdebian, there's not a whole lot (that I've heard of) that provide a long term support system for embedded.

Many of the embedded distributions are focused on cutting edge stuff. Cutting edge is cool, it's hip, and it's where all the neat stuff happens. But if you're deploying a real product that's going to have to function for years and years at a customer site, you're not going to want to have to keep sending them software updates having cutting edge versions. Cutting edge versions means things break. Stable old stuff being updated only with tiny security fixes means things don't break, at least not usually more than they were before. If you're looking to make real money selling embedded non-consumer Linux systems, you're going to pick old stable stuff getting security updates, and if you need fancy new stuff, you'll become an expert in just that new fancy stuff, and you'll do your own security updates just for that one thing you need to be newer.

I understand that having long term support be a community activity is hard. Especially when there's a low number of developers. Small projects can't afford to spend developer time supporting old stuff if they want to continue moving forward. Bigger companies who get paid (like Wind River and MontaVista) can. And Debian can, but only because they've built up the support systems, platforms, and methods of working over a huge amount of time and with a huge community that's dedicated to just that. It's very hard to do.

Linux kernel has long term supported versions, but those only get updates for 2 years, then they assume the distributions will take care of further updates. This is awesome for short life commercial projects, but some commercial projects need to last longer than that. For those projects, your choices are really limited if you don't want to employ a huge number of experts to keep things stable and secure. For those projects, you're going to buy a long term support system from a vendor or need the support of a high quality community. Because of this, you're either going to pay, or you're going to use Emdebian.

What else is there for community support?
Read More
Posted in embedded, linux | No comments

Tuesday, 4 October 2011

More Raspberry Pi

Posted on 04:30 by Unknown
When I wrote my blog entry last week about the Raspberry Pi project, I was being negative. That was wrong of me.

I was being negative about Raspberry Pi because they're doing an awesome job of putting out a low cost embedded system and I'm a bit jealous. The TuxedoBoard won't be nearly as low of cost. When I first thought up the TuxedoBoard, most ARM based single board computers were in the $100 to $250 range (think BeagleBoards and Gumstix). Pricing my less capable but much more open TuxedoBoard at $100 would fit in nicely with that marketplace. But with the Raspberry Pi being $25 and $35, that's going to ruin my potential customers' expectations on price. Even though I'm not trying to compete with the Raspberry Pi, just the fact that they're putting out an ARM based system (with very nice stats) for such a low price will hurt my chances of selling TuxedoBoards.

Raspberry Pi project, I'm sorry. I hope you succeed. I'm just jealous. Heck, I want to buy one of the $35 models. Good luck!
Read More
Posted in embedded, market, open source | No comments

Saturday, 1 October 2011

TI AM170x Booting Annoyances: Take 2

Posted on 11:08 by Unknown
I was incorrect in some of the statements I made before when discussing the TI AM170x booting. Daniel pointed out a few of my mistakes in the comments (thanks!). This is a quick follow up. I have quite a lot more reading and learning to do.

The AM170x chips require an external memory attached either to EMIFA, I2C, SPI, UART, or the HPI (host port interface). Since I want to be able to boot without requiring the UART connected, that boot method is most likely ruled out. The HPI sounds interesting but the impression I get is that usually another processor of some sort is connected there, which the TuxedoBoard won't have. So it's down to NOR or NAND flash on EMIFA, I2C, or SPI. Any of those will probably work for me, even though I wanted to avoid having an external memory device.

It turns out that the internal ROM is hard coded and not changeable. I was under the incorrect impression that it was an EEPROM and that using Code Composer Studio that one could change it. This is not the case. The internal ROM is what gets executed after reset, it sets up some basic configuration registers and checks the boot mode pins. Based on the boot mode pins, the ROM will configure the processor to access the appropriate external memory interface and load up the AIS (or non AIS boot mode) executable. This executable holds the device configuration information along with some other setup data such as clock speeds, pin mux settings, and various other configuration registers.

It seems like one could create an AIS (or non AIS executable) that would contain arbitrary code to be executed as a first stage bootloader but I'm not entirely clear on that yet. If so, or if it could fetch a first stage bootloader from the external memory that could contain a custom written binary that can access the SD/MMC card. All this together might be an end-around for booting off SD/MMC. Uboot would then be the second stage bootloader.

Daniel pointed out that there's a TI BSD licensed version of the AIS generator and other core boot code written in C# which should execute under Mono in Linux. These utilities also should not require Code Composer Studio, which is handy.
Read More
Posted in embedded, open source, tuxedo | No comments

Friday, 30 September 2011

SD Card Depot Why Don't You Exist?

Posted on 15:29 by Unknown
Trying to buy SD cards sucks. Newegg is way better than Amazon for finding an SD card that you want, but it still sucks.

I wish there was something like an SD Card Depot that just sold SD cards. They'd only sell high quality parts, test the things they sell, write reviews of them, sell consistent product (SD card quality varies. A lot!), provide guidance on what kind of cards work best for what kind of uses (do I really need a class 10 card for HD camcorder?), and make finding the SD card I want easy. Oh yea, and cheap shipping (hello Amazon sellers with $1 4GB cards and $9.95 shipping!!).

They'd be the (when they were just shoes) Zappos of SD cards. Awesome website, awesome service, dedicated to just one product and killing the act of selling it.

Makes me think there's a market opportunity here...
Read More
Posted in embedded, market | No comments

TI AM170x Booting Annoyances

Posted on 13:30 by Unknown
Although I haven't spent much time working on the TuxedoBoard in the past few months (newborn daughter in July), I've been thinking about it again recently as my sleep schedule is starting to normalize a bit.

In reading through the info from TI about boot modes on the AM17xx processors, a lot of time is spent describing the AIS (Application Image Script) proprietary boot script system. It's proprietary to TI, the script generator only runs on Windows, and it requires that you pay for and use Code Composer Studio. None of that sounds exciting to someone interested in open platforms.

So, if the AM170x processor is going to go onto the TuxedoBoard, there's going to have to be a custom bootloader.

Ideally, I would want a bootloader that doesn't require an external memory interface (either EMIFA, SPI, or I2C) due to the added cost and complexity. I'm imagining that there will be an MMC/SD card on the TuxedoBoard in order to hold the Linux filesystem, so booting directly off of that would be best. The BeagleBoard-xM boots off the MMC/SD card but its processor has internal firmware (not sure on the details) that is smart enough to find a FAT partition (if its the first one) and grab the MLO (x-loader) file (if its the first file loaded onto the partition).

I'd like it if my bootloader can setup the external SDRAM, set up all registers properly, find the MMC/SD card, transfer uboot (or other second stage bootloader) into RAM and jump to it. Kind of like the BeagleBoard-xM does it. There's 64kB of ROM and 8kB of RAM inside the AM170x ARM core. I'm not sure if that's enough but coming from a 8/16-bit microcontroller perspective, that's decent for doing quite a lot. It seems possible (even if it will be a lot of work).

It'd be awesome if the first partition on the MMC/SD card could be ext2 (or other open and less complex filesystem) and have only the uboot executable. The second partition (in your favorite, supported by uboot, format) would hold the actual Linux filesystem.

UPDATE 1 October 2011: I'm incorrect in some of the things stated in this blog post. I've not changed them but I have written another blog post.
Read More
Posted in next steps, open source, tuxedo | No comments

Thursday, 29 September 2011

Some Raspberry Pi

Posted on 05:36 by Unknown
I'm torn about the Raspberry Pi project. On the one hand, it's awesome that the group is developing a very low cost ($25 and $35 goal price points) ARM based computer with some rather nice specifications (clock speed, RAM, USB, Ethernet [on $35 model], 3d accel, etc) but the way they're going about it somewhat rubs me the wrong way.

Broadcom makes the ARM processor (BCM2835) but hasn't released any type of datasheet. It uses package-on-package memory, which is rather difficult for many assembly houses to deal with and requires rather large orders in order to obtain memory from suppliers due to constrained supply lines. The Broadcom GPU that's integrated uses closed source drivers and in order to get legal access to the multimedia hardware IP blocks you are required to buy a license (RasPi says they'll include a few of the most often used codec licenses with purchase, but not all). The boot process is yet another convoluted weird way of doing things: the GPU runs first, executes a first stage bootloader, then dumps you over to the actual ARM core for booting Linux.

In order to manufacture their 6 layer (originally they said 4 but that's not appearing possible) board, RasPi is using blind, buried, or partial vias which raises the cost of the bare board and limits who can manufacture it. They're also not even connecting all pins on the processor, some GPIO won't be connected to anything and thus will be unused. These tiny pitch BGA parts are awesome if you've got constrained spaces to fit in and you have access to seriously advanced manufacturing capability and can use 8+ layer boards. Otherwise, they're a pain!

The RasPi foundation is getting special pricing on almost all of their parts. They're buying in the 10,000 quantity but (at least on some parts) appear to be getting 1,000,000 quantity pricing. They have publicly said they are not getting any sponsorship or free parts, which is good to hear based on their very low price point goals for the finished product.

Although Eben has said (in answers to Slashdot questions) that the layout and schematics would be open with "A qualified yes," that's dependent upon the final board design being able to be exported to something like Eagle. He also throws in some other verbiage that makes me unsure what will really happen. (And yes, I understand I won't be able to build one myself, even if I had mad hot air rework skills, the pitch on some parts are remarkably small and POP is a nightmare even for automated robotic assembly shops.)

But in the end, my biggest concern is that the $25 and $35 prices won't really happen. There's been mention of a "give one get one" program at first (so you have to pay for 2 in order to obtain one) where the one you "give" will be provided to school children. But there's not been mention that I've seen of when the one you "give" will be actually given. Mostly, for $25, leaving the RasPi foundation with no profit, they need (my personal SWAG on cost) about $15 in parts (including circuit board), maybe $8 in labor to assemble (including all tooling costs being rolled into the per unit cost), and that leaves about $2 to cover testing and warranty replacements (2% warranty rate is $0.50, 4% is $1). That's crazy cheap! And it requires a very low failure rate under warranty, let alone the costs associated with fulfilling the warranty replacements (emails, phone calls, shipping, etc aren't included).

I don't think $25 and $35 price points are sustainable in a break-even or profit making enterprise based on the goals and current public information for the Raspberry Pi. I do hope I'm wrong.
Read More
Posted in embedded, linux | No comments

Wednesday, 28 September 2011

Google Search Results!

Posted on 10:36 by Unknown
Somewhat ironically, if you search Google for: Stanford database class, my blog is showing up (at least some of the time, even when searching when I'm using a different browser and not logged into Google services) in 5th spot, ahead of the actual db-class.com (which redirects to the .org version) website.  I find that intriguing and funny.  It also makes me smile.

Now to get my actual database class notes blog to show up there as well!


Read More
Posted in db | No comments

Tuesday, 27 September 2011

Do What You Love, Good Things Will Come

Posted on 04:58 by Unknown
This morning, I found this article from the Harvard Business Review blog that's mostly about job hunting but also a few other things. Do what you enjoy, build relationships, and stop stressing out about the state of the economy or your life. You'll find what you are looking for faster, or at least enjoy yourself way more while waiting for opportunity to arrive in the same amount of time.

I like the premise. It's part of why I started contributing to the Cross Linux From Scratch project and why I started blogging. My database class notes blog might make me a little money from Google ads but I think the real value is in establishing myself as a resource and opening doors for me. Maybe (but probably not) I'll become a lesser version of Salman Khan and be known for presenting small chunks of learning. Who knows?! Certainly not me, but I am enjoying writing more.

In mostly the same vein, Marco linked to a presentation by John Gruber and Merlin Mann from SXSW 2009 that I really enjoy listening to. The title of their talk is awesome, "HOWTO: 149 Surprising Ways to Turbocharge Your Blog With Credibility!" (note: you will not hear them list 149 things, it's more like 5)
Read More
Posted in db, next steps | No comments

Monday, 26 September 2011

Database Class Notes

Posted on 05:22 by Unknown
The Stanford online database course's enrollment has opened and I've got my course notes blog started!

I'll be blogging my notes and thoughts on the course in as close to real time as I can. I hope to post up my solutions to assignments once allowed on my Github account.
Read More
Posted in db | No comments

Friday, 23 September 2011

Hewlett-Packard, WebOS... RIP

Posted on 09:39 by Unknown
Meg Whitman is the new CEO of HP. Leo Apotheker got to be CEO for less than a year and for most of that time Meg Whitman was on the board of directors. The board seemed to back Apotheker when he made decisions that roiled the web press. He killed almost everything HP got from the purchase of Palm, bought Autonomy, said the company is going to transition into "enterprise" software & services, and started discussions that HP was going to sell off their commodity computer business. The board didn't seem to object, at least not publicly. Apotheker was horrible at communicating with the shareholders but that pales in comparison to the rather large changes being made, it's forgivable.

But now they've fired Apotheker and put Whitman in his place. HP's not going to recover from Apotheker's decisions if Whitman is in charge.

I'm sorry HP shareholders, employees, and customers. You're in for a continued rough ride in the near future.

Why should anyone think that Whitman, who didn't have the best record at eBay (even though the major press seems to think otherwise), who failed at becoming the governor of California, and who was on the board of directors for most of the time Apotheker made such "bad" decisions, will do anything "better" than Apotheker?

HP used to be an engineer's company. Woz worked there and loved it. If Woz thought HP was an engineer's dream company, I bet it was. HP made THE BEST calculators, THE BEST test equipment, THE BEST mid range laser printers, THE BEST low end ink jet printers, and probably tons of other products that were THE BEST of their time. HP isn't an engineer's company any more. Meg Whitman isn't going to make it back into an engineer's company.

Today, what does HP build that's the best?

WebOS had a chance to be THE BEST, even though they stumbled out of the starting blocks and were late to the party. Out of all the things that have changed at HP under Apotheker, the loss of WebOS as even a reasonable contender against iOS and Android, is the worst.

HP's not THE BEST at anything any more. Rest in peace...
Read More
Posted in computers, webOS | No comments

Thursday, 22 September 2011

Stanford Database Class and an Experiment

Posted on 05:53 by Unknown
Stanford is running a free online databases course this fall. I've signed up to get more info and once that info comes out, I'll be registering for the course. It runs from October 10 till December 12. I assume there will be two or three video lectures per week along with projects or homework.

If allowed by the course guidelines, I'm going to blog my notes from lectures and post my projects / homework up on GitHub.

I want to become a better writer, learn about databases, and possibly make a little money from Google ads. Taking the database course and blogging my notes and thoughts will help me to accomplish all three.

My background is mostly in electrical engineering but I do write software. Although I've been formally programming since my first year of college (2001), I've never taken a formal algorithms, data structures, or database course. These days I write some C# for Windows and C for microcontrollers but I've also worked with Java and C++ and done a tiny bit of Python and Perl. My background probably matches a lot of people out there who are self taught coders and I think that provides me with a good audience desiring to learn about databases and that I can easily connect with.

I had wanted to try out Tumblr but after opening an account and playing with their interface, I think I'll stick with Blogger. Tumblr wasn't necessarily bad, but I'm used to Blogger (even with the new interface) and writing in the HTML view is pretty unencumbered for me. I'll post up a link to the database class notes blog shortly.
Read More
Posted in db, next steps | No comments

Friday, 5 August 2011

Introduction to Verilog

Posted on 11:36 by Unknown
I found a nice series of lectures given at the Indian Institute of Technology at Kharagpur by Prof. Sengupta. They're hosted on YouTube and I've made a playlist for lectures 2 through 7. There are quite a few lectures in this course and I'll be posting playlists for more later.

Please be aware, at the start of each lecture video there is a very loud test tone for the first few seconds.

Read More
Posted in fpga, learning | No comments

Friday, 29 July 2011

Downsides and Upsides of Altera's Configuration Via Protocol

Posted on 07:52 by Unknown
Yesterday, I wrote a little about reconfigurable FPGAs attached to the PCI-Express bus as an addition to the general purpose computer. The idea revolves around being able to reconfigure an FPGA over PCI-Express without requiring a PCI reset (basically a reboot). In this way, as processing demands change on the host computer, the FPGA can be configured to process data in the most effective way.

The huge upside of being able to reconfigure an FPGA over PCI-Express is that there's no external programmer (such as Altera's USB Blaster) involved. The hardware needed to perform a configuration is all built into the FPGA and embedded in the operating system drivers running on the computer. This ability really opens up the possibility of having a large number of FPGAs connected over PCI-Express and configuring each one individually, quickly, and when ever you want.

On the downside, the initial configuration that is loaded into the FPGA at boot time sets the I/O interfaces up for each pin and can't be changed. This is fine, if you don't care about I/O customization. I'm envisioning a system where this isn't a large issue because the FPGAs would only be used for data processing, not for interfacing to I/O outside of the PCI-Express bus and a minimal set of devices located on the same circuit board.

Another downside is that currently only the Cyclone V, Arria V, and Stratix V FPGAs from Altera support configuration via protocol over PCI-Express. Cyclone V is the most attractive as the Cyclone family usually is lower cost than Arria and Stratix. Cyclone V doesn't appear to be available yet for public consumption which makes cost estimation difficult for those who don't have a standing relationship with Altera (myself included). The Cyclone IV has been available for a while, includes hard IP for PCI-Express 1.0, and is reasonably priced but Altera doesn't support configuration via protocol for that family.

Overall, for developing a PCI-Express reconfigurable FPGA system, the upsides strongly outweigh the downsides. I'm very excited about configuration via protocol!
Read More
Posted in fpga | No comments

Thursday, 28 July 2011

Modular FPGA Accelerated Computing

Posted on 07:43 by Unknown
General purpose computers are great at doing a huge variety of things because they are programmable via software. But with this flexibility comes sloth, general purpose computers are slow compared to specialist hardware like ASICs or even FPGAs for a large number of computations.

The recent push into GPGPU computing using graphics processors to attack massively parallel problems that involve simple computations is expanding the abilities of general purpose computers. AMD is betting the farm on it with their Fusion designs. The capabilities of GPGPU programs are limited but the speed at which they can be executed is approaching that of FPGA hardware. By utilizing GPGPU computing, a rather low cost, somewhat easy to program addition to the general purpose computer can improve processing performance for a subset of computations.

But the main drawback to GPGPU computing is power consumption. In order to be this fast and have the ability to be programmed with software, graphics cards draw huge amounts of power compared to dedicated hardware like ASICs or FPGAs.

This is where I think reconfigurable FPGAs come into play in the general purpose computer. FPGAs can be configured in many different ways and can execute some algorithms in hardware much faster than a general purpose computer can. In this way, they're a lot like GPGPU computing, except the power consumption is orders of magnitude lower.

Pico Computing makes the Pico E-18 ExpressCard/34 FPGA device. It fits in an ExpressCard/34 slot and I assume conforms to the power requirements of ExpressCard/34. That means its power consumption should be about 3W max. Compare this to even mid-level performance GPGPU devices consuming hundreds of Watts of power. Let's assume, for comparison sake, that a GPGPU device consumes 100W of power and that the Pico E-18 or similar FPGA based device consumes 3W. At that ratio, you could have 33 FPGAs or one GPGPU device! Or, even better, you can have one ExpressCard/34 FPGA in your laptop and not impact heat or battery performance dramatically.

The main drawback of FPGA based computing is the upfront costs. GPGPU devices are relatively cheap because lots of people buy graphics cards. Very few people are currently buying FPGA devices for their computers. It's a chicken and egg problem but some high profile use cases are tipping the scales towards more pervasive use of FPGAs in general purpose computers, take JPMorgan for example.

Along with use cases becoming more visible to the computing world showing what FPGAs can do, the ability to reconfigure an FPGA on the fly is very important. Usually, when an FPGA is powered up, it gets configured. Until the power goes away or a special programmer device is connected, FPGAs rarely get reconfigured while running. That's changing!

Xilinx has Partial Reconfiguration and now Altera has announced Configuration via PCI-Express. Altera's technology basically allows you to only partially configure the FPGA in the usual way, such as with an Active Serial device, and then to configure the rest of the FPGA at a later time over PCI-Express dynamically. This means that you could load up a different FPGA configuration at the start of software execution on your PC. Then when you start a different program, another FPGA configuration is loaded. This provides more general purpose abilities but with the speed of execution that an FPGA provides.

This is huge!

The main barrier to entry is up-front initial FPGA purchase price. But cost can be reduced by selling smaller modules, like ExpressCard devices, and by ramping up volume. Ramping up volume requires showing people how they can utilize the technology for lots of currently slow, power hungry computations. Showing people how this technology can improve performance requires some very well built software and example FPGA code along with making the sale of these devices more like other general purpose computing hardware (vendors currently make it difficult to buy an FPGA based PCI-Express card). Altera and Xilinx aren't going to enter this market but I bet they'd love to support someone who was. The tools and support, let alone devices to be sold, provides a great reason for Altera and Xilinx to support a company doing this.

It'd be a great start-up company and the business side has some awesome potential, too. Think of an app-store for FPGA configurations where the vendor (like Apple does) gets a cut of every sale! Let alone actually selling hardware and support contracts. Plus, there's no big player doing this yet making it easier to enter the market.
Read More
Posted in computers, crypto, fpga | No comments

Friday, 1 July 2011

Function Pointers

Posted on 10:30 by Unknown
Function pointers are pretty cool. I learned about them this week, then I solved a problem using them.

At work, I'm writing some code for a 16 bit microcontroller. In the system I'm working with, a relatively slow external clock causes an interrupt to be fired off. Inside my code, I have a state machine that executes each time the interrupt fires. The state machine was implemented using a switch statement that contained a reasonable number of cases, one for each possible state.

This worked great, up until I continued to add states. Eventually, the time to determine which state should be executed became about half as long as the period of the external clock. This is bad because it means some of my states may not have enough time to execute before the next interrupt comes along. If that happens, bad things occur and the state machine loses place compared to the rest of the world.

To solve this, I thought there had to be a way to create an array of pointers to functions. Then as I change state - represented as an index into the array - I could just call what ever function is pointed to in the array. It turns out, that's very possible in C. Here's a good tutorial I found.

The assembly code for using an array of function pointers is much shorter than the switch statement code. This gives me more time to execute code in between interrupts and was not hard to implement. Each of the switch statement's cases (states) became a function and at the start of execution an array of function pointers to each function is populated. Within the states the array index can be changed based on inputs or the result of processing data.

Extra documentation can be very helpful when using function pointers. A switch statement is easy to understand but an array of function pointers is a bit more opaque.
Read More
Posted in c | No comments

Wednesday, 15 June 2011

Crypto Load Balancer Using Off The Shelf Hardware

Posted on 16:01 by Unknown
At my day job, I work a reasonable amount of time with cryptographic and authentication systems. Lately, I've been reading about OpenCL and CUDA. I'm wondering if buying a high end graphics card to do some brute force number crunching would be worthwhile.

Today on Hacker News, there was a link to netmap. Netmap looks like a neat way of getting very high network throughput (like saturating a 10G Ethernet line using only 1.66 GHz of processor) using standard hardware (no special ASICs or FPGAs).

I've also read in the past about TLS / SSL and load balancers. TLS / SSL is what's used to encrypt data going between a server and a client, such as for credit card number or username & password transmission. A traditional load balancer will sit on the network in-line before the cluster of servers that actually serve webpages. As requests come into the load balancer, it distributes the requests to the servers in such a way that no server gets overloaded.

I've also read a tiny amount about load balancers that will decrypt and encrypt TLS / SSL traffic such that the webservers don't have to (encryption on general purpose CPUs is expensive). I'd imagine that, for these load balancers to do TLS / SSL inline, this requires very high network throughput as well as very fast number crunching for encryption systems. Traditionally, I'd expect a load balancer such as this would use special hardware (as normal routers do) in order to obtain very high network throughput. I'd also expect custom FPGA code or ASICs would be used to provide high throughput encryption abilities. In both cases, these are low volume, very specialized systems that will be very expensive to create and sell.

But what if someone could combine both netmap and OpenCL to perform load balancing and TLS / SSL in one box that uses off the shelf hardware?

It probably wouldn't be as capable as the truly high end hardware, but it could probably compete in the mid-range and cost significantly less. As the hardware required would be basically:
  • A fast processor / motherboard / RAM combo
  • A large number of PCIe 2.0 slots with a large number of lanes each
  • At least 2 10Gb Ethernet PCIe cards
  • A few high end ATI graphics cards to execute OpenCL code

A high end server system with some add-in cards would fit the hardware bill. Then you'd just need a nicely setup OS (to support netmap and the ATI drivers) and some software to load balance and run the encryption. This isn't simple but it's less complex than a dedicated custom hardware system.

I think this is a pretty neat idea. Of course, as more processors start to include encryption abilities, the viability of a device like this is reduced. But an advantage of this type of device over built-in encryption abilities in CPUs is that it's easy to update this device, we just write new software and deploy it normally. A CPU can't easily be updated to add additional encryption schemes once it is produced.

Another concern would be that the load balancer would need to store the private key and pass it around to the graphics cards, this could be a security issue, but one that could be mitigated by having separate private keys for normal TLS / SSL traffic and traffic where really sensitive data is transmitted (like credit card numbers). The credit card processing server should probably have an HSM and that would be OK because traffic would be much lower.

Something like this could really accelerate the adoption of HTTPS everywhere in order to prevent FireSheep type attacks.
Read More
Posted in crypto, linux | No comments

Tuesday, 14 June 2011

Conan's Dartmouth 2011 Commencement Address

Posted on 04:28 by Unknown
Watch Conan O'Brien give the commencement address to the Dartmouth class of 2011. It's funny and there's real life lessons that apply to everyone, not just those graduating.

Read More
Posted in | No comments

Sunday, 12 June 2011

The Standing Desk

Posted on 05:00 by Unknown
At work, I started using a ghetto standing desk with my lab PC about a month ago. At the beginning of the year, I got a new Dell tower and monitor (the U2311, which is really nice). The monitor box standing on top of a few plastic "project boxes" on top of a slightly higher than normal lab workbench is just the right height for my keyboard and trackball. The monitor sits on top of the Dell tower.

I like it, but the work I'm doing these days leads to some inefficiencies. I'm working a lot reading reams of documentation, connecting different things to various circuit boards, and running a logic analyzer. All of this stuff happens at the normal lab bench height. Because of this, I sit down about 25% of the time when working at my standing desk. That's OK, but it would be much nicer if I could raise the workbench up to the right height for my keyboard and trackball (it's about a 14" difference, I think).

The floor in the lab is 1 foot square industrial stick-on "tiles" (I think they're like linoleum). I don't use any kind of standing mat. My everyday shoes are 4 year old Adidas soccer shoes. The first week was a bit hard on my legs and back, I'd be stiff each morning, but it has gotten better. I still feel like I'm doing more physical work by standing (I've read it burns 3x the calories as sitting) but I'm not uncomfortable standing for 4 hours at a time.

The one thing I have noticed is that I'm more focused on my work when standing. Lately I'm writing C code for a PIC24f microcontroller. But I like to sit when I'm doing real hard core thinking, like when figuring out timing of interrupts or reading through assembly code. I'm not sure why this is. Having everything I work with up at the right height might help but I've not yet found the right sized cinder blocks laying around.

In my cube I still sit. My chair isn't fancy but it isn't too bad for comfort. At home I sit on a wooden chair when working on my desktop. My main motivation for trying the standing desk was that the chair I had in the lab was uncomfortable and rather than attempt to find a chair that would work, making a standing desk was quick and cheap.

So far I like it, although it does have downsides (my hardcore thinking, not everything being at the same level, etc). My coworkers think it's funny that I stand up but my boss has started pondering the idea of trying it since I've been using it successfully for a decent amount of time now.

If you're uncomfortable sitting all day, try a standing desk. It's all the rage on Hacker News ;)
Read More
Posted in | No comments

Saturday, 14 May 2011

Install the HP webOS SDK on Debian 6 Squeeze

Posted on 15:27 by Unknown
Quick instructions on how to install HP's webOS SDK (software development kit) on Debian 6 Squeeze x86_64. I was a little bored and was reading about webOS...

Edit /etc/apt/sources.list to add the VirtualBox repo and enable contrib and non-free for your favorite Debian repo line. The lines we care about look something like this:

deb http://mirror.rit.edu/debian/ squeeze main contrib non-free
deb http://download.virtualbox.org/virtualbox/debian \
squeeze contrib non-free


Grab the Oracle apt signing key and install it with a:

sudo apt-key add oracle_vbox.asc

Run a quick update for aptitude (or apt-get if you prefer):

sudo aptitude update

Install the needed packages (Java6 JDK [you supposedly only need the JRE but I'm using the JDK as well], VirtualBox 3.2, and ia32 libraries [only on 64 bit]):

sudo aptitude install sun-java6-jdk virtualbox-3.2 ia32-libs

Grab a copy of HP/Palm's novacom and the actual SDK (be wary, it's 185MB in size) in deb format.

And, finally, install both of those:

sudo dpkg -i --force-architecture \
palm-sdk_2.1.0-svn409992-pho519_i386.deb
sudo dpkg -i --force-architecture palm-novacom_1.0.64_amd64.deb


As the novacom package provided by Palm/HP uses Upstart as found on Ubuntu (Debian doesn't), you have to start the novacom daemon yourself. It can be found in /opt/Palm/novacom/novacomd. Novacom should allow you to push apps into the virtual machine for testing, Palm/HP don't want you messing with the file system in weird ways.

To launch the emulator, fire up a console and run palm-emulator. It will first build the virtual machine and then launch it. Use the escape button (on your keyboard) to go back, the end button acts like the button on the phone, and home does something (sort of like end, but not sure why it's different). Clicking and dragging are just like your finger would do.

Enjoy! :)

Pretty picture below:
Read More
Posted in webOS | No comments

Tuesday, 10 May 2011

Expectations and the i.MX53 QSB "Lab" Session

Posted on 14:34 by Unknown
My expectations were high for the Freescale i.MX53 lab session that was held this morning. I was excited! The agenda had items like Linux on the i.MX53! LTIB! Android development on the i.MX53! and free lunch!

My expectations were not realized.
There was free lunch but I left.

The morning consisted of a lecture by a very nice and smart guy about general embedded Linux things and the i.MX53 QSB hardware. No fault on him but the material was way too basic. I was expecting to get right into using LTIB and learning about the LTIB configuration and build system and how it applies to the i.MX53. I don't have much experience with LTIB but we didn't really do much with it other than run a script and look at some options in the menuconfig interface.

Those who felt comfortable with embedded Linux were given the serial cables and SDcards so they could play during the lecture. I tried to do the Ubuntu demo but just loading it onto the SDcard must have taken a good hour. Then the USB to serial converter decided to not play nice with VMware Workstation (host machines were Ubuntu 10.10 in a VM on top of Windows). And then once the demo finished loading and I booted it... It's Ubuntu! What's the fun of that? What did I learn? Nothing.

SDcards are slow. But that's another topic all together.

I then played a little with LTIB but I didn't like it. I felt like I had no control over the choices. I'm not sure if that is LTIB's fault or Freescale's fault. We didn't have a connection to the Internet so there was no way for me to use any sources other than what was provided. Regardless, it was a type the following few lines, look at some options that have already been selected, push go. One thing I really disliked was that the LTIB menuconfig had almost no help for options that were vague. That's not cool.

I did meet a nice guy name Jon who works for a local company doing board support packages for custom embedded boards, that was cool. But overall, I wish I hadn't gone. It was nice out today so I did the next best thing and left at lunch to mow the lawn. Way better use of my vacation day.
Read More
Posted in embedded, linux | No comments

Friday, 6 May 2011

The TuxedoBoard has a Brain! (picked out)

Posted on 03:43 by Unknown
I've chosen an ARM SoC (system on chip) for the TuxedoBoard! The Texas Instruments AM1707 ARM9 core will meet my requirements.

The AM1707 is a 456-MHz ARM926EJ-S SoC that has an internal Ethernet MAC, multiple UARTs (serial ports), an external memory interface for a 32 bit wide SDRAM bus supporting up to 256MB RAM, an external NOR flash memory interface multiplexed with an SD card controller, USB, an LCD interface, and a few other interesting features.

In keeping with the stated goals for the TuxedoBoard project, the schematic capture and layout will be done with Kicad. Kicad supports both Windows and Linux and is covered by the GPLv2 license. I'm currently using the 20100314 release as that's what comes with Debian 6.

I'm in the process of creating the schematic symbols for the AM1707. I'm new to Kicad and I was not able to find an already made symbol with a permissive license, so this is taking a little time. I've made the power symbol and the EMIF_A (external NOR flash / SD card interface) symbol. Some pretty pictures of what I've got so far:


Read More
Posted in embedded, tuxedo | No comments

Saturday, 30 April 2011

Picking an Open Source Hardware License

Posted on 18:35 by Unknown
I've been wandering around the Definition of Free Cultural Works open source hardware Statement of Principles and doing a little thinking.

I like the ideas behind open source hardware as stated in the Statement of Principles. I want the TuxedoBoard to have a licence that complies with these principles. The difficult part is finding a license that has already been written that can accomplish those principles. I'm not a lawyer so writing one myself seems like a bad idea to me.

The whole open source hardware movement is at the heel of the hockey stick curve. Having a high quality open source hardware license, like the GNU GPL is for software, is something that's definitely needed.

Creative Commons is nice but it is too general and doesn't require enough. The GPL seems awkward when applied to physical things or designs for physical things. The BSD and MIT licenses allow inclusion without releasing source and also seem to apply best to software.

TAPR doesn't quite go far enough and I don't think it completely complies with the OSHW Statement of Principles. For example, under TAPR, schematics or layouts can be distributed in PDF form. That's not helpful! I want a license that requires distribution of things like schematics and layouts in the original computer file format.

So far, I've not found a high quality open source hardware license that I like. I'm confident that one will come about soon but I'm not sure who's going to write it. I'm not that concerned yet, TuxedoBoard is still just an idea, but the time to be concerned is quickly approaching.

Maybe the best bet is a modified TAPR license. But then again, what license is the TAPR license text under? It's copyrighted but does not appear to be licensed for modification or reuse.
Read More
Posted in license, tuxedo | No comments

Thursday, 28 April 2011

TuxedoBoard BGAs and Minimum Ball Pitch

Posted on 03:19 by Unknown
After some discussion with Brian and lots of reading, I've learned quite a bit more about BGAs and ball pitch. I'm now leaning towards wanting at least 1mm ball pitch on any BGA parts used on the TuxedoBoard. 0.8mm ball pitch seems like the dividing line between being able to do a "traditional" dog bone fanout and needing to use via-in-pad. I want to avoid doing via-in-pad if at all possible. Not all board manufacturing houses can build PCBs this way, and even those that can will charge more or have lower yield than other methods. Even Screaming Circuits would prefer to not deal with via-in-pad, although it sounds like they can. I believe they built the BeagleBoards but even they consider the technology used on a low cost BeagleBoard to be special.

With 1mm ball pitch BGAs, two or three 4mil (or 3.5mil) traces can fit between vias, depending on a whole slew of other parameters. Brian warned me that some board houses can't reliably do 3mil and smaller traces, that's good to know. For the number of pins I'm considering for the ARM SoC (in the 300 pin range), a 6 layer board should be doable with 4 routing layers and 2 power. Now, whether 4 routing layers and 2 power is possible for the pinout, that's another question. :)

With this in mind, a minimum of 1mm ball pitch seems the best way forward for now. I want the design to be easy and inexpensive to manufacture at a large number of places. In order to achieve this, microvias and via-in-pad aren't the way to go.

Now, to pin down which SoC will be used!
The Freescale i.MX25 parts are 0.8mm and smaller ball pitch. :( But TI does make the AM1707 ARM9 part with 1mm ball pitch which now looks interesting...
Read More
Posted in beagleboard, tuxedo | No comments

Wednesday, 27 April 2011

TuxedoBoard SoC Selection

Posted on 03:41 by Unknown
I don't yet know which ARM SoC (system on a chip) I'm going to use for the TuxedoBoard. Cost and features both weigh heavily on my mind when looking at what different vendors have to offer. I wrote an email spewing some of my thoughts on this topic yesterday and I'd like to share an edited version:

Due to my desired price point of about $100 for assembled and tested TuxedoBoards and because I expect the first build's volume to be about 100 boards, I'm looking to keep the SoC cost to under $8 each.

So far, I've not had success finding Cortex-A8 devices in the $8 range when purchased in quantities of about 100 units, regardless of vendor or features. There's quite a good variety of ARM9 parts in the $6 range that include all the features I think I'm interested in. I would prefer to use a Cortex-A8 part but if the cost is too high, ARM9 will get the job done and allow my price point.

BGA packages seem to be the only package offered for all Cortex-A8 and many ARM9 parts. That's OK with me as I've realized that selling an assemble-it-yourself kit isn't as important as making everything open so others can utilize the design. I'd prefer 1mm BGA ball pitch to allow for easy and cheap assembly but 0.8mm is second choice and would work fine. Pitch smaller than 0.8mm is a real turnoff to me because assembly tolerances get very tight and some assembly houses can't promise good yields. As I'm not looking to make the board into a mobile phone, or other space constrained device, physical size of the package isn't as important as ease and cost of assembly.

I'm not that excited about package-on-package (POP) memory, like used on the BeagleBoards. I get the impression that a good number of assembly houses aren't yet comfortable with POP and that the BeagleBoard team went through some issues with manufacturing yield at first. My first manufacturing run will only be around 100 boards, having yield issues would be very bad and ruin the finance side of things.

Freescale makes a very nice looking ARM9 core in the i.MX253. The i.MX253 prices out in the $6 range at Digi-Key. TI makes a competing ARM9 part in the AM1802 but I'm not clear on the pricing or features yet, still have to look into that.
Read More
Posted in beagleboard, embedded, tuxedo | No comments

Tuesday, 26 April 2011

I Dub Thee, TuxedoBoard

Posted on 04:16 by Unknown
In order to have a name that I can refer to my planned open source hardware embedded Linux board with, I've chosen TuxedoBoard. Brian wrote me, "how about the TUX or Tuxedo board, its fitting and fun like beagle." Yes, it is! :)

I've changed the decor of my blog just slightly, replacing the formerly orange background with an almost black one. It's more fitting of a tuxedo. This is not Dumb and Dumber.
Read More
Posted in tuxedo | No comments

Monday, 25 April 2011

More Open Source Hardware Ramblings

Posted on 04:50 by Unknown
I'm that much closer to designing a completely open source embedded computer!

I've been reading Do the Work by Steven Pressfield and I've been rambling on and on about designing a board to my friend Brian. The hardest part is starting, then the hardest part is shipping. I'm working on the starting part and wanted to share my thoughts.

The concept for an open source embedded board is that everything will be open source. By everything, I mean everything! The tools used to design the hardware, both schematics and layout, will be open source tools (currently leaning towards Kicad). The files used for schematic capture and layout will be open sourced (not just PDFs but real actual files you can pick up and use to make your own board). The information on how to bring up the board from a blank, just manufactured state, will be online with an open documentation license. The information on how to build Linux and a bootloader and useful software will be online with an open documentation license. Everything will be open!

Along with general openness of the design process, I'd like to keep any software written or used on the board open as well. So no binary blob kernel drivers, no closed source software, and no non-free IP blocks. This is hard. It means no hardware accelerated 3d graphics. It means limited (probably no) DSP blocks.

I'd like to be able to sell this board for $100 but I'm not sure if that's a reasonable target price. I'm not looking to make big bucks doing this, it's a learning exercise for me. But shipping product to customers is a goal I have because it will force me to actually get things working. A more realistic price point is probably $150, but then it loses the appeal of being cheap because a BeagleBoard is only $125 now and my board won't offer much more in terms of hardware.

In order to meet the $100 price goal, I wouldn't use a Cortex-A8 part. I'd probably use an ARM9 processor. That gets the price lower but sacrifices a lot of nice things that Cortex-A8 parts have (faster, better floating point, etc). I'm not yet sure if the trade-off is worth it, in either direction. I'm leaning towards ARM9 because I think price is really important, even if my board is the only one out there that's completely open.

As a functionality differentiator, I'd like to have hardware compatibility with Arduino shields. There's already a huge amount of hardware out there that works well with Arduino systems and is aimed at people who like to play with little computer systems. Taking advantage of that ecosystem while showing people how they can communicate with the same hardware, but from within Linux, would be really cool. An ARM9 is hugely more powerful than an ATmega and is a nice halfway point between an Arduino and a full PC (size, power, price, and ability wise).

Once I have a design that will work, I plan to fund the build of prototypes and shipping hardware using Kickstarter. Open Vizsla inspired me that this type of funding scheme for hardware can really work.
Read More
Posted in embedded, next steps, open source, tuxedo | No comments

Sunday, 17 April 2011

Free IP Block Boards?

Posted on 08:08 by Unknown
At the LFCS (Linux Foundation Collaboration Summit) recently, some of the discussion was about system on chip (SoC) vendors including IP blocks (basically special circuitry to interface to the world in a specific way, like for outputting 3D graphics) in their designs that require non-free kernel drivers. By non-free, I mean that the source code is not available without some type of non-disclosure agreement. LWN mentioned this. It's basically an accepted fact of life in the embedded world right now that if you want certain kinds of hardware, you're stuck with non-free kernel drivers.

I don't want to deal with non-free IP blocks. The whole point of using Linux on embedded devices is because stuff works, and when it doesn't, you have the source and can see why. This enables delivery of a system faster and more effectively.

Are there any low cost embedded development boards out there that do not include any non-free hardware? I'd prefer a board where all the drivers exist in the mainline kernel, but stuff in -staging is OK, too. An ARM processor isn't a requirement, I'm open to MIPS, PowerPC, SuperH, x86, or any other type, just as long as I can use all of the hardware without needing any non-free code. Oh, and it should cost $150 or less.
Read More
Posted in embedded, linux, open source | No comments

Wednesday, 13 April 2011

The Freescale i.MX53 QSB Looks Neat

Posted on 03:40 by Unknown
Yesterday, I received an email from a Freescale representative saying that they would be holding a free day-long "lab" session in Rochester (where I live) next month about the i.MX53 Quick Start Development Board. Topics to be covered include getting both Linux and Android up and running on the board as well as showing how to set up a development environment on a host PC. There will be a few different "labs" (mostly following a script I assume) but everything will be provided and I think they include lunch. All attendees receive a $50 off coupon towards the purchase of an i.MX53 QSB.

I had never heard of the i.MX53 QSB before so I was intrigued.

It turns out, the i.MX53 QSB looks like a pretty cool little board. It's got Freescale's implementation of an ARM Cortex-A8 core running at 1 GHz, 1 GB of DDR3 RAM, USB, Ethernet, VGA (and LVDS) video output, SD card, microSD card, audio, and an expansion port. All for $150. One cool thing you can add to the expansion port is a 800x480 touch screen LCD!

My impression is that Freescale was inspired by the BeagleBoard-xM, although I don't know for sure. The written documentation appears to be a bit more in-depth than the BeagleBoard-xM and comes across as more professional but there are a lot of typos. The price is the same as the BeagleBoard-xM (without a coupon) and the feature set is very similar, except a few nice extras (expansion port and double the RAM).

I'm very happy to see that Freescale is getting into this market. The $150 price point is cheap enough for hobbyists (like me) but also cheap enough that employers won't balk at an engineer asking to buy one. Both the i.MX53 QSB and BeagleBoard-xM are going to help grow the ARM device ecosystem at tremendous rates.

Will Freescale be able to create a community around the i.MX53 QSB in the same way that the BeagleBoard has?

That's the million dollar question. Just having cool hardware or software isn't enough. Community is probably more important. Solving problems, posting how-tos, sending code up-stream, having an IRC channel and mailing list... Without that, the i.MX53 QSB won't be nearly as successful as the BeagleBoards.

I, for one, welcome our new low cost ARM development boards!
Read More
Posted in beagleboard, community, embedded, linux | No comments

Tuesday, 5 April 2011

Git is Cool!

Posted on 04:18 by Unknown
I'm working on adding a patch to the CLFS embedded book this morning to enable soft floating point support in libgcc for ARM when used with uClibc. I had committed the patch in my CLFS embedded git repo but with a name that wasn't really in line with other CLFS patches. I hadn't yet pushed that commit and I wanted to change the name.

I hadn't realized that I wanted to change the name until I started adding the new patch to the DocBook. So now I have unstaged changes and I want to change the name of a patch file that had already been committed. Also, having a commit that just changes the name to what it should have been in the first place seems messy to me, no reason to have two commits when one will do.

Git makes it soooo easy! Thank you Git developers!

Move the file, commit that change (and only that change), stash the unstaged changes, interactively rebase to squash the name change onto the creation of the patch, pop the unstaged changes off the stash buffer, and continue with my DocBook updates!

$ git mv incorrect-name.patch correct-name.patch
$ git commit -m "Corrected name"
$ git stash
$ git rebase -i HEAD~2
$ git stash pop

And to think I use to administer a Subversion server and tell everyone how great that was... :)
Read More
Posted in git | No comments
Newer Posts Older Posts Home
Subscribe to: Posts (Atom)

Popular Posts

  • Downsides and Upsides of Altera's Configuration Via Protocol
    Yesterday, I wrote a little about reconfigurable FPGAs attached to the PCI-Express bus as an addition to the general purpose computer. The...
  • Toolchain, Check! Kernel, Check!
    I've been working on the CLFS embedded book for a few months now.  I've been learning a lot and my goal has been to get a CLFS embe...
  • KDE4 Sucks
    I upgraded to Debian 6 Squeeze last weekend on my desktop.  I was very excited to get some more up-to-date packages (git, gcc, kernel, and c...
  • Low Cost ARM Computer
    I was thinking about my ARM + FPGA computer idea some more.  There's already a lot of competition in the single board computer space an...
  • Crypto Load Balancer Using Off The Shelf Hardware
    At my day job, I work a reasonable amount of time with cryptographic and authentication systems. Lately, I've been reading about OpenCL...
  • Embedded Linux and Long Term Support / Updates - Part 2
    In my previous post about embedded Linux long term support, I neglected Ubuntu. I had not realized how much effort Canonical are putting i...
  • The TuxedoBoard has a Brain! (picked out)
    I've chosen an ARM SoC (system on chip) for the TuxedoBoard! The Texas Instruments AM1707 ARM9 core will meet my requirements. The AM1...
  • Pick an ARM ABI When Building GCC
    If you follow the CLFS embedded book for ARM , you'll see that your ABI choice isn't used until compiling packages (ie: after you...
  • SanDisk iNAND
    I stumbled upon SanDisk's iNAND products today while doing some searching about SD cards. The iNAND idea looks very appealing to me co...
  • I'm Writing a Book
    I'm writing a book about embedded Linux but I'm not going to compete with traditional technical books.  O'Reilly isn't my co...

Categories

  • beagleboard
  • blog
  • book review
  • business
  • c
  • chairs
  • clfs
  • community
  • computers
  • crypto
  • db
  • debian
  • disapointment
  • embedded
  • energy
  • fedora
  • flash
  • fpga
  • gcc
  • git
  • google
  • health
  • hp
  • internet
  • iOS
  • learning
  • license
  • linux
  • market
  • microsoft
  • movie review
  • my book
  • next steps
  • open source
  • pandaboard
  • rails
  • software
  • SOPA
  • tuxedo
  • web 2.0
  • webOS
  • windows
  • work

Blog Archive

  • ►  2012 (10)
    • ►  January (10)
  • ▼  2011 (70)
    • ▼  December (10)
      • NameCheap and SOPA
      • Set The World On Fire
      • BeagleBone Debian Squeeze armel Multistrap Config
      • BeagleBone Boot Time
      • BeagleBone Booting Debian Squeeze!
      • Format an SD Card with 8 MiB Aligned Partitions
      • ROC The Day!
      • SanDisk iNAND
      • BeagleBone Hardware Desire - USB & FTDI Power Inde...
      • BeagleBones Arrived!
    • ►  November (9)
      • Dithering, NVIDIA Quadro 1000M, and HP ZR2440w
      • Google AdWords - Gone
      • Google's New Look - It Sucks
      • Debian 6 amd64 on HP Elitebook Workstation 8560w
      • Embedded Linux Long Term - Part 3
      • Build the PandaBoard or BeagleBoard-xM x-loader on...
      • The BeagleBone!
      • Bootstrapping Fedora for ARMv7 Hard Float
      • Calendar Interface
    • ►  October (7)
      • New Beginnings
      • Management and Leadership - Startup versus Establi...
      • Embedded Linux and Long Term Support / Updates - P...
      • An Unknown Error Has Occurred
      • Embedded Linux and Long Term Support / Updates
      • More Raspberry Pi
      • TI AM170x Booting Annoyances: Take 2
    • ►  September (8)
      • SD Card Depot Why Don't You Exist?
      • TI AM170x Booting Annoyances
      • Some Raspberry Pi
      • Google Search Results!
      • Do What You Love, Good Things Will Come
      • Database Class Notes
      • Hewlett-Packard, WebOS... RIP
      • Stanford Database Class and an Experiment
    • ►  August (1)
      • Introduction to Verilog
    • ►  July (3)
      • Downsides and Upsides of Altera's Configuration Vi...
      • Modular FPGA Accelerated Computing
      • Function Pointers
    • ►  June (3)
      • Crypto Load Balancer Using Off The Shelf Hardware
      • Conan's Dartmouth 2011 Commencement Address
      • The Standing Desk
    • ►  May (3)
      • Install the HP webOS SDK on Debian 6 Squeeze
      • Expectations and the i.MX53 QSB "Lab" Session
      • The TuxedoBoard has a Brain! (picked out)
    • ►  April (8)
      • Picking an Open Source Hardware License
      • TuxedoBoard BGAs and Minimum Ball Pitch
      • TuxedoBoard SoC Selection
      • I Dub Thee, TuxedoBoard
      • More Open Source Hardware Ramblings
      • Free IP Block Boards?
      • The Freescale i.MX53 QSB Looks Neat
      • Git is Cool!
    • ►  March (4)
    • ►  February (5)
    • ►  January (9)
  • ►  2010 (16)
    • ►  December (6)
    • ►  November (9)
    • ►  October (1)
Powered by Blogger.

About Me

Unknown
View my complete profile