Skip to main content

Linux Kernel Boot Process in RISC V - SiFive Boards -Introduction

Linux Boot Process in RISC V SiFive boards using BBL 

1. RISC V Boards are having 4 (Four) Modes.
     User mode -- User space programs runs
     Supervisor mode -- Kernel runs here
     Hypervisor mode -- Unspecified
     Machine mode --  Machine instructions
SBI (Supervisory Binary Interface) is interaction between Machine Mode & Supervisor Mode
it provide set of api for Supervisor to interact with Machine mode , like set_timer, system_shutdown, system_reset etc. 
2. In ARM CPU No.s & same is represented in RISC V as Hart Ids.
Boot CPU, or Hartid 0 is given to BBL for Initial boot process,
other HartIds are keep spining still HartId reaches to kernel init process.
3.The mhartid CSR is read,  so Linux can be passed a unique per-hart identifier.
  • 4. A PMP is set up to allow supervisor mode to access all of memory.
  • 5. Machine mode trap handlers, including a machine mode stack, is set up. bbl's machine mode code needs to handle both unimplemented instructions and machine-mode interrupts.
  • 6. The processor executes a mret to jump from machine mode to supervisor mode.
  • bbl jumps to the start of its payload, which in this case is Linux.
7. Early Boot in Linux:
  • 7-1): a0 contains a unique per-hart id. map this to Linux CPU IDs, so this is expected to be contiguous and close to 0.
  • 7-2)a1 contains a pointer to the device tree, represented as a binary flattened device tree (DTB).
  • 7-3) Memory is identity mapped, which bbl accomplishes by not enabling paging.
  • 7-4) The kernel's ELF image has been loaded correctly, with all the various segments at their correct addresses. This isn't particularly onerous for Linux, as it has a simple ELF image to load.
 8. Standard Linux Boot Process:
  • 1. A linear mapping of all physical memory is set up, with PAGE_OFFSET as the offset.
  • Paging is enabled.
  • 2.The C runtime is set up, which includes the stack and global pointers.
  • 3. A spin-only trap vector is set up that catches any errors early in the boot process.
  • start_kernel is called to enter the standard Linux boot process.
9.Setup_Arch:On RISC-V systems, setup_arch proceeds to perform following operations:
  • 9-1):Enable the EARLY_PRINTK console, if the SBI console driver is enabled. On RISC-V we unconditionally enable early printk because the SBI console is well behaved so there is no reason not to enable it.
  • 9-2):The kernel command line is parsed, and the early arch-specific options are dealt with. allowing the user to control the amount of physical memory actually used by Linux.
  • 9-3): The device tree's memory map is parsed in order to find the kernel image's memory block, which is marked as reserved. The rest of the device tree's memory is released to the kernel for allocation.
  • 9-4) The memory management subsystem is initialized, including the zero page and various zones. It support ZONE_NORMAL, as it is quite simple.
  • 9-5) Any other hart in the system is woken up.
  • The processor's ISA is read from the device tree, which is used to fill out the HWCAP field in the ELF aux vec. This allows user space programs to determine what the hardware they're executing. 


Popular posts from this blog

Writing Startup Code for ARM Cortex M4 Controllers

STM32F4 Board bringup using OpenOCD

1.STM32F4 uses ARM Cortex M4 Controller
2.Internal Jtag pin present on the STM32F4 board supports for Debugging kernel which is already flashed on the Board.
3.STM32F4 using RIOT (Revoultionay IOT ) Micro Kernel.

Adding screenshots in sequence from Reset vector table.


Steps followed for writing startup code:
1.Initialize vector table
          2. Enter  to reset_vector()
         3. Copy .data section to RAM
         4. Initialize BSS section to Zeros
         5. Call board_init () 
               (call peripherals _init & cpu_init)
         6. Call libc_init_array()
         7. Call kernel_init()

DMA Debug - Zynq ZC702 - XMD Debugger

DMA Debug in Baremetal using XMD

Writing Startup Code for ARM Cortex A9 - Board bringup series - ZED Board

ZED Board uses Dual ARM Cortex A9
ZED board internally presents Debugger called XMD (Xilinx Microprocessor Debugger)
Xilinx provides Xilinx - SDK which supports Bare metal driver debug using XMD (XMD is having Node locked License)

This boot process is equal to debug using Hardware debugger like Lauterbach /ARM DS-5 /Segger Debugger & the Same is not possible with KGDB.
KGDB is supported grom GNU tools which can enter the Code in RAM (Maxium 4 Stack frames), Debugging code present outside the RAM is possible through Physical debuggers only.

Cortex A9 Processor boot method in Zynq SoC:

   1. The boot.S file contains a minimal set of code for transferring control from the processor's reset      2. Location to the start of the application. It performs the following tasks.
       Invalidate L1 caches, TLBs, Branch Predictor Array, etc.
       Invalidate L2 caches and initialize L2 Cache Controller.
      Enable caches and MMU
     Load MMU translation table base address into TLB  …