2017年10月26日 星期四

移植 iptable 命令至 am335x

原文 http://onlybernie.blogspot.tw/2015/10/

下載 iptables-1.4.18.tar.gz

1先 source poky sdk 的 env setup script
2解壓後,進入資料夾內輸入

    ./configure --host=arm-poky-linux-gnueabi --prefix=/home/bernie/app/iptables --enable-static --disable-shared


最後進入 /home/bernie/app/iptables/sbin,將裡面的所有資料 tar 起來,丟至目標板,解壓放至 /usr/sbin 內。

因為我們一開始採用靜態編譯,所以執行 iptables 命令時不會去 /lib 尋找 library。

移植 iw 命令至 am335x

原文 http://onlybernie.blogspot.tw/2015/10/

TI Wlink 8 最新的 driver R8.6,不支援 Wireless Extentsion。所謂的 Wireless Extentsion,就是一組通用 API,要使用的話,也必須 wifi driver 有支援。所以我們另外使用 iw 來取代,TI 的 driver 有支援此命令。


iw-3.15
libnl-3.2.24

iw 需要 netlink library,所以我們先移植 libnl。進入 libnl 資料夾,打上

   source poky sdk env setup script
  ./configure --host=arm-poky-linux-gnueabi --prefix=/home/bernie/app/libnl-3.2.24

   make
   make install

   編譯 libnl 安裝完成
====================================================================

  接著不要 source poky sdk 環境,進入 iw 資料夾。打上

   export PKG_CONFIG_PATH=/home/bernie/app/libnl-3.2.24/lib/pkgconfig
   修改 Makefile 中的 CC 值

    CC=/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc --sysroot=/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi

   make
======================================================================
   error:  發現少了 libnl 的 gen.h 檔案

   solution: 修改 Makefile 的 CFLAGS,讓他增加指向
                  -I/home/bernie/app/libnl-3.2.24/include/libnl3

   make
=======================================================================
   error:
 /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: error: iw uses VFP register arguments, version.o does not
/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/ld: failed to merge target specific data of file version.o
collect2: error: ld returned 1 exit status

  solution: 在 Makefile 中的  CC 變數加上 poky sdk 裡的 envsetup script 中的 CC 值即可。

編譯成功後,將 iw命令丟到目標板 /usr/sbin。

 

移植 wpa_supplicant 命令至 am335x

原文 http://onlybernie.blogspot.tw/2015/10/

要有 wpa_supplicant 指令,要先有 openssl  的 library 以及 libnl 的 library,前一章已經移植過了 libnl-3.2.24 了。

選擇 openssl-1.0.1h。進入openssl-1.0.1h,打上

  source poky sdk env setup script
 ./Configure linux-generic32 --prefix=/home/bernie/app/openssl

  修改 Makefile 中的 CC 為 CC= $(CROSS_COMPILE)gcc ... 後面為 sdk 的參數設定。
   make
   make install

   編譯 openssl 安裝完成
 ========================================================================

 進入 wpa_supplicant-2.2,打上
  不用 source poky  sdk env setup script,但是要 export PATH=sdk 的 bin
  cp defconfig .config
  在 .config 內加上
 
      CC=arm-poky-linux-gnueabi-gcc  -march=armv7-a -marm  -mthumb-interwork -mfloat-
abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi

    CFLAGS += -I /home/bernie/app/libnl-3.2.24/include/libnl3
    CFLAGS += -I /home/bernie/app/openssl/include
    LIBS += -L /home/bernie/app/openssl/lib
    LIBS += -L /home/bernie/app/libnl-3.2.24/lib
    CONFIG_LIBNL32=y-->這個要加,不然會出現 ld找不到 -lnl 的訊息

    make

    編譯完成後,將 wpa_supplicant 和 wpa_cli 丟至開發板 /usr/sbin

=======================================================================

wpa_supplicant 用法

mkdir /var/run/wpa_supplicant

 vi  /etc/wpa_supplicant.conf

   ctrl_interface=/var/run/wpa_supplicant
   update_config=1

   network={
        psk="12345678"
        ssid="bernie"
   }

##update_config=1 /* 讓 wpa_cli 程式可以更新 wpa_supplicant */
## ctrl_interface=/var/run/wpa_supplicant /* 讓 supplicant 可以建立行程 pid */
 
 最後下指令:
wpa_supplicant -d -Dnl80211(也有可能是 wext) -c/etc/wpa_supplicant.conf -iwlan0 -B

     root@am335x-evm:/# [  684.159242] wlan0: authenticate with 18:00:2d:75:f7:80[  684.170487] wlan0: send auth to 18:00:2d:75:f7:80 (try 1/3)
