Ubuntu裡 用terminal看jpeg圖.... 借jp2a轉成ascii圖

https://csl.name/jp2a/

Ubuntu中，用指令釋放記憶體 (雖然並無必要)

設計上Ubuntu會自己管理釋放記憶體
但如果你手癢看不順眼，也可以用指令執行釋放

To free pagecache:

• echo 1 > /proc/sys/vm/drop_caches

To free dentries and inodes:

• echo 2 > /proc/sys/vm/drop_caches

To free pagecache, dentries and inodes:

• echo 3 > /proc/sys/vm/drop_caches

從Windows 7 遠端桌面連線到 Ubuntu 14.04

Ubuntu 14.04端:
sudo apt-get install xrdp

然後
gsettings set org.gnome.Vino require-encryption false
然後
reboot
找個帳號登入桌面

Windows 7端:
遠端桌面連線
連到Ubuntu ip:3389 (xrdp預設port)
Module選console
passwd敲入該帳號的密碼

[好文] 使用 rsync 實做重複資料刪除技術

http://www.ringline.com.tw/support/techpapers/storage/135--rsync-.html

前言
很多人使用rsync這個工具軟體進行日常檔案備份的工作。這個用來取代rcp的遠端檔案複製工具使用非常有效率的演算法進行檔案比對、傳輸與複製，並且支援遠端shell (remote-shell) 和rsync伺服器 (rsync daemon) 的彈性架構，讓整個檔案同步、備份的工作可以簡單的進入排程，達到完全自動。 


而隨著軟體版本的演進，超過一百個以上的功能選項，對於絕大部分的使用者來說可能還只是單純使用「歸檔」 (-a) 和「同步刪除」 (--delete) 這兩個選項就滿足了日常需求。不過像這樣簡單的設定在重複操作之下只能保有一份備份當時的全備份，卻也同時讓之前的備份直接被覆蓋而無法參考。因此，如果需要保留多次長週期的備份而使用相同的方法，這似乎意味著需要倍數的磁碟空間，和指定不同的歸檔路徑才可以容納得下多次全備份。 


其實rsync早已支援「增量備份」的實做方法。透過不同的功能選項可以讓每次同步備份過程中遇到的「差異」用不同方式保留下來，做到增量備份的效果。只是在技巧上必須撰寫指令稿 (script) 將整個備份流程包裝起來才能達到實用的目的。因此已經有許多配合rsync的「前導程式」 (不用修改軟體而達到修改軟體的目的的工具軟體) 被開發出來，使用整合的操作介面針對每次備份出來的檔案進行版本控制，並提供類似高階儲存設備的「快照備份」 (snapshot) 呈現方式，讓使用者可以任意切換到歷史版本的目錄當中直接找到之前備份的檔案，而且重點是「不需要倍數的磁碟空間就可以容納多次的全備份」，這似乎與「重複資料刪除技術」 (Data De-duplication) 有異曲同工之妙！ 


以下就針對rsync實做增量備份相關的功能選項做一個簡單的說明，並介紹一個以perl語言所開發的前導程式「rsnapshot」，看看它是如何將週期性的rsync備份模擬成檔案系統的快照備份，讓使用者可以用最節省的空間的方式保有多次的備份，而且可以直接存取任一版本的全備份。 


rsync 的增量備份
為了方便說明，以下出現的語法是以直接在本機檔案系統下操作為範例。如果需要透過rsync daemon或remote-shell模式應用在遠端檔案系統，則直接代換對應的語法即可。 


基本同步
如果我們需要備份目錄a，最基本的語法會是像這個樣子： 


rsync -a --delete a/ b/


這會在目的端產生一個目錄b，兩個目錄以下的內容在同步備份之後會一模一樣。-a代表歸檔模式，是-rlptgoD的簡化寫法，意味遞迴地進入來源端目錄a下所有的目錄，將比對、複製所有的檔案和目錄，不僅保留時間、權限、擁有者、群組等屬性，連符號連結及設備檔案也一併複製。而--delete功能選項的效果，在重複操作的時候，若目錄a下有檔案或目錄被刪除，會同步反應在目錄b。這裡需要注意到的地方，就是目錄a後面的斜線是必要的，如果沒有這個斜線，則同步備份之後的結果就是將整個目錄a備份在目錄b之下，變成b/a/的效果。 


增量備份
使用--backup選項在同步備份過程中可以讓目的端的檔案，被覆蓋或刪除之前先進行更名的動作以保留下來。 


rsync -a --delete --backup a/ b/


使用這個功能選項在預設的情況下，如果目錄a下的檔案file1被更新或刪除，則在下一次同步備份時，在目的端目錄b會將前一次備份的那個版本先更名為file1~保留下來，然後如果是更新檔案則再儲存新版本的file1，如果是刪除檔案則就不動作。這樣的作法只能保有更新之前的版本，或之前還在的檔案。在反覆同步備份操作之下，在目的端目錄b對任一檔案而言，頂多只能多留一份過去版本的備份，而形成諸多不同時間點不同檔案的「備份的備份」散落在目錄b之下。 


所以解決這個問題的方法是另外透過--backup-dir來指定目的端的檔案在被覆蓋或刪除之前，先被複製到特定的路徑之下。這樣的作法相當是實做最簡易的增量備份。 


rsync -a --delete --backup --backup-dir=../c/ a/ b/


如果目錄a的檔案被更新或刪除，則在下一次同步備份時，在目的端目錄b的前一次備份的那個版本會先複製到目錄c，然後再儲存新的版本到目錄b。 這與傳統增量備份的概念正好相反，傳統增量備份的第一份是全備份，之後的備份只留與前一次備份的差異；而rsync用--backup-dir方式進行增量備份則是最後一次備份是全備份 (目錄b) ，同時將差異記錄在另外一個目錄裡 (目錄c) 。所以透過每次備份指定不同backup dir的技巧，就可以記錄每次備份當時的差異，這樣不用倍數的儲存空間，就可以保留多次備份當時的狀態。但這裡會有的問題是，在backup dir裡出現的檔案，是之前備份之後被修改或刪除的檔案，在利用上必須跟最後一次同步備份的目錄做比較，才大概可以看得出來檔案是被修改還是被刪除。因此這個備份方式並不一定適用在任何環境。 


在這裡要注意的是，若使用相對路徑表示法，--backup-dir所指定的路徑就必須是相對於目錄b的路徑。所以前面範例的目錄b與目錄c是在同一層。而且--backup-dir是配合--backup同時使用的功能選項。 


另外一種與--backup-dir類似的功能選項是--compare-dest。這是一個獨立的選項，它讓來源端目錄a與指定的compare dest目錄c先進行比對，然後把是否覆蓋、刪除檔案的動作反應在目錄b。 


rsync -a --delete --compare-dest=../c/ a/ b/


這樣的作法必須是目錄c與目錄a之前曾先同步過，之後目錄a的任何檔案更新可以經由這個方式與目錄c比對後再將更新的檔案複製到目錄b。這個用途比較適合追蹤在前一次同步備份過後，有哪些檔案被更動過，但不包含被刪除。 


所以如果需要兩次完整的備份內容，可以用--copy-dest這個功能選項。 


rsync -a --delete --copy-dest=../c/ a/ b/


它與--compare-dest類似，作法是目錄c與目錄a之前曾先同步過，之後一樣是讓來源端目錄a與指定的copy dest目錄c先進行比對，然後將沒有被更動的檔案直接從目錄c複製到目錄b，有被更動的檔案從目錄a複製到目錄b，被刪除的檔案就不儲存。這樣的好處是從目錄c或從目錄b來看都是完整的某一次備份，而且應用在不同主機之間的備份可以節省很多網路頻寬，因為原本單純同步複製一個新的目的端就必須重新傳輸所有檔案一次，而利用這個方式則直接在目的端主機上拿之前的備份來複製，進而提高同步的效率，而且每個目錄都是備份當時的全備份，直接拿來還原也很方便。 


不過這樣的操作就等於備份幾次就需要幾倍的空間，與原來往增量備份方向去想的作法就背道而馳了。 


所以在rsync版本2.5.6之後新增加--link-dest的功能選項，它把--copy-dest當中「沒有更動的檔案直接複製的動作」用檔案的「硬式連結」 (hard link) 來取代。 


rsync -a --delete --link-dest=../c/ a/ b/


所以同樣的，目錄a與目錄c之前曾同步備份過，之後透過這個方式目錄a會先與目錄c進行比對，沒有被更動過的檔案直接在目錄b利建立硬式連結到目錄c的檔案，有被更動的檔案則從目錄a複製到目錄b，被刪除的檔案則不儲存。這樣一來同樣從目錄c或從目錄b來看都是完整的某一次全備份，而且因為是檔案的硬式連結，所以相同版本的檔案只佔據同一份空間。如果反覆備份多次，由於大部分的檔案都是靜態未被更動，那麼所有需要的容量就是最早的全備份與之後每次備份的差異量的總和而已。 


其實在這個功能選項出現之前，就已經有方法可以做到相同的效果。一樣是用rsync反覆操作基本同步的方法 (-a --delete) ，只是在每次操作之前，先在目的端把之前備份好的目錄進行一次用硬式連結的複製。 


第一次備份：來源端目錄a同步備份到目的端目錄c。 


rsync -a --delete a/ c/


在目的端之前的備份是目錄c，則有兩種方式可以產生用硬式連結複製出來的目錄b： 


cp -al c/ b/


或 


cd c && find . -print | cpio -dpl ../b


第二次備份：來源端目錄a同步備份到目的端目錄b。 


rsync -a --delete a/ b/


這裡的cp是GNU cp，在Linux環境下是預設的複製工具，可以直接使用。cp -al會以歸檔的方式複製檔案，但所有的檔案以硬式連結來建立。可是在其他平台上若沒有GNU cp，就不會有-al的選項，所以只能選擇用cpio來進行複製。 當完成這個複製動作之後，兩個目錄下檔案其實對應到相同的Inode，檔案本身的連結計數 (link counter) 加一之後為二，檔案對應到的實體區塊只有一份，所以除了目錄結構以外，不佔額外的空間。 接下來之後的備份使用rsync基本的同步方式指定目的端為目錄b。在這裡不用擔心因為是檔案的硬式連結，目錄b和目錄c下同一檔案當再次同步備份時會導致一起被覆蓋或刪除，因為rsync預設的行為會先將異動的檔案以另外的檔名複製出來進行更新，然後再更名為原來的檔名。所以不管是覆蓋還是刪除，都只是對原本檔案的連結計數做減一的動作，而在連結計數歸零之前，也就是檔案真正被刪除之前，都不會更動到原本備份的那個版本。 


所以不管使用哪一個版本的rsync，再搭配一些操作的技巧就可以實做出類似「重複資料刪除技術」的效果。而我們不需要另外撰寫script來實做這個部分，因為已經有許多現成的工具軟體可以自動化這些操作流程。以下就以rsnapshot這個軟體為例子，說明這是怎麼做到的。 

rsnapshot
rsnapshot是一個自由軟體 (free software) ，可以從官方網站 (http://www.rsnapshot.org/) 下載，或從作業系統的軟體管理工具當中找到既有的port或package來進行安裝。它是一個以perl語言開發的工具軟體，一個遠端檔案系統的快照工具 (remote filesystem snapshot utility) 。在架構上，可以用來備份本機或遠端的檔案系統，它在本機端是藉由rsync進行檔案複製，或透過ssh建立安全的rsync遠端shell與遠端主機進行檔案傳輸，或直接與遠端主機的rsync伺服器連線。它是用「拉」的方式進行同步備份，也就是說，安裝rsnapshot的主機就是發動備份的主機，也是儲存備份資料的主機。rsnapshot透過排程 (crontab) 週期地啟動同步備份，而所有需要備份檔案的遠端主機都安裝rsync或啟動rsync伺服器來等待週期的同步備份。當同步備份發生時，rsnapshot根據設定將遠端主機需要備份的目錄「拉回」到本機特定的目錄架構裡。而這個目錄架構就是模擬高階儲存設備所提供的「快照備份」 (snapshot) 的目錄結構。依照不同的備份週期產生不同時間間隔的目錄，而在每個目錄下的檔案都是備份當時的全備份。透過檔案的「硬式連結」，在每次同步備份時，未曾更動的檔案直接使用之前備份的版本進行硬式連結到最新的備份目錄下，也因此整體備份空間的需求就相當是一次全備份與異動檔案的不同版本所佔用的空間。 


在配置上，需要設定rsnapshot.conf這個檔案，和建立週期備份的排程 (crontab) 。 


設定rsnapshot.conf非常簡單，使用預設的設定檔rsnapshot.conf.default直接拿來修改就可以了。在這個檔案裡面的每一個段落都有完整的說明可以參考。其中需要注意的地方是，由於rsnapshot可以在不同平台上運作，為了實做「硬式連結」來節省相同檔案的使用空間，所以必須根據所在的平台選擇最適當的外部工具。如果使用的rsync版本支援--link-dest的功能選項，則可以直接設定link_dest為1代表支援。如果不支援則就會使用GNU cp的-al的複製方式來建立硬式連結，因此可以指定GNU cp的所在路徑。但如果作業環境裡沒有GNU cp工具而無法指定，則程式內部會額外模擬這個動作。 


另外要注意的就是備份時間間隔的表示法，這是與建立週期備份排程密切相關的設定。根據需要來決定多久備份一次，換句話說就是單位時間可以保留幾次備份。如果每四小時備份一次，意味著一天可以保留六次每四小時的備份；如果每天備份一次，代表著一週可以保留七次每天的備份。 


在rsnapshot.conf.default裡關於備份時間間隔的預設值如下： 


interval        hourly  6
interval        daily   7
interval        weekly  4
#interval       monthly 3


在系統設定相對應的crontab： 


0 */4 * * *         /usr/bin/rsnapshot hourly
50 23 * * *         /usr/bin/rsnapshot daily
40 23 * * 6         /usr/bin/rsnapshot weekly
#30 23 1 * *        /usr/bin/rsnapshot monthly


如果根據預設值配合相對應的排程，那麼每四小時就會進行一次週期名稱為hourly的備份，它會在snapshot_root所定義的路徑下產生hourly.0到hourly.5的六個目錄，目錄裡面就存放著備份的內容。hourly.0是最新的備份，每四小時啟動備份時，最舊的備份hourly.5會先被刪除，然後依序將4,3,2,1的目錄尾數更名為5,4,3,2，再依照硬式連結產生的方式，如果是使用cp -al的模式，則將hourly.0複製出hourly.1後，直接用rsync基本同步的方式備份到hourly.0，如果是使用rsync --link-dest的模式，則在hourly.0更名為hourly.1後，rsync指定hourly.1為link dest然後備份到hourly.0。 


其他不是排在最前面的週期名稱不需要實際使用rsync進行備份，因為可以直接保留前一個週期名稱的最舊的那個備份。譬如，週期名稱為daily的排程在每晚23:50進行，因為設定保留七份，所以最舊的一份也就是daily.6在備份開始的時候先被刪除，然後依序將5,4,3,2,1,0的目錄尾數更名為6,5,4,3,2,1，最後再把hourly.5更名為daily.0就完成了備份。所以排程上刻意比hourly提前十分鐘，搶在hourly.5被刪除之前先更名為daily.0。而同樣的，weekly.0也是從daily.6更名得來。 


如果使用預設值進行hourly,daily,weekly的備份排程，那麼總共可以保有17份的備份。使用rsnapshot du的命令來可以觀察集中在snapshot_root的這些備份空間使用的情形。 


# rsnapshot du
15G     /backup/.snapshots/hourly.0/
16M     /backup/.snapshots/hourly.1/
21M     /backup/.snapshots/hourly.2/
23M     /backup/.snapshots/hourly.3/
19M     /backup/.snapshots/hourly.4/
19M     /backup/.snapshots/hourly.5/
22M     /backup/.snapshots/daily.0/
38M     /backup/.snapshots/daily.1/
31M     /backup/.snapshots/daily.2/
28M     /backup/.snapshots/daily.3/
53M     /backup/.snapshots/daily.4/
30M     /backup/.snapshots/daily.5/
38M     /backup/.snapshots/daily.6/
50M     /backup/.snapshots/weekly.0/
50M     /backup/.snapshots/weekly.1/
42M     /backup/.snapshots/weekly.2/
38M     /backup/.snapshots/weekly.3/
16G     total


這裡顯示的是一個真實環境一個月下來保留17份備份所需要的空間。一次全備份大約需要容量15G，如果使用傳統備份方式保留相同數量的備份需要大約255G。而rsnapshot實做硬式連結增量備份全部17份備份只用到大約16G的容量。而且每個週期名稱目錄下的所有檔案就是備份當時的備份內容，所以要找回某一次備份取得所有檔案在時間上大約的一致性變得非常容易，因為這非常接近使用檔案系統或儲存設備所提供快照備份的功能，差別只是rsync執行一回合從頭到尾畢竟還是會有「時間差」，開始備份到結束的時間點會有段距離，相對於真正的快照備份技術等於是「慢速快門」，所以這樣的作法適合用來備份一般的檔案，卻不適合用來備份檔案之間時間相依性非常高而且不斷在變動的資料庫或其他環境。 


結語
其實真正的「重複資料刪除技術」並不是像前述這樣的應用，主要是配合在一個既有的備份環境，譬如是一個D2D或D2D2T的架構當中做為備份軟體暫時緩衝用的磁碟空間 (staging disk) 所使用的技術。透過儲存設備可以識別出重複出現的不定長度資料區塊而選擇不儲存的演算法，讓備份的image file在累積多次備份之後可以維持很高的「壓縮率」。又由於多次備份的image file都是儲存在磁碟上，所以還原的速度會比磁帶還來得快速。而rsync使用硬式連結減少重複檔案所需要的儲存空間，也可以找到特定時間版本備份的檔案直接取回使用，在儲存原理上與重複資料刪除技術非常類似，在操作上與高階儲存設備提供的快照備份技術的應用方式非常接近。而為了解決rsync「慢速快門」的問題，其實如果能夠在來源端的檔案系統使用真正的快照備份技術，讓rsync直接備份快照版本的檔案來取得時間點上的一致性，這樣不僅僅可以備份一般檔案，還可以備份不斷在變動的信件檔或資料庫一直在開啟中的資料檔，進而擴大使用rsync的應用範圍。 

 (作者現任職於麟瑞科技) 


參考資料
http://www.mikerubel.org/computers/rsync_snapshots/ Easy Automated Snapshot-Style Backups with Linux and Rsync 

According to JEDEC v5.01 spec (6.6.5), In order to switch to HS400 mode,

https://lkml.org/lkml/2014/10/21/892

幾個工作上常用的指令 Ubuntu/Linux/Android

hwclock  顯示/修改RTC時間
hwclock -r  顯示RTC時間
hwclock -w  用系統時間寫進RTC
hwclock -s  用RTC時間寫進系統
hwclock -a  估算校正RTC. 參考/etc/adjtime
hwclock --set --date="2015-12-11 16:50:05"


FSCK
http://wiki.debian.org.hk/w/Configure_regular_filesystem_check#.E6.AA.A2.E6.9F.A5.E9.96.93.E8.B7.9D_.28Check_interval.29

tune2fs -T 20150101 /dev/sda5
硬把/dev/sda5的Last Checked時間改成20150101

tune2fs -l /dev/sda5
顯示fsck相關資訊

fsck -b 32768 /dev/sda5
執行fsck. 32768是針對blocksize=4k的fs. 1k時請用8193. 2k時請用16384.

blockdev --getbsz /dev/sda5
檢查這裡的blocksize是多少.

hwclock --set --date="2011-08-14 16:45:05"

hwclock --set --date="2011-08-14 16:45:05"

git 列出每個commit的hash跟標題

git log --pretty=oneline #會顯示所有log的第一行hash與註解，在查commit的hash時很方便

Ubuntu ALSA control

amixer controls   ## 列出可控制的項目，得到numid

amixer cget numid=XX  ## 取得[XX]項目現值

amixer cset numid=XX  ??  ## 設定[XX]項目值為??

alsa 暫存設定在  /var/lib/alsa/asound.state

參考 http://bbs.chinaunix.net/thread-1929520-1-1.html
參考 http://askubuntu.com/questions/50067/howto-save-alsamixer-settings

ALSA PCM RW MMAP

http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html

PCM formats

The full list of formats present the snd_pcm_format_t type. The 24-bit linear samples use 32-bit physical space, but the sample is stored in the lower three bytes. Some hardware does not support processing of full range, thus you may get the significant bits for linear samples via snd_pcm_hw_params_get_sbits() function. The example: ICE1712 chips support 32-bit sample processing, but low byte is ignored (playback) or zero (capture). The function snd_pcm_hw_params_get_sbits() returns 24 in this case.

ALSA transfers

There are two methods to transfer samples in application. The first method is the standard read / write one. The second method, uses the direct audio buffer to communicate with the device while ALSA library manages this space itself. You can find examples of all communication schemes for playback in Sine-wave generator example. To complete the list, we should note that snd_pcm_wait() function contains embedded poll waiting implementation.

Read / Write transfer

There are two versions of read / write routines. The first expects the interleaved samples at input (SND_PCM_ACCESS_RW_INTERLEAVED access method), and the second one expects non-interleaved (samples in separated buffers - SND_PCM_ACCESS_RW_NONINTERLEAVED access method) at input. There are these functions for interleaved transfers:snd_pcm_writei() snd_pcm_readi(). For non-interleaved transfers, there are these functions: snd_pcm_writen() and snd_pcm_readn().

Direct Read / Write transfer (via mmap'ed areas)

Three kinds of organization of ring buffer memory areas exist in ALSA API. Access SND_PCM_ACCESS_MMAP_INTERLEAVED has interleaved samples. AccessSND_PCM_ACCESS_MMAP_NONINTERLEAVED expects continous sample areas for one channel. Access SND_PCM_ACCESS_MMAP_COMPLEX does not fit to interleaved and non-interleaved ring buffer organization.

There are two functions for this kind of transfer. Application can get an access to memory areas via snd_pcm_mmap_begin() function. This function returns the areas (single area is equal to a channel) containing the direct pointers to memory and sample position description in snd_pcm_channel_area_t structure. After application transfers the data in the memory areas, then it must be acknowledged the end of transfer via snd_pcm_mmap_commit() function to allow the ALSA library update the pointers to ring buffer. This kind of communication is also called "zero-copy", because the device does not require to copy the samples from application to another place in system memory.

If you like to use the compatibility functions in mmap mode, there are read / write routines equaling to standard read / write transfers. Using these functions discards the benefits of direct access to memory region. See the snd_pcm_mmap_readi(), snd_pcm_writei(), snd_pcm_readn() and snd_pcm_writen() functions.

i2c分解動作

http://www.robot-electronics.co.uk/images/i2c.GIF
http://chiachun-ariel.blogspot.tw/2007/08/i2c.html

原則: bus出現以下兩種狀況時表示變成busy或是不再busy
起始傳輸: SCL為高時，SDA由高被拉低
傳輸結束: SCL為高時，SDA由低被放高

平常:
SCL, SDA為high

傳輸過程中:
只有當SCL為低時，才能為了傳輸下一個位元資料而改變SDA

分解動作開始:
送出端把SDA拉低
經過一小段時間後，接著把SCL拉低

SCL為低時，送出端按照要送出的資料bit而調整SDA電位，調好後把SCL放高
>>接收端看到SCL變高了就讀取SDA狀態抄下來

每傳完八位元，
送出端釋出SDA控制權給接收端(作法就是不拉低SDA)一個時脈周期的時間，這時間內接收端可以把SDA拉低，表示ACK bit, 資料都成功收到了。

如果此時接收端想花點時間處理收到的資料，希望傳送端暫時別送資料過來的話，就把SCL持續拉低，直到已經準備好接收資料時才放高SCL

若已把所有資料傳出，就在SCL為高時，把SDA由低放高，釋放bus使用權出來

廉航班機時刻表

先只整理台北/高雄 飛 大阪的
有空有閒再來整理其他地方, maybe日本國內線飛北海道的?!

https://docs.google.com/spreadsheets/d/1PB7XUxaCe8p98qOs92Pje1x73alAmtT6M5blVGS84lI/edit?usp=sharing

MII , GMII , RGMII

http://aca.cust.edu.tw/pub/journal/38/38-09.pdf
https://en.wikipedia.org/wiki/Media-independent_interface

The media-independent interface (MII) was originally defined as a standard interface used to connect a Fast Ethernet (i.e., 100 Mbit/s) media access control (MAC) block to a PHY chip. The MII design has been extended to support reduced signals and increased speeds.

基本上，這三個的作用是一樣的，同樣都是連結MAC層和PHY層的介面。區別在於編碼、速度、使用的腳位數、I/O clock的頻率不同。

USB OTG

http://anemospring.blogspot.tw/2010/12/usb-otg.html

1. 概要

OTG設備使用插頭中的ID引腳來區分A/B Device，

ID接地被稱作為A-Device,為連接時候的USB Host，A-Device始終為總線提供電力，

ID懸空被稱作為B-Device,為連接時候的USB Device，

設備的USB Host/USB Device角色可以通過HNP切換。

這裡要注意A-Device/B-Device與USB Host/Device不是一回事沒有必然的綁定關係A-Device就一定要是Host，

A-Device只是連接時的Host可以通過HNP切換，切換完畢A- Device變成USB Device但是仍然為總線提供電力。

很多  點進去看

[Linux] iobase membase mepbase

http://blog.csdn.net/kickxxx/article/details/6091265

iobase 是IO端口基地址，使用in/out[bwl] 来访问

membase是IO端口的内存地址（映射过的逻辑地址），使用read/write[bwl]访问

mapbase描述的是IO端口的物理地址，是硬件定义好的，可以通过ioremap获得对应的逻辑地址

[盜文] DEVICE_ATTR() 与 sysfs接口

http://blog.csdn.net/luobin1984/article/details/8118835

最近在弄Sensor驱动，看过一个某厂家的成品驱动，里面实现的全都是sysfs接口，hal层利用sysfs生成的接口，对Sensor进行操作。

说道sysfs接口，就不得不提到函数宏 DEVICE_ATTR

原型是#define DEVICE_ATTR(_name, _mode, _show, _store)\

struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)

函数宏DEVICE_ATTR内封装的是__ATTR(_name,_mode,_show,_stroe)方法，_show表示的是读方法，_stroe表示的是写方法。

如果你完成了DEVICE_ATTR函数宏的填充，下面就需要创建接口了

例如：

   static DEVICE_ATTR(polling, S_IRUGO | S_IWUSR, show_polling, set_polling);
    static struct attribute *dev_attrs[] = {
            &dev_attr_polling.attr,
            NULL,
    };

[Android] PFUZE0100 提供I2C介面控制

dump controller register
cat /sys/bus/i2c/devices/X-0008/pfuze_ctl
或
cat /sys/devices/platform/imx-i2c.X/i2c-X/X-0008/pfuze-ctl


各regulator資訊或控制，去這裡找
 /sys/bus/i2c/devices/X-0008/pfuze100-regulator/regulator/regulator.XX/
或
/sys/devices/platform/imx-i2c.X/i2c-X/X-0008/pfuze100-regulator/regulator/regulator.XX/

紅字依你設定
0008是pfuze100的i2c address

好表...XDDDD

http://elinux.org/Tegra/Downstream_SW/Linux4Tegra/WebBrowsers/Hardware_Accelerated_Video_Decoding

Motivation

• Video Acceleration is disabled by default in Linux Builds of Chromium.^[1]
• Nvidia provides Gstreamer libraries for the Tegra K1 ^[2]
• Chromium doesn't support Gstreamer backend for media ^[3]
• Chromium supports VA-API and VDPAU libraries through the Hardware acceleration implementation called VAVDA. ^[4]
• Nvidia doesn't provide VDPAU libraries for the Tegra K1.^[5]
• Notwithstanding all the above points, Acer 13 and HP 14 Chromebooks that shipped with the same SoC supported hardware accelerated video decoding.

Jetson TK1 檢查版本

head -1  /etc/nv_tegra_release

過渡性問題 Jetson TK1 R21.3 CUDA library loading

http://blog.csdn.net/kaka20080622/article/details/40706813

error while loading shared libraries: libcudart.so.6.5: cannot open shared object file: No such file

sudo cp /usr/local/cuda-6.5/lib64/libcudart.so.6.5 /usr/local/lib/libcudart.so.6.5 && sudo ldconfig

sudo cp /usr/local/cuda-6.5/lib64/libcublas.so.6.5 /usr/local/lib/libcublas.so.6.5 && sudo ldconfig

sudo cp /usr/local/cuda-6.5/lib64/libcurand.so.6.5 /usr/local/lib/libcurand.so.6.5 && sudo ldconfig

總之如果看起來是安裝後路徑不對，沒複製好，就copy過去吧

Jetson TK1 playback h.264 hardware decode

https://devtalk.nvidia.com/default/topic/780917/jetson-tk1-mp4-video-playback-quality-from-canon-camera-recorded-videos/?offset=3

Video only:

gst-launch-0.10 filesrc location="$1" ! qtdemux name=demux demux.video_00 ! queue ! nv_omx_h264dec ! nv_omx_hdmi_videosink

Video and Audio:
gst-launch filesrc location="$1" ! qtdemux name=demux demux.video_00 ! queue ! nv_omx_h264dec ! nv_omx_hdmi_videosink demux.audio_00 ! queue ! nv_omx_aacdec ! alsasink

NVIDIA Jetson TK1 Development Guide

一塊實驗版名叫Jetson，內含Tegra K1處理器，CUDA運算能力
有32-bit與64-bit版本之分，後者使用ARMv8架構晶片

原價屋買的到

簡易版NVIDIA L4T Quick Start
http://developer.download.nvidia.com/embedded/L4T/r21_Release_v3.0/l4t_quick_start_guide.txt

Jetson TK1 Development Kit Quick Start
http://developer.download.nvidia.com/embedded/jetson/TK1/docs/2_GetStart/Jeston_TK1_QuickStartGuide.pdf

以下為官方StartGuide章節筆記(2014年末版本)

開箱使用

插電，按Power鈕，看到綠色LED燈
登入用的帳號密碼：
Username: ubuntu
Password: ubuntu

安裝NVIDIA Linux driver binary

cd ${HOME}/NVIDIA-INSTALLER
sudo ./installer.sh
Reboot system

Re-Flash your Jetson

準備好可用的rootfs
Tegra_Linux_Sample-Root-Filesystem_Rxx.x.x_armhf.tbz2
下載新的L4T Drivers
Tegra124_Linux_Rxx.x.x_armhf.tbz2

解開後
cd Linux_for_Tegra/rootfs/
sudo tar xpf ../../[你的rootfs.tbz2]
cd ..
sudo ./apply_binaries.sh
最後看到Success!

進入Reset Recovery Mode
按住RECOVERY鈕不放，按一下RESET鈕

用USB線連接host主機跟Jetson

sudo ./flash.sh -S 8GiB ${target_board} mmcblk0p1
${target_board}, 尋找目錄下$(target_board}.conf, 官方檔案取名為 jetson-tk1

JetPack TK1 (Jetson TK1 Development Pack)
載點 https://developer.nvidia.com/jetson-tk1-development-pack-archive
http://docs.nvidia.com/jetpack-tk1/index.html#developertools/mobile/jetpack_install.htm
執行 XXX.run
照指示設定平台，並燒入Jetson

[盜轉文]Linux platform总线(1)：总体框架

原文 http://blog.chinaunix.net/uid-7859076-id-2552433.html

轉文整理格式 http://blog.csdn.net/qq_695538007/article/details/38092099

1. int platform_device_add_resources(struct platform_device *pdev,struct resource *res, unsigned int num)  
2. {  
3.        struct resource *r;  
4.        r = kmalloc(sizeof(struct resource) * num, GFP_KERNEL);//为资源分配内存空间  
5.        if (r) {  
6.               memcpy(r, res, sizeof(struct resource) * num);  
7.               pdev->resource = r;        //并拷贝参数res中的内容，链接到device并设置其num_resources  
8.               pdev-> num_resources = num;  
9.        }  
10.        return r ? 0 : -ENOMEM;  
11. }