[Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

[luke.leighton]

On Wed, Jun 5, 2013 at 10:47 PM, Henrik Nordström
<henrik at henriknordstrom.net> wrote:
> ons 2013-06-05 klockan 22:15 +0100 skrev Luke Kenneth Casson Leighton:
>
>> what we do not want to happen is that they see upstream patches being
>> submitted, they merge them into their internal tree (which to date has
>> had zero upstream changes: they're currently only just getting round
>> to doing 3.4 as we speak), and they *completely* ignore *absolutely
>> everything* that's being done by the community, duplicating yet
>> another set of device drivers (named drivers/*/sun8i_* and so on).
>
> Well, that will obviously happen one or two more rounds, a bit depending
> on which kernel releases Android will use. But I hope the Allwinner
> kernel team will rethink when they hit more current kernels.

 yyyeahhh..... that's the whole point, henrik: i'd like to give
allwinner a heads-up *before* that happens, and to also give the linux
and sunxi kernel developer teams an opportunity to hear what allwinner
would like to see happen (if anything).

 what i *really* don't want to happen is for them to get a nasty
surprise some time around 3.9 or above, along with a hell of a lot of
kernel conflicts that cause them to completely abandon the entire
current linux directory conventions.

 or worse, do "find . -name "*sunxi* | xargs git rm" on linux 3.9 [or
above] prior to perging in *their* versions.


>>  this proposal is a start: however what you have to bear in mind is
>> that you now have to convince a very busy company that it is in their
>> best interests to disrupt their schedule, to drop their existing
>> working practices, to tell all their customers "please stop using the
>> existing tools and please use these ones instead".
>
> Why?

 taking this as a rhetorical question (kinda), what i believe jon
proposed would have a knock-on effect of requiring that boot0 and
boot1 be converted *away* from script.fex and onto DT.  therefore,
automatically, all tools must now be converted to understand DT not
fex.  that includes the (proprietary) equivalents of fex2bin and
bin2fex [*1]

 but, i could be wrong.

>>  you also need to convince the creators of the proprietary
>> firmware-flashing tools "livesuite" and "phoenix" to *also* convert
>> their tools over to the new proposed idea.
>
> Why?
>
>>  can you provide such a supporting argument which would convince
>> allwinner to accept the modifications to their working practices that
>> you propose?
>
> It does not really need to be such big modifications to their working
> practices. Their configuration working practices is all built around the
> fex file, and the new practices can be
>
> 0. Assuming kernel drivers gets ported over to using device tree.
>
> 1. Do configuration as you have always done in the .fex
>
> 2. Modify the build script to build a device tree from the fex +
> template, in addition to script.bin.
>
> 3. Tell u-boot to load the device tree for the kernel.
>
> That's it really.
>
> livesuit do not modify script.bin. script.bin is compiled from the .fex
> at image creation time. A couple more lines in the build script (and a
> suitable translation tool) and there is also a device tree built and
> installed and you get a nice and smoot transition.

 ok: great.  so we have something that i can potentially propose to
them.   now: what reason can i give that they should accept this?
what's the biggest incentive for them, here, to make these changes?
what would they gain?


>> > Device tree on ARM's goal is to achieve a single kernel across vendors, not
>> > just a single kernel for a single vendor.
>>
>>  you'll be aware that i've mentioned a number of times and have
>> discussed at some length why this is a goal that is completely
>> impossible to achieve [*1].  sadly.
>
> Here I disagree. It is possible. Not across all vendors but a
> significant share.

time will tell, henrik [i mean that sincerely, not in a trite way].

fortunately as you know (but many people on these various lists may
not), with the eoma initiatives [*2], we bypass that possibility, and
through hardware standardisation turn an N*M work problem into an
N+M+2 work problem (where N is number-of-SoCs and M is number of
product types).

l.

[*1] https://github.com/linux-sunxi/sunxi-tools
[*2] http://elinux.org/Embedded_Open_Modular_Architecture