Getting Ready to Rust

Before we can start running Rust code, we need to do some initialisation.

  1. .section .init.entry, "ax"
  2. .global entry
  3. entry:
  4.     /*
  5.      * Load and apply the memory management configuration, ready to
  6.      * enable MMU and caches.
  7.      */
  8.     adrp x30, idmap
  9.     msr ttbr0_el1, x30
  11.     mov_i x30, .Lmairval
  12.     msr mair_el1, x30
  14.     mov_i x30, .Ltcrval
  15.     /* Copy the supported PA range into TCR_EL1.IPS. */
  16.     mrs x29, id_aa64mmfr0_el1
  17.     bfi x30, x29, #32, #4
  19.     msr tcr_el1, x30
  21.     mov_i x30, .Lsctlrval
  23.     /*
  24.      * Ensure everything before this point has completed, then
  25.      * invalidate any potentially stale local TLB entries before they
  26.      * start being used.
  27.      */
  28.     isb
  29.     tlbi vmalle1
  30.     ic iallu
  31.     dsb nsh
  32.     isb
  34.     /*
  35.      * Configure sctlr_el1 to enable MMU and cache and don't proceed
  36.      * until this has completed.
  37.      */
  38.     msr sctlr_el1, x30
  39.     isb
  41.     /* Disable trapping floating point access in EL1. */
  42.     mrs x30, cpacr_el1
  43.     orr x30, x30, #(0x3 << 20)
  44.     msr cpacr_el1, x30
  45.     isb
  47.     /* Zero out the bss section. */
  48.     adr_l x29, bss_begin
  49.     adr_l x30, bss_end
  50. 0:  cmp x29, x30
  51.     b.hs 1f
  52.     stp xzr, xzr, [x29], #16
  53.     b 0b
  55. 1:  /* Prepare the stack. */
  56.     adr_l x30, boot_stack_end
  57.     mov sp, x30
  59.     /* Set up exception vector. */
  60.     adr x30, vector_table_el1
  61.     msr vbar_el1, x30
  63.     /* Call into Rust code. */
  64.     bl main
  66.     /* Loop forever waiting for interrupts. */
  67. 2:  wfi
  68.     b 2b
  • This is the same as it would be for C: initialising the processor state, zeroing the BSS, and setting up the stack pointer.
    • The BSS (block starting symbol, for historical reasons) is the part of the object file which containing statically allocated variables which are initialised to zero. They are omitted from the image, to avoid wasting space on zeroes. The compiler assumes that the loader will take care of zeroing them.
  • The BSS may already be zeroed, depending on how memory is initialised and the image is loaded, but we zero it to be sure.
  • We need to enable the MMU and cache before reading or writing any memory. If we don’t:
    • Unaligned accesses will fault. We build the Rust code for the aarch64-unknown-none target which sets +strict-align to prevent the compiler generating unaligned accesses, so it should be fine in this case, but this is not necessarily the case in general.
    • If it were running in a VM, this can lead to cache coherency issues. The problem is that the VM is accessing memory directly with the cache disabled, while the host has cacheable aliases to the same memory. Even if the host doesn’t explicitly access the memory, speculative accesses can lead to cache fills, and then changes from one or the other will get lost when the cache is cleaned or the VM enables the cache. (Cache is keyed by physical address, not VA or IPA.)
  • For simplicity, we just use a hardcoded pagetable (see idmap.S) which identity maps the first 1 GiB of address space for devices, the next 1 GiB for DRAM, and another 1 GiB higher up for more devices. This matches the memory layout that QEMU uses.
  • We also set up the exception vector (vbar_el1), which we’ll see more about later.
  • All examples this afternoon assume we will be running at exception level 1 (EL1). If you need to run at a different exception level you’ll need to modify entry.S accordingly.