[Arm-netbook] Ask him for Android DDK (Was: I Have An Possible Chance To Meet An ARM Senior Manager)

[Gordan Bobic]

On 10/07/2012 04:08 PM, luke.leighton wrote:

>   what it's *not* suited to is the drastic differences between the
> ARM9, ARM11, Cortex A8, A9, A7, A15 instruction sets themselves.
> remember linaro doing some work on gcc which provided a whopping 30%
> performance improvement on Cortex A8 just by reordering instructions
> to suit the Cortex A8 pipeline?

I don't recall reading about that, but I rather doubt that the 30% 
improvement was in the general case, but I'd like to read a thorough 
analysis that says otherwise.

>> EOMA68 has a LOT of advantages in terms of standardizing things, but the it
>> also increases the cost of the end device if you have the resources to
>> implement the device from scratch and plan on selling tens of thousands of
>> them.
>
>   ah.  if you only plan to sell tens of thousands, chances are that a)
> you won't be able to compete b) you'll be extremely unlikely -
> especially if it's a Chinese SoC - to gain access to the SoC in the
> first place.
>
>   so the point of EOMA-68 (one of many) is that because the SoC is on a
> standardised format that's available in mass-volume, the end device
> development is drastically simplified down to a 2 to 4 layer PCB, and
> with that comes a significant number of advantages.
>
>   so in effect, the EOMA strategy opens up the market and the
> possibilities.  i foresee that the extra cost of the PCMCIA connector
> be drastically less in mass-volume than any cost increases added by
> any small-to-medium-volume ODM having to pay 10k pricing, especially
> in the circumstances where that PCMCIA connector is ramped up to
> volumes of 100 million and above.

I understand that it limits the risk of the manufacturer because they 
can separate the device from the CPU module. But it is not at all clear 
how many device manufacturers will actually decide to go down this 
route. Also, there doesn't seem to be much in it for the SoC 
manufacturers, all it does is destroy any lock-in over the device 
manufacturers they might have had to begin with.

>   however, as this article illustrates very very clearly, the SoC
> vendors are finding that they're in a market with half a dozen to a
> dozen other SoC vendors, each with between 3 to 5 relevant (i.e.
> popular) SoCs *each*.
>
>   http://www.eetimes.com/electronics-news/4397038/China-fabless--Worldwide-table-war-rocks-Rockchip-

What it also demonstrates is that a saving $8/unit on the SoC seems to 
justify the complete redesign of the device to use a different SoC. With 
a race to the bottom raging so relentlessly, it's not trivial to work 
out the precise cost benefits between the extra few pennies on an EOMA 
card solution vs. the development cost of a proprietary solution with 
one fewer PCB, and a couple of extra connectors.

Having said that, as the wage standards across the world even out, 
standardisation will count for much greater savings vs. a couple of 
extra connectors per device. But that is also likely to take decades to 
happen to a sufficient extent.

>   you note in that article about how rockchip mentions that the
> allwinner a10 ate their profits?  that's going to happen again.  and
> again.  and again.  and again.
>
>   so yes, sure, you can try to save a few pennies, but it's a terribly
> risky strategy to try to save a few pennies.... and then three months
> later SPLAT, someone comes out with a cheaper, faster, better SoC with
> cheaper faster better DDR3 RAM with cheaper faster better NAND with a
> cheaper higher quality better LCD panel.... and all your suppliers are
> left holding stock of your ICs, with contracts reneged and it all goes
> to hell.
>
>   just like it did pretty much exactly this time last year when the
> Allwinner A10 became mainstream.  you remember that little factory who
> was going to do the CPU Card schematics for us?  they went bust...
> because all their clients went bust, because all their clients were
> using the AML-8726M which was $15 at the time when the Allwinner A10
> was $7.
>
> that happened on such a large scale in Guangdong that it caused a
> major recession.... and there's nothing in place - no strategy - to
> prevent that from happening again.

Maybe but there's only so much you can shave off a $7 price tag of an 
SoC before you actually start paying people to take them. If it does 
happen, it's certainly not going to be another $8/unit saving on the BoM.

>> For a purely business oriented manufacturer and the channel, the proprietary
>> nature of a product is an advantage - the cheaper the product is to produce,
>> the greater the profit margin, but also the higher the end cost of the
>> product (e.g. a complete Android slate vs. just a new EOMA68 module), the
>> higher the profit margin you can tag on top. From this point of view, I can
>> see the large-scale manufacturers and distributors of certain classes of
>> devices having a resistance to the concept of making things easily
>> upgradable.
>
>   again: read that article.  that situation - that belief in the
> superiority of a proprietary vertical-market strategy - is falling
> apart, very rapidly.  it's not being widely discussed, because nobody
> really has any solutions.

I can see where you are going with this, but ultimately, the cost of a 
SoC only accounts for so much of the device when the SoC itself is $7. 
Every subsequent disruptive product will have an increasingly lower 
impact because there's only so much you can skim off the price tag.

