Our New Machine, Pandora

[Squidge]

Now that we have a price point for the i.MX31 and some comparisons to the MMSP2+, it'd be interesting to see a price point for the OMAP34x0 and a quick comparison with the i.MX31.

I think there's about a 0% chance of seeing one of the OMAP3 series in this console, so not much point of a comparison. They don't have distributors and want you to forecast your quantities in advance, which should be 30,000 minimum for your first order, and then at least 10 - 20 thousand after that. Probably going for the mobile phone market more than anything.

 

[cappuchok]

Now that we have a price point for the i.MX31 and some comparisons to the MMSP2+, it'd be interesting to see a price point for the OMAP34x0 and a quick comparison with the i.MX31.

I think there's about a 0% chance of seeing one of the OMAP3 series in this console, so not much point of a comparison. They don't have distributors and want you to forecast your quantities in advance, which should be 30,000 minimum for your first order, and then at least 10 - 20 thousand after that. Probably going for the mobile phone market more than anything.

Too bad, it looks like a positively awesome chip but those terms must be certain dealbreakers for the manufacturer of this thing. Oh well, the i.MX31 should be the next best choice, then, especially at the price you quoted.

And about TV-out, I just noticed something nice in the i.MX31 docs (application notes) - the TV encoder isn't actually integrated on the chip, so you could use any suitable encoder. They just happen to recommend the CH7024 and provide docs for how to interface between the two chips. That means with the i.MX31, RGB output would still be a possible if a suitable encoder can be found, while with the MMSP2+ which has an integrated TV encoder, so if it doesn't do RGB (and it doesn't according to the docs) S-video or possibly YCbCr (it is listed) is the best we could get. I'm leaning more and more towards the i.MX31 here... :blink:

 

[Tobriand]

And about TV-out, I just noticed something nice in the i.MX31 docs (application notes) - the TV encoder isn't actually integrated on the chip, so you could use any suitable encoder. They just happen to recommend the CH7024 and provide docs for how to interface between the two chips. That means with the i.MX31, RGB output would still be a possible if a suitable encoder can be found, while with the MMSP2+ which has an integrated TV encoder, so if it doesn't do RGB (and it doesn't according to the docs) S-video or possibly YCbCr (it is listed) is the best we could get. I'm leaning more and more towards the i.MX31 here... :blink:

I think we all are, on the assumption that some test applications don't actually end up running a lot faster on the MMSP2+ (which I can't see them doing), and also, on the similar assumption that the MMSP2+ doesn't reliably overclock to 650MHz compared to 0-overclock potential for the MX31 (which I think is incredibly unlikely without some sort of liquid nitrogen cooling system).

Do bear in mind, though, that an external TV-out chip is just one more component we'd have to pay for in due course (although I'd be quite happy to, I must say).

 

[cappuchok]

Do bear in mind, though, that an external TV-out chip is just one more component we'd have to pay for in due course (although I'd be quite happy to, I must say).

Totally. If it'll give me RGB over SCART from the device (and possibly also VGA), I don't mind paying a bit extra.

 

[sam fisher]

And about TV-out, I just noticed something nice in the i.MX31 docs (application notes) - the TV encoder isn't actually integrated on the chip, so you could use any suitable encoder. They just happen to recommend the CH7024 and provide docs for how to interface between the two chips. That means with the i.MX31, RGB output would still be a possible if a suitable encoder can be found, while with the MMSP2+ which has an integrated TV encoder, so if it doesn't do RGB (and it doesn't according to the docs) S-video or possibly YCbCr (it is listed) is the best we could get. I'm leaning more and more towards the i.MX31 here... :blink:

I think we all are, on the assumption that some test applications don't actually end up running a lot faster on the MMSP2+ (which I can't see them doing), and also, on the similar assumption that the MMSP2+ doesn't reliably overclock to 650MHz compared to 0-overclock potential for the MX31 (which I think is incredibly unlikely without some sort of liquid nitrogen cooling system).

Do bear in mind, though, that an external TV-out chip is just one more component we'd have to pay for in due course (although I'd be quite happy to, I must say).

The i.MX31 will generate LESS heat than the MMSP2+ and heat is not really a factor with ARM cores. It's also an ARM V11 which vs an ARM V9 in the MMSP2+ so will perform better at the same clockrate and likely draw less current. The i.MX31 generally seems to beat the MMSP2+ hands down in EVERY area.

 

[Squidge]

