• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            專注于服務器編程、網(wǎng)絡編程

            ~~保持一顆平常心~~持之以恒~~
            posts - 18, comments - 7, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

            mtk mmu

            Posted on 2009-12-18 22:18 ~William~ 閱讀(697) 評論(0)  編輯 收藏 引用 所屬分類: MTK_MMI
            MTK MMU
            2009-02-26 01:21

            MT6225由于采用的是ARM7-EJ內(nèi)核,所以Java可以速度很快,但其它方面就有限了:首先,如果要支持MMU就不太現(xiàn)實,好在Linux可以有uCLinux。其實早年,我們在Samsung S3C4510B上,執(zhí)行SNMP V3時,也就剛好,但如果執(zhí)行完整的MMU應用,加之MMS/WAP Browser,那是相當累的。準確來講,Linux+X不是為低端的ARM AP系統(tǒng)而設計。因此,iPhone才采用了S3C6400,而Apple Mini X是經(jīng)過優(yōu)化處理的,不然不可能有這么高的執(zhí)行效能。至于NOKIA的N810/910之類產(chǎn)品,其實啟動是比較慢的。

            其次,MTK本身定位從低端切入市場,不是說他真的能達到TI或是高通的水平,那是一件非常痛苦的事,這是MTK自身的傷痛,不能支持智能操作系統(tǒng)。而要支持通用智能操作系統(tǒng),主頻顯得相當重要,因為其上運行的軟件,很多需要較為復雜的計算,圖形繪制,都采用了高級的通用模式,而不僅僅是MTK GDI的2D 簡單平面繪制。真正的復雜度,是因為最初的設計風格和體系是不相符的。MTK的Layer操作,相當于Direct Draw,這其實是其它系統(tǒng)的極限速度,有一點像DMA,如果智能平臺的應用,并非專門為DMA而設計,那麻煩就大了,效能要差很多倍。

            我想更多人講的移置,是沒有去關心效能的,只是想辦法讓Linux在這個BB上運作一下,以MTK的128+32 MCP,要想啟動uClinux,并啟動MMI和多媒體,變成一個基本可用的系統(tǒng),基本上可以說是失敗的。運行Console Mode是可行的,外加一個Mini GUI。但大家都知道,一旦Mini化,那與現(xiàn)在的MTK MMI體系,又有什么差別,那不是我們想要的東西。非通用的GUI 核心,很難像X-Windows或是QT,或是Windows一樣流行起來。與其這樣支持MTK,還不如與其它國內(nèi)有實力做ARM9以上多核心協(xié)議棧的公司聯(lián)系,在他們的BB上,采用完整版的arm-linux(帶MMU),執(zhí)行android,或許還有真正的明天。聯(lián)想目前不正在做OPhone,基本上就是這一思路。現(xiàn)在在這一方面,國內(nèi)估計還是Moto當年的執(zhí)行者,采用QTE架構。能構優(yōu)化QTE的GDI 多層繪制核心,那就是一件非常有意義的事了,充分利用ARM提供的指令,將核心運算完全匯編化,并對算法優(yōu)化,可能會有意想不到的效果。至少,QT是完全可以商用化,并且是相當完整和成熟的。這種事情,完全可以由芯片原廠支持,這種結果,可能會讓Microsoft感到害怕,這正是他們的痛神經(jīng)。

            如果真要采用MTK,建議基點選在MT6235/MT6238要好一些,不過MTK在處理多媒體時,需要Linux充分使用其DSP效能,而通用Linux是無法啟用這些優(yōu)勢的,因此,移置還有一個漫長的過程。以前我們在XScale 27X上,執(zhí)行QTE也是比較慢的,從Moto的A1200就可以看出來,不過還可以接受,但還不是我們想要的結果。

            MTK要想充分啟用Linux優(yōu)勢,主頻是一個非常麻煩的事情,因為通用QT或是X-Windows,都需要更大內(nèi)存和更多的處理器能力,不然無法加載復雜的Office和Browser應用,否則開發(fā)出來的非通用系統(tǒng),比HTC早期的Windows Mobile產(chǎn)品更差勁。

            前幾天聽朋友說,他們打算在3G的雙協(xié)議棧上采用ARM-11 Core,如果主頻在400MHz左右,就可以很好處理復雜多媒體和文檔應用了。可能很多朋友還不知道,其實真正用軟件編碼MP4,是相當吃力的一件事,我們當時采用的533MHz的Strong ARM,效果都不是很理想。事實上,MTK的MP4編碼質(zhì)量,也只能說是忽悠低級用戶可以,早期的MT6226還帶有一個MP4 硬件編碼器。就是AMR-NB,純軟件都是一件輕松的事情,而MT6225是沒有MP4編碼器的。我們看看Nokia的OMAP架構,都是實在的DSP加速,所以貴一點,才是真正的貨真價實。

            客觀地講,低端的MTK IC,無論什么系統(tǒng),要用軟件實現(xiàn)完整的MP4,幾乎是不太現(xiàn)實。我沒有看完整的MT6239 SPEC(9系列是MTK體系中最高端的IC),是否有其它的硬件加速器,諸如DivX/RMVB/H.264,如果沒有ISP,200MHz實現(xiàn)H.264幾乎不太可能。而且,要達到全解碼,我估計MTK整合也不是一兩年時間就能搞定的。如果能在200MHz的主頻上,優(yōu)化GDI設計,采用8或9系列的ISP加速,說不定在Linux上,也可以實現(xiàn),甚至超越Windows Mobile的智能系統(tǒng)。

            有勇氣固然重要,但能執(zhí)行,能預知難度才更可貴。

            至于軟件優(yōu)化,可以參考Microsoft的資料,或是Intel的文檔,以前看過,有些東西,寫得真的很好。我們當時有采用Intel 的IPP軟件包。

            前一段聽一個兄弟說,他對數(shù)字IC如何如何的懂,如何如何的厲害,我笑了笑,那根本沒什么用,因為如果不做成一個系統(tǒng),做不了產(chǎn)品,無法商用,其實多半都是垃圾。沒有大規(guī)模測試,誰知道他芯片上還有多少BUG, 以前Freescale的AP不是都有不少問題嗎。現(xiàn)在好像國內(nèi)做這門生意的人越來越多了,不知道他們是否真的能賺錢,我只看到不少項目死在他們理想上了,他們燒錢倒是一流的。說到他們的痛處,他們就說他們的專家如何如何的NBXX,不屑于做那些低級工作;呵呵,我看也是,因為他們根本就做不了,因為如果那樣,比Windows高明的系統(tǒng)早就做出來了。

            客觀地講,MTK在封閉環(huán)境,已經(jīng)做到極限了,很多人還想超越,我真替他們擔心,也許我是眼界有限,但愿Linux MTK計劃取得成功。據(jù)我所知,目前MT6235都采用了NAND啟動了,其實1G+512M已經(jīng)是智能機的胃口了。而且,6235都非目前主流,成本較高,還不是“順產(chǎn)”。MTK以前宣稱低功,以他的頻率,也不至于高到什么程度,但我想,一旦你想跑智能平臺時,那結果可能是無法預測的。

            其實,MTK在2010年后,還有多少市場,誰也不知道;只是有一點,我還比較清醒,就是MTK 目前Cash多,搞不定,可以去買別人的。

            說實話,明天,我還真有一點茫然,智能移動網(wǎng)絡,已經(jīng)是無處不存了,那不是MTK的天堂,當然,也可能不是MTK的地獄,但可以肯定的是,Linux下的Android,一定是Apple、Microsoft、Nokia的頭號敵人。國內(nèi)的TD-SCDMA/WCDMA/CDMA2000三家運營商,一定會力挺Linux下的Open MMI或是Java平臺。

            2009-02-26 01:21

            MT6225由于采用的是ARM7-EJ內(nèi)核,所以Java可以速度很快,但其它方面就有限了:首先,如果要支持MMU就不太現(xiàn)實,好在Linux可以有uCLinux。其實早年,我們在Samsung S3C4510B上,執(zhí)行SNMP V3時,也就剛好,但如果執(zhí)行完整的MMU應用,加之MMS/WAP Browser,那是相當累的。準確來講,Linux+X不是為低端的ARM AP系統(tǒng)而設計。因此,iPhone才采用了S3C6400,而Apple Mini X是經(jīng)過優(yōu)化處理的,不然不可能有這么高的執(zhí)行效能。至于NOKIA的N810/910之類產(chǎn)品,其實啟動是比較慢的。

            其次,MTK本身定位從低端切入市場,不是說他真的能達到TI或是高通的水平,那是一件非常痛苦的事,這是MTK自身的傷痛,不能支持智能操作系統(tǒng)。而要支持通用智能操作系統(tǒng),主頻顯得相當重要,因為其上運行的軟件,很多需要較為復雜的計算,圖形繪制,都采用了高級的通用模式,而不僅僅是MTK GDI的2D 簡單平面繪制。真正的復雜度,是因為最初的設計風格和體系是不相符的。MTK的Layer操作,相當于Direct Draw,這其實是其它系統(tǒng)的極限速度,有一點像DMA,如果智能平臺的應用,并非專門為DMA而設計,那麻煩就大了,效能要差很多倍。

            我想更多人講的移置,是沒有去關心效能的,只是想辦法讓Linux在這個BB上運作一下,以MTK的128+32 MCP,要想啟動uClinux,并啟動MMI和多媒體,變成一個基本可用的系統(tǒng),基本上可以說是失敗的。運行Console Mode是可行的,外加一個Mini GUI。但大家都知道,一旦Mini化,那與現(xiàn)在的MTK MMI體系,又有什么差別,那不是我們想要的東西。非通用的GUI 核心,很難像X-Windows或是QT,或是Windows一樣流行起來。與其這樣支持MTK,還不如與其它國內(nèi)有實力做ARM9以上多核心協(xié)議棧的公司聯(lián)系,在他們的BB上,采用完整版的arm-linux(帶MMU),執(zhí)行android,或許還有真正的明天。聯(lián)想目前不正在做OPhone,基本上就是這一思路。現(xiàn)在在這一方面,國內(nèi)估計還是Moto當年的執(zhí)行者,采用QTE架構。能構優(yōu)化QTE的GDI 多層繪制核心,那就是一件非常有意義的事了,充分利用ARM提供的指令,將核心運算完全匯編化,并對算法優(yōu)化,可能會有意想不到的效果。至少,QT是完全可以商用化,并且是相當完整和成熟的。這種事情,完全可以由芯片原廠支持,這種結果,可能會讓Microsoft感到害怕,這正是他們的痛神經(jīng)。

            如果真要采用MTK,建議基點選在MT6235/MT6238要好一些,不過MTK在處理多媒體時,需要Linux充分使用其DSP效能,而通用Linux是無法啟用這些優(yōu)勢的,因此,移置還有一個漫長的過程。以前我們在XScale 27X上,執(zhí)行QTE也是比較慢的,從Moto的A1200就可以看出來,不過還可以接受,但還不是我們想要的結果。

            MTK要想充分啟用Linux優(yōu)勢,主頻是一個非常麻煩的事情,因為通用QT或是X-Windows,都需要更大內(nèi)存和更多的處理器能力,不然無法加載復雜的Office和Browser應用,否則開發(fā)出來的非通用系統(tǒng),比HTC早期的Windows Mobile產(chǎn)品更差勁。

            前幾天聽朋友說,他們打算在3G的雙協(xié)議棧上采用ARM-11 Core,如果主頻在400MHz左右,就可以很好處理復雜多媒體和文檔應用了。可能很多朋友還不知道,其實真正用軟件編碼MP4,是相當吃力的一件事,我們當時采用的533MHz的Strong ARM,效果都不是很理想。事實上,MTK的MP4編碼質(zhì)量,也只能說是忽悠低級用戶可以,早期的MT6226還帶有一個MP4 硬件編碼器。就是AMR-NB,純軟件都是一件輕松的事情,而MT6225是沒有MP4編碼器的。我們看看Nokia的OMAP架構,都是實在的DSP加速,所以貴一點,才是真正的貨真價實。

            客觀地講,低端的MTK IC,無論什么系統(tǒng),要用軟件實現(xiàn)完整的MP4,幾乎是不太現(xiàn)實。我沒有看完整的MT6239 SPEC(9系列是MTK體系中最高端的IC),是否有其它的硬件加速器,諸如DivX/RMVB/H.264,如果沒有ISP,200MHz實現(xiàn)H.264幾乎不太可能。而且,要達到全解碼,我估計MTK整合也不是一兩年時間就能搞定的。如果能在200MHz的主頻上,優(yōu)化GDI設計,采用8或9系列的ISP加速,說不定在Linux上,也可以實現(xiàn),甚至超越Windows Mobile的智能系統(tǒng)。

            有勇氣固然重要,但能執(zhí)行,能預知難度才更可貴。

            至于軟件優(yōu)化,可以參考Microsoft的資料,或是Intel的文檔,以前看過,有些東西,寫得真的很好。我們當時有采用Intel 的IPP軟件包。

            前一段聽一個兄弟說,他對數(shù)字IC如何如何的懂,如何如何的厲害,我笑了笑,那根本沒什么用,因為如果不做成一個系統(tǒng),做不了產(chǎn)品,無法商用,其實多半都是垃圾。沒有大規(guī)模測試,誰知道他芯片上還有多少BUG, 以前Freescale的AP不是都有不少問題嗎。現(xiàn)在好像國內(nèi)做這門生意的人越來越多了,不知道他們是否真的能賺錢,我只看到不少項目死在他們理想上了,他們燒錢倒是一流的。說到他們的痛處,他們就說他們的專家如何如何的NBXX,不屑于做那些低級工作;呵呵,我看也是,因為他們根本就做不了,因為如果那樣,比Windows高明的系統(tǒng)早就做出來了。

            客觀地講,MTK在封閉環(huán)境,已經(jīng)做到極限了,很多人還想超越,我真替他們擔心,也許我是眼界有限,但愿Linux MTK計劃取得成功。據(jù)我所知,目前MT6235都采用了NAND啟動了,其實1G+512M已經(jīng)是智能機的胃口了。而且,6235都非目前主流,成本較高,還不是“順產(chǎn)”。MTK以前宣稱低功,以他的頻率,也不至于高到什么程度,但我想,一旦你想跑智能平臺時,那結果可能是無法預測的。

            其實,MTK在2010年后,還有多少市場,誰也不知道;只是有一點,我還比較清醒,就是MTK 目前Cash多,搞不定,可以去買別人的。

            說實話,明天,我還真有一點茫然,智能移動網(wǎng)絡,已經(jīng)是無處不存了,那不是MTK的天堂,當然,也可能不是MTK的地獄,但可以肯定的是,Linux下的Android,一定是Apple、Microsoft、Nokia的頭號敵人。國內(nèi)的TD-SCDMA/WCDMA/CDMA2000三家運營商,一定會力挺Linux下的Open MMI或是Java平臺。

            久久综合九色综合欧美就去吻| 日日狠狠久久偷偷色综合免费| 久久青青草原亚洲av无码app| 无码日韩人妻精品久久蜜桃| 99久久精品日本一区二区免费| 久久高清一级毛片| 久久久久久综合网天天| 久久久国产精品网站| 亚洲乱码中文字幕久久孕妇黑人| 93精91精品国产综合久久香蕉| 久久精品免费一区二区| 久久精品国产亚洲一区二区三区| 亚洲香蕉网久久综合影视| 九九久久精品国产| 久久精品国产99久久无毒不卡| 综合久久精品色| 中文精品久久久久国产网址| 亚洲国产一成人久久精品| 久久涩综合| 九九久久精品无码专区| 中文精品久久久久国产网址| 久久99精品综合国产首页| 伊人久久综合精品无码AV专区| 色婷婷噜噜久久国产精品12p| 日本久久久久久中文字幕| 色欲久久久天天天综合网| 久久亚洲AV无码精品色午夜麻豆| 激情久久久久久久久久| 国产精品久久久久久久午夜片| 久久这里只有精品18| 久久国产劲爆AV内射—百度| 国产毛片欧美毛片久久久| 久久精品人人做人人爽电影| 亚洲欧美伊人久久综合一区二区| 久久久久久亚洲精品不卡 | 国产2021久久精品| 91久久精品无码一区二区毛片| 香蕉久久一区二区不卡无毒影院| 久久99国产精品久久久| 久久99精品国产麻豆不卡| 久久精品成人欧美大片|