大家一起來玩 Linux

I2C master (adapter) device driver

2017-02-25T11:44:00.003+08:00

在 Linux kernel I2C device driver 中稱呼 master 為 adapter, 每一個 I2C bus 中只能有一個 master, 而在 embedded 系統中通常是 SoC 內建, 一樣受 I2C core 中所管理, 另外在 i2c_dev.c 中會為每一個 master 建立一個 device node 為 /dev/i2c-xxx 其中 xxx 為 bus number, 應用程式可以使用這個 device node 控制 master 收送資料, 進而可以取代 client device driver。

資料結構

struct i2c_adapter {
       struct module *owner;
       unsigned int class; /* classes to allow probing for */
       const struct i2c_algorithm *algo; /* the algorithm to access the bus */
       void *algo_data;
       /* data fields that are valid for all devices */
       struct rt_mutex bus_lock;
       int timeout; /* in jiffies */
       int retries;
       struct device dev; /* the adapter device */
       int nr;
       char name[48];
       struct completion dev_released;
       struct mutex userspace_clients_lock;
       struct list_head userspace_clients;
       struct i2c_bus_recovery_info *bus_recovery_info;
       const struct i2c_adapter_quirks *quirks;
};
#define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev) // d is device

以上是在驅動一開始要註冊時所需資料結構, 其內容需給予準備好以備註冊一個 master (adapter) device driver, 其中有一個 algo member 為收送資料的 call back function, 通常是讓 client 驅動所呼叫

algo 資料結構

struct i2c_algorithm {
     /* If an adapter algorithm can't do I2C-level access, set master_xfer
          to NULL. If an adapter algorithm can do SMBus access,
          smbus_xfer. If set to NULL, the SMBus protocol is
          using common I2C messages */
     /* master_xfer should return the number of messages
       processed, or a negative value on error */
         int (*master_xfer)(struct i2c_adapter *adap, struct i2c_msg *msgs,
                                         int num);
         int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr
                              unsigned short flags, char read_write
                              u8 command, int size, union i2c_smbus_data *data);
     /* To determine what the adapter supports */
          u32 (*functionality) (struct i2c_adapter *);
#if IS_ENABLED(CONFIG_I2C_SLAVE)
           int (*reg_slave)(struct i2c_client *client);
           int (*unreg_slave)(struct i2c_client *client);
#endif
};

其中的 master_xfer & smbus_xfer 就是給 client 驅動所呼叫的 call back function 來收送資料

I2C core 所提供 Kernel API

#include <linux/i2c.h> // 驅動需要的 include file
static inline void *i2c_get_adapdata(const struct i2c_adapter *dev) // 使用 i2c_adapter 的資料結構來取得你自行設定的私有資料結構
static inline void i2c_set_adapdata(struct i2c_adapter *dev, void *data)// 使用 i2c_adapter 的資料結構來設定你自行設定的私有資料結構
void i2c_lock_adapter(struct i2c_adapter *); // 鎖定這個 adapter bus, 以確保只有一個人在收送資料, 這是一個很重要的動作, 因為 I2C
void i2c_unlock_adapter(struct i2c_adapter *); // 解鎖 adapter bus, 這必需和上面的鎖定成對使用
static inline struct i2c_adapter *i2c_parent_is_i2c_adapter(const struct i2c_adapter *adapter) // 取得上一層的 adapter data, 這在如果有多工器時會更需要用到
extern int i2c_add_adapter(struct i2c_adapter *); // 增加一個 adapter or master, 這不指定 bus number, 由系統自動 assign
extern void i2c_del_adapter(struct i2c_adapter *); // 移除一個 adapter
extern int i2c_add_numbered_adapter(struct i2c_adapter *); // 增加一個指定 bus number 的 adapter
int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num); // 這是給 client 驅動所呼叫的的程式來要求 adapter 收送資料給 client, 而 master 則是轉成呼叫上面所提的 master_xfer & smbus_xfer call back function

範例 - id table
static const struct of_device_id mv64xxx_i2c_of_match_table[] = {
       { .compatible = "allwinner,sun4i-a10-i2c", .data = &mv64xxx_i2c_regs_sun4i},
       { .compatible = "allwinner,sun6i-a31-i2c", .data = &mv64xxx_i2c_regs_sun4i},
       { .compatible = "marvell,mv64xxx-i2c", .data = &mv64xxx_i2c_regs_mv64xxx},
       { .compatible = "marvell,mv78230-i2c", .data = &mv64xxx_i2c_regs_mv64xxx},
       { .compatible = "marvell,mv78230-a0-i2c", .data = &mv64xxx_i2c_regs_mv64xxx},
     {} // 一定要有這個做為結束
};
MODULE_DEVICE_TABLE(of, mv64xxx_i2c_of_match_table);

adapter algo example

static int
mv64xxx_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
{
      struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap);
      // just do it
      // return how many messages are sent
}

static u32
mv64xxx_i2c_functionality(struct i2c_adapter *adap)
{
       return I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR | I2C_FUNC_SMBUS_EMUL;
}

static const struct i2c_algorithm mv64xxx_i2c_algo = {
       .master_xfer = mv64xxx_i2c_xfer,
       .functionality = mv64xxx_i2c_functionality,
};

example – probe call back function

static int mv64xxx_i2c_probe(struct platform_device *pd) {
     // prepare i2c_adapter data structure
     adapter.name= “myname”;
     adapter.timeout = msecs_to_jiffies(timeout);
     adapter.dev.parent = &pd->dev;
     adapter.algo = &mv64xxx_i2c_algo;
     adapter.owner = THIS_MODULE;
     adapter.class = I2C_CLASS_DEPRECATED;
     adapter.nr = pd->id; // bus number
     adapter.dev.of_node = pd->dev.of_node;
     // call i2c_add_numbered_adapter(&adapter)

}

example – remove call back function & driver register

static int mv64xxx_i2c_remove(struct platform_device *dev) {};
static struct platform_driver mv64xxx_i2c_driver = {
       .probe = mv64xxx_i2c_probe,
       .remove = mv64xxx_i2c_remove,
       .driver = {
               .name = MV64XXX_I2C_CTLR_NAME,
               .of_match_table = mv64xxx_i2c_of_match_table,
       },
};
module_platform_driver(mv64xxx_i2c_driver);

如何加入一個 slave device

可以在 device tree 中描述，並準備好驅動程式即可，以下為範例：
i2c0: i2c@11000 {
                               pinctrl-names = "default";
                               pinctrl-0 = <&i2c0_pins>;
                               // timeout-ms = <3000>;

                               eeprom@50 {
                                       compatible = "atmel,24c64";
                                       pagesize = <32>;
                                       reg = <0x50>;
                                       marvell,board_id_reg = <0x7>;
                               };

                               rtc@6f {
                                       compatible = "isl,isl1208";
                                       reg = <0x6f>;
                               };

                               moxaeds-i2c-mux@08 {
                                       compatible = "moxa,moxaeds-i2c-mux";
                                       reg = <0x08>;
                               };

};

可以在 adapter (master) 驅動中加入，以下為範例：
static int moxaeds_create_client(struct moxaeds_priv_struct *priv, u32 addr, const char *type, int index)
{
       struct i2c_board_info info;
       struct dev_archdata dev_ad;
　   memset(&info, 0, sizeof(info));
       memset(&dev_ad, 0, sizeof(dev_ad));
       info.addr = addr;
       if ( addr > 0x7f )
               info.flags |= I2C_CLIENT_TEN; // for 10 bits address slave device
       strncpy(info.type, type, I2C_NAME_SIZE);
       info.archdata = &dev_ad;
       priv->client[index] = i2c_new_device(priv->madap, &info);
       if ( priv->client[index] == NULL )
               return -ENODEV;
   　return 0;
}
ret = moxaeds_create_client(fpga9_son_priv[busnum], 0x50, "24c64", EEPROM_CLIENT);

I2C client 端驅動程式

2017-02-05T23:33:00.001+08:00

以上為在 Linux Kernel 中的軟體架構, 其主要分為幾部分:

I2C core 為核心程式, 也是管理程式, 做為和 kernel 之間其它驅動要收送 I2C 資炓的介面
I2C client 為各個 I2C client 端元件的驅動式, 必須透過 I2C core 來通知 I2C master 收送資料給自己
I2C master 為 I2C master 的驅動, 提供給 I2C core 讓 I2C client 來收送資料
I2C multiplexer 在同一個 I2C master 之下的 bus, 不能有重覆的 I2C client address, 但有時需要使用多個相同 I2C client 時就需要 I2C multiplexer 來做切換的動作, 而在 multiplexer 中會建立多個 virtual master (adapter)
I2C slave 其實和 I2C client 一樣, 都是 client 端驅動程式, 只是這類的驅動會使用 event 的方式來做收送資料, 這類驅動較少使用

I2C bus 是一個 master/slave 的網路架構, 一切的收送均需由 master 來做控制, 而其通訊方式其實是一種 broadcast 的方式, 所以每一個 client (slave) 都會有一個位址來辨認, 所以 client 端的驅動必需要透過 I2C core 來通知 master 的驅動收送資料, 而 client 端的驅動程式則知道自已本身要如何控制, 所以才會有 client 端的驅動程式。

source code directory in kernel source code root

kernel-source/drivers/i2c

busses 目錄放 master device driver
muexs 目錄放 multiplexer device driver
algos 目錄放演算法或協議 device driver
i2c-core.c i2c 核心程式
i2c-dev.c 建立 bus master device node 以及介面程式
i2c-mux.c 處理 multiplexer 的核心程式
i2c-boardinfo.c 提供建立 i2c board information 的程式 (這是較舊的做法, 現在通常使用 device tree)

使用時機

原則上 slave 端的元件才是我們要使用的元件, 如 EEPROM
client 資料結構中含 adapter data

i2c_client 資料結構說明

/**
* struct i2c_client - represent an I2C slave device
* @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
* I2C_CLIENT_PEC indicates it uses SMBus Packet Error Checking
* @addr: Address used on the I2C bus connected to the parent adapter.
* @name: Indicates the type of the device, usually a chip name that's
* generic enough to hide second-sourcing and compatible revisions.
* @adapter: manages the bus segment hosting this I2C device
* @dev: Driver model device node for the slave.
* @irq: indicates the IRQ generated by this device (if any)
* @detected: member of an i2c_driver.clients list or i2c-core's
* userspace_devices list
* @slave_cb: Callback when I2C slave mode of an adapter is used. The adapter
* calls it to pass on slave events to the slave driver.
*
* An i2c_client identifies a single device (i.e. chip) connected to an
* i2c bus. The behaviour exposed to Linux is defined by the driver
* managing the device.
*/
PS: 這個資料結構在 client 端註冊的 probe call back function 中會傳給它

struct i2c_client {
       unsigned short flags; /* div., see below */
       unsigned short addr; /* chip address - NOTE: 7bit */
                                       /* addresses are stored in the */
                                       /* _LOWER_ 7 bits */
       char name[I2C_NAME_SIZE];
       struct i2c_adapter *adapter; /* the adapter we sit on */
       struct device dev; /* the device structure */
       int irq; /* irq issued by device */
       struct list_head detected;
#if IS_ENABLED(CONFIG_I2C_SLAVE)
       i2c_slave_cb_t slave_cb; /* callback for slave mode */
#endif

};

#define to_i2c_client(d) container_of(d, struct i2c_client, dev)

PS: 其中 I2C_NAME_SIZE 目前定義為 20

i2c_driver 資料結構說明
* struct i2c_driver - represent an I2C device driver
* @class: What kind of i2c device we instantiate (for detect)
* @attach_adapter: Callback for bus addition (deprecated)
* @probe: Callback for device binding
* @remove: Callback for device unbinding
* @shutdown: Callback for device shutdown
* @alert: Alert callback, for example for the SMBus alert protocol
* @command: Callback for bus-wide signaling (optional)
* @driver: Device driver model driver
* @id_table: List of I2C devices supported by this driver
* @detect: Callback for device detection
* @address_list: The I2C addresses to probe (for detect)
* @clients: List of detected clients we created (for i2c-core use only)
* The driver.owner field should be set to the module owner of this driver.
* The driver.name field should be set to the name of this driver.
* For automatic device detection, both @detect and @address_list must be defined.
* @class should also be set, otherwise only devices forced with module parameters
* will be created. The detect function must fill at least the name field of
* the i2c_board_info structure it is handed upon successful detection, and possibly
* also the flags field. If @detect is missing, the driver will still work fine for enumerated
* devices. Detected devices simply won't be supported. This is expected
* for the many I2C/SMBus devices which can't be detected reliably, and
* the ones which can always be enumerated in practice.
* The i2c_client structure which is handed to the @detect callback is
* not a real i2c_client. It is initialized just enough so that you can
* call i2c_smbus_read_byte_data and friends on it. Don't do anything
* else with it. In particular, calling dev_dbg and friends on it is not allowed.

struct i2c_driver {
       unsigned int class;
       /* Notifies the driver that a new bus has appeared. You should avoid
        * using this, it will be removed in a near future. */
       int (*attach_adapter)(struct i2c_adapter *) __deprecated;
       /* Standard driver model interfaces */
       int (*probe)(struct i2c_client *, const struct i2c_device_id *);
       int (*remove)(struct i2c_client *);
       /* driver model interfaces that don't relate to enumeration */
       void (*shutdown)(struct i2c_client *);
       /* Alert callback, for example for the SMBus alert protocol.
        * The format and meaning of the data value depends on the protocol.
        * For the SMBus alert protocol, there is a single bit of data passed
        * as the alert response‘s low bit (“event flag”). */
       void (*alert)(struct i2c_client *, unsigned int data);
       /* a ioctl like command that can be used to perform specific functions
        * with the device. */
       int (*command)(struct i2c_client *client, unsigned int cmd, void *arg);
       struct device_driver driver;
       const struct i2c_device_id *id_table;
       /* Device detection callback for automatic device creation */
       int (*detect)(struct i2c_client *, struct i2c_board_info *);
       const unsigned short *address_list;
       struct list_head clients;
};

#define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)

PS: 在 I2C client 端的驅動程式, 必需宣告這個資料, 其中 probe & remove 兩個 call back function 為必需實做的兩個 call back function, 另外 id_table 也是需要宣告的, 以下會有範例說明

I2C core 所提供的 API for client driver

#include <Linux/i2c.h>

int i2c_register_driver(struct module *, struct i2c_driver *); // 註冊一個 client 端驅動, 通常在module_init 中呼叫
void i2c_del_driver(struct i2c_driver *); // 移除一個 client 諯驅動, 通常在 module_exit 中呼叫
#define i2c_add_driver(driver) \ // 簡化上面的 API
i2c_register_driver(THIS_MODULE, driver)
module_i2c_driver(moxaeds_driver); // 簡化 module_init & module_exit

probe call back function example

static int moxaeds_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct i2c_adapter *adap=to_i2c_adapter(client->dev.parent); // my parent master
enum si5351_variant variant = (enum si5351_variant)id->driver_data; // get private data which from id table defined

// allocate private data and initialize it

// initialize hardware

// keep got client data, 就是將傳進來的 client 資料存在 local, 因為後面整個驅動都會用到

return 0;
}

remove call back function example

static int moxaeds_remove(struct i2c_client *client)
{

// release all resource

return 0;
}

id table example in driver

static const struct i2c_device_id moxaeds_id[] = {
{"moxaeds-i2c-mux", 0 /* private data */}, // 若有很多個, 可以再加
{} // 一定要加這個為結束
};
MODULE_DEVICE_TABLE(i2c, moxaeds_id);

device tree example in driver

static const struct of_device_id si5351_dt_ids[] = {
       { .compatible = "silabs,si5351a", .data = (void *)SI5351_VARIANT_A /* private data */, },
       { .compatible = "silabs,si5351a-msop", .data = (void *)SI5351_VARIANT_A3 /* private data */, },
       { .compatible = "silabs,si5351b", .data = (void *)SI5351_VARIANT_B /* private data */, },
       { .compatible = "silabs,si5351c", .data = (void *)SI5351_VARIANT_C /* private data */, },
       { } // 一定要加這個為結束
};

MODULE_DEVICE_TABLE(of, si5351_dt_ids);

device tree example in device tree file
i2c0: i2c@11000 {
         pinctrl-names = "default";
         pinctrl-0 = <&i2c0_pins>;
         // timeout-ms = <3000>;
         /* hardware change to connect after FPAG#9 bus 15
         eeprom@50 {
                 compatible = "atmel,24c64"; // 這是上面 driver 中宣告的 device tree, ',' 之後名字最多20字母
                 pagesize = <32>;
                 reg = <0x50>; // 這是 i2c client address
                 marvell,board_id_reg = <0x7>;
        };
        rtc@6f {
                 compatible = "isl,isl1208"; // 這是上面 driver 中宣告的 device tree
                 reg = <0x6f>; // 這是 i2c client address
        };
        */
        moxaeds-i2c-mux@08 {
                 compatible = "moxa,moxaeds-i2c-mux"; // 這是上面 driver 中宣告的 device tree
                 reg = <0x08>; // 這是 i2c client address
        };
};

另一個 device tree example in device tree file
&i2c0 {
       status = "okay";
       clock-frequency = <100000>;
       si5351: clock-generator {
             compatible = "silabs,si5351a-msop";
               reg = <0x60>;
               #address-cells = <1>;
               #size-cells = <0>;
               #clock-cells = <1>;
               /* connect xtal input to 25MHz reference */
               clocks = <&ref25>;
               clock-names = "xtal";
               /* connect xtal input as source of pll0 and pll1 */
               silabs,pll-source = <0 0>, <1 0>;
               clkout0 {
                       reg = <0>;
                       silabs,drive-strength = <8>;
                       silabs,multisynth-source = <0>;
                       silabs,clock-source = <0>;
                       silabs,pll-master;
               };
               clkout2 {
                       reg = <2>;
                       silabs,drive-strength = <8>;
                       silabs,multisynth-source = <1>;
                       silabs,clock-source = <0>;
                       silabs,pll-master;
               };
       };
};

上面所提 i2c_driver 資料結構範例

static struct i2c_driver moxaeds_driver = {
       .driver = {
               .name = "moxaeds-i2c-mux",
               .owner = THIS_MODULE,
               .of_match_table = of_match_ptr(si5351_dt_ids), // my device tree
       },
       .probe = moxaeds_probe, // 參考前面的範
       .remove = moxaeds_remove, // 參考前面的範
       .id_table = moxaeds_id, // my id table
};

module_init & module_exit example

#if 0 // if you want to debug module initialize function enable here
static int __init moxaeds_init(void)
{
       dgprintk(HIGH_DEBUG_LEVEL, "\n");
       return i2c_add_driver(&moxaeds_driver);
}
module_init(moxaeds_init);

static void __exit moxaeds_exit(void)
{
       dgprintk(HIGH_DEBUG_LEVEL, "\n");
       i2c_del_driver(&moxaeds_driver);
}
module_exit(moxaeds_exit);
#else
module_i2c_driver(moxaeds_driver); // to use i2c module initialize macro
#endif

如何傳送資料在 client 端驅動

