K210 无法进行 SD 卡读取

• 描述

  参考此 repo 实现的 SD 卡读写程序，在 sdcard_write_sector() 函数中出现 sdcard: invalid response token 错误。

• 错误信息

  sdcard: invalid response token

• 截图

  

• 复现

  clone https://gitlab.eduxiji.net/PTRNULL/simplekernel_oscomp_2021.git，按照 RUN.md 中的描述运行（K210）即可观察到。

• diff

  代码位于 https://gitlab.eduxiji.net/PTRNULL/simplekernel_oscomp_2021/-/blob/master/src/drv/sdcard/sdcard.c

  1. 修改了数据类型

     uint8 -> uint8_t

     uint16 -> uint16_t

     uint32 -> uint32_t

     uint64 -> uint64_t

  2. 注释了锁相关代码

     注释了 static struct sleeplock sdcard_lock 相关定义，以及依赖它的函数。

When I tried to run the kernel on qemu, as a result, I got this error message below.

qemu-system-riscv64: Some ROM regions are overlapping
These ROM regions might have been loaded by direct user request or by default.
They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.

The following two regions overlap (in the memory address space):
  ./bootloader/SBI/sbi-qemu ELF program header segment 0 (addresses 0x0000000080000000 - 0x00000000800193e8)
  fdt (addresses 0x0000000080000000 - 0x0000000080100000)
make: *** [Makefile:152: run] Error 1

It seems that there are some errors with the booting phase. Can you help me fix it? Thanks. Below are some of my compliling system informations.

