On Fri, May 31, 2013 at 3:52 AM, Ben Hutchings <[email protected]> wrote:
> The 3.8.y branch is over, so I think we have to move to 3.9, ready or
> not. I merged the work in progress from trunk to sid and am going
> through the config changes at the moment.
>
> I'm rather disappointed that nothing at all has been committed by ARM
> porters to either branch in the last month.
*sigh* i didn't want to leave this as it stood, ben, purely for the
reason that i don't want to see you discouraged! but, i also had to
think a bit about what potentially to say.
the one SoC family that's going to become increasingly important to
have both upstream and in debian is support for allwinner's
processors. with 40% world-wide tablet market share [*0], they must
be doing something right, and it's basically getting a staggering
price-performance value as well as having a set of interfaces and
level of integration that is really second to none.
to begin to describe the problem in getting allwinner soc source code
upstream is this: not only do we have the usual "let's get it out the
door as fast as possible" learning curve of a very young, very new and
bewilderingly-successful fabless SoC company, but we also have a
completely new type of very successful and comprehensive
device-tree-like dynamic configuration system to deal with, which
allwinner have called "fex" [*1].
basically at the time when device-tree was being thought of,
allwinner needed something that they could *right then* - not waiting
for developers to finish device-tree - they needed to be able to
reconfigure their customer's kernels *without* needing a recompile.
so they invented the script.fex system, which is a simple config.ini
file-format, compile it to binary, and get the bootloader to upload it
to memory and read it.
fex covers *eeeeeevvveeerryyyythiiiing* - right from flipping the
multiplexing for all 3 SD/MMC cards so that you can pretend that SD0
is SD2 and you can specify *different* GPIOs for each to say which is
the detect line, which is the write-protect line, to setting the DRAM
clock timings, saying which kernel driver must be loaded to support
the touchscreen, enabling debugging, JTAG, naming the GPIOs for easy
and convenient use in the kernel code: basically there isn't a single
piece of hardware on the allwinner SoC family which *isn't*
reconfigureable through script.fex... and they've even integrated it
into u-boot *and* their low-level (early) bootloader as well [which
they've just properly complied with the GPL on, hooray! [*2]].
what's the point of mentioning this?
well, the point is: the expectation of the linux kernel developers is
that Everyone Must Convert To DeviceTree. implicitly behind that is,
i believe, an expectation that if you *don't* convert to Device Tree,
you can kiss upstream submission goodbye. and, in allwinner's case,
that's simply not going to happen.
add to this the fact that they've already taken *five* near-identical
copies of each version of their drivers (for sun3i up to sun7i) - if
you do a recursive diff in the drivers/usb/sun7i_usb and
drivers/usb/sun4i_usb directories, the discrepancies are negligeable
(and are in many cases a regression, reintroducing known or new
bugs!), you can start to see that they simply have no idea how to work
with the free software community (they're too busy) and that they're
not really about to start, either.
... and yet they're unbelievably successful, despite making a dog's
dinner of things as far as upstream integration is concerned,
precisely because they really really do only need to get one single
kernel compiled (for *all* their multi-million-dollar clients) and
err... that's it. everything else goes into a per-client (per
product) customissed script.fex.
so, i don't have all the answers, but i can clearly see that there
needs to be some discussion and dialog - we can't have the world's
most successful SoC vendor *not* supported upstream: that's just a
ridiculous situation that is not helping any of the linux distros to
be an easy install option on some of the world's highest
price-performance ratio hardware.
thoughts and discussion appreciated.
l.
[*0] http://hardware.slashdot.org/story/13/05/08/1636217/chinas-allwinner-outsold-intel-qualcomm-in-tablet-processors-in-2012
[*1] - fex guide for SoCs up to but excluding the Allwinner A20
http://linux-sunxi.org/Fex_Guide
[*2] http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-June/007619.html and
http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-June/007611.html
On Wed, Jun 5, 2013 at 3:46 PM, Luke Kenneth Casson Leighton
<[email protected]> wrote:
>
> On Fri, May 31, 2013 at 3:52 AM, Ben Hutchings <[email protected]> wrote:
>
> > The 3.8.y branch is over, so I think we have to move to 3.9, ready or
> > not. I merged the work in progress from trunk to sid and am going
> > through the config changes at the moment.
> >
> > I'm rather disappointed that nothing at all has been committed by ARM
> > porters to either branch in the last month.
>
> *sigh* i didn't want to leave this as it stood, ben, purely for the
> reason that i don't want to see you discouraged! but, i also had to
> think a bit about what potentially to say.
>
> the one SoC family that's going to become increasingly important to
> have both upstream and in debian is support for allwinner's
> processors. with 40% world-wide tablet market share [*0], they must
> be doing something right, and it's basically getting a staggering
> price-performance value as well as having a set of interfaces and
> level of integration that is really second to none.
>
> to begin to describe the problem in getting allwinner soc source code
> upstream is this: not only do we have the usual "let's get it out the
> door as fast as possible" learning curve of a very young, very new and
> bewilderingly-successful fabless SoC company, but we also have a
> completely new type of very successful and comprehensive
> device-tree-like dynamic configuration system to deal with, which
> allwinner have called "fex" [*1].
>
> basically at the time when device-tree was being thought of,
> allwinner needed something that they could *right then* - not waiting
> for developers to finish device-tree - they needed to be able to
> reconfigure their customer's kernels *without* needing a recompile.
> so they invented the script.fex system, which is a simple config.ini
> file-format, compile it to binary, and get the bootloader to upload it
> to memory and read it.
Why don't you try converting the sunxi code over to device tree? I
don't think it will be as hard as you may think it is. Start off by
mapping the existing fex syntax into a DTS file. Send your DTS file to
devicetree-discuss to get help with the correct syntax. Once this DTS
template is constructed you can write a program to convert any fex
file into it.
Now boot with this DTB; that will get all of the existing info into
the kernel's internal FDT. Then start converting your drivers over to
use the of_ support for accessing the FDT. You've already done all of
the hard work in making the drivers configurable at boot. As a
transition tool allow the kernel to boot with both fex and DT untill
you get all of the drivers converted.
BTW, device tree has been in the kernel since 2007 (or earlier).
About two years ago the ARM community decided to switch all new
development onto it in order to stop the proliferation of
platform/machine files. I believe the rule about no new non-DT ARM
platforms has been in place for over eighteen months.
If fex is add to the kernel every device driver will have to get two
bindings. One for when the chip is used on a fex machine, and another
when the chip is used with device tree. For example most of the I2C
device drivers have been converted to device tree and they now know
how to interpret device tree data for set up. And so on, and so on --
this problem exists for every bus based device. fex is simply a
re-implementation of device tree. We don't need too implementations of
this.
>
>
> fex covers *eeeeeevvveeerryyyythiiiing* - right from flipping the
> multiplexing for all 3 SD/MMC cards so that you can pretend that SD0
> is SD2 and you can specify *different* GPIOs for each to say which is
You can do all of this in device tree too. If the exact syntax doesn't
exist you can use 'allwinner,' prefixes on the node names.
Also check out pinctrl so that it doesn't get reinvented.
>
> the detect line, which is the write-protect line, to setting the DRAM
> clock timings, saying which kernel driver must be loaded to support
> the touchscreen, enabling debugging, JTAG, naming the GPIOs for easy
> and convenient use in the kernel code: basically there isn't a single
> piece of hardware on the allwinner SoC family which *isn't*
> reconfigureable through script.fex... and they've even integrated it
> into u-boot *and* their low-level (early) bootloader as well [which
Device tree support has been integrated into uboot for about five years now.
>
> they've just properly complied with the GPL on, hooray! [*2]].
>
> what's the point of mentioning this?
>
> well, the point is: the expectation of the linux kernel developers is
> that Everyone Must Convert To DeviceTree. implicitly behind that is,
> i believe, an expectation that if you *don't* convert to Device Tree,
> you can kiss upstream submission goodbye. and, in allwinner's case,
> that's simply not going to happen.
>
> add to this the fact that they've already taken *five* near-identical
> copies of each version of their drivers (for sun3i up to sun7i) - if
> you do a recursive diff in the drivers/usb/sun7i_usb and
> drivers/usb/sun4i_usb directories, the discrepancies are negligeable
> (and are in many cases a regression, reintroducing known or new
> bugs!), you can start to see that they simply have no idea how to work
> with the free software community (they're too busy) and that they're
> not really about to start, either.
>
> ... and yet they're unbelievably successful, despite making a dog's
> dinner of things as far as upstream integration is concerned,
> precisely because they really really do only need to get one single
> kernel compiled (for *all* their multi-million-dollar clients) and
> err... that's it. everything else goes into a per-client (per
> product) customized script.fex.
Device tree on ARM's goal is to achieve a single kernel across
vendors, not just a single kernel for a single vendor.
>
> so, i don't have all the answers, but i can clearly see that there
> needs to be some discussion and dialog - we can't have the world's
> most successful SoC vendor *not* supported upstream: that's just a
> ridiculous situation that is not helping any of the linux distros to
> be an easy install option on some of the world's highest
> price-performance ratio hardware.
>
> thoughts and discussion appreciated.
>
> l.
>
>
> [*0] http://hardware.slashdot.org/story/13/05/08/1636217/chinas-allwinner-outsold-intel-qualcomm-in-tablet-processors-in-2012
> [*1] - fex guide for SoCs up to but excluding the Allwinner A20
> http://linux-sunxi.org/Fex_Guide
> [*2] http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-June/007619.html and
> http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-June/007611.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Jon Smirl
[email protected]
On 06/05/2013 02:46 PM, [email protected] wrote:
> On Wed, Jun 5, 2013 at 3:46 PM, Luke Kenneth Casson Leighton
> <[email protected] <mailto:[email protected]>> wrote:
...
> the detect line, which is the write-protect line, to setting the DRAM
> clock timings, saying which kernel driver must be loaded to support
> the touchscreen, enabling debugging, JTAG, naming the GPIOs for easy
> and convenient use in the kernel code: basically there isn't a single
> piece of hardware on the allwinner SoC family which *isn't*
> reconfigureable through script.fex... and they've even integrated it
> into u-boot *and* their low-level (early) bootloader as well [which
>
>
> Device tree support has been integrated into uboot for about five years now.
There are two aspects to DT support in U-Boot:
1) Having U-Boot pass a DT to the kernel, possibly manipulating a few
properties on the way, e.g. RAM size. As you say, this has been around a
while.
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.
[i've just received word, please remove debian-release from discussions!]
On Wed, Jun 5, 2013 at 9:46 PM, [email protected] <[email protected]> wrote:
> Why don't you try converting the sunxi code over to device tree?
ok. perhaps i wasn't clear. whatever is proposed has to be be
acceptable to allwinner, and i'm looking for proposals that i can put
to them, i.e. i am going to act as the communications channel to them.
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).
> I don't
> think it will be as hard as you may think it is. Start off by mapping the
> existing fex syntax into a DTS file. Send your DTS file to
> devicetree-discuss to get help with the correct syntax. Once this DTS
> template is constructed you can write a program to convert any fex file into
> it.
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".
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.
so if that is to truly be accepted, it has to be framed in such a way
that it will be clearly of financial benefit to the SoC vendor.
can you provide such a supporting argument which would convince
allwinner to accept the modifications to their working practices that
you propose?
> 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.
l.
[*1] without a hardware-level redesign i.e. hardware standardisation that is.
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,
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.
$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.
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.
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.
But no... all that had to be created in this custom fex stuff which now
presents a barrier with getting support for something merged.
And somehow people make out that this is _our_ problem...
[ please remove debian-release from future replies! my mistake -
please don't propagate it, thanks ]
On Wed, Jun 5, 2013 at 10:00 PM, Stephen Warren <[email protected]> wrote:
> On 06/05/2013 02:46 PM, [email protected] wrote:
>> On Wed, Jun 5, 2013 at 3:46 PM, Luke Kenneth Casson Leighton
>> <[email protected] <mailto:[email protected]>> wrote:
> ...
>> the detect line, which is the write-protect line, to setting the DRAM
>> clock timings, saying which kernel driver must be loaded to support
>> the touchscreen, enabling debugging, JTAG, naming the GPIOs for easy
>> and convenient use in the kernel code: basically there isn't a single
>> piece of hardware on the allwinner SoC family which *isn't*
>> reconfigureable through script.fex... and they've even integrated it
>> into u-boot *and* their low-level (early) bootloader as well [which
>>
>>
>> Device tree support has been integrated into uboot for about five years now.
>
> There are two aspects to DT support in U-Boot:
>
> 1) Having U-Boot pass a DT to the kernel, possibly manipulating a few
> properties on the way, e.g. RAM size. As you say, this has been around a
> while.
>
> 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.
https://github.com/linux-sunxi/u-boot-sunxi
And Then Some, stephen. there are two versions of u-boot being used:
one is the community-assembled [GPL-compliant] one, and the other
includes a [as-of-a-few-days-ago-but-no-longer, yay!]
formerly-GPL-violating one from allwinner.
the community-based one *doesn't* have fex integration (i don't
think, but henrik will know for sure), but the allwinner one
definitely does.
.... and then there's the boot0 and boot1 loaders, these *do* have
fex integration: they're absolutely tiny and they're designed to fit
into the 1st level cache. the job of these bootloaders is to set up
the DDR3 RAM timings (so that you can access DRAM!!) and to then
decide whether to load from NAND, SD/MMC etc. and many other things.
these boot0 and boot1 loaders are themselves configureable so that
you can specify, through script.fex, what GPIO is to be the "reset
key" and so on. that's a much simplified story btw.
so the point is: if anyone wishes me to propose to allwinner that
they convert over to devicetree, or any other proposal which involves
significant low-level changes to their working practices that could
potentially have a massive knock-on effect onto their
multi-million-dollar clients, it had better be a damn good story.
l.
On Wed, Jun 05, 2013 at 10:24:15PM +0100, Luke Kenneth Casson Leighton wrote:
> https://github.com/linux-sunxi/u-boot-sunxi
>
> And Then Some, stephen. there are two versions of u-boot being used:
> one is the community-assembled [GPL-compliant] one, and the other
> includes a [as-of-a-few-days-ago-but-no-longer, yay!]
> formerly-GPL-violating one from allwinner.
>
> the community-based one *doesn't* have fex integration (i don't
> think, but henrik will know for sure), but the allwinner one
> definitely does.
>
> .... and then there's the boot0 and boot1 loaders, these *do* have
> fex integration: they're absolutely tiny and they're designed to fit
> into the 1st level cache. the job of these bootloaders is to set up
> the DDR3 RAM timings (so that you can access DRAM!!) and to then
> decide whether to load from NAND, SD/MMC etc. and many other things.
>
> these boot0 and boot1 loaders are themselves configureable so that
> you can specify, through script.fex, what GPIO is to be the "reset
> key" and so on. that's a much simplified story btw.
>
> so the point is: if anyone wishes me to propose to allwinner that
> they convert over to devicetree, or any other proposal which involves
> significant low-level changes to their working practices that could
> potentially have a massive knock-on effect onto their
> multi-million-dollar clients, it had better be a damn good story.
Well certainly anyone interested in being a customer of allwinner should
very much encourage them to get with it. Having support upstream really
is very helpful when trying to use a chip. Going off an inventing your
own thing rather than talking to the linux kernel developers first is
just a bad idea as far as long term support is concerned. Had they asked
they would probably have been told devicetree would be a good idea to use.
Allwinner has some very nice chips, and it certainly would be nice if
they would start doing things "properly".
Texas instruments uses devicetree for their arm devices. It's very nice.
I haven't checked what freescale is doing yet, although at least for
powerpc, freescale is very used to devicetree, so hopefully they are
doing that for their arm chips too.
Both are certainly pushing their drivers upstream for inclusion and seem
to be listening to feedback on how to best do things.
I haven't personally dealt with any nvidia arm devices, so I have no
idea how those are turning out, nor have I looked much at the marvell
ones yet (even though I have a cubox sitting on my desk I intend to play
around with).
Lots of others like qualcomm, samsung, and who knows who else. No idea
how they are doing things either.
--
Len Sorensen
Hi Luke,
On Wednesday 05 of June 2013 22:15:08 Luke Kenneth Casson Leighton wrote:
> [i've just received word, please remove debian-release from
> discussions!]
> On Wed, Jun 5, 2013 at 9:46 PM, [email protected] <[email protected]>
wrote:
> > Why don't you try converting the sunxi code over to device tree?
>
> ok. perhaps i wasn't clear. whatever is proposed has to be be
> acceptable to allwinner, and i'm looking for proposals that i can put
> to them, i.e. i am going to act as the communications channel to them.
Well, device tree is the only method of hardware description supported by
Linux kernel on ARM at the moment (except for board files, but this is
deprecated). I don't see why it should change, considering the fact that
device tree is generic, extensible and described by standards. There is no
place for any proprietary solutions here.
> 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).
This is mostly their problem. If they don't care about work duplication on
their side then why bother?
> > I don't
> > think it will be as hard as you may think it is. Start off by mapping
> > the existing fex syntax into a DTS file. Send your DTS file to
> > devicetree-discuss to get help with the correct syntax. Once this DTS
> > template is constructed you can write a program to convert any fex
> > file into it.
>
> 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".
I'm not sure if I followed all the discussion (read
http://thread.gmane.org/gmane.linux.debian.devel.kernel/91136/focus=92096
which didn't seem to contain anything relevant), so I might not have the
full picture, but I'm going to put my two cents in.
I tend to disagree with your view. Is it really our task to convince such
companies to work with open source community? If they don't see the
benefit of doing so, then IMHO it's their loss and loss of their customers
and end users. There are so many vendors backing open source at the moment
and they somehow don't have problems like this.
> 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.
>
> so if that is to truly be accepted, it has to be framed in such a way
> that it will be clearly of financial benefit to the SoC vendor.
>
> can you provide such a supporting argument which would convince
> allwinner to accept the modifications to their working practices that
> you propose?
There is one, very simple. If they don't, there is no community
cooperation for them, that's how it works. There is a set of unwritten (or
maybe even written) rules of open source communities that you must obey if
you want to work with them and you can't just get over that, because some
company don't want to change their practices.
Just see how many companies are backing open source at the moment, without
making problems like this. They have understood the benefits and taken the
effort to change their practices, because it was worth it. (I'm working
for such company at the moment and I can assure you that this is the
case.)
> > 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.
I tend to disagree on this as well, but it's another story. Have read one
of the discussions on this topic and it seemed to look more like lobbying
for one of the standards being promoted by some company, not anything
really close to the reality (where we can already successfully run
multiplatform kernels on platforms of different vendors...).
Best regards,
Tomasz
ons 2013-06-05 klockan 22:24 +0100 skrev Luke Kenneth Casson Leighton:
> And Then Some, stephen. there are two versions of u-boot being used:
> one is the community-assembled [GPL-compliant] one, and the other
> includes a [as-of-a-few-days-ago-but-no-longer, yay!]
> formerly-GPL-violating one from allwinner.
>
> the community-based one *doesn't* have fex integration (i don't
> think, but henrik will know for sure), but the allwinner one
> definitely does.
Correct.
> .... and then there's the boot0 and boot1 loaders, these *do* have
> fex integration: they're absolutely tiny and they're designed to fit
> into the 1st level cache. the job of these bootloaders is to set up
> the DDR3 RAM timings (so that you can access DRAM!!) and to then
> decide whether to load from NAND, SD/MMC etc. and many other things.
no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
(not cache), but boot1 is on pair with u-boot in size and runs from
DRAM.
boot0 do NOT read the script.bin at all. It can't, there isn't space
fore it. There is tools in the build process that reads the script.bin
and adds some information to a header of boot0, but it's irrelevant to
the device tree question. Exactly the same can be done from a device
tree, or from a fex, it does not matter.
even most of boot1 is not using script.bin. The important parameters are
all recorded in a heaeder of boot1 when the image is composed using the
Allwinner pack tools. Currently based on those tools reading script.bin
to prepare the boot1 part of the image.
> these boot0 and boot1 loaders are themselves configureable so that
> you can specify, through script.fex, what GPIO is to be the "reset
> key" and so on. that's a much simplified story btw.
No. That info is in the boot0 and boot1 file headers, not script.bin.
> so the point is: if anyone wishes me to propose to allwinner that
> they convert over to devicetree, or any other proposal which involves
> significant low-level changes to their working practices that could
> potentially have a massive knock-on effect onto their
> multi-million-dollar clients, it had better be a damn good story.
Calm down. It isn't really a significant difference to them outside of
the kernel. They do not need to change any of their configuraiton
methods, only a small toolchain change in how the resultig images are
built to have a corresponding device tree built.
But it is a fair bit of one-time changes kernel side. And some
scratching to figure out how to use/improve/ignore the stuff being
mainlined.
Regards
Henrik
[ 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
<[email protected]> 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
future].
* 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 dropbox.com" - i'm exaggerating there but only
slightly.
... 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.
l.
On Wednesday 05 of June 2013 16:48:27 [email protected] wrote:
> On Wed, Jun 5, 2013 at 3:46 PM, Luke Kenneth Casson Leighton
>
> <[email protected]> wrote:
> > On Fri, May 31, 2013 at 3:52 AM, Ben Hutchings <[email protected]>
wrote:
> > > The 3.8.y branch is over, so I think we have to move to 3.9, ready
> > > or
> > > not. I merged the work in progress from trunk to sid and am going
> > > through the config changes at the moment.
> > >
> > > I'm rather disappointed that nothing at all has been committed by
> > > ARM
> > > porters to either branch in the last month.
> >
> > *sigh* i didn't want to leave this as it stood, ben, purely for the
> >
> > reason that i don't want to see you discouraged! but, i also had to
> > think a bit about what potentially to say.
> >
> > the one SoC family that's going to become increasingly important to
> >
> > have both upstream and in debian is support for allwinner's
> > processors. with 40% world-wide tablet market share [*0], they must
> > be doing something right, and it's basically getting a staggering
> > price-performance value as well as having a set of interfaces and
> > level of integration that is really second to none.
> >
> > to begin to describe the problem in getting allwinner soc source code
> >
> > upstream is this: not only do we have the usual "let's get it out the
> > door as fast as possible" learning curve of a very young, very new and
> > bewilderingly-successful fabless SoC company, but we also have a
> > completely new type of very successful and comprehensive
> > device-tree-like dynamic configuration system to deal with, which
> > allwinner have called "fex" [*1].
> >
> > basically at the time when device-tree was being thought of,
> >
> > allwinner needed something that they could *right then* - not waiting
> > for developers to finish device-tree - they needed to be able to
> > reconfigure their customer's kernels *without* needing a recompile.
> > so they invented the script.fex system, which is a simple config.ini
> > file-format, compile it to binary, and get the bootloader to upload it
> > to memory and read it.
>
> Why don't you try converting the sunxi code over to device tree? I
> don't think it will be as hard as you may think it is. Start off by
> mapping the existing fex syntax into a DTS file. Send your DTS file to
> devicetree-discuss to get help with the correct syntax. Once this DTS
> template is constructed you can write a program to convert any fex
> file into it.
>
> Now boot with this DTB; that will get all of the existing info into
> the kernel's internal FDT. Then start converting your drivers over to
> use the of_ support for accessing the FDT. You've already done all of
> the hard work in making the drivers configurable at boot. As a
> transition tool allow the kernel to boot with both fex and DT untill
> you get all of the drivers converted.
>
> BTW, device tree has been in the kernel since 2007 (or earlier).
> About two years ago the ARM community decided to switch all new
> development onto it in order to stop the proliferation of
> platform/machine files. I believe the rule about no new non-DT ARM
> platforms has been in place for over eighteen months.
Well, it not only has been in the kernel, but has been extensively used
for PowerPC. Not even saying that the idea started even earlier,
originating from OpenFirmware.
Allwinner has just reinvented a wheel, without even considering the fact
that it has been already invented. This is actually not so uncommon plot,
because for such companies it is often easier to develop (or hack up) a
completely new solution without any supervision, than to extend an
existing solution that would need cooperation with community and (whoaa)
being compliant with open source policy.
IMHO this is completely wrong and can't be justified. Not even saying
about adopting such solution now that we already have a standard and
widely accepted one, which they could have used as well.
Best regards,
Tomasz
On Wed, Jun 05, 2013 at 05:38:45PM -0400, Lennart Sorensen wrote:
> I haven't personally dealt with any nvidia arm devices, so I have no
> idea how those are turning out, nor have I looked much at the marvell
> ones yet (even though I have a cubox sitting on my desk I intend to play
> around with).
Cubox is Dove, which dates from way before DT on ARM, and there's
relatively few people working on Dove support, so progress towards
DT support is rather slow there. I believe it to be at the point
where it's possible to boot the Cubox using DT, but not all features
are supported.
But then, not all features of the Dove SoC are supported in mainline
either; the port essentially stopped after a little more than basic
support was merged. Eg, no hardware monitoring driver, no video
drivers, etc...
On Wed, Jun 5, 2013 at 10:47 PM, Henrik Nordström
<[email protected]> 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
On Wednesday 05 of June 2013 22:16:37 Russell King - ARM Linux wrote:
> 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,
> 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.
>
> $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.
>
> 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.
>
> 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.
>
> But no... all that had to be created in this custom fex stuff which now
> presents a barrier with getting support for something merged.
>
> And somehow people make out that this is _our_ problem...
Well said. And the problem is that this is not the first and probably not
the last such case.
Best regards,
Tomasz
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.
> 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?
> 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.
licesuit 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.
> > 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.
Regards
enrik
On Wed, Jun 5, 2013 at 10:52 PM, Tomasz Figa <[email protected]> wrote:
> Hi Luke,
allo tomasz :)
ok - much of what you say is duplicated by what russell said, so in
effect the same reply is relevant, but there's been some cross-over.
i'll summarise below and cut all but the key question below:
> I tend to disagree with your view. Is it really our task to convince such
> companies to work with open source community?
their sheer overwhelming success provides us with mass-volume
ultra-low cost hardware. to not make an effort to accommodate them
would in this specific instance be a huge missed opportunity,
responsibility for which currently falls on the shoulders of the sunxi
community, where that small community is in no way considered
"authoritative" as an upstream source and thus every single GNU/Linux
Distro is left in a position of forcing people to follow insane
non-standard build procedures that are *way* outside of the capability
of the average person.
so by the linux kernel developers intransigent position, the reach of
free software as a whole is greatly reduced. simple logical
unavoidable conclusion.
please feel free - linux kernel developers - to maintain this
intransigent position for as long as you find it useful to you to do
so. btw, that is a sincere statement, devoid and completely free of
all and any implicit or explicit additional statements and
implications.
>> > 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.
>
> I tend to disagree on this as well, but it's another story. Have read one
> of the discussions on this topic and it seemed to look more like lobbying
> for one of the standards being promoted by some company,
yeahh, that's rather unfortunate. i went to some lengths to avoid
mentioning eoma [*1] until there was a natural point at which it
became difficult *not* to bring it up, not least because i didn't hear
anyone else presenting any actual real workable solutions.
but, you have to bear in mind a couple of things:
a) i'm a free software developer and advocate. "business", "lobbying"
etc. do not come naturally to me. my associates scream at me
regularly.
b) i've been thinking about this incredibly hard problem for at least
4 years and almost *all* of my background in computing of the past 30
years leads me naturally towards actually coming up with a solution
c) i'm actually really, really really and truly going about *actively*
implementing that solution rather than just complaining about it *and*
i'm inviting free software developers to participate, why, because see
first sentence of a) above.
l.
[*1] which is an open standard, not a proprietary locked one.
On Wed, Jun 05, 2013 at 08:46:30PM +0100, Luke Kenneth Casson Leighton wrote:
> to begin to describe the problem in getting allwinner soc source code
> upstream is this: not only do we have the usual "let's get it out the
> door as fast as possible" learning curve of a very young, very new and
> bewilderingly-successful fabless SoC company, but we also have a
> completely new type of very successful and comprehensive
> device-tree-like dynamic configuration system to deal with, which
> allwinner have called "fex" [*1].
IBM for example pushs the code into the kernel before the silicon is
even finished. Once a driver was removed because the project was
scrapped before it reached the customers. Arm did the same for the 64bit
variant of the architecture.
Are the turn around times for the allwinner SoC stuff really shorter
then two kernel releases?
> basically at the time when device-tree was being thought of,
> allwinner needed something that they could *right then* - not waiting
> for developers to finish device-tree - they needed to be able to
> reconfigure their customer's kernels *without* needing a recompile.
> so they invented the script.fex system, which is a simple config.ini
> file-format, compile it to binary, and get the bootloader to upload it
> to memory and read it.
So it was invented over five years ago? What did you do in the last two
years since it was finished in all its glory?
> what's the point of mentioning this?
Obviously nothing, as the decision stands.
> well, the point is: the expectation of the linux kernel developers is
> that Everyone Must Convert To DeviceTree. implicitly behind that is,
> i believe, an expectation that if you *don't* convert to Device Tree,
> you can kiss upstream submission goodbye. and, in allwinner's case,
> that's simply not going to happen.
Yes. Our project, our rules. If you don't like them, go away.
> add to this the fact that they've already taken *five* near-identical
> copies of each version of their drivers (for sun3i up to sun7i) - if
> you do a recursive diff in the drivers/usb/sun7i_usb and
> drivers/usb/sun4i_usb directories, the discrepancies are negligeable
> (and are in many cases a regression, reintroducing known or new
> bugs!), you can start to see that they simply have no idea how to work
> with the free software community (they're too busy) and that they're
> not really about to start, either.
Send patches as everyone else.
Bastian
--
I've already got a female to worry about. Her name is the Enterprise.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0
On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
<[email protected]> wrote:
>> .... and then there's the boot0 and boot1 loaders, these *do* have
> no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
> (not cache), but boot1 is on pair with u-boot in size and runs from
> DRAM.
btw, please listen to henrik: he knows what he's talking about, as
you can see :) henrik, thank you for correcting my technical
misunderstandings, i'll try to remember them and not propagate
incorrect stuff.
>> so the point is: if anyone wishes me to propose to allwinner that
>> they convert over to devicetree, or any other proposal which involves
>> significant low-level changes to their working practices that could
>> potentially have a massive knock-on effect onto their
>> multi-million-dollar clients, it had better be a damn good story.
>
> Calm down.
i am - honest! yes it's a little past my bed-time, but hey...
> It isn't really a significant difference to them outside of
> the kernel. They do not need to change any of their configuraiton
> methods, only a small toolchain change in how the resultig images are
> built to have a corresponding device tree built.
henrik, jon (smirl), can i ask you both a favour? could you write
something up, preferably short, that i could put forward to allwinner?
describing what's needed, who would need to do what and so on.
> But it is a fair bit of one-time changes kernel side. And some
> scratching to figure out how to use/improve/ignore the stuff being
> mainlined.
i still also - really - need a good justification for this.
something which helps explain clearly what the immediate or perhaps
strategic benefits would be to allwinner, as to why they should accept
such changes. i cannot emphasise enough how important that is.
if someone can please help come up with a good justification as to
why allwinner should change their working practices, that would be
enormously helpful i feel, to solving this issue.
otherwise we are stuck in the current situation which nobody really
likes. i'm inviting you - linux kernel developers - i'm giving you an
opportunity to *fix* things. you have 2 weeks to come up with a
solution, which can be presented in a simple format. that's the
window of opportunity.
l.
On 06/05/2013 03:59 PM, Henrik Nordström wrote:
> ons 2013-06-05 klockan 22:24 +0100 skrev Luke Kenneth Casson Leighton:
...
>> so the point is: if anyone wishes me to propose to allwinner that
>> they convert over to devicetree, or any other proposal which involves
>> significant low-level changes to their working practices that could
>> potentially have a massive knock-on effect onto their
>> multi-million-dollar clients, it had better be a damn good story.
>
> Calm down. It isn't really a significant difference to them outside of
> the kernel. They do not need to change any of their configuraiton
> methods, only a small toolchain change in how the resultig images are
> built to have a corresponding device tree built.
If U-Boot needs to be parametrized, there are in theory a few options open:
1) Put all the parameters in the U-Boot configuration header. This is
normal.
2) Read some data structure at run-time. This data structure could in
theory be some SoC-specific blob format (e.g. the packed version of
information that some tool extracts from FEX/DT), a whole FEX blob, or
device tree. The U-Boot maintainers have already indicated that they
won't accept the first two options; run-time configuration has to be via
DT, and not via some SoC-specific mechanism. (As I found out to my
detriment when I attempted to make U-Boot on Tegra determine which UART
to use for debug at run-time by reading the configuration header that
our boot ROM uses). Now of course, boot0/boot1 could always transform
whatever data structure they wish into a DTB before passing that to
U-Boot...
[removing debian-release again - at their request]
On Wed, Jun 5, 2013 at 11:11 PM, Tomasz Figa <[email protected]> wrote:
> Allwinner has just reinvented a wheel, without even considering the fact
> that it has been already invented.
apologies, tomasz, but i believe i covered this issue in, again, my
reply to russell, in which i point out that the both the context as
well as the scope of the problem being solved is entirely different
from that which the linux kernel developers find themselves in. also,
we note from what russell said, was that device tree wasn't ready for
commercial deployment; allwinner's developers don't speak english, and
additionally a fabless semiconductor company need to maintain absolute
commercial secrecy at the all-critical time when they're doing
FPGA-based testing of their netlists (yes, really: running linux on a
huge $250k's worth of FPGAs) and haven't yet put the design into
actual silicon.
so there's a lot of factors which i believe the linux kernel
developers are not aware of, and haven't taken into account, and to
place blame onto the SoC vendors for not working with *you* when *you*
haven't made an effort to understand their situation is, i feel, not
really helping anyone. not that i'm one to talk about understanding
people, but hey... :)
l.
On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton <[email protected]> wrote:
> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordstr?m
> <[email protected]> wrote:
>
>>> .... and then there's the boot0 and boot1 loaders, these *do* have
>
>> no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
>> (not cache), but boot1 is on pair with u-boot in size and runs from
>> DRAM.
>
> btw, please listen to henrik: he knows what he's talking about, as
> you can see :) henrik, thank you for correcting my technical
> misunderstandings, i'll try to remember them and not propagate
> incorrect stuff.
This is not about the fex syntax or uboot. The root problem is needing
two sets of binding for every device driver in the kernel. Pick a
random driver like gpio-pca953x.c and look at the source. In that file
there are #ifdef CONFIG_OF_ sections. Those sections are directly
reading the FDT binary via calls like of_get_property(node,
"linux,gpio-base", &size);. If fex is added to the kernel every driver
driver will now need both a #ifdef CONFIG_OF_ section and also a
#ifdef CONFIG_FEX_ section. Doing that is just crazy. Is Allwinner
going to add fex support to every single device driver in the kernel?
Of course not, that task is far too large. What Allwinner needs to do
is come onto the common API that everyone else is using.
So consider what is going to happen if you try to use a pca953x chip
in an Allwinner system. You're going to have to rewrite part of the
device driver. You're going to have to do that for every chip you try
to use. Those forks won't be accepted back into the kernel, etc. And
you'll end up as yet another port and forget embedded developer.
As for uboot I hope you are using the SPL support and haven't
reimplemented it. If the full uboot has been modified to dynamically
read a script.bin then it shouldn't be much of a stretch to teach it
about FDT instead. That would be a useful feature to add to mainline
uboot.
As for fex2bin and bin2fex you already have the equivalent tool on
your machine. It is called dtc. Check out scripts/dtc.
So if you are in love with fex syntax write a script that converts it
into device tree syntax. Then compile the DTS using dtc into a DTB.
When the DTB is in memory it is a FDT (flattened device tree). It's
that FDT format in memory that has become fixed in stone.
--
Jon Smirl
[email protected]
ons 2013-06-05 klockan 16:54 -0600 skrev Stephen Warren:
> 1) Put all the parameters in the U-Boot configuration header. This is
> normal.
Yes, we do so today for U-Boot SPL. But this won't fit very well with
the Allwinner ODM workflow where one binary image works on a wide range
of board configurations probed while flashing the image to the board,
but on the other hand there is no real need for them to use u-boot as
the primary boot loader, just keep using boot0 + boot1 + u-boot chain as
they have always done.
> 2) Read some data structure at run-time. This data structure could in
> theory be some SoC-specific blob format (e.g. the packed version of
> information that some tool extracts from FEX/DT), a whole FEX blob, or
> device tree.
This is likely to happen for the sunxi U-Boot SPL due to the sheer
amount of boards involved, and is done to some extents for other boards
as well. In the SPL there generally isn't room for full DT support. Main
u-boot HW configuration could be done runtime via DT alone but we are
not quite there yet, nothing major missing however other than getting it
done.
Regards
Henrik
On Thu, Jun 6, 2013 at 12:07 AM, [email protected] <[email protected]> wrote:
> On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton <[email protected]> wrote:
>> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
>> <[email protected]> wrote:
>>
>>>> .... and then there's the boot0 and boot1 loaders, these *do* have
>>
>>> no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
>>> (not cache), but boot1 is on pair with u-boot in size and runs from
>>> DRAM.
>>
>> btw, please listen to henrik: he knows what he's talking about, as
>> you can see :) henrik, thank you for correcting my technical
>> misunderstandings, i'll try to remember them and not propagate
>> incorrect stuff.
>
> This is not about the fex syntax or uboot. The root problem is needing
> two sets of binding for every device driver in the kernel. Pick a
> random driver like gpio-pca953x.c and look at the source. In that file
> there are #ifdef CONFIG_OF_ sections. Those sections are directly
> reading the FDT binary via calls like of_get_property(node,
> "linux,gpio-base", &size);. If fex is added to the kernel every driver
> driver will now need both a #ifdef CONFIG_OF_ section and also a
> #ifdef CONFIG_FEX_ section. Doing that is just crazy.
yes. which is why they haven't done it.
> Is Allwinner
> going to add fex support to every single device driver in the kernel?
no john - they've only added it to the multiplexed sections of the
drivers which they themselves have written. such as
drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
arch/arm/mach-sun{N}i and so on.
even the touchscreen driver that they wrote, that's got nothing to do
with any other code in the touchscreen linux kernel source tree: it's
more of a "meta-"driver which even has the name of the linux kernel
module that needs to be loaded and what I2C address, GPIO options etc.
to pass in [normally done as modprobe options in userspace].
to be honest, there are better people to fully answer this question
(alejandro and henrik are two that spring to mind) but you're
definitely off-base, jon. the script.fex system deals with the pinmux
issue in a very neat way that:
a) has very little impact on the rest of the kernel tree [citation
needed! i'm saying that: could someone please confirm if it's true]
b) the linux kernel developers could, instead of criticising it,
actually learn a great deal from.
l.
On Wednesday 05 of June 2013 23:38:52 Luke Kenneth Casson Leighton wrote:
> On Wed, Jun 5, 2013 at 10:52 PM, Tomasz Figa <[email protected]>
wrote:
> > Hi Luke,
>
> allo tomasz :)
>
> ok - much of what you say is duplicated by what russell said, so in
> effect the same reply is relevant, but there's been some cross-over.
>
> i'll summarise below and cut all but the key question below:
> > I tend to disagree with your view. Is it really our task to convince
> > such companies to work with open source community?
>
> their sheer overwhelming success provides us with mass-volume
> ultra-low cost hardware. to not make an effort to accommodate them
> would in this specific instance be a huge missed opportunity,
> responsibility for which currently falls on the shoulders of the sunxi
> community, where that small community is in no way considered
> "authoritative" as an upstream source and thus every single GNU/Linux
> Distro is left in a position of forcing people to follow insane
> non-standard build procedures that are *way* outside of the capability
> of the average person.
>
> so by the linux kernel developers intransigent position, the reach of
> free software as a whole is greatly reduced. simple logical
> unavoidable conclusion.
>
> please feel free - linux kernel developers - to maintain this
> intransigent position for as long as you find it useful to you to do
> so. btw, that is a sincere statement, devoid and completely free of
> all and any implicit or explicit additional statements and
> implications.
OK, this is a large volume of hardware that can be used to run free
software, point taken.
Still, I wouldn't really bind having this platform fully upstreamed with
possibility to run Linux on it. You can take Debian or whatever and just
boot it with Allwinner's kernel. Sure, probably distribution people would
shout here about upstream kernel being the only supported, but maybe this
is the problem, not the lack of support for the platform in upstream
kernel?
I don't say that having mainline support for this platform wouldn't be
nice. Sure, it would. But if the company doesn't want to cooperate and
comply to existing rules, I don't think it can be helped.
> >> > 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.
> >
> > I tend to disagree on this as well, but it's another story. Have read
> > one of the discussions on this topic and it seemed to look more like
> > lobbying for one of the standards being promoted by some company,
>
> yeahh, that's rather unfortunate. i went to some lengths to avoid
> mentioning eoma [*1] until there was a natural point at which it
> became difficult *not* to bring it up, not least because i didn't hear
> anyone else presenting any actual real workable solutions.
>
> but, you have to bear in mind a couple of things:
>
> a) i'm a free software developer and advocate. "business", "lobbying"
> etc. do not come naturally to me. my associates scream at me
> regularly.
>
> b) i've been thinking about this incredibly hard problem for at least
> 4 years and almost *all* of my background in computing of the past 30
> years leads me naturally towards actually coming up with a solution
>
> c) i'm actually really, really really and truly going about *actively*
> implementing that solution rather than just complaining about it *and*
> i'm inviting free software developers to participate, why, because see
> first sentence of a) above.
Basically there are two possible solutions for this problem. You can
either change the hardware to be standardized or make the software handle
many different kinds of hardware. Using EOMA would be an example of the
former, while our approach with Device Tree represents the latter.
Now the key is that Linux is not just about supporting new platforms that
are going to show up in near future, but also existing ones, that can't be
magically made standardized. This makes it already too late for ARM for
such hardware solution, since there is a lot of platforms already not
using it. ARM64 would be more appropriate to go this way, but you would
have to make sure that all hardware designers adopt the standard (and I'm
pretty sure that at some point some low cost hardware design company would
do things in their own way anyway, breaking the whole idea, just as
Allwinner did to DT with FEX).
For existing ARM platforms all we can do is make a software-based
solution, which standardizes the way of hardware description, keeping the
need to describe the hardware by hand, which is necessary because of
hardware design.
Best regards,
Tomasz
On Wed, Jun 5, 2013 at 7:26 PM, luke.leighton <[email protected]> wrote:
> On Thu, Jun 6, 2013 at 12:07 AM, [email protected] <[email protected]> wrote:
>> On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton <[email protected]> wrote:
>>> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordstr?m
>>> <[email protected]> wrote:
>>>
>>>>> .... and then there's the boot0 and boot1 loaders, these *do* have
>>>
>>>> no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
>>>> (not cache), but boot1 is on pair with u-boot in size and runs from
>>>> DRAM.
>>>
>>> btw, please listen to henrik: he knows what he's talking about, as
>>> you can see :) henrik, thank you for correcting my technical
>>> misunderstandings, i'll try to remember them and not propagate
>>> incorrect stuff.
>>
>> This is not about the fex syntax or uboot. The root problem is needing
>> two sets of binding for every device driver in the kernel. Pick a
>> random driver like gpio-pca953x.c and look at the source. In that file
>> there are #ifdef CONFIG_OF_ sections. Those sections are directly
>> reading the FDT binary via calls like of_get_property(node,
>> "linux,gpio-base", &size);. If fex is added to the kernel every driver
>> driver will now need both a #ifdef CONFIG_OF_ section and also a
>> #ifdef CONFIG_FEX_ section. Doing that is just crazy.
>
> yes. which is why they haven't done it.
>
>> Is Allwinner
>> going to add fex support to every single device driver in the kernel?
>
> no john - they've only added it to the multiplexed sections of the
> drivers which they themselves have written. such as
> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
> arch/arm/mach-sun{N}i and so on.
>
> even the touchscreen driver that they wrote, that's got nothing to do
> with any other code in the touchscreen linux kernel source tree: it's
> more of a "meta-"driver which even has the name of the linux kernel
> module that needs to be loaded and what I2C address, GPIO options etc.
> to pass in [normally done as modprobe options in userspace].
>
> to be honest, there are better people to fully answer this question
> (alejandro and henrik are two that spring to mind) but you're
> definitely off-base, jon. the script.fex system deals with the pinmux
> issue in a very neat way that:
>
> a) has very little impact on the rest of the kernel tree [citation
> needed! i'm saying that: could someone please confirm if it's true]
>
> b) the linux kernel developers could, instead of criticising it,
> actually learn a great deal from.
>
> l.
--
Jon Smirl
[email protected]
On Wed, Jun 5, 2013 at 7:26 PM, luke.leighton <[email protected]> wrote:
> On Thu, Jun 6, 2013 at 12:07 AM, [email protected] <[email protected]> wrote:
>> On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton <[email protected]> wrote:
>>> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordstr?m
>>> <[email protected]> wrote:
>>>
>>>>> .... and then there's the boot0 and boot1 loaders, these *do* have
>>>
>>>> no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
>>>> (not cache), but boot1 is on pair with u-boot in size and runs from
>>>> DRAM.
>>>
>>> btw, please listen to henrik: he knows what he's talking about, as
>>> you can see :) henrik, thank you for correcting my technical
>>> misunderstandings, i'll try to remember them and not propagate
>>> incorrect stuff.
>>
>> This is not about the fex syntax or uboot. The root problem is needing
>> two sets of binding for every device driver in the kernel. Pick a
>> random driver like gpio-pca953x.c and look at the source. In that file
>> there are #ifdef CONFIG_OF_ sections. Those sections are directly
>> reading the FDT binary via calls like of_get_property(node,
>> "linux,gpio-base", &size);. If fex is added to the kernel every driver
>> driver will now need both a #ifdef CONFIG_OF_ section and also a
>> #ifdef CONFIG_FEX_ section. Doing that is just crazy.
>
> yes. which is why they haven't done it.
>
>> Is Allwinner
>> going to add fex support to every single device driver in the kernel?
>
> no john - they've only added it to the multiplexed sections of the
> drivers which they themselves have written. such as
> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
> arch/arm/mach-sun{N}i and so on.
>
> even the touchscreen driver that they wrote, that's got nothing to do
> with any other code in the touchscreen linux kernel source tree: it's
> more of a "meta-"driver which even has the name of the linux kernel
> module that needs to be loaded and what I2C address, GPIO options etc.
> to pass in [normally done as modprobe options in userspace].
>
> to be honest, there are better people to fully answer this question
> (alejandro and henrik are two that spring to mind) but you're
> definitely off-base, jon. the script.fex system deals with the pinmux
> issue in a very neat way that:
I have a Cubieboard and I have a pca9532 on my desk. Now I want to
attach this pca9532 to the Cubieboard so I wire them together on I2C.
How is the Allwinner kernel going to load the driver for the pca9532?
The mainline pca9532 driver does not understand fex so it can't read
the necessary initialization data.
Luke, you of all people should see what is going on. Take an EOMA
module based on an A10. Now plug it into ten different hosts with
widely varying hardware support - like each of the ten hosts has a
different lm-sensor type chip. Where are the fex drivers for those ten
different lm-sensor chips going to come from? We already have DT
support for them.
fex is only supported on the small number of peripheral chips
Allwinner has blessed. Use any chip outside of that set and it isn't
going to boot.
>
> a) has very little impact on the rest of the kernel tree [citation
> needed! i'm saying that: could someone please confirm if it's true]
>
> b) the linux kernel developers could, instead of criticising it,
> actually learn a great deal from.
>
> l.
--
Jon Smirl
[email protected]
tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:
> no john - they've only added it to the multiplexed sections of the
> drivers which they themselves have written. such as
> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
> arch/arm/mach-sun{N}i and so on.
And a number of SPI device drivers, USB device drivers, vendor provided
device drivers, ......
> the script.fex system deals with the pinmux issue in a very neat way that:
>
> a) has very little impact on the rest of the kernel tree [citation
> needed! i'm saying that: could someone please confirm if it's true]
Not really the case. Actually the opposite. DT have this as well, and
integrated in device probing. Allwinner need to hack every driver used
to add their gpio requests to have pinmuxing triggered.
It is just layered a bit differently when using DT.
Regards
Henrik
On Thu, Jun 6, 2013 at 12:27 AM, Tomasz Figa <[email protected]> wrote:
>> their sheer overwhelming success provides us with mass-volume
>> ultra-low cost hardware. to not make an effort to accommodate them
>> would in this specific instance be a huge missed opportunity,
> OK, this is a large volume of hardware that can be used to run free
> software, point taken.
as it's a shorter URL by 200% than the original it refers to here's a link:
http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-May/007532.html
the key bit is a dec 2012 china visit by the author of that [insanely
long, even by my standards] report, where he does a double-take,
believing that he's mis-heard due to his poor understanding of
chinese, and he *literally* goes into shock when he works out that
he's been told that the 7in tablet being offered to him, even before
"haggling", is $USD 35, and yet its specification neither blows nor
sucks.
with allwinner bringing out the A31, i really have absolutely no idea
how any other company is going to compete in this market, except by
adding extra value such as R.F. base-band and that's sewn up by
mediatek. the only saving grace for the competition is that
allwinner, due to their inexperience, bought the imgtec kool-aid and
deployed PowerVR's latest SGX545MP2 offering [*1]
> I don't say that having mainline support for this platform wouldn't be
> nice. Sure, it would. But if the company doesn't want to cooperate and
> comply to existing rules, I don't think it can be helped.
they've got no idea that there *are* any - they don't speak english!
(and the team has a manager who is a fucking dickhead, who amongst
other things has been responsible for disobeying the Director's
explicit instructions to be GPL-compliant as well as ordering the
team's engineers to create a script that destroys Allwinner Copyright
notices and replaces it with Copyright 2010-2017 reilllumatech.com,
but that's another story that's being addressed)
ok it's very late here tomasz, i'll read more of this tomorrow: i've
started the discussion but i am actually completely overwhelmed so may
have to leave it to people to get back to me with some options for
proposals preferably by the beginning of next week (10th june) at the
latest, to give allwinner an opportunity to go over this early.
i'd greatly appreciate if people could run the gamut from one extreme
to the other: ideas such as "why not put script.fex verbatim as a blob
into a device-tree entry" all the way through to "why not rip
script.fex out completely and convert everything to devicetree for
them".
l.
[*1] http://www.youtube.com/watch?v=W-HCb55X_XU - 35 minutes in. libv
talking about why for god's sake don't ever get involved with powervr.
On Thu, Jun 6, 2013 at 12:40 AM, [email protected] <[email protected]> wrote:
> I have a Cubieboard and I have a pca9532 on my desk. Now I want to
> attach this pca9532 to the Cubieboard so I wire them together on I2C.
>
> How is the Allwinner kernel going to load the driver for the pca9532?
> The mainline pca9532 driver does not understand fex so it can't read
> the necessary initialization data.
jon: you're immediately outside of the target market for which
allwinner designed and deployed script.fex.
> Luke, you of all people should see what is going on. Take an EOMA
> module based on an A10. Now plug it into ten different hosts with
> widely varying hardware support - like each of the ten hosts has a
> different lm-sensor type chip. Where are the fex drivers for those ten
> different lm-sensor chips going to come from? We already have DT
> support for them.
that's fantastic, because as you can see, the two systems complement
each other.
> fex is only supported on the small number of peripheral chips
> Allwinner has blessed. Use any chip outside of that set and it isn't
> going to boot.
eeexactly. i did say "target market".
so, we have a clear illustration that neither script.fex nor
devicetree actually help solve the "chip proliferation" problem. but
that's another story, and getting off-topic.
what i need is a clear set of proposals, discussed and then the best
one(s) that people can come up with be then summarised so that i can
get them clearly and succinctly across to allwinner, along with the
benefits to allwinner of each of the options.
time is of the essence, speaking of which i'm pushing things to the
limit including my health so i *really* have to go, i'm going to leave
this up to everyone to discuss, please nominate someone to email me
directly [on a different subject] so that i can read the proposals
summaries should people choose to write any.
thanks.
l.
On Thu, Jun 6, 2013 at 12:40 AM, Henrik Nordström
<[email protected]> wrote:
> tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:
>
>> no john - they've only added it to the multiplexed sections of the
>> drivers which they themselves have written. such as
>> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
>> arch/arm/mach-sun{N}i and so on.
>
> And a number of SPI device drivers, USB device drivers, vendor provided
> device drivers, ......
>
>> the script.fex system deals with the pinmux issue in a very neat way that:
>>
>> a) has very little impact on the rest of the kernel tree [citation
>> needed! i'm saying that: could someone please confirm if it's true]
>
> Not really the case. Actually the opposite. DT have this as well, and
> integrated in device probing. Allwinner need to hack every driver used
> to add their gpio requests to have pinmuxing triggered.
augh. ok. solutions. what are the solutions here?
l.
On Thursday 06 of June 2013 00:54:02 luke.leighton wrote:
> On Thu, Jun 6, 2013 at 12:40 AM, Henrik Nordstr?m
>
> <[email protected]> wrote:
> > tor 2013-06-06 klockan 00:26 +0100 skrev luke.leighton:
> >> no john - they've only added it to the multiplexed sections of the
> >>
> >> drivers which they themselves have written. such as
> >> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
> >> arch/arm/mach-sun{N}i and so on.
> >
> > And a number of SPI device drivers, USB device drivers, vendor
> > provided
> > device drivers, ......
> >
> >> the script.fex system deals with the pinmux issue in a very neat way
that:
> >> a) has very little impact on the rest of the kernel tree [citation
> >>
> >> needed! i'm saying that: could someone please confirm if it's true]
> >
> > Not really the case. Actually the opposite. DT have this as well, and
> > integrated in device probing. Allwinner need to hack every driver used
> > to add their gpio requests to have pinmuxing triggered.
>
> augh. ok. solutions. what are the solutions here?
I don't see any other solution here than moving all the Allwinner code to
DT (as it has been suggested in this thread several times already), as
this is the only hardware description method supported by ARM Linux.
Best regards,
Tomasz
tor 2013-06-06 klockan 00:52 +0100 skrev luke.leighton:
> > How is the Allwinner kernel going to load the driver for the pca9532?
> > The mainline pca9532 driver does not understand fex so it can't read
> > the necessary initialization data.
>
> jon: you're immediately outside of the target market for which
> allwinner designed and deployed script.fex.
You missed the point. Mainlne Kernel drivers do take advantege of DT to
ease their bindings and configuration, much further than the fex can
express.
The exact same thing is experienced in designing a tablet. You add a
pheriperal device, and it needs to be configured somehow. DT does this
and it integrated in the kernel framework. fex also attemtps in doing
part of this, but lacks integration and requires much more driver
patching to fly.
And I don't see how you can say that pca9532 is off the grid in the
target market. It would fit nicely as a key backlight / edge colour
controller in a tablet to give the tablet a personal touch.
> > fex is only supported on the small number of peripheral chips
> > Allwinner has blessed. Use any chip outside of that set and it isn't
> > going to boot.
>
> eeexactly. i did say "target market".
Yes you repeat that over an over. But what does it mean?
I think what you really mean is something else more in the line of "ODMs
not allowed to step outside a very narrow range of possible designs or
using less than a handful approved providers", typical lockin
conditions. I don't know what you really mean here, only that it's not
"target market".
Regards
Henrik
tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton:
> > Not really the case. Actually the opposite. DT have this as well, and
> > integrated in device probing. Allwinner need to hack every driver used
> > to add their gpio requests to have pinmuxing triggered.
>
> augh. ok. solutions. what are the solutions here?
What I said before.
Go with DT for the kernel. There is no need for two configuration
mechanisms doing the same thing. Disguise it in fex form (and
translator) if too hard for people with a DOS editior to configure.
Regards
Henrik
ons 2013-06-05 klockan 23:20 +0100 skrev luke.leighton:
> 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?
Mainly a common infrastructure so they don't need to hack every driver
to work with their scheme.
But there is no way to escape from the fact that first round will be far
more complicated than just adding their own stuff as-is likely is. Many
of the upstreamed drivers are rewritten and far from their drivers.
And further complicated by their supported designs often using devices
(wifi modules, touch panels, nand chips, etc) where 3 year old barely
maintained vendor code actually works better than what is currently in
the upstream kernel.
So no, I can not say that there is an easy road ahead,
Regards
Henri
On Wed, Jun 05, 2013 at 11:56:43PM +0100, Luke Kenneth Casson Leighton wrote:
> so there's a lot of factors which i believe the linux kernel
> developers are not aware of, and haven't taken into account, and to
> place blame onto the SoC vendors for not working with *you* when *you*
> haven't made an effort to understand their situation is, i feel, not
> really helping anyone. not that i'm one to talk about understanding
> people, but hey... :)
Wait, everyone in the world knows where we (Linux kernel developers)
are, and how to contact us, how are we supposed to know we are supposed
to go after these various companies and contact them directly?
So this SoC vendor doesn't want to merge their code upstream, fine, we
(kernel community) don't really care, and it's obvious the company
doesn't care, so what really is the issue here?
Eventually, the SoC will realize that they do need to get their code
merged, and we will still be here, as we aren't going anywhere. At that
point in time, we will be glad to review patches and code like we do
every day for all of the thousands of other companies we deal with on a
weekly basis.
I don't see the problem here, do you?
greg k-h
On Jun 6, 2013, at 12:07 AM, Luke Kenneth Casson Leighton <[email protected]> wrote:
> [ 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
> <[email protected]> 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
> future].
>
> * 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 dropbox.com" - i'm exaggerating there but only
> slightly.
>
> ... 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.
This is a bullshit excuse they do speak english
and I do work in Asia for lot of years and company like Allwinner do speak english
as we did work with them
And the ONLY point is that the culture difference that'a all
Best Regards,
J.-
Dear Tomasz Figa,
On Thu, 06 Jun 2013 02:01:14 +0200, Tomasz Figa wrote:
> I don't see any other solution here than moving all the Allwinner
> code to DT (as it has been suggested in this thread several times
> already), as this is the only hardware description method supported
> by ARM Linux.
Have you noticed that it is already the case in mainline? My colleague
Maxime Ripard (Cc'ed) is the maintainer of the mainline Allwinner sunxi
effort. It already supports a number of boards, has a pinctrl driver, a
GPIO driver, serial port is working, network is working, I2C is
working.
All in mainline, completely Device Tree based.
So isn't this entire discussion completely moot? The mainline support
for sunxi has already started since 6 months or so, and has been Device
Tree based from day one.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Hello,
On Wed, 5 Jun 2013 16:48:27 -0400, [email protected] wrote:
> > fex covers *eeeeeevvveeerryyyythiiiing* - right from flipping the
> > multiplexing for all 3 SD/MMC cards so that you can pretend that SD0
> > is SD2 and you can specify *different* GPIOs for each to say which
> > is
>
> You can do all of this in device tree too. If the exact syntax doesn't
> exist you can use 'allwinner,' prefixes on the node names.
> Also check out pinctrl so that it doesn't get reinvented.
Are people looking at the mainline source code?
There is already a pinctrl driver for sunxi platforms (i.e Allwinner
SoCs), it's at drivers/pinctrl/pinctrl-sunxi.c, and it's DT-based and
allows to describe the pin muxing in the Device Tree.
Cc'ing Maxime Ripard, who is the mach-sunxi maintainer in the mainline
kernel.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Thu, Jun 06, 2013 at 02:01:14AM +0200, Tomasz Figa wrote:
> I don't see any other solution here than moving all the Allwinner code to
> DT (as it has been suggested in this thread several times already), as
> this is the only hardware description method supported by ARM Linux.
Well, the server guys are working on ACPI - people could contribute to
that effort instead if they preferred (though I can see that they might
not!).
Hi Thomas,
On Thursday 06 of June 2013 11:27:23 Thomas Petazzoni wrote:
> Dear Tomasz Figa,
>
> On Thu, 06 Jun 2013 02:01:14 +0200, Tomasz Figa wrote:
> > I don't see any other solution here than moving all the Allwinner
> > code to DT (as it has been suggested in this thread several times
> > already), as this is the only hardware description method supported
> > by ARM Linux.
>
> Have you noticed that it is already the case in mainline? My colleague
> Maxime Ripard (Cc'ed) is the maintainer of the mainline Allwinner sunxi
> effort. It already supports a number of boards, has a pinctrl driver, a
> GPIO driver, serial port is working, network is working, I2C is
> working.
>
> All in mainline, completely Device Tree based.
>
> So isn't this entire discussion completely moot? The mainline support
> for sunxi has already started since 6 months or so, and has been Device
> Tree based from day one.
Sure, I've been observing the development of sunxi support since it
started.
This is the reason why any remaining Allwinner drivers must be converted
to use DT instead of this proprietary stuff as well, if they want to
upstream any of them.
Best regards,
Tomasz
On Thu, Jun 6, 2013 at 1:15 AM, Henrik Nordström
<[email protected]> wrote:
> conditions. I don't know what you really mean here, only that it's not
> "target market".
mass-volume tablet, mass-volume IPTV box. android OS, nothing else.
On Thu, Jun 6, 2013 at 1:19 AM, Henrik Nordström
<[email protected]> wrote:
> tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton:
>
>> > Not really the case. Actually the opposite. DT have this as well, and
>> > integrated in device probing. Allwinner need to hack every driver used
>> > to add their gpio requests to have pinmuxing triggered.
>>
>> augh. ok. solutions. what are the solutions here?
>
> What I said before.
idea: hook into devicetree gpio functions to allow script-fex gpio
functions to gain access in a separate module? that sort of thing.
> Go with DT for the kernel. There is no need for two configuration
> mechanisms doing the same thing. Disguise it in fex form (and
> translator) if too hard for people with a DOS editior to configure.
what methods for doing that. i need proposals. 4 days on the clock.
On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa <[email protected]> wrote:
> I don't see any other solution here than moving all the Allwinner code to
> DT (as it has been suggested in this thread several times already), as
> this is the only hardware description method supported by ARM Linux.
i repeat again: please state, explicitly and unequivocably that you -
linux kernel developers - are happy that the reach of linux and
gnu/linux OSes is dramatically reduced due to this intransigent
position.
or, tomasz, please state that you, tomasz, represent each and every
one of the linux kernel developers so that i do not need to keep
asking.
Luke,
On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa <[email protected]>
wrote:
> > I don't see any other solution here than moving all the Allwinner code
> > to DT (as it has been suggested in this thread several times
> > already), as this is the only hardware description method supported
> > by ARM Linux.
> i repeat again: please state, explicitly and unequivocably that you -
> linux kernel developers - are happy that the reach of linux and
> gnu/linux OSes is dramatically reduced due to this intransigent
> position.
>
> or, tomasz, please state that you, tomasz, represent each and every
> one of the linux kernel developers so that i do not need to keep
> asking.
I do not represent all linux kernel developers by any means. I am just
stating current policy of SoC/board support maintained by ARM Linux, which
is common for all Linux kernel devlopers, or at least ARM Linux kernel
developers.
Personally I am happy with numerous companies backing this policy and not
making problems like this with Allwinner and I am really surprised that
you are supporting a troublesome company like this.
There are many other SoC vendors making low cost SoCs, like Rockchip,
Boxchip, Telechips. Maybe they would be better candidates for being
promoted as vendors of choice for hardware running free software? (Just
saying, as I do not know anything about their view on this. There is a lot
of cheap tablets built using their products as well.)
Best regards,
Tomasz
On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa <[email protected]> wrote:
> Luke,
>
> On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
>> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa <[email protected]>
> wrote:
>> > I don't see any other solution here than moving all the Allwinner code
>> > to DT (as it has been suggested in this thread several times
>> > already), as this is the only hardware description method supported
>> > by ARM Linux.
>> i repeat again: please state, explicitly and unequivocably that you -
>> linux kernel developers - are happy that the reach of linux and
>> gnu/linux OSes is dramatically reduced due to this intransigent
>> position.
>>
>> or, tomasz, please state that you, tomasz, represent each and every
>> one of the linux kernel developers so that i do not need to keep
>> asking.
>
> I do not represent all linux kernel developers by any means. I am just
> stating current policy of SoC/board support maintained by ARM Linux, which
> is common for all Linux kernel devlopers, or at least ARM Linux kernel
> developers.
>
> Personally I am happy with numerous companies backing this policy and not
> making problems like this with Allwinner and I am really surprised that
> you are supporting a troublesome company like this.
you've not read what i've written tomasz.
> There are many other SoC vendors making low cost SoCs, like Rockchip,
> Boxchip,
boxchip *is* allwinner.
> Telechips. Maybe they would be better candidates for being
> promoted as vendors of choice for hardware running free software?
no, because they're not selling at a low-enough price with
high-enough integration. telechips and rockchip don't have the market
penetration.
and many other reasons.
> (Just
> saying, as I do not know anything about their view on this. There is a lot
> of cheap tablets built using their products as well.)
>
> Best regards,
> Tomasz
>
luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:19 AM, Henrik Nordström
> <[email protected]> wrote:
>> tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton:
>>
>>> > Not really the case. Actually the opposite. DT have this as well, and
>>> > integrated in device probing. Allwinner need to hack every driver used
>>> > to add their gpio requests to have pinmuxing triggered.
>>>
>>> augh. ok. solutions. what are the solutions here?
>>
>> What I said before.
>
> idea: hook into devicetree gpio functions to allow script-fex gpio
> functions to gain access in a separate module? that sort of thing.
>
>> Go with DT for the kernel. There is no need for two configuration
>> mechanisms doing the same thing. Disguise it in fex form (and
>> translator) if too hard for people with a DOS editior to configure.
>
> what methods for doing that. i need proposals. 4 days on the clock.
4 days? WTF? since when did setting an ultimatum to the kernel
community work?
On Thursday 06 of June 2013 13:49:38 luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa <[email protected]>
wrote:
> > Luke,
> >
> > On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
> >> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa <[email protected]>
> >
> > wrote:
> >> > I don't see any other solution here than moving all the Allwinner
> >> > code
> >> > to DT (as it has been suggested in this thread several times
> >> > already), as this is the only hardware description method supported
> >> > by ARM Linux.
> >>
> >> i repeat again: please state, explicitly and unequivocably that you
> >> -
> >>
> >> linux kernel developers - are happy that the reach of linux and
> >> gnu/linux OSes is dramatically reduced due to this intransigent
> >> position.
> >>
> >> or, tomasz, please state that you, tomasz, represent each and every
> >>
> >> one of the linux kernel developers so that i do not need to keep
> >> asking.
> >
> > I do not represent all linux kernel developers by any means. I am just
> > stating current policy of SoC/board support maintained by ARM Linux,
> > which is common for all Linux kernel devlopers, or at least ARM Linux
> > kernel developers.
> >
> > Personally I am happy with numerous companies backing this policy and
> > not making problems like this with Allwinner and I am really
> > surprised that you are supporting a troublesome company like this.
>
> you've not read what i've written tomasz.
I have.
> > There are many other SoC vendors making low cost SoCs, like Rockchip,
> > Boxchip,
>
> boxchip *is* allwinner.
Right, sorry. I am not really into this low cost hardware.
There is also AMLogic, though.
> > Telechips. Maybe they would be better candidates for being
> > promoted as vendors of choice for hardware running free software?
>
> no, because they're not selling at a low-enough price with
> high-enough integration. telechips and rockchip don't have the market
> penetration.
I do not have access to any numbers, so I am left to believe in what you
say. (Although here in Poland the cheap tablet market is almost evenly
divided between all those companies, you can find almost same amount of
tablets based on SoCs from each vendor.)
Best regards,
Tomasz
> and many other reasons.
>
> > (Just
> > saying, as I do not know anything about their view on this. There is a
> > lot of cheap tablets built using their products as well.)
> >
> > Best regards,
> > Tomasz
On Thu, Jun 06, 2013 at 01:24:57PM +0100, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa <[email protected]> wrote:
>
> > I don't see any other solution here than moving all the Allwinner code to
> > DT (as it has been suggested in this thread several times already), as
> > this is the only hardware description method supported by ARM Linux.
>
> i repeat again: please state, explicitly and unequivocably that you -
> linux kernel developers - are happy that the reach of linux and
> gnu/linux OSes is dramatically reduced due to this intransigent
> position.
If companies are going to go off and invent the square wheel, and that
makes *them* suffer the loss of being able to merge back into the
mainline kernel, thereby making *their* job of moving forward with
their kernel versions much harder, then yes, we *are* happy.
Companies will always do idiotic things; it's *them* and their users
who have to live with the results of that bad decision making process.
Eventually, the pain of being outside the mainline kernel will become
too great, especially if their users demand things like kernel upgrades
from them. Eventually, they will change.
And no, this isn't an intransigent position. This is reality given
that ARM already has way too much code in the Linux kernel and we're
trying to reduce that through the use of technologies like DT. The
last thing we need right now is for another "DT" like implementation
to come along which is only used on a minority of platforms - even if
the platform it is used on is successful.
The way this works is this:
- you either go with the policies which are set, or
- you change the policy as a whole because you have a technically
superior solution
What that means in this case is either you adopt DT, or you convince
everyone that DT isn't the solution, but your solution is, and we adopt
your solution for *everything* instead.
If neither of those are possible, then that's really not our problem,
and it's not _us_ who are being "intransigent".
On Thu, Jun 06, 2013 at 01:22:04PM +0100, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:19 AM, Henrik Nordstr?m
> <[email protected]> wrote:
> > tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton:
> >
> >> > Not really the case. Actually the opposite. DT have this as well, and
> >> > integrated in device probing. Allwinner need to hack every driver used
> >> > to add their gpio requests to have pinmuxing triggered.
> >>
> >> augh. ok. solutions. what are the solutions here?
> >
> > What I said before.
>
> idea: hook into devicetree gpio functions to allow script-fex gpio
> functions to gain access in a separate module? that sort of thing.
>
> > Go with DT for the kernel. There is no need for two configuration
> > mechanisms doing the same thing. Disguise it in fex form (and
> > translator) if too hard for people with a DOS editior to configure.
>
> what methods for doing that. i need proposals. 4 days on the clock.
No.
If you want to set time scales, please put up money to find the work to
come up with those proposals.
Virtually no one here is a charity; the charity days of open source are
long gone. Everyone needs money to put food in their mouths, and the
way this works is that those who pay the most get the time. That's the
nature of a open and free market.
What's more is that you have been given some good proposals already:
converting the fex description to DT for the kernel. Wow, that means you
can use the work which has already been done in the mainline kernel for
free! How cool is that!
On Thu, Jun 06, 2013 at 01:24:57PM +0100, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa <[email protected]> wrote:
>
> > I don't see any other solution here than moving all the Allwinner code to
> > DT (as it has been suggested in this thread several times already), as
> > this is the only hardware description method supported by ARM Linux.
>
> i repeat again: please state, explicitly and unequivocably that you -
> linux kernel developers - are happy that the reach of linux and
> gnu/linux OSes is dramatically reduced due to this intransigent
> position.
But that's not a true statement. You've said that Allwinner is
perfectly happy to carry code out of tree, by constantly porting their
hacks from mainline kernels.
For some of their customers, this will be acceptable to them. In
those cases, Linux will still be in use. Great! So claiming that the
reach of Linux will be "dramatically reduced" just is not a
supportable position.
For other (potential) customers, for whom mainline kernel support is
critically important, they will choose other hardware solutions that
are in the mainline kernel.
I don't see the problem here.
- Ted
On Thu, Jun 6, 2013 at 7:02 AM, Theodore Ts'o <[email protected]> wrote:
> On Thu, Jun 06, 2013 at 01:24:57PM +0100, luke.leighton wrote:
>> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa <[email protected]> wrote:
>>
>> > I don't see any other solution here than moving all the Allwinner code to
>> > DT (as it has been suggested in this thread several times already), as
>> > this is the only hardware description method supported by ARM Linux.
>>
>> i repeat again: please state, explicitly and unequivocably that you -
>> linux kernel developers - are happy that the reach of linux and
>> gnu/linux OSes is dramatically reduced due to this intransigent
>> position.
>
> But that's not a true statement. You've said that Allwinner is
> perfectly happy to carry code out of tree, by constantly porting their
> hacks from mainline kernels.
>
> For some of their customers, this will be acceptable to them. In
> those cases, Linux will still be in use. Great! So claiming that the
> reach of Linux will be "dramatically reduced" just is not a
> supportable position.
>
> For other (potential) customers, for whom mainline kernel support is
> critically important, they will choose other hardware solutions that
> are in the mainline kernel.
>
> I don't see the problem here.
This is all just a big storm in a cup. Mainline kernel support for
allwinner SoCs are already happening through hobby development by
Maxime Ripard and others. Allwinner are not yet actively
participating, but they're aware of it. The whole situation is a
non-issue.
If the vendor prefers to keep carrying their own code for a while,
they're free to. It makes more sense for them to move over to the
upstream code as they move forward with their kernel versions, but
they can do that on their own schedule.
We've seen all this before, it tends to turn out OK in the longer run.
-Olof
On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton <[email protected]> wrote:
> augh. ok. solutions. what are the solutions here?
Luke if you really want to fix this a good solution is to have
Allwinner join Linaro and provide an engineer to the Linaro effort.
That engineer will get educated on the right way to do kernel
development and he can pass that knowledge back to Allwinner each day
as he learns it.
Allwinner has expressed interest in the past in joining Linaro but the
price was too high. I believe there are cheaper options now for
joining. The benefits Allwinner receives from joining will far exceed
the cost of joining. The net result will likely be a reduction in the
amount they need to spend on in-house development since they will
learn how to better leverage other developer's work.
--
Jon Smirl
[email protected]
On Wed, Jun 05, 2013 at 11:38:52PM +0100, Luke Kenneth Casson Leighton wrote:
> their sheer overwhelming success provides us with mass-volume
> ultra-low cost hardware. to not make an effort to accommodate them
> would in this specific instance be a huge missed opportunity,
> responsibility for which currently falls on the shoulders of the sunxi
> community, where that small community is in no way considered
> "authoritative" as an upstream source and thus every single GNU/Linux
> Distro is left in a position of forcing people to follow insane
> non-standard build procedures that are *way* outside of the capability
> of the average person.
Who cares what their sales volume is.
If they are that successful perhaps they could afford to spend some
resources to fix the mess they have created.
> so by the linux kernel developers intransigent position, the reach of
> free software as a whole is greatly reduced. simple logical
> unavoidable conclusion.
Long term having maintainable code is important. Companies like the
maker of the allwinner come and go. Maybe in a yaer or two they will be
irrelevant after some much better design from another company takes over
the market. Perhaps even one sensible enough to work with the community
in the first place, rather than violate the GPL for a long time.
> please feel free - linux kernel developers - to maintain this
> intransigent position for as long as you find it useful to you to do
> so. btw, that is a sincere statement, devoid and completely free of
> all and any implicit or explicit additional statements and
> implications.
I have not seen anything mentioned that the allwinner proprietary fex
system does that devicetree does not already do. So there is no benefit
to anyone (except perhaps allwinner) to adding their system, and a lot
of disadvantages in terms of changes to lots of drivers. Life would
become much easier for allwinner customers if they did change to
devicetree. Suddenly a much larger selection of hardware becomes trivial
to include in designs. Upgrades to new kernels become easier. Life in
general becomes easier.
> yeahh, that's rather unfortunate. i went to some lengths to avoid
> mentioning eoma [*1] until there was a natural point at which it
> became difficult *not* to bring it up, not least because i didn't hear
> anyone else presenting any actual real workable solutions.
>
> but, you have to bear in mind a couple of things:
>
> a) i'm a free software developer and advocate. "business", "lobbying"
> etc. do not come naturally to me. my associates scream at me
> regularly.
>
> b) i've been thinking about this incredibly hard problem for at least
> 4 years and almost *all* of my background in computing of the past 30
> years leads me naturally towards actually coming up with a solution
>
> c) i'm actually really, really really and truly going about *actively*
> implementing that solution rather than just complaining about it *and*
> i'm inviting free software developers to participate, why, because see
> first sentence of a) above.
Well making a tool to convert the fex stuff to devicetree sure sounds
like it could be helpful to allwinner customers.
And if there is anything you know if that can't be represented in
devicetree, I am sure some people would like to know about it. I doubt
you can come up with anything though.
Clearly adding fex to the upstream kernel isn't a good idea and isn't
going to happen, so any "solution" has to involve getting allwinner to
use devicetree and making doing that as easy as possible.
> [*1] which is an open standard, not a proprietary locked one.
It will be interesting to see if it ever turns into anything, or gets
stuck as just an interesting idea that never took off.
I just checked for my freescale i.mx53, and it has devicetree support
as of 3.3 kernels. The TI chips I have looked at recently all use
devicetree, even the ones that have not yet been merged upstream.
The marvell armada 370 and xp both appear to have devicetree support.
Nvidia tegras appear to have devicetree support. not sure if any of
the qualcomm snapdragons have devicetree support yet.
It seems to me almost everyone else is getting on with doing devicetree,
and allwinner is the odd one out that just can't be bothered to get with
the program.
--
Len Sorensen
On Thu, Jun 6, 2013 at 8:13 AM, [email protected] <[email protected]> wrote:
> On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton <[email protected]> wrote:
>> augh. ok. solutions. what are the solutions here?
>
> Luke if you really want to fix this a good solution is to have
> Allwinner join Linaro and provide an engineer to the Linaro effort.
> That engineer will get educated on the right way to do kernel
> development and he can pass that knowledge back to Allwinner each day
> as he learns it.
There's no need for anybody to join Linaro to contribute upstream.
That's a crazy notion.
Listen, Allwinner isn't working in a vacuum, believe it or not. I've
talked to them, so has Arnd and other people working on ARM, including
Maxime Ripard, who's been reimplementing upstream support for their
platform. Everybody is interested in the right things happening, it's
just a matter of figuring out how to do it. The right people are
already talking.
> Allwinner has expressed interest in the past in joining Linaro but the
> price was too high. I believe there are cheaper options now for
> joining. The benefits Allwinner receives from joining will far exceed
> the cost of joining. The net result will likely be a reduction in the
> amount they need to spend on in-house development since they will
> learn how to better leverage other developer's work.
Uh, you're listing the benefits of doing upstream work, not of joining Linaro.
-Olof
Hi everyone,
On Thu, Jun 06, 2013 at 09:00:00AM -0700, Olof Johansson wrote:
> On Thu, Jun 6, 2013 at 8:13 AM, [email protected] <[email protected]> wrote:
> > On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton <[email protected]> wrote:
> >> augh. ok. solutions. what are the solutions here?
> >
> > Luke if you really want to fix this a good solution is to have
> > Allwinner join Linaro and provide an engineer to the Linaro effort.
> > That engineer will get educated on the right way to do kernel
> > development and he can pass that knowledge back to Allwinner each day
> > as he learns it.
>
> There's no need for anybody to join Linaro to contribute upstream.
> That's a crazy notion.
>
> Listen, Allwinner isn't working in a vacuum, believe it or not. I've
> talked to them, so has Arnd and other people working on ARM, including
> Maxime Ripard, who's been reimplementing upstream support for their
> platform. Everybody is interested in the right things happening, it's
> just a matter of figuring out how to do it. The right people are
> already talking.
I should also add that Allwinner not only talked to us already, but also
expressed interest in doing actual modern kernel development (like using
"recently" introduced kernel frameworks, like the clk framework).
I've received patches from them already for private reviews, they began
to show up on the kernel mailing lists, they asked to be CCed on the
patches I send upstream, they're even the one that reached out to me
when the early support for their chips was released. So, like Olof said,
they aren't in a vacuum, they are very aware of the mainline kernel and
speak a decent english.
So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
inferior (because not generic enough) to the device tree, but they show
interest on going down the mainline road.
tor 2013-06-06 klockan 13:19 +0100 skrev luke.leighton:
> mass-volume tablet, mass-volume IPTV box. android OS, nothing else.
Which still includes a number of possible configurations with different
i2c, spi, usb etc devices connected on the board. Because Allwinner is
not using mainline methods for configuration their customers are stuck
in only selecting between a very limited set of "Allwinner compatible"
auxillary chips (g-sensors, led controls, wifi modules, gps modules etc)
in their designs.
By using DT their customers are free to choose any device supported
mainline.
Regards
Henrik
tor 2013-06-06 klockan 13:22 +0100 skrev luke.leighton:
> idea: hook into devicetree gpio functions to allow script-fex gpio
functions to gain access in a separate module? that sort of thing.
No. Drop FEX from the kernel, use DT. There is no reason why the kernel
shold care about the FEX format.
Translate from FEX to DT where needed in the "firmware" image build
process to allow Allwinner to keep the FEX as hardware description to
the ODMs.
Regards
Henrik
On Thu, Jun 06, 2013 at 07:28:10PM +0200, Maxime Ripard wrote:
> I should also add that Allwinner not only talked to us already, but also
> expressed interest in doing actual modern kernel development (like using
> "recently" introduced kernel frameworks, like the clk framework).
>
> I've received patches from them already for private reviews, they began
> to show up on the kernel mailing lists, they asked to be CCed on the
> patches I send upstream, they're even the one that reached out to me
> when the early support for their chips was released. So, like Olof said,
> they aren't in a vacuum, they are very aware of the mainline kernel and
> speak a decent english.
>
> So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
> inferior (because not generic enough) to the device tree, but they show
> interest on going down the mainline road.
Well I hope they get there soon, because they sure have some very nice
chip designs at amazing prices.
--
Len Sorensen
On Thursday 06 June 2013, Maxime Ripard wrote:
> So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
> inferior (because not generic enough) to the device tree, but they show
> interest on going down the mainline road.
Right, and of course there is nothing special about that, everybody starts
out with they own even vendor tree (c), and as hardware support gets merged
upstream, the diff gets smaller, even though the code in the mainline
kernel is normally very different from what they started out with.
Chances are actually that the Allwinner (A10/A13/A20, not A31) platform may
end up being the first modern one that is fully supported upstream including
a GPU driver, since it is one of the obvious targets for the
reverse-engineering efforts. Ironically (given NVIDIA's reputation), the
Tegra platform is the strongest competitor I see in that race at the moment.
For all I can tell, things are progressing nicely, given that it's currently
a volunteer effort. If anyone needs things to move faster, I'd recommend
them to send money to free-electrons.com.
Arnd
On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic <[email protected]> wrote:
> 4 days? WTF? since when did setting an ultimatum to the kernel
> community work?
i was only informed of the opportunity 2 days ago, vladimir. this is
an important meeting. of course the linux kernel community is
entirely free to:
* completely ignore this opportunity
* continue to complain that soc vendors do not follow their
unilaterally-decided rules
* to continue to its chosen course of making unilateral decisions and
setting unilaterally-decided rules and to experience the consequences.
i'm extremely busy, vladimir, and i'm acting as the messenger here.
3 days remaining on the clock.
l.
luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic <[email protected]> wrote:
>
>> 4 days? WTF? since when did setting an ultimatum to the kernel
>> community work?
>
> i was only informed of the opportunity 2 days ago, vladimir. this is
> an important meeting. of course the linux kernel community is
> entirely free to:
>
> * completely ignore this opportunity
> * continue to complain that soc vendors do not follow their
> unilaterally-decided rules
SoC vendors are free to join the discussion, and many SoC vendors are
part of the kernel community, so calling this unilateral is plain wrong.
> 3 days remaining on the clock.
what catastrophic thing will happen when the time runs out?
On Thu, Jun 6, 2013 at 2:02 PM, Tomasz Figa <[email protected]> wrote:
> On Thursday 06 of June 2013 13:49:38 luke.leighton wrote:
>> On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa <[email protected]>
> wrote:
>> > Luke,
>> >
>> > On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
>> >> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa <[email protected]>
>> >
>> > wrote:
>> >> > I don't see any other solution here than moving all the Allwinner
>> >> > code
>> >> > to DT (as it has been suggested in this thread several times
>> >> > already), as this is the only hardware description method supported
>> >> > by ARM Linux.
>> >>
>> >> i repeat again: please state, explicitly and unequivocably that you
>> >> -
>> >>
>> >> linux kernel developers - are happy that the reach of linux and
>> >> gnu/linux OSes is dramatically reduced due to this intransigent
>> >> position.
>> >>
>> >> or, tomasz, please state that you, tomasz, represent each and every
>> >>
>> >> one of the linux kernel developers so that i do not need to keep
>> >> asking.
>> >
>> > I do not represent all linux kernel developers by any means. I am just
>> > stating current policy of SoC/board support maintained by ARM Linux,
>> > which is common for all Linux kernel devlopers, or at least ARM Linux
>> > kernel developers.
>> >
>> > Personally I am happy with numerous companies backing this policy and
>> > not making problems like this with Allwinner and I am really
>> > surprised that you are supporting a troublesome company like this.
>>
>> you've not read what i've written tomasz.
>
> I have.
>
>> > There are many other SoC vendors making low cost SoCs, like Rockchip,
>> > Boxchip,
>>
>> boxchip *is* allwinner.
>
> Right, sorry. I am not really into this low cost hardware.
i've been tracking it for several years.
> There is also AMLogic, though.
they're *definitely* GPL-violators.
>> > Telechips. Maybe they would be better candidates for being
>> > promoted as vendors of choice for hardware running free software?
>>
>> no, because they're not selling at a low-enough price with
>> high-enough integration. telechips and rockchip don't have the market
>> penetration.
>
> I do not have access to any numbers, so I am left to believe in what you
> say.
well... none of us do :) that report (was it from IDC? it was in
earlier messages) is a good analysis.
> (Although here in Poland the cheap tablet market is almost evenly
> divided between all those companies, you can find almost same amount of
> tablets based on SoCs from each vendor.)
most likely.
allwinner is the one that's actually expressed an interest, at
Director (Board) Level, of being GPL-compliant. the software
engineers understand that; their immediate Manager does not [and is
causing considerable disruption].
AMLogic stone-walled and cost us money and a large client due to
their GPL violations. which they till have not resolved [in over 2
years]. i will not work with them, ever again.
Telechips are korean-based: they haven't responded to communications.
Nufront got themselves in a muddle [late on silicon] so we ruled them
out - we'll come back to them later.
there's a number of others, but allwinner's the only one that is
actively communicating.
so.
coming back to what you said earlier: i'm formulating what to say to
allwinner [and need to pre-send something by monday so that they can
consider it before the meeting]. so far, it consists of:
* device-tree is what the linux kernel community has come up with, it
is equivalent to FEX.
* the linux kernel community would like to apologise for not
consulting with you (allwinner) on the decision to only accept device
tree
[bear in mind that if this kind of thing isn't said, they risk just
continuing to make the sunxi community's life absolute hell by
continuing to work in isolation and continuing to duplicate drivers
etc. etc. ]
* work is being done by the free software community, they are
beginning to integrate allwinner's work into the upstream kernel, and
you (allwinner) will begin to see this when you get round to doing
linux kernel 3.9
* allwinner and the linux and sunxi community therefore need to work
closer together, we propose:
* {insert proposals here}
3 days left on the clock.
l.
On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux
<[email protected]> wrote:
> If companies are going to go off and invent the square wheel, and that
> makes *them* suffer the loss of being able to merge back into the
> mainline kernel, thereby making *their* job of moving forward with
> their kernel versions much harder, then yes, we *are* happy.
russell: they have more employees than sense :) they also don't have
any idea of what they *should* be doing, so this is an opportunity to
educate them.
they're not feeling any pain: they just employ more chinese
developers and substitute bodies for time and common-sense.
also, in this particular case, thanks to their script.fex system when
i said they only need to develop one kernel and one u-boot i really
wasn't kidding around: they really have got to the point which
everyone else dreams of with device-tree [admittedly by limiting the
product range that their clients can play with, but that product range
has huge returns, so they're still happy].
> Companies will always do idiotic things; it's *them* and their users
> who have to live with the results of that bad decision making process.
russell: the decision process they've made is actually an extremely
effective one.
> Eventually, the pain of being outside the mainline kernel will become
> too great, especially if their users demand things like kernel upgrades
> from them. Eventually, they will change.
>
> And no, this isn't an intransigent position. This is reality given
> that ARM already has way too much code in the Linux kernel and we're
> trying to reduce that through the use of technologies like DT. The
> last thing we need right now is for another "DT" like implementation
> to come along which is only used on a minority of platforms - even if
> the platform it is used on is successful.
>
> The way this works is this:
> - you either go with the policies which are set, or
.... which they weren't consulted on, it has to be pointed out.
> - you change the policy as a whole because you have a technically
> superior solution
i believe they have a technically more *successful* solution. whether
it's more appropriate in a wider context is another matter.
here we have a key to the crux of the problem: the linux kernel
maintainers have to cater for _everyone_. with no funding or
incentive from the major contributors to work with them. hmmm....
> What that means in this case is either you adopt DT, or you convince
> everyone that DT isn't the solution, but your solution is, and we adopt
> your solution for *everything* instead.
>
> If neither of those are possible, then that's really not our problem,
> and it's not _us_ who are being "intransigent".
indeed.
ok. so. we come back to the question again: what shall i propose to
them that they consider doing, and what benefit would it be to them to
do so?
i cannot go to them and say "you have to do this [insert proposal
here]" - it has to be more subtle than that.
l.
On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic <[email protected]> wrote:
> luke.leighton wrote:
>>
>> On Thu, Jun 6, 2013 at 1:51 PM, Vladimir Pantelic <[email protected]>
>> wrote:
>>
>>> 4 days? WTF? since when did setting an ultimatum to the kernel
>>> community work?
>>
>>
>> i was only informed of the opportunity 2 days ago, vladimir. this is
>> an important meeting. of course the linux kernel community is
>> entirely free to:
>>
>> * completely ignore this opportunity
>> * continue to complain that soc vendors do not follow their
>> unilaterally-decided rules
>
>
> SoC vendors are free to join the discussion, and many SoC vendors are part
> of the kernel community, so calling this unilateral is plain wrong.
you're free to believe that, vladimir. i've explained why that
hasn't happened, in prior messages. can we move forward, please?
>
>> 3 days remaining on the clock.
>
>
> what catastrophic thing will happen when the time runs out?
no catastrophe, vladimir: all that happens is that an opportunity is
lost, and the result of that is that the situation remains as it is,
with a major soc vendor being divorced from and isolated from the free
software community, who will continue to have to shoulder the
frustrating and isolated burden of responsibility of reworking
"over-the-fence" kernel patches as best they can with the limited
resources that they have.
On 07/06/2013 10:06, luke.leighton wrote:
> On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic <[email protected]> wrote:
>> luke.leighton wrote:
>>> 3 days remaining on the clock.
>>
>> what catastrophic thing will happen when the time runs out?
> no catastrophe, vladimir: all that happens is that an opportunity is
> lost, and the result of that is that the situation remains as it is,
> with a major soc vendor being divorced from and isolated from the free
> software community, who will continue to have to shoulder the
> frustrating and isolated burden of responsibility of reworking
> "over-the-fence" kernel patches as best they can with the limited
> resources that they have.
I think the question was: what will be done in 3 days that cannot be
undone ? and you didn't answer that. I don't understand why your are
still stating that Allwinner will never be able to get code in the
mainline after Olof and Maxime told you that they are already working,
at least discussing with them.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
luke.leighton wrote:> so.
>
> coming back to what you said earlier: i'm formulating what to say to
> allwinner [and need to pre-send something by monday so that they can
> consider it before the meeting]. so far, it consists of:
>
> * device-tree is what the linux kernel community has come up with, it
> is equivalent to FEX.
>
> * the linux kernel community would like to apologise for not
> consulting with you (allwinner) on the decision to only accept device
> tree
apologize? WTF?
> * allwinner and the linux and sunxi community therefore need to work
> closer together, we propose:
>
> * {insert proposals here}
1) switch to DT
2) there is no 2)
> 3 days left on the clock.
tick tock
On Fri, Jun 07, 2013 at 09:02:43AM +0100, luke.leighton wrote:
> ok. so. we come back to the question again: what shall i propose to
> them that they consider doing, and what benefit would it be to them to
> do so?
>
> i cannot go to them and say "you have to do this [insert proposal
> here]" - it has to be more subtle than that.
It seems that you don't have to do anything at all. From what Arnd and
others have said, they are _already_ talking to, and working with people
in the kernel community to move their code base forward, move to DT, and
they are already starting to send their own patches for the mainline
kernel themselves.
On Friday 07 of June 2013 08:52:43 luke.leighton wrote:
> On Thu, Jun 6, 2013 at 2:02 PM, Tomasz Figa <[email protected]>
wrote:
> > On Thursday 06 of June 2013 13:49:38 luke.leighton wrote:
> >> On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa <[email protected]>
> >
> > wrote:
> >> > Luke,
> >> >
> >> > On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
> >> >> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa
> >> >> <[email protected]>
> >> >
> >> > wrote:
> >> >> > I don't see any other solution here than moving all the
> >> >> > Allwinner
> >> >> > code
> >> >> > to DT (as it has been suggested in this thread several times
> >> >> > already), as this is the only hardware description method
> >> >> > supported
> >> >> > by ARM Linux.
> >> >>
> >> >> i repeat again: please state, explicitly and unequivocably that
> >> >> you
> >> >> -
> >> >>
> >> >> linux kernel developers - are happy that the reach of linux and
> >> >> gnu/linux OSes is dramatically reduced due to this intransigent
> >> >> position.
> >> >>
> >> >> or, tomasz, please state that you, tomasz, represent each and
> >> >> every
> >> >>
> >> >> one of the linux kernel developers so that i do not need to keep
> >> >> asking.
> >> >
> >> > I do not represent all linux kernel developers by any means. I am
> >> > just
> >> > stating current policy of SoC/board support maintained by ARM
> >> > Linux,
> >> > which is common for all Linux kernel devlopers, or at least ARM
> >> > Linux
> >> > kernel developers.
> >> >
> >> > Personally I am happy with numerous companies backing this policy
> >> > and
> >> > not making problems like this with Allwinner and I am really
> >> > surprised that you are supporting a troublesome company like this.
> >>
> >> you've not read what i've written tomasz.
> >
> > I have.
> >
> >> > There are many other SoC vendors making low cost SoCs, like
> >> > Rockchip,
> >> > Boxchip,
> >>
> >> boxchip *is* allwinner.
> >
> > Right, sorry. I am not really into this low cost hardware.
>
> i've been tracking it for several years.
>
> > There is also AMLogic, though.
>
> they're *definitely* GPL-violators.
>
> >> > Telechips. Maybe they would be better candidates for being
> >> > promoted as vendors of choice for hardware running free software?
> >>
> >> no, because they're not selling at a low-enough price with
> >>
> >> high-enough integration. telechips and rockchip don't have the
> >> market
> >> penetration.
> >
> > I do not have access to any numbers, so I am left to believe in what
> > you say.
>
> well... none of us do :) that report (was it from IDC? it was in
> earlier messages) is a good analysis.
>
> > (Although here in Poland the cheap tablet market is almost evenly
> > divided between all those companies, you can find almost same amount
> > of
> > tablets based on SoCs from each vendor.)
>
> most likely.
>
> allwinner is the one that's actually expressed an interest, at
> Director (Board) Level, of being GPL-compliant. the software
> engineers understand that; their immediate Manager does not [and is
> causing considerable disruption].
>
> AMLogic stone-walled and cost us money and a large client due to
> their GPL violations. which they till have not resolved [in over 2
> years]. i will not work with them, ever again.
>
> Telechips are korean-based: they haven't responded to communications.
>
> Nufront got themselves in a muddle [late on silicon] so we ruled them
> out - we'll come back to them later.
>
> there's a number of others, but allwinner's the only one that is
> actively communicating.
>
> so.
>
> coming back to what you said earlier: i'm formulating what to say to
> allwinner [and need to pre-send something by monday so that they can
> consider it before the meeting]. so far, it consists of:
>
> * device-tree is what the linux kernel community has come up with, it
> is equivalent to FEX.
...before FEX ever existed...
> * the linux kernel community would like to apologise for not
> consulting with you (allwinner) on the decision to only accept device
> tree
>
> [bear in mind that if this kind of thing isn't said, they risk just
> continuing to make the sunxi community's life absolute hell by
> continuing to work in isolation and continuing to duplicate drivers
> etc. etc. ]
So basically you are making sure that they think they decision to reinvent
the wheel by using proprietary FEX was correct and our decision to use
generic, extensive and standard-based DeviceTree was self-oriented.
In addition you are telling them something completely opposite from how
the Linux kernel community (and probably any other open source community
works). This is _THEIR_ responsibility to consult things they do with us,
_NOT_ the other way around, if they want to work with upstream.
> * work is being done by the free software community, they are
> beginning to integrate allwinner's work into the upstream kernel, and
> you (allwinner) will begin to see this when you get round to doing
> linux kernel 3.9
>From what I could read from other posts in this thread they already know
this.
> * allwinner and the linux and sunxi community therefore need to work
> closer together, we propose:
- joining the mailing lists by Allwinner people to remove any messengers
from the way (don't say here that they don't speak English, as several
people clearly confirmed that they do...)
- adjusting their workflow to comply with rules of Linux kernel open
source community (i.e. sending RFCs, getting code reviewed, addressing
comments)
- reworking existing code to use widely-accepted, standard solutions
available in upstream Linux kernel (although this is already mostly done
by sunxi community)
> 3 days left on the clock.
By the way, I haven't seen any explanation from you who (and by what
means) gave you any authorization to speak on behalf of Allwinner or to
represent Linux kernel community for them.
Seeing from your posts you don't have any knowledge on how Linux kernel
development works and even on how Allwinner's cooperation with our
community looks (and seem to be completely closed to our effort of showing
you the reality), so I'm not sure if you are the right person to take any
of those roles...
I'd suggest Maxime Ripard or someone else from Free Electrons to be
responsible for communication with Allwinner instead.
Best regards,
Tomasz
On Fri, Jun 07, 2013 at 10:40:37AM +0200, Vladimir Pantelic wrote:
> luke.leighton wrote:> so.
> >
> > coming back to what you said earlier: i'm formulating what to say to
> > allwinner [and need to pre-send something by monday so that they can
> > consider it before the meeting]. so far, it consists of:
> >
> > * device-tree is what the linux kernel community has come up with, it
> > is equivalent to FEX.
> >
> > * the linux kernel community would like to apologise for not
> > consulting with you (allwinner) on the decision to only accept device
> > tree
>
> apologize? WTF?
(I don't seem to have the original mail).
Definitely not.
The way this generally works is that discussions happen in public on
mailing lists, and people who have an interest get involved in the
discussion. If someone decides to avoid the mailing lists because they
want to be secret about XYZ then they won't be part of the decision
making process - but that's not _our_ problem. That is _their_ problem.
In the case of DT, there was quite a lengthy discussion about it and
its adoption.
So, either the discussion took place _before_ there was any interest in
the ARM kernel developments from Allwinner, or they themselves _chose_
not to be represented in the discussion by not being on the mailing list
or participating in the discussion.
There is nothing for us to apologise for here.
(Occasionally, the kernel community *is* a dictatorship - for example,
when Linus threatens to delete all the ARM defconfigs, or when Linus
decides that we're running out of control when adding more than 10k
lines of new code per kernel release, or - in the same way - when I see
something I really don't like, but thankfully those are fairly rare.)
On Fri, Jun 07, 2013 at 09:48:22AM +0200, Vladimir Pantelic wrote:
> luke.leighton wrote:
>> 3 days remaining on the clock.
>
> what catastrophic thing will happen when the time runs out?
Maybe the world will explode into tiny small bits? Probably not. I
suspect nothing of any relevance to us.
As has already been pointed out, Allwinner is already working with
people in the kernel community to move things forward, so the right
things are already happening.
2013/6/7 Olof Johansson <[email protected]>:
> On Thu, Jun 6, 2013 at 8:13 AM, [email protected] <[email protected]> wrote:
>> On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton <[email protected]> wrote:
>>> augh. ok. solutions. what are the solutions here?
>>
>> Luke if you really want to fix this a good solution is to have
>> Allwinner join Linaro and provide an engineer to the Linaro effort.
>> That engineer will get educated on the right way to do kernel
>> development and he can pass that knowledge back to Allwinner each day
>> as he learns it.
>
> There's no need for anybody to join Linaro to contribute upstream.
> That's a crazy notion.
i do agree. i don't think there is any direct relationship between
linaro and upstream.
otherwise, we will be in pain as we are not linaro member too.
>
> Listen, Allwinner isn't working in a vacuum, believe it or not. I've
> talked to them, so has Arnd and other people working on ARM, including
> Maxime Ripard, who's been reimplementing upstream support for their
> platform. Everybody is interested in the right things happening, it's
> just a matter of figuring out how to do it. The right people are
> already talking.
>
>> Allwinner has expressed interest in the past in joining Linaro but the
>> price was too high. I believe there are cheaper options now for
>> joining. The benefits Allwinner receives from joining will far exceed
>> the cost of joining. The net result will likely be a reduction in the
>> amount they need to spend on in-house development since they will
>> learn how to better leverage other developer's work.
>
> Uh, you're listing the benefits of doing upstream work, not of joining Linaro.
>
>
> -Olof
thanks
barry
fre 2013-06-07 klockan 09:02 +0100 skrev luke.leighton:
> ok. so. we come back to the question again: what shall i propose to
> them that they consider doing, and what benefit would it be to them to
> do so?
Just tell them that the kernel is moving to a different configuration
syntax called Device Tree, but apart from updating kernel drivers to the
new way of configuring things it only have minor impact on their
envionment. It is still possible to use the fex file for all board
configuration details, only requires a small tool for translating fex to
device tree.
The change only impacts kernel, and a small change to their SDK build
scripts to also build the device tree from the fex.
It is no big deal really in structural terms. There is far bigger
structural changes in the kernel which coincides with this and will
require some developer time to adjust for. Had they upstreamed their
changes earlier then...
Regards
Henrik
Tomasz Figa <[email protected]>
writes:
> Seeing from your posts you don't have any knowledge on how Linux kernel
> development works and even on how Allwinner's cooperation with our
> community looks (and seem to be completely closed to our effort of showing
> you the reality), so I'm not sure if you are the right person to take any
> of those roles...
Try googling for "Luke Leighton troll". The pattern is some lengthy
semi-technical post, followed by very long threads with no substance
whatsoever. It seems like some sick joke trying to waste as much time
for as many people as possible.
He's even become an -ENOPATCH example:
http://linuxmafia.com/~rick/lexicon.html#enopatch
Bjørn
On Fri, Jun 07, 2013 at 08:52:43AM +0100, luke.leighton wrote:
> coming back to what you said earlier: i'm formulating what to say to
> allwinner [and need to pre-send something by monday so that they can
> consider it before the meeting]. so far, it consists of:
>
> * device-tree is what the linux kernel community has come up with, it
> is equivalent to FEX.
>From what I have seem looking at FEX, devicetree is vastly more powerful
and scalable than FEX. It is also a standard (IEEE1275) that has been
around for many years (given devicetree is using part of openfirmware).
> * the linux kernel community would like to apologise for not
> consulting with you (allwinner) on the decision to only accept device
> tree
I would consider that an enourmous lie. Devicetree was around long
before their company had ever started doing the allwinner. It might
not have been used in ARM yet, but it was used in a number of other
architectures, making it the obvious choice for doing the same thing on
more architectures.
> [bear in mind that if this kind of thing isn't said, they risk just
> continuing to make the sunxi community's life absolute hell by
> continuing to work in isolation and continuing to duplicate drivers
> etc. etc. ]
That is their problem (and their customers).
> * work is being done by the free software community, they are
> beginning to integrate allwinner's work into the upstream kernel, and
> you (allwinner) will begin to see this when you get round to doing
> linux kernel 3.9
If something is popular enough, people will work on getting it supported,
where supported means done properly.
> * allwinner and the linux and sunxi community therefore need to work
> closer together, we propose:
>
> * {insert proposals here}
How about allwinner simply tries to help with the activity already taking
place for getting everything working with devicetree. That probably
means doing work to their tools to generate devicetree files from their
FEX files, if they really like FEX (and think their customers like FEX).
> 3 days left on the clock.
Who cares what your deadline is. That's not how good choices are made.
--
Len Sorensen
> > SoC vendors are free to join the discussion, and many SoC vendors are part
> > of the kernel community, so calling this unilateral is plain wrong.
>
> you're free to believe that, vladimir. i've explained why that
> hasn't happened, in prior messages. can we move forward, please?
I prefer it if the "vladimir" troll (and fellow trolls)
make requests for one of us to make or do something instead of
constantly whining and wasting time.
After all we are attached to funds and resources ready to
deploy if something sounds a good idea and gets a vote.
To vladimir - please put your thoughts in a blog where it belongs.
If its important, I'm sure others would offer comment
and take you up on your thoughts.
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On 06/07/2013 02:02 AM, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux
> <[email protected]> wrote:
>
>> If companies are going to go off and invent the square wheel, and that
>> makes *them* suffer the loss of being able to merge back into the
>> mainline kernel, thereby making *their* job of moving forward with
>> their kernel versions much harder, then yes, we *are* happy.
>
> russell: they have more employees than sense :) they also don't have
> any idea of what they *should* be doing, so this is an opportunity to
> educate them.
You know, they're probably reading this thread, and if not, they
certainly can in the list archives. It's probably not a good idea to
slag them off like that, and like other comments in this thread...
On Fri, Jun 7, 2013 at 9:18 AM, Alexandre Belloni
<[email protected]> wrote:
> On 07/06/2013 10:06, luke.leighton wrote:
>> On Fri, Jun 7, 2013 at 8:48 AM, Vladimir Pantelic <[email protected]> wrote:
>>> luke.leighton wrote:
>>>> 3 days remaining on the clock.
>>>
>>> what catastrophic thing will happen when the time runs out?
>> no catastrophe, vladimir: all that happens is that an opportunity is
>> lost, and the result of that is that the situation remains as it is,
>> with a major soc vendor being divorced from and isolated from the free
>> software community, who will continue to have to shoulder the
>> frustrating and isolated burden of responsibility of reworking
>> "over-the-fence" kernel patches as best they can with the limited
>> resources that they have.
>
> I think the question was: what will be done in 3 days that cannot be
> undone ? and you didn't answer that.
apologies for not being clear. there is nothing that cannot be
"undone". i trust that that answers the specific question you've
asked.
let me try to put it into "undo" words.
this is about me (a messenger) offering you plural (the linux kernel
community) an opportunity to "undo" the
mess-that-is-perceived-to-be-the-case wrt one specific SoC vendor,
named "Allwinner".
let me try to put it another way. i cannot specifically state
EXACTLY what will "be done", because i do not have authorisation to
make that publicly known. i am trying hard to hint at what can be
"done", and the deadline is monday 10th june 2013 to get a clear
proposal in which will make its way to allwinner, by means that i
cannot specifically tell you about because i do not have the specific
authorisation or permission to tell you.
does that point you in the right direction?
can we please get on with taking advantage of this opportunity and
discuss options that can be presented, instead of asking these kinds
of questions?
> I don't understand why your are
> still stating that Allwinner will never be able to get code in the
> mainline
i didn't say that. apologies if that wasn't clear.
> after Olof and Maxime told you that they are already working,
> at least discussing with them.
>
apologies, i missed that. there's a lot i need to get up-to-speed,
in very little time. i have some keywords to search for now i'll go
find those messages.
l.
On Fri, Jun 07, 2013 at 02:49:28PM +0000, joem wrote:
> > > SoC vendors are free to join the discussion, and many SoC vendors are part
> > > of the kernel community, so calling this unilateral is plain wrong.
> >
> > you're free to believe that, vladimir. i've explained why that
> > hasn't happened, in prior messages. can we move forward, please?
>
> I prefer it if the "vladimir" troll (and fellow trolls)
> make requests for one of us to make or do something instead of
> constantly whining and wasting time.
>
> After all we are attached to funds and resources ready to
> deploy if something sounds a good idea and gets a vote.
>
> To vladimir - please put your thoughts in a blog where it belongs.
> If its important, I'm sure others would offer comment
> and take you up on your thoughts.
I think your position is confused. Everything that Vladimir (in his
three posts) in this thread so far have been correct. Vladimir is not
the one doing any trolling in this thread.
Vladimir has not requested anything. He hasn't whined. He hasn't
wasted time. He has stated the following in _three_ short succinct
emails:
(a) no one gets to impose stipulate timescales unless they're willing
to financially sponsor the work.
(b) the adopted position of the Linux kernel developers.
Luke Leighton on the other hand is demanding that we (Linux kernel
developers) come up with proposals within three days so that Luke can
act as a middle man between us and Allwinner, and is blaming the Linux
kernel community for the situation with Allwinner.
As you seem to have your facts wrong, I can only conclude that you
are also trolling... I hope I'm wrong about that and you've just made
an innocent mistake.
thomas i _very_ briefly spotted this when i was extremely busy
yesterday, and i'm grateful to the 2 or 3 people who've given me the
keywords and/or links to catch up.
On Thu, Jun 6, 2013 at 10:27 AM, Thomas Petazzoni
<[email protected]> wrote:
> Dear Tomasz Figa,
>
> On Thu, 06 Jun 2013 02:01:14 +0200, Tomasz Figa wrote:
>
>> I don't see any other solution here than moving all the Allwinner
>> code to DT (as it has been suggested in this thread several times
>> already), as this is the only hardware description method supported
>> by ARM Linux.
>
> Have you noticed that it is already the case in mainline?
i knew there was a little bit, but not the extent of the commits.
> My colleague Maxime Ripard (Cc'ed)
maxime: we need to talk :)
please tell me in 4 or 5 sentences what you've managed to do so far,
expanding a little on what thomas says below, more specifically what
it achieves and/or allows rather than technically what it does
(suitable for managers and directors in other words), and what plans
you'd like to see happen.
> is the maintainer of the mainline Allwinner sunxi
> effort. It already supports a number of boards, has a pinctrl driver, a
> GPIO driver, serial port is working, network is working, I2C is
> working.
>
> All in mainline, completely Device Tree based.
great. which version did it first hit, i.e. what will the first
signs of this be when allwinner begin doing "git pulls"?
and which boards. bear in mind that one of those "boards" should
really be "the total range of products available across hundreds of
chinese tablet clone manufacturers".
specific question: is one of the "boards" the one that tom cubie
submitted, which covers virtually every android tablet product
manufactured in the millions by chinese tablet clone manufacturers?
> So isn't this entire discussion completely moot?
no because it's totally in isolation from allwinner. i need to give
them a heads-up, and get them involved, giving them specific
incentives [which nobody's yet given!!] for following a particular
path [or paths] yet to be recommended.
> The mainline support
> for sunxi has already started since 6 months or so, and has been Device
> Tree based from day one.
to clarify: the *community-driven* mainline support for sunxi. ok -
which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i
(Dual-Core Cortex A7)? which ones are in?
l.
On Thu, Jun 6, 2013 at 5:00 PM, Olof Johansson <[email protected]> wrote:
> On Thu, Jun 6, 2013 at 8:13 AM, [email protected] <[email protected]> wrote:
>> On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton <[email protected]> wrote:
>>> augh. ok. solutions. what are the solutions here?
>>
>> Luke if you really want to fix this a good solution is to have
>> Allwinner join Linaro and provide an engineer to the Linaro effort.
>> That engineer will get educated on the right way to do kernel
>> development and he can pass that knowledge back to Allwinner each day
>> as he learns it.
>
> There's no need for anybody to join Linaro to contribute upstream.
> That's a crazy notion.
indeed. this is a company that produced a 70-page "datasheet" when
freescale produced 4,500 for the iMX6. i passed on that link and i
believe it'll be an eye-opener to their engineers: education is what's
key here, and you don't need to pay vast sums to do it.
although the quantities they're selling are just ennorrrmous,
allowing them to undercut absolutely everybody because they can pay
absolute best rates to the Fab Houses (TSMC etc.) their profit margins
are going to be exceptionally slim.
so we cannot count on them having a spare $1m per year to give to
linaro, so yes, i tend to agree with what you're implying, olof, that
allwinner should be encouraged to participate more in upstream
contribution.
so.
could someone please describe to me what they should do, here? whom
should they best contact, what lists, what's the procedures, where's
the best-working-practices, where are the foundations with which they
can participate that have the formal procedures for proposals [similar
to python's PEP and debian's DEP]. that last was a not-very-subtle
hint, btw.
and... please... i've yet to receive *any* answers to the question
"and what are the benefits that they would get by doing so"!!
> Listen, Allwinner isn't working in a vacuum, believe it or not. I've
> talked to them, so has Arnd and other people working on ARM, including
> Maxime Ripard, who's been reimplementing upstream support for their
> platform.
great.
> Everybody is interested in the right things happening, it's
> just a matter of figuring out how to do it. The right people are
> already talking.
.... but the Directors of Allwinner aren't been kept in the loop,
here: that's my job, to get them up-to-speed.
>> the cost of joining. The net result will likely be a reduction in the
>> amount they need to spend on in-house development since they will
>> learn how to better leverage other developer's work.
but you forget one thing: they only need *ever* produce *one*
board/kernel. they have a registered board type, it covers *all*
products and i mean *all* products. i don't mean that in the "usual"
way where most companies re-use a single machine type for multiple
devices and irritate the crap out of linux kernel developers when the
GPL source finally "leaks", i mean "thanks to script.fex they
LITERALLY only ever compile one binary and then customise script.fex
on a per-customer basis".
so the usual lessons really do not apply, here.
the only one i spotted was that they rather foolishly made duplicates
of sun5i_usb and renamed all the files (s/SUN5I/SUN7I/g) to make
sun7i_usb, then started editing. one of the developers created a
buffer overflow, which corrupted internal memory, and there are signs
that he then started experimenting switching off DMA trying to fix
various problems.
if he'd done a proper job #ifdef CONFIG_SUN7I_USB #ifdef
CONFIG_SUN5I_USB in the same source code etc etc. and tested on
known-good [older] hardware he would have noticed that the
modifications failed on previously-known-good hardware and would have
spotted the buffer overflow error much sooner.
that _is_ something i will be bringing to the Director's attention,
that the "strategy" of cut-paste-itis has detrimental effects.
ok. so. apologies, bit of a digression there.
question for you olof [and others of course]: you've clearly listed
some benefits, which i'm very very grateful for. in light of what i
describe above [the "we only need ever write one kernel" strategy
which is serving Allwinner really really well apart from the
code-duplication mistake], do the benefits you list *still* apply, and
if so, could you please elaborate for me, assume i'm thick or
something [or at least not a programmer, which i am unfortunately so
might miss something]
l.
On Thu, Jun 6, 2013 at 6:28 PM, Maxime Ripard
<[email protected]> wrote:
> I should also add that Allwinner not only talked to us already,
oo! great! can you please [privately, not publicly] let me know who
that is, so i can let the Directors know, so that they can follow up?
> but also
> expressed interest in doing actual modern kernel development (like using
> "recently" introduced kernel frameworks, like the clk framework).
awesome.
> I've received patches from them already for private reviews, they began
> to show up on the kernel mailing lists, they asked to be CCed on the
> patches I send upstream, they're even the one that reached out to me
> when the early support for their chips was released. So, like Olof said,
> they aren't in a vacuum, they are very aware of the mainline kernel and
> speak a decent english.
good! next thing you know they'll be writing comments in english too [*1]
> So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
> inferior (because not generic enough) to the device tree, but they show
> interest on going down the mainline road.
yes. i'm coming at this from the other end, via the top management,
so that this is properly coordinated.
so. reminder. and question. what needs to be done, and what are
the benefits?
l.
[*1] http://git.rhombus-tech.net/?p=linux.git;a=blob;f=drivers/usb/sun7i_usb/manager/usb_manager.c;h=3775c83134efee9694789b68e85010ebc0d9938b;hb=refs/heads/lkcl-3.3-a20#l274
Luke,
I want only one thing from you at this time. See below.
On Fri, Jun 7, 2013 at 11:45 AM, luke.leighton <[email protected]> wrote:
> .... but the Directors of Allwinner aren't been kept in the loop,
> here: that's my job, to get them up-to-speed.
The one job I would love for you to do instead of all this trolling
and time-wasting that's being done by _everybody_ involved, is to just
extract yourself from the situation and let us go on with our work.
You're causing nothing but confusion and extra work. Literally. You
represent nobody that matters in this discussion.
By demanding us to spend time and effort bringing you personally up to
speed on a subject that both we (ARM kernel community) and them
(Allwinner) are already having discussions about, it's nothing but a
distraction and waste of energy.
And yes, Allwinner knows about this public email thread.
Thanks.
-Olof
On Thu, Jun 6, 2013 at 9:22 PM, Arnd Bergmann <[email protected]> wrote:
> On Thursday 06 June 2013, Maxime Ripard wrote:
>> So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
>> inferior (because not generic enough) to the device tree, but they show
>> interest on going down the mainline road.
>
> Right, and of course there is nothing special about that, everybody starts
> out with they own even vendor tree (c), and as hardware support gets merged
> upstream, the diff gets smaller, even though the code in the mainline
> kernel is normally very different from what they started out with.
*sigh* except if that idiot manager [whom we're keenly aware of]
orders them to delete absolutely everything (find . -name '*sunxi*' |
xargs git rm) and overwrite it with their internally-managed tree,
causing absolute mayhem in the process...
> Chances are actually that the Allwinner (A10/A13/A20, not A31) platform may
> end up being the first modern one that is fully supported upstream including
> a GPU driver, since it is one of the obvious targets for the
> reverse-engineering efforts.
yes. http://libv.livejournal.com/24735.html
> Ironically (given NVIDIA's reputation), the
> Tegra platform is the strongest competitor I see in that race at the moment.
at $7.50 for a dual-core processor, and i am *not* going to tell you
the quad-core price, i don't believe it can be considered to be a
race, or even a competition. they're *OUT*, man. really.
oh wait - did you mean for "1st to have fully supported upstream GPU
driver"? that would be veery nice.
> For all I can tell, things are progressing nicely, given that it's currently
> a volunteer effort. If anyone needs things to move faster, I'd recommend
> them to send money to free-electrons.com.
i'll put that on the list of recommendations, but - again - i need a
list of clear benefits and returns as to why that should happen.
l.
Hello,
On Fri, 7 Jun 2013 19:26:49 +0100, luke.leighton wrote:
> > Have you noticed that it is already the case in mainline?
>
> i knew there was a little bit, but not the extent of the commits.
Then you could probably use a bit of your time to read the kernel
commit logs rather than writing hundreds of e-mails, no?
> > My colleague Maxime Ripard (Cc'ed)
>
> maxime: we need to talk :)
>
> please tell me in 4 or 5 sentences what you've managed to do so far,
> expanding a little on what thomas says below, more specifically what
> it achieves and/or allows rather than technically what it does
> (suitable for managers and directors in other words), and what plans
> you'd like to see happen.
Maxime will reply to this in more details, but I believe the status is:
* Interrupt controller is working.
* Clock drivers are working.
* Pinctrl is working.
* GPIO is working.
* Timer is working.
* UART is working
* Watchdog is on its way (patches posted)
* Ethernet is on its way (patches posted)
* I2C is on its way (patches posted)
Cubieboard (A10), Hackberry (A10), Mini XPlus (A10) And OLinuxino (A13)
are supported.
See arch/arm/boot/dts/sun{4,5}i* for a good overview.
> > All in mainline, completely Device Tree based.
>
> great. which version did it first hit, i.e. what will the first
> signs of this be when allwinner begin doing "git pulls"?
The very first support landed in 3.8.
> > So isn't this entire discussion completely moot?
>
> no because it's totally in isolation from allwinner. i need to give
> them a heads-up, and get them involved, giving them specific
> incentives [which nobody's yet given!!] for following a particular
> path [or paths] yet to be recommended.
You really believe you're more important than you really are, I'd say.
My colleague Maxime is in contact with Allwinner, he has regular
discussion with them, started reviewing some of the kernel code they're
writing, has received datasheets from them, and evaluation boards.
So this work is definitely not done in isolation from Allwinner, and
they have received much more than an heads-up from Maxime.
> > The mainline support
> > for sunxi has already started since 6 months or so, and has been Device
> > Tree based from day one.
>
> to clarify: the *community-driven* mainline support for sunxi. ok -
> which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i
> (Dual-Core Cortex A7)? which ones are in?
So far, A10 and A13. Maxime has received a A31 evaluation board from
Allwinner very recently, and also A10S and A20 boards. I suppose he
will be working on those fairly and posting the corresponding patches
fairly soon.
In other words, it looks like you've started an entire discussion about
the mainline support for Allwinner SoCs without having a look at what
"git log" tells you... Which by itself is a very good indicator that
you're probably not the best interlocutor for Allwinner as far as
mainline development is concerned.
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Fri, Jun 7, 2013 at 9:57 AM, Tomasz Figa <[email protected]> wrote:
>Seeing from your posts you don't have any knowledge on how Linux kernel
> development works
check back to 2004.
> and even on how Allwinner's cooperation with our
> community looks (and seem to be completely closed to our effort of showing
> you the reality),
no - just f*****g busy, tomasz
> so I'm not sure if you are the right person to take any
> of those roles...
well, tough. get me up to speed, *fast*. please stop wasting time
like this: get me up to speed. i may not be the best person but i am
in the right place at the right time, and nobody else is going to be
able to step into this role in time.
so i may not be the best person that you *think* i am, but i'm the
person you've got. time's ticking. can we get on please?
> I'd suggest Maxime Ripard or someone else from Free Electrons to be
> responsible for communication with Allwinner instead.
you're welcome to suggest, however they do not have the contacts that
i have (many of which are indirect anyway), and i am not going to
introduce him to them either, in case they jeapordise the critical
business relationships that took my associates 4 years to establish.
l.
On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson <[email protected]> wrote:
> Luke,
>
> I want only one thing from you at this time. See below.
>
>
> On Fri, Jun 7, 2013 at 11:45 AM, luke.leighton <[email protected]> wrote:
>> .... but the Directors of Allwinner aren't been kept in the loop,
>> here: that's my job, to get them up-to-speed.
>
> The one job I would love for you to do instead of all this trolling
> and time-wasting that's being done by _everybody_ involved, is to just
> extract yourself from the situation and let us go on with our work.
> You're causing nothing but confusion and extra work. Literally. You
> represent nobody that matters in this discussion.
absolutely correct. i am nobody, who is in the right place at the
right time. i'm just a messenger. so - what message do you wish to
take to the Directors of Allwinner (if any).
> By demanding
a-a-ah, no demands made.
> us to spend time and effort bringing you personally up to
> speed on a subject that both we (ARM kernel community) and them
> (Allwinner) are already having discussions about, it's nothing but a
> distraction and waste of energy.
>
> And yes, Allwinner knows about this public email thread
that's good!
On Fri, Jun 7, 2013 at 7:57 PM, Wookey <[email protected]> wrote:
> OK, this sounds good. Could you say who the allwinner engineers are?
[cross-over: i asked him if he'd be happy to let me know privately,
so i have at least some context when speaking to the Directors]
> I
> guess it's quite a large organisation, so if Crazy Luke can say 'the
> work of mainline integration using device-tree is already being done
> by $these $people, please talk to them to help move it along', that
> might help get everyone on the same page.
.... *mull*, *mull*... yes exactly!
> If it's like many large organisations, some bits of it will 'get it'
> and see why, in the long term, mainline integration is worthwhile, but
> other bits will look at what they have now and their android focus,
> and decide it's easier to keep doing what they are doing.
>
> There is a lot of hardware using these socs, and I'd love to be able
> to use that with mainstream stuff, rather than random vendor piles,
> and specific android kernels, so anything we can do to help make that
> happen is good.
>
>> So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
>> inferior (because not generic enough) to the device tree, but they show
>> interest on going down the mainline road.
>
> So, luke: mainline is not going to support fex directly, whatever you
> or allwinner do. The advantages to allwinner of working with mainline
> are:
> 1) Ability to use whatever (kernel supported) hardware they like with
> new designs, with no driver work
> 2) Ability to use latest kernels and thus whatever shiny goodies those
> include
> 3) No need to do fex-ready drivers for new hardware
> 4) No need to keep backporting new kernels to add fex integration
> forevermore
hooraaaaay - thank you wookey, this is exactly what i need.
cut/paste, straight into the report.
> If they want to keep existing tools and fex workflow then a fex<->DT
> translation tool will be needed.
in-kernel or external tool?
> (It's not clear to me to what degree
> DT can simply be used instead directly)
TBD. input here, anyone?
On Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni
<[email protected]> wrote:
> Hello,
>
> On Fri, 7 Jun 2013 19:26:49 +0100, luke.leighton wrote:
>
>> > Have you noticed that it is already the case in mainline?
>>
>> i knew there was a little bit, but not the extent of the commits.
>
> Then you could probably use a bit of your time to read the kernel
> commit logs rather than writing hundreds of e-mails, no?
not now, thomas. i need summaries. bear in mind i type faster than
i can read/find. very very grateful for your summaries, it's exactly
what i need.
>> > My colleague Maxime Ripard (Cc'ed)
>>
>> maxime: we need to talk :)
>>
>> please tell me in 4 or 5 sentences what you've managed to do so far,
>> expanding a little on what thomas says below, more specifically what
>> it achieves and/or allows rather than technically what it does
>> (suitable for managers and directors in other words), and what plans
>> you'd like to see happen.
>
> Maxime will reply to this in more details, but I believe the status is:
>
> * Interrupt controller is working.
> * Clock drivers are working.
> * Pinctrl is working.
> * GPIO is working.
> * Timer is working.
> * UART is working
> * Watchdog is on its way (patches posted)
> * Ethernet is on its way (patches posted)
> * I2C is on its way (patches posted)
>
> Cubieboard (A10), Hackberry (A10), Mini XPlus (A10) And OLinuxino (A13)
> are supported.
>
> See arch/arm/boot/dts/sun{4,5}i* for a good overview.
>
>> > All in mainline, completely Device Tree based.
>>
>> great. which version did it first hit, i.e. what will the first
>> signs of this be when allwinner begin doing "git pulls"?
>
> The very first support landed in 3.8.
>
>> > So isn't this entire discussion completely moot?
>>
>> no because it's totally in isolation from allwinner. i need to give
>> them a heads-up, and get them involved, giving them specific
>> incentives [which nobody's yet given!!] for following a particular
>> path [or paths] yet to be recommended.
>
> You really believe you're more important than you really are, I'd say.
no, i don't. i'm just a messenger. under-informed one, at the
moment. please bear that in mind rather than saying "you seem
dreadfully underinformed" - i got caught off-guard by this opportunity
and need to get up-to-speed rather fast.
> My colleague Maxime is in contact with Allwinner, he has regular
> discussion with them, started reviewing some of the kernel code they're
> writing, has received datasheets from them, and evaluation boards.
_great_. that's brilliant to hear.
> So this work is definitely not done in isolation from Allwinner, and
> they have received much more than an heads-up from Maxime.
>
>> > The mainline support
>> > for sunxi has already started since 6 months or so, and has been Device
>> > Tree based from day one.
>>
>> to clarify: the *community-driven* mainline support for sunxi. ok -
>> which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i
>> (Dual-Core Cortex A7)? which ones are in?
>
> So far, A10 and A13. Maxime has received a A31 evaluation board from
> Allwinner very recently, and also A10S and A20 boards. I suppose he
> will be working on those fairly and posting the corresponding patches
> fairly soon.
great. you've got the A20 3.3 kernel source drop?
http://git.rhombus-tech.net/?p=linux.git;a=tree;h=refs/heads/lkcl-3.3-a20;hb=refs/heads/lkcl-3.3-a20
> In other words, it looks like you've started an entire discussion about
> the mainline support for Allwinner SoCs without having a look at what
> "git log" tells you...
absolutely correct. dived into this the moment i got word of a
potential meeting on extremely short notice, having had zero time to
review the logs prior even to then.
> Which by itself is a very good indicator that
> you're probably not the best interlocutor for Allwinner as far as
> mainline development is concerned.
the meeting's going ahead, regardless of your concerns. please help
get me up to speed, for the benefit of the linux community. take
advantage of the opportunity, please: take it at face value without
judgement.
l.
On Friday 07 of June 2013 20:02:03 luke.leighton wrote:
> On Fri, Jun 7, 2013 at 9:57 AM, Tomasz Figa <[email protected]>
wrote:
> >Seeing from your posts you don't have any knowledge on how Linux kernel
> >
> > development works
>
> check back to 2004.
$ git log --oneline --author="Luke Kenneth Casson Leighton" | wc -l
0
$ git log --oneline --author="[email protected]" | wc -l
0
$ git log --oneline --author="Luke Leighton" | wc -l
0
That's an -ENOPATCH for me.
> > and even on how Allwinner's cooperation with our
> > community looks (and seem to be completely closed to our effort of
> > showing you the reality),
>
> no - just f*****g busy, tomasz
Just like many of us, I guess.
> > so I'm not sure if you are the right person to take any
> > of those roles...
>
> well, tough. get me up to speed, *fast*. please stop wasting time
> like this: get me up to speed. i may not be the best person but i am
> in the right place at the right time, and nobody else is going to be
> able to step into this role in time.
>
> so i may not be the best person that you *think* i am, but i'm the
> person you've got. time's ticking. can we get on please?
>
> > I'd suggest Maxime Ripard or someone else from Free Electrons to be
> > responsible for communication with Allwinner instead.
>
> you're welcome to suggest, however they do not have the contacts that
> i have (many of which are indirect anyway), and i am not going to
> introduce him to them either, in case they jeapordise the critical
> business relationships that took my associates 4 years to establish.
Well, I'm quitting this discussion right now, as it doesn't seem to be of
any use or might be even counter-productive. I have already showed my view
on this matter (and even given you some proposals for them), got it
confirmed by several other people and got nothing from you that could make
me reconsider anything.
Thank you for your time.
Best regards,
Tomasz
On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux
<[email protected]> wrote:
> Luke Leighton on the other hand is demanding that we
no demands have been made, russell: i've informed you of an immovable
deadline which will pass beyond which the opportunity being presented
is lost.
> (Linux kernel
> developers) come up with proposals within three days so that Luke can
> act
.... is *going* to act, regardless of how well people deal with the
time limitations and my own communication limitations....
> as a middle man between us and Allwinner, and is
.... not ...
> blaming the Linux
> kernel community for the situation with Allwinner.
>
> As you seem to have your facts wrong, I can only conclude that you
> are also trolling... I hope I'm wrong about that and you've just made
> an innocent mistake.
please continue to assume that i am making mistakes [under time
pressure]: you'd be right. i never understand this word "troll" and i
haven't got time to discuss its meaning.
greatly appreciated efforts to correct my misunderstandings and
mistakes so that i'm properly prepared - ready or not - for the
meeting ahead.
l.
On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote:
> On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux
> <[email protected]> wrote:
> > Luke Leighton on the other hand is demanding that we
>
> no demands have been made, russell: i've informed you of an immovable
> deadline which will pass beyond which the opportunity being presented
> is lost.
[...]
Would that be the opportunity for you to pose as an intermediary
between the Linux community and Allwinner, which you failed to realise
was a completely redundant position?
If not, please explain what you are actually hoping to do, and why
anyone should care.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote:
> well, tough. get me up to speed, *fast*.
No, not unless you're willing to *pay* someone to spend time teaching you,
because you are asking to be *taught* about the current situation, so
you're asking someone to do some _work_ _for_ _you_. If you're not
willing to do that, then all the information is out there in the public
domain for you to learn from yourself.
> please stop wasting time like this:
Pot. Black.
On Fri, Jun 07, 2013 at 08:04:26PM +0100, luke.leighton wrote:
> On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson <[email protected]> wrote:
> > By demanding
>
> a-a-ah, no demands made.
" well, tough. get me up to speed, *fast*. please stop wasting time
like this: get me up to speed."
That is a demand. Stop trolling.
+++ Maxime Ripard [2013-06-06 19:28 +0200]:
> Hi everyone,
>
> On Thu, Jun 06, 2013 at 09:00:00AM -0700, Olof Johansson wrote:
> > Listen, Allwinner isn't working in a vacuum, believe it or not. I've
> > talked to them, so has Arnd and other people working on ARM, including
> > Maxime Ripard, who's been reimplementing upstream support for their
> > platform. Everybody is interested in the right things happening, it's
> > just a matter of figuring out how to do it. The right people are
> > already talking.
>
> I should also add that Allwinner not only talked to us already, but also
> expressed interest in doing actual modern kernel development (like using
> "recently" introduced kernel frameworks, like the clk framework).
>
> I've received patches from them already for private reviews, they began
> to show up on the kernel mailing lists, they asked to be CCed on the
> patches I send upstream, they're even the one that reached out to me
> when the early support for their chips was released. So, like Olof said,
> they aren't in a vacuum, they are very aware of the mainline kernel and
> speak a decent english.
OK, this sounds good. Could you say who the allwinner engineers are? I
guess it's quite a large organisation, so if Crazy Luke can say 'the
work of mainline integration using device-tree is already being done
by $these $people, please talk to them to help move it along', that
might help get everyone on the same page.
If it's like many large organisations, some bits of it will 'get it'
and see why, in the long term, mainline integration is worthwhile, but
other bits will look at what they have now and their android focus,
and decide it's easier to keep doing what they are doing.
There is a lot of hardware using these socs, and I'd love to be able
to use that with mainstream stuff, rather than random vendor piles,
and specific android kernels, so anything we can do to help make that
happen is good.
> So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
> inferior (because not generic enough) to the device tree, but they show
> interest on going down the mainline road.
So, luke: mainline is not going to support fex directly, whatever you
or allwinner do. The advantages to allwinner of working with mainline
are:
1) Ability to use whatever (kernel supported) hardware they like with
new designs, with no driver work
2) Ability to use latest kernels and thus whatever shiny goodies those
include
3) No need to do fex-ready drivers for new hardware
4) No need to keep backporting new kernels to add fex integration
forevermore
If they want to keep existing tools and fex workflow then a fex<->DT
translation tool will be needed. (It's not clear to me to what degree
DT can simply be used instead directly)
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote:
> On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux
> <[email protected]> wrote:
> > Luke Leighton on the other hand is demanding that we
>
> no demands have been made, russell: i've informed you of an immovable
> deadline which will pass beyond which the opportunity being presented
> is lost.
" well, tough. get me up to speed, *fast*. please stop wasting time
like this: get me up to speed."
That is a demand. On the other hand this would not be:
"Can someone please get me up to speed on this?" That is a request.
Sorry, you've just lost some more credibility.
Please let those who are already working with Allwinner continue to
work with them rather than spending time needlessly with someone who
clearly doesn't have any idea about what they say even from one moment
to the next.
Confused yes - innocent mistake - 50% yes.
I see now the posts are cc'd from arm-netbook mailing lists to many
other mailing lists with different standards for noise.
Apologies for not seeing that.
arm-netbook list 'belongs' to luke, but generally the noise level
is very low here and its aim is to make EOMA 68 and other similar gadgets.
So it is not fair on anybody here to be flooded like this with blog quality post.
If anyone got open source things that need building, or things that need doing, by
all means send a one or two line request.
So stop squabbling, become more productive by sticking to one or two
line responses. I'm sure everyone can do that.
And if you have time, here are projects to take inspiration from
when it comes making gadgets:
http://rhombus-tech.net/
Projects that have sprung up around Luke's project:
http://www.iuac.res.in/~elab/phoenix/SBC/
https://github.com/slapin/a13board
http://www.gplsquared.com/SoM2/SoM2.html
http://www.gplsquared.com/mk802/mk802.html
________________________________________
As you seem to have your facts wrong, I can only conclude that you
are also trolling... I hope I'm wrong about that and you've just made
an innocent mistake.
right - too many people contributed to this, input from jon smirl,
wookie, maxime, tomasz, henrik, i've made a start here and will
continue editing: this is notes for me to put forward an agenda for
discussion:
http://hands.com/~lkcl/allwinner_linux_proposal.txt
i'm setting a rule that each section *has* to have a list of clear
benefits, otherwise it'll have to be removed before it goes on to
their Directors.
so - even if there are any allwinner engineers reading this who would
like something put forward please also speak up! :)
l.
On Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni
<[email protected]> wrote:
> Maxime will reply to this in more details, but I believe the status is:
>
> * Interrupt controller is working.
> * Clock drivers are working.
> * Pinctrl is working.
> * GPIO is working.
> * Timer is working.
> * UART is working
> * Watchdog is on its way (patches posted)
> * Ethernet is on its way (patches posted)
> * I2C is on its way (patches posted)
ok so i've got this now in
http://hands.com/~lkcl/allwinner_linux_proposal.txt - that leaves...
well there's quite a bit: usb, sd/mmc (both variants: they changed the
data structures around sun5i), nand (probably both - the allwinner one
and the mtd one being done, reminds me: we need full documentation on
the NAND chip), scsi, g2d - cedarx and more.
what else should be raised, and to what benefit?
On Fri, Jun 7, 2013 at 8:30 PM, Russell King - ARM Linux
<[email protected]> wrote:
> On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote:
>> well, tough. get me up to speed, *fast*.
>
> No, not unless you're willing to *pay* someone to spend time teaching you,
there's not enough time. 2 days left.
> because you are asking to be *taught* about the current situation, so
> you're asking someone to do some _work_ _for_
..... for the benefit of free software, russell.
for the benefit of free software.
for the BENEFIT of free software.
> _you_.
NO.
On Fri, Jun 7, 2013 at 8:35 PM, Russell King - ARM Linux
<[email protected]> wrote:
> On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote:
>> On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux
>> <[email protected]> wrote:
>> > Luke Leighton on the other hand is demanding that we
>>
>> no demands have been made, russell: i've informed you of an immovable
>> deadline which will pass beyond which the opportunity being presented
>> is lost.
>
> " well, tough. get me up to speed, *fast*. please stop wasting time
> like this: get me up to speed."
>
> That is a demand. On the other hand this would not be:
>
> "Can someone please get me up to speed on this?" That is a request.
thank you for the correction.
can someone please get me up to speed on this? i've collated peoples
very gratefully received responses so far, here:
http://hands.com/~lkcl/allwinner_linux_proposal.txt
> Please let those who are already working with Allwinner continue to
> work with them rather than spending time needlessly with someone who
> clearly doesn't have any idea about what they say even from one moment
> to the next.
1) correct: i don't. i've been caught off-guard by this: it's very
short notice, and i have limited time available. i'm doing the best i
can to correct mistakes as i go along, but i *don't have time* to
observe the niceties, dot all the i's or cross all the t's.
2) that appears to be a request to a large audience. i have to point
out to that audience: end result of complying with the request above
will be that the free software community suffers as a result of losing
the opportunity to speak to - and therefore influence - the Directors
of one of the world's most successful, fastest growing [and also very
young and inexperienced] SoC fabless semiconductor company.
please make your own choice.
l.
On Fri, Jun 07, 2013 at 07:26:49PM +0100, luke.leighton wrote:
> maxime: we need to talk :)
>
> please tell me in 4 or 5 sentences what you've managed to do so far,
> expanding a little on what thomas says below, more specifically what
> it achieves and/or allows rather than technically what it does
> (suitable for managers and directors in other words), and what plans
> you'd like to see happen.
You mean something like http://linux-sunxi.org/Linux_mainlining_effort ?
You should really do a bit of research before starting a thread like
this one. This webpage has been around for like 9 monthes now on the wiki
of a community you pretend to represent (even though I fail to get how
you can pretend such thing, but that's another topic).
> > is the maintainer of the mainline Allwinner sunxi
> > effort. It already supports a number of boards, has a pinctrl driver, a
> > GPIO driver, serial port is working, network is working, I2C is
> > working.
> >
> > All in mainline, completely Device Tree based.
>
> great. which version did it first hit, i.e. what will the first
> signs of this be when allwinner begin doing "git pulls"?
3.8, as shown in the wiki page
> and which boards. bear in mind that one of those "boards" should
> really be "the total range of products available across hundreds of
> chinese tablet clone manufacturers".
>
> specific question: is one of the "boards" the one that tom cubie
> submitted, which covers virtually every android tablet product
> manufactured in the millions by chinese tablet clone manufacturers?
Again, wiki.
> > So isn't this entire discussion completely moot?
>
> no because it's totally in isolation from allwinner. i need to give
> them a heads-up, and get them involved, giving them specific
> incentives [which nobody's yet given!!] for following a particular
> path [or paths] yet to be recommended.
>
> > The mainline support
> > for sunxi has already started since 6 months or so, and has been Device
> > Tree based from day one.
>
> to clarify: the *community-driven* mainline support for sunxi. ok -
> which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i
> (Dual-Core Cortex A7)? which ones are in?
A10, A13 for the moment. I just received hardware with A10s, A20 and A31
that I need to work on, but support should come quite soon. I already
have some patches pending to be tested on an A31 board, but didn't have
as much time as I wanted lately to actually set a proper environment to
test them.
Maxime
On Fri, Jun 7, 2013 at 11:08 PM, Maxime Ripard
<[email protected]> wrote:
> On Fri, Jun 07, 2013 at 07:26:49PM +0100, luke.leighton wrote:
>> maxime: we need to talk :)
>>
>> please tell me in 4 or 5 sentences what you've managed to do so far,
>> expanding a little on what thomas says below, more specifically what
>> it achieves and/or allows rather than technically what it does
>> (suitable for managers and directors in other words), and what plans
>> you'd like to see happen.
>
> You mean something like http://linux-sunxi.org/Linux_mainlining_effort ?
ahh, fantastic. with references too. magic. exactly what i need.
thank you. listed now at
http://hands.com/~lkcl/allwinner_linux_proposal.txt
> You should really do a bit of research before starting a thread like
> this one.
then that gives you some idea of how busy i've been and still am, to
not be aware even of things like this, to have kicked a project off
some 18-24 months ago and not be able to keep up with one of the many
branches and initiatives that it's spawned.
when i said i've been caught off-guard by this opportunity i meant
exactly what i said.
> This webpage has been around for like 9 monthes now on the wiki
> of a community you pretend to represent
i pretend no such thing and apologise for giving any impression of such.
> (even though I fail to get how
> you can pretend such thing, but that's another topic).
i have a different focus: a meta-project of sorts, where allwinner
happened to be the first. look up rhombus-tech and EOMA68 and it'll
become a bit clearer.
>> > is the maintainer of the mainline Allwinner sunxi
>> > effort. It already supports a number of boards, has a pinctrl driver, a
>> > GPIO driver, serial port is working, network is working, I2C is
>> > working.
>> >
>> > All in mainline, completely Device Tree based.
>>
>> great. which version did it first hit, i.e. what will the first
>> signs of this be when allwinner begin doing "git pulls"?
>
> 3.8, as shown in the wiki page
got that.
>> and which boards. bear in mind that one of those "boards" should
>> really be "the total range of products available across hundreds of
>> chinese tablet clone manufacturers".
>>
>> specific question: is one of the "boards" the one that tom cubie
>> submitted, which covers virtually every android tablet product
>> manufactured in the millions by chinese tablet clone manufacturers?
>
> Again, wiki.
yep, am there now.
>> > So isn't this entire discussion completely moot?
>>
>> no because it's totally in isolation from allwinner. i need to give
>> them a heads-up, and get them involved, giving them specific
>> incentives [which nobody's yet given!!] for following a particular
>> path [or paths] yet to be recommended.
>>
>> > The mainline support
>> > for sunxi has already started since 6 months or so, and has been Device
>> > Tree based from day one.
>>
>> to clarify: the *community-driven* mainline support for sunxi. ok -
>> which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i
>> (Dual-Core Cortex A7)? which ones are in?
>
> A10, A13 for the moment. I just received hardware with A10s, A20 and A31
> that I need to work on, but support should come quite soon.
superb. question: what help or other resources could you do with?
what additional information?
> I already
> have some patches pending to be tested on an A31 board, but didn't have
> as much time as I wanted lately to actually set a proper environment to
> test them.
ok - good to know. btw when you get to it please note a bug found in
the "vanilla" [allwinner-released] A20 3.3 tree where they reduced a
128 byte buffer to 78 bytes for spurious reasons; the critical fix is
at line 989, of the following patch:
http://git.rhombus-tech.net/?p=linux.git;a=commitdiff;h=refs/heads/lkcl-3.3-a20;hp=6c5753e5dc1fafff288d522c94b40a7dd2a81adc
i found this by running a diff -u of sun4i_usb from the 3.4 sunxi
community tree against the sun7i_usb tree from the allwinner 3.3
release. amongst the desperate attempts to disable DMA (probably due
to stack corruption of the above bug) and various renaming attempts of
*SUN4I* to *SUN7I*, that one stuck out like a sore thumb. the other
bits - which may or may not be relevant - are the spinlock protection
and the call to sw_udc_enable which is present in the sun4i_usb 3.4
code but not the A20 3.3 code.
mileage may vary, and the buffer overrun only happens if you enable
the OTG interface as "dual" (auto-detect) because that's enough
features in the bitfield to cause there to be enough strcpy's... oops
:)
l.
Luke,
On Friday 07 of June 2013 22:29:34 luke.leighton wrote:
> On Fri, Jun 7, 2013 at 7:59 PM, Thomas Petazzoni
>
> <[email protected]> wrote:
> > Maxime will reply to this in more details, but I believe the status
is:
> > * Interrupt controller is working.
> > * Clock drivers are working.
> > * Pinctrl is working.
> > * GPIO is working.
> > * Timer is working.
> > * UART is working
> > * Watchdog is on its way (patches posted)
> > * Ethernet is on its way (patches posted)
> > * I2C is on its way (patches posted)
>
> ok so i've got this now in
> http://hands.com/~lkcl/allwinner_linux_proposal.txt - that leaves...
> well there's quite a bit: usb, sd/mmc (both variants: they changed the
> data structures around sun5i), nand (probably both - the allwinner one
> and the mtd one being done, reminds me: we need full documentation on
> the NAND chip), scsi, g2d - cedarx and more.
>
> what else should be raised, and to what benefit?
Now that the discussion went off from "you stupid kernel developers
adopted DeviceTree without even asking a closed company about their
proprietary solution, which does the same" to something a bit more
constructive, let me point some of the benefits.
First let me remind you the proposals from one of my previous posts:
- let Allwinner engineers join the relevant mailing lists - mostly linux-
arm-kernel, but also all the topic-specific ones, like linux-mmc, linux-
usb, linux-pm, devicetree-discuss, etc.
- adjust their workflow to comply with rules of Linux kernel open
source community (i.e. sending RFCs of things in development, getting code
reviewed, addressing comments)
- rework existing code to use widely-accepted, standard solutions
available in upstream Linux kernel (although this is already mostly done
by sunxi community) to avoid reinventing wheels - this is not only about
DeviceTree, which you mentioned already in your proposal list, but also
all the generic frameworks present in the kernel
Now the benefits of cooperation with Linux kernel community:
- access to big knowledge base of all the Linux kernel developers
participating in discussions on the mailing lists; any technical (and
maybe non-technical?) problems related to the kernel can be discussed on
the lists at any time; also this would be a good form of communication
between Allwinner engineers and sunxi community
- in-depth code review by experienced kernel developers that allows early
spotting of issues and finding possible improvements of design and
implementation; having this would avoid things like you mentioned with
their usb driver
- extended testing coverage - anyone can access the patches in
development (through the ML or linux-next integration tree), test them on
their board with Allwinner SoC and report any issues on respective mailing
lists
- ability to participate in development of the whole Linux kernel,
including any existing and new generic frameworks, drivers, etc., in terms
of discussion, sending patches, reviewing patches of other developers;
this is very important to make sure that the part being developed
suits the needs of everyone (or at least most of the parties)
- you can't know that without enough discussion;
this is also important to avoid reinventing wheels - there might
be a useful part of code available in some internal tree of some
company or developer, which could be just extended (or even used
as is), without the need to reinvent it, but people must know
about it first
That's all I can think of at the moment (+ all the proposals and benefits
you have in your file already).
Best regards,
Tomasz
On Sat, Jun 8, 2013 at 9:28 AM, Tomasz Figa <[email protected]> wrote:
> Now that the discussion went off from "you stupid kernel developers
*lol*. i get that summary ["you said people were stupid!!!"] a lot.
i don't quite understand where it comes from, otherwise i would stop
doing it :)
> adopted DeviceTree without even asking a closed company about their
> proprietary solution, which does the same" to something a bit more
> constructive, let me point some of the benefits.
> [snip...]
ahh, magic. these have gone straight into that proposal. i think
the best ones - the gems - are the test-coverage and formally allowing
public interaction.
the test coverage because it will reduce the risk of errors in the
silicon [you never know when developing both hardware and software
where the bug might be] as well as reduce the development time and
development costs.
the public interaction (which i was going to ask thomas and maxime
about, this morning) because it means a much faster feedback loop.
i've been trying to think of ways to link "if you do X it will result
in more sales and reduce risk" to the discussion, and i think you
finally hit it tomasz, so thank you.
l.
ok, so the deadline's almost up but the discussions of the past two or
so days have basically i think everything that needs to be said, and
i'm extremely grateful to everyone who's contributed, privately and
publicly, especially on such short notice. i've passed it over to my
associates who will turn it into executive-level-speak: they
understand that the situation is sensitive and have far more sense
than i, which is good.
i'm not sure if i should admit this, but there's some irony here that
needs to be shared. i passed the collation of input from people -
most of it verbatim - over to my associate who is used to dealing with
executive-level people, and he said it couldn't possibly go as-is to
them, not even to their assistant. when i asked why he said it was
because it sounded too much like ordering them what decisions to make.
if you've been following the shit-storm criticism that's been
directed at me, and you've also noticed the bit about "most of it
being verbatim" you have to appreciate the irony, really.
so *sigh* we have to trust my associates and their experience in
dealing with executives to work out a way to get the message across: i
understand the things about public communication on-list(s) being
important and so on and will fight to make sure those are got across
in some clear form. the good news is that they *have* asked for
advice and for a report, so there *is* an opening, it's not an
unwelcome cold-call that we're engaging in, here.
the last thing i'd like to say is this: free (libre) software
developers and advocates are in an extremely... odd position of not
really being fully or adequately monetarily compensated for the true
level of service that they truly provide. i mention "service" because
regardless of whether it's business or whether it's spare-time work
just for the heck of it, we *are* acting as servants to a great many
people, and in many cases those people who directly receive the
benefit of our work - millions if not hundreds of people now that the
linux kernel has made its way into android - have absolutely no way of
being able to identify us and pay us for that service.
i've never thought about giving up, but i *have* been thinking "what
the hell am i doing wrong i.e. why have i only received direct
donations of about $300 in *total* for all work done for the free
software community since 1995 including samba and exchange 5.5
reverse-engineering and much more", up until recently when i learned
some new insights that i thought it important to share, here.
the insight is this: that there is a separate tally which is inviolate
that keeps a *true* account of the level of service that we *truly*
provide to others, of which monetary compensation is only a partial
reflection [subtracted from that inviolate account, in some cases
resulting in a DEBT in the inviolate and true account - which will
need to be repaid - if the monetary compensation was too high or the
service provided too poor].
so, for anyone reading this who has seen the shit-storm of the past
few days and felt either embarrassed, or for any other reason has felt
that they should quit working with free software, please don't:
remember that the work itself is not necessarily the reward (although
that's important too), nor that you're providing service to others and
that that itself should be the reward, but that you *will* or *are*
receiving true and accurate compensation: believe it, because it's
true.
this is all a rather round-about way to say that for those people who
heard and are thinking of heeding russell's call to "be silent and to
ignore me", to do so would be a significant dis-service both to
yourself and to the hundreds of millions of end-users whom you are
serving, if the long-term and immediate-term projects that i have
embarked on are the success that i envision them to be. even with
that having been said, it is, indeed, entirely your choice, that
nobody but you should make.
l.
On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote:
> this is all a rather round-about way to say that for those people who
> heard and are thinking of heeding russell's call to "be silent and to
> ignore me"
Okay, so you've just misrepresented me in the above comment. I never
said anything of the sort. The closest that I've come to a comment like
that is asking you to stop wasting people's time.
So, given your displayed inability to properly convey what people have
said to you in a discussion in your own replies, is there *any* reason
that anyone should trust you to communicate their position to any other
third party?
In some ways, I'm *glad* that you've passed everything on verbatum,
because it means that it's (hopefully) free from any misrepresentations
such as the above.
On Sun, Jun 9, 2013 at 11:31 PM, Russell King - ARM Linux
<[email protected]> wrote:
> On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote:
>> this is all a rather round-about way to say that for those people who
>> heard and are thinking of heeding russell's call to "be silent and to
>> ignore me"
>
> Okay, so you've just misrepresented me in the above comment. I never
> said anything of the sort. The closest that I've come to a comment like
> that is asking you to stop wasting people's time.
close enough.
> So, given your displayed inability to properly convey what people have
> said to you in a discussion in your own replies, is there *any* reason
> that anyone should trust you to communicate their position to any other
> third party?
trust is always something that has to be given, russell. respect is
earned, but trust is given. many make the mistake of believing that
trust is earned [people who seek to defeat others as "enemies" know
this and exploit it to devastating effect].
so i can't answer your question directly, but consider this: the
people that i work with have known me for a long time. they know i'm
a bit of a live wire (you saw that wookey called me "crazy luke") and
they often go as completely spare at some of the spanners i throw in
the works just as everyone else does. it's *they* who will be doing
all the talking, and i will be advising them in the background over
the next week so that *technically* they're prepped.
everyone has a different role to play here.
/peace
l.