I assume you are talking about Balloon 3 as Balloon 2 does not strictly have
a SAMOSA bus.

On Balloon 3 the SAMOSA bus is separate from the CF socket.
The CF socket shares data and address with the backplane (available over the
Samtec connector (large 200 way connector on the back)).

There is no conflict between CF and backplane because the PXA treats the CF
as a separate bus with dedicated control signals (typically labelled
PCMCI_xxxx or CF_xxxx).

The "Wired IO" board under development has Ethernet and VGA and USB breakout
and MMC support (basically making the Balloon a thin client).
This is now partly working and the hope is to deliver this at the same time,
or very soon, after the first production run of Balloon 3.

This is all added via the Backplane bus.

There are a number of different ways to get at IO on Balloon 3, depending on
how much effort/skill you wish to apply.

a) Use the SAMOSA bus. This can be used as a word bus with muxed address
latches (actually this is a NAND FLASH type bus) and is typically used to
access registers on a product motherboard where the backplane (Samtec) is
not fitted or used. Alternatively the SAMOSA connector can easily be
refactored inside the FPGA to provide dedicated IO lines either from
registers or VHDL engines in the FPGA. Since the SAMOSA connector is fitted
top side this will always be available even on CPLD one side builds.

b) Use the Backplane bus and build a dedicated board. Here you will need to
provide IO drivers and hardware, but this is highly flexible.

c) Use J9 which provides some direct IO from the processor provided you
don't need the dedicated IO devices that are allocated to it.

Ironically the FPGA we are fitting has far more IO pins than we have space
to route so there are quite a few IO lines from it that just terminate on
vias from the FPGA ball array. I am in the process of laying out the final
production version of the board and one task is to see if there is any way
to expose these sensibly, but don't hold your breath...

I will also publish the schematic for the Backplane interface and the
associated blank motherboard. These will be in Protel format but have the
advantage that a real board has been made from them and so the bug level is
lower.

Finally you ask about on-board Ethernet. There are good reasons not to do
this in the next rev. One reason the Balloon format is so nice is that there
are no large connectors eating up board space. Because there are reasonable
constraints on the layout and routing of Ethernet line signals (potentially
240v and high speed) from the driver chip to the transformer and on to the
massive RJ45 connector the addition of on-board ether will eat a very
significant fraction of the Balloon board real estate, not to mention the
vast increase in board height and the limitations on placing the Balloon
board in equipment cause by having the Ethernet connector in a fixed
location.

For all these reasons the Ethernet will be provided via an attached IO board
so that people can refactor the location and fit of the massive connectors
we have inherited from the 1990's. (Rant over :-))

Given that the design phase of Balloon 3 is now effectively over we are
starting to think about Balloon 4. So Suggestions are welcome...
Please also bear in mind that we *may* move away from Marvel as the core
processor vendor given that their documentation is not freely available and
it looks a bit odd having an open hardware project where the information
about the core processing element is not openly available.

David Bisset
MD Balloonz

-----Original Message-----
From: balloon-bounces@balloonboard.org
[mailto:balloon-bounces@balloonboard.org] On Behalf Of Peter Clifton
Sent: Thursday, January 24, 2008 3:22 PM
To: balloon@balloonboard.org
Subject: Re: [Balloon] Balloon 3 FPGA code?

On Thu, 2008-01-24 at 14:12 +0000, Peter Clifton wrote:
> Hi,

> I've been looking at the pin-out documents, and don't see many (if any)
> uncommitted lines, then again.. I'm not really following Chris Jones'
> documents that well.
> 
> Ethernet is a real desire, so I'd not like to re-use any data-lines
> which would stop the CF socket working. USB would be nice to have, but
> if any other features could be sacrificed in exchange for more IO, that
> would be something I'd consider.

Moving away from the Samtec pinout and looking deeper at the schematic,
I see that the samosa bus might be useful for my application.

I'd started to think that the D0-31, A0-24 lines on the Samtec were
pretty much uncommitted, but I now note they are the same data-lines
used by the CF socket.

Can anyone who's constructed motherboards or accessories for the
Balloon comment as to how extra functionality such as Ethernet
controllers are added, and what IO pins are used? I realise can't share
in my application (I need control over the line), but can the address
and data lines of the CF socket be shared with other addressed and
chip-selected devices?

In the future, I'd really like to have on-board Ethernet, so if most
Ethernet controller chips require a good complement of address + data
lines, perhaps I'll be stuck using the number of signals on the samosa,
even if I can fore go support for the compact flash socket.

Are there any schematics or design documents for motherboards I could
look at?


Best wishes,
-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)


_______________________________________________
Balloon mailing list
Balloon@balloonboard.org
http://balloonboard.org/mailman/listinfo/balloon