Re: Good ARM board for Debian?
On 12/23/2013 2:27 PM, Luke Kenneth Casson Leighton wrote:
On Mon, Dec 23, 2013 at 4:09 AM, Jerry Stuckle <jstuckle@attglobal.net> wrote:
On 9/26/2013 5:13 PM, Jerry Stuckle wrote:
Hi again, all,
Well, it looks like for several reasons the RaspberryPi won't work for
this project. Can anyone recommend other ARM-based boards which run
Wheezy well?
This is going to be a used as a monitor/controller, so major speed isn't
a factor. It will mainly be using SPI and GPIO ports, plus ethernet for
communications. Other things like graphics, USB ports, etc. are not
important for this project (but their presence doesn't rule the board
out).
Also the ability to run their ARM version of Wheezy under QEMU is
important for development.
I appreciate any recommendations.
TIA
Jerry
Let's try this again. I'm still looking for a good ARM board for Debian. I
thought the Olinuxino A10s board would work until I found out recently that
Allwinner has stopped making the SDK as of last February.
ignore that. it's irrelevant. unless you're ordering 100k+ units
you'll never get direct support from allwinner, they're overloaded as
it is. you're using completely the wrong criteria.
It is completely relevant when you are talking a commercial product.
When the manufacturer stops creating SDKs for a chip, chip EOL is not
far behind.
you _should_ be asking the question "how long will the sunxi
community support the A10s" and the answer to _that_ will be "as long
as there are people using them". not "as long as allwinner is doing
an SDK" - fuck the SDK: it won't help you anyway.
Commercial products cannot depend on community support. It is too
unreliable.
And such language is completely uncalled for.
what you *should* be asking is, "what's the lifetime of the A10s
processor" and "can i buy as many as is needed, for as long as is
needed".
The lifetime is obviously limited.
also you should be asking "can i get a replacement within the
expected lifetime of the product i'm putting out the door?"
Replacing the processor in existing boards will require redesign and
possibly different software. Both are a cost the client would rather
avoid in the near future by not picking a SOC that is near EOL.
and the answer to _that_ depends on the volume you're going to be
ordering. if it's "quantity 1" then for fuck's sake just get an A10s
and be done with it :) if it's "quantity 10,000 over a period of say
7-10 years" then you've flat-out ZERO chance of getting ANYTHING, with
the possible exception of Freescale iMX products, which have a
guaranteed production life [as long as freescale stays in business
that is].
They won't even tell me the quantities they expect to need (I'm only a
consultant, after all). But my guess would be some orders of magnitude
higher than what you guess. But I did check out Freescale, and didn't
find anything meeting the requirements.
so if you wait - as you've been doing - the products will go
end-of-life on you, and you're screwed. if you buy into one system
you're screwed, because you don't know when they'll go end-of-life.
if you buy long-lived products you're _still_ screwed because a) they
cost more b) this is a volatile market where one minute a planned
product (e.g. iMX7) is to be cancelled and the next minute it's on.
We have not been waiting. There has been active development aimed at
the A10s board. However, the solution looks to be no longer viable. At
least we found out now, not after we had started shipping.
... there _is_ a possible solution which solves this conundrum, as
long as you're happy to get a base-board made up which satisfies the
SPI requirement [or do
whatever-you-wanted-to-do-with-SPI-in-a-different-way], and that's to
get an EOMA68 CPU Card. the first one in the series uses an allwinner
A20 CPU. details and links here:
http://eoma68-a20.qimod.com/improv.html - if you would like an order
code that will get you to the front of the queue please contact me
off-list for instructions.
The chipset we are interfacing to is SPI, so that's not an option. It
would be too difficult to try to do it reliably in software. And while
this board looks nice, it's way too expensive for this project.
the advantage of the EOMA68 standard is that it *doesn't matter* what
the CPU is. as long as you stick to the standard (in the design of
the base-board) you can continously upgrade the CPU Card on a rolling
basis. EOMA68 was designed with at least a decade of lifetime in it,
in order to provide stability in markets where a single Soc can shine
for 6 months and even cause major recessions in the electronics
industry in china [this has happened twice, now: the most severe was
the introduction of the $7 Allwinner A10 when all other competition at
the time was around $12 with fewer features].
And every upgrade means different hardware and potentially different
software. It also adds to the cost with unnecessary features for this
project and doesn't support features we need.
No more updates
for Linux, and it looks like this chip is going by the wayside. We need one
which will be around for a while.
tough. you're looking at ARM consumer-grade SoCs. if they're around
for longer than 9 months you're doing well. the only exceptions are
TI and Freescale "long-term" Industrial SoCs.
Not tough when you're looking at commercial products. And there are a
lot of SoC's which have been around much longer than 9 months.
We looked at several boards, including the rpi (problems with the ethernet
interface because it feeds into the USB port, and poor support for
commercial applications) and Beagleboards (lawyers and management don't like
the licensing requirements).
So it's pretty much back to square one. This will be a dedicated system.
Minimum needs are:
500Mhz ARM (faster is better),
512Mb RAM (1GB would be better),
100MB Ethernet,
SD/Micro SD card 4G or greater (a second slot would be nice so one for
software, one for data),
1 SPI,
3-4 GPIO.
Video/USB keyboard/mouse are optional but could be used for development.
Once installed, the system will be remote, accessed by ethernet (TCP/IP).
existing systems: with the exception of SPI the EOMA68-A20 CPU Card
would do the job [and that can either be replaced or substituted].
The SPI is a major part of the system, as I indicated.
upcoming SoCs: you might find that the ATSAM5 series fits the bill.
they're based around a Cortex A5. i can introduce you to someone at
atmel if you need more information. the ATSAM5 *just* about fits the
requirements, but fits them very nicely. disadvantage: it's very new.
New is not necessarily bad.
Client would like to keep the cost below $50 US in quantity (i.e. 250-1000).
then the TI SoCs have automatically been eliminated, on price alone.
you'd also be pushing the boundaries on freescale SoCs but there may
be some that are still in the running.
There are some out there. My client could arrange to build their own
boards (in fact they will for some of this product), but that's not
really their emphasis. The boards they will need to build are much
simpler, but they would rather be able to purchase processor boards, if
the price is agreeable.
An advantage would be full details (schematics, board details, etc.) so the
client can have their own boards designed if necessary.
i'm happy to send you privately the schematics of the EOMA68-A20 CPU
Card as long as you don't distribute them, and also point you at open
hardware designs of feature boards, including ones that are GPLv3'd.
which... i might as well do here. here's two extremes: anything in
between is possible. the router's a full-on 4-port gigabit switch
plus VGA _and_ SATA port jobbie. the micro-engineering board (altium
files available at the links below) has been superseded by improv
(which i understand has been GPL'd and is done in KiCAD). improv and
the MEBv1 are *really* basic: just access to the interfaces of EOMA68
via connectors - that's it.
http://hands.com/~lkcl/eoma/router/
http://hands.com/~lkcl/eoma/meb/
more info available if you need it.
l.
The main reason for the details would be if the board is no longer
produced. Things like this have happened in the past, and they don't
want to be left high and dry.
Thanks,
Jerry
Reply to: