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

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

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。

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)

samba 寫入測試

1. mount -t cifs //ip/path ${LOCAL_PATH} -o username="${USER},password=${PASS}
2. 斷線測試：
2.1 open by "O_CREAT | O_WRONLY | O_TRUNC"
open: 斷線第一次後，需要15~30秒才會跳出；第二次之後為10秒。
write: 斷線第一次後，需要15秒才會跳出；第二次之後為10秒。不會回傳錯誤值。
close: 開檔之後再斷線仍可正常close。
檔案: 斷線後在連線，檔案大小正確，但斷線期間的內容為"0x0"。
2.2 open by "O_CREAT | O_WRONLY | O_TRUNC | O_NDELAY"
open: 斷線第一次後，需要25秒才會跳出；第二次之後為10秒。
write: 斷線第一次後，需要15秒才會跳出；第二次之後為10秒。不會回傳錯誤值。
close: 開檔之後再斷線仍可正常close。
檔案: 斷線後在連線，檔案大小正確，但斷線期間的內容為"0x0"。
2.3 open by "O_CREAT | O_WRONLY | O_TRUNC | O_ASYNC"
open: 斷線第一次後，需要15~35秒才會跳出；第二次之後為10秒。
write: 斷線後不會卡住，也不會回傳錯誤值。
close: 開檔之後再斷線需10秒才回傳。
檔案: 斷線後在連線，檔案大小正確，但因為"非同步"原因，斷線前的資料會遺失，再連線前的部分資料會寫入。
2.4 open by "O_CREAT | O_WRONLY | O_TRUNC | O_ASYNC | O_NDELAY"
open: 斷線第一次後，需要15~35秒才會跳出；第二次之後為10秒。
write: 斷線第一次後，需要15秒才會跳出；第二次之後為10秒。不會回傳錯誤值。
close: 開檔之後再斷線仍可正常close。
檔案: 斷線後在連線，檔案大小正確，但斷線期間的內容為"0x0"。
2.5 open by "O_CREAT | O_WRONLY | O_TRUNC | O_SYNC"
open: 斷線第一次後，需要15~30秒才會跳出；第二次之後為10秒。
write: 斷線第一次後，需要15秒才會跳出；第二次之後為10秒。會回傳錯誤值。回覆連線後，會直接回傳錯誤不卡住，幾次後可正常寫入。
close: 開檔之後再斷線仍可正常close。
檔案: 斷線後在連線，檔案大小正確，回傳錯誤期間的內容為"0x0"。
2.6 open by "O_CREAT | O_WRONLY | O_TRUNC | O_SYNC | O_NDELAY"
open: 斷線第一次後，需要25~35秒才會跳出；第二次之後為10秒。
write: 斷線第一次後，需要15秒才會跳出；第二次之後為10秒。會回傳錯誤值。回覆連線後，會直接回傳錯誤且卡住，直到可以正常寫入。
close: 開檔之後再斷線仍可正常close。
檔案: 斷線後在連線，檔案大小正確，回傳錯誤期間的內容為"0x0"。

多事的一星期

Ken`s blog : 2010/03/29 (晴)

多事的一星期...
星期一：Sensor廠商要來調整參數；研發抵減要開始簽名。
星期二：Pre-M1教育訓練先前的內部檢驗。
星期三：Pre-M1教育訓練。
星期四：AM 7000 release FW to Amelie
星期五：不知道...

MOT Part-II & spook MJPEG test ok

Ken`s work blog 2009/09/25 (五) 晴
1. MOT(關鍵時刻)第二天課程：全天
2. 9/24已經修正 myapp 在 jpeg 模式下遠端接收不到資料的問題：程式碼中，傳送的部分被mark掉了...@_____@。 經過一天一夜的測試工作ok，接下來準備做H.264的部分。

新人教育訓練

