[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Good ARM board for Debian?



On Tue, Dec 24, 2013 at 1:07 PM, Dale Amon <amon@vnl.com> wrote:


> However many of us who are silent have found this to be
> one of the more interesting discussions on the business
> and industry of SoC that have come along in a very long
> time. Definitely a high S/N.
>
> I say this as someone in early stages of an aerospace
> product development.

 ok, so after a little bit of thought, it occurred to me that there
may be others who would benefit from continuing the discussion rather
than attempting to get jerry to correct some of his assumptions and
stop making judgements.

 one of the mistakes that jerry's made was to assume that a board with
a higher component count would automatically be more expensive than a
lower component count board.  the pricing is critically
volume-dependent.  in cases where the boards are ordered in 100k+
volumes (which would be reasonable to expect in a product that's
designed around a mass-volume strategy), there are several advantages:

 1) the factories can typically subcontract and ask ODMs to absorb the
NREs of development.  especially if the factory is PRC
State-Sponsored.  a written letter placing an order for 200k units -
even ones that haven't even been designed yet - is as good as cash.

 2) tape and reel typically comes in quantities of 2500 (or so).  it's
only in europe and the west that you can buy "part-reels" online.
typically from companies such as mouser, digikey, arrow etc.  the
markups for doing so are usually between 300 and 1000%.

 3) ordering 250 or even 1000 units therefore ends up with *massive*
component wastage.  or huge storage costs.

 4) below 1000 units it's just not worth any factory's time to set up
automated assembly: it takes too long to set up and tear down.
therefore when you get quotes for 100 units you find that the labour
costs bring the costs to pretty much the same as 1000 units.

 the EOMA68 strategy is designed to take these factors into
consideration.  by taking advantage of huge amortised bulk-buying
during the high point of any one SoC's lifetime, not only are the NREs
drastically reduced but the production runs are longer and,
potentially, if the volume is large enough, actually end up
*extending* a SoC beyond its anticipated EOL.  overall, the cost ends
up being lower - MUCH lower - despite the possibility of there being
several components (such as HDMI, Micro-SD or USB-OTG) which may not
have been part of the initial requirements when compared to a
single-board design.

 so, the scenario that jerry's looking at is one where the NREs to
create a custom 6-layer PCB would be somewhere around... $USD 20k to
$30k, PCB printing and population of 2 samples would be around $1500
per revision of the PCB, and the cost of the system would (depending
on complexity and peripherals) typically be somewhere around let's say
$25 in 10k volumes, what with all the production NREs being amortised
over that 10k volumes *BUT*, if only 1,000 units were required, those
NREs would probably lift those prices to $40 or even $50.

by contrast, let's say that a mass-volume module is used instead.  a
custom 2 or 4-layer carrier-board PCB would be somewhere around... $5k
to develop, PCB printing and population of 2 samples would be
around... $1000 per revision of the PCB, and the cost of the system
would (assuming the same functionality) probably be about the same in
10k volumes.  if only 1,000 units were required, however, then because
the module was mass-volume and effectively just a component, the only
NREs affecting the pricing would be those of the carrier board which,
as it was a simpler design, would potentially be lower.  pricing could
well be around $5 less than a custom board, at the lower volumes.

the other mistake that jerry's made is in not asking about the plans
to put SPI on the EOMA68 interface list.  he's dismissed the board
based on a judgement without checking the facts.

i trust that others may find this useful and insightful information,
as it's challenging enough as it is to put debian onto ARM-based
systems, without having to custom-port the OS to every single piece of
hardware (not just a SoC).  how many times have people asked - just on
this mailing list alone in the past year - "please can you advise me
how to get debian onto my {insert piece of low-cost hardware i bought
off the internet}"?  i've lost count!  but every time we've had to
patiently advise them, "i'm sorry but you're looking at a
reverse-engineering effort" or "i'm sorry but you'll need to run a
chroot under android unless you're happy to do reverse-engineering".

i leave it at that.

l.


Reply to: