[lkml]   [2013]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
    [ please do try to remove debian-release from replies - my mistake
    please try not to propagage it, even though it may be too late!]

    On Wed, Jun 5, 2013 at 10:16 PM, Russell King - ARM Linux
    <> wrote:

    eyy, allo russell, long time since we last spoke, which was eek around
    2004 for that cirrus logic 90mhz ARM when i was converting skyguard
    over from 2.4 to 2.6.

    > On Wed, Jun 05, 2013 at 03:00:13PM -0600, Stephen Warren wrote:
    >> 2) Having U-Boot itself read a DT and configure itself, just like the
    >> kernel does. This is relatively new, and only supported by a few boards
    >> (all Tegra to some extent, and a couple each Samsung Exynos and Xilinx
    >> boards). I suspect/guess this is the kind of thing that Luke was
    >> referring to re: U-Boot fex integration.
    > Reading what I have of this thread, this is just another case of
    > $company runs of and does their own unique way of doing something,

    he he - don't be too despondent, russell: they've managed to be
    incredibly successful, and they're a young company, my role here is to
    act as the go-between, to be able to say to them "can we help each
    other out here please?"

    > which is in a totally different direction from that path chosen by
    > Linux kernel developers, and Linux kernel developers are _expected_
    > to roll over and accept $company's unique way of doing it.

    not at all. no. definitely wrong. you're thinking about this the
    wrong way. i.e. you're imagining that they have some sort of agenda
    which is to punish linux kernel developers.

    the sunxi community however - those of us who have to act as
    piggy-in-the-middle - those of us who are working directly with the
    linux-sunxi kernel tree - are torn between going:

    * damnit let's give those linux kernel developers a damn good kicking
    for setting silly rules!
    * oh blast. not a snowball in hell's chance of getting allwinner soc
    code upstream
    * i wonder if there's a diplomatic solution or a well-reasoned argument here

    and so on.

    allwinner? naah. they'll quite happily keep on taking linux 3.4,
    3.5, 3.20e6 source code and forking it and throwing it back out there
    until the heat death of the universe reaches zero.... all without
    *ever* having expected a *single* linux kernel developer to roll over
    any object of their personal choosing.

    > $company could have assisted with the DT effort, helping to sort out
    > the common arch issues (which haven't been all that much), converting
    > drivers to DT and such like. But no, instead they've gone off and
    > created their own thing.

    yes, for very very good reasons, i feel. they have different
    requirements and different goals from the stated [unachievable but
    quite laudable one-kernel-fits-all-ARM-SoCs-everywhere] goal that the
    linux kernel developers have set themselves.

    * the markets that allwinner are targetting [their own SoCs in the
    tablet and IPTV markets] are very much a subset of those which the
    linux kernel developers are targetting [every single ARM SoC and every
    single product based around ARM SoCs in existence, past present and

    * the file format is standard DOS .INI format, so their customers,
    instead of having to edit c code or understand DT, can just use a DOS
    editor. remember: these devices are often being made by people who
    decided "i'm fed up of selling socks, jumpers and handbags: i know, i
    fink i will diversify and get my girls to make.... tablets. yes,
    that's it! tablets!". so now you know what level of technical
    computing competence most of these factories have: NONE. it's amazing
    that they sell anything at all, to be honest, but sell they have, and
    taken 40% world-wide market share of the tablet market.

    * the ODMs can take virtually any device, from any customer,
    regardless of the design, put *one* [unmodified, precompiled] boot0,
    boot1, u-boot and kernel onto it, prepare the script.fex easily when
    the customer has been struggling on how to start that DOS editor he
    heard about 20 years ago, and boot the device up, put it into a
    special mode where the SD/MMC card becomes a JTAG+RS232 and see what's
    up... all without even removing any screws.

    > I wonder how many more of these cases there needs to be before people
    > get the message that Linux kernel developers *do* *not* like this
    > behaviour, and if you do this, then chances are you're going to be
    > stuck with having code which isn't able to be merged into mainline.

    well... then the SoC vendor with a global market share totalling 40%
    will carry on creating yet more code which isn't able to be merged
    into mainline, and they won't give a flying fuck, russell - simple as
    that. actually, they won't even give a flying fuck, they'll just
    carry on happily making money.

    and the sunxi community, who are stuck in the middle, will be forced
    to shoulder the burden of the work in living between these two worlds.

    plus, because debian and the many other linux distros only really
    accept code from upstream rather than from self-appointed communities
    (because it's damn inconvenient to do merging for just one SoC e.g. in
    debian where they have *mostly* a multi-arch kernel i.e.
    multi-minus-allwinner), the sunxi community will... no, actually, they
    won't be burdened with that task, they'll just continue to advise
    people where various people have created non-packageable versions of
    the linux kernel, usually distributed as part of some god-awful
    instructions that include "now download a 1gbyte pre-prepared root
    filesystem from" - i'm exaggerating there but only

    ... am i making it clear that this is a dog's dinner mess, and setting
    intransigent rules only hurts the end-users and reduces the acceptance
    and availability of linux distros?

    > And I don't buy the argument that we were still sorting out DT. DT has
    > been well defined for many many years before we started using it on ARM.
    > It has been used for years on both PowerPC and Sparc architectures to
    > describe their hardware, and all of the DT infrastructure was already
    > present in the kernel. What was left for us were:
    > * converting our platform-data based drivers to use data from DT.
    > * come up with ways of dealing with SoC issues such as clock
    > representation, pin muxing and such like in DT.

    yes. "what was left". in other words, when allwinner would have
    been looking at this, they would have gone, "we can't possibly deal
    with this. none of us speak english. we have to get a simple-to-use
    bootstrap system out there, including something equivalent to a BIOS
    all customisable *without* any recompiles... we have to do this
    ourselves and we have to get it out *now*, not on the linux kernel
    developers' schedule".

    virtually all of the comments in the allwinner source code are in
    chinese, russell.

    > But no... all that had to be created in this custom fex stuff which now
    > presents a barrier with getting support for something merged.

    indeed. can i please ask people to consider how much of that barrier
    is realistically achievable, and how much of that barrier should
    remain in place given that it is clearly detrimental to the adoption
    of GNU/Linux OSes?

    if this was that cirrus logic 90mhz SoC we were discussing, russell,
    i wouldn't even bother to raise it as an issue. but this is the
    company that, when they first created the Allwinner A10 and undercut
    the competition by a whopping 40% (that's excluding the reductions in
    the BOM due to its high level of integration), actually caused a major
    recession *in their own country* as everyone scrambled to adopt it,
    leaving all those people with stock of components *not* based around
    that SoC high and dry.

    > And somehow people make out that this is _our_ problem...

    no - i'm pointing out the scope of the problem, and i'm asking for a
    discussion of proposals that i can take back to allwinner, and to have
    a concrete but preliminary agenda that i can pass to the Director's
    Assistant some time within the next two weeks.

    more than that i cannot say but this is an opportunity to get things sorted out.


     \ /
      Last update: 2013-06-06 00:41    [W:0.034 / U:50.392 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site