把R40e的hpa cd 都燒在一片DVD裡。

開機，FWRESTORE file=R40EHPA

Paging in FATFS registry

FATFS registry 中的 "paging" 意思是..
http://blogs.gotdotnet.com/ce_base/archive/2005/08/09/449748.aspx
是支援 demand paging 的意思。

SD Password Protect Command Sequence

set password :

• CMD7 : Select Card
• CMD16 : Set Block Length
• CMD42 with Block Data

reset password :

• CMD7 : Select Card
• CMD16 : Set Block Length
• CMD42 with BlockData

Lock

• CMD7 : Select Card
• CMD16: Set Block Length
• CMD42 with BlockData

Unlock

• CMD7 : Select Card
• CMD16 : Set Block Length
• CMD42 with BlockData

Erase

• CMD7 : Select Card
• CMD16 : Set Block Length (to 1 byte only)
• CMD42 with BlockData

---

Result of CMD42

gps tracker with camera (or lcd)

看到 TC_Chu 的文章：

一個有camera的GPS tracker ，camera可以讀取，parsing 2d bar code。…並且把讀取的內容存起來，可以配合 gps log 資料應用。

這樣我就想到:

一個有小型 單色 lcd 的 GPS tracker，可以顯示2d bar code 在 lcd 上。
將 GPS 位置資料以2d bar code 的方式顯示在 lcd 上。

這樣的裝置有什麼用呢？

可以配合照相機，沒有 gps 的相機，可以拍下這個 lcd 的影像，這樣回去處理影像時，就可以知道當時的地理位置。

那也不用存甚摩麼 bar-code啦，就直印出 座標就可以啦，這樣不僅人可以判讀，電腦上處理起來也一樣 --- 而且不需要什麼 單色 lcd，用七段顯示器 就可以啦..

CE SDCARD Driver atchitecture

在 \PUBLIC\COMMON\OAK\DRIVERS\SDCARD

---

HostContainer -- 內部保有 一個 SDHost[] (以HostContainerClass 處理)，
利用 InserSDHost( )加入到 Arrary中。

HostContainer 是一個Singleton pattern

SDHost 內有一個 *SDSlot[]

以上都在sdbus.cpp

SDSlot 內有一個 SDDevice[]


SDSlot[] 的array size是在 SDHost 生成時指定的 (dwNumSlot)。
但是 SDHost[] 是用 InserSDHost( ) 動態加入。

是在 HostContainer 的 static function : SDHCDAllocateContext_X( ) 中生成的，dwNumSlot 是 argument。

SDHCDAllocContext_X( )是由 另一個 driver : HSMMC 透過 function pointer 呼叫。
呼叫時，dwNumSlot 是從 registry key 讀出來的。 -- 是猜出來的。

Slot在處理 CardInsert 時，才會 生成 SDDevice，依照 inser card 的 function number 來決定生成多少 device.

---

SDHostContainer -- 內含 SDHost
SDHost -- 內含 SDSlot
SDSlot -- 內含 SDDevice

SDHostContainer 內含 function-pointer array, 指向 HSMMC
SDHostContainer 內含 static function array，expose (called by) HSMMC


SDSlot 和 SDDevice 可以送出 Command 給 SD, ( 因為他們都有繼承 SDBusRequest)
但是 SDSlot 只操作 SDRequestQueue，
SDDevice 實際生成 SDRequestQueue，然後呼叫

 m_sdSlot.QueueBusRequest(pNewRequest);

呼叫 slot 的 queue operation , 將 request 加入到 request queue 中

---

SDWorkItem 是一個 postevent, thread handle event 的 class。
如其名，是實際工作的 class，生成會後launch 一個 working thread，和一個event queue 。
可以藉由 PostEvent( ) 通知該 Thread。

可以視為獨立於 CE 系統之外的 event-signal 系統

但是很白痴的會call SlotStatusChangeProcessing( )。
所以要利用這個WorkItem機制，要繼承這個class，然後實做 SlotStatusChangeProcessing( )

grep : find string in source

還是unix 好用，用 UnixUtil 搜尋 source 中的字串，可以用：

grep -Ir CStaticContainer *

其中..

• -I 是說，ignore binary file
• -r 是說，recursive

使用 grep 不能同時指定 file pattern 和 recursive，要配合 find 才行。

但是 xargs 在 Windows 下會有 "cannot fork" 的 error message。

其他：

• -i 是說，ignore case (大小寫不管)

這一夜的說明很不錯。
http://www.esmerel.com/wagons/rob/grep.html

原來在

C:\WINCE500\PUBLIC\COMMON\OAK\DRIVERS\SDCARD\SDBUSDRIVER\sdbusrequest.cpp

有 SDBUS driver 的 normalpath-fastpath 的圖例 說明

eVC with KITL - SDK setting

eVC 使用 KITL 作 debug 時，要注意 和選擇的 SDK 有關系。
在 Configure Platform Builder 中會有很多 platform setting ，這些都是你有裝的 SDK。
eVC會用目前 project 的 SDK 的設定來連線。

sequence on CMD42

SD card 的溝通也是要靠 Address 的， (RCA : Relative Card Address)，但是 address 0x00 是 broadcast address，所有的 card 都要收。

CMD7 (SELECT_DESELECT) 是用來 toggle SD card 進入/退出 Transfer Mode 。

Card Lock/Unlock Command 類似 Block Write Command。
其中 transfer 的 data 部份，就是 password, setting... etc。

所以 CMD42 的 Response 也跟 Block Write Command 的 Result 一樣 ？

Card Identification.. 然後 Configuration...然後進 Transfer state..

procedure :

先作 setting password

---

Linux 真是偉大，在某一版看到 implement，但是好像沒有 接受
http://groups.google.com.tw/group/linux.kernel/browse_thread/thread/7ddefc84c21ede84/d47cd82a306fd9d8?q=mmc_lock_unlock#d47cd82a306fd9d8

int mmc_lock_unlock(struct mmc_card *card, struct key *key, int mode)
+{
+       struct mmc_request mrq;
+       struct mmc_command cmd;
+       struct mmc_data data;
+       struct scatterlist sg;
+       struct mmc_key_payload *mpayload;
+       unsigned long erase_timeout;
+       int err, data_size;
+       u8 *data_buf;
+
+       mpayload = NULL;
+       data_size = 1;
+       if (mode != MMC_LOCK_MODE_ERASE) {
+               mpayload = rcu_dereference(key->payload.data);
+               data_size = 2 + mpayload->datalen;
+       }
+
+       data_buf = kmalloc(data_size, GFP_KERNEL);
+       if (!data_buf)
+               return -ENOMEM;
+       memset(data_buf, 0, data_size);
+
+       data_buf[0] = mode;
+       if (mode != MMC_LOCK_MODE_ERASE) {
+               data_buf[1] = mpayload->datalen;
+               memcpy(data_buf + 2, mpayload->data, mpayload->datalen);
+       }
+
+       memset(&cmd, 0, sizeof(struct mmc_command));
+
+       cmd.opcode = MMC_SET_BLOCKLEN;
+       cmd.arg = data_size;
+       cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
+       err = mmc_wait_for_cmd(card->host, &cmd, CMD_RETRIES);
+       if (err != MMC_ERR_NONE)
+               goto out;
+
+       memset(&cmd, 0, sizeof(struct mmc_command));
+
+       cmd.opcode = MMC_LOCK_UNLOCK;
+       cmd.arg = 0;
+       cmd.flags = MMC_RSP_R1B | MMC_CMD_ADTC;
+
+       memset(&data, 0, sizeof(struct mmc_data));
+
+       mmc_set_data_timeout(&data, card, 1);
+
+       data.blksz = data_size;
+       data.blocks = 1;
+       data.flags = MMC_DATA_WRITE;
+       data.sg = &sg;
+       data.sg_len = 1;
+
+       memset(&mrq, 0, sizeof(struct mmc_request));
+
+       mrq.cmd = &cmd;
+       mrq.data = &data;
+
+       sg_init_one(&sg, data_buf, data_size);
+       err = mmc_wait_for_req(card->host, &mrq);
+       if (err != MMC_ERR_NONE)
+               goto out;
+
+       memset(&cmd, 0, sizeof(struct mmc_command));
+
+       cmd.opcode = MMC_SEND_STATUS;
+       cmd.arg = card->rca << 16;
+       cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
+
+       /* set timeout for forced erase operation to 3 min. (see MMC spec) */
+       erase_timeout = jiffies + 180 * HZ;
+       do {
+               /* we cannot use "retries" here because the
+                * R1_LOCK_UNLOCK_FAILED bit is cleared by subsequent reads to
+                * the status register, hiding the error condition */
+               err = mmc_wait_for_cmd(card->host, &cmd, 0);
+               if (err != MMC_ERR_NONE)
+                       break;
+               /* the other modes don't need timeout checking */
+               if (mode != MMC_LOCK_MODE_ERASE)
+                       continue;
+               if (time_after(jiffies, erase_timeout)) {
+                       dev_dbg(&card->dev, "forced erase timed out\n");
+                       err = MMC_ERR_TIMEOUT;
+                       break;
+               }
+       } while (!(cmd.resp[0] & R1_READY_FOR_DATA));
+       if (cmd.resp[0] & R1_LOCK_UNLOCK_FAILED) {
+               dev_dbg(&card->dev, "LOCK_UNLOCK operation failed\n");
+               err = MMC_ERR_FAILED;
+       }
+
+       if (cmd.resp[0] & R1_CARD_IS_LOCKED)
+               mmc_card_set_locked(card);
+       else
+               mmc_card_clear_locked(card);
+
+out:
+       kfree(data_buf);
+
+       return err;
+}

