Discussion:
[Arm-netbook] "[EOMA68] RFC: ADDITION OF SD/MMC TO STANDARD."
Luke Kenneth Casson Leighton
2013-12-23 21:48:23 UTC
Permalink
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*.

this would also happen to give EOMA68 an SPI port as well.

the idea came to me because it's something that's been forced on
EOMA-26 due to the small number of pins (26) on EOMA-26.

after looking at dozens of SoCs i don't think i've seen a single one
these days which *only* has a [non-multiplexed] SD/MMC port. even if
there was one that did (at an affordable price), a cross-bar buffer IC
would take care of that.

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?

l.
Christopher Thomas
2013-12-23 22:08:53 UTC
Permalink
Sent from my iPhone
Post by Luke Kenneth Casson Leighton
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?)
Post by Luke Kenneth Casson Leighton
l.
_______________________________________________
arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook at files.phcomp.co.uk
Luke Kenneth Casson Leighton
2013-12-23 22:16:11 UTC
Permalink
On Mon, Dec 23, 2013 at 10:08 PM, Christopher Thomas
Post by Christopher Thomas
Sent from my iPhone
Post by Luke Kenneth Casson Leighton
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.
joem
2013-12-24 08:21:27 UTC
Permalink
Post by Luke Kenneth Casson Leighton
On Mon, Dec 23, 2013 at 10:08 PM, Christopher Thomas
Post by Christopher Thomas
Sent from my iPhone
Post by Luke Kenneth Casson Leighton
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
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.)
Luke Kenneth Casson Leighton
2013-12-24 11:30:08 UTC
Permalink
Post by joem
Post by Luke Kenneth Casson Leighton
On Mon, Dec 23, 2013 at 10:08 PM, Christopher Thomas
Post by Christopher Thomas
Sent from my iPhone
Post by Luke Kenneth Casson Leighton
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
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.
next revision. we need to sell units first. or someone needs to
provide the $10k NREs to be able to have the first EOMA68-A20 CPU card
layout completely redesigned. but even then, an FPC is not going to
be part of the EOMA68 specification because the EOMA68 specification
is a mass-volume specification where the units are sold with a sealed
metal shield around them.

l.
joem
2013-12-24 12:07:08 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by joem
My thoughts were to add an high pin count
FPC somewhere to get more pins out
than limit the box to 68 pins.
next revision. we need to sell units first. or someone needs to
provide the $10k NREs to be able to have the first EOMA68-A20 CPU card
layout completely redesigned. but even then, an FPC is not going to
be part of the EOMA68 specification because the EOMA68 specification
is a mass-volume specification where the units are sold with a sealed
metal shield around them.
What I notice was that the HDMI end has a gap that will allow
an FPC flat cable to be fitted through the gap.
Careful design needed though - tight squeeze to get access
to the ears of the FPC connector to allow cable to be connected
and disconnected without having to open the case.

The alternative is an FPC positioned at 90 degrees
which forces the case to be opened for fitting.
A flexible PCB with 90 degree tracks would be the way to
connect into the EOMA, and only embedded engineer would do it.

A third alternative is to have the PCMCIA case made with a
laser cut slot to allow the FPC cable to be connected.
But that goes against the idea of a well sealed box.
Luke Kenneth Casson Leighton
2013-12-24 12:13:53 UTC
Permalink
joe could you please keep this discussion on topic and limit it to
what the subject line says, thank you. regarding what you've
suggested: that will involve at least $6k NREs for the tooling. it
also will not be part of the EOMA68 standard. an individual board
however in non-EOMA68-compliance mode could have this done.

now - do you have any input at all on what the subject-line is about?
much appreciated.

l.
Post by joem
Post by Luke Kenneth Casson Leighton
Post by joem
My thoughts were to add an high pin count
FPC somewhere to get more pins out
than limit the box to 68 pins.
next revision. we need to sell units first. or someone needs to
provide the $10k NREs to be able to have the first EOMA68-A20 CPU card
layout completely redesigned. but even then, an FPC is not going to
be part of the EOMA68 specification because the EOMA68 specification
is a mass-volume specification where the units are sold with a sealed
metal shield around them.
What I notice was that the HDMI end has a gap that will allow
an FPC flat cable to be fitted through the gap.
Careful design needed though - tight squeeze to get access
to the ears of the FPC connector to allow cable to be connected
and disconnected without having to open the case.
The alternative is an FPC positioned at 90 degrees
which forces the case to be opened for fitting.
A flexible PCB with 90 degree tracks would be the way to
connect into the EOMA, and only embedded engineer would do it.
A third alternative is to have the PCMCIA case made with a
laser cut slot to allow the FPC cable to be connected.
But that goes against the idea of a well sealed box.
_______________________________________________
arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook at files.phcomp.co.uk
joem
2013-12-24 13:33:55 UTC
Permalink
Post by Luke Kenneth Casson Leighton
now - do you have any input at all on what the subject-line is about?
much appreciated.
Anything that improves the overall number of pins, even multiplexed
is a good thing.
Luke Kenneth Casson Leighton
2013-12-24 14:01:01 UTC
Permalink
Post by joem
Post by Luke Kenneth Casson Leighton
now - do you have any input at all on what the subject-line is about?
much appreciated.
Anything that improves the overall number of pins, even multiplexed
is a good thing.
thanks joe. now the only thing to resolve is whether the A20's
SD/MMC can do SPI. it's in the spec [of SD/MMC] but i really need
proper confirmation. then it will be possible to say that the EOMA68
specification supports SD/MMC and SPI.

l.

Loading...