No.

_________________
Matt Sealey

Thanks. Me returns to waiting for your product. In the meantime, let's see if someone gets a CherryPal, and decides to write a review about it.
I've read lately that this company is out of funds... This world stinks, doesn't it.

It's not the world's fault, Cherrypal dug the hole they're in all on their own.

_________________
Matt Sealey

Exactly the answer I was expecting. I understood, sometime ago, that CherryPal somehow "stole" your product.
Who is this Max Seybold, and why does this name sound familiar to me?

He was the CEO Cherrypal. I'd never heard of him before Cherrypal.

_________________
Matt Sealey

It is a long story and it is not over yet. Basically, we developed a plan for a family of devices with MTC/THTF in 2007 (LOI and Forecast - by the way, MTC/THTF used this same forecast with Freescale). We worked a few months on this. The objective was to leverage all the software and community support created around the EFIKA. We developed a comprehensive agreement which was *also* signed by MTC/THTF. When the chip samples finally arrived in September 2007 (three months late), we began working with them diligently. The goal was to show something at CES 2008. Unfortunately, in about 45 days we knew that the chip was not going to be able to get the job done for the devices we had defined because of the lack of cache-coherency (the 5200B on the EFIKA supports cache-coherency). Freescale had not informed us of any changes. This was a shock to all of us. The 5121e is suited to many potential applications, but not a full-scale desktop machine or a fully functional mobile device. Significant software modifications would be required. When we brought this information forward MTC/THTF (and Freescale) they did not want to accept this information/proof. MTC/THTF decided to do it themselves and ignore the alternatives we proposed. MTC/THTF discarded our agreement; they had no intention to respect it. They said they had hundreds if not thousands of software engineers that could solve all the problems. This is when we decided to post the LOI and Forecast. It was at this time the LimePC was born (formally it was called MyMate or the EFIKA). MTC/THTF hired an EFIKA Projects developer selected by reviewing the information on this site and flew him to China. For a time, he led the team. They worked feverishly, but ended up at CES with handheld devices that did not work. The desktop and television demo systems worked, but were actually not using the chip at all. They used standard PCs hidden under the booth. These false systems are what MTC/THTF used to sell CherryPal on the concept, which then CherryPal used to raise some initial money and create a website full of misrepresentation about the chip and the devices that can be built using it.

More later...

_________________
http://bbrv.blogspot.com

What a nice read! I'm not saying that business failures are nice, only the fact of being able to read this.
Yes, I remember this story. It would require a very big software effort to overcome.
This is when you realize that direct contact with the engineers is unvaluable. While freescale, as a company, couldn't care less about this detail, engineers would have warned you immediately.
Indeed. It has the same e300 core as the 5200, the drop of cache coherency is quite a surprise. Until you realize that this is a multicore chip (e300 + PowerVR + AXE), which perhaps makes cache coherency so complicated that it had to be dropped.
But it comes close, I think. And, most of all, as someone said in this forum before, it's the only sensible priced CPU from freescale, so perhaps the first one in the list if you insist in having them as CPU provider in your products.
It was then when you felt the urge to... whatever.
Sure, they are the big boys here, that's the usual attitude. Still, as of today, no product from them can be seen. And they keep that ugly web site.
Again, big boys attitude.
And that's "do it ourselves"? Can we know the name of that fellow developer?
Horror! But we all saw those videos with the handheld variations "working". Or, at least, things moved in their screens...
There goes Matt's phrase about CherryPal digging their own hole. I keep on searching for proof of a CherryPal getting to the hands of the customer, but this could also be a complete failure. Perhaps the next news from them is removing the web site and dissapear... I hope not, but after reading this, it could happen easily.
Gimme gimme... Again, thankyou very much for sharing this story with us.

China is a dangerous place for busines...

It's not complicated. The MPC5121e uses the same bus model as the MPC834x and MPC837x chips (a so called "Coherent System Bus" designed for that chip line, check out the reference manual, Chapter 10, and compare the MPC8379e book chapter 6). This was certainly a "shock", too. It's difficult to imagine how you can get from a working IP core to having features removed like that.

