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

[luke.leighton]

On Sun, Oct 7, 2012 at 1:53 PM, Gordan Bobic <gordan at bobich.net> wrote:

> On 10/07/2012 12:43 PM, luke.leighton wrote:
>
>> so effectively what i'm saying is that Android faces *exactly* the
>> same proliferation problems that *all* GNU/Linux OSes face, which is
>> that each hardware device has to have its Linux kernel hard-customised
>> *specifically* for that hardware, when the Linux kernel is continously
>> undergoing drastic revision.
>
>
> A couple of points here. If you are referring here to source-level
> customizations, then this is down to the hardware and SoC vendors not caring
> about whether the hardware is supported in mainline, and rampantly violating
> GPL by not releasing their sources.

 that's an additional problem imposed on top of the problems that the
ongoing improvements made by the core linux developers cause - yes.
inter-related, because they can't keep up, because there's no
standardisation, no BIOS etc. etc. as we well know, BIOS
standardisation being absolutely flat-out impossible in the SoC world.

> I would _LOVE_ to see this change, but I don't realistically see that
> happening without a major world-wide litigation that would set a precedent
> of GPL being enforceable and make an example of both the companies that are
> responsible for the GPL violations and the directors of those companies with
> both large fines and directorship bans for wilful licence infringement on
> large scale.

 i can't comment on this.  "can't comment" as in i am under an
obligation to not reveal what i know, other than to say that there is
something which i have been made aware of that is confidential (but
that i have not signed any confidentiality agreements on).

> In the western world I can almost see it happening against the likes of
> StorageOptions and similar small-scale producers, but against thousands of
> small-scale here-one-week-gone-the-next companies in the far east that are
> long gone by the time a 100,000 of their devices hit the shelves in Europe?

 you didn't hear from me that considering this to be the absolute last
word on the matter means having forgotten about the concept of
"secondary copyright infringment".  criminal means criminal.  if you
buy from a criminal, you are yourself a criminal, being an accessory
to a crime.  flouting copyright law is a criminal act.  secondary
copyright infringement is therefore an extension of criminal copyright
infringement all the way down the supply chain.

> If, OTOH, you are talking about the issue of one binary kernel booting on
> multiple ARM devices, I believe that is already almost ready in kernel 3.7.
> There was something about this on /. a few days ago, IIRC.

 oh... the multiarch stuff?
http://linux.slashdot.org/story/12/10/04/1942201/linux-37-kernel-to-support-multiple-arm-platforms

 it looks like that's suited to the various equivalent features from
the x86 world such as SSE, MMX and so on.

 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?

 you simply can't merge all those into one monolithic kernel.

>> by contrast: if you had a hardware standard (EOMA-68) that was simple
>> and comprised of other proven stable decade-old I/O specifications,
>> the job of adding a new SoC is made drastically simpler: you merely
>> have to write linux kernel code that conforms to that standard.. and
>> AUTOMATICALLY YOU GET ACCESS TO THE PRE-WRITTEN DEVICE DRIVERS FOR
>> PRODUCTS THAT CONFORM TO THAT EXACT SAME STANDARD.
>
>
> Maybe. But the problem still remains on a lower level in the sense that a
> lot of SoCs take ages to get proper kernel level support for all of their
> built in features, even before we start talking about implementations and
> choice of components and protocols for connecting to all the various
> external add-ons.

yes.  that's still the job of a SoC manufacturer, and there's not a
lot that can be done about that, at the "product" level.  to make SoC
manufacturers' lives easier, they have to start to agree standards
amongst themselves, start cooperating and so on.  as they like to
compete rather than collaborate, that's unlikely to happen.

so there isn't anything that can really be done about this, we just
have to let them get on with it, and do what can be done.

> 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.

> Ultimately, the cost of the PCMCIA connector and casing is something
> you can lose if you don't care about upgradability, and save a few pennies
> per device.

 well... if there was only one SoC vendor, then yes, you'd be right.
that one SoC vendor could go "whew!  we can save our customers
pennies!  all we have to do is bring out the next SoC, it'll all be
fine!"

 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-

 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.


> 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 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.

> 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.

> 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*.

 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.


>
>> do you see how that solves the exact same problem, just in a different
>> way?  each new SoC that comes out, a DDK doesn't have to be customised
>> solely and exclusively for each and every single piece of hardware in
>> existence into which that SoC is ever going to go.
>
>
> In terms of peripheral devices, sure, that'd be great. But my perception is
> that with ever more being integrated onto the SoC, it won't make the problem
> go away completely. It's a step in the right direction, but I don't think it
> addresses the entire scope of the current problem.

 you can't do everything, overnight.  we can however bootstrap our way
up to credibility, after proving the viability of EOMA-68.  once
EOMA-68 is well underway i'll have time and funds to focus on finding
more solutions that are to everyones' benefit.

> 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.

> 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.

>>   android was never designed to be a full-blown OS.  it was never
>> designed to be a desktop replacement.  it has a completely different
>> mindset behind it.  they truly expect the devices to be throw-away
>> "toys".  "so a device doesn't do what you want? so what!  get another
>> one that does!" i feel is the general attitude, here.
>
>
> And you just hit the nail squarely on the head. This attitude prevails far
> and wide in the SoC consumer electronics world, from what I can tell.

 yes.  the sheer waste that's ongoing as we speak is truly making me
both angry and also ashamed that i haven't been more forthright about
getting this aspect across.

> 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.

> 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.

>>   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.

>>   by contrast: if you had an EOMA-68 hardware standard where the CPU
>> Card came pre-installed with the OS, the kernel could be optimised for
>> that CPU, yet the CPU Card would have access to a wide range of device
>> drivers so vendors would be forced to clean up their act.
>
>
> I think this is just coming across wrong - it sounds like you are proposing
> addressing the issue of proprietary binary kernels

 you mean GPL violating.  you can't have a proprietary GPL linux kernel.

> with a proprietary binary kernel

 you mean GPL violating.  you can't have a proprietary GPL linux kernel.

>  for each EOMA68 SoC.

 ah no!  ok, we can't stop e.g. apple from creating a port of MacOSX
to work with EOMA-68, but that's a different matter.

 we'll get to how to solve the "turn GPL-violating kernels into
EOMA-68 GPL-violating kernels" later.

>  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.

 the essence of this all is that the EOMA-68 initiative turns SoCs
back into "general purpose computing devices", thus expanding and
broadening the markets for all the SoC vendors, and thus reducing
their risk and liability.

 what's also neat about EOMA-68 is that they can also, with the exact
same modular form-factor, cover "niche" markets - vertical markets -
as well, by using the exact same CPU Card as a factory-install module,
through access to other features of the CPU being made available via
FPC or DIL2 factory-only connectors.

 so they can have it both ways.

l.