並不是所有的embedded system都具有良好的file system support, 在此方面使用FAT 還是相當普遍. 而使用FAT的原因相當簡單, 因為FAT 沒有複雜的設計, 降低實做的code size, 多數3C產品與一般OS屬於預設的支援.
目前屬於Open Source FAT implementation有下
ELM - FAT File System Module
具有相當不錯的介面設計, 很接近一般VFS的介面
具有格式化功能, 算是相當完整的實做
並無明顯的授權聲明, 在source 中的 readme.txt 聲明自負風險下不限制使用於任何用途
EFSL - Embedded File System Library
有相當完整的文件說明
授權: LGPL
libfat
授權: GPL
dosfs
source中的readme.txt 聲明自負風險下不限制使用於任何用途.
2009年2月17日 星期二
2009年2月15日 星期日
Prex - FAT32
原本是打算將ELM FAT implementation移植到Prex上
然而因為Prex的Embedded VFS設計的緣故(該設計相當接近於VFS in Sun Unix),
若採用整合ELM FAT的方式需要相當的時間
而其中原因在於資料結構上的考量
因此就改為直接修改Prex本身具有的FAT 12/16以支援FAT32
如此還能針對FAT深入瞭解
而經過數日的奮戰
目前Prex 已經能夠操作 FAT32 檔案系統
也簡短地測試過, 檔案/目錄的新增移除是正常的
尚未支援用以輔助配置free block的 FSINFO以及長檔名的LFN(Long File Name)
有機會再把實做補上
由於處理FAT32的緣故, 研讀了些關於FS的相關資料
而先前所提到的書 File System Forensic Analysis 也幫助不少
另外下列資訊也有相當得助益
boot log如下:
Prex version 0.8.1 for arm-at2440ii (Feb 12 2009)
Free pages:
start end size
-------- -------- --------
00000000 - 00010000 64K
00033800 - 01c27000 28622K
01c39c00 - 04000000 36633K
used=142K free=65319K total=65461K
Time slice is 50 msec
IRQ10 attached priority=10
Clock rate: 1000 ticks/sec
Prex driver module built: Feb 12 2009
Calibrating delay loop... ok count=837
Initializing NULL device
Initializing Power Management
pm: Default power policy is performance mode
Initializing Zero device
Initializing Serial Console
UBRDIV0:0x23
IRQ28 attached priority=1
Initializing RAM disk
RAM disk at 0x01c270e0 (74K bytes)
Initializing SD card
Init. SD Freq. is 401256Hz
In idle
MMC check end!!
In SD ready
End id
RCA=0x9ffc
SD Frequency is 33304320Hz
In stand-by
****4bit bus****
SD disk
IRQ21 attached priority=2
Initializing TTY device
Driver initialized
Loading task:'boot'
Loading task:'proc'
Loading task:'fs'
Loading task:'exec'
Starting Bootstrap Server
Starting Process Server
Starting File System Server
Starting Exec Server
boot: Mounting file systems
VFS: Mounting ramfs dev= dir=/
VFS: Mounting devfs dev= dir=/dev
VFS: Mounting arfs dev=/dev/ram0 dir=/boot
VFS: Mounting fifofs dev= dir=/fifo
VFS: Mounting fatfs dev=/dev/card0 dir=/mnt/floppy
fatfs_mount device=/dev/card0
0 1 1 0 b 1f fd f7 3d 0 0 0 c3 42 1e 0
fatfs partition at sect: 3d
----- FAT 12/16/32 info ----- 3c673
drive:80
total_sectors:1983170
heads :32
serial :49984554
cluster size:8 sectors
fat_start :5d
root_start :2
data_start :f77
fat_type :FAT32
fat_eof :0xfffffff
boot: Run init process
Prex version 0.8.1 (arm-at2440ii)
[prex:/]# cat /mnt/floppy/champ.txt
fatfs_lookup: name=champ.txt
fat_lookup_denode: cl=0 name=champ.txt
fat_lookup_dirent: Ac
fat_lookup_dirent: found sec=3959
fatfs_lookup: cl=4
fatfs_read: vp=38e3c
Hello World!
fatfs_read: vp=38e3c
[prex:/]#
然而因為Prex的Embedded VFS設計的緣故(該設計相當接近於VFS in Sun Unix),
若採用整合ELM FAT的方式需要相當的時間
而其中原因在於資料結構上的考量
因此就改為直接修改Prex本身具有的FAT 12/16以支援FAT32
如此還能針對FAT深入瞭解
而經過數日的奮戰
目前Prex 已經能夠操作 FAT32 檔案系統
也簡短地測試過, 檔案/目錄的新增移除是正常的
尚未支援用以輔助配置free block的 FSINFO以及長檔名的LFN(Long File Name)
有機會再把實做補上
由於處理FAT32的緣故, 研讀了些關於FS的相關資料
而先前所提到的書 File System Forensic Analysis 也幫助不少
另外下列資訊也有相當得助益
boot log如下:
Prex version 0.8.1 for arm-at2440ii (Feb 12 2009)
Free pages:
start end size
-------- -------- --------
00000000 - 00010000 64K
00033800 - 01c27000 28622K
01c39c00 - 04000000 36633K
used=142K free=65319K total=65461K
Time slice is 50 msec
IRQ10 attached priority=10
Clock rate: 1000 ticks/sec
Prex driver module built: Feb 12 2009
Calibrating delay loop... ok count=837
Initializing NULL device
Initializing Power Management
pm: Default power policy is performance mode
Initializing Zero device
Initializing Serial Console
UBRDIV0:0x23
IRQ28 attached priority=1
Initializing RAM disk
RAM disk at 0x01c270e0 (74K bytes)
Initializing SD card
Init. SD Freq. is 401256Hz
In idle
MMC check end!!
In SD ready
End id
RCA=0x9ffc
SD Frequency is 33304320Hz
In stand-by
****4bit bus****
SD disk
IRQ21 attached priority=2
Initializing TTY device
Driver initialized
Loading task:'boot'
Loading task:'proc'
Loading task:'fs'
Loading task:'exec'
Starting Bootstrap Server
Starting Process Server
Starting File System Server
Starting Exec Server
boot: Mounting file systems
VFS: Mounting ramfs dev= dir=/
VFS: Mounting devfs dev= dir=/dev
VFS: Mounting arfs dev=/dev/ram0 dir=/boot
VFS: Mounting fifofs dev= dir=/fifo
VFS: Mounting fatfs dev=/dev/card0 dir=/mnt/floppy
fatfs_mount device=/dev/card0
0 1 1 0 b 1f fd f7 3d 0 0 0 c3 42 1e 0
fatfs partition at sect: 3d
----- FAT 12/16/32 info ----- 3c673
drive:80
total_sectors:1983170
heads :32
serial :49984554
cluster size:8 sectors
fat_start :5d
root_start :2
data_start :f77
fat_type :FAT32
fat_eof :0xfffffff
boot: Run init process
Prex version 0.8.1 (arm-at2440ii)
[prex:/]# cat /mnt/floppy/champ.txt
fatfs_lookup: name=champ.txt
fat_lookup_denode: cl=0 name=champ.txt
fat_lookup_dirent: Ac
fat_lookup_dirent: found sec=3959
fatfs_lookup: cl=4
fatfs_read: vp=38e3c
Hello World!
fatfs_read: vp=38e3c
[prex:/]#
2009年2月11日 星期三
File System Forensic Analysis
目前個人正嘗試修改Prex上的FAT 12/16實做, 以便支援FAT 32. 過程中, 很令我很訝異的, 儘管FAT廣為人知,良好解釋FAT的文件卻付之闕如. 雖然, FAT 相關實做已經非常的多, 網路上相關的訊息卻非常零散且難以消化, 缺乏有系統和概念性的完整資訊.
File System在各種實際應用系統中, 都扮演著舉足輕重的角色. 從系統效能, 到基本的資料保存, 都與File System 息息相關. 然而很可惜的, 對於File System而言, 許多人的印象似乎只是附屬的存在, 常常容易被忽略.
那麼非得下去好好trace code才能獲得相關知識? 對於File System有興趣研究的人該怎麼下手?對此File System Forensic Analysis是關於FS相當不錯的參考書目, 該書除了提供目前主流各式File System的說明外, 也提供了相關的基本知識, 在章節的規劃與內文的易讀性, 都相當不錯. 目前市面上專注於此方面的書並不多, 而部份甚至已經顯得過時. 對FS有興趣者, 相當建議購買一本來閱讀.儘管許多進階的檔案系統(ex: ext4, xfs, zfs) 沒有納入介紹, 然而書的內容對於瞭解這些FS的設計與規劃也有相當的助益.
2009年2月9日 星期一
S3C2440A - SD Card works on Prex!
參考著Samsung的測試程式與u-boot, 把SD driver for prex 移植完畢
目前使用的是處理read/write interrupt的方式完成實做
一開始是採用使用DMA方式實作, 然而碰到無法讀寫完畢
像是read counter會有尚未讀出的資料, 而停留在Rx Active的狀態
今日全部改寫後就可以使用了, 日後會多花時間在blog上撰寫文件與porting過程
日後會實做AC97 driver與 Audio Server
接著就是完成所設定目標的CLI MP3 Player
prex本身有FAT16的支援(之後有打算將fat32移植上去)
以下是開機到把SD Card上名為TEST.TXT的檔案內容印出的過程
Prex Boot Loader V1.00
loading: hdr=01c02008 module=000030e4 name=prex
loading: hdr=01c0a290 module=00003114 name=dev.ko
loading: hdr=01c0e260 module=00003144 name=boot
loading: hdr=01c0fe78 module=00003174 name=proc
loading: hdr=01c12a38 module=000031a4 name=fs
loading: hdr=01c21880 module=000031d4 name=exec
bootdisk base=01c26358 size=000128bc
kernel_entry=00010074
Entering kernel...
Prex version 0.8.1 for arm-at2440ii (Feb 9 2009)
Free pages:
start end size
-------- -------- --------
00000000 - 00010000 64K
00032c00 - 01c26000 28621K
01c39000 - 04000000 36636K
used=140K free=65321K total=65461K
Time slice is 50 msec
IRQ10 attached priority=10
Clock rate: 1000 ticks/sec
Prex driver module built: Feb 9 2009
Calibrating delay loop... ok count=837
Initializing NULL device
Initializing Power Management
pm: Default power policy is performance mode
Initializing Zero device
Initializing Serial Console
UBRDIV0:0x23
MMC check end!!
In SD ready
End id
RCA=0x9ffc
SD Frequency is 33304320Hz
In stand-by
****4bit bus****
SD disk
IRQ21 attached priority=2
Initializing TTY device
Driver initialized
Loading task:'boot'
Loading task:'proc'
Loading task:'fs'
Loading task:'exec'
Starting Bootstrap Server
Starting Process Server
Starting File System Server
Starting Exec Server
boot: Mounting file systems
VFS: Mounting ramfs dev= dir=/
VFS: Mounting devfs dev= dir=/dev
VFS: Mounting arfs dev=/dev/ram0 dir=/boot
VFS: Mounting fifofs dev= dir=/fifo
VFS: Mounting fatfs dev=/dev/card0 dir=/mnt/floppy
boot: Run init process
Prex version 0.8.1 (arm-at2440ii)
[prex:/]# cat /mnt/floppy/TEST.TXT
Hello World !!
[prex:/]#
目前使用的是處理read/write interrupt的方式完成實做
一開始是採用使用DMA方式實作, 然而碰到無法讀寫完畢
像是read counter會有尚未讀出的資料, 而停留在Rx Active的狀態
今日全部改寫後就可以使用了, 日後會多花時間在blog上撰寫文件與porting過程
日後會實做AC97 driver與 Audio Server
接著就是完成所設定目標的CLI MP3 Player
prex本身有FAT16的支援(之後有打算將fat32移植上去)
以下是開機到把SD Card上名為TEST.TXT的檔案內容印出的過程
Prex Boot Loader V1.00
loading: hdr=01c02008 module=000030e4 name=prex
loading: hdr=01c0a290 module=00003114 name=dev.ko
loading: hdr=01c0e260 module=00003144 name=boot
loading: hdr=01c0fe78 module=00003174 name=proc
loading: hdr=01c12a38 module=000031a4 name=fs
loading: hdr=01c21880 module=000031d4 name=exec
bootdisk base=01c26358 size=000128bc
kernel_entry=00010074
Entering kernel...
Prex version 0.8.1 for arm-at2440ii (Feb 9 2009)
Free pages:
start end size
-------- -------- --------
00000000 - 00010000 64K
00032c00 - 01c26000 28621K
01c39000 - 04000000 36636K
used=140K free=65321K total=65461K
Time slice is 50 msec
IRQ10 attached priority=10
Clock rate: 1000 ticks/sec
Prex driver module built: Feb 9 2009
Calibrating delay loop... ok count=837
Initializing NULL device
Initializing Power Management
pm: Default power policy is performance mode
Initializing Zero device
Initializing Serial Console
UBRDIV0:0x23
MMC check end!!
In SD ready
End id
RCA=0x9ffc
SD Frequency is 33304320Hz
In stand-by
****4bit bus****
SD disk
IRQ21 attached priority=2
Initializing TTY device
Driver initialized
Loading task:'boot'
Loading task:'proc'
Loading task:'fs'
Loading task:'exec'
Starting Bootstrap Server
Starting Process Server
Starting File System Server
Starting Exec Server
boot: Mounting file systems
VFS: Mounting ramfs dev= dir=/
VFS: Mounting devfs dev= dir=/dev
VFS: Mounting arfs dev=/dev/ram0 dir=/boot
VFS: Mounting fifofs dev= dir=/fifo
VFS: Mounting fatfs dev=/dev/card0 dir=/mnt/floppy
boot: Run init process
Prex version 0.8.1 (arm-at2440ii)
[prex:/]# cat /mnt/floppy/TEST.TXT
Hello World !!
[prex:/]#
2009年2月4日 星期三
S3C2440A - Memory Address Space
S3C2440A的Memory Address Space的分佈有兩種模式
基本上兩種模式主要的位置分佈都相同
SDRAM都是分佈在 0x30000000 ~ 0x40000000
不同的僅是 0x0 位置對應的裝置
兩種模式取決於是否使用boot from NAND FLASH
當使用Nand開機時, 0x0 對映的是 4KB 的 SRAM
而不使用Nand開機時, 0x0 對映的是 ROM
(手邊的板子是先前發售的版本, 附有2MB NOR FLASH, 新版本的目前已經不附了, 猜想u-boot是寫入NAND中)
對於S3C2440A惱人的一點就是:
無論如何DRAM的起始位置都固定於 0x30000000
而且沒有提供硬體 remap 的功能
(許多IC具有選擇將ROM or DRAM map 到 0x0 的設定, 方便開機後將ARM環境交給DRAM)
這對於後續要放置的 Exception Vector 比較麻煩
目前沒有特別測試是否SRAM內能否直接放置 Exception Vector
而若寫死後固定放入NOR中, 如此對於之後更新擴充上比較麻煩
不管系統為何都需要遷就放置NOR中寫的處理位置
如此Exception處理速度上變得是需要作兩次branch
對於效率上來說有相當的傷害, 稱不上好的方式
(網路上有人使用這種比較拖泥帶水的作法)
S3C2440A既然使用了ARM920T
具有MMU, 這就是一個漂亮簡單的解法
當使用MMU時, CPU所產生的address皆為 virtual memory address
透過MMU轉換產生physical memory address, 存取適當位置
關於ARM MMU的設定在ARM Architecture Reference Manual 中有詳細的說明
這裡只作簡單說明
ARM MMU Level 1 table 將以1MB 為單位作為對映單位, 管理4GB 定址空間
因此需要 4GB/1MB * 4 = 16KB 空間, 而alignment亦為16KB
每個Entry 有三種選擇可以設定, section, coarse, fine
section: 直接對映連續 1MB 空間 到 指定的位置
coarse: 指定level 2 table所在位置, level 2 中每個位置指定page size為 64KB/4KB 的page table的位置, table 大小為 1KB ((1MB/4KB) * 4 = 1KB), alignment為 1KB (若page size為64KB, 需要重複每個entry 16次)
fine: 在ARM VMSAv6中已經不支援此設定, 與coarse 相似, 但page size為 4KB/1KB, 而level 2 page table 大小為 4KB ((1MB/1KB)*4 = 4KB), alignment 為 4KB (若page size 為 4KB, 每個entry需要重複4次)
MMU的主要用途不用多說, 在OS教科書中都有說明
主要是透過每個中process的page table建構屬於每個process獨立的 virtual memory space
在embedded system中還有一個用法. 就是建立global page table統一管理記憶體, 解決記憶分配造成的fragmentation, 將physical address不連續的page解釋為連續的空間. 亦可以用此方式管理, 以產生physical address連續的空間提供給hardware使用
對於S3C2440A, 最簡單的方法即是建立一個global的level 1 page table, 並且使用section 方式, 將physical address 0x3000000 map到 virtual address 0x0, 即可正常處理各種exception
基本上兩種模式主要的位置分佈都相同
SDRAM都是分佈在 0x30000000 ~ 0x40000000
不同的僅是 0x0 位置對應的裝置
兩種模式取決於是否使用boot from NAND FLASH
當使用Nand開機時, 0x0 對映的是 4KB 的 SRAM
而不使用Nand開機時, 0x0 對映的是 ROM
(手邊的板子是先前發售的版本, 附有2MB NOR FLASH, 新版本的目前已經不附了, 猜想u-boot是寫入NAND中)
對於S3C2440A惱人的一點就是:
無論如何DRAM的起始位置都固定於 0x30000000
而且沒有提供硬體 remap 的功能
(許多IC具有選擇將ROM or DRAM map 到 0x0 的設定, 方便開機後將ARM環境交給DRAM)
這對於後續要放置的 Exception Vector 比較麻煩
目前沒有特別測試是否SRAM內能否直接放置 Exception Vector
而若寫死後固定放入NOR中, 如此對於之後更新擴充上比較麻煩
不管系統為何都需要遷就放置NOR中寫的處理位置
如此Exception處理速度上變得是需要作兩次branch
對於效率上來說有相當的傷害, 稱不上好的方式
(網路上有人使用這種比較拖泥帶水的作法)
S3C2440A既然使用了ARM920T
具有MMU, 這就是一個漂亮簡單的解法
當使用MMU時, CPU所產生的address皆為 virtual memory address
透過MMU轉換產生physical memory address, 存取適當位置
關於ARM MMU的設定在ARM Architecture Reference Manual 中有詳細的說明
這裡只作簡單說明
ARM MMU Level 1 table 將以1MB 為單位作為對映單位, 管理4GB 定址空間
因此需要 4GB/1MB * 4 = 16KB 空間, 而alignment亦為16KB
每個Entry 有三種選擇可以設定, section, coarse, fine
section: 直接對映連續 1MB 空間 到 指定的位置
coarse: 指定level 2 table所在位置, level 2 中每個位置指定page size為 64KB/4KB 的page table的位置, table 大小為 1KB ((1MB/4KB) * 4 = 1KB), alignment為 1KB (若page size為64KB, 需要重複每個entry 16次)
fine: 在ARM VMSAv6中已經不支援此設定, 與coarse 相似, 但page size為 4KB/1KB, 而level 2 page table 大小為 4KB ((1MB/1KB)*4 = 4KB), alignment 為 4KB (若page size 為 4KB, 每個entry需要重複4次)
MMU的主要用途不用多說, 在OS教科書中都有說明
主要是透過每個中process的page table建構屬於每個process獨立的 virtual memory space
在embedded system中還有一個用法. 就是建立global page table統一管理記憶體, 解決記憶分配造成的fragmentation, 將physical address不連續的page解釋為連續的空間. 亦可以用此方式管理, 以產生physical address連續的空間提供給hardware使用
對於S3C2440A, 最簡單的方法即是建立一個global的level 1 page table, 並且使用section 方式, 將physical address 0x3000000 map到 virtual address 0x0, 即可正常處理各種exception
S3C2440A - Clock & Power Controller
原本要撰寫SD Driver for prex, 但是看到test program中SD部份必須清楚知道PCLK
因此先花時間搞清楚S3C2440A關於Clock的設置與目前設定
這裡只列出Programmer 需要注意的地方
S3C2440A 中 Clock Controller 負責產生所需的 clock signals
包含提供給CPU的FCLK, 給AHB週邊的HCLK, 給APB週邊的PCLK
S3C2440A 有兩組PLL, 一組提供FCLK, HCLK, PCLK, 另一組提供給USB(48MHz)
這裡Clock Manager的設定將直接影響到CPU 頻率與後續需要注意PCLK的週邊(Ex:UART, Timer, SD )的設定
手邊的AT2440-II 使用的 oscillator freq = 16.9344 Mhz
輸出頻率取決於 M/P/S divider
Mpll = (2*m*Fin)/(p*(2^s))
m = M (the value for divider M)+ 8, p = P (the value for divider P) + 2
文件列出了數種設定組合方便programmer 使用
Output Freq. MDIV PDIV SDIV
47.98 MHz 60(0x3c) 4 2
95.96 MHz 60(0x3c) 4 1
266.72 MHz 118(0x76) 2 2
296.35 MHz 97(0x61) 1 2
399.65 MHz 110(0x6e) 3 1
530.61 MHz 86(0x56) 1 1
533.43 MHz 118(0x76) 1 1
(47.98/95.96 為 48/96近似值, 提供USB使用 (48Mhz) )
而HCLK/PCLK 取決於 CLKDIVN 中的HDIVN 與 PDIVN
HCLK 可為 1, 1/2, 1/3, 1/4, 1/6, 1/8 FCLK
PCLK 可為 1, 1/2 HCLK
UCLK 可為 1, 1/2 UPLL
測試後顯示, 板上的u-boot boot後設定值為 399.65Mhz
(Mpll = (2*(110+8)*16.9344)/((3+2)*2) = 399.65184 Mhz )
此外Clock Controller 提供四種模式
Four Modes
* Normal:
Clock Controller提供CPU, 週邊 clocks
當啟動所有週邊, 功耗將達到最大值
* Slow :
Non-PLL模式, 使用外部clock (XTIpll or EXTCLK)作為FCLK
* Idle :
停止提供FLCK給CPU, 僅提供週邊
* Sleep :
停止內部電源, 除了wake-up 電路, 其他部份皆無電源消耗
因此先花時間搞清楚S3C2440A關於Clock的設置與目前設定
這裡只列出Programmer 需要注意的地方
S3C2440A 中 Clock Controller 負責產生所需的 clock signals
包含提供給CPU的FCLK, 給AHB週邊的HCLK, 給APB週邊的PCLK
S3C2440A 有兩組PLL, 一組提供FCLK, HCLK, PCLK, 另一組提供給USB(48MHz)
這裡Clock Manager的設定將直接影響到CPU 頻率與後續需要注意PCLK的週邊(Ex:UART, Timer, SD )的設定
手邊的AT2440-II 使用的 oscillator freq = 16.9344 Mhz
輸出頻率取決於 M/P/S divider
Mpll = (2*m*Fin)/(p*(2^s))
m = M (the value for divider M)+ 8, p = P (the value for divider P) + 2
文件列出了數種設定組合方便programmer 使用
Output Freq. MDIV PDIV SDIV
47.98 MHz 60(0x3c) 4 2
95.96 MHz 60(0x3c) 4 1
266.72 MHz 118(0x76) 2 2
296.35 MHz 97(0x61) 1 2
399.65 MHz 110(0x6e) 3 1
530.61 MHz 86(0x56) 1 1
533.43 MHz 118(0x76) 1 1
(47.98/95.96 為 48/96近似值, 提供USB使用 (48Mhz) )
而HCLK/PCLK 取決於 CLKDIVN 中的HDIVN 與 PDIVN
HCLK 可為 1, 1/2, 1/3, 1/4, 1/6, 1/8 FCLK
PCLK 可為 1, 1/2 HCLK
UCLK 可為 1, 1/2 UPLL
測試後顯示, 板上的u-boot boot後設定值為 399.65Mhz
(Mpll = (2*(110+8)*16.9344)/((3+2)*2) = 399.65184 Mhz )
此外Clock Controller 提供四種模式
Four Modes
* Normal:
Clock Controller提供CPU, 週邊 clocks
當啟動所有週邊, 功耗將達到最大值
* Slow :
Non-PLL模式, 使用外部clock (XTIpll or EXTCLK)作為FCLK
* Idle :
停止提供FLCK給CPU, 僅提供週邊
* Sleep :
停止內部電源, 除了wake-up 電路, 其他部份皆無電源消耗
2009年2月2日 星期一
S3C2440A
瞭解硬體的功能特性對於撰寫移植或是撰寫embedded system是必要的
選擇S3C2440A的原因, 僅只是因為向友人借的EVB使用的是這顆IC
詳細的datasheet可以到此下載
簡單敘述S3C2440A的硬體特性為:
另外建議手邊有著下列書目以便參考使用
選擇S3C2440A的原因, 僅只是因為向友人借的EVB使用的是這顆IC
詳細的datasheet可以到此下載
簡單敘述S3C2440A的硬體特性為:
- ARM920T core
- AC97 codec
- SD interfacce
- RTC
- USB Host/Device controller
- LCD controller
- Uart
另外建議手邊有著下列書目以便參考使用
- ARM Architecture Reference Manual 2/e (ARM官網這裡有免費的第一版)
- ARM System Developer's Guide
- ARM Procedure Call Standard (ARM's Calling Convention)
前言
拋開可以查閱Wiki或是IEEE而來的無聊制式定義
每個資訊從業人員對於embedded system都有著或深或淺的認知, 而各自有著用以理解它的一套思維. 然而除了親自去trace一窺究竟, 更甚者去coding之後, 才能深刻體會其中所充斥的挫折與饒富的樂趣所在.
不得已而接觸它的人可能會覺得複雜, 麻煩, 不知所以, 沒有規則; 樂在其中的人卻也喜於享受它的多種樣貌,抽絲剝繭的趣味, 欣賞巧奪天工的設計, 或是一手掌握的成就感. 是的, embedded system就是這麼樣地讓人又愛又恨.
對於許多人而言, 在desktop 上使用SDK, 熟悉的語言加上各式的library/framewrk, 從coding, compilation, linking產生程式到 load-in & execute 的一氣呵成, 一切是那麼方便, 是那麼的理所當然.如此一來, 那些曾囫圇吞棗背念的computer organization/architecture, compiler, system Ssoftware, operating systems, 在現今分工細膩且功能完善的OS與toolkit中, 似乎還顯得有些多餘. 的確, 現今Linux/Windows這樣desktop-oriented的OS也走入了embedded system領域, 但即便有心深入, 不考慮封閉性, 對大多數人來說, 無論Linux/Windows都顯得過於龐大且複雜. 對於系統著實難以一窺其精妙, 例如想把Linux Virtual Memory Management看到有所心得是一件不小的工程, 這樣作有時也難免有著見樹不見林的缺憾. 而使用Linux/Windows的硬體成本較高, 在應用上也有不適合的時候.
如此說法, 並非是要拋棄Linux/Windows, 一切要從頭來過.
畢竟在許多方面有其應用層面的考量. 而embedded system的樂趣之一在於, 透過實作所獲得的應用性外, 經由設計良好具體而微的embedded system也能夠讓自己更瞭解整體系統, 自硬體平台到軟體系統的設計與來龍去脈也能夠有更深一層的認知. 如此即便再面對Linux/Windows也有不同層次的心得, 或有提綱見領之效. 也因為如此, 反過來說, 面對embedded system, 對於軟硬體所需要的瞭解與面對的問題更甚於開發一般desktop application.
每個資訊從業人員對於embedded system都有著或深或淺的認知, 而各自有著用以理解它的一套思維. 然而除了親自去trace一窺究竟, 更甚者去coding之後, 才能深刻體會其中所充斥的挫折與饒富的樂趣所在.
不得已而接觸它的人可能會覺得複雜, 麻煩, 不知所以, 沒有規則; 樂在其中的人卻也喜於享受它的多種樣貌,抽絲剝繭的趣味, 欣賞巧奪天工的設計, 或是一手掌握的成就感. 是的, embedded system就是這麼樣地讓人又愛又恨.
對於許多人而言, 在desktop 上使用SDK, 熟悉的語言加上各式的library/framewrk, 從coding, compilation, linking產生程式到 load-in & execute 的一氣呵成, 一切是那麼方便, 是那麼的理所當然.如此一來, 那些曾囫圇吞棗背念的computer organization/architecture, compiler, system Ssoftware, operating systems, 在現今分工細膩且功能完善的OS與toolkit中, 似乎還顯得有些多餘. 的確, 現今Linux/Windows這樣desktop-oriented的OS也走入了embedded system領域, 但即便有心深入, 不考慮封閉性, 對大多數人來說, 無論Linux/Windows都顯得過於龐大且複雜. 對於系統著實難以一窺其精妙, 例如想把Linux Virtual Memory Management看到有所心得是一件不小的工程, 這樣作有時也難免有著見樹不見林的缺憾. 而使用Linux/Windows的硬體成本較高, 在應用上也有不適合的時候.
如此說法, 並非是要拋棄Linux/Windows, 一切要從頭來過.
畢竟在許多方面有其應用層面的考量. 而embedded system的樂趣之一在於, 透過實作所獲得的應用性外, 經由設計良好具體而微的embedded system也能夠讓自己更瞭解整體系統, 自硬體平台到軟體系統的設計與來龍去脈也能夠有更深一層的認知. 如此即便再面對Linux/Windows也有不同層次的心得, 或有提綱見領之效. 也因為如此, 反過來說, 面對embedded system, 對於軟硬體所需要的瞭解與面對的問題更甚於開發一般desktop application.
訂閱:
文章 (Atom)
在 ARM 平台上使用 Function Multi-Versioning (FMV) - 以使用 Android NDK 為例
Function Multi-Versioning (FMV) 過往的 CPU 發展歷程中, x86 平台由於因應各種應用需求的提出, 而陸陸續續加入了不同的指令集, 此外也可能因為針對市場做等級區隔, 支援的數量與種類也不等. 在 Linux 平台上這些 CPU 資訊可以透過...
-
在 Halide 的使用上會有錯覺地認為 Halide::Runtime::Buffer 的使用必須與 libHalide.so or libHalide.a linking 才可以. 但其實 Halide::Runtime::Buffer 是可以單獨使用的, 只需要 head...
-
現今對於 Daily Linux Developer / User 面對不同程式/開發版本環境感到很頭疼, 常常疲於 執行舊版程式需要安裝舊版本 Library, 設定 RPATH / LD_LIBRARY_PATH 開發需求建立不同的版本 SDK 開發/執行環境, 在較舊系統...
-
在講解 680 中的 SIMD 單元 - HVX 之前, 還是先以 系列文 I 的 blocks diagram開頭, 並且今日重點會是文中提到第3點的官方文件 從 blocks diagram 中可以看到 HVX 由三個主要部分所組成 VX : Vector ...