On the flipside, by separating the device from the CPU module, if 
something similar is yet to happen on the rest of the device, at least 
you could still use your stock of CPU modules if, for example, some 
manufacturer comes up with a disruptively priced screen or whatever else 
forms the dominant part of the device cost.

Eventually, however, the race to the bottom hits that bottom, and at 
that point quality starts to make a bigger difference - and if you have 
a decent device but could do with more CPU/RAM, at least you don't have 
to throw it away. Devices with high-res screens, for example, are few 
and far between and it would be awesome to be able to upgrade them 
rather than waiting in vain that someone might make a similar but better 
one in the future during another race to the bottom driven by some other 
factor in the future. For example, it took 6 years for somebody to come 
up with a high-end laptop that packs more than 2048x1536 pixels in a 
15"-ish format (Apple's new MacBook Pro with retina display, vs. my 
trusty old ThinkPad T60).

>   i think that guy at rockchip was incredibly brave to go on record and
> describe that rockchip is getting absolutely hammered.  i'd love to
> get in touch with him and invite him to participate in the EOMA-68
> initiative.

Perhaps you should. :)

>> That, of course, is not to say that I don't think EOMA68 is likely to become
>> massively popular in some areas, e.g. smaller scale manufacturers and those
>> interested in making higher-quality products with decent long-term
>> supportability, high density servers, etc.
>
>   yes.  and mobile phones.  mobile phones are just too specialist right
> now.  perhaps in 3 to 5 years it will be possible to create an EOMA
> standard where the phone's key electronics are packaged into a size
> 3mm x 40 x 30 or so, that itself will be a major challenge.  we'll
> see, eh? maybe some of the 22nm geometries or below will help there.

Problem there might be the format you end up being limited to size-wise. 
Would CF have enough pins? You could go with a SO-DIMM format, but that 
does away with the thus far paramount "safe-to-handle-by-the-user" 
requirement.

>> The problem is in figuring out who stands to lose from standardisation like
>> this and working around them.
>
>   well... that's the thing: nobody's yet told me anything that shows
> that anyone "loses".  i've been trying to think, on and off since i
> came up with EOMA, and i truly haven't yet encountered a single thing
> which is a "loss", to *anyone*.

You gave an example of it by pointing out the article. If Rockchip lost 
all of their business to Allwinner over an $8 price difference in the 
SoC, imagine how much faster they would have lost all that business if 
everyone was already using a standardised CPU module. This would have 
meant that the re-targetting re-development cost would have been much 
smaller, and Rockchip would have had an even harder landing. I don't 
imagine the SoC manufacturers are going to look forward to losing what 
little customer-lock-in they might already have. In that example, I can 
see why Allwinner might like the idea of EOMA, but I can't see why 
Rockchip would like it.

>   SoC vendors are in trouble because they're on a glut-and-starvation
> cycle of development, as that article in eetimes graphically
> demonstrates.  EOMA-68 helps them to respond much quicker.

Hmm... You mean the SoC manufacturers actually end up doing all of 
device manufacturers' homework? Makes you wonder why they don't just go 
and make the end devices themselves...

>> As an example, last I checked, Tegra2 has PCIe support in the SoC, but last
>> I checked, nobody has actually managed to make this work in an actual
>> device.
>
>   managed to, or bothered to?  the problem i think here is the
> disparity between the power consumption of SoCs (1 watt) and the kinds
> of peripherals that have PCIe interfaces (3D Graphics cards: the best
> i've ever been able to find is 8 watts!)   you just... you just
> *don't* match up a 1 watt CPU with a peripheral that takes 10x the
> power.  you find a different solution.

I seem to remember reading about the TrimSlice guys having wanted to use 
a PCIe SiliconImage SATA chip, but couldn't get it working with Tegra's 
PCIe implementation. And from what they said, it wasn't for lack of 
trying. So they gave up and went with a USB->SATA solution.

>> Ultimately, however, I can see one benefit from EOMA68 in this regard - it
>> is inevitably going to give a big boost to well supported SoCs because it is
>> likely that EOMA68 cards will be much more likely to be implemented using
>> those SoCs. On the downside, some of the smaller, more GPL violating SoC
>> vendors are likely to go out of business, but hopefully most will just start
>> to be more GPL compliant in order to not put their SoCs at a disadvantage in
>> terms of likelyhood EOMA68 implementations. Note: that puts some of those
>> more resistant-to-GPL small manufacturers on the list of entities that will
>> need to be "worked around" due to them potentially standing to lose
>> something from a move away from proprietary implementations.
>
>   i can't possibly comment on the fact that secondary copyright
> infringement could be used as a tool to make it bluntly clear to
> GPL-violating SoC vendors that they need to get their act together,
> very very fast.

Maybe - but that's when lawyers get involved; and things start to take 
decades until the endless appeals and escalations are exhausted by which 
point none of it matters any more anyway.

>> Devices are treated as throw-away both:
>> 1) by the consumers who get them cheap enough that they can afford to not
>> worry about it (the attitudes, are, thankfully, changing slowly in times of
>> decline in economic prosperity, but this is offset by greater propensity for
>> buying something that is cheap over something that is good).
>
>   ... whereas what we're proposing is something that's both cheap *and*
> good.  ok, cheap if they want it, and then during times of propsperity
> they can spend a bit more and buy something expensive and really
> good... yet still save money by only having to upgrade 1/2 the
> product, not all of it.

