Note: Vendor ACPI Driver on Windows

之前寫了一些 ACPI Driver 相關的紀錄, 最近看到USB Type C connector for Windows 10 如果不做PD State Machine,下面也需要ACPI Driver 去協調 MCU/EC 所以整理一下手上有的資料 順便重新整理一下網路上很多消失的檔案

ACPIDriver Vista — 這個是Microsoft 最早提供的文件,不過根據實際經驗應該Windows XP 就支援這些功能
ACPI in Vista — 這是早期 WinHEC 2006 的 Presatations
BIOS implement of UCSI — Intel 這是Intel 講如何實作USB Type C Connector System Interface

這邊提供實際原始碼的實作內容

Older WDM driver implement – 實作了Customer GPIO Button/Indicator LED, 應該是 Intel 用來Demo MID (Mobile Internal Device)做的
Current WDF Driver implement for UCSI - 這就是Microsoft 實作UCSI 的參考Driver了 可以搭配Intel 文件跟 Microsoft 網站資料一起看

下面是想更了解UCSI可以參考的資料
http://www.usb.org/developers/presentations/  — 2017 USB Developer Days  in Taipei

廣告

Note: Treble

從Android Oreo, Google 透過Treble 機制去解耦合HAL 跟Framework的相依性,希望借此機制去解決Android 碎片化跟安全性的問題。雖然目前還看不出有達成他想要的目的,但是真的有達成更進一步緊縮Android 裝置的控制權,不過最主要的原因實際是控制了GMS,跟Microsoft 藉由Office 控制桌面作業系統一個道理,是終端使用者離不開這些軟體與服務進而綁住供應商。
下圖是Android 的HAL 跟Framework的連結方式從1的傳統Legacy HAL 到2,3和4的Treble 實作方式,2 and 3的方法是為了提供舊的裝置單純升級到Android Oreo 提供的方法,如果裝置一開始就是Android Oreo 必須使用4 的方法

HIDL 是透過IPC 解藕合HAL與Framework 等於可以動態升級,不再是編譯時期繫結(Bind)。

而除了上述透過HIDL去分離界面外,再Kernel跟Disk Paratitions也做了規範,強制引入了/vendor or /odm paratitions 從/system or /boot 去分離HAL實作 而且也透過Kernel 4.4 and Later 去加入device tree overlays功能,讓廠商達成同一個 /boot and /system 去適應不同裝置的可能性

Note: golang with docker

Docker 這幾年對於各種運維很流行,實際上在開發各種嵌入式裝置與Android BSP維護上也會遇到很多相依性問題,這一兩年也看到越來越多公司開始採用 Docker 去維護開發環境了,尤其當你需要多地協同開發時,與第三方客戶或是夥伴開發更是如此,可以透過設定好的Dockerfile 去做開發環境的維護,降低各種溝通與反覆試誤的成本。

這裡舉一個 台灣工控一哥的例子 可以看到連結內有許多不同OS版本對應的不同開發環境,這樣你開發的環境不用去管理各種不同版本的套件相依性問題,對客戶跟第三方合作廠商都可以快速的發布,對於有多樣客戶是一個相對省力的支援方式

因為IoT Era 的到來,今天測試一下Docker 做Golang 開發

底下是一個 golang with git, gcc and make 的Dockerfile,用的是Alpine distribution, 要改成其他Distribution 也可以, 官方有Debian可選 , 可以直接用Docker pull golang:$tagname 之類的方式去拉下image
下面是我新增git & make & gcc 的開發用Dockerfile

FROM golang:1.10.1-alpine

RUN apk add --no-cache git make gcc

ENV GOPATH /go
ENV PATH $GOPATH/bin:/usr/local/go/bin:$PATH

RUN mkdir -p "$GOPATH/src" "$GOPATH/bin" && chmod -R 777 "$GOPATH"
WORKDIR $GOPATH

然後可以參考官方文件的Docker-compose 去結合其他service 像是資料庫PostgreSQL
這樣可以開發一些Microservice 來做一些應用,需要水平擴展時可以加上反向代理等等,做現在所謂雲端的開發

如果想放像DockerHub 讓大家都可以使用你的Dockerfile 也可以參考工控一哥的這篇

透過上面的Dockerfile 可以用docker build 變成image 我這裡用 docker tag 改成 mygolang
透過docker image ls 可以看到下面狀況

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
mygolang            latest              2da237294097        2 hours ago         475MB
golang              1.10.1-alpine       52d894fca6d4        5 days ago          376MB
postgres            9.6.8-alpine        b27674feae2a        6 weeks ago         38MB

然後建一個 docker-compose.yml 如下, golang 那區塊應該有點問題還需要更正

# Use postgres with golang
version: '3'

services:
    db:
        image: postgres:9.6.8-alpine
        restart: always
        ports:
            - "5432:5432"
        environment:
            POSTGRES_DB: dev
            POSTGRES_PASSWORD: IdQuivgebobr9Dra
            POSTGRES_USER: postgres
    go:
        image: mygolang:latest
        ports:
            - "8080:8080"
        working_dir: /go
        depends_on:
            - db
        links:
            - db

然後下 docker-compose up -d 這樣會出現

Starting mydocker_db_1 ... done
Creating mydocker_go_1 ... done

在接著用 docker-compose run go 重跑一次mygolang 這樣就可以開始開發相關service
透過 docker-compose ps 可以觀察到下面 container status

      Name                     Command              State            Ports         
-----------------------------------------------------------------------------------
mydocker_db_1       docker-entrypoint.sh postgres   Up       0.0.0.0:5432->5432/tcp
mydocker_go_1       /bin/sh                         Exit 0                         
mydocker_go_run_1   /bin/sh                         Up

Update: 這篇還沒整理完,參考 Where and how to persist application data 可以知道應該透過Volume/Bind 跟Host的目錄連結,這樣才能持續開發並且不增加container 需要在花一些時間整理
至於一些使用Docker 快速提示可以參考這個 docker cheatsheet

Note: Http request

之前看過某些同一個IP 上有多個不同網域Http 服務器且共用80 port,今天看了HTTP 的相關內容,應該是HTTP 的Request 裡面的Header 有一個Host 讓Web Server 可以知道現在到底對應那個Domain, 來回應不同網站內容,就如同可以透過User-Agent 識別是哪種瀏覽器字串,輸出不同的Layout 讓桌面跟行動裝置可以有更佳的操作方式或是支持不同瀏覽器的行為。

而RESTFUL API 目前針對不同的Request method有一些通用/標準化的使用方式定義,需注意的是,對HTTP 方法而言,則是透過Server 跟Client 實作間的約定,沒有強制性,也可以自定義方法

  • GET — 功能主要是跟Server 要資料,對應CRUD 的Read, 因其不改變Server狀態, 單純讀取而已,所以具有安全與冪等性
  • POST — 增加一筆資料到Server上,如果資料已經存在還是會新增一筆,對應CRUD的Create,會改變狀態,而起資料會重複增加,所以安全與冪等性都不存在
  • DELETE — 刪除一筆特定資料,對應CRUD的Delete, 不具安全性,因其改變狀態但是重複執行後,還是無法重複刪除資料,所以不具備安全但具備冪等性
  • PUT — 新增資料,是資料不存在就新增,存在則覆蓋,對應CRUD的Update(Replace),所以一樣是不具安全性但具備冪等性因為重複覆蓋不影響最後結果
  • PATCH — 更新資料,附加資料在已有資料後方,與PUT不同處主要是該資料必須已經是存在的,不具備冪等性與安全性,對應CRUD 的Update(Modify)
  • HEAD — 基本上跟GET差不多,主要是用來讀與Server 的狀態但是不讀取實質資料就只取前方的HEADER而已

HTTP/1.1 文件RFC 2616 的 Section 5 定義一個客戶端的Request 由下列元素組成

  • Request Line — 由Method/URI/HTTP Version + CRLF組成
  • Header — 任意的header區(可以為0) + CRLF
  • CRLF — 最少會有一行CRLF,換行看了提案人估計是Microsoft 的關係
  • Message Body – 大小不定可以為0

基本上設計Web Service 應該需要把HTTPS/1.1 先看過一遍吧,有概略認知後對後續系統設計與運作會比較有全面性認知,應該可以算是打基礎的關鍵定義,至於CoAP and HTTP/2之類的都是延伸增強概念,讓HTTP從本來的人類易讀的明文(PLAIN TEXT)協定,改成因為安全與效率考量的BINARY方式傳輸

Ref.

Note: RPMB Partition

RPMB 是從eMMC 4.4  開始引入的設計,全稱叫做Replay Protected Memory Block, 從名稱就知道是一個有特殊保護設計的區域,透過SHA-256 MAC (Message Authentication Code)SHA-256機制保護,也就是要寫入該區域時,Host 需要將要寫入的資料透過一個Key去做HMAC讓eMMC controller 去驗證是否為有效資料,目前常見使用環境下是設備生產時會寫入Key 到eMMC/UFS 內的OTP區域,然後將該Key也存放在TEE 區域內,透過TEE 去保護該Key 不會洩漏到裝置外部,達到保護該區域的資料安全可靠

他有幾個特徵它同BOOT Partition一樣是128KB 為最小單位,最大則為32MB,同Boot 一樣是透過CSD register 的值去設定大小, 一般出廠原生設定為32, 剛好是4MB

RPMB 一般用來存裝置內的各種生產時需要寫入的各種公鑰與裝置相關設定等等,如序號,因為讀取時不需要Key 所以可以讓一般應用讀取

ref.

 

 

 

Note: MyDriving/Azure

台灣近年某些產業很喜歡跟著潮流走,一堆公司目前花各種資源投入物聯網或是車用電子,如車聯網的應用(fleet telematics),Microsoft 當然不會錯過這種議題,早在2016為了展示他的Azure 就有出現一個 Azure Samples Demo – MyDriving 用來協助展示他的Azure功能,翻了一下,它可以讓新創快速參考打造一個展示系統,可以用來展示給終端客戶去吸引合作機會,不過就是很基礎的功能實作出來,如果要實際應用在現實場景還是需要不少資源去客製化,但是可以幫助想踏入這個領域的廠商快速有個概念與做業務展示去擷取眼球爭取曝光
Update: 後來讀了他的 Reference Guide , Microsoft 的PM 也很清楚的說這是起點,然後系統架構圖等等也很清楚簡單的畫出來,這好像是台灣競爭落差的感覺

不然如果從GIS等等搭建起可能需要付出數倍資源與時間

Note: HockeyApp SDK for Mobile/IoT devices

剛注意到 Azure 目前提供一個Free servcie, 叫做 HockeyApp 他是用來管理Mobile Device上面的App, 透過它OpenSource的SDK 去整合到自有的App裡面,然後使用Azure內的Service 去做本身App的管理, 主要有下圖的功能

Distribution(Update)/Crash Report/User Metrics 算是可以再這物連網時代,幫助中小型公司快速打造自有產品的好服務,可以節省很多時間與金錢去打造原型產品,而且支援常見的Android/iOS/Windows 平台