mtk mmu

MTK MMU

2009-02-26 01:21

MT6225由于采用的是ARM7-EJ内核，所以Java可以速度很快，但其它方面就有限了：首先，如果要支持MMU就不太现实，好在Linux可以有uCLinux。其实早年，我们在Samsung S3C4510B上，执行SNMP V3时，也就刚好，但如果执行完整的MMU应用，加之MMS/WAP Browser，那是相当累的。准确来讲，Linux+X不是为低端的ARM AP系统而设计。因此，iPhone才采用了S3C6400，而Apple Mini X是经过优化处理的，不然不可能有这么高的执行效能。至于NOKIA的N810/910之类产品，其实启动是比较慢的。 其次，MTK本身定位从低端切入市场，不是说他真的能达到TI或是高通的水平，那是一件非常痛苦的事，这是MTK自身的伤痛，不能支持智能操作系统。而要支持通用智能操作系统，主频显得相当重要，因为其上运行的软件，很多需要较为复杂的计算，图形绘制，都采用了高级的通用模式，而不仅仅是MTK GDI的2D 简单平面绘制。真正的复杂度，是因为最初的设计风格和体系是不相符的。MTK的Layer操作，相当于Direct Draw，这其实是其它系统的极限速度，有一点像DMA，如果智能平台的应用，并非专门为DMA而设计，那麻烦就大了，效能要差很多倍。 我想更多人讲的移置，是没有去关心效能的，只是想办法让Linux在这个BB上运作一下，以MTK的128+32 MCP，要想启动uClinux，并启动MMI和多媒体，变成一个基本可用的系统，基本上可以说是失败的。运行Console Mode是可行的，外加一个Mini GUI。但大家都知道，一旦Mini化，那与现在的MTK MMI体系，又有什么差别，那不是我们想要的东西。非通用的GUI 核心，很难像X-Windows或是QT，或是Windows一样流行起来。与其这样支持MTK，还不如与其它国内有实力做ARM9以上多核心协议栈的公司联系，在他们的BB上，采用完整版的arm-linux(带MMU)，执行android，或许还有真正的明天。联想目前不正在做OPhone，基本上就是这一思路。现在在这一方面，国内估计还是Moto当年的执行者，采用QTE架构。能构优化QTE的GDI 多层绘制核心，那就是一件非常有意义的事了，充分利用ARM提供的指令，将核心运算完全汇编化，并对算法优化，可能会有意想不到的效果。至少，QT是完全可以商用化，并且是相当完整和成熟的。这种事情，完全可以由芯片原厂支持，这种结果，可能会让Microsoft感到害怕，这正是他们的痛神经。 如果真要采用MTK，建议基点选在MT6235/MT6238要好一些，不过MTK在处理多媒体时，需要Linux充分使用其DSP效能，而通用Linux是无法启用这些优势的，因此，移置还有一个漫长的过程。以前我们在XScale 27X上，执行QTE也是比较慢的，从Moto的A1200就可以看出来，不过还可以接受，但还不是我们想要的结果。 MTK要想充分启用Linux优势，主频是一个非常麻烦的事情，因为通用QT或是X-Windows，都需要更大内存和更多的处理器能力，不然无法加载复杂的Office和Browser应用，否则开发出来的非通用系统，比HTC早期的Windows Mobile产品更差劲。 前几天听朋友说，他们打算在3G的双协议栈上采用ARM-11 Core，如果主频在400MHz左右，就可以很好处理复杂多媒体和文档应用了。可能很多朋友还不知道，其实真正用软件编码MP4，是相当吃力的一件事，我们当时采用的533MHz的Strong ARM，效果都不是很理想。事实上，MTK的MP4编码质量，也只能说是忽悠低级用户可以，早期的MT6226还带有一个MP4 硬件编码器。就是AMR-NB，纯软件都是一件轻松的事情，而MT6225是没有MP4编码器的。我们看看Nokia的OMAP架构，都是实在的DSP加速，所以贵一点，才是真正的货真价实。 客观地讲，低端的MTK IC，无论什么系统，要用软件实现完整的MP4，几乎是不太现实。我没有看完整的MT6239 SPEC(9系列是MTK体系中最高端的IC)，是否有其它的硬件加速器，诸如DivX/RMVB/H.264，如果没有ISP，200MHz实现H.264几乎不太可能。而且，要达到全解码，我估计MTK整合也不是一两年时间就能搞定的。如果能在200MHz的主频上，优化GDI设计，采用8或9系列的ISP加速，说不定在Linux上，也可以实现，甚至超越Windows Mobile的智能系统。 有勇气固然重要，但能执行，能预知难度才更可贵。 至于软件优化，可以参考Microsoft的资料，或是Intel的文档，以前看过，有些东西，写得真的很好。我们当时有采用Intel 的IPP软件包。 前一段听一个兄弟说，他对数字IC如何如何的懂，如何如何的厉害，我笑了笑，那根本没什么用，因为如果不做成一个系统，做不了产品，无法商用，其实多半都是垃圾。没有大规模测试，谁知道他芯片上还有多少BUG， 以前Freescale的AP不是都有不少问题吗。现在好像国内做这门生意的人越来越多了，不知道他们是否真的能赚钱，我只看到不少项目死在他们理想上了，他们烧钱倒是一流的。说到他们的痛处，他们就说他们的专家如何如何的NBXX，不屑于做那些低级工作；呵呵，我看也是，因为他们根本就做不了，因为如果那样，比Windows高明的系统早就做出来了。 客观地讲，MTK在封闭环境，已经做到极限了，很多人还想超越，我真替他们担心，也许我是眼界有限，但愿Linux MTK计划取得成功。据我所知，目前MT6235都采用了NAND启动了，其实1G+512M已经是智能机的胃口了。而且，6235都非目前主流，成本较高，还不是“顺产”。MTK以前宣称低功，以他的频率，也不至于高到什么程度，但我想，一旦你想跑智能平台时，那结果可能是无法预测的。 其实，MTK在2010年后，还有多少市场，谁也不知道；只是有一点，我还比较清醒，就是MTK 目前Cash多，搞不定，可以去买别人的。 说实话，明天，我还真有一点茫然，智能移动网络，已经是无处不存了，那不是MTK的天堂，当然，也可能不是MTK的地狱，但可以肯定的是，Linux下的Android，一定是Apple、Microsoft、Nokia的头号敌人。国内的TD-SCDMA/WCDMA/CDMA2000三家运营商，一定会力挺Linux下的Open MMI或是Java平台。

