Brad For Dem Bedded

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

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)
    • ►  November (9)
    • ►  October (7)
    • ►  September (8)
    • ►  August (1)
    • ►  July (3)
    • ►  June (3)
    • ►  May (3)
    • ▼  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