改进 RISC-V 平台 UART 及中断处理

[AsakuraMizu]

目前在 RISC-V 架构的多个平台的测试中发现一些与 UART 中断相关问题，先列举如下：

• QEMU：LOG=trace 或 LTO=y 时无法工作
  • LOG=trace 时表现为中断风暴，初步确认是处理中断不及时导致的，可能需要做一个缓冲区
  • LTO=y 时表现为不触发外部中断，目前还不知道原因
• VisionFive 2：目前还完全无法使用 UART 中断，初步调研表明问题与 QEMU 平台上 LOG=trace 的问题相似，但是仍存在其他问题：
  • 在完全使用 uart_16500 提供的 init 函数时，每次从 IIR 中读到的标识为 0xcc，读取缓冲区后仍然会触发中断，且 IIR 中读到一个很奇怪的值 0xc7，按照 UART 规范，最低位为 0b1 应该表示没有发生中断才对
  • 对 init 过程进行魔改，删除大部分寄存器初始化而只初始化中断，则行为正常，只在数据到来时触发中断且 IIR 读出来是 0xc4

关于中断处理时机问题：在 #49 之前，我们把 waker 的唤醒直接插入到了axplat 调用的中断处理程序中，而这个 PR 之后，我把它挪到了 axplat 处理完毕之后。理论上不应该影响处理的及时性，因为在处理期间 irq 都处于关闭状态才对，所以任务应该还是正常唤醒了，多了一个 log 后导致调度到 tty-reader 任务的延时变长了？目前想到的可能的解决方案就是在 uart 上接一个缓冲区。

关于初始化：在物理设备上 OS 启动时 u-boot、sbi 等应该已经把 uart 早都初始化好了，我们最多开个中断就够了，其他的fifo什么的确实都可以删掉（也说明 u-boot 在这个板子上也没启用 fifo）

关于后续改进：crates-io 上有一万个 uart。。。我们现在用的是下载量最多的 uart_16550，之前用过 ns16550a 但是它不开中断所以换了，最近调研这个问题的过程中也参考过 some-serial，但是这个依赖树直接吓哭了

---

还没弄清楚更多细节，先留一个 discussion 了，之后再开 issue