Note:WSL2 with Bitbake and VHDX

目前Yocto 用的 bitbake 已經會辨識是否在WSL2 執行
第一次執行的話會出下面 警告訊息
“WARNING: You are running bitbake under WSLv2, this works properly but you should optimize your VHDX file eventually to avoid running out of storage space"

提示要做VHDX 的最佳化, 其實就是當不使用WSL2的時候去 透過 diskpart 做shirnk (compact commad)
檔案會在

C:\Users\<user name>\AppData\Local\Packages\<distor image>\LocalState
像我目前電腦上

C:\Users\kunic\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState\ext4.vhdx

要先用 wsl.exe –list –verbose 去看目前 wsl 是否執行中
然後用 wsl.exe –terminate <running wsl>

然後用 diskpart
diskpart > select vdisk file=C:\Users\kunic\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState\ext4.vhdx
diskpart > compact vdisk

Note: VS Code with Yocto Project in WSL2

本來是意外, 想看看 WSL2 可以幹嘛, 昨天有成功把之前 Beaglebone with Yocto 的東西做出來
今天發現 WindRiver 有一個詳細用VS Code with Yocto Project 的入門介紹
可以直接在VSCode 開 WSL2 (前提是你的WSL2先設定好)

影片中介紹裝 下面3各 extension, 我是覺得奇怪因為沒裝的時候我就可以開 remote wsl2
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack
https://marketplace.visualstudio.com/items?itemName=EugenWiens.bitbake
https://marketplace.visualstudio.com/items?itemName=ms-python.python

ref.

Note:Ubuntu/Debian armhf/arm64 cross compiler toolchain

Debian/Ubuntu 這幾年已經內建cross compiler toolchain package 下面是我個人常用的
主要是根據 build kernel 所需要的基本軟體包

for armhf

apt install crossbuild-essential-armhf libc6-dev-armhf-cross binutils-arm-linux-gnueabihf build-essential libncurses5-dev flex bison bc libssl-dev

for arm64/aarch64

apt install crossbuild-essential-arm64 libc6-dev-arm64-cross binutils-aarch64-linux-gnu build-essential libncurses5-dev flex bison bc libssl-dev

for arm cortex R/M

apt install gcc-arm-none-eabi

然後用ccache 的話, 可以把 /usr/lib/ccache 加進 PATH
透過 ls -al /usr/lib/ccache 可以觀察到 下面狀況

total 8
drwxr-xr-x 2 root root 4096 Jan 7 17:10 .
drwxr-xr-x 81 root root 4096 Jan 7 17:10 ..
lrwxrwxrwx 1 root root 16 Jan 7 17:10 aarch64-linux-gnu-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:10 aarch64-linux-gnu-g++-9 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:10 aarch64-linux-gnu-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:10 aarch64-linux-gnu-gcc-9 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 arm-linux-gnueabihf-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 arm-linux-gnueabihf-g++-9 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 arm-linux-gnueabihf-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 arm-linux-gnueabihf-gcc-9 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 c++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 c89-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 c99-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 cc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 g++-9 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 gcc-9 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 x86_64-linux-gnu-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 x86_64-linux-gnu-g++-9 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 x86_64-linux-gnu-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 Jan 7 17:04 x86_64-linux-gnu-gcc-9 -> ../../bin/ccache

Note: RS485 China components from RakWiress

手上有個案子需要用到 Modbus 之前買了一些 轉版問題很多受不了 需要自己重新弄一塊板子
很久沒做RS485 電路了, 查了一下對岸目前IC國產化的腳步出了幾個公司在做這個沒注意是不是抄大廠的 但是價錢是有競爭力的

  • RS485 Transceiver – TP8485E — 3PEAK
  • ESD protection device – LRC399-04AT1G — LRC

下面的電路圖來自 Rakwireless RAK5802



2020 做了一個LoRaWAN 的案子 發現對岸的資源真的比現在台灣豐富很多也比較開放 並且對岸已經有幾家公司都是朝國際化客戶服務的方向擴展 都有自己的國外開發與服務的團隊與community
HelTecAutomation/Rakwireless 都是在LoRa 投注很多資源並產出許多產品的公司

與它們接觸的過程可以感受到那種新興發展的氣息 
不過相對來說 目前的品質穩定度也有待加強 HeltecAutomation 我買了不少 Node 的硬體(over 70pcs)他們出廠可以確定有測試過TX/RX 但是我實際的使用上大概還有8%的不良率, 礙於兩岸退貨機制的複雜與麻煩就只能多採購一些來當作備品
當然除此之外也詢問過ebyte/rejeee 礙於本身量太小與他們本身沒有那樣針對海外市場的發展方向就只能暫時
目前大概普遍接觸的訂製量1000pcs 左右, 低於1000pcs 都還是要自己想辦法處理
礙於疫情真是一件麻煩的事情, 不然直接過去深圳 當場找人談可能會快一點

現在Rakwireless 出了RAK4270 比較像我當初想要找的東西, 加上他上面那個RS485/Modbus 可以快速做出一些LoRaWAN 的 IoT 應用展示
https://store.rakwireless.com/collections/wisduo/products/rak4270-lpwan-module

Note: Network Device Role

最近有些案子開始進入網通範疇, 使用上必須清楚各種設備的角色跟設定方式, 以前都是LAN或是頂多一個 現成的4G Router 就解決, 現在遇到大公司內部私有網路的設定搞得昏頭轉向的

Hub(Switch Hub) : 一般常見設備, 常見 5port/8 port , 工作在Layer 1 (Physical/PHY) 將某一個port 收到的封包往其他port 發送出去

Switch: 他跟Hub不同之處,在於它會分析/學習封包內部接收的address 該往那個port 丟,所以他必定在Layer 2(DataLink/MAC), 也有更高貴的L3 (Network/IP) Switch, Switch 主要用在組VLAN(Virtual LAN) 透過設定將不同的Port 如同接在Hub上, .透過Switch/VLAN 等設計可以讓網路頻寬不會因為 廣播風暴與CSMA/CD 問題造成頻寬受限

Router: 工作在 L3 (Network/IP) 主要用來處理網路層的封包需要跨網段/網域的問題, Router 可以具有不同的 WAN 網路

Bridge: 主要是將兩個不同的網路透過他連通, 收到封包後會分析L2內容跟網段設定判斷是否要轉發到另一個網路,但是無法避免廣播風暴, 多port 的就後來演變為Switch, 不過在OS 上面軟體設定多port 還是稱為Bridge, Bridge 通常是軟體而Switch 通常用ASIC 硬體的方法處理封包

Note: Debian 10, some CA Certificate not workable?

昨天遇到客訴問題, 一開始說是否設備上的Debian 不支援 curl, 但是我自己本身開發測試是有使用過的先驗證一遍,工作正常。然後請客戶提供相關的 error message 結果發現是

curl: (60) ssl certificate problem: unable to get local issuer certificate

然後就開始了研究之路, 這個客戶遇到的問題是透過 apt install nodejs npm 後, 透過npm 去安裝其他套件會出現nodejs.org 的憑證無法驗證成功

可以採用openssl 去驗證實際錯誤的原因,可以看到實際是最上面的 USERTrust RSA Certification Authority 驗證出問題

$ openssl s_client -showcerts -connect nodejs.org:443
CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.nodejs.org
verify return:1

確認一下 /etc/ssl/certs/USERTrust_RSA_Certification_Authority.pem 會發現不一致
透過下面命令可以抓到CA 的URI

$openssl s_client -showcerts -connect nodejs.org:443 \
2>/dev/null | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ \
| openssl x509 -noout -text | grep “CA Issuers" | head -1

>> CA Issuers – URI:http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt

然後這時就需要手動加入這張CA了

ref. https://stackoverflow.com/questions/21181231/server-certificate-verification-failed-cafile-etc-ssl-certs-ca-certificates-c

Note: LoRa node deploy on Chirpstack v3.x

之前在某個LoRaWAN 專案使用 下面的程式碼來自動產生對應的 key , 但是當需要做裝置管理與重新安裝需要從一個檔案或是資料庫讀出對應的資訊才是必須的功能,
https://gist.github.com/KunYi/25dd273951552831b6237572d75d5736#file-deploynode_xlsx-go

下面是之前用來自動產生對應的 key, 然後在註冊成功後透過 log.println 產生一個對應的csv 檔案, 後面就可以透過上面的 git gist 去重新註冊在新的 chirpstack gateway 上面

appKey, _ := uuid.NewRandom()
genAppKey, _ := uuid.NewRandom()
nwkKey, _ := uuid.NewRandom()
strAppKey := strings.Replace(appKey.String(), "-", "", -1)
strGenAppKey := strings.Replace(genAppKey.String(), "-", "", -1)
strNwkKey := strings.Replace(nwkKey.String(), "-", "", -1)

Note: initramfs-tools — mount

為了搞 overlayfs 去做rootfs 的擴展與factory reset 的功能, 開始研究起 initramfs 本身init 的 script 
他本身在 script 內埋了幾個 hook 點, 有 init-top, init-premount, init-bottom, local-top, local-premount, local-bottom

因此參考一些網路上 readonly rootfs 透過 ramdisk 做得 script 開始了 我的嘗試

有幾個要注意的點

  • 如果 overlayfs 是採取 module driver  型式, 在 /etc/initramfs-tools/modules 要加進去 overlay 這樣 update/rebuild initramfs 才會將 overlay module 包進去
  • 然後在 hook點, (一般選擇 init-bottom, 這裡會將 rootfs 掛起來 掛在 $rootmnt 這個路徑(Debian 是 /root)要 modprobe overlay, 載入 overlayfs 的 module driver
  • upperdir and workdir 需要在同一個filesystem 上面
  • 最有問題的是mount 這個在initramfs(debian) 本身是busybox 所以使用上要特別注意一下他對參數有一些處理順序的問題, 經過測試 要透過下面順序才行
    mount -t overlay -o lowerdir=${OVER_LOWER},upperdir=${OVER_UPPER},workdir=${OVER_WORK} overlay ${rootmnt}

ref.

深入理解overlayfs(一):初识

深入理解overlayfs(二):使用与原理分析