[  684.199773] wlan0: authenticated
[  684.205871] wlan0: associate with 18:00:2d:75:f7:80 (try 1/3)
[  684.314794] wlan0: RX AssocResp from 18:00:2d:75:f7:80 (capab=0x431 status=0 aid=2)
[  684.335695] wlan0: associated
[  684.410374] wlcore: Association completed.

 成功會有上述字樣


 udhcpc -i wlan0

 即可拿到 IP

Poky vs Yocto vs OpenEmbedded

Package list: apps_proc/oe-core/build/tmp-glibc/deploy/images/<target>/<image>.rootfs.manifest


1. Why not just call this project Poky? What has changed between Poky and the Yocto Project?

The Yocto Project is an umbrella project. Accordingly, it includes a number of projects and resources specifically intended for facilitating development with Linux on embedded devices, and it is an appropriate place for larger organizations to collaborate on the development of build infrastructure for embedded Linux. Poky is one of the the largest components of the Yocto Project, and Poky continues as an independent, open source project developing the build system used by the Yocto Project, as well as by other open source projects.

Poky is a reference system for the Yocto Project, showing how the tools work together. It includes BitBake, openembedded-core, and several other components that anyone can use to start developing with embedded Linux. Poky as a build system is tested by the Yocto Project teams before each release. When you download and use the Yocto Project build system, you are actually downloading Poky and using it to create a distribution that by default is also named Poky. (You can, of course, name your distribution anything you like.)


2. What is the difference between OpenEmbedded and the Yocto Project?

The Yocto Project and OpenEmbedded share a core collection of metadata called openembedded-core. However, the two organizations remain separate, each with its own focus. OpenEmbedded provides a comprehensive set of metadata for a wide variety of architectures, features, and applications. The Yocto Project focuses on providing powerful, easy-to-use, interoperable, well-tested tools, metadata, and board support packages (BSPs) for a core set of architectures and specific boards.

Linux WiFi

Source: http://blog.csdn.net/liuxd3000/article/details/23761663


1. 基本概念
  • cfg80211:  用於對無線設備進行配置管理。與FullMAC, mac80211和nl80211一起工作。(Kernel態)
  • mac80211: 是一個driver開發者可用於為SoftMAC無線設備寫驅動的框架 (Kernel態)。
  • nl80211: 用於對無線設備進行配置管理,它是一個基本Netlink的使用者態協議(User態)
  • WNIC : Wireless Network Interface Controller, 它總是指望硬體執行協定(如IEEE802.11)描述的功能。
  • MLME: 即MAC(Media Access Control ) Layer Management Entity,它管理實體層MAC狀態機。
  • SoftMAC: 其MLME由軟體實現,mac80211為SoftMAC實現提供了一個driver API。 即:SoftMAC設備允許對硬體執行更好地控制,允許用軟體實現對802.11的幀管理,包括解析和產生802.11無線幀。目前大多數802.11設備為SoftMAC,而FullMAC設備較少。
  • FullMAC:  其MLME由硬體管理,當寫FullMAC無線驅動時,不需要使用mac80211。
  • wpa_supplicant: 是使用者空間一個應用程式,主要發起MLME命令,然後處理相關結果。
2. cfg80211

  • cfg80211是Linux 802.11配置API。cfg80211用於代碼wext(Wireless-Extensions),nl80211用於配置一個cfg80211設備,且用於kernel與userspace間的通信。wext現處理維護狀態,沒有新的功能被增加,只是修改bug。如果需要通過wext操作,則需要定義CONFIG_CFG80211_WEXT。
  • cfg80211 and nl80211: 基於消息機制,使用netlink介面
  • wext: 基於ioctl機制
  • struct ieee80211_hw: 表示硬體資訊和狀態
  • ieee80211_alloc_hw:每個driver調用ieee80211_alloc_hw分配ieee80211_hw,且以ieee80211_ops為參數
  • ieee80211_register_hw:每個driver調用ieee80211_register_hw創建wlan0和 wmaster0,並進行各種初始化。
  • struct ieee80211_ops:每個driver實現它的成員函數,且它的成員函數都以struct ieee80211_hw做為第一個參數。在struct ieee80211_ops中定義了24個方法,以下7個方法必須實現: tx,start,stop,add_interface,remove_interface,config和configure_filter。

3. mac80211
  • 它是一個driver開發者可用於為SoftMAC無線設備寫驅動的框架,mac80211為SoftMAC設備實現了cfg80211回呼函數,且mac80211通過cfg80211實現了向網路子系統註冊和配置。配置由cfg80211通過nl80211和wext實現。
  • mac80211在體系結構中的位置如下圖所示:


4. socket




問題:
想了解nl80211和cfg80211的工作細節。以及功能流程,nl80211是如何與網絡工具如wpa_supplicant進行交互的。
解答:
為了能夠從用戶空間控制無線驅動程序,一些IPC被用於內核和用戶態之間。


