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建立成功。

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搜尋，發現了以下的網頁

http://stackoverflow.com/questions/5905434/building-gcc-4-6-libmpfr-so-4-cannot-open-shared-object-file

其中有類似的問題，然而解決的方式是：宣告 "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

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：這樣修改雖然可以使用，但因為解析度的問題，所以會造成程式中功能圖示的位置有些偏移。

海康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杪。

 

 

 

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

 

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