SoC: Back and forth!

[sebt3]

You're giving me way too much credit

Nope. all the credit is rightly deserved.

there have been lots of negative feedback lately.

Where? I'll hunt them down

I kind of wish ED chose x86 so I can finally retire.

That's something I can get. You even took over my pnd_run.sh mess while I was away. But you're awesome and this community needswants you

 

[wej]

In 2007 armhf compilers did not exist, it has little to do with the driver..

I was pretty sure that even with GCC 4.1 it was possible to compile with hardfloat.

there have been lots of negative feedback lately. I kind of wish ED chose x86 so I can finally retire.

I just wanted to say (in case my posts about the Pandora kernel have been interpreted this way), I did not mean to criticize your work on the kernel in any way. Obviously, without your work, the Pandora kernel would be in a much worse state. I really appreciate your work.

 

[Linux-SWAT]

there have been lots of negative feedback lately. I kind of wish ED chose x86 so I can finally retire.

I just wanted to say (in case my posts about the Pandora kernel have been interpreted this way), I did not mean to criticize your work on the kernel in any way. Obviously, without your work, the Pandora kernel would be in a much worse state. I really appreciate your work.

A delicate way to criticize.

Curiously, i don't see any of your patches in the OP kernel git.

Notaz, you kick so much asses i'm sure your legs hurts.

 

[wej]

A delicate way to criticize. Curiously, i don't see any of your patches in the OP kernel git.

What exactly is your problem? Is it really that hard to understand what I wrote and see it in the context with previous posts?

Also, it is not exactly nice to change posts of others when quoting. I did not write anything in bold/underlined.

 

[Michoko]

- I'm not part of the Pandora team and I don't really matter compared to notaz. I'll port DraStic whatever is chosen and whatever other emulators I work on in the future, if that's where the concern it. Also, I don't prefer x86, if all other parts of the SoC are equal, that's just not always the case. I'd rather the thing stayed with ARM too if it meant avoiding losing notaz, because there's a much bigger risk that this won't work without him.

You're giving me way too much credit, there have been lots of negative feedback lately. I kind of wish ED chose x86 so I can finally retire.

Sorry notaz to hear you didn't feel the love we all have for you lately. Frankly, I value all your contributions so much that it made me change my mind about the kind of SoC I'd wish for the Pyra. I generally don't put people on a pedestal, but please don't underestimate the aura you have here.

 

[Linux-SWAT]

A delicate way to criticize. Curiously, i don't see any of your patches in the OP kernel git.

What exactly is your problem? Is it really that hard to understand what I wrote and see it in the context with previous posts?

I just pointed out that some people do, some doesn't.

You don't have to take that as an aggression.

For instance, i know nothing about kernel development and can't do nothing about it apart translating some docs, so i won't overreact like you do if someone tells me i propose no patch.

You should not take things like this especially on those forums where the vast majority of member are nice and constructive.

We're now headed to the future with a new machine which looks more than promising, and without a doubt will convert more and more people into open source and maybe (let's dream) a more humanist way of living.

 

[ghostpatch]

I think wej's point is that it would be easier to maintain the kernel with a completly open source graphics driver or that you could stick more closely to a standard kernel (whether its true or not I don't know)... or something along those lines.... actually I forgot

Somehow the debate turned in a different direction.

jup   "Obviously, without your work, the Pandora kernel would be in a much worse state."   was a poor choice of words.

 

[Hồng Thất Công]

In 2007 armhf compilers did not exist, it has little to do with the driver..

I was pretty sure that even with GCC 4.1 it was possible to compile with hardfloat.

What's the matter with you?  Hardfloat or softfIoat, I, as a user, don't see any problem with the Pandora since I've been owning it.  It has been working just fine.  It runs all my emulators just fine.  Why do you keep insisting on it should have been this and it should have been that?  You weren't part of the team.  You didn't know what obstacle they had to face.  Yeah if I knew, I would like to have been born in a billionaire family.

 

[WizardStan]

Also, it is not exactly nice to change posts of others when quoting. I did not write anything in bold/underlined.

The bold was to emphasize the problem he had with what you said. It's common practice, not just forum etiquette but also business practices will highlight things that need attention.In this particular instance you said "would be in a much worse state" which carries an implication that you believe that it is currently in a bad state, worse than it should be but not as bad as it could be. Whether that's what you meant or not is irrelevant, such is the nature of the English language with its ambiguities and implied effects. I'm going to assume you didn't mean it to be an insult but you have to accept that without knowing exactly what you were thinking at the time it is entirely possible for someone to see it as an insult. You shouldn't take offense when someone points out the ambiguities in your statements.

 

[ghostpatch]

^^ wej' was saying the PowerVR blob affected kernel development, but apperently thats not the case according to some dev's. Then it became a life of its own. He did't say there's a problem with Pandora although the statement: "Obviously, without your work, the Pandora kernel would be in a much worse state."   was a poor choice of words.

 

[wej]

For instance, i know nothing about kernel development and can't do nothing about it apart translating some docs, so i won't overreact like you do if someone tells me i propose no patch.

That's not what caused my reaction. It was the sentence before that comment.

You should not take things like this especially on those forums where the vast majority of member are nice and constructive.

I have been trying to be as constructive as possible in this thread. That does not mean, that I should not be allowed to say things that I don't like about certain things. At the same time I suggested things to improve things on the Pyra (which is why I said what I did not like in the first place). None of that was meant to criticize people. All those decisions made in the past have been made for certain reasons and I know that. As notaz was upset about negative feedback and some of my posts could possibly have been interpreted as such, I wanted to say that it was never intended as such.

 

[wej]

I think wej's point is that it would be easier to maintain the kernel with a completly open source graphics driver or that you could stick more closely to a standard kernel (whether its true or not I don't know)... or something along those lines.... actually I forgot

Somehow the debate turned in a different direction.

jup   "Obviously, without your work, the Pandora kernel would be in a much worse state."   was a poor choice of words.

Yeah, that's what I meant. For the same reason did I suggest the HID thing.

I didn't mean to say the kernel's state was horrible, and I especially did not mean to say it was the fault of anyone, but was rather using those words because I had previously said that I didn't like certain things about the kernel (not being mainline...).

You shouldn't take offense when someone points out the ambiguities in your statements.

Yes, you are right and I'll try not to do that.

 

[WizardStan]

He did't say there's a problem with Pandora although the statement: "Obviously, without your work, the Pandora kernel would be in a much worse state."   was a poor choice of words.

Yes, that is exactly what I was saying: ambiguities in the English language means the statement could be taken as an insult, Linux-SWAT pointed out the insult but wej himself should not be insulted by that, it's just an unfortunate byproduct of written communication. If someone misunderstands what you said simply apologize for the error and use different words, exactly as he's done above. All good now.

 

[wej]

All good now.

Yeah, let's just move on. Too much off-topic already.

 

[Linux-SWAT]

I read somewhere (rumors, rumors...) that a softfp program on a hardfp machine can use the hardfp hardware anyway.

 

[wej]

The difference between softhardfp and hardfp is basically the way the parameters are passed. While with softhard float the floating point hardware is used, it is still slower than hardfp. How much slower it actually is depends on the code and can vary quite a bit.

 

[CrazyIvan]

The Allwinner was announced after we already had secured the OMAP5...

Allwinner seems to be mostly an Android shop, from a first look - the Cubietruck board that uses one of those (http://cubieboard.org/) comes with Android preinstalled, for example. And all the Linux distributions for that board seem to use the same 3.4.75 kernel...

Here, the board is based on EOMA68 'open standard' module with Allwiner A20. It's running Mer linux and is actually a testbed for plasma active & kde5, you can find some videos on Aaron Seigo's Google+ page. There is a big chance of A80 EOMA68 module i guess.

I'd love for pyra to be able to be part of that community since it have enough low level linux developers to not depend really much on our single-man support team aka notaz. So called 'Real Life' can be unpredictable sometimes and supporting pandora (or later pyra) isn't his day job

 

[God Ginrai]

I thought the cores have to be clocked the same in big.little. You can only switch between the sets of cores.

But maybe I misunderstood that.

Either way the question still is valid.

How efficient is an a7 at the same speed as the a8 in the Pandora compared to an a15 at the same speed (not MHz)?

 This is why I said to read Exophase's post about big.LITTLE....

I've bolded some parts for emphasis:

That's actually pretty interesting.

Does that mean a Quad-Core A15 SoC will most probably use MORE CPU Power when running something simple like a SNES emulator than a Dual-Core A15 SoC, simply because all SoCs run at the same clock (and 4 is more than 2)

All of the cores must run at the same clock speed only when active. When active the individual cores can be turned off either through power gating (actually shut off) or clock gating (clock is turned off, the logic in the chip is basically "waiting.") With power gating virtually zero power is consumed. With clock gating, the gates consume static non-switching power via leakage. The reason why you have both is because with clock gating you can usually retain state, for example of registers and cache, so long as they don't have dynamic elements (like DRAM). With power gating you lose everything and therefore you have to save and restore it to somewhere else, which takes a lot of extra time and adds a lot of complexity. You don't want power gating if there's something you turn on and off again constantly, you will waste time and energy in all of the transitions. But in the case where two cores are basically never being used they shouldn't be powered on.

EDIT: Notaz, I appreciate all of the work you've done for the system, as well as your work on Picodrive, Ginge, etc. I would be quite sad if you stepped down, but I wouldn't want you to dislike what you are doing either.

-God Ginrai

 

[_jr_]

In my oppinon big.LITTLE might bring a huge power advantage to the Pyra.


I've read of A7 cores that are slightly faster than the A8 (at least what concerns clockspeed).


Even if they are only as fast as Pandora cores they consume less power than A8.


So there are 2 advantages.


1: Things that run on Pandora will last longer on the Pyra.


2: If developers want to support the Pandora further they also can optimize their Programs to run well on the A7 cores. That will also give more battery life.

In one of the many threads about this subject Exophase already explained, that the A7 NEON unit is most probably slower on (Pandora-)optimized NEON than the Pandora, even with the (slightly) higher clock rates typically available. How much slower is unknown, but it might make some of the more demanding - even though optimized - emulators unusable on an A7.

 

[notaz]

In 2007 armhf compilers did not exist, it has little to do with the driver..

I was pretty sure that even with GCC 4.1 it was possible to compile with hardfloat.

Wrong, it only appeared in 4.5, which only came out in 2010. You're probably mixing it with softfp that's already on pandora.