The cheaper half, too. A decent high res screen costs orders of 
magnitude more than an SoC and some RAM.

>> and
>> 2) the manufacturers, a lot of whom seem to be of the sort that set up in a
>> shed in China, build a few tens of thousands of devices, put them in a
>> shipping container, and are long dissolved and gone by the time the devices
>> arrive to the end market. Those manufacturers stand to gain nothing at all
>> by making standards compliant devices because they have no intention of
>> being around to support the device once it leaves the factory.
>
>   again, it's necessary to use both carrot and stick, here.  carrot
> being the incentive of public awareness of the cost and environmental
> benefits of EOMA-68 driving demand *away* from vertical market
> products; stick being massive secondary copyright infringment lawsuits
> which i can't possibly comment on which make retail stores think twice
> before buying GPL-violating product.

I think we can safely ignore the environmental benefits, at least at the 
moment. I don't know many people who would buy a more expensive device, 
all things being equal, just because the manufacturer uses more 
environmentally friendly processes. But the rest of the argument may 
stand a chance.

>>>    in other words: even if you got google to "solve" this problem by
>>> allowing kernel modules to be installed, the massive and endemic GPL
>>> violations problem makes it completely and utterly pointless to even
>>> *have* the ability to dynamically load kernel modules.
>>>
>>>    do you see?
>>>
>>>    so again, here, EOMA-68 helps out, because of the standardisation.
>>> even in cases where there were GPL violations of EOMA-68 CPU Cards,
>>> the task of reverse-engineering the linux kernel onto that hardware
>>> would be enormously simplified, because the only part that would need
>>> to actually be reverse-engineered would be the CPU Card part, *not*
>>> the I/O side (for the products that the CPU Cards go into).
>>>
>>>    you get the point i'm making, here?
>>
>>
>> I'm not sure I quite see the distinction. How much of the kernel level
>> support is actually focused on the things that are _outside_ of the SoC?
>
>   ok, let's think it through.  "outside" basically means I/O.  these
> are the categories i can think of:
>
>   a) GPIO.  typically used for powering up of peripherals, or as
> keyboard matrices and so on.
>   b) single-purpose buses (Camera, Transport Stream, RS232, RS423,
> SD/MMC) to which devices are typically hard-wired (GPS, WIFI SOMs
> etc.)
>   c) multi-purpose dynamic buses (SATA, PCIe, USB)
>   d) general-purpose memory buses (e.g. HPI, DDR, NAND) which kinda
> should be considered to be part of b above, now that i think about it.
>
>   let's consider the most recent 1000 products world-wide that have
> come out, with ARM SoCs in them.  every single one of those products
> will have *NOTHING* to do with any other product - no large subset of
> common features WHATSOEVER.  no cooperation is even possible.
> reverse-engineering is a nightmare.  you can do it... but you're truly
> wasting your time, due to the sheer product diversity.  even the large
> manufacturers will, by the time you get to buy any one of those 1,000
> products, have *already* moved their focus on to the 1001th product.
>
>   now let's consider the situation where there are over 100 EOMA-68 CPU
> Cards, and over 1,000 different EOMA-68 products.  let's say that you
> are a GPL-violating SoC vendor who wants to "break in" to the EOMA-68
> market.  you take the linux kernel source code including EOMA-68
> compliant drivers, you create modifications of one tiny portion of it
> and then try to claim that the *entirety* of that source code is
> yours, in direct violation of Copyright Law.
>
>   you release a GPL-violating CPU Card and... what happens?  i've done
> quite a lot of writing, here, so i'll let other people write some
> answers before chipping in.

In theory? Few people would buy your EOMA card if they couldn't easily 
develop their product's software on it due to lack of kernel sources.

In practice? The manufacturers would buy it anyway if it's cheap and if 
they get a working (no matter how GPL infringing) version of software 
with it that they can just shove out the door, take the money and run. 
Rather like what happens today, I guess.

>>   Same situation, albeit with fewer SoCs to
>> support. Not saying that wouldn't be an improvement (although all the other
>> SoC vendors going out of business would reduce competition and drive up
>> prices, which would be a bad thing).
>
>   yes, it would be bad.  the point of the exercise is to increase the
> window of opportunity for each SoC vendor to get their CPUs out
> rapidly into the market, and also to reduce their risk of running into
> "vertical market" niches which have enough competitor product problems
> already, as it is.

Sure, it's an insurance, especially if the SoC vendor is expected to do 
most of the device vendor's homework, as mentioned above. I hadn't 
realized to what extent that is the case until this thread. I thought 
device manufacturers actually did something over and above soldering 
things together. Assuming I'm getting the correct gist of the situation 
here.

Gordan