Re: [Balloon] Getting Started with BalloonBoard

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Nick Bane
Date:  
To: balloon
Subject: Re: [Balloon] Getting Started with BalloonBoard
see usbnet+RNDIS opinion below
> +++ Patrick Doyle [2011-04-11 12:49 -0400]:
>> Can anybody point me at a "Getting Started with BaloonBoard" resource?
>
> It sounds like you've found most of it. Exactly what is most
> appropriate depends on what you are trying to do. (fill up a new board
> with code vs. talk to a pre-programmed board with a serial port, vs.
> programming the ASIC)
>
>> As background, I would like to use a BalloonBoard as a testbench to
>> control a custom ASIC. I have a pile o' Verilog code that I use
>> currently in simulation for testing the ASIC. I would like to drop
>> that code into an FPGA and control it with an external processor. I
>> would also like to talk to that external processor from some desktop
>> (or laptop) PC.
>
> Cool, relatively few people have made serious use of the ASIC
> functionality, so any action on that front would be great.
>
>> I've poked around the wiki a bit and have learned a few things.
>>
>> 1) It seems that I can plug into J14, apply power& ground, and talk
>> serially to the board.
>
> correct
>
>> -- as an aside, http://www.balloonboard.org/balloonwiki/Software
>> states that I need to apply power via "the main molex connector
>> J10,..." I believe that should be "J14" (at least according to the
>> schematics).
>
> Yep. I think you're right. Fixed. (do feel free to fix up such things
> yourself - it's a wiki)
>
>> -- as another aside, is the BOM for the BalloonBoard online anywhere?
>> It would be much simpler for me to look up J14 on the BOM and find the
>> mating connector at Digikey than it would be to try to guess what
>> "PH200_4WAY_RT" means.
>
> There is this:
> http://balloonboard.org/hardware/300/Loon3_Manufacture_0V1.zip (from
> the 'Hardware' page) But I see that just specifies PH200_4WAY_RT anyway.
>
> You'll get one of those with a loon anyway, but yes we could usefully
> provide more info on that sort of thing.
>
>
>> -- as yet another aside, for any security folks who happen to be
>> monitoring this email, "BOM" refers to "Bill of Materials", and not
>> homophones that might come to mind when pronouncing it out loud. I'm
>> not even going to touch "Pinko connector" here.
>
> :-)
>
>> 2) It would be nicer if I could plug a USB cable into the board, plug
>> the other end into a PC and speak TCP/IP to the board from a random
>> Windows based PC. Does the USB OTG or USB client work well enough to
>> do this? Does Windows support this (via USB "gadget" or some other
>> other mechanism).
>
> Yes, that works, but there are complicated if's and buts about doing
> this on Windows as opposed to Linux (where it's easy). You used to
> have to rebuild the USB ethnet gadget with RNDIS support on for
> windows, and off for linux, but I _think_ that's sorted in latest
> kernels. I just can't remember if pxa270 limitation means it can;t
> take advantage of the fix.
>

The "ifs and buts" are due to middle-to-old linux kernel problems when
using the combined CDCSimple+RNDIS variant. Older kernels (erm 2.6.25-ish?)
mis identify the USB id when not from a Strongarm SA1110 and defaults to a
zaurus implementation that adds a checksum to the packet making it borked.
There is a kernel patch incl Kconfig option that forces the gadget driver
to mis-identify itself as being an SA1110 to overcome this defect. Its a
horrible but useful kludge. This made a waoring solution under XP. I gather
that it also works with Vista. I tried recently on Win7 Ultimate and Win
config seemed ok as well as usbnet working fine. However, the Win7 system
seemed to have some trouble establishing a good link and I stopped prodding
it. I guess that its either actually ok or very nearly ok and may need some
review. I note that Win7 provides a driver. It might be deliberately broken
of course ... ;-)

>> 3) It just dawned on me yesterday that the FPGA on the board might be
>> required for correct operation of the board and that I may not be able
>> to program it with my own arbitrarily custom code. Can I put
>> arbitrarily custom code in the FPGA?
>
> Part of it is used for flash access and the somosa bus and a few other
> bits of logic, so you do have to be a bit careful putting your own
> code in. However the board-support stuff is logically separated in the
> build system, so it's not hard to put inyour own dollop. The main
> limitation is actually available pins - you need to work out which
> bits of functionality you want to sacrifice. Normally the 16-odd pins
> of the samosa bus are a good target to dedicate to your private FPGA
> interface bits.
>
>> 4) I read in 1.0-stable/vhdl/README:
>>
>> You are strongly urged to read "L3 Hardware" before altering these files
>>
>>      where would I find the "L3 Hardware" document?

>
> In here: http://www.balloonboard.org/files/balloon3/distro/test-v0.1/docs/
>
> (under a different name - but I think one of those corresponds). And
> yes that was almost entirely undiscoverable. Those docs need linking
> from somewhere useful (and updating!)
>
>> -- BTW, http://www.balloonboard.org/balloonwiki/BalloonFPGA says that
>> the FPGA code can be found at:
>>
>> $ svn checkout svn://www.balloonboard.org/balloon/trunk/vhdl/ balloonboard-vhdl
>>
>>      Some spelunking suggests that it might really live at:

>>
>> $ svn checkout svn://www.balloonboard.org/balloon/balloon/tags/1.0-stable/vhdl
>
> There are snapshots in those
> http://www.balloonboard.org/files/balloon3/distro/
> dirs
> and 'latest' in
> http://balloonboard.org/trac/browser/balloon/trunk/package/vhdl
>
>> I'm happy to sign up for a wiki account and make these changes as I
>> find them. Is there some sort of review process that will ensure that
>> I don't change them incorrectly and thus direct people in the wrong
>> direction?
>
> No, we assume that anyone interested enough to change things in here
> has a reasonable idea of what they are doing. A fresh eye is always
> very useful, because that finds the glaring omissions.
>
>> 5) Assuming I can place my own code in the FPGA, can anybody point me
>> at an example of using the FPGA to do something simple, say blink an
>> LED or something, by running code in userland on the processor,
>> communicating with the FPGA via a device driver (perhaps even
>> something as simple as opening /dev/mem and writing to registers via a
>> memory mapped interface)? What if I wanted something a little more
>> complex than that with interrupt generated events?
>
> There is a ledblinck example for using a GPIO directly off the board.
> For doing FPGA reality checks you need someone hardwarier than me. The
> 'wishbone.vhdl' stuff is intended as an example of putting in your own
> module, I beleive.
>
>> Thanks for any tips and pointers folks can give me. I am asking all
>> of this in the spirit of "If I don't ask, I won't find out" and not in
>> the spirit of "can you do this for me". If I designed the board
>> myself, I'd have to do all of this myself. If other folks have done
>> this already and it's just a matter of finding the right pages in the
>> wiki showing what they've done, I'm glad to stand upon the shoulders
>> of giants and learn from them/you.
>
> Yep, that's how it's supposed to work. We've used the FPGA for
> on-board stuff and the samosa bus implementation, (and CJ put a 1980s
> arcade machine pacman implementation on it once (video essentially
> straight off the FPGA - very cool), but that's about it, and nothing
> much is documented on that front beyond what you've found (and those
> docs in the test-v0.1 release (whcih will help).
>
> So please ask lots of questions, then write down the answers in a 'how
> to use the FPGA page' :-)
>
> Wookey