..............                                     ********@kali 
            ..,;:ccc,.                             ------------- 
          ......''';lxO.                           OS: Kali GNU/Linux Rolling x86_64 
.....''''..........,:ld;                           Host: VMware Virtual Platform None 
           .';;;:::;,,.x,                          Kernel: 5.16.0-kali5-amd64 
      ..'''.            0Xxoc:,.  ...              Uptime: 6 mins 
  ....                ,ONkc;,;cokOdc',.            Packages: 2991 (dpkg) 
 .                   OMo           ':ddo.          Shell: zsh 5.8.1 
                    dMc               :OO;         Resolution: 1718x900 
                    0M.                 .:o.       DE: Xfce 4.16 
                    ;Wd                            WM: Xfwm4 
                     ;XO,                          WM Theme: Kali-Dark 
                       ,d0Odlc;,..                 Theme: Kali-Dark [GTK2/3] 
                           ..',;:cdOOd::,.         Icons: Flat-Remix-Blue-Dark [GTK2/3] 
                                    .:d;.':;.      Terminal: qterminal 
                                       'd,  .'     Terminal Font: FiraCode 10 
                                         ;l   ..   CPU: Intel i7-9750H (8) @ 2.592GHz 
                                          .o       GPU: 00:0f.0 VMware SVGA II Adapter 
                                            c      Memory: 649MiB / 11940MiB 
                                            .'
                                             .                             
                                                                           

qemu-riscv64 version 5.0.0
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2)
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

rustc 1.61.0-nightly (1bfe40d11 2022-03-18)

riscv64-unknown-elf-gcc (gca312387ab1) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

既然proc的kpagetable既有用户地址空间和内核地址空间，这样显得pagetable就多余了，在限制用户地址空间小于0x80000000的前提下，删除pagetable也能正常工作？这样每个进程的pagetable的0,1项对应用户地址空间的映射，后面的项对应内核空间的映射。只保留一个页表的话可以简化vm.c的代码？

启动失败，提示不是fat32 然后我打印了tf卡的前512 可以看到后面有0x55 0xaa，但是前面的内容好像完全错了，我以为是我tf卡格式化有问题，然后我导出了tf卡前512 发现是对的，没有问题，有fat32标识，然后我以为是硬件pin脚不一致导致的，我对照了一下官方的，是这样的 但是这个工程中初始化是写在fpioa.c，是这样的 多了一个32号pin脚不明白是为什么（完全不懂硬件） 而且在初始化的时候片选是3，但是在这里片选却是7 但是我改成我想的样子后，连本来能读取的都读取不了，所以很困惑到底发生了什么，希望能帮忙解惑！

main主分支的eput函数实现是这样的

void eput(struct dirent *entry)
{
    acquire(&ecache.lock);
    if (entry != &root && entry->valid != 0 && entry->ref == 1) {
        // ref == 1 means no other process can have entry locked,
        // so this acquiresleep() won't block (or deadlock).
        acquiresleep(&entry->lock);
        entry->next->prev = entry->prev;
        entry->prev->next = entry->next;
        entry->next = root.next;
        entry->prev = &root;
        root.next->prev = entry;
        root.next = entry;
        release(&ecache.lock);
        if (entry->valid == -1) {       // this means some one has called eremove()
            etrunc(entry);
        } else {
            elock(entry->parent);        // 为什么不在此之前释放entry->lock ？
            eupdate(entry);
            eunlock(entry->parent);
        }
        releasesleep(&entry->lock);

        // Once entry->ref decreases down to 0, we can't guarantee the entry->parent field remains unchanged.
        // Because eget() may take the entry away and write it.
        struct dirent *eparent = entry->parent;
        acquire(&ecache.lock);
        entry->ref--;
        release(&ecache.lock);  // 在查看entry->ref == 0 之前释放是否安全？
        if (entry->ref == 0) {    
            eput(eparent);
        }
        return;
    }
    entry->ref--;
    release(&ecache.lock);
}

在函数第二次释放ecache.lock后才查看enrty->ref == 0 是否安全（原文件694行）？ 设想进程B执行entry->ref--之后，ref变为0，释放了ecache.lock锁之后，另一个进程A调用eget函数尝试获取一个目录块，恰好eget选中了这个刚释放的目录块，此时ref=1，因此进程B不再执行eput(eparent)便返回，这样会导致eparent的ref计数出现问题？

运行make sdcard、 $ make sdcard sd=/dev/sdc flashing into sd card... 524288+0 records in 524288+0 records out 268435456 bytes (268 MB, 256 MiB) copied, 0.974044 s, 276 MB/s

连接板子，make run, $ make run 0+1 records in 0+1 records out 53335 bytes (53 kB, 52 KiB) copied, 0.00043795 s, 122 MB/s Segmentation fault (core dumped) make: *** [Makefile:148: run] Error 139

原句是：
if((sstatus & SSTATUS_SPP) == 0) panic("kerneltrap: not from supervisor mode");

问题：(sstatus & SSTATUS_SPP) = 0 不是意味着sstatus第8位是0么？0意味着是用户态，说明中断是来自用户态，那么为什么要panic？ 谢谢！

在与@AtomHeartCoder讨论之后，我们认为可以在调度器中引入任务（Task）支持。任务控制块的一个草稿如下

struct task {
	struct list _node;                   // 与链表有关的域
	struct proc *process;            // 指向自己的进程控制块
	enum task_status status;     // 当前任务的运行状态
        int tid;                                   // 类似于PID，当前任务的ID
	struct context context;          // 上下文，用于调度
	struct trapframe *tf;              // 用于中断时保护现场
}

任务基于进程，不同的任务之间可能属于同一个进程。而一个进程控制块中主要是包含了当前进程的地址空间信息（页表和segment链表），属于同一个进程的任务共享这些信息，所以在调度器在这些任务之间进行调度时就不需要刷新TLB，这可以进一步地加快调度的速度。

一方面，Kendryte提供的spi.c对于xv6-k210的应用场景来说过于庞杂。原本的代码中考虑了很多在xv6-k210中大概率不会被用到的情况。另一方面，我们也希望通过重写spi.c来彻底消化SD卡驱动的协议栈。最后，我们还希望能够在新的代码中使用kmemalloc.c提供的动态内存分配功能。 但考虑到现有的spi.c模块其实跑得还挺好的，也许这项工作尚不太急？（笑