Also, the MX31 has 32KB of ROM and 16KB of RAM which are internal to the processor. Ideal for a bootstrap just in case you manage to toast your nand from a firmware upgrade - should be able to rescue from an sd card (I can easily get sd hardware access and a complete file system in well under 32KB), so no need for jtag. Yay!

Oh, and don't forget that at first glance, it seems that the memory system is twice the speed of the MMSP2+ and has 160KB of cache, compared to 32KB.

 

[sam fisher]

I doubt we will get such a brilliant SoC though

 

[Squidge]

Only time will tell!

 

[sam fisher]

Only time will tell!

Well it was implied from your previous posts in the other topic that you had a development board and that it was running Squidgesnes. Can you tell us what SoC this development board is based on? I assumed it was the MMSP2+.

 

[icurafu]

And about TV-out, I just noticed something nice in the i.MX31 docs (application notes) - the TV encoder isn't actually integrated on the chip, so you could use any suitable encoder. They just happen to recommend the CH7024 and provide docs for how to interface between the two chips. That means with the i.MX31, RGB output would still be a possible if a suitable encoder can be found, while with the MMSP2+ which has an integrated TV encoder, so if it doesn't do RGB (and it doesn't according to the docs) S-video or possibly YCbCr (it is listed) is the best we could get. I'm leaning more and more towards the i.MX31 here... :blink:

I think we all are, on the assumption that some test applications don't actually end up running a lot faster on the MMSP2+ (which I can't see them doing), and also, on the similar assumption that the MMSP2+ doesn't reliably overclock to 650MHz compared to 0-overclock potential for the MX31 (which I think is incredibly unlikely without some sort of liquid nitrogen cooling system).

Do bear in mind, though, that an external TV-out chip is just one more component we'd have to pay for in due course (although I'd be quite happy to, I must say).

The i.MX31 will generate LESS heat than the MMSP2+ and heat is not really a factor with ARM cores. It's also an ARM V11 which vs an ARM V9 in the MMSP2+ so will perform better at the same clockrate and likely draw less current. The i.MX31 generally seems to beat the MMSP2+ hands down in EVERY area.


Hmm. I always thought ARM11 was v6 and ARM9 was v4 and v5.

 

[cappuchok]

Also, the MX31 has 32KB of ROM and 16KB of RAM which are internal to the processor. Ideal for a bootstrap just in case you manage to toast your nand from a firmware upgrade - should be able to rescue from an sd card (I can easily get sd hardware access and a complete file system in well under 32KB), so no need for jtag. Yay!

Oh, and don't forget that at first glance, it seems that the memory system is twice the speed of the MMSP2+ and has 160KB of cache, compared to 32KB.

I doubt we will get such a brilliant SoC though

Only time will tell!

Well it was implied from your previous posts in the other topic that you had a development board and that it was running Squidgesnes. Can you tell us what SoC this development board is based on? I assumed it was the MMSP2+.


Quote from the earlier thread:

One thing that I really want this new thing to have is an easy way to reinstall the firmware/linux/whatever in case it's buggered up, without the need for something like a JTAG cable and special software.

Well, at the moment, the way to fix a buggered system is to insert an SD card whilst pressing another button, and it boots from the card instead of the internal OS. The OS is then reflashed to defaults.


Clue? :blink:

Or I could just be way off.

 

[A_SN]

And about TV-out, I just noticed something nice in the i.MX31 docs (application notes) - the TV encoder isn't actually integrated on the chip, so you could use any suitable encoder. They just happen to recommend the CH7024 and provide docs for how to interface between the two chips. That means with the i.MX31, RGB output would still be a possible if a suitable encoder can be found, while with the MMSP2+ which has an integrated TV encoder, so if it doesn't do RGB (and it doesn't according to the docs) S-video or possibly YCbCr (it is listed) is the best we could get. I'm leaning more and more towards the i.MX31 here... :blink:

I think we all are, on the assumption that some test applications don't actually end up running a lot faster on the MMSP2+ (which I can't see them doing), and also, on the similar assumption that the MMSP2+ doesn't reliably overclock to 650MHz compared to 0-overclock potential for the MX31 (which I think is incredibly unlikely without some sort of liquid nitrogen cooling system).

Do bear in mind, though, that an external TV-out chip is just one more component we'd have to pay for in due course (although I'd be quite happy to, I must say).

The i.MX31 will generate LESS heat than the MMSP2+ and heat is not really a factor with ARM cores. It's also an ARM V11 which vs an ARM V9 in the MMSP2+ so will perform better at the same clockrate and likely draw less current. The i.MX31 generally seems to beat the MMSP2+ hands down in EVERY area.


