Re: Good ARM board for Debian?
[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.
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?
> 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.
>> 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.
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.
> 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.
>> 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,
> 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.
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.
> 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.
>> 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!
> 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.
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
> 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.
>
>> 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.
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 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.
> 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?
>
>>> 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.
>
>> 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.
>
>>> 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.
> 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.
Reply to: