SoC: Back and forth!

[Linux-SWAT]

There's tons of x86 vs arm threads, please don't pollute this one too.

 

[Granitehead]

Where is this debate? (So I could go check whether there were any good arguments against going x86)

 Was it this one?

http://boards.openpandora.org/topic/14346-what-would-the-world-and-his-dog-think-if-p2-used-an-x86-soc-but-not-mini-sd/

At least you have 10 pages to read through.

May look at it.Also sorry, I didn't see that post of gta04 before mine (which contains lots of interesting info) and I actually searched for "x86" in thread titles, but nothing showed up.

 

[TrashyMG]

lso sorry, I didn't see that post of gta04 before mine (which contains lots of interesting info) and I actually searched for "x86" in thread titles, but nothing showed up.

^ the forums doesn't return any search results if you search with three characters or less.

 

[Granitehead]

lso sorry, I didn't see that post of gta04 before mine (which contains lots of interesting info) and I actually searched for "x86" in thread titles, but nothing showed up.

^ the forums doesn't return any search results if you search with three characters or less.

Should have known. There is a reason I tend to hate forum search functions.

 

[Fzero]

lso sorry, I didn't see that post of gta04 before mine (which contains lots of interesting info) and I actually searched for "x86" in thread titles, but nothing showed up.

^ the forums doesn't return any search results if you search with three characters or less.

Should have known. There is a reason I tend to hate forum search functions.

Yes, not sure if this is something ED can resolve, think just at the mercy of IPBoards to fix this.

Remember there is a workaround, using the asterisk character as a wildcard, which would help in some cases, like:

x86*

Also taking it to Google, this was mentioned a couple year back, here

http://boards.openpandora.org/topic/10846-search-in-this-forums-seems-to-ignore-3-character-words/#entry201647

 

[EvilDragon]

OMAP does not need big.LITTLE. TI has it's own technology to save power. That's why the Pandora is so power efficient.

Which is what exactly? TI is implementing ARM's Cortex-A15 core on their SoC (unlike some other manufacturers who design their own ARMv7 CPU cores), so basically the only thing having a major influence on the CPU core's power consumption is the manufacturing process. They might implement power saving features (and they most likely are) for other components of the SoC, but that does not influence the power consumption of the CPU cores. If they would have changed the actual CPU cores (for which they need a special ARM license), those would no longer be A15's anymore.

Yes TI has their own power saving functions and two M4 cores for that.

However, big.LITTLE doesn't save anything when using the A15 as well, only when NOT using it.

So there's not that much different.

 

[wej]

Yes TI has their own power saving functions and two M4 cores for that.

Cortex M4 cores are small microcontroller cores without a MMU and a limited feature set, so they can't be used as general purpose CPUs by the operating system. The M4 cores can only be used for very special tasks.

However, big.LITTLE doesn't save anything when using the A15 as well, only when NOT using it. So there's not that much different.

That is exactly the point of big.LITTLE. So there actually is quite a difference. If there is not a high demand for processing power, the lower-power A7 cores do all the computing. Only if there is much processing power needed the A15 cores will be used. This is only possible because the A15 and A7 cores share the exact same instruction set (unlike the A15 vs. M4).

 

[Grench]

The z3770 has open source drivers.  It is supported  in the Linux kernel.  It meets 100% of the other requirements for an SoC for this system, but it is X86 not ARM.

 It is even available though Mouser in single unit quantities at around 40 EUR. They even have 100 in stock. But no data sheets I.e. we can't even check if and how we can connect anything.

What makes me nervous is that it is said to be a "FCBGA1380" in a 17x17mm package (OMAP5 is 17x17 mm PBGA754). This means it may need a more expensive pcb technology to be connected. And if I interpret some rough diagram correctly, it has only one eMMC and one SD card interface. This makes interfacing two SD slots plus internal eMMC more difficult (could go through USB and an extra chip) and WiFi as well. So the total system complexity must be taken into account.

But it is quite useless to buy chips without getting public documentation. For the OMAP5 there are 6000 pages of technical reference manual available.

At the moment it looks to be the first time that we have a small chance to get an up-to-date SoC with x86 architecture (it was impossible for the last 10 years). But if this is the right train to board is a different question.

Data sheet is linked to from the Intel product page:

http://ark.intel.com/products/76760/Intel-Atom-Processor-Z3770-2M-Cache-up-to-2_39-GHz

Right hand column. "Download Datasheet" It's not like they hid it.

I have no basis to argue whether the PCB technology is more or less expensive.

eMMC and SD interface overview is in section 1.2.11 of the datasheet.

Supports one SDIO 3.0 controller

Supports one eMMC 4.51 controller

Supports one SDXC controller

Personally I'd put the WiFi on a USB 2.0 port so that it's easier to swap out in the process if the WiFi chip chosed goes EOL. Isn't that easier and would have faster data?

Per page 21 of the datasheet, the Z3770 has One USB 3.0 OTG port and an internal hub with 4 USB 1.1 to 2.0 ports.

Anyway, the documentation doesn't get any more 'public' than posted in the open on the product page. There are 291 pages on V1 (overview) and there is a 23MB V2 as well - I'm pretty sure you'll find anything you need there IF the project is serious about considering this option.

I agree that it is possible that the Z3770 may not the right SoC for this project. However, Intel has seemingly pulled a huge rabit out of it's hat and seemingly created exactly what our specs call for.

It's fast, efficient, available, has open source drivers and is relatively innexpensive.

It may not be for us, but wow - we should at least consider it.

Of course there is something attractive to me about having a 64bit X86 Debian handheld running Half Life and Neverwinter Nights. So I'm biased.

Before someone piles on the 'We've been through this! It's Done! You're an idiot for bringing it up!'

I was directly addressed from the system designer with their concerns - and misconceptions surrounding this chip that they apparently had -not- considered. This reply is to allow them the option, if they choose to explore it, to see the information that was claimed to not exist.

 

[God Ginrai]

Before someone piles on the 'We've been through this! It's Done! You're an idiot for bringing it up!'

I was directly addressed from the system designer with their concerns - and misconceptions surrounding this chip that they apparently had -not- considered. This reply is to allow them the option, if they choose to explore it, to see the information that was claimed to not exist.

That only gives you a reason for this post, not for the 3 or so you've made in this topic before this where you kept harping about a subject already past.

-God Ginrai

 

[Hồng Thất Công]

 

[EvilDragon]

Anyway, the documentation doesn't get any more 'public' than posted in the open on the product page. There are 291 pages on V1 (overview) and there is a 23MB V2 as well - I'm pretty sure you'll find anything you need there IF the project is serious about considering this option.

That doesn't sound like it's a complete datasheet for designing a PCB - the OMAP5 is 6000 pages...

 

[Linux-SWAT]

Ban the x86 tool for some time please.

 

[wej]

That doesn't sound like it's a complete datasheet for designing a PCB - the OMAP5 is 6000 pages...

The datasheets for that Intel SoC are more than 4000 pages long. Looks pretty much complete to me. You have to check both part 1 and 2.

 

[vcoleiro1]

You know in 6 months time there will be another thread comparing the OMAP5 to the Tegra K1 and Snapdragon XX etc - of course it will be way to late. But you know it will happen 

 

[EvilDragon]

That doesn't sound like it's a complete datasheet for designing a PCB - the OMAP5 is 6000 pages...

The datasheets for that Intel SoC are more than 4000 pages long. Looks pretty much complete to me. You have to check both part 1 and 2.

Ah, okay. Didn't read it, just saw the 200 pages mentioned above

 

[Hồng Thất Công]

6000-page is better than 4000-page   Just kidding

 

[Wrath Of Khan]

That doesn't sound like it's a complete datasheet for designing a PCB - the OMAP5 is 6000 pages...

The datasheets for that Intel SoC are more than 4000 pages long. Looks pretty much complete to me. You have to check both part 1 and 2.

So another possible soc?

 

[Hồng Thất Công]

Oh boy! It's gonna take another 2-MonthsTM for PYRA to come out!

 

[rohezal]

My main question is: if the Pyra is based on debian arm hf, will it be compatible with the old pnds (which are compiled with hardsoftfloat)? If not will there be some kind of compatiblity layer? Or must the source be recompiled? If it must be recompiled, I don't see the disadvantadge (except neon / assembler optimizations) of a x86 soc.

 

[TrashyMG]

^If soft-float libraries are included then it's possible to have a compatibility layer.

I stated my reasons before, but If an X86 SoC is chosen, I don't plan on getting a Pyra.