Re: [linux-sunxi] Further Allwinner misbehaviour.

[Clement Wong]

Hey buddy,

This issue has been fixed in the repo, so please don’t using aggressive words in
regards of this issue. It’s just mean to reply to their action with “nothing 
more than Software Pirates”.
They did actually wrote those code by themselves, and give them out for free, 
and it’s no under
restriction of GPL since they are not apart of the original program but modules.
See 
https://github.com/allwinner-zh/media-codec/commit/a912bbe300d522e199001bd903bab22e54eff37b
 

 .

I think Allwinner needs more encouragement than criticism now, as they are doing
some actual good works here.
I also think this whole drama was just a mistake made by Allwinner during the 
open sourcing process,
as all those files states that they were written from 2008, and I’m guessing 
that they just forgot to change
a few files’ header before they submit the code. Honestly Chinese companies 
does not care about licensing, they
only care if they should open source the code, once it is open source, they 
won’t think of licensing because
licensing of source code means not much in China.

Sure there are more works to be resolved, but they are in action, and wish them 
the best.

Clement

> On Jun 27, 2015, at 7:09 PM, rcm...@gmail.com wrote:
> 
> On Monday, June 22, 2015 at 3:19:54 PM UTC+3, Luc Verhaegen wrote:
>> Hi,
>> 
>> It's been a month since Allwinners big "open source" release, where they 
>> tried to shut up the big (and very justified) GPL violations noise by 
>> releasing some code which moves decoder codecs into modules, and by 
>> releasing some codecs as open source as well. As i predicted then, 
>> Allwinner now has taken the next step:
>> 
>> They produced a binary for the decoder, which is loaded in:
>> https://github.com/allwinner-zh/media-codec/blob/72f2b8537/sunxi-cedarx/SOURCE/vencoder/venc_device.c
>> 
>> Note the "Proprietary" license notice on top of this and other new 
>> files.
>> 
>> Even if we ignore the past, all of this is built together with LGPLed 
>> code, and the binary is being dlopened into this LGPLed code. Quite 
>> illegally so.
>> 
>> This is further deliberate avoidance of responsibility by Allwinner. One 
>> can only assume that Allwinner is incorrigible at this point. They have 
>> been told time and time again what is wrong and they have time and time 
>> again been given possible ways out, in great detail. All we get though, 
>> is microsteps to take off the heat, followed by further deliberate 
>> breaking/bending of the rules.
>> 
>> This also sheds a further shadow on the C.H.I.P. project. Clearly the 
>> Next Thing Co. guys were very gullible when they went into business with 
>> Allwinner (and believed the statements made by allwinner). Later during 
>> the run of the kickstarter campaign, after all the noise had been made 
>> on the internet about GPL Violations, Next Thing Co. loudly claimed that 
>> they are working the Free Electrons and that all promises of open 
>> sourceness and such would be kept (all?). While this move in itself was 
>> very laudable, it did underline the fact that Next Thing Co. had not 
>> done its homework beforehand. Now Allwinner does this, which clearly 
>> goes in against everything the Next Thing Co. people have promised us so 
>> far...
>> 
>> Allwinner has some explaining to do (as does Next Thing Co, to a lesser 
>> extent).
>> 
>> Luc Verhaegen.
> 
> == OFFTOPIC: ==
> 
> It is obvious after all this years that Allwinner are nothing more than 
> Software Pirates.
> 
> Years ago I was very naive hoping that the rise of these Chinese ARM chip 
> manufacturers would prevent Intel from taking over the embedded industry also.
> But because of their unlimited level of incompetency, unfortunately Intel has 
> already won even before the war has started.
> 
> You can't really expect a company with a thieves mindset to get the big 
> picture and make smart decisions they are always looking to make a quick buck.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Further Allwinner misbehaviour.

[Clement Wong]

