1. 11 Jul, 2019 1 commit
    • Atish Patra's avatar
      RISC-V: Add an Image header that boot loader can parse. · 0f327f2a
      Atish Patra authored
      Currently, the last stage boot loaders such as U-Boot can accept only
      uImage which is an unnecessary additional step in automating boot
      Add an image header that boot loader understands and boot Linux from
      flat Image directly.
      This header is based on ARM64 boot image header and provides an
      opportunity to combine both ARM64 & RISC-V image headers in future.
      Also make sure that PE/COFF header can co-exist in the same image so
      that EFI stub can be supported for RISC-V in future. EFI specification
      needs PE/COFF image header in the beginning of the kernel image in order
      to load it as an EFI application. In order to support EFI stub, code0
      should be replaced with "MZ" magic string and res4(at offset 0x3c)
      should point to the rest of the PE/COFF header (which will be added
      during EFI support).
      Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
      Signed-off-by: default avatarAtish Patra <atish.patra@wdc.com>
      Reviewed-by: default avatarKarsten Merker <merker@debian.org>
      Tested-by: Karsten Merker <merker@debian.org> (QEMU+OpenSBI+U-Boot)
      Tested-by: Kevin Hilman <khilman@baylibre.com> (OpenSBI + U-Boot + Linux)
      [paul.walmsley@sifive.com: fixed whitespace in boot-image-header.txt;
       converted structure comment to kernel-doc format and added some detail]
      Signed-off-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
  2. 09 Jul, 2019 1 commit
    • Anup Patel's avatar
      RISC-V: Setup initial page tables in two stages · 671f9a3e
      Anup Patel authored
      Currently, the setup_vm() does initial page table setup in one-shot
      very early before enabling MMU. Due to this, the setup_vm() has to map
      all possible kernel virtual addresses since it does not know size and
      location of RAM. This means we have kernel mappings for non-existent
      RAM and any buggy driver (or kernel) code doing out-of-bound access
      to RAM will not fault and cause underterministic behaviour.
      Further, the setup_vm() creates PMD mappings (i.e. 2M mappings) for
      RV64 systems. This means for PAGE_OFFSET=0xffffffe000000000 (i.e.
      MAXPHYSMEM_128GB=y), the setup_vm() will require 129 pages (i.e.
      516 KB) of memory for initial page tables which is never freed. The
      memory required for initial page tables will further increase if
      we chose a lower value of PAGE_OFFSET (e.g. 0xffffff0000000000)
      This patch implements two-staged initial page table setup, as follows:
      1. Early (i.e. setup_vm()): This stage maps kernel image and DTB in
      a early page table (i.e. early_pg_dir). The early_pg_dir will be used
      only by boot HART so it can be freed as-part of init memory free-up.
      2. Final (i.e. setup_vm_final()): This stage maps all possible RAM
      banks in the final page table (i.e. swapper_pg_dir). The boot HART
      will start using swapper_pg_dir at the end of setup_vm_final(). All
      non-boot HARTs directly use the swapper_pg_dir created by boot HART.
      We have following advantages with this new approach:
      1. Kernel mappings for non-existent RAM don't exists anymore.
      2. Memory consumed by initial page tables is now indpendent of the
      chosen PAGE_OFFSET.
      3. Memory consumed by initial page tables on RV64 system is 2 pages
      (i.e. 8 KB) which has significantly reduced and these pages will be
      freed as-part of the init memory free-up.
      The patch also provides a foundation for implementing strict kernel
      mappings where we protect kernel text and rodata using PTE permissions.
      Suggested-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: default avatarAnup Patel <anup.patel@wdc.com>
      [paul.walmsley@sifive.com: updated to apply; fixed a checkpatch warning]
      Signed-off-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
  3. 04 Jul, 2019 2 commits
  4. 03 Jul, 2019 2 commits
  5. 01 Jul, 2019 8 commits
  6. 30 Jun, 2019 3 commits
  7. 29 Jun, 2019 23 commits