2013年11月12日 星期二

Buffalo LS-QTL 全硬碟更換後,系統重灌步驟

起因:
因為硬碟使用3年多,系統常常出現硬碟錯誤訊息,所以就買了4顆2T的硬碟,將原本的1T * 4硬碟全部更換,結果沒想到竟然就不能正常工作....,寫信給Buffalo客服,回覆是:
===================================================
產品有保固服務,但只限定主機和原廠附的硬碟,所以您說明的情形,不在服務範圍內,請換原本4顆硬碟,後續做付費維修,就可以回復出廠預設值,就可以繼續使用.
===================================================

想想真是坑爹阿...,別家的NAS都可以為什麼Buffalo不可以,所以只好求救google大神(大神果然無所不能 ^___^),經過不斷的搜尋、嘗試之後,皇天不負苦心人,終於讓我的LS-QTL復活了。


準備工具:
1. TFTP Boot Recovery:
https://drive.google.com/folderview?id=0B_oFnRRMAwk0SkYtdGpSdTNKTk0&usp=sharing
2. 韌體:
http://www.buffalotech.com/support-and-downloads/downloads



參考文件:
1. FAQ (1 of 5): EM Mode boot procedures:讓設備進入緊急模式的方式。     
2. FAQ (3 of 5): TFTP boot procedure:如何使用TFTP來進入更新韌體。
3. FAQ (2 of 5): Force Firmware update procedure:如何設定更新韌體工具使用除錯模式
4. http://wenku.baidu.com/view/0d927c49e518964bcf847c71:綜合步驟


備註:
LS-QTL進入緊急模式的方式:
1. 開機前先按 function 鍵,等 function 燈號出現藍燈閃爍。
2. 按 power 鍵兩次,開啟電源。(不要問我,為什麼要兩次,因為我每次按第一次都不會開機)
3. 等 power 燈變成閃六次停一次的時候,同時按下 power & function,等到TFTP的視窗出現了後續的訊息後,就可以放開。
4. 搜尋設備,我是使用更新韌體程式搜尋,因為TFTP Boot Recovery目錄中所附的程式會出現找不到設備的問題。
5. 進入更新程式的除錯視窗設定,我是將"Rebuild partition table" & "Delete User-Config"都選取,然後確認,進行更新。
6. 等待復活。
7. 悲劇的是,重新做RAID時卻沒辦法將四顆硬碟作成RAID5....T_____T

更新:
8. 發現RAID5失敗的原因是:其他三顆硬碟沒有格式化....(無言),格式化後RAID5建立成功。

2013年8月19日 星期一

FIX: libmpfr.so.4: cannot open shared object file: No such file or directory

在ubuntu上使用toolchain產生zlib-1.2.5時發生了問題,在使用configure出現了:
======================================================
Checking for shared library support...
Tested arm-buildroot-linux-uclibcgnueabi-gcc -w -c -O ztest17184.c
/home/ken/WrkSrc/toolchain/buildroot-2012.11.1/output/host/usr/bin/../libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.4.0/cc1: error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory
Tested cc -shared -O -o ztest17184.so ztest17184.o
cc: error: ztest17184.o: No such file or directory
cc: fatal error: no input files
compilation terminated.
======================================================