call i2c_transfer() or __i2c_transfer(), 前面一個會幫忙做 lock bus 的動作, 可避免同時有在存取相同的 bus master, 而後面的則不會, 必需使用者自己做 lock 的動作
範例如下：
struct i2c_msg msg[2];
u8 tbuf[4], rbuf[4];
int ret;
msg[0].addr = moxaeds_client_fpga->addr;
msg[0].flags = 0;
msg[0].len = 1;
msg[0].buf = tbuf;
tbuf[0] = FPGA_SET_BIT_MAP_REG_NO;
msg[1].addr = moxaeds_client_fpga->addr;
msg[1].flags = I2C_M_RD;
msg[1].len = 2;
msg[1].buf = rbuf;
ret = i2c_transfer(moxaeds_master_adap, msg, 2); // called i2c_transfer(), not __i2c_transfer(),
if ( ret != 2 ) {
myprintk("Read bit map register fail [%d] !\n", ret);
return 0;
}

return sprintf(buf, "0x%02x%02x", rbuf[0], rbuf[1]);

// 其中在 i2c_transfer 中第一個參數 moxaeds_master_adap, 在前面所提 probe call back function 所傳進來的 client 中其中的 member

I2C 硬體了解

2017-02-02T22:54:00.002+08:00

What is I2C (Inter-IC) ?

它是一種半雙工的串列式 bus
它是一種廣播式的 bus
三種通訊速度

Standard is 100 Kbps
Fast-mode is 400 Kbps
High-speed mode supports speeds up to 3.4 Mbps

supports 7-bits and 10-bits address
Master-slave communication
每一個 slave 都會給一個特定位址, 對於 7-bits address 只能 0x08 ~ 0x77, 10-bits address 可以設定 0x77 以後
假如 slave address 有相同, 硬體上則可能會使用多工器來切換

硬體實際接法

硬體訊號

•When the bus is free, both lines are HIGH.
• The data on the SDA line must be stable during the HIGH period of the clock.
• The HIGH or LOW state of the data line can only change when the clock signal on the SCL line is LOW.

Start and Stop conditions

•A HIGH to LOW transition on the SDA line while SCL is HIGH is one such unique case. This situation indicates a START condition.
• A LOW to HIGH transition on the SDA line while SCL is HIGH defines a STOP condition.
• START and STOP conditions are always generated by the master.
• The bus is considered to be busy after the START condition.
• The bus is considered to be free again a certain time after the STOP condition.

Data Format
•Every byte put on the SDA line must be 8-bits long.
• Each byte has to be followed by an acknowledge bit.

Link level protocol

Address table

Two groups of eight addresses (0000XXX and 1111XXX) are reserved for the purposes

寫驅動程式所需的技能

2014-12-12T16:31:00.001+08:00

我個人寫過很多種作業系統的驅動程式，但是寫驅動程式對一般寫程式的人員而言是一個非常神秘的事，不知道如何著手，也不知道需要那些技能，這邊就來談談這方面的事，好讓有心要寫驅動程式的人員才知道如何準備。

首先當然 C 要很熟，以前的人在寫 Linux 驅動程式時總是喜歡用較艱深的語法來寫，造成其他的人很難理解，現在則是𣎴會這樣了，大家都會用較簡易的方式來寫，所以如何來檢視自己的 C 是否熟悉，找出 Linux 驅動程式一個約有 100 行的程式碼，在10～20 分鐘之內將其看完，即可了解其程式羅輯，甚至其中若有錯誤也可將其指出，以及該程式的優缺點，那你的 C 就夠熟了。再者驅動程式中用很多的 function pointer 以及資料結構，另外對 pointer 也用的很多，所以這方面的 C 都要很熟悉，將會對於寫驅動程式有很大的幫助。

再來需要的技能就比較有點麻煩，因為是寫驅動程式，所以對硬體要有一點認識，舉例來說如果你要寫的是硬碟驅動程式，你當然得對硬碟的一些硬體動作或者行為必須有所了解，因為驅動程式就是在控制硬體行為，如此你才能知道如何去控制硬體才是正確的，又如你寫的是 Ethernet 驅動程式，你必須對於 Ethernet 的硬體行為以及基本的操作要有所了解，如此當你在寫它的驅動程式時，才能了解為何其硬體行為如何，出來的結果才知道正確或不正確，再者對於通訊協議的驅動程式，你可能對其協議內容也要有所了解，這樣對正確性以及除錯都有所幫助，另外在做自我測試時才能知道如何架設測試環境，所有的軟體一定都要經過嚴謹的測試，才能確定其一定的正確性，尤其是在硬體的驅動程式，因為硬體有相容性的問題，而這些問題可能都需要經過軟體，以及硬體環境的架設才能得到正確的測試，而對硬體的了解都有助於你開發驅動程式的優質化。

另外的一個知識則是對作業系統的了解，驅動程序它要利用 kernel 所提供的 API 來和系統合作，所以它也可以說是作業系統的一部分，而且它是運行在系統中，因此如果驅動寫的不好，是會造成系統當掉，或者不穩定等等，所以對於該系統的一些內部行為要有所了解，如此也才能和系統好好地合作。另外一個的知識是系統了解，是在開完機之後的系統了解，如何設定系統，如果你的驅動程式是給系統管理用的，那你就要了解如何使用它，如此測試才能確保你的驅動是正確的，你也必須很清楚地了解，你的驅動程式到底是在何時載入系統的，這樣才能確保它可以正常地運行你的驅動程式。

這時則是我們最常説的，需要了解作業業系統的驅動程式要如何撰寫，每個作業系統的驅動程式架構都不太一樣，所以我們必須去了解它，但是在Linux中有一個好處，就是你可以取得所有的驅動程式原始碼，因此你可以參考其他人的程式，方便你快速了解，再者驅動程式所呼叫的API，和應用程式完全不同，因此你需要全部重新了解以及知道。

最後則是應用程式的了解，也就是要會寫應用程式來測試你的驅動程式，前面有提過驅動程式通常是給應用程式用的，為了要確保你的驅動程式是没有問題，你必須自己先寫一些應用測試程式來測你的驅動程式，當然如果你所在的單位有專門的測試單位，你可以讓測試單位來協助你測試，不過我還是建議自己還是先測試有没有問題，再交給測試單位測試，我想這是對自己的程式負責的態度。

結論我再一次條例式列出寫驅程式所需的技巧：

C 語言的熟悉
作業系統的了解
硬體的了解
了解如何撰寫驅動程式
作業系統的操作的了解
應用程式的撰寫

以上是我個人認為要寫好一個驅動程式所必要的條件，通常我們要會寫一個驅動程式不太難，但是要寫好一個驅動程式就不太容易，所謂一個好的驅動程式，有幾個必要條件，第一要穩定，就是在任何情況下都不會當掉，第二就是要好維護，不要讓後面接手的人看不懂你的程式，也不知道要如何修改，第三就是要容易除錯，最後希望大家都能夠寫好一個驅動程式。

如何撰寫在Linux Kernel 2.6.x的GPIO驅動程式

2012-09-02T16:06:00.004+08:00

前言

GPIO是目前SoC常常會使用到的一個元件，以往的GPIO使用上並不普遍，所以在Linux Kernel並未加以統一寫法，因此以往的寫法則各家自行撰寫，比較多的是架構在misc的驅動之下，但今日新的Linux Kernel則有給予新的統一做法，它讓kernel中有要用GPIO的其它驅動程式可以透過其定義的library API來使用，而GPIO本身則實現其實體層的控制就好，如此一來其它使用GPIO的驅動則在porting更容易了。

什麼是GPIO

對於GPIO我們要先有一些了解，GPIO – Generic Program Input Output，中文說法是可程式輸出輸入的控制訊號，意思是該點可以設定為input或者output訊號，而其輸出的訊號則是單純的數位訊號，不是high就是low，而輸入訊號的偵測也是一樣，而其電位則是TTL訊號，而這樣的東西，通常可以例如模擬I2C HOST，或者拿來讀取RTC的介面，又或接一個LED當做某些事件的指示使用。

Kernel中的GPIO Library

還没有寫驅動程式之前，我們先來了解這個library，它是最近的Linux kernel版本所定義的，是給其它需要用到GPIO的驅動程式所使用，意思就是在Kernel內部定義了義標準的GPIO Library API，如此一來對需要使用到GPIO的驅動程式便可以不用理會其底層的GPIO，也不會因平台不同而各家自行所定義的GPIO API而造成上層的驅動程式而跟著修改，我們可以用以下的軟體加構圖來了解其中的做法：

目前定義較常用的Kernel API有如下：

int gpio_direction_output(unsigned gpio, int value);

這是設定該GPIO為output，第一個參數為GPIO number，第二個參數則是設定其為輸出時的初始值。

int gpio_set_value(unsigned gpio, int value);

這是針對己經設為output的GPIO設定其值為high或者為low。

int gpio_direction_input(unsigned gpio);

這是設定該GPIO為input。

int gpio_get_value(unsigned gpio);

這是針對己設為input的GPIO讀回其現在的輸入值為何。

int gpio_request_array(struct gpio *array, size_t num);

這是若要使用任何GPIO時，必須先呼叫該API，這個動作有點類似open的動作，以免其它人會佔用到相同的GPIO pin，這個API可以讓你要求不連續任意個存在的GPIO，之後你就可以使用以上的所有API。

struct gpio {

unsigned gpio;

unsigned long flags;

const char *label;

};

flags可以設定的值如下：

#define GPIOF_DIR_OUT (0 << 0)

#define GPIOF_DIR_IN (1 << 0)

#define GPIOF_INIT_LOW (0 << 1)

#define GPIOF_INIT_HIGH (1 << 1)

#define GPIOF_IN (GPIOF_DIR_IN)

#define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)

#define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)

int gpio_free_array(struct gpio *array, size_t num);

上一個若類似open的動作，這一個API就是close的動作。

以上這些kernel API都是給kernel內部其它driver使用的，使用它之前必需確定GPIO驅動已經被載入，否則將會無法使用，所以這時驅動載入的順序是非常重要的。另外由於有這一層的介面，使得其它會使用到GPIO的驅動程式，會統一的介面，不會因為底層的GPIO控制驅動程式不同因而有不同的介面，而產生需要修改程式，這對軟體的維護會是一大負擔。

實體層的GPIO chip controller的驅動程式

這是一個底層的驅動程式，直接控制GPIO的晶片，並接受上層的管理層的指令動作，並以此提供其它需要使用GPIO的驅動程式，可以有統一的介面。該驅動程式會用到一個資料結構，它是宣告在include/asm-generic/gpio.h，並且在kernel中必需將CONFIG_GENERIC_GPIO啓動，其宣告如下：

/**

* struct gpio_chip - abstract a GPIO controller

* @label: for diagnostics

* @dev: optional device providing the GPIOs

* @owner: helps prevent removal of modules exporting active GPIOs

* @request: optional hook for chip-specific activation, such as

* enabling module power and clock; may sleep

* @free: optional hook for chip-specific deactivation, such as

* disabling module power and clock; may sleep

* @direction_input: configures signal "offset" as input, or returns error

* @get: returns value for signal "offset"; for output signals this

* returns either the value actually sensed, or zero

* @direction_output: configures signal "offset" as output, or returns error

* @set: assigns output value for signal "offset"

* @to_irq: optional hook supporting non-static gpio_to_irq() mappings;

* implementation may not sleep

* @dbg_show: optional routine to show contents in debugfs; default code

* will be used when this is omitted, but custom code can show extra

* state (such as pullup/pulldown configuration).

* @base: identifies the first GPIO number handled by this chip; or, if

* negative during registration, requests dynamic ID allocation.

* @ngpio: the number of GPIOs handled by this controller; the last GPIO

* handled is (base + ngpio - 1).

* @can_sleep: flag must be set iff get()/set() methods sleep, as they

* must while accessing GPIO expander chips over I2C or SPI

* @names: if set, must be an array of strings to use as alternative

* names for the GPIOs in this chip. Any entry in the array

* may be NULL if there is no alias for the GPIO, however the

* array must be @ngpio entries long. A name can include a single printk

* format specifier for an unsigned int. It is substituted by the actual

* number of the gpio.

* A gpio_chip can help platforms abstract various sources of GPIOs so

* they can all be accessed through a common programing interface.

* Example sources would be SOC controllers, FPGAs, multifunction

* chips, dedicated GPIO expanders, and so on.

* Each chip controls a number of signals, identified in method calls

* by "offset" values in the range 0..(@ngpio - 1). When those signals

* are referenced through calls like gpio_get_value(gpio), the offset

* is calculated by subtracting @base from the gpio number.

struct gpio_chip {

const char *label;

struct device *dev;

struct module *owner;

int (*request)(struct gpio_chip *chip,

unsigned offset);

void (*free)(struct gpio_chip *chip,

unsigned offset);

int (*direction_input)(struct gpio_chip *chip,

unsigned offset);

int (*get)(struct gpio_chip *chip,

unsigned offset);

int (*direction_output)(struct gpio_chip *chip,

unsigned offset, int value);

int (*set_debounce)(struct gpio_chip *chip,

unsigned offset, unsigned debounce);

void (*set)(struct gpio_chip *chip,

unsigned offset, int value);

int (*to_irq)(struct gpio_chip *chip,

unsigned offset);

void (*dbg_show)(struct seq_file *s,

struct gpio_chip *chip);

int base;

u16 ngpio;

const char *const *names;

unsigned can_sleep:1;

unsigned exported:1;

#if defined(CONFIG_OF_GPIO)

* If CONFIG_OF is enabled, then all GPIO controllers described in the

* device tree automatically may have an OF translation

struct device_node *of_node;

int of_gpio_n_cells;

int (*of_xlate)(struct gpio_chip *gc, struct device_node *np,

const void *gpio_spec, u32 *flags);

#endif

};

另外向上註冊及移除的API如下：

/* add/remove chips */

extern int gpiochip_add(struct gpio_chip *chip);

extern int __must_check gpiochip_remove(struct gpio_chip *chip);

extern struct gpio_chip *gpiochip_find(void *data, int (*match)(struct gpio_chip *chip, void *data));

程式範例

GPIO控制晶片驅動程式：

struct myart_gpio_module {

struct gpio_chip gpio;

……………………………….

};

int myart_gpio_to_irq(struct gpio_chip *chip, unsigned offset)

{

struct myart_gpio_module *module;

module = container_of(chip, struct myart_gpio_module, gpio);

return module->intr_start + offset;

}

int myart_gpio_direction_input(struct gpio_chip *chip,unsigned offset)

{

myart_gpio_inout_pin(offset , MCPU_GPIO_INPUT);

return 0;

}

int myart_gpio_get_value(struct gpio_chip *chip, unsigned offset)

{

return myart_gpio_get_pin(offset);

}

int myart_gpio_direction_output(struct gpio_chip *chip,unsigned offset, int value)

{

myart_gpio_inout_pin(offset , MCPU_GPIO_OUTPUT);

return 0;

}

void myart_gpio_set_value(struct gpio_chip *chip, unsigned offset, int value)

{

myart_gpio_set_pin(offset , value);

}

static int __devinit myart_gpio_probe(struct platform_device *pdev)

{

……………………………….

/* Initialize the GPIO data structures */

module->gpio.dev = &pdev->dev;

module->gpio.label = pdev->name;

module->gpio.owner = THIS_MODULE;

module->gpio.direction_input = myart_gpio_direction_input;

module->gpio.get = myart_gpio_get_value;

module->gpio.direction_output = myart_gpio_direction_output;

module->gpio.set = myart_gpio_set_value;

module->gpio.to_irq = myart_gpio_to_irq;

module->gpio.can_sleep = 0;

module->gpio.base = 0;

module->gpio.ngpio = MCPU_GPIO_NUM;

ret = gpiochip_add(&(module->gpio));

……………………………………..

}

static int __devexit my_gpio_remove(struct platform_device *pdev)

{

……………………………..

ret = gpiochip_remove(&module->gpio);

if (ret) {

dev_err(dev, "unable to remove GPIO chip\n");

return ret;

}

………………………..

return 0;

}

