[Arm-netbook] update to EOMA68 specification [was Re: 5" LCD resolution 800x480 working for EOMA but color problems may exist because of miswire]

[luke.leighton]

On Sun, Nov 10, 2013 at 8:16 PM, joem <joem at martindale-electric.co.uk> wrote:
>
>> Hmmmppp...... The is another outstanding issue that needs resolving
>> before the next batch goes into production - this time to do with the RS232 RX line.
>> When connected, the entire board is able to power up through the RX line.
>> The cubieboard1,2 and iteaduino plus and EOMA-A20 boards all have same defect
>> because I assume all of them were designed and tested by the same engineering
>> team from Wits with no peer review input onto the process.
>
> |  ... well, the schematics for the EVB and also the schematics for the
> |GPL-licensed EOMA68-A10/20 CPU Card have been publicly available for
> |nearly two years.  unfortunately we've not had you around until
> |recently joe... *rueful*...
>
>> If you are doing another batch, make sure the CPU board RX line doesn't
>> power up the entire board through that line.
>
> | not going to happen, for exactly the same reason that the RGB/TTL
> |lines are not going to be modified: it's too late.  the PCB design
> |went out to the factory over two months ago when the first 30 samples
> |were made, and the gerbers cannot now be changed.  a) it would make
> |the factories nervous (no way we're doing that) b) someone needs to
>
> Don't believe in such things. Most good factories are only too glad
> to help down to the wire. I've changed stuff after 1st day of production.

 joe you're not listening.  the scale of the production facilities
we're dealing with is enormous.  at their *current* capacity our
client is capable of making *TWENTY MILLION* CPU Cards PER WEEK.
there is flat-out absolutely zero chance that we will be telling them
"sorry we made a mistake, we have to change what we're delivering".
our reputation would be immediately destroyed.

> | so - no. no changes to the CPU Card.
>
> If its gone to production, it not end of world.

 joe - you're not listening.  this is the first CPU Card.  it's a
MODULAR system.  it's too late.  there will be no changes.

 if however this was a single-board system you would be absolutely
right.  it would be perfectly reasonable to just go and redesign the
next release of the PCB.

 ... but this isn't a single-board system, is it?


> Just more revisions are due next batch.
> The revision to fix RX line problem will likely be transparent
> to end user.

 no it will not.  think it through.  there's due to be a batch of 2500
CPU Cards followed by another batch of 10k.  these two batches are the
ones that cannot be modified.

what then happens if any one of those 12500 CPU Cards is plugged into
an I/O board that doesn't have the RX line-protection?

the venn diagram is as follows:

cpu card Rx-fixed  IO board Rx-fixed   combination OK
n                         n                           N
y                         n                           Y
n                         y                           Y
y                         y                           Y

can you see, using karnaugh mapping, that "fixing the CPU Card" is
completely and totally irrelevant?  the CPU Cards *have* to go out
without UART-RX being fixed [for reasons already stated].  the I/O
Boards therefore *have* to go out with UART-RX hardware fixes.

therefore "fixing the CPU Card" *afterwards* is not only completely
irrelevant but is also *dangerous* because it will give I/O board
developers the false impression that they do not need to take care of
the problem.

and if that ever happens they're f*****d.

so it has to be the way that i've said it has to be, for the reasons
that i've already stated that it has to be.  i've looked at all the
options: this is the only option.  therefore we go with it.

> Learn from this - always make in batches of 10 to iron out problems.

  the circumstances are different.  30 samples or 10 samples, it
doesn't make any difference: one of those went to our client.  due to
the number of fuck-ups that have already occurred (from using Wits
Tech) there was absolutely no way unless it was yet another serious
fuckup that we could say "i'm sorry, we have to make some minor
changes".

 if we did not have such large clients, or if we did not have a
modular system, matters would be entirely different.

 so - there's a solution: that's what we go with for the next 10
years.  end of story.

l.