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平台。

你可能感兴趣的:(mtk mmu)