static struct platform_driver my_gpio_driver = {

.driver = {

.name = "GPIO Driver",

.owner = THIS_MODULE,

.probe = my_gpio_probe,

.remove = __devexit_p(my_gpio_remove),

};

static int __init my_gpio_module_init(void)

{

return platform_driver_register(&my_gpio_driver);

}

static void __exit my_gpio_module_exit(void)

{

platform_driver_unregister(&my_gpio_driver);

}

module_init(my_gpio_module_init);

module_exit(my_gpio_module_exit);

上層GPIO應用驅動程式

上層的GPIO應用驅程式則是使用GPIO Kernel Library所提供的介面來撰寫驅動程式，如RTC, I2C等等都是常看到的使用GPIO來應用的驅動程式，它必須使用gpio_request_array()來向kernel取得所要用的GPIO，並確定它是没被其它驅動程式所使用，使用後並將其佔住不被其它驅動程式所佔用，在該應用驅動程式下載時需要呼叫gpio_free_array()將所佔用的GPIO free給其它的驅動程式使用，在整個驅動程式中則可以使用gpio_direction_input(), gpio_direction_output(), gpio_set_value(), gpio_get_value()來個別控制相對的GPIO為input or output，並且讀回或者設定相對GPIO為high or low。

程式範例

GPIO RTC驅動程式：

static void rtc_write(u8 cmd, u8 Data)

{

………………………

gpio_direction_output(GPIO_RTC_DATA, MCPU_GPIO_LOW);

gpio_set_value(GPIO_RTC_RESET, MCPU_GPIO_HIGH);

………………………

}

static u8 rtc_read(u8 cmd)

{

…………………

gpio_direction_input(GPIO_RTC_DATA);

………………..

v = gpio_get_value(GPIO_RTC_DATA);

…………………….

}

static int myart_rtc_read_time(struct device *dev, struct rtc_time *tm)

{

……………………..

v = rtc_read(RTC_MONTH_R);

………………………………

}

static int myart_rtc_set_time(struct device *dev, struct rtc_time *tm)

{

……………………

rtc_write(RTC_YEAR_W, v);

……………………..

}

static const struct rtc_class_ops myart_rtc_ops = {

.read_time = myart_rtc_read_time,

.set_time = myart_rtc_set_time,

};

static struct gpio rtc_gpios[] = {

{ GPIO_RTC_RESET, GPIOF_DIR_OUT, "rtc_reset"},

{ GPIO_RTC_SCLK, GPIOF_DIR_OUT, "rtc_sclk"},

{ GPIO_RTC_DATA, GPIOF_DIR_OUT, "rtc_data"},

};

static int __init myart_rtc_probe(struct platform_device *pdev)

{

…………………………..

err = gpio_request_array(rtc_gpios, ARRAY_SIZE(rtc_gpios));

…………………………..

rtc = rtc_device_register("rtc-myart", &pdev->dev, &myart_rtc_ops,

THIS_MODULE);

…………………………..

}

static int __exit myart_rtc_remove(struct platform_device *pdev)

{

…………………………..

rtc_device_unregister(rtc);

gpio_free_array(rtc_gpios, ARRAY_SIZE(rtc_gpios));

return 0;

}

static struct platform_driver myart_rtc_driver = {

.driver = {

.name = "RTC",

.owner = THIS_MODULE,

.remove = __exit_p(myart_rtc_remove),

};

static int __init myart_rtc_init(void)

{

return platform_driver_probe(&myart_rtc_driver, myart_rtc_probe);

}

static void __exit myart_rtc_exit(void)

{

platform_driver_unregister(&myart_rtc_driver);

}

module_init(myart_rtc_init);

module_exit(myart_rtc_exit);

Linux Kernel New HAL Timer Device Driver

2012-03-19T22:08:00.000+08:00

前言

由於現在的作業系統對於Real Time的需求越來越多，而對於Real Time的需求則是需要一個較精確的時間計時，以往的Linux在時間的設計上已經不符這個需求，所以在2.6.38之後的版本中已經針對它來修改，這份文件將會說明對於這個新架構的HAL Timer Device Driver的寫法為何。

以往的問題

時間不夠精細，需要能夠取得nanosecond
在計算時間時必需能夠考慮到timer counter overflow的問題

現在的做法

你可以註冊多個clocksource, 所謂的clocksource就是可以產生一個固定的clock, 並且可以讀回其計數值, 系統中將會比較各個clocksource的精確度, 以找出最佳的clocksource做為系統的clocksource, 而這個clocksource將會做為系統的計算時間用, 另外必須註冊一個做為clock event使用, 這就是取代以往的timer interrupt, 而clocksource和clockevent可以為同一個, 也可以為分別不同的timer, 若系統的timer夠多, 建議可以設定不同的timer

How to

在arch/arm/mach-xxx的目錄中必須包以下的程式碼

在MACHINE_START宣告中須有timer的資料結構指定

MACHINE_START(MOXAART, "Moxa ART CPU platform")

.boot_params = 0x100,

.fixup = moxaart_fixup,

.map_io = moxaart_map_io, /* map physical to virtual address */

.init_irq = irq_init_irq,

.timer = &moxaart_timer,

.init_machine = moxaart_init, /* register platform_device */

MACHINE_END

其中timer的資料結構如下

extern void moxaart_timer_init(void);

static struct sys_timer moxaart_timer = {

.init = moxaart_timer_init,

};

其中init的成員為一個call back function，其寫法如下

void __init moxaart_timer_init(void)

{

*timer_ctrl_reg = timer_ctrl_reg_value;

setup_irq(IRQ_TIMER1, &moxaart_timer_irq);

moxaart_clocksource_init();

moxaart_clockevent_init();

}

請注意其中將會註冊一個clock source以及一個clock event。

如何初始化以及設定一個clock source

啓動該計時器，準備一個call back function讓系統可以隨時讀取讓計時器的值，最後呼叫一個kernel API clocksource_mmio_init()來設定一個clock source, 以下為範例程式

static cycle_t moxaart_clocksource_read(struct clocksource *c)

{

return ~moxaart_timer_get_counter(CLOCK_TIMER);

}

static void __init moxaart_clocksource_init(void)

{

moxaart_timer_set_reload(CLOCK_TIMER, MAX_COUNTER);

moxaart_timer_set_counter(CLOCK_TIMER, MAX_COUNTER);

moxaart_timer_enable(CLOCK_TIMER);

clocksource_mmio_init(NULL, "timer2", APB_CLK, CLOCK_RATING, 32, moxaart_clocksource_read);

}

請注意在讀取計時器的值call back function中的return值，若讓計時器是遞減的值則必須反相加一個 ”~”, 若是遞加則不用。

如何初始化以及設定一個clock event

這個初始化較為繁複，首先你要準備一個資料結構struct clock_evelt_device, 以下為其範例

static struct clock_event_device clockevent_moxaart = {

.name = "timer1",

.features = CLOCK_EVT_FEAT_PERIODIC|CLOCK_EVT_FEAT_ONESHOT,

.irq = IRQ_TIMER1,

.rating = CLOCK_RATING,

.shift = CLOCK_SHIFT,

.set_mode = moxaart_set_mode,

.set_next_event = moxaart_set_next_event,

};

其中的features設定CLOCK_EVT_FEAT_PERIODIC, 是較為傳統的timer功能，就是會一直產生的固定時間，也就是以前所謂的tick功能，而CLOCK_EVT_FEAT_ONESHOT的功能較為新的設計，若要有high resolution (至nanosecond等級)，則必須有這個功能，意思就是timer可以只產生一次到的interrupt，而不是前面所提的periodic一直產生的timer interrupt。另外對shift成員的設定為一個為2的幾次方值，如32則表示所有的timer counter值將會先乘於2的32次方。

接下需要準備ISR, 其設定如下

static struct irqaction moxaart_timer_irq = {

.name = "timer1",

.flags = IRQF_DISABLED|IRQF_TIMER|IRQF_TRIGGER_FALLING|IRQF_IRQPOLL,

.handler = moxaart_timer_interrupt,

.dev_id = &clockevent_moxaart

};

請注意其成員dev_id為上面所宣告的clockevent_moxaart。

在clock_event_device中的成員set_mode call back function則是在設定該timer是要使用何種方，以下為其寫法

static void moxaart_set_mode(enum clock_event_mode mode, struct clock_event_device *evt)

{

switch ( mode ) {

case CLOCK_EVT_MODE_PERIODIC:

moxaart_timer_set_reload(USED_TIMER, LATCH);

moxaart_timer_set_counter(USED_TIMER, LATCH);

moxaart_timer_enable(USED_TIMER);

break;

case CLOCK_EVT_MODE_ONESHOT:

moxaart_timer_set_reload(USED_TIMER, 0);

moxaart_timer_set_match1(USED_TIMER, 0);

timer_ctrl_reg_value &= ~(TIMER1_INT_ENABLE);

timer_ctrl_reg_value |= (TIMER1_ENABLE|TIMER1_USED_PCLK);

*timer_ctrl_reg = timer_ctrl_reg_value;

break;

case CLOCK_EVT_MODE_RESUME:

moxaart_timer_enable(USED_TIMER);

break;

case CLOCK_EVT_MODE_SHUTDOWN:

case CLOCK_EVT_MODE_UNUSED:

default:

moxaart_timer_disable(USED_TIMER);

break;

}

請注意其模式中的periodic和oneshot定義的不同，在oneshot的模式中會將reload的值設為零。

而對於set_next_event的call back function，則是只是設定讓計時器的reload值

static int moxaart_set_next_event(unsigned long evt, struct clock_event_device *unused)

{

moxaart_timer_set_reload(USED_TIMER, evt);

return 0;

}

對於ISR的寫法如下

static irqreturn_t moxaart_timer_interrupt(int irq, void *dev_id)

{

struct clock_event_device *evt=dev_id;

*(volatile unsigned int *)(MOXAART_TIMER_VA_BASE+TIMER_INTR_STATE) = 0;

evt->event_handler(evt);

return IRQ_HANDLED;

}

對於timer interrupt的寫法其實很制式，大家都一樣。

最後則是clock event的初始化，其寫法如下

static void __init moxaart_clockevent_init(void)

{

clockevent_moxaart.mult = div_sc(APB_CLK, NSEC_PER_SEC, clockevent_moxaart.shift);

clockevent_moxaart.max_delta_ns = clockevent_delta2ns(0xffffffff, &clockevent_moxaart);

clockevent_moxaart.min_delta_ns = clockevent_delta2ns(0xf, &clockevent_moxaart);

clockevent_moxaart.cpumask = cpumask_of(0);

clockevents_register_device(&clockevent_moxaart);

}

在arch/arm/Kconfig的有關自己CPU的選項中必須有以下的設定

select GENERIC_CLOCKEVENTS

select CLKSRC_MMIO

以下是一個範例：

config ARCH_MOXAART

bool "MOXA ART CPU"

select CPU_FA526

select USB_ARCH_HAS_EHCI

select MIGHT_HAVE_PCI

select ARCH_REQUIRE_GPIOLIB

select GENERIC_GPIO

select GENERIC_CLOCKEVENTS

select CLKSRC_MMIO

help

Support for MOXA ART CPU

附錄

Kernel APIs

/**

* clocksource_mmio_init - Initialize a simple mmio based clocksource

* @base: Virtual address of the clock readout register

* @name: Name of the clocksource

* @hz: Frequency of the clocksource in Hz

* @rating: Rating of the clocksource

* @bits: Number of valid bits

* @read: One of clocksource_mmio_read*() above

int __init clocksource_mmio_init(void __iomem *base, const char *name,

unsigned long hz, int rating, unsigned bits,

cycle_t (*read)(struct clocksource *))

API Select怎麼用

2012-02-28T17:57:00.002+08:00

前言

常在寫網路程式的人對select()這個API應該不莫生才對，或常寫伺服器端程式也應該很熟悉才對，它可以同時監看多個檔案的讀寫允許，而且檔案包含各種週邊元件以及網路的socket，這裏我將會介紹它經常被用的應用，以及我個人經驗中覺有點特別的用法分享給其他人參考參考。

Select函式原型

int select(int nfds, fd_set *restrict readfds, fd_set *restrict writefds, fd_set *restrict errorfds, struct timeval *restrict timeout);

這個函數主要是用來同時監看數個檔案(包含socket)，其中的事件在一定時間內是否有發生，而其中的事件有是否有資料可取得，是否可以寫入，以及其它錯誤事件，若在一段時間內沒有任何事件產生，則會回覆一個timeout的訊息，這個函數好用在它可以同時監看很多個檔案，以及時間，如此一來可以讓電腦更有效率以及可以同時處理多個檔案。

其中輸入的參數說明如下：

int nfds

對所要監看的所有file handle中最大的file handle號碼加1

fd_set *restrict readfds

相對監看該檔案是否有資料已收到或者已有資料可讀，只是確認有資可讀，但不知有多少資料可讀。可以使用FD_SET來設定相對需要確認的檔案，以及使用FD_ISSET來檢查確認的結果。

fd_set *restrict writefds

相對確認該檔案是否可以寫入或者有空間可寫入，只是確認可寫入，但是有多少空間可寫入，並不知道。可以使用FD_SET來設定相對需要確認的檔案，以及使用FD_ISSET來檢查確認的結果。

fd_set *restrict errorfds

相對確認該檔案是否有任何錯誤產生，可以使用FD_SET來設定相對需要確認的檔案，以及使用FD_ISSET來檢查確認的結果。

struct timeval *restrict timeout

這是設定timeout時間，若為NULL則是無限制時間監看及確認，其宣告如下：

struct timeval {

time_t tv_sec;

suseconds_t tv_usec;

}

以上最小時間單位為usec，但是在Linux中系統tick設定通常為10ms之下，通常最小時間可細分也只能到10ms，比這個小的時間其實是無法達到的。

其回傳值如下：

> 0 表示所以監看的檔案中有幾個檔案已符合條件。

= 0 表示未任何事件發生並且已經timeout。

< 0 表示有錯誤產生。

其它會用到的巨集指令

void FD_CLR(int fd, fd_set *set);

清除掉該檔案相對檔案的設定，也就是取消對該檔案的監看。

int FD_ISSET(int fd, fd_set *set);

檢查相對該檔案是否為真，就是對該檔案所監看的結果，確認是否為真，若是為真即表示該事件有發生，若為否則表示該事件未發生。

void FD_SET(int fd, fd_set *set);

設定監看該檔案行為。

void FD_ZERO(fd_set *set);

清除所有檔案的監看及設定。

正常使用

在Linux中任何週邊都是使用檔案來使用，所以在select中的所使用file handle可以是網路socket open來的，也可以是open device node所得來的，也可以是真正的檔案，所以以下為一個正常使用的範例：

int fd1=soekcet(…)

int fd2=open(“device-node-name”, …);

int maxfd;

fd_set readfds, writerfds;

struct timeval timev;

FD_ZERO(&readfds);

FD_ZERO(&writefds);

if ( fd1 > fd2 )

maxfd = fd1;

else

maxfd = fd2;

FD_SET(fd1, &readfds);

FD_SET(fd2, &readfds);

FD_SET(fd1, &writefds);

FD_SET(fd2, &writefds);

timev.tv_sec = 3;

timev.tv_usec = 0;

if ( select(maxfd, &readfds, &writefds, NULL, &timev) ) {

if ( FD_ISSET(fd1, &readfds) ) {

// fd1有資料可讀

}

if ( FD_ISSET(fd2, &readfds) ) {

// fd2 有資料可讀

}

if ( FD_ISSET(fd1, &writefds) ) {

// fd1 可寫入

}

if (FD_ISSET(fd2, &writefds) ) {

// fd2 可寫入

}

} else {

// timeout or error

}

以上的寫法在應用有許多好處，一是可以同時處理許多檔案，並且可以隨時加入或退出，二是使用事作觸發讓系統的負載不會過重，並且也可兼顧時效性。

短時間休眠用

前面所提是一般正常的使用方式，有一種另外的使用場合，那是因為在Linux的sleep function中只有秒級的單位，若我們想要實現msec的sleep則無法做到(注:現在在real time中可以有usleep)，則可以利用select的timeout機制來作sleep的msec等級，其寫法如下：

struct timeval timev;

timev.tv_sec = 0;

timev.tv_usec = 10000; // 10msec

select(1, NULL, NULL, NULL, &timev);

GNU編繹設定

2012-01-02T23:15:00.000+08:00

我們現在大多會在網路下載各種GNU的軟件原始碼，並給予做編繹的動作，而在每個原始碼的根目錄中通常會有一個shell script，檔名會是configure，而我們在編繹原始碼之前，都需要先執行這一個執行檔，而在這執行檔中，會有三個設定，分別為--host, --build, --target其代表的意義如下：
--build - 表示要在那一個機器執行編繹的動作，通常為 i686-pc-linux，原則這個可以讓configure自動幫你判別
--host - 表示最後的執行要在那個平台執行，例如arm-linux
--target - 表示其執行檔為何種格式，例如arm-linux，所以這會和--host相同
另外我們在執行編繹有幾個環境會做設定如下：
CC=arm-linux-gcc
CPP="arm-linux-gcc -E"
LD=arm-linux-ld
AS=arm-linux-as
NM=arm-linux-nm
RANLIB=arm-linux-ranlib
CXX=arm-linux-g++

Linux Kernel 開機大追蹤

2011-12-09T13:02:00.001+08:00

前言

多年之前大家都在談論所謂後PC時代，在當時大家無法很確定什麼是後PC時代，在今天因為智慧型手機及平板電腦的興起，己使大家可以很清楚地了解什麼是後PC時代，就是嵌入式系統，而在這些嵌入式系統中，會需要一個作業系統，而Linux的免費，以及它的穩定、open source code、Linux 已成為現在嵌入式首選的作業系統，也因此現在已有越來越多人投入開發。通常若要了解一個作業作統，可以從其開機流程來了解，若清楚地了解其開機流程程，將有助於你了解整個作業系統。

Kernel原始碼

Linux將其所有的程式碼全部公開，用以讓所有世界高手來修改，其實你可以將其視做一個framework的原始碼，所以你若了解其原始碼目錄的擺放將會有助於你開發的速度。以下是kernel source code根目錄的內容：

圖一Linux Kernel source code根目錄

其中幾個比較重要的目錄說明如下：

arch

這是一個HAL層的原始碼，和CPU以及各個板子有關，通常這部分會由CPU廠商所提供，另外程式起始包含在這裏面，後面將會給予說明。

drivers

這是各個元件的驅動元件，而各個元件的驅動程式，將會依照各分門別類給予不同的目錄而放置。

這是有關記憶體管理的部分程式碼，這部分是和硬件無關的程式，其底層則是呼叫HAL層的程式碼，而這部分則是前面所提的arch目錄。

在這個目錄所放置的則是各種檔案系統的程式，通常檔案系統和硬體沒有關係，而其底層的IDE或者SCSI等等則是放在前面所提的driver目錄之中。對於各種的虛擬檔案系統也是在這裏。

kernel

這是系統微核心的地方，而這部分通常和硬體無關，排程的管理也是在這裏。

有關各種網路協定的實做，都在這裏，從網路的link層至應用層都在這裏，以及和應用程式之間的socket層介面也是在此目錄中。

include

kernel中用到C和組合語言的include file放在這個目錄。

init

這是系統開機時的初始化動作，這會呼叫arch之下以及各個driver的初始化動作。

Kernel編譯模式

我們在編譯kernel有兩種模式可以產生，一種是有壓縮的形式，這種形式檔案會較小很多，但是在啓動時會先做自我解壓縮，這樣會造成開機時會較慢一點，另外一種是直接產生一個binary (位元)檔，這是一個kernel的執行檔，這個檔案會大很多，但其實就是前一種解壓縮完之後的內容。如何編譯這兩種kernel呢? 其實很簡單，若要產生壓縮的程式碼，在根目錄執行 ’make zImage’就可以了，它會產生一個檔案 zImage ，放在目錄arch/arm/boot之內，另外要產生沒有壓縮的kernel執行 ’make linux’就可以了，而其產生的檔名為 vmlinux 在原始檔的根目錄之下，最後要說明的是要產生壓縮的 zImage 一定會先產生沒有壓縮的 vmlinux，再由其做壓縮成 zImage。

自我解壓縮

壓縮的zImage檔其前面有一個自我解壓縮的程式碼，這段程式碼在arch/arm/boot/compressed目錄之內，第一個執行的程式為該目錄之下的head.S，原則上bootloader可以傳遞參數給kernel，它將透過暫存器r1及r2來傳送，其中r1是CPU的ID，這個值其實是由CP15的指令所讀來的，而r2則是存於一些tag的指標位置，通常在embedded系統中我們都會省略而不使用。這是一小段解壓縮的程式碼，它可以放在記憶中任何位置來執行，也就是為independent code，其實它是將kernel壓縮後利用linker及objdump公用程式，將其結合成為一個可執行檔或者是firmware，其實是將壓縮過的核心程式當做是資料和head.S的程式結合在一起，另外值得一提的是，這個解壓縮程式可放在記憶體中任何位置執行，所以它會自動判別解壓縮後的程式是否會覆蓋自己而給予避開。

第一個指令

如果是有壓縮的第一個指令如前所提的，放在arch/arm/boot/compressed/head.S，若不是壓縮檔則是放在arch/arm/kernel/head.S之內，應該說這才是真正kernel的第一個指令，一樣的在解壓縮之後會將bootloader所傳送過來的r1 & r2暫存器原封不動的再傳給kernel，而 r1 則是傳遞 CPU 的代碼，而kernel則會使用cp15的指令讀回做檢查，並且查核那一個ARM core，則會使用相對的cache指令將cache打開，通常打開cache時需要啓動MMU才能打開cache，而這時通常會設定虛擬位址和真實位址是一樣的，而打開cache是為了要加快解壓縮的速度，而在解壓縮之前會將r1 & r2分別拷貝至r7 & r8暫存器，而在解壓縮完之後，會將這兩個暫存器存回原先的r1 & r2，而r2則是存放參數位置，而這些參數是有關開機時的選項，而這些說明目前已經寫在程式的開頭地方，當你看其原始碼時即可看到，而第一個指令則是在標示在.setion “.text.head”的地方。

接著它會檢查從bootloader傳來的CPU ID是否正確，在kernel中可以撰寫支援多顆CPU的程式碼，因此可以透過這個代碼來取得相對應的程式碼，主要是cache以及CP15指令的不同，另外還有關MMU方面的操作也有所不同，當確認讓CPU ID是有被支援的，就會繼續執行下去。

再來的動作則取回該CPU的訊息，以及該CPU在kernel己經準備好的一些初始化程式碼，我們在porting kernel時會建立一個錄在arch/arm之下，然後以mach-當開頭的目錄，像是mach-ixp4xx，在這目錄之內將會建立一個C程式碼，在這之內會有一個巨集指令MACHINE_START，在這之內會有一些call back function的設定，在初始化的過程中會被呼叫，其主要是設定那些硬體需要被mapping至那些virtual address，以及timer & interrupt controller的初始化程式碼，當這些初始化的程式碼都可以正確無誤地被執行，它最後則會執會init/main.c中的start_kernel，而在它執行的當中它會檢查從bootloader傳來的command line，若沒有會有一個警告訊息，說這個tag有問題，若你確定没有傳，那你可以忽略掉它。

當它初始都没有問題，則會開始載入各個驅動程式，以及kernel本身的初始化動作，如記憶體管理，當這些都正常執行完之後，就會開始執行第一支AP，它會先執行由bootloader或者在kernel中設定的command line所指定的第一支程式，若没有則會尋找/sbin/init這支程式，若無法執行，則行bash，還是無法執行則會panic系統，並會說明找不到程式可執行，若第一支程式可以正常執行，則其它的程式則會由這第一支程式去執行其它程式，若它沒有執行其它程式，則將不會執行其它程式，另外第一支程式可以是一支shell script，以上則是kernel開機的順序。

如何製作一個Debian安裝磁碟在USB storage上

2011-11-08T23:58:00.000+08:00

Debian是在linux中常被使用的發行版本，它可以從多種的儲存謀體來做安裝的動作，這裹要介紹從USB stroage (俗稱大姆哥)做安裝的動作，以下則是裝作USB安裝碟的流程：
1．將USB format成FAT or FAT32檔案系統，因為只有這兩種系統才能做為開機系統，而且這兩種檔案系統有可能會讓USB可使用的大小比實際硬體還要小。
2．從網路下載一個公共程式 syslinux
3．執行指令 'syslinux /dev/sdb1' (其中/dev/sdb1則是USB磁碟機代碼)，完成之後將其掛載起來
mount /dev/sdb1 /mnt/usbdisk
4．下載網路安裝檔 netboot.sio 至PC並將其掛載起來如下
mount -o loop /home/netboot.iso /mnt/isodisk
5．拷貝上一個動作所掛載的網路安裝檔的所有內容至USB disk
cp -a /mnt/isodisk/* /mnt/usbdisk
6．將在USB disk中根目錄之下的isolinux目錄名稱改為syslinux
7．將在USB disk中的syslinux/isolinux.bin檔名改為syslinux/syslinux.bin
8．將在USB disk中的syslinux/isolinux.cfg檔名改為syslinux/syslinux.cfg
到此就大功告成，最後重新開機進入BIOS設定從USB disk開機即可

Serial驅動程式中的Flow Control問題

2011-09-27T17:20:00.000+08:00

什麼是Flow Control

Flow Control簡單講就是流量控制，其主要目的就是避免通訊的雙方資料被掉包，那為何資料會掉包呢？我們想像一個情境，通訊一定是至少兩人以上互相傳送資料，互相傳送資料雙方硬體不一定會一樣，所以在效能上也會不一樣，若當接收端來不及處理已接收到資料時，若沒有通知對方暫停傳送資料，因而造成對方持續送資料，這樣就會產一種現象，就是接收端會將收進來的資料丟棄，或者不接收對方送過來的資料，因而造成資料的留失，所以我們就使用流量控制的部分來確保資料不要留失。其實其中的做法也不是太難，就是利用一個機制來通知對方不要送資料就好了，而問題在於以前這種的控制都由軟體來做，但是最後還是控制使用硬體來通知對方，在控制硬體送出訊號給對方會需要一些時間處理，而這段時間長短是無法預測的，並且對方還是在繼續傳送資料，假如這段時間過長，就會造成和没有流量控制一樣的情形，也因此為了解決這個問題，現在就有人改用硬體來處理這個問題，就可以大大降低這個問題的產生，但是若要真正有效發揮硬體的功能是需要修改軟體的，所以以下我們會來說明如何修改軟體。

Serial Port的流量控制方式

RS232的流量控制方式有兩種，一種稱為軟體流量控制方式，另外一種就是所謂的硬體流量方式，什麼是軟體流量控制方式，其控制方式就是將控制訊息加到資料之中，用另外一個方式說明，就是當接收端無法收資料時就送一個字元Xoff (0x13)給對方，可以收的時候就送一個字元Xon (0x11)給對方，所以軟體控制的方式有幾種限制，首先是在傳送的資料不可以包含這兩個字完，否則將會嚴重破壞流量控制的正常運行，另外一個限制就這兩個字元必須是要即時被送出，若和要送給對方的資料一起排隊的話，有可能會延誤流量控制的時間點，因而造成流量控制的失敗。

另外一種的流量控制方式為硬體方式，其作法是必需另外再接兩條線，一條為RTS至對方的CTS，因為是雙向的所以另外一條就是我的CTS接至對方的RTS，另外的說法雙方都會增加兩隻腳為RTS及CTS，其做法很簡單就是當接收端資料快滿的時候，將RTS設為low，一直到可以接收資料時再將RTS拉為high，相對的傳送端會隨時檢查CTS，當它為low時就停止送資料，當它為high時就開始送資料。

RS232的上層控制驅動程式為tty_io，而這層則會負責流量控制，當需要做相對流量控制的行為時，它會呼叫你的RS232驅動程式作動作，所以只要做相對的動作即可，而這個動作則是前一篇文章-serial port device driver中所提的throttle & unthrottle這兩個call back function。

有什麼問題嗎？

若按照前面所提的，在寫串列式驅動程式的時候有什麼問題？看是沒有問題，但問題就在後面，因為現在的UART越做越好，所以就將流量控制的動作直接由IC本身實現，就不需要軟體來處理，IC實現有它的好處，因為它是由硬體來處理，所以反應的時間會非常快，能夠避免軟體處理時需要冗長的時間，可能會造成反應不及而讓流量控制無效。在找出問題之前我們先看以下的圖：

以上為驅動程式的架構圖，通常每一層驅程式都會有自已的buffer來存放收送的資料，而前面有說過在tty_io層會做流量控制，而它是如何判斷何時需要做流量控制呢？當然是依照它自已的buffer來做判斷，快滿的時候就叫對方不要送資料，buffer已被讀完則通知對方可以送資料，問題在於當上層的buffer滿並不代表低層IC上的buffer已滿，如此一來有一種情境將會發生，底層的IC buffer已滿，因為有支援流量控制，所以IC已經主動通知對方不要送資料，可是這時候因為上層的資料未滿，或者剛到低水位，所以通知低層送出通知對方可以送資料，如此一來將會弄亂底層的流量控制，簡單的說明就是上層的buffer水位和底層是不會同步的，用另外一種方式來看待這個問題，其實這麼多層的驅動程式，只要其中有一層做流量控制即可，這時候當然讓最低層的IC來處理即可，因為可以反應最快，並且因為由IC自行處理，所以可以減輕CPU的負擔，所以在有IC支援流量控制時RS232的驅動程式，應該如以下的寫法將會是比較好的：

static void uart_throttle(struct tty_struct *tty)

{

…………

disable_IC_receiving_and_receiving_interrupt();

………………..

}

static void uart_unthrottle(struct tty_struct *tty)

{

………………

enable_IC_receiving_and_receiving_interrupt();

…………………

}

没錯一個簡單的動作，就是在throttle的callback function中停止收資料就好了，因為如此一來將會造成IC buffer到達高水位而讓IC自動作成流量控制的行為即可，另外unthrottle的callback function中再一次啓動收資料即可，因為將IC中的buffer讀走而達低水位時，IC將會再次自動做出流量控制，如此一來上層可以不用知道低層IC的buffer使用情形，也不會弄亂IC的流量控制，這是在IC支援流量控制時所要做的修正。

驅動程式中的DMA問題

2011-09-12T17:14:00.000+08:00

前言

什麼是DMA(directly memory access)? 簡單的講就直接記憶體存取，或許你還是無法明白，這樣說好了，在一個電腦系統中，通常都是由CPU (中央控制單元) 來對記憶體做存取的動作，也就是在各個電腦週邊元件中，若要對記憶體做存取動作，則必須經由 CPU 來做仲介的角色，而DMA則可以取代CPU這個工作，但僅至於資料而已無法對指令做這個動作，因為記憶體在系統中是唯一的，若要讓CPU及DMA可以很順暢的工作而不會互相干擾，則必需在軟體上做一些協調的動作，另外因為CPU有MMU及Cache的元件，也使得為了要讓DMA取得正確的資料，所以在寫這方面的驅動程式時需要特別注意，以下就來說明這方面的作法及問題。

硬體架構

圖一

問題點

從上圖中我們可以清楚地了解以下幾件事：

當CPU要向DRAM或者是週邊元件存取時，所以放出來的位置將會經過cache及MMU的處理。

在cache中的處理主要是提高對記憶體的存取速度。
當作業啓動時所有程式均使用虛擬記憶體，所以一定會經過MMU的位址轉換，因為當實際要對週邊元件或者記憶體存取時一定會使用實體位址。

當DMA要存取記憶體時並不會經過MMU模組的轉換，換句話說就是DMA會直接使用實體位址來存取記憶體。

另外一個問題是DMA也沒有經過cache模組，所以存取的資直接從記憶體存取。

解決方案

由以上的問題描述，我們可以看一個很基本的問題，就是CPU和DMA之間對記憶體的存取可能會有不相符的現象產生。首先我們先來看週邊元件要送資料，也就是從CPU寫入資料至記憶體，然後DMA從記憶體取得資料給週邊元件，進而週邊元件送出資料，這裡問題在於CPU寫入資料時，可能不會一定寫入記憶體，有可能保留至cache中，若這時DMA來取資料將會是不對的資料，因此在DMA存取之前，一定要讓CPU的cache單元做一次sync的動作，將若有還有cache中的資料，真的寫入記憶體中，如此一來DMA將可以取得正確資料。換一個簡單的說法，就是週邊元件要送資料時必須對cache做sync的動作，確認最後的資料是有寫入記憶體。

另一個資料方向就是當週邊元件收到資料時，將會由DMA直接寫入記憶體，完作接收後，週邊元件會產生一個中斷通知CPU來讀取資料，這時的問題是在於存放收到資料，有可能是已被cache住，若CPU不做任何動作而直接來讀取資料，一樣會產生資料不正確的情形，這時在CPU讀取時必須對該區塊作一個cache invalid的動作，讓CPU在讀取該區塊資料，會實際至記憶體做讀取的動作，因此重新讓cache元件，針對該區域重新做cache的動作，如此一來就不會有資料不正確的情形產生。所以說週邊元件在收資料時，必需對cache做invalid的動作。

另外有一個簡單的作法，就是在準備這些記憶體時，就取得讓記憶體是不會做cache的動作，如此一來就不需要做資料同步動作。

Kernel API

我們從以上知道問題，也知道該如何解決，現在的問題是有多少的kernel API可供使用，以下我們就來看：

dma_addr_t dma_map_single(struct device *, void *, size_t, enum dma_data_direction);

void dma_unmap_single(struct device *, dma_addr_t, size_t, enum dma_data_direction);

dma_addr_t dma_map_page(struct device *, struct page *,unsigned long, size_t, enum dma_data_direction);

void dma_unmap_page(struct device *, dma_addr_t, size_t,enum dma_data_direction);

void dma_cache_maint(const void *kaddr, size_t size, int rw);

void dma_cache_maint_page(struct page *page, unsigned long offset,size_t size, int rw);

enum dma_data_direction {

DMA_BIDIRECTIONAL = 0,

DMA_TO_DEVICE = 1,

DMA_FROM_DEVICE = 2,

DMA_NONE = 3,

};

以上的kernel API主要是針對將一般取得的記憶體(例如由kmalloc所取得)，是會被cache的記憶體，將cache中的資料和實體記憶體資料做同步的動作，其DMA_TO_DEVICE就是做invalidate的動作，而DMA_FROM_DEVICE就是synchronize的動作，這些API必需要在呼叫DMA之前完成。

void *dmam_alloc_coherent(struct device *dev, size_t size,dma_addr_t *dma_handle, gfp_t gfp);

void dmam_free_coherent(struct device *dev, size_t size, void *vaddr,dma_addr_t dma_handle);

以上的kernel API是在要allocate記憶體時就取得不會被cache的記憶體，如此一來對這塊記憶體的存取時就不需要前面所提的動作 – invalidate or synchronize，另外也可取得該記憶體的實體記憶體，這個實體記憶體將會給DMA controller所使用。

SD/MMC驅動程式面面談

2011-07-28T23:23:00.001+08:00

前言

MMC/SD在現在崁入式系統常被使用，因為它的體積小而且目前最新的版本可以支援到2TB，所以現在的崁入式的系統中自然而然會選用它來做儲存媒介。而SD/MMC其標準定義了實體層的硬體介面訊號，以及第二層為指令及資料讀寫的定義。它可分為SD/MMC為第一版只支援至2G，而SDHC則是第二版，可以支援至32G，它和第一版的差異，除了實體層的工作頻率增加，可以較快速的讀取之，在第二層也有擴充其功能，使其可以存取更大的檔案系統，而目前最新的為SDXC它可以支援至2TB，它又將工件往上提升，可是可以向下相容，也就是舊規格的SD卡也可以用，現在我們來介紹如何在driver中撰這些程式碼。

MMC/SD程式目錄

MMC/SD在Linux Kernel原始程式碼中的擺放位置為drivers/mmc，在其中又分為三個子目錄，分別為host、core及card，而這三個目錄其所包含內容如下：

host

則是各家SD controller晶片廠所實現的部分，其主要是控制硬體，並將上層的所下的指令給轉換至硬體層，我們所要撰寫的驅動程式也是在這個目錄之下。

core

這是SD/MMC的管理及核心程式的地方，其中包含了第二層大家共通的部分，也是提供實體註冊及管理的部分，這個部分是大家一起共用，所以不用修改。

card

這是kernel中的檔案系統和管理中心溝通部分，也就是將檔案系統的需求轉換至核心管理程式，而核心管理再將其轉換至實體層，這個部分也是大家一起共用，所以也不需要修改。

在2.6.18之後有支援SDHC其主要是第二層的指令增加，所以舊的SD硬體 (SD host) 可以經軟體的改變而可以支援SDHC，只是因為硬體沒有改變，因此無法支援較高速的SD card。而在載入驅動程式需如下：

insmod mmc_core.ko

insmod mmc_block.ko

insmod your_hardware_SD_driver.ko

因為這是一個底層的驅動程式，所以你可以在上層載入任何的檔案系統，因為檔案系統是一個純軟體的驅動程式，所以和硬體無關，只是FAT32最大所能支援的檔案系統就只有32G，所以若要使用較大的檔案系統則必需使用其它的檔案系統。

系統驅動程式結構

我們先來了解一下linux kernel其中驅動程式的結構，在linux kernel的驅動程式中會將各種元件給予分門別類，並且在各種類別中會給予建構一個管理層的驅動程式，其主要目的是要建立和應用程式之間的標準介面，並且管理相同類別中的各家不同的硬體廠商，如此一來即可規範硬體廠商如何撰寫廠商，避免因不同的廠商而產生不同的驅動程式的撰寫格式不同，或者造成應用程式的介面，進而造成使用者因不同的廠商而要修改軟體。其架構圖如下：

圖一：驅動程式系統架構

圖一清楚地表示前面所說明的各個目錄所負責的事情，而我們今天所要實現就是在host的目錄之下，向core註冊一個硬體，如此一來就可很輕易地連接到整個檔案系統，而檔案系統維護的部分，則是由上層的檔案所維護，對硬體層而言則是執行上層的指令，並且是完全是被動的，不會主動自行執行任何指令。

MMC core所提供的API

在介紹如何撰寫前，先來了解有那些MMC core API可供使用，其所用的include file是及，而API如下：

struct mmc_host *mmc_alloc_host(int extra, struct device *)

這是allocate MMC註冊時所需的資料結構記憶體，另外可以多要一些記憶體來存放驅動程式的私有資料，其input/output說明如下：

Input :

int extra – 需要額外記憶體的大小，其存放位置的指標將會放在return回來的mmc資料結構中的private指標，它將會是緊接在mmc資料結構的最後面，或者經由呼叫mmc_priv(struct mmc_host *)來取得其指標。

struct device * – 為驅動程式進入時系統會傳過來的一個參數，只要將其再轉傳過去即可。

Output :

其返回值為一個mmc_host資料結構的位址point，這個資料結構會在後面介紹，這個point位址將會給予保留，因為我們需要在其中幾個call back欄位填入我們要實現的功能，也就是提供給上層驅動程式如何溝通的介面。

void *mmc_priv(struct mmc_host *host)

這是取回私有資料的指標，通常會再給予強迫轉型給local變數。

Input :

struct mmc_host *host – 是mmc_alloc_host API所return回來的class pointer。

Output :

其返回值為一個指標位址。

int mmc_add_host(struct mmc_host *)

這是增加一個SD host controller，而其所需要的資料結構則是由上一個API所取得回來的，而登錄加入時上層的管理者會掃瞄一次是否有SD卡已經插上來，若有則增加一個SD disk，若没有也會設定該SD host所支援的電壓及頻率。

Iuput:

struct mmc_host * - 是由mmc_alloc_host API所return回來的class pointer。

Output:

0代表成功，非0值代表錯誤。

void mmc_remove_host(struct mmc_host *)

這是移除一個SD host controller，其做的事情和mmc_add_host()是相反的事。

Input:

struct mmc_host * - 是由mmc_alloc_host API所return回來的class pointer。

Output:

無

void mmc_free_host(struct mmc_host *)

這是將mmc_alloc_host()所取得的資料結構記憶體空間歸還給系統，另外也會將多取得的私有空間也歸還給系統，所以在這之後將不可再使用該資料結構的記憶體空間。

Input:

struct mmc_host * - 是由mmc_alloc_host API所return回來的class pointer。

Output:

無

void mmc_detect_change(struct mmc_host *, unsigned long delay)

在控制器偵測到有SD卡的插入或拔出都會呼叫這個API通知上層管理層加入一張SD卡或者移除一張SD卡，請不要搞亂並沒有移除或增加一個控制器，只是SD卡而己，但在移除時未完成的SD動作，都需要給予放棄。

Input:

struct mmc_host * - 是由mmc_alloc_host API所return回來的class pointer。

unsigned long delay – 當是插入時通常會設定一個值，以等待插入的SD卡電氣訊號穩定，而移除時通常其值會是0。

Output:

無

void mmc_request_done(struct mmc_host *, struct mmc_request *)

這是一個非常也常用到的API，原則上層管理層下達指令給控制器時都是透過mmc_request，而當控制器完成該指令時則需要呼叫這個API來通知上層已完成該指令，而在SD的控制指令則是半雙工的，一個指令完成之後才會有下一個，不會有連續好幾個指令產生。另外指令是包含讀寫資料。

Input:

struct mmc_host * - 是由mmc_alloc_host API所return回來的class pointer。

struct mmc_request * - 是由上層所下的指令資料結構。

Output:

無

資料結構

如前面所提，其中最重要的資料結構宣告如下：

struct mmc_ios {

unsigned int clock; /* clock rate */

unsigned short vdd;

unsigned char bus_mode; /* command output mode */

unsigned char chip_select; /* SPI chip select */

unsigned char power_mode; /* power supply mode */

unsigned char bus_width; /* data bus width */

unsigned char timing; /* timing specification used */

};

這是一個SD卡的基本設定值，其中要支援的電壓值、使用的頻率等等，其使用時機當有SD卡插上會要求設定這些以啓動插入的SD卡。

struct mmc_host_ops {

void (*request)(struct mmc_host *host, struct mmc_request *req);

void (*set_ios)(struct mmc_host *host, struct mmc_ios *ios);

int (*get_ro)(struct mmc_host *host);

int (*get_cd)(struct mmc_host *host);

void (*enable_sdio_irq)(struct mmc_host *host, int enable);

};

這是設定讓SD host所能提供功能，而其中的request最為重要，它是SD要對SD卡任何的動作需求，包含讀寫資料，以其它SD控制指令下達，set_ios則是設定以上資料結構的call back function，get_ro則是回覆這個SD卡是否可以寫入。

struct mmc_host {

struct device *parent;

struct device class_dev;

int index;

const struct mmc_host_ops *ops;

unsigned int f_min;

unsigned int f_max;

u32 ocr_avail;

unsigned long caps; /* Host capabilities */

/* host specific block data */

unsigned int max_seg_size; /* see blk_queue_max_segment_size */

unsigned short max_hw_segs;/* see blk_queue_max_hw_segments */

unsigned short max_phys_segs; /* see blk_queue_max_phys_segments */

unsigned short unused;

unsigned int max_req_size; /* maximum number of bytes in one req */

unsigned int max_blk_size; /* maximum size of one mmc block */

unsigned int max_blk_count; /* maximum number of blocks in one req */

/* private data */

spinlock_t lock; /* lock for claim and bus ops */

struct mmc_ios ios; /* current io bus settings */

u32 ocr; /* the current OCR setting */

/* group bitfields together to minimize padding */

unsigned int use_spi_crc:1;

unsigned int claimed:1; /* host exclusively claimed */

unsigned int bus_dead:1; /* bus has been released */

#ifdef CONFIG_MMC_DEBUG

unsigned int removed:1; /* host is being removed */

#endif

struct mmc_card *card; /* device attached to this host */

wait_queue_head_t wq;

struct delayed_work detect;

const struct mmc_bus_ops *bus_ops; /* current bus driver */

unsigned int bus_refs; /* reference counter */

unsigned int sdio_irqs;

struct task_struct *sdio_irq_thread;

atomic_t sdio_irq_thread_abort;

#ifdef CONFIG_LEDS_TRIGGERS

struct led_trigger *led; /* activity led */

#endif

struct dentry *debugfs_root;

#ifdef CONFIG_MMC_EMBEDDED_SDIO

struct {

struct sdio_cis *cis;

struct sdio_cccr *cccr;

struct sdio_embedded_func *funcs;

int num_funcs;

} embedded_sdio_data;

#endif

unsigned long private[0] ____cacheline_aligned;

};

這是記錄SD host的一些資訊，SD中所有驅動程式將會隨時使用這個資訊。

struct mmc_command {

u32 opcode;

u32 arg;

u32 resp[4];

unsigned int flags; /* expected response type */

unsigned int retries; /* max number of retries */

unsigned int error; /* command error */

* Standard errno values are used for errors, but some have specific

* meaning in the MMC layer:

* ETIMEDOUT Card took too long to respond

* EILSEQ Basic format problem with the received or sent data

* (e.g. CRC check failed, incorrect opcode in response

* or bad end bit)

* EINVAL Request cannot be performed because of restrictions

* in hardware and/or the driver

* ENOMEDIUM Host can determine that the slot is empty and is

* actively failing requests

struct mmc_data *data; /* data segment associated with cmd */

struct mmc_request *mrq; /* associated request */

};

這個資料結構只有在下指令時會用到，但是有一個很重要的概念是，讀寫資料也是指令的一種，所以意思就是SD的管理層軟體全部使用command和實體的驅動程式做溝通。

struct mmc_data {

unsigned int timeout_ns; /* data timeout (in ns, max 80ms) */

unsigned int timeout_clks; /* data timeout (in clocks) */

unsigned int blksz; /* data block size */

unsigned int blocks; /* number of blocks */

unsigned int error; /* data error */

unsigned int flags;

unsigned int bytes_xfered;

struct mmc_command *stop; /* stop command */

struct mmc_request *mrq; /* associated request */

unsigned int sg_len; /* size of scatter list */

struct scatterlist *sg; /* I/O scatter list */

};

這是當指令為讀寫資料時會用到的資料結構，其中有包含要存放的buffer，但有點很重要，就是這個buffer是使用page的管理，而不是raw buffer的方式。

struct mmc_request {

struct mmc_command *cmd;

struct mmc_data *data;

struct mmc_command *stop;

void *done_data; /* completion data */

void (*done)(struct mmc_request *);/* completion function */

};

這是來存放指令的資料結構。

範例程式

static void vicsd_request(struct mmc_host *mmc, struct mmc_request *mrq)

{

struct vicsd_host *host=mmc_priv(mmc);

struct mmc_command *cmd;

spin_lock(&host->lock);

host->mrq = mrq;

cmd = mrq->cmd;

// if no card inserted, return timeout error

if ( readl(&host->reg->status) & MSD_CARD_DETECT ) { // card is removed

cmd->error = MMC_ERR_TIMEOUT;

goto request_done;

}

// request include data or not

if ( cmd->data ) {

vicsd_prepare_data(host, cmd->data);

}

// do request command

vicsd_send_command(host, cmd);

if ( cmd->data && cmd->error == MMC_ERR_NONE ) {

spin_unlock(&host->lock);

return;

}

request_done:

vicsd_request_done(host);

spin_unlock(&host->lock);

}

static void vicsd_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)

{

struct vicsd_host *host=mmc_priv(mmc);

spin_lock(&host->lock);

if (ios->clock) {

// set SD host controller frequency

} else if ( !(readl(&host->reg->clock_control) & MSD_CLK_DIS) ) {

* Ensure that the clock is off.

}

if ( ios->power_mode == MMC_POWER_OFF ) {

// power off host controller

} else {

// power on host controller

}

#if 1

// set bus width

if ( ios->bus_width == MMC_BUS_WIDTH_1 ) {

………………………….

} else {

…………………………..

}

#endif

spin_unlock(&host->lock);

}

static int vicsd_get_ro(struct mmc_host *mmc)

{

struct vicsd_host *host=mmc_priv(mmc);

if ( readl(&host->reg->status) & MSD_WRITE_PROT )

return 1;

else

return 0;

}

static struct mmc_host_ops vicsd_ops = {

.request = vicsd_request,

.set_ios = vicsd_set_ios,

.get_ro = vicsd_get_ro,

};

static int vicsd_probe(struct platform_device *pdev)

{

struct device *dev = &pdev->dev;

struct mmc_host *mmc;

int ret;

// allocate a MMC host data structure

mmc = mmc_alloc_host(sizeof(struct vicsd_host), dev);

if (!mmc) {

ret = -ENOMEM;

goto out;

}

// initialize the MMC host data structure

mmc->ops = &vicsd_ops;

mmc->f_min = 400000;

mmc->f_max = 25000000;

mmc->mode = MMC_MODE_SD;

#if 1

mmc->ocr_avail = 0xffff00; // support 2.0v - 3.6v power

#else

mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;

mmc->caps = MMC_CAP_4_BIT_DATA;

mmc->max_hw_segs = 128;

mmc->max_phys_segs = 128;

mmc->max_sectors = 128;

mmc->max_seg_size = mmc->max_sectors * 512;

#endif

host = mmc_priv(mmc);

host->mmc = mmc;

…………………………………………………..

* Ensure that the host controller is shut down, and setup

* with our defaults.

// reset the SD card controller

………………………………………………

// to check any card inserted or not

……………………………………………

// initialize the SD card host register

…………………………………………..

dev_set_drvdata(dev, mmc);

mmc_add_host(mmc);

return 0;

out:

if (mmc)

mmc_free_host(mmc);

return ret;

}

static struct platform_driver vicsd_driver = {

.probe = vicsd_probe,

.remove = vicsd_remove,

.suspend = vicsd_suspend,

.resume = vicsd_resume,

.driver = {

.name = "victor-sd",

};

static int __init vicsd_init(void)

{

int ret;

ret=platform_driver_register(&vicsd_driver);

if ( ret ) {

printk("fail !\n");

platform_driver_unregister(&vicsd_driver);

} else {

vicsd_device = platform_device_alloc("moxart-sd", -1);

if (!vicsd_device) {

platform_driver_unregister(&vicsd_driver);

return -ENOMEM;

}

ret = platform_device_add(vicsd_device);

if (ret) {

platform_device_put(vicsd_device);

platform_driver_unregister(&vicsd_driver);

return ret;

}

printk("OK.\n");

}

return ret;

}

static void __exit vicsd_exit(void)

{

platform_driver_unregister(&vicsd_driver);

}

module_init(vicsd_init);

module_exit(vicsd_exit);

如何撰寫Driver支援sysfs檔案系統

2011-04-26T23:20:00.000+08:00

前言

在現在Linux的系統中，有一個新的虛擬檔案系統，叫做sysfs，它只要是來管理Linux系統中的週邊元件，及配合使用公用程式來自動產生device node。其實它是一個虛擬的記憶體檔案系統，它是由proc所變化而來的，它是由各個driver所產生，換另一句話就是要Driver有撰寫才會有這樣的功能，它是繼承kobject的資料結構，另外其檔名及內容都是driver自行解決，目前主要都是來設定driver自己本身的一些功能，這樣可以讓驅動程式更多元化，或者可以讀取驅動程式現在的情形為何，這可以來維護系統的運作，現在有很多驅動程式已經支援這個功能，所以有許多的系統管理程式，也是透過這個介面來管理系統核心。現在我們來介紹如何在driver中撰這些程式碼。

如何啓動這個目錄

因為它是一個虛擬的記憶體檔案系統，所以將使用Linux系統中管理檔案系統一樣的方法，就是使用mount的指令將其掛載在作業系統的檔案系統中，以下為單獨載入的指令：

> mount –t sysfs sysfs /sys

另外在kernel的選項中必須要啓動以下選項：

CONFIG_SYSFS=y

系統驅動程式結構

圖一：驅動程式系統架構

以圖一中來看將會有一個RTC class產生，它將會統籌管理系統中所有的RTC元件，而系統中所有的RTC將會和它來做一個註冊，如此會產生一個RTC的class及其底下的RTC0, RTC1 ….. RTCn，其會在/sys/class之下會建立一個RTC的目錄，而每一個註冊的RTC元件將會在RTC class目錄之下產生RTC0至RTCn的子目錄，而每一個子目錄將會各別產生或者說是繼承RTC class的各個檔案。

Kernel API

在介紹如何撰寫前，先來了解有那些kernel API可供使用，其所用的include file是，而API如下：

struct class *class_create(struct module *owner, const char *name)

這是建立一個模組的類別，其input/output說明如下：

Input :

struct module *owner – 模組的擁有者，通常是設定為THIS_MODULE。

const char *name –要建立之類別名稱，之後可以建立在這個類別之下的檔案。

Output :

其返回值為一個class資料結構的位址point，這個資料結構會在後面介紹，這個point位址將會給予保留，因為我們需要在其中幾個call back欄位填入我們要實現的功能，也就是提供給AP如何溝通的介面。

extern struct device *device_create(struct class *cls, struct device *parent, dev_t devt, void *drvdata, const char *fmt, ...) __attribute__((format(printf, 5, 6)));

#define device_create_drvdata device_create

這是在該類別之下建立一個週邊元件，也就是建立一個device。

Input :

struct class *cls – 是前一個API所return回來的class pointer。

struct devuce *parent – 為該元件的上一層driver為何若没有可以設定為NULL。

dev_t devt – 這是該元件的major number & minor number的結合，可以使用巨集指令MKDEV()來產生。

const char *fmt – 為該元件的device node名稱。

Output :

其返回值為一個device的資料結構，可讓driver其它地方使用。

資料結構

如前面所提，其中最重要的資料結構宣告如下：

struct class {

const char *name;

struct module *owner;

struct class_attribute *class_attrs;

struct device_attribute *dev_attrs;

struct kobject *dev_kobj;

int (*dev_uevent)(struct device *dev, struct kobj_uevent_env *env);

void (*class_release)(struct class *class);

void (*dev_release)(struct device *dev);

int (*suspend)(struct device *dev, pm_message_t state);

int (*resume)(struct device *dev);

struct pm_ops *pm;

struct class_private *p;

};

其中的成員struct device_attribute *dev_attrs; 是比較重要，這是設定在這類別之下所建立的元件都會繼承這些基設定，而每一個設都可以設定為唯讀或可讀寫，可以參考以下範例得到較清楚的解答。

範例程式

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/spinlock.h>

#include <linux/mutex.h>

#include <linux/tty.h>

#include <linux/proc_fs.h>

#include <linux/timer.h>

#include <linux/sysfs.h>

#include <linux/device.h>

#include <linux/platform_device.h>

#include <asm/uaccess.h>

#define VICTOR_DEBUG

#include "../include/mydebug.h"

#define MY_MAJOR 40

struct class *sysfs_class;

static ssize_t

sysfs_show_name(struct device *dev, struct device_attribute *attr, char *buf)

{

return sprintf(buf, "show name\n");

}

static ssize_t

sysfs_show_date(struct device *dev, struct device_attribute *attr, char *buf)

{

ssize_t retval;

retval = sprintf(buf, "show date\n");

return retval;

}

這是一個讀取的call back function，必需返回共有多少的bytes放在buffer中。

static ssize_t

sysfs_show_time(struct device *dev, struct device_attribute *attr, char *buf)

{

ssize_t retval;

retval = sprintf(buf, "show time\n");

return retval;

}

static ssize_t

sysfs_show_max_user_freq(struct device *dev, struct device_attribute *attr, char *buf)

{

return sprintf(buf, "show max user freq\n");

}

這是一個寫入的call back functio，一樣必需返回共有多少bytes被處理。

static ssize_t

sysfs_set_max_user_freq(struct device *dev, struct device_attribute *attr, const char *buf, size_t n)

{

printk("get string = %s\n", buf);

return n;

}

以下設定中，S_IRUGO表示唯讀而己，S_IWUR表示可以寫入，而相對應的call back function必需要實現，其定義在linux/stat.h之。

static struct device_attribute sysfs_attrs[] = {

__ATTR(name, S_IRUGO, sysfs_show_name, NULL),

__ATTR(date, S_IRUGO, sysfs_show_date, NULL),

__ATTR(time, S_IRUGO, sysfs_show_time, NULL),

__ATTR(max_user_freq, S_IRUGO | S_IWUSR, sysfs_show_max_user_freq, sysfs_set_max_user_freq),

{ },

};

static int sysfs_suspend(struct device *dev, pm_message_t mesg)

{

dbg_printk("\n");

return 0;

}

static int sysfs_resume(struct device *dev)

{

dbg_printk("\n");

return 0;

}

static int __init mysysfs_init(void)

{

dbg_printk("\n");

sysfs_class = class_create(THIS_MODULE, "mysysfs");

if (IS_ERR(sysfs_class)) {

printk(KERN_ERR "%s: couldn't create class\n", __FILE__);

return PTR_ERR(sysfs_class);

}

dbg_printk("class create OK.\n");

sysfs_class->suspend = sysfs_suspend;

sysfs_class->resume = sysfs_resume;

sysfs_class->dev_attrs = sysfs_attrs;

device_create_drvdata(sysfs_class, NULL, MKDEV(200, 0), NULL, "mysysfs0");

return 0;

}

static void __exit mysysfs_exit(void)

{

dbg_printk("\n");

device_destroy(sysfs_class, MKDEV(200, 0));

class_destroy(sysfs_class);

}

module_init(mysysfs_init);

module_exit(mysysfs_exit);

如何撰寫Driver支援proc檔案系統

2011-04-06T22:32:00.000+08:00

前言

在Linux的系統中，通常我們都會有一個目錄 – proc，其實它是一個虛擬的記憶體檔案系統，它通常是一個應用程式和kernel直接溝通的一個介面，它是由各個driver所產生，換另一句話就是要Driver有撰寫才會有這樣的功能，另外其檔名及內容都是driver自行解決，目前主要都是來設定driver自己本身的一些功能，這樣可以讓驅動程式更多元化，或者可以讀取驅動程式現在的情形為何，這可以來維護系統的運作，現在有很多驅動程式已經支援這個功能，所以有許多的系統管理程式，也是透過這個介面來管理系統核心。現在我們來介紹如何在driver中撰這些程式碼。

如何啓動這個目錄

> mount –t proc proc /porc

另外在kernel的選項中必須要啓動以下選項：

CONFIG_PROC_FS=y

CONFIG_PROC_SYSCTL=y

Kernel API

在介紹如何撰寫前，先來了解有那些kernel API可供使用，其所用的include file是，而API如下：

struct proc_dir_entry *create_proc_entry(const char *name, mode_t mode, struct proc_dir_entry *parent)

這是建立一個在相對目錄之下的一個檔名或目錄，其input/output說明如下：

Input :

const char *name – 想要建立的檔名，相對於後面的parent的目錄之下，若後面的parent為NULL，則其相對目錄為/proc之下，另外這個檔名也可以包含目錄。

mode_t mode – 前面所要建立之名稱為檔案或者是目錄，0為檔案，S_IFDIR為目錄。

struct proc_dir_entry *parent – 這次要建立的檔名或者目錄，其上層的目錄為何，若這個參數為NULL則表示為/proc目錄。

Output :

其返回值為一個資料結構的位址point，這個資料結構會在後面介紹，這個point位址將會給予保留，因為我們需要在其中幾個call back欄位填入我們要實現的功能，也就是提供給AP如何溝通的介面。

void remove_proc_entry(const char *name, struct proc_dir_entry *parent);

這是移除已建立的檔案或目錄，其中輸入的參數皆和建立時相同。

以下為一個簡單的範例：

struct proc_dir_entry *MyProcEntry;

MyProcEntry = create_proc_entry(“driver/myproc”, 0, NULL);

MyProcEntry->read = MyProcRead;

MyProcEntry->write = MyProcWrite;

……………………………….

remove_proc_entry(“driver/myproc”, NULL);

資料結構

如前面所提，其中最重要的資料結構宣告如下：

struct proc_dir_entry {

unsigned int low_ino;

unsigned short namelen;

const char *name;

mode_t mode;

nlink_t nlink;

uid_t uid;

gid_t gid;

loff_t size;

const struct inode_operations *proc_iops;

* NULL ->proc_fops means "PDE is going away RSN" or

* "PDE is just created". In either case, e.g. ->read_proc won't be

* called because it's too late or too early, respectively.

* If you're allocating ->proc_fops dynamically, save a pointer

* somewhere.

const struct file_operations *proc_fops;

struct proc_dir_entry *next, *parent, *subdir;

void *data;

read_proc_t *read_proc;

write_proc_t *write_proc;

atomic_t count; /* use count */

int pde_users; /* number of callers into module in progress */

spinlock_t pde_unload_lock; /* proc_fops checks and pde_users bumps */

struct completion *pde_unload_completion;

struct list_head pde_openers; /* who did ->open, but not ->release */

};

在這個資料結構中有兩個重要的call back function，一個是read_proc，另一個是write_proc，其實就是寫入及讀出。以下為其簡單的範例：

static int my_read_proc(char *page, char **start, off_t off, int count, int *eof, void *data)

{

char *out = page;

int len;

dbg_printk("page=0x%p,off=0x%x,count=%d\n", page, off, count);

out += sprintf(out, "This is a read proc testing.\n");

dbg_printk("out=0x%p\n", out);

len = out - page - off;

dbg_printk("len=%d,out=0x%p\n", len, out);

if (len < count) {

*eof = 1;

if (len <= 0)

return 0;

} else

len = count;

*start = page + off;

dbg_printk("start=0x%p\n", start);

return len;

}

static int my_write_proc(struct file *file, const char __user *buffer, unsigned long count, void *data)

{

char *buf;

dbg_printk("count=%d\n", count);

buf = kmalloc(count+1, GFP_KERNEL);

if ( copy_from_user(buf, (char*)buffer , count) ) {

kfree(buf);

return -EFAULT;

}

buf[count] = 0;

dbg_printk("string=%s\n", buf);

kfree(buf);

return count;

}

在read call back function中所傳入的page為要存放輸出內容的buffer所在page address，其off為相對於page的offset位置，通常為0，不管read or write其所return的值為實際處理的大小，因為其處理方式為page的方式，所以一次可處理的資料不會大於一個page的大小，現在default值為4096bytes，以上的範例若是成功將可以產生一個虛擬檔案/proc/driver/myproc，你將可以使用簡單的echo & cat來對其做讀寫的動作。

如何撰寫ARM CPU的Linux PCI Host 驅動程式

2011-03-03T23:27:00.000+08:00

簡介

PCI是一種BUS，它可以讓你擴充週邊元件的一種BUS，在PC上使用非常普遍，因為它是一個共同的標準介面，所以它可以讓很多的週邊元件附加在這個電腦上，而且可以很容易地附加進來，雖然現在的嵌入式系統已經把很多的週邊已SoC在CPU裏面，可是有時候在成本的考量，由PCI來擴充週邊，就不會有必須要的現象產生，因為他可以選擇，這樣就不會造成SoC的CPU成本過高，另外把過多的週邊元件SoC會造成CPU用電過高，更進而造成過熱現象產生，造成必需使用其它的煽熱元件，如鋁片或者風扇等，這會造成產品體積變大，成本增加，等問題產生。

PCI的另一個好處是它是一個PNP的BUS，對資源的分配及取得是較有彈性，如此一來對軟體撰寫者也是一大好處，因為這樣一來軟體較容易移植至各個不同的CPU平台，而不需要因為不同的CPU而撰寫不同的程式。

ARM和x86的PCI有何不同

以硬體來說是没有不同，因為它本來就是一種標準，那在軟體上有何不同？因為在x86上只有一種CPU，而且它的PCI Host的IC都一樣，並不會因為不同的生產廠商而有所不同，也因此在PCI Host的驅動程式都是OS廠商所撰寫好了，但是每家的ARM CPU廠商所生產的PCI Host的控制器都不同，所以軟體人員必須各別撰寫，以應付不同的CPU廠商，也是為什麼我們必須要知道如何撰寫PCI Host驅動程式。

另外PCI它是一種主從式架構，host端是由主機板廠商所負責，x86平台它通常會留下幾個標準的slot讓使用者可以購買其它的client的擴充卡來增加週邊元件，在ARM base的嵌入系統中，通常PCI Host會是SoC在CPU內，對於client的元件，原則上不會是做成slot再插卡，通常是直接拉PCI Bus的訊號線從PCI Host至PCI client，如此一來就可節省空間及成本。

PCI Bus開機順序

PCI Bus在開機程序中，開機時PCI Host會先自我控制器做初始化程序，之後會將可分配及使用的資源和系統登錄，之後將掃描是否有PCI client的週邊元件接上，若有則依照它們所要求的資源分配給它們，分配完之後則檢查是否有相對應的client端登錄驅動程式，若有則呼叫其所登錄的call back function，而這個call back function則是PCI client的驅動程式所登錄，在這個call back function中通常所完成的事是初始化其元件，PCI host將會逐一已插上的PCI client重覆前面的動作，一直到所有已插上的週邊元件都完成分配資源。

PCI Configuration Table

在PCI host和PCI client之間有一個表叫做configuration table，該表有256字元，它是做為host和client之間溝通資源分配及其資訊交換的表格，其內容如下：

以上所看到是我們較會用到的部分，這份表是存放在PCI client上的，其中的幾個重要欄位說明如下：

Vendor ID & Device ID是唯讀的，PCI host將會把它存起來，PCI client也是用這兩個ID來向host做註冊，host也會拿它來做比對，當前面所提要呼叫client端時才知道要呼叫那一個驅動程式。
command則是host有些動作需要client端來做時所下的指令，而這些指令在PCI的標準有定義。
status是目前client現狀的表示，也是PCI標準中有所定義。
Base Address Registers是非常重要的項目，它是client和host端資源描述的地方，而且它是一個雙向溝通的資料，對32位元的設備來說則總共最多有6個資源可以取得，若是64位元的設備，則最多只有3個資源可以取得，其實做法很簡單，就是將兩個32位元合成一個64位元。在此我們只說明32位元的設備，因為目前64位元的嵌入式並不多見，在說明之前我們先了解一件事，就是當CPU和週邊做溝通有兩個路徑，一個是I/O存取，一個記憶體存取，這在硬體上有所差異，所以在這欄位使用最低的兩個位元來表示需求何種資源，以二進位來看，00代表是需要記憶，01代表是需要 I／O，所耍的大小從位元2開始，若不需要則填零，不然則填其所需的大小，當PCI Host掃描之後會將該client週邊所分配到的起始位置填回，如此完成資源的分配。

PCI Host實做
在了解了PCI Bus的基本定義之後我們開始要來談實做的部分，在PCI Host部分，因為像前面所提的部分標準和硬硬體無關，或者另外的說法是硬體工作內容是一樣，因為這部分已由GNU所撰寫好，我們並不需要做任何更動，這部分的原始碼在kernel source的drivers/pci目錄之下，我們所要寫的是HAL部分，你必須在arch/arm/mach-xxxx的目錄之下（這個目錄是你在porting一個SoC時會建立的目錄，其中的xxxx是你自行定義的名稱），撰寫一個PCI Host的一個C程式，而在這程式有幾個部分需要撰寫，首先需要宣告一個資料結構如下：

struct hw_pci ixdp425_pci __initdata = {

.nr_controllers = 1,

.preinit = ixdp425_pci_preinit,

.swizzle = pci_std_swizzle,

.setup = ixp4xx_setup,

.scan = ixp4xx_scan_bus,

.map_irq = ixdp425_map_irq,

};

先在此說明一下這個資料結構的定義，其資料結構原型為struct hw_pci，其定義在arch/arm/mach/pci.h (這是kernel版本2.6.31之後，ixdp425_pci 是使用者自行取的名字，__initdata定義為這個資料在kernel初始化之後會給予free收回使用），其各個成員說明如下：

.nr_controllers

是指示有多少個PCI host控制器，通常都是只有一個。

.preinit

這是在初始化該PCI host chipset的call back function，這也是和各個SoC有所不同，所要做的初始化內容也不盡相同，當註冊一個PCI Host時第一個被呼叫的副程式，若有需要中斷的設定，必需要在此完成和系統註冊。

.setup

它是一個call back function pointer，在這個副程式原型為int ixp4xx_setup(int nr, struct pci_sys_data *sys)，所以系統會將第幾個PCI host controller - nr以及一個指標struct pci_sys_data *sys，在呼它時傳送給它，這個指標將會是需要填入這PCI Host controller可以使用的資源，以下是一個範例：

struct resource *res;

res = kzalloc(sizeof(*res) * 2, GFP_KERNEL);

res[0].name = "PCI I/O Space";

res[0].start = 0x00000000;

res[0].end = 0x0000ffff;

res[0].flags = IORESOURCE_IO;

res[1].name = "PCI Memory Space";

res[1].start = 0x4b000000;

res[1].end = 0x4bffffff;

res[1].flags = IORESOURCE_MEM

request_resource(&ioport_resource, &res[0]);

request_resource(&iomem_resource, &res[1]);

sys->resource[0] = &res[0];
sys->resource[1] = &res[1];

sys->resource[2] = NULL;

從以上的註冊系統將會保留所要的資源，而在之前所提的標準的PCI driver會協助分配資源給PCI client，所以之後如何分配及管理這些資源，你就不用費心了。

.scan

這是系統要開始掃描在PCI Bus有插上那些PCI client時會呼叫的副程式，通常都會直接再展轉呼叫系統的掃描程式，以下是其範例程式：

return pci_scan_bus(sys->busnr, &ixp4xx_ops, sys);

在以上的sys變數為系統傳過來的，ixp4xx_ops則是我們所要準備的一些有關PCI Bus設定的一些HAL call back function，其內容為如下：
struct pci_ops ixp4xx_ops = {
.read = ixp4xx_pci_read_config,
.write = ixp4xx_pci_write_config,
};

上面其的read/write為在讀寫前面所談的configuration table的方式，這和每一個晶片不同，其控制的位置也不同，所以根據每一顆SoC來寫，而這兩個的函數原型如下：

int ixp4xx_pci_read_config(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *value)

int ixp4xx_pci_write_config(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 value)

在系統呼叫進來的bus的資料結構中成員bus->number是這個系統中第幾個bus，在控制晶片時可能會用到，devfn則是slot number和function number的結合，你可以使用巨集指令PCI_SLOT()或PCI_FUNC()分別取得其資訊，size則是表示1 or 2 or 4 bytes的存取，where則是需要特別注意，它是在存取1 or 2 bytes會用到，在256 bytes的configuration table的相對位置，大部分PCI host 控制器會有boundary存取的問題，這邊需要特別注意做轉換，value則是較簡單，是讀取或寫入所放的值。

.map_irq

則是當PCI Host在掃描時在要指定IRQ時會呼叫這個副程式，而這個副程式則會回傳要指定的中斷號碼。

當以上的資料準備好之後，你需要撰寫一個初始化的進入點，讓系統開機會呼叫這個初始化副程式，以下為其範例：

int __init ixdp425_pci_init(void)

{

return pci_common_init(&ixdp425_pci);

}

subsys_initcall(ixdp425_pci_init);

由以上的程式碼可以看到，該程式會直接呼叫系統的pci_common_init()而且給它前面所提的資料結構，當你呼叫該系統程式時，系統會馬上呼叫你所給的資料結構中的preinit call back function，之後會呼叫setup call back function，再接著就是呼叫scan call back function，如此而完成一個PCI host的載入動作，以下用流程圖來表示如下：

最後記得用巨集指令subsys_initcall()將你所完成的副程式註冊為一個開機會被呼叫的副程式。

PCI Host需要注意的地方

原則上在以上所說明的應該就完成了PCI Host的移植，因為我們在移植時只要完成這部分會和硬體有關的 HAL 層即可，但是還是有一些地方必需要注意，第一個就是在x86的平台上是有所謂的I/O存取，我是指CPU本身就有這個支援，CPU對週邊的元件的存取方式，本來就有兩種，一種是記憶體存取，一種是I/O存取，而在PCI bus也有這兩種的存取方式，所以這兩種不同的存取方法，被視為兩種不同的資源，但是在ARM CPU中是没有I/O 存取的，它只有記憶體存取，而我們在寫驅動程式時若是I/O存取則會使用inb(), oub(), inw(), outw(), inl(), outl()等副程式，若是記憶體存取則會使用readb(), writeb(), readw(), writew(), readl(), writel()等副程式，因為ARM CPU沒有I/O 存取所以在HAL層會將inx(), outx()等副程式內容改寫，改成使用記憶體存取，如此一來應是沒有任何問題才對，問題在於對於I/O存取的驅動程式，對於所使的資源(也就所分配到的I/O 位置)不會將其轉換為虛擬位址，可是如此一來將會產生非法存取記憶體位置，因為kernel一啓動所有的程式碼都需要使用虛擬位址，對於這個問題有幾個解決方法，第一個是修改PCI client的驅動程式碼，可是這會有一個缺點，那就是這個原始碼必需只能使用在你的ARM平台，其它如x86的平台將無法使用，另外你也必需修改你的驅動程式，所以個人比較不喜歡這個方式，另一個方式則是修改我的PCI host的資源分配，很簡單的做法，就是前面有提到在初始化時需要將可分配的資源向系統註冊，註冊前先將其轉換為虛擬位址，再向系統註冊就可以了，如此的修改不多，又沒有前一個方法的問題，並且前面已說明我們本來就是需要修改PCI host的程式碼。

同樣是存取方式的問題，我們先看以下的表示圖，再來討論這個問題：

因為ARM CPU只有記憶體存取的方式，而PCI bus卻有兩種（記憶體和I/O的存取方式），另外PCI host的晶片有兩種，一種是它本身對PCI bus的兩種不同存取方式會做自動的轉換，意思對於PCI client是使用I/O存取方式的週邊，它會自動將ARM CPU過來的記憶體存取方式，自動轉換為I/O存取方式，所以對於前面所提的第二種I/O存取方式的修改將可以達成，而對於ARM CPU的記憶體存取方式，則可以直接轉換至PCI bus即可，對於這種PCI Host的晶片可以省卻我們很多工夫。但是有另外一種PCI host晶片是不會如此做的，對於這種晶片則是較麻煩的，對於這種晶片你必須控其中的一些暫存器在PCI bus上做出I/O 存取的訊號，以下則是其寫法說明（這是在2.6.31之後的寫法）：

首先你必須在arch/arm/mach-xxxx的目錄之下，建立一個檔案include/mach/io.h，請注意其路徑及檔名不可更改，因為在整個kernel 原始碼中的Makefile及編譯時要尋找C語言的include file路徑都已寫好，你若更改將會造成編譯錯誤，在這個檔案之中將可以改寫ARM CPU已內定改好的inx()及outx()的副程式，若你在這個檔案之中宣告如下：

#define __io(v) __typesafe_io(v)

表示使用ARM CPU中己改好的inx()及outx()副程式，這是使用PCI host會自動轉換I/O 存取至PCI bus的晶片，若不是你所需要的修改如下：

#define outb(p, v) __ixp4xx_outb(p, v)

#define outw(p, v) __ixp4xx_outw(p, v)

#define outl(p, v) __ixp4xx_outl(p, v)

#define outsb(p, v, l) __ixp4xx_outsb(p, v, l)

#define outsw(p, v, l) __ixp4xx_outsw(p, v, l)

#define outsl(p, v, l) __ixp4xx_outsl(p, v, l)

#define inb(p) __ixp4xx_inb(p)

#define inw(p) __ixp4xx_inw(p)

#define inl(p) __ixp4xx_inl(p)

#define insb(p, v, l) __ixp4xx_insb(p, v, l)

#define insw(p, v, l) __ixp4xx_insw(p, v, l)

#define insl(p, v, l) __ixp4xx_insl(p, v, l)

你必需針對每一個副給予重新定義至另一個你改寫的內容，而這些改寫的內容則是針對你所使用的PCI host晶片做控制，以下為其範例：

static inline void

__ixp4xx_outb(u8 value, u32 addr)

{

u32 n, byte_enables, data;

n = addr % 4;

byte_enables = (0xf & ~BIT(n)) << IXP4XX_PCI_NP_CBE_BESL;

..........................

return data >> (8*n);

}

.................................

另外幾個和I/O有關的副程式你也必需重新改寫如下：

#define ioread8(p) __ixp4xx_ioread8(p)

#define ioread16(p) __ixp4xx_ioread16(p)

#define ioread32(p) __ixp4xx_ioread32(p)

#define ioread8_rep(p, v, c) __ixp4xx_ioread8_rep(p, v, c)

#define ioread16_rep(p, v, c) __ixp4xx_ioread16_rep(p, v, c)

#define ioread32_rep(p, v, c) __ixp4xx_ioread32_rep(p, v, c)

#define iowrite8(v,p) __ixp4xx_iowrite8(v,p)

#define iowrite16(v,p) __ixp4xx_iowrite16(v,p)

#define iowrite32(v,p) __ixp4xx_iowrite32(v,p)

#define iowrite8_rep(p, v, c) __ixp4xx_iowrite8_rep(p, v, c)

#define iowrite16_rep(p, v, c) __ixp4xx_iowrite16_rep(p, v, c)

#define iowrite32_rep(p, v, c) __ixp4xx_iowrite32_rep(p, v, c)

#define ioport_map(port, nr) ((void __iomem*)(port + PIO_OFFSET))

#define ioport_unmap(addr)

#define PIO_OFFSET 0x10000UL

#define PIO_MASK 0x0ffffUL

#define __is_io_address(p) (((unsigned long)p >= PIO_OFFSET) && \

((unsigned long)p <= (PIO_MASK + PIO_OFFSET)))

static inline unsigned int

__ixp4xx_ioread8(const void __iomem *addr)

{

unsigned long port = (unsigned long __force)addr;

if (__is_io_address(port))

return (unsigned int)__ixp4xx_inb(port & PIO_MASK);

else

return (unsigned int)__ixp4xx_readb(addr);

}

..........................................

static inline void

__ixp4xx_iowrite8(u8 value, void __iomem *addr)

{

unsigned long port = (unsigned long __force)addr;

if (__is_io_address(port))

__ixp4xx_outb(value, port & PIO_MASK);

else

__ixp4xx_writeb(value, addr);

}

....................................

除此之外有些PCI host的晶片對於ARM CPU的記憶體存取方式也不會直接自動轉換至PCI bus，和I/O存取一樣必須控制PCI host晶片來產生一個PCI bus上的記憶體存取，其改寫內容和I/O改寫很像，一樣的你若不需要改寫，使用ARM CPU內定的程式碼則必需有一個以下的宣告：

#define __mem_pci(a) (a)

若要改寫以下為其範例：

#define writeb(v, p) __ixp4xx_writeb(v, p)

#define writew(v, p) __ixp4xx_writew(v, p)

#define writel(v, p) __ixp4xx_writel(v, p)

#define writesb(p, v, l) __ixp4xx_writesb(p, v, l)

#define writesw(p, v, l) __ixp4xx_writesw(p, v, l)

#define writesl(p, v, l) __ixp4xx_writesl(p, v, l)

#define readb(p) __ixp4xx_readb(p)

#define readw(p) __ixp4xx_readw(p)

#define readl(p) __ixp4xx_readl(p)

#define readsb(p, v, l) __ixp4xx_readsb(p, v, l)

#define readsw(p, v, l) __ixp4xx_readsw(p, v, l)

#define readsl(p, v, l) __ixp4xx_readsl(p, v, l)

static inline void

__ixp4xx_writeb(u8 value, volatile void __iomem *p)

{

....................................

if (addr >= VMALLOC_START) {

__raw_writeb(value, addr);

return;

}
.............................

}

....................................

* We can use the built-in functions b/c they end up calling writeb/readb

#define memset_io(c,v,l) _memset_io((c),(v),(l))

#define memcpy_fromio(a,c,l) _memcpy_fromio((a),(c),(l))

#define memcpy_toio(c,a,l) _memcpy_toio((c),(a),(l))

最後有一個問題需要注意的是，通常對於使用記憶體存取的使用之前，做一個實體記憶體轉換為虛擬位址，若你的PCI host是前面的方式需要使用PCI host來產生一個存取動作，那麼你可以也需要改寫ioremap() & iounmap()的副程式，其範例程式如下：

static inline void __iomem *

__ixp4xx_ioremap(unsigned long addr, size_t size, unsigned int mtype)

{

if((addr <> 0x4fffffff))

return __arm_ioremap(addr, size, mtype);

return (void __iomem *)addr;

}

static inline void

__ixp4xx_iounmap(void __iomem *addr)

{

if ((__force u32)addr >= VMALLOC_START)

__iounmap(addr);

}

#define __arch_ioremap(a, s, f) __ixp4xx_ioremap(a, s, f)

#define __arch_iounmap(a) __ixp4xx_iounmap(a)

至此你應可以完成你的PCI Host的程式，而且可以讓你的PCI client的程式更有相容性，而可以使用在多種CPU之下，你也許會有疑問為何要如此的相容性？因為你的PCI client的驅動程式，可能由晶片廠商所提供，但是他們只有在x86的平台有測試過，為了可以無痛的使用這些原始碼，所以你必需了解以上所提的事。

如何啓動USB sound

2011-01-10T21:15:00.000+08:00

簡介

USB喇叭是一個標準的USB class，它是一個USB接頭直接接到一對喇叭，而在喇叭中直接有音訊解碼器及擴大機，可以讓你播放各音樂檔檔式，如mp3 or wav格式，在kernel中有其標準的驅動程式可供使用，在此說明如何在kernel source code做設定，以及要如何安裝才可以使用。

Kernel驅動程式的選項

在原始中已有現成的驅動程式，我們只要設定使用它就可以了，要設定原始碼，當然是執行' make menuconfig' 其選項如下 :
首先要進入‘Device Driver'的選項如下：

進入之後選擇'Sound'的選項如下：

啓動‘Sound card support'，之後再進入’Advanced Linux Sound Architecture'如下：

請將以上所有項目給予啓動，之後請按往下𨧞進入‘Generic devices'選項如下：

將以下所有選項啓動 :

回到上一個主單，進入‘USB devices'選項如下：

以上完成kernel的選項設定，重新編繹kernel即可 :

播放程式

有兩個簡單的播放程式可用：

mp3play - 這是一個可以播放MP3音樂檔格式的一個簡單應用程式。
play - 這是一個可以播放wav音樂檔格式的一個簡單應用程式。

以上兩個程式都可以在網路找到，並且將其重新編繹即可。

需要建立的Device Node

有幾個device node必需建立給應用程式使用如下：

> mknod dsp c 14 3

> mknod audio c 14 4

> mknod mixer c 14 0

需要載入的驅動程式

> modprobe snd_usb_audio

> modprobe snd_pcm_oss

若載入正常可以看到以下的驅動程式被載入：

若USB Speaker插入有被正常找到，你可以在目錄/proc/asound之下看到以下檔案：

這時你可以執行一下程式測試，若一切正常你可以聽到聲音，如此你也大功告成。

kernel的開機執行順序

2010-12-25T21:30:00.000+08:00

Linux是一個目前非常普遍的作業系統，因為它為免費且公開原始碼的作業系統，所以在嵌入系統中大家都很喜歡使用它，而且它的執行可以很小，且又有效率。我們現在就來大概地了解一下它的開機順序。

首先我們要了解的是，Linux kernel可以被編譯成兩種形式，一種是有壓縮的，另一種是沒有壓縮的，兩種形式其第一個執行指令不同，我們先來了解有壓縮的，它是將另一種沒有壓縮的kernel將其做壓縮，並在其前面加一段解壓縮的程式碼，而這段程式碼則是可以執行在記憶中任何位置，並且會將kernel作解壓縮之後放在記憶上，之後將其控制權交給kernel，之後的執行順序，有壓縮和没壓縮的順序是一樣的。

那麼我們先來看看有壓縮的第一個指令在那裹，以ARM CPU來說，它是在arch/arm/boot/compressed/head.S的程式裹，這一段是使用組合語言寫的，其中有兩個重要的暫存器，一個是r1存放的是CPU的代碼，這個代碼是由使用自行定義，由bootloader傳過來，這個值定義在arch/arm/tools/mach-types中，在編譯時會產生一個include/asm/mach-types.h，這時會使用CP15來讀回CPU的ID做比對，確認是否正確，並且使用相對應的cache操作副程式，因此在正確的CPU ID比對之後會啓動cache，以加快對kernel的解壓縮動作。

在解壓縮kernel之前，解壓縮程式會先檢查現在的位置是否和解壓縮之後的位址是否有衝突，若沒有則直接開始解壓縮，若有將會解壓縮至其它地方，之後再搬至最後kernel所要擺放的位置，並且跳至kernel的第一個指令，開始執行，而kernel的第一個指令放在arch/arm/kernel/head.S，開始執行時kernel會比對CPU ID是否正確，再初始化系統的cache HAL call back function，以及各種初始化動作，這些定在MACHINE_START的巨集宣告中，而這是使用者所宣告的，這時也會初始化整記憶體管理，最後會呼叫kernel_start，這是在init/main.c之中，接下來會載入各個driver，以及會mount root file system，當一切都好了之後則會呼叫第一支應用程式，default為/sbin/init，你可以在make menuconfig中將其更換你所要執行的程式，而這支程式可以是binary file也可以是shell script，到此就結束所有的開機動作。

如何製作kernel的default setting

2010-12-14T22:22:00.000+08:00

當我們取得kernel的source code之後，將其解壓縮，原則上我們第一動作當然會修改根目錄中的Makefile，將其ARCH & CROSS_COMPILE的環境變數修改，例如如下：

ARCH = arm

CROSS_COMPILE = arm-linux-

接著我們將會執行make menuconfig的動作，在結束這個動作之後會產生兩個一個是 .config 它是存在原紿檔的根目錄中，這個檔是給Makefile讀取用的，另一個檔為include/linux/autoconfig.h這是給kernel中的C程式用的，當你完成所有的開發之後，可以將 .config 檔拷貝至 arch/arm/default目錄之下，並且取名為 xxxx_defconfig，其中的 xxxx 為你個人自行取名，如此一來當其它人拿到你的source code之後不知該如何設定時，他可以先執行 make xxxx_defconfig 如此一來將會用你之前的設定設置至 .config & include/linux/autoconfig.h 之中，如此一來這將會是你的default setting。

Linux Device Driver的基本架構

2010-10-26T22:12:00.000+08:00

每一種OS都會有驅動程式, 而驅動程式主要是做為應用程式要使用各種系統的週邊元件的一中間橋樑, kernel接收及管理應用程式的需求, 並將其需求轉送給驅動程式, 而kernel將會處理多工的問題, 為了讓各種驅動程式好撰寫, 所以每一種OS將會規定驅動程式的寫法, 就好像C語言也有規定應用程式的寫法, 而在linux的OS中規定驅動程式的寫法如下：

目前都是使用C語言來撰寫驅動程式
程式務必include & include
每一個程式都會有一個進入點, 或者第一個指令的地方, linux device driver的進入點如下:

static int __init your_driver_name_init(void)

{

return 0;

}

module_init(your_driver_name_init);

其進入點的名字你可以隨意取一個名字, 但是其原型的宣告方式必須是固定的, 請參考上面的範例程式, 最後必須使用一個巨集指令module_init()來宣告其為程式進入點。

Linux的驅動程式可以是static link至kernel, 也可以是動態的方式, linux稱做module, 若是static的方式則必須要有完整的kernel source code, 並且在編譯時會將整個kernel source code編譯過, 而module的方式則不用, 只需要kernel的include檔即, 但是不管是static或者module其進入點宣告方式都一樣
離開或者是下載驅動程式時的進入點宣告如下 :

static void __exit your_driver_name_exit(void)

{

}

module_exit(your_driver_name_exit);

這和進入點一樣, 名字可以隨意取, 但是原型宣告則必須固定, 並且使用module_exit()巨集指令來確定離開驅動式的進入點。

以上是Linux的驅動程式的基本概念。

如何使用NFS做為開機時的root file system

2010-10-21T10:56:00.000+08:00

我們都知道Linux在開機時必須要mount一個檔案系統做為根目錄系統, 而這個根目錄通常會指定定在kernel bootup command line的root及rootfstype選項中指定, 但是初期我們在開發embedded系統時通常會有問題, 或者embedded flash的空間不大, 所以若可以使用NFS做為root file system, 將會對開發embedded系統來說會是一項非常方便的事情, 以下即是說明如何設定來使用NFS做為開機時的root file system。

若要使用NFS做為開機時的根目錄, 在kernel的選項中有幾個是必須被打開, 如NFS client (CONFIG_ROOT_NFS), 以及可以自動設定IP的選項, 如DHCP或者BOOTP或RARP, 這是讓kernel開機時即可取得IP address (CONFIG_IP_PNP), 因為NFS是架構在網路上。

而其中的boot command line的設定如下 :

root=/dev/nfs

而其中的/dev/nfs為一個虛擬的device node, 並不是真實存在, 所以也並不需要真的在檔案系統中建立這個device node

nfsroot=[{server-ip}:]{root-dir}[,{nfs-options}]

nfsroot是指定NFS server的資料，　若沒有指定nfsroot則會default使用/tftpboot/%s, 做為mount的點，其各個選項說明如下:

{server-ip} 是指定NFS server的IP address

{root-dir} 是指定NFS server export出來的目錄, 也是會被mount為根目錄的目錄

{nfs-options} 為選項如下：

port = portmap所使用的port number
rsize = 4096
wsize = 4096
timeo = 7
retrans = 3
acregmin = 3
acregmax = 60
acdirmin = 30
acdirmax = 60
flags = hard, nointr, noposix, cto, ac

ip={client-ip}:{server-ip}:{gw-ip}:{netmask}:{hostname}:{device}:{autoconf}

這是在設定embedded自已的IP address, 若沒有這個設定, 將會依照kernel中所設定的autoconf方法取得IP address, 這個設定可以如下各個情形：

ip="off"
ip="none"
ip=dhcp"
ip="autoconf"

其各選項說明如下 :

{client-ip} embedded自已本身的IP address

{server-ip} NFS server的IP address

{gw-ip} gateway IP address

{netmask} netmask

{hostname} embedded自已本身的名字

{device} embedded自已本身所使用的網路介面名字

{autoconf} 其可用的選項如下 :

off or none
on or any
dhcp
bootp
rarp
both (使用bootp & rarp)
default is any

以上若是使用正確將可以使用NFS來做為開機時的root file system，以下是一個範例：

root=/dev/nfs console=ttySAC0,115200 nfsroot=192.168.2.144:/home/work/embedded/filesystem/rootfs ip=dhcp

以上範例測試板是dhcp取得IP address，以下是另一個範例!為設定固定IP address ：

root=/dev/nfs console=ttySAC0,115200 nfsroot=192.168.2.144:/home/work/embedded/filesystem/rootfs ip=192.168.2.90

在Linux一些好用的設定

2010-10-04T22:31:00.000+08:00

如何讓在Linux系統下ls指令時所顯示的檔名，會根據檔案屬性不同，顯示不同的顏色，其做法是在使用者的home directory之下編譯.bashrc檔案，加入一些設定如下

　　　　export LS_OPTIONS='--color=auto'

　　　　eval "`dircolors`"

　　　　alias ls='ls $LS_OPTIONS'

　　　　alias ll='ls $LS_OPTIONS -l'

　　　　alias l='ls $LS_OPTIONS -lA'

在debain系統按裝套件的指令

apt-get install package-name

apt-cache search package-name

檢查有多少軟件已按裝

dpkg -l

免設IP/ 免使用public IP / 使用P2P / Window, Ubuntu, iphone支援，可以穿透任何firewall

http://www.teamviewer.com

用過心得：還是VNC的效能較好，比較不會有延遲晝面及解析度較好。但是VNC無法透過internet使用。

如何設定讓debain 6.0的Window可以用root權限登入：

default的debain 6.0是不讓人使用root來登錄，當然這是為了安全著想，但是有時debain我們是將它安裝在virtual machine中，只是自已使用，所以常常需使用su或者做權限的認證才能做事，其實是很麻煩的，所以可以直接用root來登錄是一件很方便的事。其實要讓root可以直接登入是一件很簡單的事，只要修改 /etc/pam.d/gdm3 的檔案，將以下的這行mark掉就好了：

auth required pam_succeed_if.so user != root quiet_success

如何編譯ARM Cross Compiler ToolChain

2010-08-20T21:00:00.000+08:00

在Embedded系統中, 通常我們會需要做cross development, 而這時則需要cross compiler, 而有時等待網路上其他編譯好的cross compiler會太慢, 或者他們編譯時所選的選項不是你想要的, 這時則必需自行編譯, 我個人的經驗則是完全自行編譯使用, 而不用其他人所編譯好的toolchain, 所以我將我個人的經驗提供給大家做參考。在編譯之前你必需準備好以下的環境及source code:

下載原始碼
1. 安裝好一個PC Linux, 你可以用virtual machine來建立, 個人不太建議使用cygwin這類的環境來做開發環境。
2. 必需在PC Linux上按裝軟體如下:

x86版本的gcc compiler (必須包含g++)
公共程式texi2html
公共程式gawk
函式庫zlib

3. 下載kernel source code (這裏我使用2.6.35當範例) 。
4. 下載gcc source code (這裏我使用4.5.0當範例) 。
5. 下載glibc source code (這裏我使用2.11.2當範例) 。
6. 下載binutil source code (這裏我使用2.20.0當範例) 。
7. 下載glibc ARM patched file (glibc-ports-2.11.tar.bz2)。
8. 下載gmp source code (這裏我使用5.0.1當範例) 。
9. 下載mpfr source code (這裏我使用3.0.0當範例) 。
10. 下載mpc source code (這裏我使用0.8.2當範例, 在GCC 4.5.0之後必需使用mpc)。

編譯流程
以下則是整個編譯過程的主要步驟, 你必須依照以下的順序, 否則你將無法順利編譯成功：
1. 將下載下來的source code全部解壓縮至各別的目錄。
2. 先編譯binutils, 並將其按裝在你的PC Linux上 (這裏假設按裝的目錄為/usr/local/arm-linux-gnueabi), 這個原始碼是ld, as, ranlib等的程式碼。
3. 編譯gmp並將其按裝至以上binutil按裝目錄之下的tools目錄。
4. 宣告一個系統變數 export LD_LIBRARY_PATH=/usr/local/arm-linux-gnueabi/tools/lib。
5. 編譯mpfr並將其按裝至以上binutil按裝目錄之下的tools目錄。
6. 編譯mpc並將其按裝至以上binutil按裝目錄之下的tools目錄。
7. 增加系統search變數 export PATH=$PATH:/usr/local/arm-linux-gnueabi/bin。
8. 編譯gcc為static以及只有 c 語言的支援, 並將其按裝至PC Linux。
9. 編譯glibc為shared library並將其按裝至PC Linux, 若是要編譯多種版本library (little endian, big endian version), 則必須要在這個步驟重覆執行, 使用不同的參數來產生不同版本的library。
10. 再編譯一次gcc, 但是將其編譯為shared library, 並有c++的支援, 至此就大功告成。

編譯gmp步驟如下:

1. 建立一個子目錄為 /usr/local/arm-linux-gnueabi/tools

2. 進入gmp的source code directory

3. 建立一個目錄為build-arm, 並進入該目錄

4. 執行命令如下:

CPPFLAGS=-fexceptions ../configure --prefix=/usr/local/arm-linux-gnueabi/tools --enable-cxx --with-gnu-ld
5. 執行make & make install

編譯mpfr步驟如下:

1. 進入mpfr的source code directory

2. 建立一個目錄為build-arm, 並進入該目錄

3. 執行命令如下:

../configure --prefix=/usr/local/arm-linux-gnueabi/tools --with-gmp=/usr/local/arm-linux-gnueabi/tools --with-gnu-ld
4. 執行make & make install

編譯mpc步驟如下:

1. 進入mpc的source code directory

2. 建立一個目錄為build-arm, 並進入該目錄

3. 執行命令如下:

../configure --prefix=/usr/local/arm-linux-gnueabi/tools --with-gnu-ld --with-gmp=/usr/local/arm-linux-gnueabi/tools --with-mpfr=/usr/local/arm-linux-gnueabi/tools
4. 執行make & make install

編譯binutil的步驟如下:
1. 進入binutils的source code directory
2. 建立一個月錄build-arm, 並且進入該目錄
3. 執行命令如下:
../configure --prefix=/usr/local/arm-linux-gnueabi --host=i686-pc-linux --build=i686-pc-linux --target=arm-linux-gnueabi --enable-shared --disable-multilib --with-gmp=/usr/local/arm-linux-gnueabi/tools --with-mpfr=/usr/local/arm-linux-gnueabi/tools --with-mpc=/usr/local/arm-linux-gnueabi/tools

3-1. 假如你要支援多種版本的library (little-endian & big-endian), 則所下的參數會是如下 :

../configure --prefix=/usr/local/arm-linux-gnueabi --build=i686-pc-linux --host=i686-pc-linux --target=arm-linux-gnueabi --enable-shared --enable-multilib --with-lib-path=/usr/local/arm-linux-gnueabi/lib:/usr/local/arm-linux-gnueabi/lib/be:/usr/local/arm-linux-gnueabi/lib/soft-float:/usr/local/arm-linux-gnueabi/lib/be/soft-float --with-gmp=/usr/local/arm-linux-gnueabi/tools --with-mpfr=/usr/local/arm-linux-gnueabi/tools --with-mpc=/usr/local/arm-linux-gnueabi/tools

主要是多一個--with-lib-path的選項。

4. 之後執行make & make install

設定環境變數

這時需要先編譯一版使用static library的gcc版本, 再使用這版compiler去編譯glibc為shared library, 之後再回頭再編譯一次gcc為使用shared library, 在編譯之前需設定幾個環境變數如下 :

1. export LD_LIBRARY_PATH=/usr/local/arm-linux-gnueabi/tools/lib

2. export PATH=$PATH:/usr/local/arm-linux-gnueabi/bin

3. 若要支援多版本的編繹器則需要修改設定檔gcc/config/arm/t-linux-eabi，增加內容如下：

MULTILIB_OPTIONS = mlittle-endian/mbig-endian

MULTILIB_DIRNAMES = le be

LIBGCC = stmp-multilib

INSTALL_LIBGCC = install-multilib

以下是編譯的流程 :

1. 進入GCC source code目錄並建立一個子目錄build-arm-static

2. 進入build-arm-static目錄, 執行以下指令

../configure --host=i686-pc-linux --build=i686-pc-linux --target=arm-linux-gnueabi --prefix=/usr/local/arm-linux-gnueabi --with-gmp=/usr/local/arm-linux-gnueabi/tools --with-mpfr=/usr/local/arm-linux-gnueabi/tools --with-gnu-ld --without-newlib --enable-long-long --disable-libada --without-cvs --disable-libgomp --disable-libmudflap --disable-libssp --disable-threads --enable-__cxa_atexit --disable-shared --enable-languages=c --with-system-zlib --with-mpc=/usr/local/arm-linux-gnueabi/tools --disable-multilib

2-1.若是要支援多版library則設定如下:

./configure --host=i686-pc-linux --build=i686-pc-linux --target=arm-linux-gnueabi --prefix=/usr/local/arm-linux-gnueabi --with-gmp=/usr/local/arm-linux-gnueabi/tools --with-mpfr=/usr/local/arm-linux-gnueabi/tools --with-gnu-ld --without-newlib --enable-long-long --disable-libada --without-cvs --disable-libgomp --disable-libmudflap --disable-libssp --disable-threads --enable-__cxa_atexit --disable-shared --enable-languages=c --with-system-zlib --with-mpc=/usr/local/arm-linux-gnueabi/tools --enable-multilib

3. 執行make & make install

編譯glibc

接下來是要編譯glibc是較麻煩的一件事, 在編譯glibc之前, 你必須使用kernel來產生一些header files因為在編譯glibc時需要用到, 以下是產生kernel header file的步驟：

1. 進入kernel source code目錄, 修改Makefile中的ARCH及CROSS_COMPILE變數如下 :

ARCH := arm

CROSS_COMPILE := arm-linux-gnueabi

INSTALL_MOD_PATH := `pwd`/installed_modules

1-1. 你若要產生多種版本的library (little endian & big endian), 那你必須更改兩個檔案 (glibc-source-code/Makeconfig & glibc-source-code/config.make.in), 以便在編譯完要按裝時可以得到適當的按裝, 其修改內容如下:

glibc-source-code/Makefconfig 第193行加入以下內容:

slibdir = $(libdir)

glibc-source-code/config.make.in mark掉第13行 #slibdir = @libc_cv_slibdir@, 加入一行如下:

slibdir = @libdir@

1-2. 在新版的glibc中gcc_eh並未準備好，所以無法使用，必須修Makeconfig檔以防止在編譯glibc時會連結gcc_eh, 你必須將該檔中的-lgcc_eh移除即。

2. 執行make menuconfig並選擇一種ARM平台, 之後將設定存下

3. 執行make headers_install以取得編譯glibc時要使用的kernel header files, 這時這些的include files將會被產生在kernel source code的目錄之下的usr/include目錄

4. 進入glibc的source code根目錄, 並建立一個目錄為build-arm-le, 並將glibc-ports-2.11.tar.bz2解壓縮的內容拷貝至glibc的目錄並設為ports的目錄

5. 進入build-arm-le的目錄, 並執行以下指令 :

CC=arm-linux-gnueabi-gcc CXX=arm-linux-gnueabi-g++ CPP="arm-linux-gnueabi-gcc -E" LD=arm-linux-gnueabi-ld STRIP=arm-linx-gnueabi-strip AR=arm-linux-gnueabi-ar NM=arm-linux-gnueabi-nm AS=arm-linux-gnueabi-as RANLIB=arm-linux-gnueabi-ranlib ARCH=arm ../configure --prefix=/usr/local/arm-linux-gnueabi --target=arm-linux-gnueabi --host=arm-linux-gnueabi --build=i686-pc-linux --disable-profile --enable-add-ons --with-__thread --enable-threads=posix --enable-multilib --without-cvs --enable-shared --without-gd --with-headers=/home/work/kernel/linux-2.6.35/usr/include --libdir=/usr/local/arm-linux-gnueabi/lib libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes

5-1.進入build-arm-be的目錄, 並執行以下指令:

CC="arm-linux-gnueabi-gcc -mbig-endian" CXX="arm-linux-gnueabi-g++ -mbig-endian" CPP="arm-linux-gnueabi-gcc -E -mbig-endian" LD="arm-linux-gnueabi-ld -EB" STRIP=arm-linx-gnueabi-strip AR=arm-linux-gnueabi-ar NM=arm-linux-gnueabi-nm AS="arm-linux-gnueabi-as -EB" RANLIB=arm-linux-gnueabi-ranlib ARCH=arm ../configure --prefix=/usr/local/arm-linux-gnueabi --target=arm-linux-gnueabi --host=arm-linux-gnueabi --build=i686-pc-linux --disable-profile --enable-add-ons --with-__thread --enable-threads=posix --enable-multilib --without-cvs --enable-shared --without-gd --with-headers=/home/work/kernel/linux-2.6.35/usr/include --libdir=/usr/local/arm-linux-gnueabi/lib/be libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes

6. 執行make & make install, 至此即可完成glibc的建立, 你將可以在/usr/local/arm-linux-gnueabi目錄下, 可以發現include & lib的目錄內容已包含glibc的內容
7. 將kernel/usr/include目錄之下的所有檔案拷貝至/usr/local/arm-linux-gnueabi/include目錄之下

編譯gcc for shared library

最後的動作則是要再重新編譯一次gcc使它支援shared library, 在重新編譯之前, 有幾個動作必須要完成, 以下是這些動作的內容：

1. 進入/usr/local/arm-linux-gnueabi/arm-linux-gnueabi的目錄, 特別注意是有兩層的arm-linux-gnueabi, 不可弄錯

2. 執行指令如下：

> mv lib lib.bak

> ln -s ../lib lib

> ln -s ../include include

> cp -a lib.bak/* ../lib

這時可以正式開始來重新編譯gcc, 其步驟如下：

1. 進入gcc source code目錄, 並建立一個目錄為build-arm-shared, 之後進入build-arm-shared目錄

2. 執行以下指令 :

../configure --host=i686-pc-linux --build=i686-pc-linux --target=arm-linux-gnueabi --prefix=/usr/local/arm-linux-gnueabi --with-arch=armv6 --with-gmp=/usr/local/arm-linux-gnueabi/tools --with-mpfr=/usr/local/arm-linux-gnueabi/tools --with-gnu-ld --without-newlib --enable-long-long --disable-libada --without-cvs --disable-libgomp --disable-libmudflap --disable-libssp --enable-threads --enable-__cxa_atexit --enable-shared --enable-languages=c,c++ --with-system-zlib --with-mpc=/usr/local/arm-linux-gnueabi/tools --disable-multilib

2-1.若要支援多版library執行指令如下:

3. 執行make ; make install

至此就大功告成, 你可以寫一個簡單的hello程式來試試, 記得這是default share library的cross compiler, 所以你執行ap時也要記得將shared library也拷貝至embedded computer

最後有一個公共程式很好用，那就是 ldd 它可將應用程式及 library 所用到的 library 例出來，default 的 ldd 有點問題無法執行，這邊可以自行寫一個 shell script 檔名就是 arm-linux-gnueabi-ldd 其內容如下：

#!/bin/sh
arm-linux-gnueabi-objdump -x $@ | grep NEEDED

並將這執行放至 /usr/local/arm-linux-gnueabi/bin 目錄之下即可。

如何porting linux kernel給一顆新的ARM CPU

2009-11-09T23:03:00.000+08:00

ARM CPU是目前使用最多的embedded CPU, 所以這邊會就我個人經驗來分享如何porting一顆新的ARM CPU Linux platform, 在porting之前有幾項硬體規格必須事先弄清楚：

CPU是何種ARM core, 例如arm926, 是V5, V6還是V7等等
SoC多少週邊元件在這顆Embedded ARM CPU之內
interrupt如何設定及使用, 這裏所指的是interrupt controller
timer如何設定及使用
DRAM & Flash mapping至CPU那個位置

收集這些資訊之後, 開始要做Linux kernel porting的工作, 以下是它的工作步驟

修改源始碼根目錄的Makefile, 將其中幾個變數做修改如下

ARCH := ARM

CROSS_COMPILE := arm-linux-gnueabi

INSTALL_MOD_PATH := `pwd`/installed_modules

在arch/arm目錄之下建立一個子目錄其名字為mach-開頭, 之後你可以取一個名字, 例如mach-victorcpu, 而在這目錄下的程式皆為HAL層的程式碼
在arch/arm/tools目錄之下有一個文字檔 "mach-types" , 仿照其它CPU的寫法, 你必須定一個ID號碼, 必須是唯一的。
在你建立的mach-victorcpu目錄建立Makefile & Kconfig, 並將你建立的Kconfig檔加入至arch/arm/Kconfig的include之中
在新建mach-victorcpu的新目錄中, 必須幾個檔案而其內容如下:
MACHINE_DESCRIPTION
interrupt controller initialization
timer controller initialization
mapping fixed some SoC address to be virtual address, 有些SoC的元件在開機就必須使用到的, 就需要使用事先定對好的方式來設定, 例如timer
若有PCI host, 則必須撰寫其HAL層在此, 而PCI BUS Driver則會在driver/pci的目錄中, 不用撰寫。
若在cahce操作部若有和ARM的標準不同, 則必需撰寫其差異部分的程式在arch/arm/mm的目錄之下。
接下來必需要開始撰寫各個SoC進來元件的device driver, 你要依照硬體的設計來撰寫個別device driver。

以上為porting Linux kernel時非常非常大項分法所需要撰寫的程式說明。

如何撰寫一個serial port的驅動程式

2009-10-29T23:05:00.001+08:00

簡介

RS232是kernel中常用到的一種週邊元件，在以前主要是拿來連接終端設備的通訊介面，而今日則是常被拿來做控制或者和其它設備通訊的介面，因為其硬體簡單及成本低所以會被很多設備做為最基本的通訊介面，因為其發展有很長一段時間，所以在Linux中有為它特別規劃一組軟體堆疊，主要分為實體控制層以及上層的終端控制層，其架構如下:

初始化
所以通常我們要寫的是實體層的驅動程式，在driver的進入點，若是PCI介面，則先註冊一個PCI的call back function，若是local bus則是可以註冊一個platform device call back function，當系統進入你所註冊的call back function，必須對你所使用的硬體介面位址做一個remapping的動作，就是將實體位址轉換成虛擬位址，接著後面的所有程式碼都要使用這個虛擬位址，這時要開始初始化你的硬體及driver，首先建立一個struct tty_driver的資料結構，其宣告如下：

struct tty_driver {
int magic; /* magic number for this structure */
struct cdev cdev;
struct module *owner;
const char *driver_name;
const char *name;
int name_base; /* offset of printed name */
int major; /* major device number */
int minor_start; /* start of minor device number */
int minor_num; /* number of *possible* devices */
int num; /* number of devices allocated */
short type; /* type of tty driver */
short subtype; /* subtype of tty driver */
struct ktermios init_termios; /* Initial termios */
int flags; /* tty driver flags */
int refcount; /* for loadable tty drivers */
struct proc_dir_entry *proc_entry; /* /proc fs entry */
struct tty_driver *other; /* only used for the PTY driver */

/*
* Pointer to the tty data structures
*/
struct tty_struct **ttys;
struct ktermios **termios;
struct ktermios **termios_locked;
void *driver_state; /* only used for the PTY driver */

/*
* Interface routines from the upper tty layer to the tty
* driver. Will be replaced with struct tty_operations.
*/
int (*open)(struct tty_struct * tty, struct file * filp);
void (*close)(struct tty_struct * tty, struct file * filp);
int (*write)(struct tty_struct * tty,
const unsigned char *buf, int count);
void (*put_char)(struct tty_struct *tty, unsigned char ch);
void (*flush_chars)(struct tty_struct *tty);
int (*write_room)(struct tty_struct *tty);
int (*chars_in_buffer)(struct tty_struct *tty);
int (*ioctl)(struct tty_struct *tty, struct file * file,
unsigned int cmd, unsigned long arg);
long (*compat_ioctl)(struct tty_struct *tty, struct file * file,
unsigned int cmd, unsigned long arg);
void (*set_termios)(struct tty_struct *tty, struct ktermios * old);
void (*throttle)(struct tty_struct * tty);
void (*unthrottle)(struct tty_struct * tty);
void (*stop)(struct tty_struct *tty);
void (*start)(struct tty_struct *tty);
void (*hangup)(struct tty_struct *tty);
void (*break_ctl)(struct tty_struct *tty, int state);
void (*flush_buffer)(struct tty_struct *tty);
void (*set_ldisc)(struct tty_struct *tty);
void (*wait_until_sent)(struct tty_struct *tty, int timeout);
void (*send_xchar)(struct tty_struct *tty, char ch);
int (*read_proc)(char *page, char **start, off_t off,
int count, int *eof, void *data);
int (*write_proc)(struct file *file, const char __user *buffer,
unsigned long count, void *data);
int (*tiocmget)(struct tty_struct *tty, struct file *file);
int (*tiocmset)(struct tty_struct *tty, struct file *file,
unsigned int set, unsigned int clear);

struct list_head tty_drivers;
};

在這個資料結構中其中分為幾個部分，第一個部分是所以謂的callback function的註冊，在這些個callback function中你必須金對你有實現的部分給予註冊，若沒有就可以給予不註冊，但相對的你的驅動程式所支援的功能會較少。另一個部分則是驅動程式本身資訊的資料，如major number、starting minor number、tty device name等等，以下是一個例子：

struct tty_driver MySerialDriver;

#define MAX_PORTS 4

struct ktermios *my_termios[MAX_PORTS];

struct ktermios *my_termios_locked[MAX_PORTS];

memset(&MySerialDriver, 0 sizeof(MySerialDriver));

MySerialDriver.name = "ttyN";

MySerialDriver.major = 40;

MySerialDriver.minor_start = 0;

MySerialDriver.minor_num = MAX_PORTS;

MySerialDriver.num = MAX_PORTS;

MySerialDriver.magic = TTY_DRIVER_MAGIC;

MySerialDriver.type = TTY_DRIVER_TYPE_SERIAL;

MySerialDriver.subtype = SERAL_TYPE_NORMAL;

MySerialDriver.init_termios = tty_std_termios;

MySerialDriver.init_termios.c_cflag = B9600 CS8 CREAD CLOCAL;

MySerialDriver.flags = TTY_DRIVER_REAL_RAW;

MySerialDriver.termios = my_termios;

MySerialDriver.termios_locked = my_termios_locked;

MySerialDriver.open = my_open;

以下為driver initialize的工作內容

1. allocate tty driver資料結構使用

struct tty_driver *mxvar_sdriver=alloc_tty_driver(MXSER_PORTS + 1);

2. 在allocate的tty driver資料結構中填入必要的資訊

mxvar_sdriver->owner = THIS_MODULE;
mxvar_sdriver->magic = TTY_DRIVER_MAGIC;
mxvar_sdriver->name = "ttyMI";
mxvar_sdriver->major = ttymajor;
mxvar_sdriver->minor_start = 0;
mxvar_sdriver->num = MXSER_PORTS + 1;
mxvar_sdriver->type = TTY_DRIVER_TYPE_SERIAL;
mxvar_sdriver->subtype = SERIAL_TYPE_NORMAL;
mxvar_sdriver->init_termios = tty_std_termios;
mxvar_sdriver->init_termios.c_cflag = B9600|CS8|CREAD|HUPCL|CLOCAL;
mxvar_sdriver->flags = TTY_DRIVER_REAL_RAW|TTY_DRIVER_DYNAMIC_DEV;

3. 設定tty會使用的各個call back function

tty_set_operations(mxvar_sdriver, &mxser_ops);

而其中的mxser_ops設定如下:

static const struct tty_operations mxser_ops = {

.open = mxser_open,

.close = mxser_close,

.write = mxser_write,

.put_char = mxser_put_char,

.flush_chars = mxser_flush_chars,

.write_room = mxser_write_room,

.chars_in_buffer = mxser_chars_in_buffer,

.flush_buffer = mxser_flush_buffer,

.ioctl = mxser_ioctl,

.throttle = mxser_throttle,

.unthrottle = mxser_unthrottle,

.set_termios = mxser_set_termios,

.stop = mxser_stop,

.start = mxser_start,

.hangup = mxser_hangup,

.break_ctl = mxser_rs_break,

.wait_until_sent = mxser_wait_until_sent,

.tiocmget = mxser_tiocmget,

.tiocmset = mxser_tiocmset,

};

4. 向tty_io註冊driver

retval = tty_register_driver(mxvar_sdriver);

5. 註冊 PCI client或者platform的driver, 等待其call back所設定probe程序

retval = pci_register_driver(&mxser_driver);

PCI client driver的資料結構如下：

static struct pci_driver mxser_driver = {

.name = "mxser",

.id_table = mxser_pcibrds,

.probe = mxser_probe,

.remove = __devexit_p(mxser_remove)

};

或者

retval = platform_register_driver(&mxser_driver);

platform client driver的資料結構如下：

static struct platform_driver moxaarm11_gmac_driver = {

.driver.name = DRV_NAME,

.probe = moxaarm11_gmac_probe,

.remove = moxaarm11_gmac_remove,

};

6. 這時HAL層(PCI or platform)若有找到該元件, 將會呼叫設定的probe call back function

probe call back function內做的事情

1. 取得所分配到的resource, 包含I/O及IRQ

2. 向kernel註冊所需的resource, 若是使用memory的方式來存取, 記得需要將取得的physical address用ioremap將其轉換為virtual address

3. 註冊IRQ service routine (ISR)

4. 針對每一個實體的port向上層tty做註冊

tty_register_device(mxvar_sdriver, brd->idx + i, &pdev->dev);

remove call back function內做的事情

1. 將取得resource釋放出來

2. 將已remap過的virtual address做unremap的動作

3. 取消已註冊的ISR

4. 針對每一個已註冊的實體port向上層tty做取消的動作

tty_unregister_device(mxvar_sdriver, brd->idx + i);

原則上remove的動作剛好都和probe做相反的動作

各個operation call back function內做的事情

這些的call back function都會先經過tty_io的處理之後，才會再呼叫這些call back function。

open

這是當AP呼叫open()時會被呼叫的進入點，但是在呼叫你的open call back function之前，會先經過tty_io處理過，在你的open call back function中如何取得的minor number? 可以從tty_io傳給你的tty_struct structure 中的成員index取得(tty->index)，你若有控制多port的serial port這時你就可以知道AP要open那一個port，另外linux是一個多工的作業系統，所以有可能多個AP會呼叫下來，也許會open同一個port，這時driver本身自已要記住該port已被open多少次，當是第一個open時需初始化該port，以及buffer的allocate，另外serial port的硬體設定是保留前一個設定，在open時不會做更動。

close

從call back的名字就可以知道，這是從AP的close()時的進入點，這個call back function應該檢查是否為最後一個close，也就之前已有多個open()之中的最後一個close(), 記得前面的open會記住被open幾次，在close則相對地減掉被open的數，在最後一次的close時，應將open中所取得的resource應全數release給kernel。

write

這是送資料的進入點, 通常我們都會先將資料放在自已的buffer, 之後再慢慢送, 而且通常會使用interrupt的方式來送, 而這個return值會是有多少bytes已存在你的buffer中

put_char

serial communication中有所謂software flow control, 它是用資料中兩個bytes XON(0x11), XOFF (0x13)來做這流量控制, 而當要送這個bytes時就會呼叫這一個call back function, 而且這兩個必須要馬上被送出, 不可放在buffer之中, 所以原則上會在這個call back function做一個flag記錄, 而在interrupt service routine中即時送出

flush_chars

這是清除本來在put_char中的資料, 若尚未送出將給予丟棄

write_room

檢查送的buffer還剩多少空間可以存放資料

char_in_buffer

已收進多少資料在driver buffer之中

ioctl

這是相對應AP的ioctl() API, 在linux的tty中已定義一些ioctl() command, 應給予支援, 你也可以自行定義一些ioctl()

set_termios

設定RS232如baud rate, data bits, stop bits等等, 將會使用struct termios來做設定資料結構

throttle

這是在做flow control用的, 在以往hardware不夠好的時候, flow control是軟體來實現, 而且由tty_io來控制, 現在硬體已比以前強了, 所以flow control部分將會由硬體來實現, 而這個將是停止送資料, 不用管是由software flow control or hardware flow control來的, 這個call back function被呼叫時, 就是停止送資料

unthrottle

這個動作也是在做flow control, 和上面的throttle相反, 則是開始送資料

stop

shutdown該UART port

start

啓動該port

hangup

這是在接modem時用的, 用在掛電話

break_ctrl

這是在送break訊號的控制

flush_buffer

這是清除在driver buffer中的資料, 將存放在buffer中尚未處理的資料全部給予丟棄

wait_until_sent

等待在buffer中尚未送出的資料全部送出, 而且需要block在這裏面

tiocmget

最得modem的訊號 CTS, DSR, DCD, RI

tiocmset

控制modem訊號 RTS, DTR

在了解各個call back function的定義及作業內容，這時寫driver的人就必須依照這樣的定義來撰寫serial port device driver. 最後最重要的是interrupt service routine, 原則上收送資料都是使用interrupt的方式來收送, 但是在送資料時, 應該是一次就將FIFO填滿, 而收的部分通常設定一個FIFO的high water就產生interrupt, 因為不可在FIFO滿的時候才產生interrupt, 這樣沒有緩衝時間來處理後面持續進來的資料, 容易造成FIFO overflow, 以上是RS232 device driver的大概說明, 其它還有許多細節的部分留待以後再說明