[Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
luke.leighton at gmail.com
Sat Jun 8 00:07:28 BST 2013
On Fri, Jun 7, 2013 at 11:08 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> 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
> 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
>> 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:
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
More information about the arm-netbook