<p dir="ltr">I wouldn't even say stripped down.  For me that would manifest as something not working like I expected it to, and so far the only problem I've experienced with my Pi is flaky USB support with some devices, which is pretty well-documented.</p>

<div class="gmail_quote">On Jan 17, 2013 7:13 PM, "Dan Lyke" <<a href="mailto:danlyke@flutterby.com">danlyke@flutterby.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, 17 Jan 2013 16:58:38 -0500<br>
DaWorm <<a href="mailto:daworm@gmail.com">daworm@gmail.com</a>> wrote:<br>
> Can anyone recommend a course, either brick and mortar in the<br>
> Chattanooga area, or online, that covers setting up a system with<br>
> embedded Linux?<br>
<br>
Been there, done that...<br>
<br>
> I'm looking for something that covers the build system,<br>
<br>
A lot of this depends on what architecture you're using. The various<br>
different chip makers have funded click-and-go build systems like<br>
Buildroot for Atmel chips that take care of creating the entire build<br>
environment.<br>
<br>
And for others with more community support, there are just packages you<br>
can apt-get.<br>
<br>
> distro<br>
> choices (if any), device driver development, system startup tasks,<br>
> display/graphics issues, application startup, security, debugging and<br>
> the like.  Something that uses a Arm based dev board, such as a<br>
> BeagleBoard, would be best.<br>
<br>
It has been two years, but my guess is that for boards like that (and<br>
I'll get a chance to verify this with a Pi in a couple of days) you<br>
don't have to worry about drivers unless you want to.<br>
<br>
As far as system startup, the kernel runs /sbin/init (or whatever<br>
you've compiled it to run or passed through in the kernel args), which<br>
on modern embedded distributions is BusyBox based. BusyBox behaves an<br>
awful lot like a lighter weight version of what you're used to, but I<br>
was amazed at how much USB and SD stuff just worked (and for the stuff<br>
that didn't, usually it was a matter of finding the right module name<br>
to give to "modprobe").<br>
<br>
After that, debugging is GDB, security is what you make of<br>
it, /dev/framebuffer will often do what you want or you can put X or<br>
use SDL.<br>
<br>
As I said, I'm a few days out from my Raspberry Pi boards arriving, but<br>
I'm told they run a stripped down Debian, so at that point they may as<br>
well be a desktop machine. Does your projected number of deployed<br>
devices warrant the engineering costs over and above just using the<br>
Raspberry?<br>
<br>
Dan<br>
_______________________________________________<br>
Chugalug mailing list<br>
<a href="mailto:Chugalug@chugalug.org">Chugalug@chugalug.org</a><br>
<a href="http://chugalug.org/cgi-bin/mailman/listinfo/chugalug" target="_blank">http://chugalug.org/cgi-bin/mailman/listinfo/chugalug</a><br>
</blockquote></div>