[Arm-netbook] "[EOMA68] RFC: ADDITION OF SD/MMC TO STANDARD."

[joem]

On Mon, 2013-12-23 at 22:16 +0000, Luke Kenneth Casson Leighton wrote:
> On Mon, Dec 23, 2013 at 10:08 PM, Christopher Thomas
> <christopher at firemothindustries.com> wrote:
> >
> >
> > Sent from my iPhone
> >
> >> On Dec 23, 2013, at 3:48 PM, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> >>
> >> i'm giving serious consideration, even at this late phase, to adding
> >> SD/MMC to EOMA68 by way of the GPIO pins as a multiplexing option.
> >> this would not have any impact on the EOMA68-A20 CPU Card: in fact,
> >> the only reason this can be considered at all is because the pins
> >> *happen* to be multiplexed as SD/MMC and GPIO *anyway*.
> >>
> >> does anyone have any objections, and/or can think of any gotchas which
> >> would prevent SD/MMC from being added as a non-optional multiplexed
> >> option to EOMA-68?
> >>
> >
> > How many of the 8 GPIO would essentially be used? (I presume 6?)
> 
>  yes, 6.  it's no change - literally - of the EOMA68-A20 CPU Card.
> the pinouts happen already to be multiplexed to SD/MMC (just at
> present in "non-EOMA68-compliant" mode).  the change would be "it is
> now mandatory that the following pins be multiplexed on GPIO [1]:
> 
> GPIO-0: SD0-D3
> GPIO-1: SD0-D2
> GPIO-4: SD0-CMD
> GPIO-5: SD0-CLK
> GPIO-6: SD0-D0
> GPIO-7: SD0-D1
> 
> l.
> 
> [1] from http://rhombus-tech.net/allwinner_a10/orders/ - the section
> on "Features".  these pins were originally selected because they have
> a secondary multiplex functional mapping to JTAG, but also because of
> the *tertiary* multiplex functional mapping to SD/MMC.


My thoughts were to add an high pin count 
FPC somewhere to get more pins out
than limit the box to 68 pins.
This problem is going to hit the box a lot
of the time.

(My interest is embedded applications - so higher pin count
is more flexibility.)