Re: Good ARM board for Debian?
On 12/23/2013 4:23 PM, Luke Kenneth Casson Leighton wrote:
[jerry please read very last paragraph first, thanks].
On Mon, Dec 23, 2013 at 8:11 PM, Jerry Stuckle <jstuckle@attglobal.net> wrote:
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.
yes. the facts here have come out rather slowly. when you initiated
this thread i believe pretty much everyone responded based on an
assumption that you were looking to purchase a single unit for
personal use. only later on (even in this round of questions) and
even later on in the _message_ does it become clear that the
requirements are actually those of a client.
No, this was all detailed in the original posts in this thread. It was
a while ago, I agree. But I didn't see the need to repeat everything.
so we are a bit arse-about-face here :)
we also have yet to established expected product lifetime. is it 6
months, 12 months, 6 years or 12 years? also are product revisions
anticipated? would it be okay to redesign the entire board later on,
using a completely different SoC?
This is a commercial product. Lifespan will be measured in years. A
redesign is not contemplated at this time; the original product still
runs fine; it's just more expensive to product due to older technology.
And the only revisions which may be required would be additional
software features.
When
the manufacturer stops creating SDKs for a chip, chip EOL is not far behind.
then the fact that the majority of chinese ODMs only ever produce one
SDK - usually an incomplete one and almost invariably GPL-violating -
should tell you everything you need to know.
I didn't say anything about using chinese ODMs. I never said anything
was required or out.
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.
i wouldn't say "unreliable" - i'd say that they're just as dependent
on financial support as anyone is. a community is the first place i
would go to look for people to pay to provide *commercial* support.
My 20+ years of experience has shown they are unreliable. Nothing
against the people working there; some are good, others are anal orifices.
They started out wanting to use the Raspberry Pi and asked me if it was
a good idea. A couple of posts in their forums proved it was not. I
won't go into the story here, but my client has no interest in any
community-supported product any more. A shame - RPI could have sold
tens of thousands of units over the lifetime of the product.
and the nice thing is that by taking advantage of those people to
provide commercial support, it strengthens their resolve to continue
to be a community.
if on the other hand you were expecting something for nothing,
without putting them under contract, and without paying them a single
cent, then yes, you could say 100% that you can have absolutely no
expectation that a community would be around or be reliable for the
duration that you would like them to be.
I'm not expecting something for nothing. But I do expect reliable
support when it is necessary. You get this when the support people are
dependent on your purchases. Community support doesn't have this.
And such language is completely uncalled for.
in an informal setting, for emphasis i tend to make sparse use of
swearwords, just like any liverpudlian or mancurian would, in any
conversation. they're intended both for emphasis as well as comical
and theatrical effect. this, after all, is a public forum: a little
theatre and entertainment is... expected :) in a business setting
however i would never use them unless something reaally bad happened.
And this list is also read by young people. It is not an adult-only
newsgroup. Such language is not called 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.
yes.
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
in a single-board monolithic design: yes, you would be absolutely
right. if that's something that the client is prepared to take into
consideration as part of the product lifetime and evolution, that's
great.
in the special case of EOMA68, the answer is NO, the base board will
NOT require a redesign. at all. ever. [caveat: as long as the
EOMA68 specification is adhered to, without deviation]. and the CPU
Cards will be available, and hardware-compatible,
Which once again means a different CPU card. Still different hardware
and potentially different software. It doesn't matter if it's a one or
a two or fifty board design. Just because the case doesn't change
doesn't mean the internals don't.
and possibly different software.
in a single-board monolithic design: that would, if ARM SoCs were
exclusively picked, be pretty much limited to the kernel and the boot
system. however, interfacing to the hardware would be where the
niggles start: GPIO will be radically different on a per-SoC basis (we
know this) and so on.
Plus custom software (which is where I come in). Much of the software I
develop is hardware dependent.
in the special case of EOMA68, those issues go away. firstly there's
a standard way in which GPIO is accessed. secondly, the interfaces
are deliberately restricted such that the base board has to be "CPU
Card independent" - that extends all the way up through the kernel
stack right to userspace, thus, by the time a new CPU Card comes out
all the interfaces are presented in a standard way that *does not*
require significant software changes to interface to the hardware.
But EOMA68 does not mean our needs at several points, as indicated
above. It is out of the running.
Both are a cost the client would rather avoid
in the near future by not picking a SOC that is near EOL.
... where EOL in the case of the low-cost SoCs that the client wants
are *literally* defined in months. not even years.
Not in my experience. They are available much longer than that.
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).
i want subcontractor consultancy fees!
Get me an answer that I can work with and I'll see what I can do!
The chipset we are interfacing to is SPI, so that's not an option.
well, i'm the person responsible for the EOMA68 specification.
you're going to need to give me *really* good reasons why i should, at
this incredibly late phase, add SPI to the specification.
I'm not asking you to. It's not even in the running.
the only reason i'm mentioning that is because it so happens that it
might actually be possible to do, because by a complete coincidence 6
pins of SD/MMC *happen* - in the very first CPU Card - to be on the 8
GPIO pins, via multiplexing. and, as you are no doubt aware, SPI is
backwards-compatible to SD/MMC:
http://pinouts.ru/Memory/sdcard_pinout.shtml
We need a real SPI interface, not something simulated.
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.
those are end-user single unit prices, the improv feature board was
designed by a team who prioritised component selection from USA
suppliers over cost, and it's a limited engineering run.
in sufficient volume the price target the client is expecting is
perfectly achievable.
When that becomes available, if my client is still looking, they may
consider it. But as of right now, it's out of the question.
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.
if you're going to make those kinds of judgements without asking them
in the form of a question then i cannot help you. i have enough to
deal with.
I'm only going by what is documented. If the documentation is
incorrect, you need to correct the documentation.
would you be interested to rephrase these statements in a
non-judgemental and more open way? if so then i can perhaps reply to
them and provide you with insights without first having to completely
contradict everything that you've stated, with the obvious
disadvantage in doing so that i'm made to look like the Bad Guy, and
we get nowhere.
No, I'm going by what the "official" documentation says, and my
experience with dozens of RISC processors over the last 20+ years.
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.
yes, tough. rockchip's offerings and allwinner's offerings are
*highly* successful commercial products. they're just targetted at
mass-volume extremely volatile markets. that doesn't make them
"non-commercial", does it? it just makes them "not in the market
you're expecting them to be". the EOMA68 strategy takes that into
account.
Sure they are, which is why we are considering them.
And there are a lot
of SoC's which have been around much longer than 9 months.
indeed. are you familiar with the economics behind SoC manufacture?
Yes, I do. I've been working with embedded systems and RISC chips since
1990. I even did a little back in the late 70's before I went to work
for IBM, but those were hardly even processors at the time (e.g.
Motorola 6800).
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.
then convince me that it's worth adding to the standard.
I don't have to because we aren't considering the standard at this time.
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.
that can be arranged.
Sorry, it's just not going to happen.
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.
for the CPU Card i can probably arrange an escrow contract which
would cover that possibility.
for the base-boards i'm inclined to ask if they can be done as open
hardware projects, only doing them as "private designs" if the client
has specific reasons to do so.
No. This is a commercial product, not an open source freebie.
Things like this have happened in the past, and they don't want to be left
high and dry.
again: that's exactly why i designed EOMA68, to minimise that
happening, and yet to take advantage of the low-cost of these SoCs and
to minimise transition costs.
... i have to say that at this stage this is beginning to stray from
the remit of the debian-arm mailing list. i'll take a look at the
next message you sent (which may be in reply to the general
recommendation one about the atmel and freescale socs, i'll have to
check) but am inclined to suggest taking this discussion off-list?
l.
Yes, it is. But I do not wish to take it off line. From everything
I've seen, the EOMA68 board does not support the features we need, is
too expensive and is not available at this time. And the additional
factor that it has a daughter board will make it bigger than necessary.
Additionally, nothing against you, but so far there is no indication
on how well your standard will be accepted. I think it's a great idea
and a good implementation (from the doc, anyway). But it isn't what we
need.
So I'm still looking for an inexpensive ARM board which will run Debian,
which is on topic for this list.
Jerry
Reply to: