2. follow : ESP8266 WiFi module firmware update ( 若無法立即執行, 按一下 power reset 即可 )
3. Firmware download tool : 注意 SPI MODE 的選取, flash memory >= 4MB : DIO, others QIO
2017-05-23
更新 ESP8266 ESP-01 firmware 的方法
1. 燒錄前要將 GPIO0 接地才行 (須在 power up 之前, 因 ESP8266 是在電源打開時偵測 GPIO 以便決定是否進入燒錄模式), 燒錄完成後再拔掉GPIO0接地線 :
2. follow : ESP8266 WiFi module firmware update ( 若無法立即執行, 按一下 power reset 即可 )
3. Firmware download tool : 注意 SPI MODE 的選取, flash memory >= 4MB : DIO, others QIO
2. follow : ESP8266 WiFi module firmware update ( 若無法立即執行, 按一下 power reset 即可 )
3. Firmware download tool : 注意 SPI MODE 的選取, flash memory >= 4MB : DIO, others QIO
2017-05-20
udev
來源 :
1. udev-強大的device node管理系統
2. Howto--udev rules
一、devfs
linux下有專門的檔系統用來對設備進行管理，devfs和sysfs就是其中兩種。
在2.6內核以前一直使用的是devfs，devfs掛載於/dev目錄下，提供了一種類似於檔案的方法來管理位於/dev目錄下的所有設備，我們知道/dev目錄下的每一個檔案都對應的是一個設備，至於當前該設備存在與否先且不論，而且這些特殊檔是位於根檔系統上的，在製作檔案系統的時候我們就已經建立了這些設備檔，因此通過操作這些特殊檔，可以實現與內核進行交互。但是devfs檔案系統有一些缺點，例如：不確定的設備映射，有時一個設備映射的設備檔可能不同，例如我的U盤可能對應sda有可能對應sdb；沒有足夠的主/輔設備號，當設備過多的時候，顯然這會成為一個問題；/dev目錄下檔太多而且不能表示當前系統上的實際設備；命名不夠靈活，不能任意指定等等。
udev的出現, 解決了在devfs上碰到的3個問題
1.udev能夠根據規則建立device node(這可以解決probing時,device node可能會依probing的順序不同而改變)
2.udev動態建立device node,不會像以前在/dev資料夾下擺一堆多而無用的device node
3.提供user更方便的API存取目前device的資訊,在kernel 2.6以上已提供sysfs這個device管理機制
二、sysfs
正因為上述這些問題的存在，在linux2.6內核以後，引入了一個新的檔案系統sysfs，它掛載於/sys目錄下，跟devfs一樣它也是一個虛擬檔案系統，也是用來對系統的設備進行管理的，它把實際連接到系統上的設備和匯流排組織成一個分階層的檔案目錄，用戶空間的程式同樣可以利用這些資訊以實現和內核的交互，該檔案系統是當前系統上實際設備樹的一個直觀反應，它是通過kobject子系統來建立這個資訊的，當一個kobject被創建的時候，對應的檔案和目錄也就被創建了，位於/sys下的相關目錄下，既然每個設備在sysfs中都有唯一對應的目錄，那麼也就可以被用戶空間讀寫了。用戶空間的工具udev就是利用了sysfs提供的資訊來實現所有devfs的功能的，但不同的是，udev運行在用戶空間中，而devfs卻運行在內核空間，而且udev不存在devfs那些先天的缺陷。很顯然，sysfs將是未來發展的方向。
The top level sysfs directory looks like:
block/
bus/
class/
devices/
firmware/
net/
fs/
devices/ contains a filesystem representation of the device tree. It maps directly to the internal kernel device tree, which is a hierarchy of struct device.
bus/ contains flat directory layout of the various bus types in the kernel. Each bus's directory contains two subdirectories:
devices/
drivers/
devices/ contains symlinks for each device discovered in the system that point to the device's directory under root/.
drivers/ contains a directory for each device driver that is loaded for devices on that particular bus (this assumes that drivers do not span multiple bus types).
fs/ contains a directory for some filesystems. Currently each filesystem wanting to export attributes must create its own hierarchy below fs/ (see ./fuse.txt for an example).
三、udev
udev是一種工具，它能夠根據系統中的硬體設備的狀況動態更新設備檔，包括設備檔的創建，刪除等。設備檔通常放在/dev目錄下，使用udev後,在/dev下面只包含系統中真實存在的設備。它於硬體平臺無關的，位於用戶空間，需要內核sysfs和tmpfs的支援，sysfs為udev提供設備入口和uevent通道，tmpfs為udev設備檔提供存放空間。
udev運作的原理很簡單,它透過netlink得知目前kernel有那些module新增了,在收到kernel module新增的netlink訊息之後,它會先掃描user是否有指派device node rule,如果沒有,會自動根據module的major和minor number建立device node.有一點比較特殊的地方是,udev用inotify監聽rule變化的event,所以可以即時改變device node的狀態,udev的架構圖可參考如下
如前述，udev的功能是動態的對/dev/下的device node做增減的動作。動態增減是為了解決以往/dev下有太多沒用到的device node，而devfs又有一些"先天的缺陷":
1. 屬於kernel space
2. 存在一些可解和解不了的bug
3. 作者消失，維護者也不見了
4....
在種種原因下，udev取代了devfs。當然 devfs也不是沒有優點，如比較小，比較快(速度)，比較省(memory)，但anyway，過去就讓它過去了。
來吧
基本上，rule是用來在某些條件成立後，執行指令，包括增減device node，並執行外部程式等。比如說，在插入usb disk時，建立/dev/sdb，並mount起來，然後彈出檔案總管。大致條列如下:
1. 將kernel預設的device node改個名字，如把/dev/sdb改成 /dev/apacer-8G (by NAME, no longer works after udev became a part of systemd ??? )
2. 為預設device node建立symbolic link (by SYMLINK)
3. 更彈性的用法，用外部程式來替device node命名 (by PROGRAM)
4. 改變device node的permission和ownership (by GROUP and MODE)
5. device node增減時，執行shell script (by RUN)
時機
通常改變rule是為了改變系統預設的行為，因此，會希望在預設動作前，先完成自己想要做的事。而udev是根據字母排序來parse rule。在rule裡，#開頭的是註解，且每條rule都要在同一行，每條非空行都被視為一條rule。同一個device可以match多條rule，udev會apply每條match的rule。
Syntax
每條rule是由一串(key, value)組成，由comma(“,”)區隔。兩種key:
1. match key(==): 用來識別device，並決定是否要執行該條rule
2. assignment key(=): 當所有的match key都成立，則執行assignment key指定的指令。
每條rule至少要有一個match key和assignment key。
比如說：
KERNEL＝=”sdb”, NAME=”usb_disk”
意思是如果kernel report sdb這個device，則建立usb_disk這個device node (就不會有sdb這個node了)。不過這是比較沒鑑別的rule，因為sdb會隨著插入的順序而assign給不同的usb disk，因此最好是使用可uniquely identified的match key，見下述。
常用的match key如下:
KERNEL: kernel所給的預設名字 (如,sda, lp等)
SUBSYSTEM: device所屬的subsystem，如net, block, usb (可由sysfs得知)
DRIVER: 該device所使用的driver
常用的assignment key如下:
NAME: 該device node的名字
SYMLINK: device node的另一個名字，用symbolic link。這個link可以有很多個，所以可以用+=來做assignmet。
PROGRAM: 指定所需執行的外部程式，其stdout可用來指定device node的名字，用%c表示。若不止一個output，也可用%c{1}，%c{2}或%c{2+}等表示式。
RUN: 在某些rule成立時，再多執行另一個外部程式。這和PROGRAM有點像，只是PROGRAM是用來產生device node的名字。
正規表示法
match key也有類似正規表示法的東西:
*:match任一個字母，0個或多個
?:match一個字母
[]: match 括號內任一個字母，可以是某個range，如[a-p]，[0-9]，或是[!1-3]
例如:
KERNEL=”sd*| hd[a-e]”, NAEM=”block/%k”
字串代換
類似printf的表示法:
%k: kernel給的預設名字，如sdb1
%n:kernel給的device number，若%k是sdb1，則%n是1
%c:外部程式的stdout
特殊字元%與$若要拿來當match key，需寫為:%%和$$
Sysfs登場
以上都是解釋，接下來就是真正的應用了。每個device插入系統時，會export一大堆訊息給sysfs，因此在sysfs裡有許多可用的訊息，而且是可以在rule裡直接剪下貼上的，因此udev和sysfs的關係是相當的密切。先從sysfs裡看看有什麼可以挖的吧!
使用udevinfo來query sysfs:
先插入一個usb disk，看看kernel給了什麼預設的名字:
user@user-ubuntu:/etc/udev/rules.d$ cat /proc/partitions
major minor #blocks name
8 0 244198584 sda
8 1 78180291 sda1
8 2 1 sda2
8 5 158200056 sda5
8 6 7815591 sda6
7 0 10240000 loop0
8 16 7823360 sdb
8 17 7819328 sdb1
這樣可知道，是在sdb，而真正要mount的是sdb1，來查一下:
udevadm info -a -p /sys/block/sdb/sdb1 會看到如下的output (只挑其中兩段做例子):
looking at device '/devices/pci0000:00/0000:00:1d.7/usb4/4-3/4-3:1.0/….':
KERNEL=="sdb1"
SUBSYSTEM=="block"
DRIVER==""
ATTR{start}=="8064"
ATTR{size}=="15638656"
ATTR{stat}==" 78 2219 2765 164 4 ……."
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb4/4-3/4-3:1.0/…':
KERNELS=="52:0:0:0"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{device_blocked}=="0"
ATTRS{type}=="0"
ATTRS{scsi_level}=="0"
ATTRS{vendor}==" "
ATTRS{model}=="USB FLASH DRIVE "
ATTRS{rev}=="PMAP"
ATTRS{state}=="running"
ATTRS{timeout}=="30"
ATTRS{iocounterbits}=="32"
ATTRS{iorequest_cnt}=="0xe3"
ATTRS{iodone_cnt}=="0xe3"
其實這些資訊都是透過driver export給sysfs，而udevinfo只是透過sysfs裡所記錄的內容，整理過後程現出來有關這個device的屬性。而這些屬性都是可以用來做match key。還有一個原則是每段的屬性是不能交互寫在同一個rule。比如說:
KERNEL==”sdb1”, ATTR{size}=="15638656", NAME=”apacer-disk”
SUBSYSTEMS=="scsi", ATTRS{model}=="USB FLASH DRIVE ", NAME=”apacer-disk”
這兩條rule都是對的，但不能這樣用:
KERNEL==”sdb1”, ATTR{size}=="15638656", ATTRS{model}=="USB FLASH DRIVE ", NAME=”apacer-disk”
Permission and ownership
這個比較直覺，就是設定而已
KERNEL==”sdb1”, ATTR{size}=="15638656", NAME=”apacer-disk”, GROUP=”user”, MODE=”0755”
結果如下:
brwxr-xr-x 1 root user 8, 33 2009-07-03 21:52 apacer-8g
Naming by External Program
比較複雜的情況下，可以存在一支命名程式，使用其stdout來當作device node的名字。在rule中，甚至可以傳參數給這支外部程式。其stdout用%c來表;
示，若有多組output，可用%c{1}，%c{2}或%c{2+}這樣的表示方式。舉例如下
SUBSYSTEM=="block", ATTR{size}=="15638656", PROGRAM=”/usr/bin/usb-naming %k”, NAME=”%c”
%k是kernel預設的名字，usb-naming接收此名字後，output結果至stdout。
Run external program upon events
當收到某個udev event後，可再執行某個外部指令。這個跟PROGRAM類似，但不是做naming。比如說，在mount完usb後，做個記錄，可以這麼寫:
SUBSYSTEM=="block", ATTR{size}=="15638656", NAME=”apacer-8g”, RUN+=”/usr/bin/mount-log %k”。
特殊選項
all_partition: 意思大概是為block device建立所有可能的partition，而不是只建一開始偵測到的，不知道這個有什麼應用。
ignore_device:忽略這個event。這個還蠻好用。有些usb有不止一個partition，比如說一個是開機，一個是data。如果每次udev都把這兩個 partition mount起來，但是開機 那個永遠用不到，那就很煩。可用這個選項來忽略開機partition的event。比如:
SUBSYSTEM=="block", ATTR{size}=="1440", OPTIONS+=”ignore_device”
last_rule:對該device不再match之後的rule
1. udev-強大的device node管理系統
2. Howto--udev rules
一、devfs
linux下有專門的檔系統用來對設備進行管理，devfs和sysfs就是其中兩種。
在2.6內核以前一直使用的是devfs，devfs掛載於/dev目錄下，提供了一種類似於檔案的方法來管理位於/dev目錄下的所有設備，我們知道/dev目錄下的每一個檔案都對應的是一個設備，至於當前該設備存在與否先且不論，而且這些特殊檔是位於根檔系統上的，在製作檔案系統的時候我們就已經建立了這些設備檔，因此通過操作這些特殊檔，可以實現與內核進行交互。但是devfs檔案系統有一些缺點，例如：不確定的設備映射，有時一個設備映射的設備檔可能不同，例如我的U盤可能對應sda有可能對應sdb；沒有足夠的主/輔設備號，當設備過多的時候，顯然這會成為一個問題；/dev目錄下檔太多而且不能表示當前系統上的實際設備；命名不夠靈活，不能任意指定等等。
udev的出現, 解決了在devfs上碰到的3個問題
1.udev能夠根據規則建立device node(這可以解決probing時,device node可能會依probing的順序不同而改變)
2.udev動態建立device node,不會像以前在/dev資料夾下擺一堆多而無用的device node
3.提供user更方便的API存取目前device的資訊,在kernel 2.6以上已提供sysfs這個device管理機制
正因為上述這些問題的存在，在linux2.6內核以後，引入了一個新的檔案系統sysfs，它掛載於/sys目錄下，跟devfs一樣它也是一個虛擬檔案系統，也是用來對系統的設備進行管理的，它把實際連接到系統上的設備和匯流排組織成一個分階層的檔案目錄，用戶空間的程式同樣可以利用這些資訊以實現和內核的交互，該檔案系統是當前系統上實際設備樹的一個直觀反應，它是通過kobject子系統來建立這個資訊的，當一個kobject被創建的時候，對應的檔案和目錄也就被創建了，位於/sys下的相關目錄下，既然每個設備在sysfs中都有唯一對應的目錄，那麼也就可以被用戶空間讀寫了。用戶空間的工具udev就是利用了sysfs提供的資訊來實現所有devfs的功能的，但不同的是，udev運行在用戶空間中，而devfs卻運行在內核空間，而且udev不存在devfs那些先天的缺陷。很顯然，sysfs將是未來發展的方向。
The top level sysfs directory looks like:
block/
bus/
class/
devices/
firmware/
net/
fs/
devices/ contains a filesystem representation of the device tree. It maps directly to the internal kernel device tree, which is a hierarchy of struct device.
bus/ contains flat directory layout of the various bus types in the kernel. Each bus's directory contains two subdirectories:
devices/
drivers/
devices/ contains symlinks for each device discovered in the system that point to the device's directory under root/.
drivers/ contains a directory for each device driver that is loaded for devices on that particular bus (this assumes that drivers do not span multiple bus types).
fs/ contains a directory for some filesystems. Currently each filesystem wanting to export attributes must create its own hierarchy below fs/ (see ./fuse.txt for an example).
三、udev
udev是一種工具，它能夠根據系統中的硬體設備的狀況動態更新設備檔，包括設備檔的創建，刪除等。設備檔通常放在/dev目錄下，使用udev後,在/dev下面只包含系統中真實存在的設備。它於硬體平臺無關的，位於用戶空間，需要內核sysfs和tmpfs的支援，sysfs為udev提供設備入口和uevent通道，tmpfs為udev設備檔提供存放空間。
udev運作的原理很簡單,它透過netlink得知目前kernel有那些module新增了,在收到kernel module新增的netlink訊息之後,它會先掃描user是否有指派device node rule,如果沒有,會自動根據module的major和minor number建立device node.有一點比較特殊的地方是,udev用inotify監聽rule變化的event,所以可以即時改變device node的狀態,udev的架構圖可參考如下
如前述，udev的功能是動態的對/dev/下的device node做增減的動作。動態增減是為了解決以往/dev下有太多沒用到的device node，而devfs又有一些"先天的缺陷":
1. 屬於kernel space
2. 存在一些可解和解不了的bug
3. 作者消失，維護者也不見了
4....
在種種原因下，udev取代了devfs。當然 devfs也不是沒有優點，如比較小，比較快(速度)，比較省(memory)，但anyway，過去就讓它過去了。
來吧
基本上，rule是用來在某些條件成立後，執行指令，包括增減device node，並執行外部程式等。比如說，在插入usb disk時，建立/dev/sdb，並mount起來，然後彈出檔案總管。大致條列如下:
1. 將kernel預設的device node改個名字，如把/dev/sdb改成 /dev/apacer-8G (by NAME, no longer works after udev became a part of systemd ??? )
2. 為預設device node建立symbolic link (by SYMLINK)
3. 更彈性的用法，用外部程式來替device node命名 (by PROGRAM)
4. 改變device node的permission和ownership (by GROUP and MODE)
5. device node增減時，執行shell script (by RUN)
時機
通常改變rule是為了改變系統預設的行為，因此，會希望在預設動作前，先完成自己想要做的事。而udev是根據字母排序來parse rule。在rule裡，#開頭的是註解，且每條rule都要在同一行，每條非空行都被視為一條rule。同一個device可以match多條rule，udev會apply每條match的rule。
Syntax
每條rule是由一串(key, value)組成，由comma(“,”)區隔。兩種key:
1. match key(==): 用來識別device，並決定是否要執行該條rule
2. assignment key(=): 當所有的match key都成立，則執行assignment key指定的指令。
每條rule至少要有一個match key和assignment key。
比如說：
KERNEL＝=”sdb”, NAME=”usb_disk”
意思是如果kernel report sdb這個device，則建立usb_disk這個device node (就不會有sdb這個node了)。不過這是比較沒鑑別的rule，因為sdb會隨著插入的順序而assign給不同的usb disk，因此最好是使用可uniquely identified的match key，見下述。
常用的match key如下:
KERNEL: kernel所給的預設名字 (如,sda, lp等)
SUBSYSTEM: device所屬的subsystem，如net, block, usb (可由sysfs得知)
DRIVER: 該device所使用的driver
常用的assignment key如下:
NAME: 該device node的名字
SYMLINK: device node的另一個名字，用symbolic link。這個link可以有很多個，所以可以用+=來做assignmet。
PROGRAM: 指定所需執行的外部程式，其stdout可用來指定device node的名字，用%c表示。若不止一個output，也可用%c{1}，%c{2}或%c{2+}等表示式。
RUN: 在某些rule成立時，再多執行另一個外部程式。這和PROGRAM有點像，只是PROGRAM是用來產生device node的名字。
正規表示法
match key也有類似正規表示法的東西:
*:match任一個字母，0個或多個
?:match一個字母
[]: match 括號內任一個字母，可以是某個range，如[a-p]，[0-9]，或是[!1-3]
例如:
KERNEL=”sd*| hd[a-e]”, NAEM=”block/%k”
字串代換
類似printf的表示法:
%k: kernel給的預設名字，如sdb1
%n:kernel給的device number，若%k是sdb1，則%n是1
%c:外部程式的stdout
特殊字元%與$若要拿來當match key，需寫為:%%和$$
Sysfs登場
以上都是解釋，接下來就是真正的應用了。每個device插入系統時，會export一大堆訊息給sysfs，因此在sysfs裡有許多可用的訊息，而且是可以在rule裡直接剪下貼上的，因此udev和sysfs的關係是相當的密切。先從sysfs裡看看有什麼可以挖的吧!
使用udevinfo來query sysfs:
先插入一個usb disk，看看kernel給了什麼預設的名字:
user@user-ubuntu:/etc/udev/rules.d$ cat /proc/partitions
major minor #blocks name
8 0 244198584 sda
8 1 78180291 sda1
8 2 1 sda2
8 5 158200056 sda5
8 6 7815591 sda6
7 0 10240000 loop0
8 16 7823360 sdb
8 17 7819328 sdb1
這樣可知道，是在sdb，而真正要mount的是sdb1，來查一下:
udevadm info -a -p /sys/block/sdb/sdb1 會看到如下的output (只挑其中兩段做例子):
looking at device '/devices/pci0000:00/0000:00:1d.7/usb4/4-3/4-3:1.0/….':
KERNEL=="sdb1"
SUBSYSTEM=="block"
DRIVER==""
ATTR{start}=="8064"
ATTR{size}=="15638656"
ATTR{stat}==" 78 2219 2765 164 4 ……."
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb4/4-3/4-3:1.0/…':
KERNELS=="52:0:0:0"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{device_blocked}=="0"
ATTRS{type}=="0"
ATTRS{scsi_level}=="0"
ATTRS{vendor}==" "
ATTRS{model}=="USB FLASH DRIVE "
ATTRS{rev}=="PMAP"
ATTRS{state}=="running"
ATTRS{timeout}=="30"
ATTRS{iocounterbits}=="32"
ATTRS{iorequest_cnt}=="0xe3"
ATTRS{iodone_cnt}=="0xe3"
其實這些資訊都是透過driver export給sysfs，而udevinfo只是透過sysfs裡所記錄的內容，整理過後程現出來有關這個device的屬性。而這些屬性都是可以用來做match key。還有一個原則是每段的屬性是不能交互寫在同一個rule。比如說:
KERNEL==”sdb1”, ATTR{size}=="15638656", NAME=”apacer-disk”
SUBSYSTEMS=="scsi", ATTRS{model}=="USB FLASH DRIVE ", NAME=”apacer-disk”
這兩條rule都是對的，但不能這樣用:
KERNEL==”sdb1”, ATTR{size}=="15638656", ATTRS{model}=="USB FLASH DRIVE ", NAME=”apacer-disk”
Permission and ownership
這個比較直覺，就是設定而已
KERNEL==”sdb1”, ATTR{size}=="15638656", NAME=”apacer-disk”, GROUP=”user”, MODE=”0755”
結果如下:
brwxr-xr-x 1 root user 8, 33 2009-07-03 21:52 apacer-8g
Naming by External Program
比較複雜的情況下，可以存在一支命名程式，使用其stdout來當作device node的名字。在rule中，甚至可以傳參數給這支外部程式。其stdout用%c來表;
示，若有多組output，可用%c{1}，%c{2}或%c{2+}這樣的表示方式。舉例如下
SUBSYSTEM=="block", ATTR{size}=="15638656", PROGRAM=”/usr/bin/usb-naming %k”, NAME=”%c”
%k是kernel預設的名字，usb-naming接收此名字後，output結果至stdout。
Run external program upon events
當收到某個udev event後，可再執行某個外部指令。這個跟PROGRAM類似，但不是做naming。比如說，在mount完usb後，做個記錄，可以這麼寫:
SUBSYSTEM=="block", ATTR{size}=="15638656", NAME=”apacer-8g”, RUN+=”/usr/bin/mount-log %k”。
特殊選項
all_partition: 意思大概是為block device建立所有可能的partition，而不是只建一開始偵測到的，不知道這個有什麼應用。
ignore_device:忽略這個event。這個還蠻好用。有些usb有不止一個partition，比如說一個是開機，一個是data。如果每次udev都把這兩個 partition mount起來，但是開機 那個永遠用不到，那就很煩。可用這個選項來忽略開機partition的event。比如:
SUBSYSTEM=="block", ATTR{size}=="1440", OPTIONS+=”ignore_device”
last_rule:對該device不再match之後的rule
2017-04-18
bootstrap of Allwinner A64
source :
1. [u-boot.git] / board / sunxi / README.pine64
2. Allwinner 64-bit boards README
1 Pine64 board README
2 ====================
3
4 The Pine64(+) is a single board computer equipped with an AArch64 capable ARMv8
5 compliant Allwinner A64 SoC.
6 This chip has ARM Cortex A-53 cores and thus can run both in AArch32
7 (compatible to 32-bit ARMv7) and AArch64 modes. Upon reset the SoC starts
8 in AArch32 mode and executes 32-bit code from the Boot ROM (BROM).
9 This has some implications on U-Boot.
10
11 Quick start
12 ============
13 - Get hold of a boot0.img file (see below for more details).
14 - Get the boot0img tool source from the tools directory in [1] and compile
15 that on your host.
16 - Build U-Boot:
18 $ make pine64_plus_defconfig
19 $ make
20 - You also need a compiled ARM Trusted Firmware (ATF) binary. Checkout the
21 "allwinner" branch from the github repository [2] and build it:
23 $ make PLAT=sun50iw1p1 DEBUG=1 bl31
24 The resulting binary is build/sun50iw1p1/debug/bl31.bin.
25
26 Now put an empty (or disposable) micro SD card in your card reader and learn
27 its device file name, replacing /dev/sd below with the result (that could
28 be /dev/mmcblk as well):
29
30 $ ./boot0img --device /dev/sd -e -u u-boot.bin -B boot0.img \
31 -d trampoline64:0x44000 -s bl31.bin -a 0x44008 -p 100
32 (either copying the respective files to the working directory or specifying
33 the paths directly)
34
35 This will create a new partition table (with a 100 MB FAT boot partition),
36 copies boot0.img, ATF and U-Boot to the proper locations on the SD card and
37 will fill in the magic Allwinner header to be recognized by boot0.
38 Prefix the above call with "sudo" if you don't have write access to the
39 uSD card. You can also use "-o output.img" instead of "--device /dev/sd"
40 to create an image file and "dd" that to the uSD card.
41 Omitting the "-p" option will skip the partition table.
42
43 Now put this uSD card in the board and power it on. You should be greeted by
44 the U-Boot prompt.
45
46
47 Main U-Boot
48 ============
49 The main U-Boot proper is a real 64-bit ARMv8 port and runs entirely in the
50 64-bit AArch64 mode. It can load any AArch64 code, EFI applications or arm64
51 Linux kernel images (often named "Image") using the booti command.
52 Launching 32-bit code and kernels is technically possible, though not without
53 drawbacks (or hacks to avoid them) and currently not implemented.
54
55 SPL support
56 ============
57 The main task of the SPL support is to bring up the DRAM controller and make
58 DRAM actually accessible. At the moment there is no documentation or source
59 code available which would do this.
60 There are currently two ways to overcome this situation: using a tainted 32-bit
61 SPL (involving some hacks and resulting in a non-redistributable binary, thus
62 not described here) or using the Allwinner boot0 blob.
63
64 boot0 method
65 -------------
66 boot0 is Allwiner's secondary program loader and it can be used as some kind
67 of SPL replacement to get U-Boot up and running.
68 The binary is a 32 KByte blob and contained on every Pine64 image distributed
69 so far. It can be easily extracted from a micro SD card or an image file:
70 # dd if=/dev/sd of=boot0.bin bs=8k skip=1 count=4
71 where /dev/sd is the device name of the uSD card or the name of the image
72 file. Apparently Allwinner allows re-distribution of this proprietary code
73 as-is.
74 For the time being this boot0 blob is the only redistributable way of making
75 U-Boot work on the Pine64. Beside loading the various parts of the (original)
76 firmware it also switches the core into AArch64 mode.
77 The original boot0 code looks for U-Boot at a certain place on an uSD card
78 (at 19096 KB), also it expects a header with magic bytes and a checksum.
79 There is a tool called boot0img[1] which takes a boot0.bin image and a compiled
80 U-Boot binary (plus other binaries) and will populate that header accordingly.
81 To make space for the magic header, the pine64_plus_defconfig will make sure
82 there is sufficient space at the beginning of the U-Boot binary.
83 boot0img will also take care of putting the different binaries at the right
84 places on the uSD card and works around unused, but mandatory parts by using
85 trampoline code. See the output of "boot0img -h" for more information.
86 boot0img can also patch boot0 to avoid loading U-Boot from 19MB, instead
87 fetching it from just behind the boot0 binary (-B option).
88
89 FEL boot
90 =========
91 FEL is the name of the Allwinner defined USB boot protocol built-in the
92 mask ROM of most Allwinner SoCs. It allows to bootstrap a board solely
93 by using the USB-OTG interface and a host port on another computer.
94 Since FEL boot does not work with boot0, it requires the libdram hack, which
95 is not described here.
96
97 [1] https://github.com/apritzel/pine64/
98 [2] https://github.com/apritzel/arm-trusted-firmware.git
1. [u-boot.git] / board / sunxi / README.pine64
2. Allwinner 64-bit boards README
1 Pine64 board README
2 ====================
3
4 The Pine64(+) is a single board computer equipped with an AArch64 capable ARMv8
5 compliant Allwinner A64 SoC.
6 This chip has ARM Cortex A-53 cores and thus can run both in AArch32
7 (compatible to 32-bit ARMv7) and AArch64 modes. Upon reset the SoC starts
8 in AArch32 mode and executes 32-bit code from the Boot ROM (BROM).
9 This has some implications on U-Boot.
10
11 Quick start
12 ============
13 - Get hold of a boot0.img file (see below for more details).
14 - Get the boot0img tool source from the tools directory in [1] and compile
15 that on your host.
16 - Build U-Boot:
$ git clone https://github.com/u-boot/u-boot.git
$ cd u-boot
$ export CROSS_COMPILE=aarch64-linux-gun-
$ make pine64_plus_defconfig
$ make18 $ make pine64_plus_defconfig
19 $ make
20 - You also need a compiled ARM Trusted Firmware (ATF) binary. Checkout the
21 "allwinner" branch from the github repository [2] and build it:
$ git clone https://github.com/apritzel/arm-trusted-firmware.git
$ cd arm-trusted-firmware
$ git checkout allwinner
$ export CROSS_COMPILE=aarch64-linux-gnu-
$ make PLAT=sun50iw1p1 DEBUG=1 bl3123 $ make PLAT=sun50iw1p1 DEBUG=1 bl31
24 The resulting binary is build/sun50iw1p1/debug/bl31.bin.
25
26 Now put an empty (or disposable) micro SD card in your card reader and learn
27 its device file name, replacing /dev/sd
28 be /dev/mmcblk
29
30 $ ./boot0img --device /dev/sd
31 -d trampoline64:0x44000 -s bl31.bin -a 0x44008 -p 100
32 (either copying the respective files to the working directory or specifying
33 the paths directly)
34
35 This will create a new partition table (with a 100 MB FAT boot partition),
36 copies boot0.img, ATF and U-Boot to the proper locations on the SD card and
37 will fill in the magic Allwinner header to be recognized by boot0.
38 Prefix the above call with "sudo" if you don't have write access to the
39 uSD card. You can also use "-o output.img" instead of "--device /dev/sd
40 to create an image file and "dd" that to the uSD card.
41 Omitting the "-p" option will skip the partition table.
42
43 Now put this uSD card in the board and power it on. You should be greeted by
44 the U-Boot prompt.
45
46
47 Main U-Boot
48 ============
49 The main U-Boot proper is a real 64-bit ARMv8 port and runs entirely in the
50 64-bit AArch64 mode. It can load any AArch64 code, EFI applications or arm64
51 Linux kernel images (often named "Image") using the booti command.
52 Launching 32-bit code and kernels is technically possible, though not without
53 drawbacks (or hacks to avoid them) and currently not implemented.
54
55 SPL support
56 ============
57 The main task of the SPL support is to bring up the DRAM controller and make
58 DRAM actually accessible. At the moment there is no documentation or source
59 code available which would do this.
60 There are currently two ways to overcome this situation: using a tainted 32-bit
61 SPL (involving some hacks and resulting in a non-redistributable binary, thus
62 not described here) or using the Allwinner boot0 blob.
63
64 boot0 method
65 -------------
66 boot0 is Allwiner's secondary program loader and it can be used as some kind
67 of SPL replacement to get U-Boot up and running.
68 The binary is a 32 KByte blob and contained on every Pine64 image distributed
69 so far. It can be easily extracted from a micro SD card or an image file:
70 # dd if=/dev/sd
71 where /dev/sd
72 file. Apparently Allwinner allows re-distribution of this proprietary code
73 as-is.
74 For the time being this boot0 blob is the only redistributable way of making
75 U-Boot work on the Pine64. Beside loading the various parts of the (original)
76 firmware it also switches the core into AArch64 mode.
77 The original boot0 code looks for U-Boot at a certain place on an uSD card
78 (at 19096 KB), also it expects a header with magic bytes and a checksum.
79 There is a tool called boot0img[1] which takes a boot0.bin image and a compiled
80 U-Boot binary (plus other binaries) and will populate that header accordingly.
81 To make space for the magic header, the pine64_plus_defconfig will make sure
82 there is sufficient space at the beginning of the U-Boot binary.
83 boot0img will also take care of putting the different binaries at the right
84 places on the uSD card and works around unused, but mandatory parts by using
85 trampoline code. See the output of "boot0img -h" for more information.
86 boot0img can also patch boot0 to avoid loading U-Boot from 19MB, instead
87 fetching it from just behind the boot0 binary (-B option).
88
89 FEL boot
90 =========
91 FEL is the name of the Allwinner defined USB boot protocol built-in the
92 mask ROM of most Allwinner SoCs. It allows to bootstrap a board solely
93 by using the USB-OTG interface and a host port on another computer.
94 Since FEL boot does not work with boot0, it requires the libdram hack, which
95 is not described here.
96
97 [1] https://github.com/apritzel/pine64/
98 [2] https://github.com/apritzel/arm-trusted-firmware.git
2017-04-16
Linux - how to format multiple file systems within one file?
source : Linux - how to format multiple file systems within one file?
psihodelia:
Linux - how to format multiple file systems within one file?
I need to create a disk image with two empty file systems. I have created it using
dd if=/dev/zero of=./disk.img bs=1MiB count=1024
Next, I have created 2 primary partitions using fdisk disk.img; one is FAT32 and other is EXT3. Now, I have to format both partitions in order to create file-systems to be mounted as -o loop devices. But I can't understand how to format them? I can't use mkfs.vfat on disk.img. So I am totally confused.
SOLUTION: Thanks to answer from @pjc50 I found very simple solution:
sudo aptitude install multipath-tools
sudo kpartx -a disk.img #it maps (mounts) found partitions to /dev/mapper/loop...
sudo mkfs.vfat -F 32 -n boot /dev/mapper/loop0p1
sudo mkfs.ext3 -L rootfs /dev/mapper/loop0p2
A drawback of this solution is requirement of superuser rights.
-----------------------------------------------------------------------
karatedog:
I would go with the tools I have in mind:
create a new VM in Virtualbox with one disk, that would usually be /dev/sda
boot into the VM with a GParted Live CD
partition and format the disk in the VM to your needs (2 partitions, different file systems, etc.)
then use dd to export /dev/sda to a file
With an educated guess it would take about 15 minutes.
-----------------------------------------------------------------------
Shawn Chin:
You can do so by first mounting your partitions to /dev/loop? using losetup with the -o option to specify a suitable offset to your partition. The offset can be calculated based on the output of fdisk -l disk.img (start_sector * sector_size).
For example:
losetup -o32256 /dev/loop1 ./disk.img # mount first partition
Once mounted, you can then proceed to format the partition using mkfs.*:
mkfs.vfat -F32 /dev/loop1
For more details and examples, see the following articles:
http://wiki.osdev.org/Loopback_Device#Mounting
http://web2.clarkson.edu/projects/itl/honeypot/ddtutorial.txt
http://wiki.eeeuser.com/howtocustomrestoreimage:pt2mkcustomimage
-----------------------------------------------------------------------
pjc50
It appears you can use the kpartx tools: http://robert.penz.name/73/kpartx-a-tool-for-mounting-partitions-within-an-image-file/
Kpartx can be used to set up device mappings for the partitions of any partitioned block device. It is part of the Linux multipath-tools. With kpartx -l imagefile you get an overview of the partitions in the image file and with kpartx -a imagefile the partitions will accessible via /dev/mapper/loop0pX (X is the number of the partition). You can mount it now with mount /dev/mapper/loop0pX /mnt/ -o loop,ro. After unmounting you can disconnect the mapper devices with kpartx -d imagefile.
psihodelia:
Linux - how to format multiple file systems within one file?
I need to create a disk image with two empty file systems. I have created it using
dd if=/dev/zero of=./disk.img bs=1MiB count=1024
Next, I have created 2 primary partitions using fdisk disk.img; one is FAT32 and other is EXT3. Now, I have to format both partitions in order to create file-systems to be mounted as -o loop devices. But I can't understand how to format them? I can't use mkfs.vfat on disk.img. So I am totally confused.
SOLUTION: Thanks to answer from @pjc50 I found very simple solution:
sudo aptitude install multipath-tools
sudo kpartx -a disk.img #it maps (mounts) found partitions to /dev/mapper/loop...
sudo mkfs.vfat -F 32 -n boot /dev/mapper/loop0p1
sudo mkfs.ext3 -L rootfs /dev/mapper/loop0p2
A drawback of this solution is requirement of superuser rights.
-----------------------------------------------------------------------
karatedog:
I would go with the tools I have in mind:
create a new VM in Virtualbox with one disk, that would usually be /dev/sda
boot into the VM with a GParted Live CD
partition and format the disk in the VM to your needs (2 partitions, different file systems, etc.)
then use dd to export /dev/sda to a file
With an educated guess it would take about 15 minutes.
-----------------------------------------------------------------------
Shawn Chin:
You can do so by first mounting your partitions to /dev/loop? using losetup with the -o option to specify a suitable offset to your partition. The offset can be calculated based on the output of fdisk -l disk.img (start_sector * sector_size).
For example:
losetup -o32256 /dev/loop1 ./disk.img # mount first partition
Once mounted, you can then proceed to format the partition using mkfs.*:
mkfs.vfat -F32 /dev/loop1
For more details and examples, see the following articles:
http://wiki.osdev.org/Loopback_Device#Mounting
http://web2.clarkson.edu/projects/itl/honeypot/ddtutorial.txt
http://wiki.eeeuser.com/howtocustomrestoreimage:pt2mkcustomimage
-----------------------------------------------------------------------
pjc50
It appears you can use the kpartx tools: http://robert.penz.name/73/kpartx-a-tool-for-mounting-partitions-within-an-image-file/
Kpartx can be used to set up device mappings for the partitions of any partitioned block device. It is part of the Linux multipath-tools. With kpartx -l imagefile you get an overview of the partitions in the image file and with kpartx -a imagefile the partitions will accessible via /dev/mapper/loop0pX (X is the number of the partition). You can mount it now with mount /dev/mapper/loop0pX /mnt/ -o loop,ro. After unmounting you can disconnect the mapper devices with kpartx -d imagefile.
2017-03-06
安裝 ARM ToolChain on Debian
in Synaptic, install
1. crossbuild-essential-arm64 : 64 bits
2. crossbuild-essential-armel : 32 bits, soft floating point
3. crossbuild-essential-armhf : 32 bits, hard floating
為了方便未來我們使用, 三個不同版本的工具，可在 ~/.bashrc 中新增底下設定：
alias makearmel='make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-'
alias makearmhf='make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-'
alias makearm64='make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-'
----------------------------------------------------------------------------------------------
以 qemu-arm 測試:
: arm-linux-gnueabihf-gcc hello.c -o hello_arm
: qemu-arm -L /usr/arm-linux-armhf hello_arm
*** 善用 man qemu-arm ***
1. crossbuild-essential-arm64 : 64 bits
2. crossbuild-essential-armel : 32 bits, soft floating point
3. crossbuild-essential-armhf : 32 bits, hard floating
為了方便未來我們使用, 三個不同版本的工具，可在 ~/.bashrc 中新增底下設定：
alias makearmel='make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-'
alias makearmhf='make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-'
alias makearm64='make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-'
----------------------------------------------------------------------------------------------
以 qemu-arm 測試:
: arm-linux-gnueabihf-gcc hello.c -o hello_arm
: qemu-arm -L /usr/arm-linux-armhf hello_arm
*** 善用 man qemu-arm ***
Kernel Building for Raspberry pi (ARM CPU)
1. [進階] 安裝 Raspberry Pi 的 Toolchain
2. [進階] 編譯 Raspberry Pi 的核心 OR KERNEL BUILDING : DOCUMENTATION > LINUX > KERNEL > BUILDING
raspberrypi-tools 是 32bits 的，所以在 debian wheezy amd64 要裝上 32bits 的程式庫。
$ sudo apt-get install libc6-i386 lib32stdc++6 lib32z1
裝好後，試試看指令能不能執行
$ arm-linux-gnueabihf-gcc
arm-linux-gnueabihf-gcc: fatal error: no input files
compilation terminated.
這樣 no input files 就是正常可執行的狀況
-bash: /opt/cross/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc: No such file or directory
若出現 No such file or directory 則應該是 32bits 程式庫沒裝好，再用 ldd 檢查一下。
2. [進階] 編譯 Raspberry Pi 的核心 OR KERNEL BUILDING : DOCUMENTATION > LINUX > KERNEL > BUILDING
raspberrypi-tools 是 32bits 的，所以在 debian wheezy amd64 要裝上 32bits 的程式庫。
$ sudo apt-get install libc6-i386 lib32stdc++6 lib32z1
裝好後，試試看指令能不能執行
$ arm-linux-gnueabihf-gcc
arm-linux-gnueabihf-gcc: fatal error: no input files
compilation terminated.
這樣 no input files 就是正常可執行的狀況
-bash: /opt/cross/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc: No such file or directory
若出現 No such file or directory 則應該是 32bits 程式庫沒裝好，再用 ldd 檢查一下。
armel和armhf區別選擇
出於低功耗、封裝限制等種種原因，之前的一些ARM架構處理器因為內部資源寶貴，加入浮點運算單元是十分奢侈的，因為需要額外的軟件實現。隨著技術發展，目前高端的ARM處理器已經具備了硬件執行浮點操作的能力。這樣新舊兩種架構之間的差異，就產生了兩個不同的嵌入式應用程序二進制接口（EABI）——軟浮點與矢量浮點（VFP）。但是軟浮點（soft float）和硬浮點（hard float）之間有向前兼容卻沒有向後兼容的能力，也就是軟浮點的二進制接口（EABI）仍然可以用於當前的高端ARM處理器。
fpu單元
在ARM體系架構內核中，有些有浮點運算單元（fpu），有些沒有。對於沒有fpu內核，是不能使用armel和armhf的。在有fpu的情況下，就可以通過gcc的選項-mfloat-abi來指定使用哪種，有如下三種值：
- soft：不用fpu計算，即使有fpu浮點運算單元也不用。
- armel：也即softfp，用fpu計算，但是傳參數用普通寄存器傳，這樣中斷的時候，只需要保存普通寄存器，中斷負荷小，但是參數需要轉換成浮點的再計算。
- armhf：也即hard，用fpu計算，傳參數用fpu中的浮點寄存器傳，省去了轉換性能最好，但是中斷負荷高。
kernel、rootfs和app編譯的時候，指定的必須保持一致才行。
使用softfp模式，會存在不必要的浮點到整數、整數到浮點的轉換。而使用hard模式，在每次浮點相關函數調用時，平均能節省20個CPU週期。對ARM這樣每個週期都很重要的體系結構來說，這樣的提升無疑是巨大的。
在完全不改變源碼和配置的情況下，在一些應用程序上，雖然armhf比armel硬件要求（確切的是指fpu硬件）高一點，但是armhf能得到20-25%的性能提升。對一些嚴重依賴於浮點運算的程序，更是可以達到300%的性能提升。
armel與armhf
之前EABI中，armel（低端ARM硬件，支持armv4以上版本），在執行浮點運算之前，浮點參數必須首先通過整數寄存器，然後傳遞到浮點運算單元。新的EABI ，也就是armhf，通過直接傳遞參數到浮點寄存器優化了浮點運算的調用約定。
相比我們熟悉的armel，armhf代表了另一種不兼容的二進制標準。在一些社區的支持下，armhf目前已經得到了很大的發展。像Ubuntu，已經計畫在之後的發行版中放棄armel，轉而支持armhf編譯的版本。正如目前依然很火熱的Raspberry Pi（ARM11），由於ubuntu只支持armv7架構的編譯，Raspberry Pi將不能直接安裝ubuntu系統。而BB Black（Cortex-A8）和Cubietruct（Cortex-A7）則同時支持ubuntu的armel與armhf的編譯。
安裝armel和armhf
以上就是armel與armhf的比較。相信大家也應該有個大概的瞭解了。在Ubuntu系統下，如何根據需求分別實現兩種交叉編譯器的安裝呢？
arm-linux-gnueabi的安裝 (debian synaptic supported)
sudo apt-get install gcc-arm-linux-gnueabi
按操作下載即可，沒啥好說的。
arm-linux-gnueabihf的安裝 (debian synaptic supported)
兩種方法，
- linaro開源組織有相關的交叉工具鏈下載，點擊進入網頁選擇下載即可，地址：https://launchpad.net/linaro-toolchain-binaries。
- 到本站工具鏈頁面下載，地址：http://www.veryarm.com/arm-linux-gnueabihf-gcc。
然後就是解壓到自定義目錄中，並添加bin環境變量。
armhf 使用
armhf的開啟需要硬件的支持，在Debian的wiki上要求ARMv7 CPU、Thumb-2指令集以及VFP3D16浮點處理器。
在gcc的編譯參數上，使用-mfloat-abi=hard -mfpu=vfp即可。
在工具上，CodeSourcery最早支持hard模式。或者，也可已自己編譯工具鏈。
Subscribe to:
Posts (Atom)