2009-02-26 01:21

MT6225由于采用的是ARM7-EJ内核，所以Java可以速度很快，但其它方面就有限了：首先，如果要支持MMU就不太现实，好在Linux可以有uCLinux。其实早年，我们在Samsung S3C4510B上，执行SNMP V3时，也就刚好，但如果执行完整的MMU应用，加之MMS/WAP Browser，那是相当累的。准确来讲，Linux+X不是为低端的ARM AP系统而设计。因此，iPhone才采用了S3C6400，而Apple Mini X是经过优化处理的，不然不可能有这么高的执行效能。至于NOKIA的N810/910之类产品，其实启动是比较慢的。 其次，MTK本身定位从低端切入市场，不是说他真的能达到TI或是高通的水平，那是一件非常痛苦的事，这是MTK自身的伤痛，不能支持智能操作系统。而要支持通用智能操作系统，主频显得相当重要，因为其上运行的软件，很多需要较为复杂的计算，图形绘制，都采用了高级的通用模式，而不仅仅是MTK GDI的2D 简单平面绘制。真正的复杂度，是因为最初的设计风格和体系是不相符的。MTK的Layer操作，相当于Direct Draw，这其实是其它系统的极限速度，有一点像DMA，如果智能平台的应用，并非专门为DMA而设计，那麻烦就大了，效能要差很多倍。 我想更多人讲的移置，是没有去关心效能的，只是想办法让Linux在这个BB上运作一下，以MTK的128+32 MCP，要想启动uClinux，并启动MMI和多媒体，变成一个基本可用的系统，基本上可以说是失败的。运行Console Mode是可行的，外加一个Mini GUI。但大家都知道，一旦Mini化，那与现在的MTK MMI体系，又有什么差别，那不是我们想要的东西。非通用的GUI 核心，很难像X-Windows或是QT，或是Windows一样流行起来。与其这样支持MTK，还不如与其它国内有实力做ARM9以上多核心协议栈的公司联系，在他们的BB上，采用完整版的arm-linux(带MMU)，执行android，或许还有真正的明天。联想目前不正在做OPhone，基本上就是这一思路。现在在这一方面，国内估计还是Moto当年的执行者，采用QTE架构。能构优化QTE的GDI 多层绘制核心，那就是一件非常有意义的事了，充分利用ARM提供的指令，将核心运算完全汇编化，并对算法优化，可能会有意想不到的效果。至少，QT是完全可以商用化，并且是相当完整和成熟的。这种事情，完全可以由芯片原厂支持，这种结果，可能会让Microsoft感到害怕，这正是他们的痛神经。 如果真要采用MTK，建议基点选在MT6235/MT6238要好一些，不过MTK在处理多媒体时，需要Linux充分使用其DSP效能，而通用Linux是无法启用这些优势的，因此，移置还有一个漫长的过程。以前我们在XScale 27X上，执行QTE也是比较慢的，从Moto的A1200就可以看出来，不过还可以接受，但还不是我们想要的结果。 MTK要想充分启用Linux优势，主频是一个非常麻烦的事情，因为通用QT或是X-Windows，都需要更大内存和更多的处理器能力，不然无法加载复杂的Office和Browser应用，否则开发出来的非通用系统，比HTC早期的Windows Mobile产品更差劲。 前几天听朋友说，他们打算在3G的双协议栈上采用ARM-11 Core，如果主频在400MHz左右，就可以很好处理复杂多媒体和文档应用了。可能很多朋友还不知道，其实真正用软件编码MP4，是相当吃力的一件事，我们当时采用的533MHz的Strong ARM，效果都不是很理想。事实上，MTK的MP4编码质量，也只能说是忽悠低级用户可以，早期的MT6226还带有一个MP4 硬件编码器。就是AMR-NB，纯软件都是一件轻松的事情，而MT6225是没有MP4编码器的。我们看看Nokia的OMAP架构，都是实在的DSP加速，所以贵一点，才是真正的货真价实。 客观地讲，低端的MTK IC，无论什么系统，要用软件实现完整的MP4，几乎是不太现实。我没有看完整的MT6239 SPEC(9系列是MTK体系中最高端的IC)，是否有其它的硬件加速器，诸如DivX/RMVB/H.264，如果没有ISP，200MHz实现H.264几乎不太可能。而且，要达到全解码，我估计MTK整合也不是一两年时间就能搞定的。如果能在200MHz的主频上，优化GDI设计，采用8或9系列的ISP加速，说不定在Linux上，也可以实现，甚至超越Windows Mobile的智能系统。 有勇气固然重要，但能执行，能预知难度才更可贵。 至于软件优化，可以参考Microsoft的资料，或是Intel的文档，以前看过，有些东西，写得真的很好。我们当时有采用Intel 的IPP软件包。 前一段听一个兄弟说，他对数字IC如何如何的懂，如何如何的厉害，我笑了笑，那根本没什么用，因为如果不做成一个系统，做不了产品，无法商用，其实多半都是垃圾。没有大规模测试，谁知道他芯片上还有多少BUG， 以前Freescale的AP不是都有不少问题吗。现在好像国内做这门生意的人越来越多了，不知道他们是否真的能赚钱，我只看到不少项目死在他们理想上了，他们烧钱倒是一流的。说到他们的痛处，他们就说他们的专家如何如何的NBXX，不屑于做那些低级工作；呵呵，我看也是，因为他们根本就做不了，因为如果那样，比Windows高明的系统早就做出来了。 客观地讲，MTK在封闭环境，已经做到极限了，很多人还想超越，我真替他们担心，也许我是眼界有限，但愿Linux MTK计划取得成功。据我所知，目前MT6235都采用了NAND启动了，其实1G+512M已经是智能机的胃口了。而且，6235都非目前主流，成本较高，还不是“顺产”。MTK以前宣称低功，以他的频率，也不至于高到什么程度，但我想，一旦你想跑智能平台时，那结果可能是无法预测的。 其实，MTK在2010年后，还有多少市场，谁也不知道；只是有一点，我还比较清醒，就是MTK 目前Cash多，搞不定，可以去买别人的。 说实话，明天，我还真有一点茫然，智能移动网络，已经是无处不存了，那不是MTK的天堂，当然，也可能不是MTK的地狱，但可以肯定的是，Linux下的Android，一定是Apple、Microsoft、Nokia的头号敌人。国内的TD-SCDMA/WCDMA/CDMA2000三家运营商，一定会力挺Linux下的Open MMI或是Java平台。