這系列文章，將會帶過數個跨度極大的主題，故有需要先於開篇的引文來作展開。

首先，我們由RISC-V是什麼來開始說明。
在現代電腦系統中，軟硬體的交界我們通常會以指令集架構來作天然的區隔；例如大家耳熟能詳的x86、ARM、MIPS，就是這樣的存在。

然而RISC-V有幾項（以我作為一個CS背景的人來說）特點導致它與過往的指令集不同：

1. RISC-V 切成 Unprivileged ISA 與 Privileged ISA，並且希望排除platform影響。
2. 刻意對cache的描述淡化。
3. 官方指令集架構沒有授權金與專利屏蔽。

第一點點出的事情是，RISC-V的系統狀態與邏輯指令是分離的，例如系統狀態控制暫存器（CSR）這個概念，僅有在實做Privilged ISA的平台才會存在。〝platform〞這個概念很模糊，但大致上可以理解成「出於實做意義上會出現，但非指令集架構該定義的事情」。所有今天platform相依的housekeeping邏輯，理論上都要能夠透過一層叫做〝Supervisor Binary Interface〞的抽象層來操作。

第二點是與第一點有關的特點，在RISC-V創始者(Andrew Waterman、David Peterson、Krste Asanović）的理念裡，cache是platform的東西，不該存在於不管是Privileged 或 Unprivileged的ISA規格之中。這點也直接導致了後續無數的討論與紛爭。

第三點則是RISC-V目前在市場上最大的賣點，因為有了公用的指令集基礎，IC/IP公司可以專心做出符合spec的處理器，便能（理論上）共享由（倒楣鬼）先驅者投資的軟體開發動能。如果有熟悉ARM生態系的朋友，可以想像成一個沒有Linaro、但有Linaro效果的世界。

於是說到這裡我便需要扣題一下〝Port Alpine Linux to open source RISC-V platform〞 — — 我們有了一個公定的ISA規格，自然也就會有開放原始碼的硬體實做。但是它在一些platform上的實做細節，不同於像x86、ARM那樣有一個穩定的參考實做，導致Linux Distro的運作，是需要花開發動能去補完抽象層的。

在這系列中，我們挑選的RISC-V 32平台為 LiteX/VexRiscv 這樣一個RV32 SoC；它的名稱代表了兩個事物，前者LiteX是SoC platform、後者VexRiscv是ISA的實做(CPU Core）。

VexRiscv在2020年後，已經完整實做完成了RV32GC的指令集，所以目前可以近乎無痛使用RISC-V既有的工具鏈(早年筆者作移植時，因為VexRiscv沒有完整實做A/C擴展時、尚須使用特製的toolchain)； 但是LiteX這個platform本身，就有耐人尋味的事情了，例如，它的中斷控制器，並非是目前台面上的參考實做PLIC與CLINT組合，所以這邊Linux就需要有driver的porting需要、另外則是SBI的firmware，這點本身就是平台方需要去補足的。

接下來，要讓Alpine Linux這樣一個Linux distro跑在這樣的平台上，我們有了一個會動的kernel還不夠，我們需要一個迴異於多數Linux distro使用的glibc的C library runtime — — musl-libc支援。目前musl-libc上游僅有RISC-V 64平台的支援，RISC-V 32的僅有早年試驗性質的porting。然而沒有RV32 musl-libc porting、也就沒有Alpine Linux可以運作於LiteX/VexRiscv的可能性。而且有了RV32 musl的support後，因為目前Alpine沒有正式支援RISC-V，我們必須要從abuild/aports這樣的原始碼建置系統開始，package by package的建置出alpine-base這樣一個套件基底。

所以這系列文章，將會在數個主題間跳動：如何建置出一個LiteX/VexRiscv這樣的平台到FPGA開發板上、Linux核心porting到這樣一個平台有什麼困難處、RV32 musl-libc的porting與測試、以及Alpine Linux的initial bootstrapping。