> From: allwinner-zh 
> Date: 26 June 2015 08:00:21 CEST
> To: allwinner-zh/media-codec 
> Subject: Re: [media-codec] Unsuitable copyright text in some source code 
> files (#8)
> Reply-To: allwinner-zh/media-codec 
> 
> 
> Thank you very much for your constructive suggestion, it has been fixed.
> 
> —
> Reply to this email directly or view it on GitHub.
> 



Clement

> On 25 Jun 2015, at 17:12, Julian Calaby  wrote:
> 
> Hi Simos,
> 
> On Thu, Jun 25, 2015 at 7:56 PM, 'Simos Xenitellis' via linux-sunxi
>  wrote:
>> Let's dissect.
> 
> Yes, let's dissect.
> 
>>> On Wed, Jun 24, 2015 at 11:56 PM, Andrés Domínguez  
>>> wrote:
>>> 2015-06-24 21:25 GMT+02:00 Simos Xenitellis :
 
 If something needs to get fixed in those repositories
 (https://github.com/allwinner-zh/),
 point it out constructively.
>>> 
>>> Sorry, I didn't make the infringement statement and I don't know about it, 
>>> but
>>> knowing about allwinner's past behavior and libv it's clear that it has some
>>> credibility.
>> 
>> Here you say "it's clear" for a reference to _past behaviour_, while a
>> more appropriate
>> wording would be "I assume". You *assume* it has some credibility.
> 
> Allwinner's past behaviour is very clear. They release stuff without
> checking that it complies with the license they release it under then
> appear to ignore it (or at least don't communicate) when the
> community, us, rightly complains.
> 
> As for libv, arguably he's just the messenger here, the person who
> shouts the loudest about this. The fact that he keeps shouting this
> message when things don't change is commendable.
> 
> And you know what, he's right: GPL violations are serious business and
> ignoring them is simply not a viable strategy for anyone involved. Luc
> has been consistently right on this subject from the very beginning,
> that's credibility.
> 
>> You also use the term "past behavior", which is a term that probably
>> means a different thing
>> to each recipient of these emails. It is not constructive to use such
>> terms; in those
>> TV shows that depict family problems, you get to see family members picking
>> on each other for things that happened in the past, remaining stuck 
>> perpetually
>> for that other thing in the past.
> 
> I outlined the behaviour I, and a lot of other people, perceive from
> companies like Allwinner in my previous email. Again, it's very clear.
> 
> Are you saying that we shouldn't argue about serious legal issues
> because they happened in the past? Yet you attack Luc for the things
> he's done in the past. What exactly are you trying to argue here?
> 
> So maybe you're trying to argue that we should focus less on the past
> and more on the future. Focusing less on the past isn't going to
> happen. These are, again, serious legal issues, they're not going to
> just go away. As for focusing on the future, we've made it very clear
> what we want from Allwinner: (L)GPL compliant code to replace the
> binary blobs they keep releasing. Very simple.
> 
>>> What I criticized was your non constructive attitude with libv
>>> just because you don't like their way to say things, instead of explaining 
>>> why
>>> do you think that you are right and others are wrong.
>> 
>> My point has been that if there are things in the repository that
>> should be fixed,
>> then point them out and explain them.
> 
> This isn't just about some little changes in a repository. This is
> about a systematic company practice of violating the licence
> agreements the software their continued existence is built on.
> 
> As far as I know, every single SoC they've produced since the A10 has
> had GPL issues. _Every_ one. There's a saying: "Once is happenstance.
> Twice is coincidence. The third time it's enemy action." We've seen
> this happen for ~9 different products. This is not a coincidence any
> more.
> 
>>> And no, saying that
>>> header files are easy to fix (it seems that you don't understand that 
>>> changing
>>> license text is not enough, but also fulfilling with the LGPL conditions, 
>>> like
>>> releasing source code) don't matter in this topic. About "Such cases occur
>>> frequently with many companies" (I doubt it) is sad if true.
>> 
>> Let's see a recent case.
>> It's about the MediaTek kernel for the bq E4.5 phone Ubuntu Edition,
>> and the post was written by Carsten Munk,
>> http://mer-project.blogspot.gr/2015/03/some-doubts-about-gpl-licensing-and-bq.html
>> Phoronix covered it with style,
>> https://www.phoronix.com/scan.php?page=news_item&px=BQ-Ubuntu-Phone-Bad-Kernel
>> It was about header files and here is the commit that fixed it,
>> https://github.com/bq/aquaris-E4.5/commit/34cf494bca625acad06274c3cba10aca148813c0
> 
> You're missing the forest for the trees: the point is that code with
> proprietary licenses shouldn't have been released in the first place.
> It might be easy to change, the point was that the change didn't
> happen before it left their hands.
> 
> In the case of the BQ Ubunt

Re: [linux-sunxi] Further Allwinner misbehaviour.

[Clement Wong]

Guys,

I think Jon is just saying how all hardware (and hardware + software) companies 
think,
not just for AW, same apply to Nvidia, AMD, Apple, etc.
So there isn’t really much we should troll here.

I personally believe AW has valid reason internally why not to open source 
directly
but taking time to open up piece by piece, as reviewing code to make sure it is 
not
violating copyrights is a huge task even for us a western company.

Therefore I believe and encourage AW taking action to this license issue, and 
keep
improving the driver, although it takes time.

I hope there would be a day that all hardware companies will work with mainline 
kernel
community in order to compete, but for now we’ll need to be shaking hands and 
keep
encouraging each others, instead of throwing shit.

Big thanks to all that concerns.

Clement

> On Jun 22, 2015, at 7:59 PM, Manuel Braga  wrote:
> 
> On Mon, 22 Jun 2015 12:07:24 -0400 "jonsm...@gmail.com"
>  wrote:
>> On Mon, Jun 22, 2015 at 11:54 AM, Rodrigo Pereira
>>  wrote:
>>> I don't understand any advantages of put a device driver code in
>>> secret. Someone can explain the advantage of a secret device
>>> driver? Maybe is about money. They want to license the code to some
>>> company and charge money for that. In case I want to buy the source
>>> code, how much this will cost?
>> 
>> There are many reasons for keeping device drivers code secret...
> 
> I am answering, not to oppose this points, but because i believe that
> this answer should be complemented in the context of allwinner's video
> engine. That has been in the focus of this discussions. So here goes.
> 
> 
>> 1) You believe you have an innovative hardware implementation and are
>> protecting it via trade secret. Releasing the driver source code will
>> provide register definitions and an understanding of how the hardware
>> works. Competitors will see this and copy your hardware.
> 
> Register definitions, which in large part have been already Reverse
> Engineered by the people involved in the Cedrus effort, that had
> started 2 years ago and which results can be seen in the wiki for
> everyone that wants to see.
> http://linux-sunxi.org/VE_Register_guide
> 
> What little is still missing is only a question of priorities and
> needs, because as everyone can see, this information was and is
> more than enough for the creation of a working vdpau implementation.
> http://linux-sunxi.org/Cedrus
> https://github.com/linux-sunxi/libvdpau-sunxi
> 
> There is nothing to hide.
> 
> 
>> 
>> 2) Your hardware implementation is violating patents or you are afraid
>> that people will sue you for patent infringement even when you aren't.
>> Closed source makes it much hard for trolls to launch a patent suit.
> 
> This patent trolls will not be very successful if they can be stopped by
> close source software, or are the patent trolls too greed to paid
> someone to look for targets.
> 
> This video engine was already successful reverse engineered, where it
> was found that this video engine hardware is of fixed-function-kind.
> Meaning that everything (the codec) are done by the hardware in the
> silicon die. The software driver task in only one of feeding the
> hardware.
> 
> All the secrets or patenta are in the hardware, and not in the software.
> 
> 
>> 3) You have licensed third party code for use in your device driver
>> and you don't have the ability to open source. The third party that
>> wrote this code wants to sell it multiple times so they refuse to open
>> source.  Common example -- lighting or physic engines in GPU drivers.
> 
> Then here, the solution is to rewrite what can not be open-sourced, 
> and as this video engine is very simples, this is not difficult task.
> 
> As can be seen, by the current cedarx driver, which is a rewrite.
> 
> 
> 
>> 
>> 4) You are afraid competitors with similar hardware will take the
>> source you have worked hard to write, modify a few lines, and have a
>> free driver for their hardware.
> 
> Free, like taking the linux kernel source and the android kernel source,
> and modify to add support for the some particular socs.
> Or by taking some LGPL license source code and include in a video
> engine driver.
> 
> 
>> 
>> 5) Your hardware is really messed up and almost broken. These warts
>> are embarrassing and you hide the work arounds in closed source.
> 
> Actually, this video engine is not bad.
> It has some (hardware) limitations, but this has been improving in
> newer versions, and up to now, i only found one undefined (maybe
> better to say unexpected because should not happen in normal use)
> This to say, that this video engine hardware is very well behaved,
> whatever can be writing to registers or whatever state the hardware get
> into, can always be recovered from.
> 
> 
>> 6) You licensed the IP for the hardware. As part of the IP licensing
>> agreement you are required to keep the register definitions closed.
> 
> Register definitions that are already here,
> http