裡面有完整的CMD42 的 command sequence..
但是這段 code 在linux kernel 中找不到...

這一個Thread 有相關的討論..

Something about SD

High Speed SD card 的 clock 增加一倍(up to 50MHz)，使用 4 bit data line，所以 interface bandwidth 是 25MB/s。

但是 Class 6 的 SD card，速度只有到 6MB/s。

25 -- 6, 哇，Overhead 好大呀！

SD Card power on 時，只使用 D0 傳輸，適當的 initialize (SET_BUS_WIDTH)後，就可以選擇使用 D0 ，或是 D0~D4傳輸。

即使在 D0 (1 line) 傳輸狀態，D1~D4也不可以挪作他用，要保持 tri-state。

問題：只使用 D0 傳輸時，就是 SPI Mode 嗎？

好像不是，SPI 還會用 D3 當 CS用，拿CMD當Di (datain)用。

SD interface 是序列傳輸的 interface，有專屬的雙向 CMD, Data line。
CMD 只有一條線，Data 可以有 1 ~ 4 條。

我以前以為 data (0~3) 是共用的，然後用 CMD 的 high/low 來代表目前 data送的是 command 還是 data.

CMD line 用來傳輸 host 給 SD card 的 command ，同用來傳輸 SD card 給 host 的 response。

Command, Response 都是由單一條 CMD line 傳送的，所以 Command packet，Response Packet 的 size 都不必是 8 的倍數。(?)

但是好像實際都是8 的倍數呀。

SD card 操作的形式都是 由 Command 來操作。
有些 Command 有 Response，Card 會回送 Response回來，
有些 Command 會 引發 Data 的操作，例如 Read Block command，SD card 收到後，就會將 傳送 Data 回 Host，同時回應 Response 回 host。

Write Command 也會引發 Data傳輸，
Host 送給 SD card，SD card 收到後，以D0 作為 busy 信號，
host 送完 Data 要 check D0 (busy) 狀態，等 SD card 動作結束，放掉 D0 後，才可以進行下一個 command/data 操作。

Windows CE : load Device Driver : ActivateDeviceEx

Device Manager : DEVICE.EXE

先 CreateDevice( ) : 把Driver 的 DLL load 進memory，並且取出 DLL 的：

• Init
• PreDeinit
• Deinit
• Open
• PreClose
• Close
• Read
• Write
• Seek
• IOControl
• PowerUp
• PowerDown

以上的function point，給自己(DEVICE.EXE)保存起來。

LaunchDevice( )

會 call 上面說的 function 的 Init( )

SDBUS\sdslot.cpp    HandleAddDevice()
Initial, get Interface,, 之後 SDLoadDevice( )

SDBUS\sddevice.cpp  SDLoadDevice( )
從registry 取出 path.. new HostController( ), New  DriverFolder( )
之後 DriverFolder->LoadDevice( )

\DRIVERS\BUSENUM\BUSDEF\defbus.cpp  DeviceFolder::LoadDevice()
 ActivateDeviceEx( )

.. COREDLL....

然後就是 private code 的 device manager

DEVCORE\devapi.c  l_ActivateDeviceEx( )  <---!!! 這一段就有 DEVFLAGS_NOLOAD 的 ref code.

SD card 的 password protection lock.

SD card 的 password protection Lock 是 SD 2.0 規範SD card 要提供的功能

機制大概是這樣

• SD card 提供一個位置儲存 password。
• SD card power on 時會 check 有沒有 password，如果有，就 lock SD card 所有的 read data 動作。
• SD card 提供一個 unlock command，需要提供 password。當 隨著這個 unlock command 的 password 是正確的，SD card 就解除 read data 的限制。 這樣，就可以正常讀取SD card的資料。
  

但是這時候，password 欄位並沒有被清除唷

• SD card 提供一個 lock command。需要提供正確的 password。
• SD card 提供一個 clear password 的 command，需要提供正確的 password。好將password clear掉。
• SD card 提供一個 clear all data and password 的 command，不需要正確的 password。將整個 SD card 的資料都刪除，同時 password 也清掉。

所以，對於一個有設 password 的SD card，插入讀卡機後，要下unlock command (with password)，然後才可以讀取資料。
之後拔出SD card，再插入其他機器，因為 password 還在(沒有被 clear)，所以一樣是lock 的，需要輸入 password 來 unlock。

這樣，就做到保護 SD card 資料的目的。

---

password 是 128 bit，忽略暴力解好了。
這樣的 protection，只要在插入 SD card，授權的 AP做完 unlock，正在存取資料時，同時讀取SD card，就可以讀到 SD card 的資料了。