For certain applications cache coherency can be a chore; it actually takes time and bandwidth off your bus to implement cache coherency protocols. When you have multiple cores (be that two CPUs or a CPU, graphics chip and DSP processor) it gets a lot worse. If you have full control over the traffic from one component to another than you can hit a higher peak bandwidth without interruption or having the processor hold while it updates cache lines.

However this is usually only a valid assessment in contrived test benchmarks where the only thing running is your benchmark - running an OS like Linux, this is completely false.

What is demonstrably true is that cache coherency requires a lot less software management - it's maintained for you. This nearly always produces better performance since the coherency protocols are usually more efficient than marking swathes of memory as uncacheable, or manually flushing cache lines before and after transfers.
Freescale have many affordable CPUs if you buy them in quantities of more than a handful.
:D

The only good thing about it is that it proves the worth of Power Developer Projects. If you do good work and blog a lot, you might get hired by a partner :D
The handheld wasn't a "fake" device but it wasn't using the MPC5121e to our knowledge (at the time they showed it, that would have been impossible)

_________________
Matt Sealey

Thankyou for these explanations about cache coherency, lesson learnt. Again, top notch discussion here!
Perhaps the only positive thing in this uglly story. You can feel proud about what't going on here. Quantity is scarce, but quality excels.
So I just have to check for the project blog with more entries, and there's the guy who flew to China, only to slam his head against a wall...
Ugh! And people peeked under the table where the Lorraine prototype was been demonstrated.
I guess I'll keep on hunting for videos and reviews about the CherryPal.

You might think I'm a bit obsessed by this very product (I sometimes think that too), but it's the only computer based in the MPC5121e, aside from a couple of development boards.
Perhaps you are a bit tired about this story, but I have high hopes for this CPU, even more when you stated here that you have not abandoned your project around it.

@jcmarcos

We seriously doubt the 5121e CherryPal or LimePC will ever see any serious commercial success or even ship more than a few hundred units if even that many. MTC/THTF tried to get everybody involved to do everything for nothing. In fact, that is what they really have today: nothing. CherryPal is in the same boat. CherryPal's investors bailed because neither CherryPal or MTC/THTF could deliver on all the promises they made. Fortunately for us we know the chip very well and the customized software we developed for the MBX and AXE works in many embedded environments.

We will post more later, but we will inform you that the division inside Freescale that managed this chip was let go yesterday when Freescale reduced its headcount 10%. The Infotainment, Multimedia and Telematics Division is no more. The future as far as Freescale is *corporately* concerned for consumer devices is with i.Mx. The focus for the 5121e will be medical, industrial, home automation, etc. Of course, GM's OnStar uses the 5200B so the objective is that the 5121e will move into this role. We will be fine supporting these uses for the chip and have good customers still pushing ahead.

R&B :)

_________________
http://bbrv.blogspot.com

Plus I still think the 5121 may make a nice little ultro low wattage MorphOS box (sorry for repeating this MorphOS mantra again and again ;-), but I *believe* MorphOS still can have chance, a pretty small chance indeed). Thus, I am still very interested in that chip. Maintaining cache coherency with MorphOS shouldn't be much of a big issue if I understand that right.
The Efika 5200B demonstrated that MorphOS on a 400MHz 603/e300 cpu is not too slow for simple usage. But the 5200 has its limitations (ide bus, usb1.1; needs additional gfx card, needs some expensive parts (atx psu, custom case)).

Not quite. I assume they liked the sound of his project and his past work, but they skimmed Projects looking for him first.

Hey maybe he'll speak up here but I really doubt he wants to be publically embarrassed like that.
I don't think people are cynical enough these days :D
Yes.