Well, sounds like a consensus on everybody not directly involved in the project in favour of the i.MX31.. If the MMSP2+ is chosen over it, Craig, you'd better prepare some solid arguments to help us swallow the pill.

 

[cappuchok]

Well, sounds like a consensus on everybody not directly involved in the project in favour of the i.MX31.. If the MMSP2+ is chosen over it, Craig, you'd better prepare some solid arguments to help us swallow the pill.

It would seem Squidge is also in favour of the i.MX31, and he seems to be involved to some degree...

 

[Squidge]

Well it was implied from your previous posts in the other topic that you had a development board and that it was running Squidgesnes. Can you tell us what SoC this development board is based on? I assumed it was the MMSP2+.

Correct.

Well, at the moment, the way to fix a buggered system is to insert an SD card whilst pressing another button, and it boots from the card instead of the internal OS. The OS is then reflashed to defaults.

Clue? :blink:

Or I could just be way off.


Both systems support the feature, but I think the MX31 version will be more robust. Why? Well, the MMSP2+ will have to boot from nand before being able to read an SD card, so will only work if the boot loader on the nand isn't corrupt (kinda like the existing gp2x functionality). However, on the MX31, everything to reflash the nand can be stored internally in the processor, so nand isn't required. It would also mean that you could boot directly from sd card and ignore nand completely (to boot alternative os's from sd for example)

However, like I said, the entire result is still upto Craig, as he's paying all the bills... (although I guess he'll be paying even more bills if he produces a device no one wants )

 

[craigix]

And about TV-out, I just noticed something nice in the i.MX31 docs (application notes) - the TV encoder isn't actually integrated on the chip, so you could use any suitable encoder. They just happen to recommend the CH7024 and provide docs for how to interface between the two chips. That means with the i.MX31, RGB output would still be a possible if a suitable encoder can be found, while with the MMSP2+ which has an integrated TV encoder, so if it doesn't do RGB (and it doesn't according to the docs) S-video or possibly YCbCr (it is listed) is the best we could get. I'm leaning more and more towards the i.MX31 here... :blink:

I think we all are, on the assumption that some test applications don't actually end up running a lot faster on the MMSP2+ (which I can't see them doing), and also, on the similar assumption that the MMSP2+ doesn't reliably overclock to 650MHz compared to 0-overclock potential for the MX31 (which I think is incredibly unlikely without some sort of liquid nitrogen cooling system).

Do bear in mind, though, that an external TV-out chip is just one more component we'd have to pay for in due course (although I'd be quite happy to, I must say).

The i.MX31 will generate LESS heat than the MMSP2+ and heat is not really a factor with ARM cores. It's also an ARM V11 which vs an ARM V9 in the MMSP2+ so will perform better at the same clockrate and likely draw less current. The i.MX31 generally seems to beat the MMSP2+ hands down in EVERY area.


Well, sounds like a consensus on everybody not directly involved in the project in favour of the i.MX31.. If the MMSP2+ is chosen over it, Craig, you'd better prepare some solid arguments to help us swallow the pill.


That's GPH you are thinking of!

 

[OrR]

Using a proven PDA distro instead of reinventing the wheel would make sense IMO.

True, but there is no OpenMoko or other like system pre-built for any of the chipsets we are investigating, which means we would have to port it. Since we have working Linux's already that would just be like wasting time (possibly months) unnecessarily.

What is there to do? If you've got the drivers ready on Linux, adding them to OpenMoko shouldn't be much work?

 

[Squidge]

What is there to do? If you've got the drivers ready on Linux, adding them to OpenMoko shouldn't be much work?

Are you volunteering for the job?

 

[Eolair]

Found this thing while googling the i.MX31:

Compal

Look, it has a slide keyboard. Think it's patented?

It looks a bit too much like my design <_<
But the stick is on the wrong side :rolleyes:

 

[X-Code]

Neat looking PDA design , I can't figure out why the stick is on that side... Single-handed control I guess?

That's what we need, but with game controls in the right places B)

Edit: Not too bad, 5 hours of battery life

 

[fusion_power]

somewhere I've read here, that this i.MX31 has over 500MHz and can run 10Hours battery time, is this right? and does this mean, if for example a music Player only needs 100MHz, we could have more than 20 Hours of Battery time?

Well, I hope, the most programms can run underclocked at such an fast CPU to save battery time and for lazy people it would be great, if an application could choose the clockrate itself which it needs, if this is possible at all - to controll this, I'm still for an Clockrate display on the Handheld so we always know the current clock rate. ^^
Yes, I'll take care of the batteries/Accus to.