Pandora 2 specifications and price

[Foxgod]

We are looking at an 64-bit ARM P2

Which doesn't even have any processors announced yet, there is no chance you can get this in low volume even in 2013-2014 that Craig keeps talking about.

Exactly. And the wider address space is just more power hungry. This is ARM trying to have an in to the server market. Not for use in mobile devices near term IMO.

I dont think craig really finalized the specs anyway, hes just looking into what can be done.


Its obviously hes doing research as of late.

 

[Grench]

One thread regarding the issue of microSD Vs full size SD in capabilities (which you lost repeatedly but refuse to bow out gracefully).

Wow. Just wow.


You unilaterally state that 2 full sized SD cards is strictly better than 2 full sized SD cards and 1 microSD card and declare that a victory for yourself. Yesterday when this was a debate I thought there was merit to it, that there must be something I was misunderstanding in your arguments. There's no merit in a debate where one person declares victory before all points have been understood. I'm done. You are so ingrained in your belief that I'm quite certain that you are wrong and I will never convince you of it or you are right in a way that is so convoluted and backwards that you will never convince me. Sorry for having wasted your time.

I thought you were smarter than that. You're confusing two entirely different arguments again.


The victory I declared was in the overall superiority of full sized SD cards to microSD cards in every way that matters except sheer dimensional volume.


That is a different argument than whether or not an internal microSD card slot is worth while.


The primary purpose to an internalized card slot (of any kind) is for use as a boot, swap and persistent storage device - and to prevent accidentally ejecting it. I want my boot, swap and persistent storage card to be as fast, hardy and high capacity as I can get. Between the two devices, microSD and full sized SD, SD wins in those capabilities.


In a hypothetical device with a microSD internal card and two external full sized SD cards, by the above statement, I would be forced to use one of the full sized SD cards as my boot, swap and persistent storage - just like I do on my existing Pandora. That makes the internal slot that you and Exo are so hot for - useless for it's primary purpose.


Flip that around and put a full sized SD card internal - and I'd use the heck out of it. I'd use that with the biggest, fastest, most robust card I've got. AND at that point, I'd only need one external full sized SD card slot and I'd be set.


So, hopefully that clarifies it and you'll kindly stop misstating my argument for me - and please, if you must continue to insert yourself in this, would you, and Exo for that matter, please make a logical argument why you NEED the internal slot to be a microSD? I've already, repeatedly, stated my reasons against having that slot be microSD.


It's all hypothetical now unless the Pandora 2 design team wakes up. From Exo's and my recent polls they could loose on the range of 40% of their customer base just because a large number of their existing customers dislike microSD enough to pass if the next unit has only microSD.


We'll see - hopefully they're early enough in the design to fix this and do it right with full sized SD slots.

 

[Grench]

Still no hardware out, but ARM 64bit is on the way:


http://www.phoronix....item&px=MTEzNDg

Wow - that would be VERY cool. Nifty that they're talking about merging the instruction set into the Linux kernel even before you can buy the processors. You all know that there have to be beta chips sitting somewhere if they've done this, right? So - 64bit ARM is probably coming to the world inside of 18 months. To the Pandora 2? I have no idea - but that might explain the 8GB RAM questions.

The only way the P2 could have a 64bit arm chip is if we get used as guinea pigs/beta testers..

And how, exactly, is that any different from the rest of the Pandora project? A -good- hardware beta test has at least 200+ people in it. A -great- one will often have upwards of 2-3 thousand. We -are- all a beta testing group. And, in general, we're all quite happy about it.

 

[slaeshjag]

After the disaster that is the GPU in most pandoras out there, I think most devs beg to differ

 

[Exophase]

There are no beta 64-bit ARM chips lying somewhere. The architecture details were revealed. You don't need to have the chip to start adding support into Linux or GCC or whatever (nor should this be the way it works!).. look at x86-64, work started with that long before anyone could get the CPUs. And x86 ISA changes have faster time to market because they aren't licensed off to third parties.


The closest you can get right now is an FPGA implementation from Applied Micro that MAY be available. That's a real far cry from an ASIC, and it's irrelevant because their design isn't something you'll be able to use in a mobile device. It's for servers.

 

[Grench]

There are no beta 64-bit ARM chips lying somewhere. The architecture details were revealed. You don't need to have the chip to start adding support into Linux or GCC or whatever (nor should this be the way it works!).. look at x86-64, work started with that long before anyone could get the CPUs. And x86 ISA changes have faster time to market because they aren't licensed off to third parties.


The closest you can get right now is an FPGA implementation from Applied Micro that MAY be available. That's a real far cry from an ASIC, and it's irrelevant because their design isn't something you'll be able to use in a mobile device. It's for servers.

Apples, oranges and watermelon. We're talking about having it pre-loaded into the Linux kernel. You can re-compile your kernel to your hearts content, but things only get into the main kernel IF they can be tested and the devs to Mr. Torvalds himself have a chance to see that they will 'do no harm'. So - if it's going into the kernel, there fairly well HAVE to be at least a handful of 64bit ARM processors floating about to test it on before inclusion in the default kernel.


Or do you ordinarily include your code, untested, into the core workings of production systems?

 

[Exophase]

You're talking about code that no one can run in the first place. Exactly what harm COULD it do if no one can even run it? Your logic is faulty.


Furthermore, how does a set of patches from ARM equate to full upstream integration and/or Linus's blessing? And what leads you to believe that ARM themselves wouldn't have some kind of functional model like an FPGA design (or even a software simulation) that, while capable of running a64 code has no actual connection to any physical product? They even say outright there's no physical hardware platform yet..

 

[Grench]

You're talking about code that no one can run in the first place. Exactly what harm COULD it do if no one can even run it? Your logic is faulty.


Furthermore, how does a set of patches from ARM equate to full upstream integration and/or Linus's blessing? And what leads you to believe that ARM themselves wouldn't have some kind of functional model like an FPGA design (or even a software simulation) that, while capable of running a64 code has no actual connection to any physical product?

Sheesh - I, for one, sure hope they wouldn't fill the kernel full of code that hasn't been tested to do what it's supposed to do. Not much of a way to do that without a chip. In my experience they've always been slow to market on additional processor support - forcing new system users to recompile on their own. In this case, though, it's moving much faster. No way they're doing that without code testing.


Or are you now arguing that Linux development is sloppy and poorly thought out? Or what?

 

[Exophase]

Sheesh - I, for one, sure hope they wouldn't fill the kernel full of code that hasn't been tested to do what it's supposed to do. Not much of a way to do that without a chip. In my experience they've always been slow to market on additional processor support - forcing new system users to recompile on their own. In this case, though, it's moving much faster. No way they're doing that without code testing.

Or are you now arguing that Linux development is sloppy and poorly thought out? Or what?

Are you listening to a word I'm saying? No one has filled the kernel with anything. Patches have been submitted. That's it.


And no, you do not need a chip to test the code. You want to test it? Add AArch64 support to qemu. Now you can test it. Or maybe you think this is a comparable workload to designing, testing, and taping out an actual hardware solution. You're just willing to rationalize anything to support your flights of fancy.

 

[Aurekana]

Looks like if Craig is really committed to a 64-bit arch to allow for more than 4GB of RAM, there are existing MIPS64 SoCs on the market at the moment, such as: http://www.broadcom....siness/BCM1125H


Downside is that switching to the MIPS arch would break compatibility with all existing Pandora software.


Edit: Dual core version of the above link: http://www.broadcom....rovider/BCM1250, and an eval board for it: http://www.broadcom....enter/BCM91250A


Disclaimer: I do not work for, or tend to promote, Broadcom. Was just the first result in my search.

 

[Exophase]

BCM1125H would not be a good choice for Pandora 2 even ignoring the incompatibility.. it has two cores but only goes up to 800MHz (with perf/MHz maybe comparable to Cortex-A9) uses way too much power (4W at 400MHz, presumably much more at 800MHz - the entire Pandora consumes around 1.5W) and has a pretty small amount of L2 cache. It also doesn't have many of the peripherals a good mobile SoCs will have like 3D, display controller, or SD card, or even something better than DDR1 memory.. it's a 10 year old chip intended for networking and it shows.


You'll find some 64-bit PPC SoCs with similar problems. Medfield might have been suitable had it actually kept 64-bit support enabled.

 

[Aurekana]

BCM1125H would not be a good choice for Pandora 2 even ignoring the incompatibility.. it has two cores but only goes up to 800MHz (with perf/MHz maybe comparable to Cortex-A9) uses way too much power (4W at 400MHz, presumably much more at 800MHz - the entire Pandora consumes around 1.5W) and has a pretty small amount of L2 cache. It also doesn't have many of the peripherals a good mobile SoCs will have like 3D, display controller, or SD card, or even something better than DDR1 memory.. it's a 10 year old chip intended for networking and it shows.


You'll find some 64-bit PPC SoCs with similar problems. Medfield might have been suitable had it actually kept 64-bit support enabled.

Yeah, after doing some more in depth searching, it looks like the newer MIPS64 SoCs comparable to ARMv8 will be released about the same time as the latter, so there's really no point in considering a switch between the architectures.


EDIT: There might not be a need to move to a 64-bit arch; according to Ti's whitepaper on the OMAP 5, it has some form of physical address extension to support up to 8GB of memory, despite being a 32-bit processor. http://www.ti.com/li...048/swpt048.pdf (Page 9)

 

[Foxgod]

BCM1125H would not be a good choice for Pandora 2 even ignoring the incompatibility.. it has two cores but only goes up to 800MHz (with perf/MHz maybe comparable to Cortex-A9) uses way too much power (4W at 400MHz, presumably much more at 800MHz - the entire Pandora consumes around 1.5W) and has a pretty small amount of L2 cache. It also doesn't have many of the peripherals a good mobile SoCs will have like 3D, display controller, or SD card, or even something better than DDR1 memory.. it's a 10 year old chip intended for networking and it shows.


You'll find some 64-bit PPC SoCs with similar problems. Medfield might have been suitable had it actually kept 64-bit support enabled.

Yeah, after doing some more in depth searching, it looks like the newer MIPS64 SoCs comparable to ARMv8 will be released about the same time as the latter, so there's really no point in considering a switch between the architectures.


EDIT: There might not be a need to move to a 64-bit arch; according to Ti's whitepaper on the OMAP 5, it has some form of physical address extension to support up to 8GB of memory, despite being a 32-bit processor. http://www.ti.com/li...048/swpt048.pdf (Page 9)

Would be great if that turns up in time!

 

[Linux-SWAT]

Linus about PAE:


https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/

 

[Askarus]

EDIT: There might not be a need to move to a 64-bit arch; according to Ti's whitepaper on the OMAP 5, it has some form of physical address extension to support up to 8GB of memory, despite being a 32-bit processor. http://www.ti.com/li...048/swpt048.pdf (Page 9)

Reading the whole article makes my happy .


Thanks for sharing the link.

 

[WizardStan]

So, hopefully that clarifies it and you'll kindly stop misstating my argument for me - and please, if you must continue to insert yourself in this, would you, and Exo for that matter, please make a logical argument why you NEED the internal slot to be a microSD? I've already, repeatedly, stated my reasons against having that slot be microSD.

No. You've dismissed every counter example presented to you, every compromise, every argument as not being exactly a 100% perfect match to your very specific use case. When you can simply ignore logic like this and declare your way absolutely superior in all ways then there is no reasoning with you.


For the record, neither Exophase nor I have ever once said that the internal slot needs to be microSD. The argument we have made several times is that it simply does not need to be a full sized SD card. It is you who is insisting that it needs to be something, and you have used your own personal contradictory use case as reasoning for that; we have simply pointed out that your use case is not everyone's use case, that your use case will absolutely fail for people who are not you, and that a compromise is the only way to make everyone happy, but you refuse to compromise.


Whatever, your arguments are egocentric and unless the next thing you say is "I didn't consider that other people might want to use their device differently from me and I guess a compromise a compromise where everyone's use case is covered and no one (not even me) loses their desired functionality wouldn't be so bad, even if it meant there exists a microSD card" then there is no point at all in trying to carry on this conversation. I will not respond again to anything you say ever. Sorry for having wasted everyone's time in a pointless debate.

 

[Foxgod]

Internal Micro SD slot would save space compared to Nand.


Internal SD slot would probably not save space at all, might even take more space.


And it doesnt matter which is faster, what matters is finding a Micro SD that is fast enough.


WHo cares if its 90 mbits or 60 mbits, if both are enough to do the job.


Its not like the rest of the hardware will magically go faster, if the SD card is uber duber fast (Uber Schnel!).

 

[slaeshjag]

SD-slot takes more space than NAND, since it shares chip with RAM, and the RAM/NAND-chip is mounted on top of the CPU. Any other design would probably not fit on the pandora's PCB

 

[Foxgod]

SD-slot takes more space than NAND, since it shares chip with RAM, and the RAM/NAND-chip is mounted on top of the CPU. Any other design would probably not fit on the pandora's PCB

In Mobile phones micro sd slots are often mounted on top or below something else as well.


So thats possible, it wont be to intend to make the pandora smaller, but to make it thinner.

 

[ShleeDragon]

They will get the best SOC available when they actually start looking. also, I doubt we need 8GB of memory regardless.