Ulrich, wouldn't you rather have a 600MHz MPC8610 if you're insisting on a low clock speed? The best feature of the MPC5121e is in there - integrated graphics. It's not accelerated but then you do have AltiVec in the chip to help out with compositing. With PCI Express you can add a better graphics card, serial ATA, USB 2.0, firewire, gigabit ethernet, SpursEngine :D and all the things you really want out of a board (either as a southbridge, the AMD SB750 is looking pretty darn awesome, still - or discrete chips for a subset of those features) and still be looking at a lower part count than, say, an Intel Atom system and arguably better performance.

_________________
Matt Sealey

I am not exactly insisting on a low clock speed, but rather on low cost and low wattage. If a 600 MHz 8610 comes close in terms of price and energy consumption - brilliant! I may not know the final retail prices of those chips, but rely on figures I obtain from spoerle et al. - and there the price of a low clocked (667MHz) 8610 is about three times as high as the price of a 5121. Plus,the 8610 needs more additional ICs (IIRC Southbridge, NIC), where the 5121 is almost complete. Hence my estimation, that a *real low cost* design is more feasible with a 5121 than with a 8610 - which obviously is another performance league.
Anyway, I am all for it either way.

I'm developing an automotive infotainment and I was interested to use the MPC5121e.
Why I've choosed this SoC?
-Opengl ES.
-A lot of peripherals included in the chip. (ethernet too!)
-2 CANBUS ports (automotive device!).
-BSP Linux from freescale (I was happy to know they are pretty active trying to contribute and support this chip in the mainline kernel).
-1mm pitch Ball, this means PCB and assembly with low cost.

Before read this post I was wondering why the Cherrypal or the LimePC didn't come out. I was interested to use one as a development platform. Now I'm scared to use this chip.

I did some googling about "cache coherency" and I highly recomment this paper:
http://people.redhat.com/drepper/cpumemory.pdf

And found this too:
John Rigby wrote:
"Unlike other SOCs with e300 cores the 5121 is not cache coherent. The problem is an internal bridge that the processor can not snoop across"
John Rigby works at Freescale and he's in charge to support the chip in linux.

The BSP available at Freescale support the 2.6.25 kernel, you have a nice build system called LTIB (I have used this before with IMX31 SoC), you have closed drivers for OpenglES and I suppost some codecs for the audio accelerator.

If this BSP works, plus some GUI stack like QT, I have everthing I need. Sure I'm missing something but I don't know where is the problem with the cache coherency.

"The 5121e is suited to many potential applications, but not a full-scale desktop machine or a fully functional mobile device"
Why this? the performance penalty to implement the cache coherency is so high?

Could someone anticipate me which problem I will have with my application?

Yep we know him :)

The bus inside the chip is based on AMBA which is an embedded ARM IP - SATA and a couple other things go through here - it's not cache coherent, but it's certainly possible to trace bus transfers across it and add coherency to any peripherals here, just like any bus.

That's a matter of a dedicated coherency unit that all the bus transfers go through. On some ARM designs they call this the "Snoop Control Unit" - AMBA, AHB and AXI are all practically the same thing.

There are a couple of IEEE articles (like this one) and even a patent describing techniques to do so, and these are not the ONLY ways to do it :)
Because desktop applications require interoperation between multiple components on the chip, and the added complexity in the software to deal with lack of coherency cuts away a significant amount of performance. It is not unusable as a result, but you have to consider this is a 3-core chip, so doing any work on 3D using AXE to offload some calculation and coordination with the CPU requires a lot more work to do reliably and with good performance.

Every snippet of code that AXE works on has to be managed by the cache-management software. If the VGP in the PowerVR core gives back result data, it has to be into uncached or software-managed memory locations. DMA from every device needs to be explicitly cache-managed (with small amounts of data - a handful of cache lines or so - you may completely negate the benefit of using DMA at all by stalling the processor doing a cache invalidate)

The extra work means, that some things which run now and the chip might struggle to keep up, could run with some power to spare.

The chip had and still has a lot of promise. We have software demos written in house which demonstrate the potential of using these units in coordination (for instance video decoding with color conversion)
You shouldn't have any problems as long as you're not looking at running video apps on KDE :)

_________________
Matt Sealey