引言与大纲

这系列文章，将会带过数个跨度极大的主题，故有需要先於开篇的引文来作展开。

首先，我们由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。