Ken`s Blog 2009/09/21 (一) 晴
1. CC 於星期五來信說到，IPCam的專案因價格與規格備YOKO上層退件，所以先暫停機構方面的支援，以避免後續的設計與上級期待不同。
2. 下午參加YOKO舉辦的新人教育訓練，目的在於：了解YOKO的經營理念與文化、產品、請款流程、職業安全...等等。

不想給它寫日誌拉~~~

Ken`s Blog 2009/09/02 (三) 晴
1. 列出基於Pixord P606W所規劃出的Entry 2M/VGA CMOS IPCamera規格與初步價格。
2. 協請yoko採購幫忙搜尋主要IC零件 (Flash / DDR2 RAM / 2M CMOS sensor)
3. 與James定義初版產品型號編碼原則。

事情好多阿~~~

Ken`s Blog 2009/08/27 (四) 晴
1. 因Ethan在YOKO事務繁忙，所以目前暫由James代理Ethan業務方面事務，我暫代PM方面事務。
2. 需提供YOKO機構phone jack圖面，其餘I/O皆以提供。
3. Info：由大陸Howard提供。
3.1 目前杭特交大陸D-Link ip-cam(六月底前)平均一個月出貨約600~700台；N2100 FOB約700 rp(稅)，扣除17%關稅 & 10%運費，粗估台灣出貨FOB約為550 rp (US/RP = 6.9) 約為US80。
3.2 目前大陸D-Link還有使用 VideoTrec 提供的camera (平台：海思1502) (speed dome/100m ir-cam)
3.3 預計下星期 Howard 會拿到 1080p realtime 的 ip-cam，由 IQVersion提供。
3.4 期望價格(CMOS/VGA/雙向語音)：400 rp => 57US => 52US (扣除10%運費) => 40US (扣除30%獲利)，最後E-BOM cost 必須為40US。
4. 訂定專案名稱及編號：
4.1 Mobilygen平台之專案代號為： Mercury (水星)
4.2 Entry IP-cam 產品代碼： A100
4.3 編號(依YOKO編碼定義)： 8A1-01

面試真不知要說什麼 @___@

Ken`s Blog 2009/08/24 (一) 晴
面試：助工面試 - 感覺還好，沒有研發的經驗，對焊接、儀器使用經驗缺少，且對薪資28k~30K不太滿意。
硬體：相關I/O圖面已經準備完成，只缺無線天線找不到圖面。

@____@ 又忘了寫日誌

Ken`s Blog 2009/08/19 (二) 晴 － (補)
1. 產品規格會議： IPv6, QoS, 3Gpp, Easy Connect, IP filtering, Provacy Masking, Event Storage, wirelee, MIC.
2. FW時程規劃 with Jack/Sendo

每天寫好累阿~~~

Ken`s blog 2009/08/13 晴

1. 完成網域註冊繳費動作，已通知John。

2. 用餐人數統計完成。

3. P606 LED選擇討論：

3.1 要多加LED數目? 或是使用有發光角度的LED?

=> 等James看過有發光角度LED的效果後再決定。

3.2 是否可以使用紅光LED?

=> 等YOKO人員測試效果。

4. 於星期五前整理出目前硬體規格。

事情越來越多了...忙阿

1. 電腦請購：發現HUB與延長線並未採購到。HUB已請Amy補請購，但延長線必須自行購買。

2. 文具申請：Amy回覆，文具要自行購買再申請。

3. IPCAM外觀討論：James提出可以攜帶的IPCAM想法，原本有想使用電池外掛或是外殼上使用電池蓋的方式，但因為模具費用只有預計400K，所以沒辦法達成，後來改採電池內建的方式。(YOKO已有一款PSR 9107有內建鋰電，可以參考電源部分的線路)

4. 網域申請：MIS回應有兩種申請方式，其一為：申請domain與網頁，價格約4K；其二為：單純申請domain，價格約1K。已經問過John，若單純申請domain，之後web server可以交由YOKO MIS代管，或我們自行架設後再請YOKO MIS設定相關網路設定。

暫代行政事務窗口

2009/8/10 (一) 晴

1. 接到James指示，先行代理行政/總務/人事等對YOKO的窗口。

2. 新事業群命名結束，以：amegia 為事業群之英文名稱。

3. 電腦採購追蹤：今天廠商已進貨，進入組裝階段，預計8/12(三)入公司。

4. 由YOKO研二處接收硬體儀器一批。(類比螢幕/示波器/烙鐵/三用電錶/吸風器)

5. 網域申請：已轉請YOKO MIS協助申請。