可是當初在fedora 11上使用時卻沒有出現這樣的問題(
======================================================
Checking for shared library support...
Building shared library libz.so.1.2.5 with arm-buildroot-linux-uclibcgnueabi-gcc.
Checking for off64_t... Yes.
Checking for fseeko... Yes.
======================================================

所以上google搜尋,發現了以下的網頁
其中有類似的問題,然而解決的方式是:宣告 "LD_LIBRARY_PATH",所以嘗試 "LD_LIBRABY_PATH" 指向到 toolchain 的 lib 目錄後就可以正常 configure。


PS:
當以上步驟做完後,可以一起解決"lzp=2.04" configure遇到的問題。
cd lzo-2.04; CC=arm-buildroot-linux-uclibcgnueabi-gcc RANLIB=/home/ken/WrkSrc/toolchain/buildroot-2012.11.1/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-ranlib ./configure --host=arm-buildroot-linux-uclibcgnueabi --prefix=/home/ken/WrkSrc/toolchain/buildroot-2012.11.1/output/host/usr/arm-buildroot-linux-uclibcgnueabi/
configure: WARNING: if you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used
configure: Configuring LZO 2.04
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm-buildroot-linux-uclibcgnueabi
checking target system type... arm-buildroot-linux-uclibcgnueabi
checking whether to enable maintainer-specific portions of Makefiles... no
checking for arm-buildroot-linux-uclibcgnueabi-gcc... arm-buildroot-linux-uclibcgnueabi-gcc
checking whether the C compiler works... no
configure: error: in `/home/ken/WrkSrc/svn/grain/platform/faraday/toolchain_lib/lzo-2.04':
configure: error: C compiler cannot create executables
See `config.log' for more details
make: *** [prebuild] Error 77

2013年3月29日 星期五

GPLUS GN708W & PAPAGO! 安裝與地圖無法開啟問題解決

1. 自己google找安裝檔
2. 將708W 連接USB,開啟USB功能。PC端會出現相對應的"抽取式磁碟機"。(我有裝SD卡,所以出現了兩組)
3. 選擇自己想安裝的"磁碟",建立"Navi"目錄,將圖資檔複製到目錄下。
4. 安裝PAPAGO!


問題一:安裝完成後,時程式會出現不支援540x960或960x540解晰度。
=> 解決: 將圖資目錄中"Organic"目錄下的480x800與800x480,複製一份並改名稱為540x960與960x540。

問題二:當解決問題一後,再執行程式,程式會出現"無法開啟地圖檔"。
=> 解決:將圖資目錄中"Organic\950"目錄下的480x800與800x480,複製一份並改名稱為540x960與960x540。

PS:這樣修改雖然可以使用,但因為解析度的問題,所以會造成程式中功能圖示的位置有些偏移。

2013年2月7日 星期四

海康NVR 與 AM ONVIF 溝通過久的議題 (補2/5)

2/1
客戶反映他們使用NVR 連接AM系列產品時,需要花費15分鐘NVR才會出現影像。
=> 2/4 早上到客戶那實地測試。
2/4
到客戶端實地測試結果:
  • 問題一:
當NVR發出ONVIF指令溝通時,每道指令都要花費2~3秒的時間,且回傳的封包會被分割成數十段小封包(封包大小不一,有時還會出現長度為"0"的封包)。但是A-MTK的產品每道指令卻花費不到0.5秒的時間,且封包大小都是維持為"1448"。
方案:目前還找不出原因。
  • 問題二:
當NVR連線設備RTSP(UDP)影像後,當網路出現斷線後,設備端無法在短時間之內中斷。
方案:
1. 設定RTCP socket recv timeout => 沒用,因為雖然RTCP recv thread 結束,但卻不會更改RTSP相關狀態。
2. 在polling 的地方,當ETH0 狀態變更且為斷線時,重新啟動RTSP stream.
3. 另外,將RTSP session timeout 由60秒縮短為15杪。
  • 提供新板FW給客戶驗證。
客戶測試後,新增設備到影像出現,仍然需要一分10秒左右,客戶希望我們能直接現場解決,不然可能就會改單。
2/5
客戶端實測與比較A-MTK與我們設備的ONVIF 溝通的回傳值得差異。發現一些相異的地方。

  • 相同處:
A-MTK與我們的設備都有六個video profile

  • 相異處:
A-MTK: 在getProfiles 只回應一組,切換解析度是以setEncoderParamater來改變對應的profile。
AM系列:getProfiles回應六組profiles,切換解析度就是直接對應profile。缺點:NVR必須花費更多CMD來讀取個profile 的設定值。

  • 初步改善方案: 

在getProfiles CMD只回復第一組profile 以爭取最少的CMD 數完成ONVIF 的溝通。修改後,NVR與設備溝通時間明顯縮短,由原先一分多縮短為20~25秒。
客戶初步能夠接受,但還是希望我們能再縮短時間,希望能夠縮短到10~15杪。
 
 
 


2013年2月6日 星期三

build uClibc toolchains using Buildroot for GM812x (續一) (補2/4)

參考來源:



  • http://communities.mentor.com/community/cs/archives/arm-gnu/msg01673.html
  • http://communities.mentor.com/community/cs/archives/arm-gnu/msg02332.html


問題解決:


  • 在產生nsboot.bin (gm8126_mp) 發生以下錯誤:
output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/libgcc.a(_dvmd_lnx.o): In function `__aeabi_ldiv0':
output/toolchain/gcc-4.6.3/libgcc/../gcc/config/arm/lib1funcs.asm:1266: undefined reference to `raise'
make: *** [nsboot] Error 1

網路上有幾篇文章有相關類似的說明,大致上應該是boot 通常都是 non GNU/Linux application,而ARM EABI" toolchains 卻是 GNU/Linux,所以導致相衝的問題。
解決方案:

  1. 直接修改原始檔,將 raise() 直接回傳 zero. (只是不清楚要改哪,所以跳過)
  2. 直接使用原廠提供的glibc 產生的 nsboot.bin檔。不再產生uClibc 的nsboot.bin。 

 

build uClibc toolchains using Buildroot for GM812x (補2/1)

參考來源:

  • uClibc Web site : http://uclibc.org/toolchains.html
  • http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-03/msg04460.html
  • http://www.crifan.com/make_uimage_error_conflicting_types_for_getline_stdio_h_previously_declaration_was_here/
  • https://bugzilla.redhat.com/show_bug.cgi?id=493941


步驟:
1. 在uClibc官網中(http://uclibc.org/toolchains.html)有簡易的說明如何此用 Buildroot 來產生 uClibc 的 toolchains.
2. 下載 Buildroot,然後修改設定檔:(run 'make menuconfig')

  • Target Architecture (ARM (little endian))
  • Target Architecture Variant (arm926t)
  • Target ABI (EABI)
  • Toolchain  --->
    • Kernel Headers (Linux 2.6 (manually specified version))
    • (2.6.28) linux version 
  • Filesystem images ==> 全部取消
3. run 'make'

問題修正:

  • 當在build 到 output/toolchain/linux-2.6.28 kernal時會出現以下的錯誤。


   scripts/unifdef.c:209: error: conflicting types for 'getline'
   /usr/include/stdio.h:653: note: previous declaration of 'getline' was here
   make[2]: *** [scripts/unifdef] Error 1
   make[1]: *** [__headers] Error 2
   make[1]: Leaving directory `/home/ken/WrkSrc/test1/Grain/grain/test_tmp/buildroot-      2012.11.1/output/toolchain/linux-2.6.28'
  make: *** [/home/ken/WrkSrc/test1/Grain/grain/test_tmp/buildroot-2012.11.1/output/toolchain/linux/.configured] Error 2

        在網路上搜尋到有兩種解決方式(請看參考來源),一種是直接修改 "scripts/unifdef.c",將"getline"函式直接修改成其他的名字(例:parseline);另外一種是在 CFLAGS 中加入 "-D_POSIX_C_SOURCE=200112L"。
※ 若是採用第一種方式,每次當 buildroot run 'make clean' 後,就必須再修改一次。(至於第二種不知道加在哪,所以沒試)
        此外網路上也有說明這問題已經在2009/04已經修正。


  • 安裝額外的lib (prec)時,發生需要支援 large file support.
    => 修改 buuild 設定檔。
    • Toolchain  --->
      •  [*] Enable large file (files > 2 GB) support
 

2013年1月31日 星期四

GM812x cramfs測試步驟


PS: 已經有一個cramfs image file大小約3M

1. 以目前的ramdiskfs模式下,使用chroot 測試cramfs:
  1.1 變更kernal MTD table(mtdblock5),切割一塊3M的partition。
  1.2 enable kernal config to support cramfs.
  1.3 更新FW,讓kernal能support cramfs
  1.4 上傳測試用cramfs,將其寫入mtdblock5:
      dd if=/upload/roo.img of=/dev/mtdblock5
  1.5 切換rootfs:
     mount -t cramfs /dev/mrdblock5 /mnt/mtd
    chroot /mnt/mtd
2. 在kernal boot command 直接開啟cramfs
  2.1 disable kernal config to dissupport ramdiskfs
  2.2 修改kernal boot command,加入cramfs 開機指令:
    ... rootfs=/dev/mtdbloack5 rootfstype=cramfs

2013年1月30日 星期三

iwlist [interface] scanning 回傳訊息的順序修改

常常發現在不同的wifi dongle在使用iwlist [interface] scanning後所得到訊息往往裡面的順序都會有所不同,可是上層APP parse function已經寫好了(例如:目前的parse是以"Quality"的訊息來判對AP資訊的結束),又不想改寫的話,就只好修改wifi dongle driver 在iwlist [interface] scanning 回傳訊的順序,所以就去瞭解一下iwlist [interface] scanning的動作流程。

由iwlist.c中可以發現,scanning的動作是呼叫"print_scanning_info"函式,在此function中可以看到
      /* Initiate Scanning */
      if(iw_set_ext(skfd, ifname, SIOCSIWSCAN, &wrq) < 0)
這裡就是對interface發出scanning的ioctl,而後就等待底層的回應
      /* Wait until something happens */
      ret = select(last_fd + 1, &rfds, NULL, NULL, &tv);
當底層有回應後,在呼叫
 if(iw_get_ext(skfd, ifname, SIOCGIWSCAN, &wrq) < 0)
來讀取底層回傳的訊息。

所以修改底層可以先以"SIOCGIWSCAN"來搜尋,以RTL8192CU的驅動來看,
rtw_wx_set_scan, /* SIOCSIWSCAN */
rtw_wx_get_scan, /* SIOCGIWSCAN */
rtw_wx_set_essid, /* SIOCSIWESSID */
可以看到"SIOCGIWSCAN" 對應函式為"rtw_wx_get_scan",在其中可以看到"translate_scan"的函式,這個函式就是要修改的地方。在此函式中可以看到最後的訊息是Quality相關,也可以看到關鍵的cmd。
/* Add quality statistics */
iwe.cmd = IWEVQUAL;
接著再以"IWEVQUAL" 來搜尋RT5370 dirver,就可以看到"rt_ioctl_siwscan" int sta_ioctl.c,而其中Quality相關的動作是在中間
/*Channel and Frequency */
......
/*Add quality statistics */
....
/*Encyption key */
接下來就只要把Quality相關的程式碼移到函式的尾端,如此就可讓兩個WIFI dongle在iwlist [interface] scanning的回傳訊息中,每個AP都會以Quality作為結尾。

WIFI signal percentage與dbm互轉

因RTL8192CU與RT5370在iwlist [interface] scanning 回傳的訊息中,signal level的回傳值RTL8192CU使用percentage,而RT5370卻是以DB表示,所以為了統一UI上顯示的訊息,所以將signal level轉為percentage表示。

percentage to dbm:
在RTL8192CU的driver中有段程式碼將percentage to dbm(rtw_recv.h),程式碼如下:

__inline static s32 translate_percentage_to_dbm(u32 SignalStrengthIndex)
{
s32 SignalPower; // in dBm.

// Translate to dBm (x=0.5y-95).
SignalPower = (s32)((SignalStrengthIndex + 1) >> 1);
SignalPower -= 95;

return SignalPower;
}

dbm to percentage:
在RT5370的driver中有段程式碼將dbm to percentage(cmm_info.c),程式碼如下:
/* Rssi*/
Rssi = (INT)pBss->Rssi;
if (Rssi >= -50)
Rssi_Quality = 100;
else if (Rssi >= -80)    /* between -50 ~ -80dbm*/
Rssi_Quality = (UINT)(24 + ((Rssi + 80) * 26)/10);
else if (Rssi >= -90)   /* between -80 ~ -90dbm*/
Rssi_Quality = (UINT)(((Rssi + 90) * 26)/10);
else    /* < -84 dbm*/
Rssi_Quality = 0;
sprintf(msg+strlen(msg),"%-9d", Rssi_Quality);

也許有人會問怎麼不把percent to dbm的函式反轉就可以做dbm to percentage,為什麼要這麼麻煩?原本也是打算這麼做,可是實做後發現,也許是廠商不同,RT5370回傳的dbm值若是直接使用反轉的函式所得到的percentage值有時會出現超過100%的數值,所以後來還是乖乖的使用判斷的方式來將dbm to percentage。

2013年1月24日 星期四

Apache Software License Version 1.1

目前遇到國外客戶需要我們列出平台使用的software license,可是因為公司沒有這方面的經驗,所以就大家分別研究各種license的限制。然而,被分配到研究"Apache Software Licence version 1.1",首先先放中英文對照翻譯:(這時候Google翻譯真好用...)

※目前已經被Apache Software License Version 2.0取代※

Copyright (c) 2000 The Apache Software Foundation. All rights reserved.
版權所有(c)2000 Apache軟件基金會。 保留所有權利。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
准許以無論有無修改的原始碼或二進位碼形式,為再散布或使用行為,只要符合義務要求即可。
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
1. 原始碼的重製物必須包含授權條款的著作權聲明和授權條款的所有內容。
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
以二進位碼呈現的重製物必須在程式本體或其他說明資料中重現授權條款的著作權聲明和授權條款的所有內容。
3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment:
"This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."
Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear.
3. 若含有終端用戶使用說明時,必須同時包含「此產品所含軟體為 ASF 所開發」的確認訊息,並可與第三者的確認訊息間隔並列。
4. The names "Apache" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact apache@apache.org.
4. 在沒有事前書面的允許下,"Apache" 和 "Apache Software Foundation" 的名稱不被用於支持或宣傳從本軟體衍生的產品。書面許可請洽"apache@apache.org"
5. Products derived from this software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation.
5.  未經Apache Software Foundation書面允許前,從本軟體衍生的產品不得以 "Apache" 稱呼或在名稱中包含 "Apache" 的字眼。

======以下省略=====
THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation. For more information on the Apache Software Foundation, please see .
Portions of this software are based upon public domain software originally written at the National Center for Supercomputing Applications, University of Illinois, Urbana-Champaign.
======以上省略=====

看起來這種License很簡單,沒有強迫軟體商必須放出自己的原始碼,只要發行時保留授權條款的著作權聲明和授權條款的所有內容、在使用說明書中說明「此產品所含軟體為 ASF 所開發」、並且在沒有書面允許前不要使用"Apache"相關字樣來宣傳或命名產品

資料來源:
http://www.openfoundry.org/tw/licenses/28-apache-license-11-apache-11 (中文翻譯部分)
http://opensource.org/licenses/apachepl-1.1.php (英文部分)
http://www.apache.org/licenses/LICENSE-1.1 (原始文件)

LDD命令

来自:http://blog.csdn.net/tenfyguo/article/details/5605120

Linux中,可以顯示指令/程式所聯結的so,但不會執行指令/程式。
一般是使用環境變數來開啟或關閉:
開啟:export LD_TRACE_LOADED_OBJECTS=1
關閉:unset LD_TRACE_LOADED_OBJECTS
當開啟LDD功能後,指令/程式就只會顯示所聯結的so檔,例:(GM812x平台)

# ls /usr
        libm.so.6 => /lib/libm.so.6 (0x40028000)
        libc.so.6 => /lib/libc.so.6 (0x400c4000)
        /lib/ld-linux.so.3 (0x40000000)