Re: [linux-sunxi] Allwinner R8 module

[Clement Wong]

I think you should be happy that your work is in use by thousands.
And there is mention of sunxi in QA “I want to know more about the Allwinner R8 
processor!”.

Clement

> On May 11, 2015, at 10:23 AM, Luc Verhaegen  wrote:
> 
> On Sun, May 10, 2015 at 09:49:43PM -0400, jonsm...@gmail.com wrote:
>> Does anyone have any info on the new Allwinner R8 module being used in
>> the Chip $9 PC Kickstarter? It is A13+flash+RAM on module.
>> 
>> I'd like to get a pin out and projected price. That module has to be
>> really low cost if they are able to make a $9 computer out of it.
> 
> *sigh* I am amazed that people still fall for what i can now only call 
> the kickstarter trap.
> 
> * "only" 9usd
> * 1y delivery time
> * full mainline support
> * linux-sunxi is not mentioned even once
> 
> None of that fits together, and i am amazed that people actually fall 
> for that still.
> 
> Luc Verhaegen.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] how to get latest sunxi ?

[Clement Wong]

https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.4 

https://github.com/linux-sunxi/linux-sunxi/tree/stage/sunxi-3.4 


Or mainline. I’ve been using 3.19 for awhile now. 

Clement

> On May 11, 2015, at 1:48 AM, Antoine RODRIGUEZ  
> wrote:
> 
> Hi,
> 
> how can I get the lastest sunxi for A20 ?
> 
> I see here a lot of improvements but the git is stuck on 2014 ... Maybe I 
> don't look on the good branch...
> 
> Someone can advise me where to get the latest updates for sunxi ?
> 
> Best regards,
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Allwinner GPL violations: definitive proof.

[Clement Wong]

I wanna say big THANKS to Allwinner for this step, please continue to work in 
this direction.
I look forward to see more source code from you guys.
One small comment is it will be great if you guys can also use git internally, 
so we can see the changes along the way.

Clement

