Hello Team Balloon!

I want to say "Thank you" to you all for the work you've put into
creating the Balloon board and the software ecosystem that supports
it.  I wish I could do more to support the project, but for now, the
best I can do is to give you all a heartfelt "THANK YOU" and to toss
back miscellaneous bugfixes as I find them.

It can be lonely sometimes being a geek -- there are so few people who
understand our joys.  Since some of you seem to be the sorts who
understand these sorts of joys, I thought I would share my Balloon
board success stories from the past month.

I got my board a month ago (a month ago today, in fact) after much
eager anticipation.  (I wonder... who else understands "eager
anticipation" for a PCB with a PXA270, a Spartan3, some NAND flash,
some NOR flash, some SDRAM, an audio codec, an RS232 level shifter,
and a bunch of connectors? ... Especially anticipation by somebody who
had absolutely no involvement at all in the design of that board.)
After a certain amount of struggle with USB<->RS232 adapters, I was
able to reliably connect to the board and transfer data to it.  I
should mention that I don't have any sort of breakout board for my
BalloonBoard (yet), so no USB connection; and that I live in a
self-induced less-than-ideal development environment.  I do my
development on a Debian VMWare machine running on my MacBook.  A lot
of the USB<->RS232 adapter problems I encountered were due to this
less than ideal environment.

Anyway, the first thing I did was to substitute my minicom/kermit
connection (from a MacBook terminal prompt) for a PPP connection to
the board.  I figured out enough BSD/Apple OS X to set up NAT on that
connection and gave myself the ability to SSH into the board (from my
Debian VM) and for the board to get out to the Internet (with a
capital "I").

Thank you HW development team for designing this board.

With that set up, I can now do things like:

balloon# apt-get install openssh-client

...and have the board go out to the Emdebian grip repository, download
and install OpenSSH, and set up .ssh/config files (and keys) so I can
get from my development board to various servers I need to get to.  I
can also do:

balloon# apt-get install ntpdate

... and now, each time I boot the board and fire up the PPP
connection, I can do:

balloon# ntpdate us.pool.ntp.org

... and not have to deal with timestamp issues and/or manually typing
in the date each time I boot the board.  (Yes, I know I could probably
set up an if-up script to do this automatically.  So far it hasn't
been an issue.  I need to type 2 commands to bring up the PPP link
instead of 1.)

Thank you Emdebian team (and Debian team) for giving me a decent
starting rootfs and the ability to go grab some of my favorite
packages and use them easily on the board.  (Did I mention I've now
got Emacs on the board?  A simple 25 or so minute apt-get while I was
busy working on other stuff).

Once I had my PPP link up and running (BTW, I've started some notes on
the Wiki showing how I did that -- see
http://www.balloonboard.org/balloonwiki/pppSetup), I turned my
attention to downloading new FPGA images to the board.  (Many of you
know this from my various email flurries).  I don't need to update the
FPGA image while running my target application, but since I have the
PPP link, it just seemed like it would be easier to transfer new
images to the board and write them to the NOR flash from within the
Linux environment, rather than dropping back to bootldr (and back to a
kermit/minicom prompt in a MacBook terminal) just to transfer the
compressed image.  Did I mention that SSH can be configured to
compress its data stream on the fly?  Did I mention how easy it was
for me to bring up an SSH client on the board?

Enabling writes to the FPGA partition in the NOR flash was as easy as
enabling the MTD_PHYSMAP module (as a loadable module not as a
compiled in module) and modifying the 'balloon3_nor_partitions[]'
array in "arch/arm/mach-pxa/balloon3.c".  Now I can download a new
FPGA image and simply write it to /dev/mtdblock6.

In fact, since I've installed the Xilinx tools on our server (locked
in a closet somewhere in the basement of our building), each time I
generate a new FPGA image, I can do something like this (Note -- from
the Balloon board!):

balloon# scp -C server:path/to/image.bin image.bin

balloon# cp image.bin /dev/mtdblock6

...reboot the board, log in, (type the 3 commands to bring up the PPP
link and set the date/time), and test the new image.

Thank you Balloon board kernel developers (and Linux developers
worldwide) for making this as easy as it was.

Interestingly, although the tools run faster on the 16-core server in
the basement than they do on my dual core MacBook, it's only a factor
of 2 to 3 times faster.  Still, a 10-15 minute compile wait (when
I've enabled the full FPGA image) is much better than a 30 minute
compile wait.

So, now I've got a new FPGA image on the board.  I would like to
interact with that image.  I don't really like the 3-5 minute download
time it takes to transfer a new kernel (and set of modules).  I would
rather write a user space driver.  After all, right now, I only need
to be able to read and write to some registers in the FPGA, possibly
wait for an interrupt someday.  It turns out that the "uio" driver in
the kernel handles all of this for me.  In fact, the "uio_pdrv" driver
makes this even easier.  (And, when I'm ready for that interrupt, I
anticipate that the "uio_pdrv_genirq" driver will make that task
easier as well).  I wrote a module with 3 structures and 2 lines of
code (module_init and module_exit) and I was talking to my FPGA.
(Well, I was talking to my FPGA once I stomped on those pesky bugs
that crept into my FPGA code).  I'll try to write this up on the Wiki
as well, hopefully sometime this weekend.

Thank you again team!

I have been doing embedded hardware, software, and DSP development for
25 years.  I am typically the first person in the universe to run some
software on a newly designed board.  I have ported real time kernels
to new boards and new processors in the past.  But this is my first
real experience with embedded Linux (although I have been a Linux
enthusiast since 1995 and been referred to as a Unix "guru" since 1986
or so).

I have to say... this is the most fun I've had working on a new (to
me) board.  Thank you once again for the work you have all put into
this.

I'm going to stop here before I get too mushy.

--wpd