> the slow, slow, slow IDE interface

...can be cured :-)

http://lists.ozlabs.org/pipermail/linuxppc-dev/2008-November/065048.html
http://lists.ozlabs.org/pipermail/linuxppc-dev/2008-December/066418.html

Edit: changed URL and added another

Quote:

Moved to MorphOS 2.2 wish list.

Quote:

We actually want the PowerVR core For the dreamcast emulator of course..

Quote:

Me too! But I guess that having it on the chip doesn't mean you can use it. Amazing as it might sound, BBRV have said that the documentation for the PowerVR core is propietary. It happens with many hardware devices, and it's very usual in graphics technoilogy.
This, and more juicy details are in PowerDeveloper. Please read, it's becoming the place with most information about the MPC5121e.

> There's a certain MPC5123 chip (for which Genesi announced a developer program)

...and for which Genesi is (was?) supposed to deliver the official reference design (like STx did for the MPC5121e).

http://www.genesi-usa.com/press/2008/4/14/

Quote:

It does.

The chip is broken in more ways than one. The reference designs from STx and GDA and the LimePC efforts (which are one or the other tweaked reference designs) are all extremely badly designed.

There is not a single MPC5121e board on the planet that would reliably operate and give the user a coherent and comfortable environment to run an OS in. It would not be ethical to foist these designs onto an excitable community like this one, and if you add in the fact we've seen it happen before (AmigaOne with the busted Mai chip, based on a busted Mai reference design.. you may remember everything Genesi and bplan said about that chip and those boards came absolutely true despite assertions to the contrary from Eyetech and Amiga and Mai) this just makes it even more of a shitty move.

MorphOS can and should turn past it. There are several other choices for processors to run the OS on, most better performing and with more features than the MPC5121e. After a discussion this weekend with a MorphOS team member, actually the 5200B and 5121E are really not up to the task of running MorphOS anymore. There was a day... that day was sometime in 2005. You're looking at 3D-accelerated windowing system for which there can never be a driver for the 3D part. Where DMA access is a burden, not a saving grace.. and where your maximum resolution is a paultry 1024x768. As Andre said this doesn't go well with most peoples' 22" monitors (to be fair I only have 17" and 19" screens with a maximum resolution of 1280x1024 but that's still too high. That's a lie - the DIU can run at that resolution, but the chip is not powerful enough at all to do any reasonable graphics with that much screen to maintain..)

Cache coherency may not matter and in fact I am fairly sure because of the way MorphOS is architected and based on the AmigaOS API, there is a built-in, 20 year old system for managing non-coherent DMA and peripherals (remember the m68k was not cache coherent) but in the end, why in Gaia's name would you bother?

[ Edited by Neko on 2008/11/20 21:20 ]

Quote:

And Linux, which is older, does require cache coherency? Or is it the way current Linux drivers are coded?

Quote:

With all the bits of information you've posted lately, I also have to agree. There has to be better hardware for MorphOS. The MPC512x looked good on paper, that's all.
What puzzless me is, why did freescale develop such a bad chip? Or is it that everyone in the world uses it wrong?

Roll on MPC8610!

IMO we don't need another underpowered crap that will end up in the dumpster. Green computing to pollute the world ;)

Mac mini is the true green computing as it gets recycled and still has plenty of time left in it. But the future shouldn't lie in underpowered machines. Yes they are fun toys, but you can hardly browse the net efficiently with Efika etc.

|||

[ Edited by Velcro_SP on 2011/3/20 6:53 ]

Yes I do agree with you that future should be about more efficient devices, but Efika uhhh ohh... Atleast slam more ram in there etc. Mini laptops nowadays are very capable desktop machines and they are all build to be efficient. So is Asus Eee Top all-in-one displays etc. Yet they pack way more horse power than Efika. Surely they consume a little more juice but not that much more and the trade off between usability and efficiensy in that matter is well worth it...

Sure you can not run MOS on x86 machine, but Efika will pretty much be forgotten once MOS is released for Mac mini and Mac mini is also a pretty efficient computer but also usable :). I just hope that future development on power efficient PPC hardware could be more towards desktop solutions than for custom solution (one use only). 128MBs of ram for Efika was a really bad choise and every one knows it. It really doesn't take much effort to get limited by the ram etc.

But hey if you can do all your daily computing on Efika then fine, but I can't and many others can't either. For a custom solution, be it browse one web site at a time etc. it is fine hardware but everything beyond that and multitasking on that machine is pretty useless. Cash register would be a fine solution for Efika also ;)

[ Edited by Painkiller on 2008/11/21 20:36 ]

Let me cross-quote myself here:

Quote:

[ Edited by Zylesea on 2008/11/21 17:13 ]

Quote:

It doesn't require it but it uses some fairly freakish techniques to manage it. Remember a lot of SoCs share IP cores between themselves so drivers that work on one chip also work with slight modifications on another. Adapting an existing solution to work without cache coherency messes up perfectly good drivers even in the best case, littering little snippets of cache management code where relevant.

At worst case the drivers don't perform well, and they have to be reworked so as to stress caches less, or manage data more effectively.

Or they need whole new API entries to deal with it.

The way Linux manages non-coherency of peripherals is to map out a section of memory to do DMA to (which is mapped not coherent so the CPU does not attempt to load it into the cache). The important thing to remember is that you can't really turn off the internal CPU cache, as small as it may be on the MPC5121e at 32 kilobytes, it would absolutely destroy CPU performance. And running code requires the instruction cache. So as long as the CPU is just running code and it is acting on data, the system is in fact cache coherent. You just can't interact with a peripheral in that coherent memory.

So, it marks this block of memory, say 32MB at some high location, to use as a bounce buffer. This way, you can do DMA in and out of this 32MB by allocating memory out of it, doing your transfer (which will not be stomped on by a cache flush), and then when you need the data, copying it out to another place which is accessed only by the CPU, so you get the benefit of the instruction and data caches.

You can also do DMA to other parts of memory by specifically flushing caches at certain points but this is more complicated by far especially with things like kernel preemption. It *is* a lot faster though.

Both techniques mean you can't run the same kernel on these two different chips - support for coherent or non-coherent systems is a compile time option. This sort of defeats the object of a lot of things and means basically no Linux distribution on the planet would touch the chip without significant investment or interest, as they would have to duplicate yet another kernel tree, maintain another set of configs, and ship new installers.

In the end the amount of work to get it done is really not worth the hassle when you can pick a chip with a working coherency model and have the magic work behind the scenes and use everything you already used.

> Cache coherency may not matter and in fact I am fairly sure because
> of the way MorphOS is architected and based on the AmigaOS API,
> there is a built-in, 20 year old system for managing non-coherent DMA
> and peripherals (remember the m68k was not cache coherent)

"the system doesn't have cache coherency, something which MorphOS requires."
http://www.amiga.org/forums/showpost.php?p=665328

I also stumbled over that post. I thought it was as Neko said. Pity if Piru is right - would rule out MorphOS on any 512x device.