> On Feb 25, 2015, at 1:15 PM, Simos Xenitellis  
> wrote:
> 
> On Wed, Feb 25, 2015 at 5:55 AM, Luc Verhaegen  wrote:
>> 
>> Allwinner, it is very high time to start playing nice. You've been at it
>> for 4 years now and seem utterly incapable of or unwilling to change.
> 
> I think it's time for Luc to start playing nice. His toxic behavior
> does not help.
> Trying to berate both on list and off list, even new members to this
> Google group,
> is unacceptable behavior.
> It makes me wonder whether his abrasive behavior was actually a factor
> to the situation that we try to solve here.
> It's very ironic as well!
> 
> We see constructive efforts from Allwinner to fix issues
> and it makes sense for the community to be constructive as well.
> I do not even see an issue filed at
> https://github.com/allwinner-zh/media-codec/issues
> 
> Being constructive and nice takes you a long way,
> Simos
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [u-boot 2/2] sun5i: bump DEBE priority (useful on a10s only)

[Clement Wong]

Hey thanks for the blog @ssvb. I love to see this kind of analysis.
Next time maybe share it on the list?

Clement

> On Jan 22, 2015, at 5:05 PM, Hans de Goede  wrote:
> 
> Hi,
> 
> On 22-01-15 15:43, Michal Suchanek wrote:
>> Hello,
>> 
>> On 22 January 2015 at 14:26, Hans de Goede  wrote:
>>> Hi,
>>> 
>>> 
>>> On 22-01-15 08:30, Siarhei Siamashka wrote:
 
 On Tue, 20 Jan 2015 14:16:35 +0100
 Hans de Goede  wrote:
 
> Hi,
> 
> On 20-01-15 09:16, Siarhei Siamashka wrote:
>> 
>> On Mon, 19 Jan 2015 06:29:47 +0200
>> Siarhei Siamashka  wrote:
>> 
>>> On Sun, 04 Jan 2015 20:49:38 +0100
>>> Hans de Goede  wrote:
>>> 
 Hi,
 
 On 04-01-15 20:19, Michal Suchanek wrote:
> 
>  Setting magic 'reserved' hpcr bit on sun5i DEBE seems required
> for
>  smooth HDMI scanout of large frambuffer (eg. 1080p).
> 
>  This fix comes at the cost of some overall memory bandwidth so
> it
>  might be appropriate to detect a10s and only apply there (and
> not a13).
 
 
 Hmm, Sairhei is the expert on this, adding him to the Cc. Sairhei,
 what
 do you think of the proposed change ?
>>> 
>>> 
>>> I don't have A10s hardware, so have no idea and can't test anything
>>> myself.
>>> 
>>> It would be great to have a better description of what exactly is
>>> happening before the patch. And precisely how the patch is helping.
>>> A description of the test setup and benchmark numbers would be
>>> appreciated. And it would be perfect if somebody else could reproduce
>>> the test and confirm the results.
>>> 
>>> I may try to check A20 with the bus width artificially reduced
>>> to 16 bits (not a totally unrealistic configuration, since
>>> A20-OLinuXino-LIME board exists). If sun5i and sun7i are similar
>>> enough, then the magic reserved bit may have some effect there too.
>>> But that's a different hardware either way.
>> 
>> 
>> Done these tests with A20. Ironically, now the tables have turned and
>> A10 seems to be doing a better job than A20 at low DRAM clock speeds
>> (~408MHz) and 16-bit bus width when dealing with full-hd monitors.
>> 
>> Just like Michal observed on A10s, setting 0x5031 as DEFE host port
>> config makes things much worse on A20. Overall, the test results look
>> in the following way on A20 with 16-bit DRAM clocked at 408MHz (yes,
>> none of the real boards uses such a slow DRAM setup) while running
>> lima-memtester and driving 1920x1080-32@60Hz monitor:
>> 
>> 0x1035 - The screen regularly blanks, but comes back again instantly.
>> 0x1037 - The screen regularly blanks, but comes back again instantly.
>> 0x5031 - Severe screen shaking.
>> 
>> Unlike A10, there does not seem to be any difference between using DEBE
>> or DEFE for framebuffer scanout on A20, so using DEBE has the same
>> effect as listed above. Setting the magic 'reserved' hpcr bit 1
>> (0x1037 value) does not seem to have any effect on sun7i. It is
>> great that it is apparently helping on sun5i/A10s though.
> 
> 
> Thanks for running these tests, this makes me more confident that I
> only need to enable DEFE in u-boot on A10, and can directly use
> DEBE on the others.
 
 
 But what about A10s? Do we want to do something about it?
>>> 
>>> 
>>> Once we have some feedback from hramrach from running tests with /
>>> without the frontend enabled, then yes, unless the fix is to simple
>>> disable the frontend, and then u-boot probably is fine as is.
>> 
>> I need to re-test this but it seemed that on my a10s board enabling
>> and disabling scaler had pretty much no impact on display performance.
>> Increasing the priority of the display ports did not seem to increase
>> display performance either. However, setting the 'magic' bit degraded
>> memory throughput as reported by the lima-memspeed somewhat but
>> enabled jump-free lima-memtester rotating cube. Since a13 has no hdmi
>> this is moot for most sun5i hardware.
>> 
>> Affected would be the obsolete olinuxinos and a few HDMI sticks that
>> actually had a10s in them.
> 
> There are actually a lot of a10s using HDMI sticks out there (all later
> mk802 models use the a10s + many others) as well as various a10s
> based top setboxes and an a10s variant of the mini-x. So I would really
> like to get this fixed, I'm ok with applying your fix, but before that
> I would like to see the following confirmed:
> 
> 1) That currently you are using the scaler, since your patch modifies
> the scaler dram prio anything else would make no sense
> 
> 2) Please retest without the scalar, and if you've the same problem
> try applying the same fix / DRAM settings to the DEBE dram prio
> bits. See 
> http://ssvb.github.io/2014/11/11/revisiting-f

Re: [linux-sunxi] Wiki page to track allwinner datasheets ("user manual") errata

[Clement Wong]

Hi,

Wouldn’t it be easier if these PDF files are in some kind of markdown format?
Then it will be so much easier to do pull request, review, diff, see commit 
log, etc.
And it’ll be very easy to export as PDF.

Clement

> On Oct 1, 2014, at 9:14 AM, Simos Xenitellis  
> wrote:
> 
> 
> On Tue, Sep 30, 2014 at 7:32 PM, jonsm...@gmail.com 
>  mailto:jonsm...@gmail.com>> 
> wrote:
> On Tue, Sep 30, 2014 at 12:21 PM, Hans de Goede  > wrote:
> > Hi All,
> >
> > I think we should start an errata page on the linux-sunxi wiki somewhere,
> > specifically targeting errata for the official "user manual" documents.
> 
> Why not issue tracking on the github account Allwinner made?
> https://github.com/allwinner-zh/documents/issues 
> 
> 
> I'd like to see Allwinner get used to responding to a normal issues
> tracking system.
> 
> 
> Ideally, Allwinner should update the PDF documents once errors/omissions are 
> found.
> I do not know how fast they can attend to such issues, so it is important to 
> find out.
> 
> The second option is to maintain errata files on 
> https://github.com/allwinner-zh/documents/ 
> 
> for each SoC. 
> For the current issue for the A20, we create a new file into 
> https://github.com/allwinner-zh/documents/tree/master/A20 
> 
> called errata_datasheet.txt/errata_usermanual.txt and add the text that 
> describes what is changed.
> Then we sent a pull request so that Allwinner would merely need to click a 
> button at github.com  to accept the change.
> Then, they can take their time to update the original PDF docs. When that 
> happens, we clear the errata files.
> 
> If however Allwinner would prefer the community to do all the work with the 
> errata files,
> then the github.com  account for "allwinner-zh" could be 
> converted into an "organization" account,
> and then they can add a few of our github user accounts as members of the 
> "documents" repository.
> This means that we can deal with errata documents completely by ourselves, 
> and let Allwinner
> add those changes into future revisions of the documents.
> 
> If the above make sense, we can suggest them to Allwinner. 
> Are we OK with that?
> 
> Simos
> 
> 
> >
> > I know we already have various pages to document specific blocks, the
> > idea here would be to have a general errata page. The purpose is to have
> > a single place to gather doc fixes for blocks which are adequately
> > documented in the user-manual, except for one or two missing bits.
> >
> > IMHO it is not worth the trouble / useful to create an entire new page
> > for cases where we're talking about just 1-2 bits. But it would be
> > useful to gather these little fixes somewhere, hence the suggestion
> > to have a generic errata page. For blocks for which we already have
> > extensive documentation in the wiki, this generic page can contain
> > links to the documentation for these blocks.
> >
> > So good or bad idea ?
> >
> > And if you believe this is a good idea, any suggestions for a name /
> > hierarchy for these pages ?
> >
> > ###
> >
> > The specific case triggering this idea is the lack of documentation
> > for bits 10-12 of the GMAC clk register (0x01c20164). I've been in
> > contact with allwinner about these 3 bits, and they configure
> > the GMAC Transmit Clock Delay Chain (GTXDC), they are the transmit
> > equivalent of bits 5-7.
> >
> > Regards,
> >
> > Hans
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to linux-sunxi+unsubscr...@googlegroups.com 
> > .
> > For more options, visit https://groups.google.com/d/optout 
> > .
> 
> 
> 
> --
> Jon Smirl
> jonsm...@gmail.com 
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group

[linux-sunxi] "VidOn.me Publishes A New XBMC Source Tree"

[Clement Wong]

Hi guys, any comments on 
http://www.phoronix.com/scan.php?page=news_item&px=MTY4NjI ?

"VidOn.me has an Allwinner A20 based media player called VidOn.me AV100 that 
they are using a forked version for XBMC on, which unlike upstream mainline 
XBMC features full hardware accelerated video decoding and full Blu-ray Disc 
menu support, but like many Chinese companies VidOn.me have previously not 
released all the source code changes and modification as they are required to 
as XBMC is licensed under GPLv2 (GPL version 2), meaning their code have never 
had a chance to make it into upstream mainline XBMC as per the GPL, but now it 
looks like they might have released their latest code to comply with the GPL", 
wrote a Phoronix reader this morning. 

VidOn.me going back at least two years has had a commercial fork of the XBMC 
multimedia center software and shipped hardware devices with their media player 
fork running atop Android and offered complete hardware acceleration. While 
they or their associates, have reportedly sponsored XBMC in the past, there's 
been numerous reports about their violation of XBMC's GPL license with not 
releasing their source modifications. Originally, they also stripped out all 
references to XBMC. 

Harley, a Phoronix reader, wrote in today to say that it looks like they might 
be fully in compliance now with this GitHub repository with commits as of six 
days ago that appears to be their forked version of XBMC. However, I nor the 
one providing the news tip have yet been able to corroborate this first-hand. 
"VidOn.me have updated their repository for their XBMC fork on GitHub.com with 
new source code, which now looks to contain a new video player 'core' for 
Allwinner A20 (and I guess Allwinner A10 too since both uses the same CedarX 
VPU - Video Processor Unit) to decode videos." 

We'll hopefully find out soon enough whether this is their full, build-able 
source tree and whether any of the acceleration code will be of use to upstream 
XBMC developers.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Allwinner A10: the L2 cache may not keep up with the speed at 1GHz

[Clement Wong]

Hi Siarhei,

Thanks for you great work (again), I had to throw out djpeg/cjpeg version check 
to make it work, here's my version.

root@debian:~/cpuburn-arm# echo  `djpeg -v &1`
Independent JPEG Group's DJPEG, version 8d 15-Jan-2012 Copyright (C) 2012, 
Thomas G. Lane, Guido Vollbeding Empty input file
root@debian:~/cpuburn-arm# echo  `cjpeg -v &1`
Independent JPEG Group's CJPEG, version 8d 15-Jan-2012 Copyright (C) 2012, 
Thomas G. Lane, Guido Vollbeding Empty input file


Here's the result from my cubieboard.
Creating './whitenoise-1920x1080.jpg' ... done
CPU stress test, which is doing JPEG decoding by libjpeg-turbo
at different cpufreq operating points.

Testing CPU 0
 1488 MHz SKIPPED
 1440 MHz SKIPPED
 1392 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1248 MHz SKIPPED
 1200 MHz SKIPPED
 1152 MHz SKIPPED
 1104 MHz SKIPPED
 1056 MHz SKIPPED
 1008 MHz  OK
  960 MHz  OK
  912 MHz  OK
  864 MHz  OK
  816 MHz  OK
  768 MHz  OK
  744 MHz  OK
  720 MHz  OK
  696 MHz  OK
  672 MHz  OK
  648 MHz  OK
  600 MHz  OK
  576 MHz  OK
  528 MHz  OK
  480 MHz  OK
  432 MHz  OK
  408 MHz  OK
  384 MHz  OK
  360 MHz  OK
  336 MHz  OK
  300 MHz  OK
  288 MHz SKIPPED
  264 MHz SKIPPED
  240 MHz SKIPPED
  216 MHz SKIPPED
  204 MHz SKIPPED
  192 MHz SKIPPED
  180 MHz SKIPPED
  168 MHz SKIPPED
  156 MHz SKIPPED
  144 MHz SKIPPED
  132 MHz SKIPPED
  120 MHz SKIPPED
  108 MHz SKIPPED
   96 MHz SKIPPED
   84 MHz SKIPPED
   72 MHz SKIPPED
   60 MHz SKIPPED
   48 MHz SKIPPED
   30 MHz SKIPPED

Overall result : PASSED

I still have some cubieboards to test if you need.
Here's a libjpeg-turbo package for debian wheezy/armhf user if they would like 
to test.
https://drive.google.com/file/d/0B_3w0fkIKW4xTjVYSkVRVF9QOHc/edit?usp=sharing
https://drive.google.com/file/d/0B_3w0fkIKW4xajBTQ1ZRaWIwUWM/edit?usp=sharing


Clement

On May 6, 2014, at 11:34 AM, Siarhei Siamashka  
wrote:

> On Sun, 4 May 2014 11:36:10 +0300
> Siarhei Siamashka  wrote:
> 
>> Hello,
>> 
>> Yesterday I have been trying to debug what's causing the XFCE desktop
>> background artefacts on my A10-Lime, which look like this:
>>
>> http://people.freedesktop.org/~siamashka/files/20140504/a10-l2-cache-fail-artefacts-in-xfce.png
>> 
>> And narrowed them down to ARM Cortex-A8 L2 cache failures, which
>> are reproducible when doing JPEG decoding:
>> 
>> $ djpeg -v   
>> libjpeg-turbo version 1.3.0 (build 20130811)
>> 
>> $ wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg
>> 
>> $ djpeg A10-LIME.jpg | md5sum
>> 691497bd2e5d36976c1ea3150de89df6  -
>> 
>> $ djpeg A10-LIME.jpg | md5sum
>> 6a874af750f92e1e3c019f2df7edf3f7  -
>> 
>> $ djpeg A10-LIME.jpg | md5sum
>> 297b98ba10233cbbcea2566e1c4fd7c7  -
>> 
>> Please note that the md5sum of the decoded JPEG file is different for
>> each run.
>> 
>> There are other ways to reproduce it (the FFmpeg test suite can detect
>> this problem too), but the djpeg test is very simple and fast to do.
>> In the case if somebody does not have the djpeg tool from libjpeg-turbo
>> in their distro, I have a static djpeg binary here for extra
>> convenience:
>>http://people.freedesktop.org/~siamashka/files/20140504/djpeg-static
>> It has been built using:
>>
>> http://people.freedesktop.org/~siamashka/files/20140504/build-static-djpeg.sh
>> 
>> On my collection of just three Allwinner A10 based devices, I get the
>> following results with the libjpeg-turbo djpeg test (and the default
>> CPU core voltage):
>>A10-Lime- fails at 1008MHz (960MHz is fine)
>>Mele A2000  - fails at 1152MHz (1104MHz is fine)
>>Cubieboard1 - fails at 1152MHz (1104MHz is fine)
>> 
>> Why is it likely related to the L2 cache? Because this problem goes
>> away if we disable the L2 cache by adding somethin

