On Wed, Jun 5, 2013 at 10:47 PM, Henrik Nordström <hen...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