目前都是 multitasking的OS，要做到應該不難。

不然就在授權AP做完unlock，正在access SD時，強制 kill 該AP。然後就可以讀取SD了。


更不要說..如果你是 OS developement....負責 SD card driver .....可以 log cmd42...

1. What's the problem ?
   
2. What's the ideal situation when there is no problem ?
3. How do we go from here to there ? ( How do we go there from here ?)
4. How do people respond to the policy change ?
5. Can we really go from here to there ?

從這裡 copy 的

eVC++ over KITL

eVC 一般都是用 ActiveSync 和 Target連線，但是也可以用 KITL 喔.... (雖然不知道這樣有什麼好處..)。

但是需要 Platform Builder 幫忙建立起 KITL 連線。

platform builder 建立KITL 連線的方法就跟平常一樣。
所以重點在 eVC 的設定：

Tools -- Configuration Platform Manager : 選target 的 device, 按 properties:
Transport : KITL transport for Windows CE
Startup Server : CESH Server for Windows CE

這樣就OK了。 eVC就可以像 ActiveSync 一樣動作。只不過是"慢"動作..

跟 ActiveSync比起來，好處在哪？
(這樣的問題不要問我了..)

JIT Debugger

這一篇：JIT debugger

Platform--Setting 不enable Kernel Debugger，但是要Enable KITL。

kd.dll, osaxst0.dll, osaxst1.dll 改放在FILES，不要放在MODULE (因為放在MODULE會被自動load進去啟動)。

需要 loaddbg.exe ，所以可以把這個 file放進 files。
hd.dll一樣放到 FILES。

要啟動 kitl debug。只要執行 loaddbg.exe 就可以了。 <=說錯。
kitl debug 還是要手動 enable 起來 (run activekitl).
然後在 platform builder 的 cesh 下command

Wincows CE <s loaddbg.exe

然後platform builder 會 load symbol 讓 platform builder 好像當機一樣，約 2 min 後，symbol load 進來。就可以操作了.,

---

這一篇msdn 有說明 JIT Debugger Setup.
這一篇討論好像有關。
這一篇也是講 JIT，但是要換 debug module. UsrExceptDmp.exe

msdn blog 說ktil , debug for ce 5.0 and 6.0. 這一篇和這一篇也是。

---

JITDebugger 好像有兩種：on pc, on device。
大概是依照 exception 發生時，叫起 debugger的動作：

• pc : 開啟 kitl，和 platform builder 連線。
• device : 依照registry 的內容，開啟一個ap (例如 UsrExceptDmp.exe)

PASSIVE KITL cannot "Run Program"

如果是 passive KITL，Platform Builder 的 Target--Run Programs 就不會active 。
要是Active KITL 才可以。 <==其實是可以的，ref loaddbg.exe
這是 Release folder 有沒有mount 的原因嗎？

---

因為太短，所以多寫一些..


Active KITL，雖然 boot 時就啟動 kitl, wait for connection，但是還是run nandflash 中的 image，並沒有重新download kernel 進來 run。

download and run 是在 eboot 作的，但是如果是 XIP，也沒有辦法。binfs 部份還是 在nandflash中

USB initiate..log

ref 這一篇，有 initiate packet data.
USB Request Pocket.

typedef struct DEVICE_REQUEST
{
 UINT8 RequestType; //0
 UINT8 Request;     //1
 UINT8 ValueL;      //2
 UINT8 ValueH;      //3
 UINT8 IndexL;      //4
 UINT8 IndexH;      //5
 UINT8 LengthL;     //6
 UINT8 LengthH;     //7
} DEVICE_REQUEST;

Request Code:

GET_STATUS         0
CLEAR_FEATURE      1
RESERVED_1         2
SET_FEATURE        3
RESERVED_2         4
SET_ADDRESS        5
GET_DESCRIPTOR     6
SET_DESCRIPTOR     7
GET_CONFIGURATION  8
SET_CONFIGURATION  9
GET_INTERFACE      10
SET_INTERFACE      11
SYNCH_FRAME        12

Install Samba Server in Windows

這一篇有prebuild version，還有，不用裝Cygwin.

為甚麼要這樣作呢？ 因為Windows 有 15 人的連線限制...

還沒試..

這一篇是在 Cygwin 上安裝 Samba 的範例。

romimage ce.bib

makeimage 時，會由 config.bib, platform.bib 產生 ce.bib。
然後 romimage 會依照 ce.bib 的內容產生 *.bin

config.bib 和 platform.bib 內容常常有一些 define 和variable，所以很難看出 ce.bib 最後是怎樣。
可以等 makeimg 完再看 ce. bib。

如果只是要修改 bib (config.bib or platform.bib)，可以只修改 %_FLATRELEASEDIT%\ce.bib。
然後 call romimage ce.bib 就可以。