[linux-sunxi] Wayland

[Clement Wong]

Hi guys,

As Collabora has announced Wayland-based shell Maynard today, the demo looks 
quite promising under RPi.
I would like to know the possibility of running sun4i/sun7i under Wayland, so I 
can dig in during Easter.

Also noticed Hans just joint Wayland, maybe you have played with it already, or 
just focusing on input?

Thanks.

Regards,

Clement

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

[Clement Wong]

Looks exciting!! Especially for us who use full HD!
Hope we'll be able to test something soon. :)

Clement

On Apr 6, 2014, at 12:43 PM, Siarhei Siamashka  
wrote:

> On Sat, 05 Apr 2014 17:58:11 +0200
> Jens Kuske  wrote:
> 
>> On 03/04/14 07:49, Siarhei Siamashka wrote:
>>> 
>>> I would guess that the .tpr settings, bundled with .cas=6, are likely
>>> assuming 400MHz memory clock speed. Which also agrees with the tRFC
>>> hardcoded values as you mentioned above. And also with the A10
>>> and A20 user manuals, which specify 0~400MHz range for SDRAM_clk.
>>> 
>>> The .cas=9 style sets of timings are likely very conservative and
>>> assuming memory clock speeds up to 667MHz if we take the cas value
>>> as a hint. If we are running dram at around 480MHz, these settings
>>> may unnecessarily sacrifice some performance.
>> 
>> I found some documentation for TPR registers in the rk30xx manual from
>> radxa. Their dram controller is pretty much different, but comparing the
>> default values and settable bits of the TPR registers makes it likely
>> that at least these registers have nearly the same bitfields.
>> 
>> This makes the .cas=6 set look like:
>> tMRD = 2, tRTP = 4, tWTR = 4, tRP = 6, tRCD = 6,
>> tRAS = 18, tRRD = 4, tRC = 24, tCCD = 0
>> tAOND_tAOFD = 0, tRTW = 0, tFAW = 18, tMOD = 0, tRTODT = 0
>> tXS = 200, tXP = 8, tCKE = 3
>> 
>> Assuming this is valid, we can do some trail and error again and try to
>> figure out the original timings.
>> 
>> As it turns out, your guess was pretty good. The settings *exactly*
>> match DDR2(!)-800E speed bin at 400MHz. Its DDR2 again, as with tRFC.
>> Interesting part is, if we assume DDR3-1333H chips (as on cubieboard)
>> many parameters are still in spec up to 480MHz (not all however, tFAW,
>> tXS and what else I missed not).
>> 
>> And for the .cas=9 set, most settings match DDR3-1333H speed bin at
>> 667MHz. But some settings, like tFAW and tXP are too low,
>> they only fit for ~420MHz.
>> 
>> tMRD = 3, tRTP = 5, tWTR = 5, tRP = 9, tRCD = 9,
>> tRAS = 24, tRRD = 6, tRC = 33, tCCD = 0
>> tAOND_tAOFD = 0, tRTW = 0, tFAW = 18, tMOD = 0, tRTODT = 0
>> tXS = 512, tXP = 10, tCKE = 4
> 
> That's a very nice catch. Thanks! Looks like this is a stepping stone
> in the memory controller reverse engineering.
> 
> However things would have been surely much easier if all of this was
> properly documented by Allwinner.
> 
>> I tried to calculate the correct parameters for 480MHz on cubietruck,
>> and currently lima-memtester is running without any errors till now. I
>> first accidentally kept the clock at 432MHz and only changed the tprs,
>> and even that gave a ~150MB/s boost at tinymembench compared to the
>> original values.
>> This is highly experimental, but if somebody wants to try (only
>> cubietruck, other dram chips need different timings):
>> .clock = 480
>> .cas = 7
>> .tpr0 = 0x30b27790
>> .tpr1 = 0xa078
>> .tpr2 = 0x0001b200
>> 
>> These timings are calculated by hand, but maybe this could lead to some
>> program or even function in u-boot that calculates matching parameters
>> for given dram chip type and speed.
> 
> Well, not a big surprise, but my "lucky" Cubietruck fails
> lima-memtester tests with these settings too:
> 
> Kernel driver is version 14
> Detected 1 Mali-400 GP Cores.
> Detected 2 Mali-400 PP Cores.
> FB: 1280x720@32bpp at 0x51001000 (0x00A8C000)
> Using dual buffered direct rendering to FB.
> 
> memtester version 4.3.0 (32-bit)
> Copyright (C) 2001-2012 Charles Cazabon.
> Licensed under the GNU General Public License version 2 (only).
> 
> pagesize is 4096
> pagesizemask is 0xf000
> want 300MB (314572800 bytes)
> got  300MB (314572800 bytes), trying mlock ...locked.
> Loop 1:
>  Stuck Address   : ok 
>  Random Value: ok
>  Compare XOR : ok
>  Compare SUB : ok
>  Compare MUL : ok
>  Compare DIV : ok
>  Compare OR  : ok
>  Compare AND : ok
>  Sequential Increment: ok
>  Solid Bits  : ok 
>  Block Sequential: ok 
>  Checkerboard: ok 
>  Bit Spread  : ok 
>  Bit Flip: testing 221FAILURE: 0xf7ff != 0xf700 at offset 
> 0x03e041fc.
> FAILURE: 0x0800 != 0x080c at offset 0x03e04200.
> FAILURE: 0xf7ff != 0xf706 at offset 0x03e04204.
>  Walking Ones: ok 
>  Walking Zeroes  : ok 
> 
> Loop 2:
>  Stuck Address   : ok 
>  Random Value: ok
>  Compare XOR : ok
>  Compare SUB : ok
>  Compare MUL : ok
>  Compare DIV : ok
>  Compare OR  : ok
>  Compare AND : ok
>  Sequential Increment: ok
>  Solid Bits  : ok 
>  Block Sequential: ok 
>  Checkerboard: ok 
>  Bit Spread  : ok 
>  Bit Flip: testing 213FAILURE: 0xfbff != 0xfb00 at offset 
> 0x038051bc.
> FAILURE: 0x0400 != 0x04ff at offset 0x038051c0.
> FAILURE: 0xfbf

Re: [linux-sunxi] sunxi-devel branch updated to 3.15-rc1

[Clement Wong]

Hi Hans,

Can A10/20 runs on mainline without hacks now?
What's works and what doesn't?

Cheers,

Clement

On Apr 14, 2014, at 5:23 PM, Hans de Goede  wrote:

> Hi All,
> 
> I've just updated: 
> https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel
> to 3.15-rc1
> 
> This means that a whole lot of patches have been dropped as they have all
> been merged, hurray! The big next item on the to get merged list is
> the mmc code.
> 
> Note for this to work with more then 1 cpu core on sun7i you also need my
> sunxi-next u-boot branch:
> https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-next
> 
> Enjoy,
> 
> Hans
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [Cubietruck] 全志A20_DMA开发说明文档_V1.0_20130315

[Clement Wong]

Hi,

Feel free to poke if you need translation for some specific parts, I’m willing 
to help.

Clement

On Apr 8, 2014, at 2:05 PM, yog...@gmail.com wrote:

> There was no intention to post the question twice. It happened by mistake and 
> i know it makes no sense, but nothing was intentional. 
> 
> I know about google translate, it does not work properly for Chinese 
> characters.
> 
> Also i am aware that there is no proper documentation of allwinner for many 
> subsystems. Hence i had asked if the kernel maintainers  for sunxi could 
> merge the DMA test files (sun7i_dma_test.c) as part of the kernel as it is 
> quiet useful for everybody..
> 
> -- yk
> 
> On Saturday, April 5, 2014 12:35:52 PM UTC+5:30, Ivan Kozic wrote:
>> First of all - Google Translate? This is how I translate their comments in 
>> the code and also datasheet for AXP... Btw, most of the subsystems are not 
>> covered by their documentation at all, so nothing strange there.
>> 
>> Second - please don't post the same post twice - it is really not polite and 
>> it makes searches for the topic harder later. There's also a thin line 
>> between spamming and being eager, so I guess that most people will actually 
>> not reply when they see two same topics written in the same day. Plus you're 
>> just bloating up the list like this - it really makes no sense.
>> 
>> If there's no answer for 2-3 days, you could bump the topic, although I'm 
>> pretty sure it's also forbidden here (but one or two times can't hurt much I 
>> guess).
>> 
>> On Thursday, April 3, 2014 9:20:47 AM UTC+2, yog...@gmail.com wrote:Hello 
>> Sunxi,
>> 
>> 
>> 
>> I saw a document 全​志​A​2​0​_​D​M​A​开​发​说​明​文​档​_​V​1​.​0​_​2​0​1​3​0​3​1​5 
>> related to DMA operations after google search.
>> 
>> 
>> 
>> Also there were some DMA test files for Allwinner A20, sun7i_dma_test.c 
>> which were available on some local server released by allwinner A20 for 
>> kernel 3.3
>> 
>> 
>> 
>> 
>> 
>> Could somebody please make these DMA test files a part of standard sunxi 
>> kernel 3.4 onwards as they will be really useful to understand the working 
>> of DMA in Allwinner A20 chipset.
>> 
>> 
>> 
>> Also if somebody could convert the Chinese document 
>> 全​志​A​2​0​_​D​M​A​开​发​说​明​文​档​_​V​1​.​0​_​2​0​1​3​0​3​1​5 to English and put 
>> in into some standard server path so that it is useful for everyone.
>> 
>> 
>> 
>> 
>> 
>> --yk
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.