原文網址:https://read01.com/5MakMK.html
問題:
想了解nl80211和cfg80211的工作細節。以及功能流程,nl80211是如何與網絡工具如wpa_supplicant進行交互的。
解答:
為了能夠從用戶空間控制無線驅動程序,一些IPC被用於內核和用戶態之間。


原文網址:https://read01.com/5MakMK.html
問題:
想了解nl80211和cfg80211的工作細節。以及功能流程,nl80211是如何與網絡工具如wpa_supplicant進行交互的。
解答:
為了能夠從用戶空間控制無線驅動程序,一些IPC被用於內核和用戶態之間。


原文網址:https://read01.com/5MakMK.html
問題:
想了解nl80211和cfg80211的工作細節。以及功能流程,nl80211是如何與網絡工具如wpa_supplicant進行交互的。
解答:
為了能夠從用戶空間控制無線驅動程序,一些IPC被用於內核和用戶態之間。


原文網址:https://read01.com/5MakMK.html

2017年7月28日 星期五

phy_scan_fixups()

Source: http://lists.openwall.net/netdev/2008/04/09/53

+Board Fixups
+
+ Sometimes the specific interaction between the platform and the PHY requires
+ special handling.  For instance, to change where the PHY's clock input is,
+ or to add a delay to account for latency issues in the data path.  In order
+ to support such contingencies, the PHY Layer allows platform code to register
+ fixups to be run when the PHY is brought up (or subsequently reset).
+ 
+ When the PHY Layer brings up a PHY it checks to see if there are any fixups
+ registered for it, matching based on UID (contained in the PHY device's phy_id
+ field) and the bus identifier (contained in phydev->dev.bus_id).  Both must
+ match, however two constants, PHY_ANY_ID and PHY_ANY_UID, are provided as
+ wildcards for the bus ID and UID, respectively.
+ 
+ When a match is found, the PHY layer will invoke the run function associated
+ with the fixup.  This function is passed a pointer to the phy_device of
+ interest.  It should therefore only operate on that PHY.
+ 
+ The platform code can either register the fixup using phy_register_fixup():
+ 
+ int phy_register_fixup(const char *phy_id,
+  u32 phy_uid, u32 phy_uid_mask,
+  int (*run)(struct phy_device *));
+
+ Or using one of the two stubs, phy_register_fixup_for_uid() and
+ phy_register_fixup_for_id():
+ 
+ int phy_register_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask,
+  int (*run)(struct phy_device *));
+ int phy_register_fixup_for_id(const char *phy_id,
+  int (*run)(struct phy_device *));
+ 
+ The stubs set one of the two matching criteria, and set the other one to
+ match anything.
+

2017年7月17日 星期一

Linux module parameters.

Source: http://nano-chicken.blogspot.tw/2011/01/linux-modules11module-parameters.html

Linux Module允許使用者在insmod時帶入相關的parameters,這些parameters必須被宣告成golbal,並且使用 module_param()宣告資料型態與權限,目前支援的資料型態有byte, short, ushort, int, uint, long, ulong, charp, bool等等。也可以使用module_param_array(name, type, num, perm)宣告成陣列。perm(權限)會決定/sys/module/顯示該參數的權限。

#include 
#include 

MODULE_LICENSE("GPL");

static unsigned char b_byte = 1;
module_param(b_byte, byte, S_IRUGO|S_IWUSR);

static short int b_short = 2;
module_param(b_short, short, S_IRUGO|S_IWUSR);

static unsigned short int b_ushort = 3;
module_param(b_ushort, ushort, S_IRUGO|S_IWUSR);

static int b_int = 6;
module_param(b_int, int, S_IRUGO|S_IWUSR);

static unsigned int b_uint = 5;
module_param(b_uint, uint, S_IRUGO|S_IWUSR);

static long b_long = 6;
module_param(b_long, long, S_IRUGO|S_IWUSR);

static unsigned long b_ulong = 7;
module_param(b_ulong, ulong, S_IRUGO|S_IWUSR);

static char *b_charp = "brook";
module_param(b_charp, charp, S_IRUGO|S_IWUSR);

static int b_bool = 1;
module_param(b_bool, bool, S_IRUGO|S_IWUSR);

static int __init init_modules(void)
{
    printk("b_byte: %d\n", b_byte);
    printk("b_short: %d\n", b_short);
    printk("b_ushort: %u\n", b_ushort);
    printk("b_int: %d\n", b_int);
    printk("b_uint: %u\n", b_uint);
    printk("b_long: %ld\n", b_long);
    printk("b_ulong: %lu\n", b_ulong);
    printk("b_charp: %s\n", b_charp);
    printk("b_bool: %d\n", b_bool);

    return 0;
}

static void __exit exit_modules(void)
{
}

module_init(init_modules);
module_exit(exit_modules);