riscv | RISC-V processor model

I needed to add LIBS="-lz -lzstd -llzma". The full configuration command looks like this:

We can trace the jumps on binary file only if we don't have any indirect jumps and if the trace is not involved in library functions. In my case I couldn't trace since the program had a lot of pthreads and indirect jumps.

This is standart problem, try to type whereis riscv64-unknown-linux-gnu-gcc if it get nothing, try to type riscv64- and press tab, you should see necessary prefix you need paste after CROSS_COMPILE=. Also maybe you also need add PATH variable with path to riscv-toolchain's bin in ~/.bashrc or/and in ~/.profile.

Build own linux is a big task, maybe you should learn some manuals about toolchain and building linux.

riscv toolchain link

This has been mentioned in Tools Used in 6.S081

At this moment in time, it seems that the package qemu-system-misc has received an update that breaks its compatibility with our kernel. If you run make qemu and the script appears to hang after

This is basically a font issue. You'd need a monospace font with a glyph for U+2705 WHITE HEAVY CHECK MARK and the other characters, and make sure to disable Emojis with a variation selector. Web browsers typically replace missing characters with a fallback font, but then you lose control over character spacing. Your best bet is to use characters which are more likely to be supported. Unfortunately, even U+2713 CHECK MARK seems to be supported only in a few monospace fonts.

u/stepinfusion on reddit

If we are reading the same version of head.S, it looks to me that the instruction at ...008c is head.S:97, the first time satp is modified. head.S:119 is the ret instruction at ...00ac.

I don't know this code very well but it looks like it's supposed to trap at head.S:97 and stvec is pointing to the next instruction's virtual address. It's an interesting way to switch from running in physical space to virtual space without an identity mapping.

It's not that simple. In x86, there are 4 different privilege levels: 0 (operating system kernel), 1, 2, and 3 (applications). Privilege levels 1 and 2 aren't used in Linux: the kernel runs at privilege level 0 while user space code runs at privilege level 3. The current privilege level (CPL) is stored in bits 0 and 1 of the CS (code segment) register.

There are multiple ways in which the transition from user to kernel can happen:

• Through hardware interrupts: page faults, general protection faults, devices, hardware timer, and so on.
• Through software interrupts: the int instruction raises a software interrupt. The most common in Linux is int 0x80, which is configured to be used for system calls from user space to kernel space.
• Through specialized instructions like sysenter and syscall.

In any case, there is no actual code that does the transition: it is done by the processor itself, which switches from one privilege level to the other, and sets up segment selectors, instruction pointer, stack pointer and more according to the information that was set up by the kernel right after booting.

In the case of interrupts, the entries of the Interrupt Descriptor Table (IDT) are used. See this useful documentation page about interrupts in Linux which explains more about the IDT. If you want to get into the details, check out Chapter 5 of the Intel 64 and IA-32 architectures software developer's manual, Volume 3.

In short, each IDT entry specifies a descriptor privilege level (DPL) and a new code segment and offset. In case of software interrupts, some privilege level checks are made by the processor (one of which is CPL <= DPL) to determine whether the code that issued the interrupt has the privilege to do so. Then, the interrupt handler is executed, which implicitly sets the new CS register with the privilege level bits set to 0. This is how the canonical int 0x80 syscall for x86 32bit is made.

In case of specialized instructions like sysenter and syscall, the details differ, but the concept is similar: the CPU checks privileges and then retrieves the information from dedicated Model Specific Registers (MSR) that were previously set up by the kernel after boot.

For system calls the result is always the same: user code switches to privilege level 0 and starts executing kernel code, ending up right at the beginning of one of the different syscall entry points defined by the kernel.

Possible syscall entry points are:

• entry_INT80_32 for 32-bit int 0x80
• entry_INT80_compat for 32-bit int 0x80 on a 64-bit kernel
• entry_SYSENTER_32 for 32-bit sysenter
• entry_SYSENTER_compat for 32-bit sysenter on a 64-bit kernel
• entry_SYSCALL_64 for 64-bit syscall
• entry_SYSCALL_compat for 32-bit syscall on 64-bit kernel (special entry point which is not used by user code, in theory syscall is also a valid 32-bit instruction on AMD CPUs, but Linux only uses it for 64-bit because of its weird semantics)

My suggestion:

• flash your SD card to a rpi distribution to make sure the hardware is still working
• if the hardware is good, check the difference of your code with the in-kernel serial driver

The error message does not say that the header was included multiple times. It says that the same symbol exists in multiple object files and the header file is just the source of that symbol.

If an H file defines a symbol, then in fact every C file that includes it will define that symbol because only a compiled file can define a symbol and H files are not compiled, they are included into C files when those C files are compiled (actually when they are preprocessed but that usually happens when they are compiled). And if multiple C files define the same symbol, are compiled, and linked together (note that this is a ld error, so it is a linker error), you end up with multiple symbols of the same name, which is not allowed by C standard.

If a H file just wants to inform a C file about the existence and type of a symbol that is defined elsewhere, e.g. in another C file, it must only declare the symbol by prefixing it with extern.