1. 28 Apr, 2020 1 commit
    • Andre Przywara's avatar
      fdt/wrappers: Generalise fdtw_read_array() · 6e3a89f4
      Andre Przywara authored
      
      
      Currently our fdtw_read_array() implementation requires the length of
      the property to exactly match the requested size, which makes it less
      flexible for parsing generic device trees.
      Also the name is slightly misleading, since we treat the cells of the
      array as 32 bit unsigned integers, performing the endianess conversion.
      
      To fix those issues and align the code more with other DT users (Linux
      kernel or U-Boot), rename the function to "fdt_read_uint32_array", and
      relax the length check to only check if the property covers at least the
      number of cells we request.
      This also changes the variable names to be more in-line with other DT
      users, and switches to the proper data types.
      
      This makes this function more useful in later patches.
      
      Change-Id: Id86f4f588ffcb5106d4476763ecdfe35a735fa6c
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      6e3a89f4
  2. 27 Apr, 2020 1 commit
  3. 25 Apr, 2020 1 commit
    • Masahiro Yamada's avatar
      linker_script: move .data section to bl_common.ld.h · caa3e7e0
      Masahiro Yamada authored
      Move the data section to the common header.
      
      I slightly tweaked some scripts as follows:
      
      [1] bl1.ld.S has ALIGN(16). I added DATA_ALIGN macro, which is 1
          by default, but overridden by bl1.ld.S. Currently, ALIGN(16)
          of the .data section is redundant because commit 41286590
      
      
          ("Fix boot failures on some builds linked with ld.lld.") padded
          out the previous section to work around the issue of LLD version
          <= 10.0. This will be fixed in the future release of LLVM, so
          I am keeping the proper way to align LMA.
      
      [2] bl1.ld.S and bl2_el3.ld.S define __DATA_RAM_{START,END}__ instead
          of __DATA_{START,END}__. I put them out of the .data section.
      
      [3] SORT_BY_ALIGNMENT() is missing tsp.ld.S, sp_min.ld.S, and
          mediatek/mt6795/bl31.ld.S. This commit adds SORT_BY_ALIGNMENT()
          for all images, so the symbol order in those three will change,
          but I do not think it is a big deal.
      
      Change-Id: I215bb23c319f045cd88e6f4e8ee2518c67f03692
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      caa3e7e0
  4. 24 Apr, 2020 3 commits
    • Masahiro Yamada's avatar
      linker_script: move stacks section to bl_common.ld.h · a926a9f6
      Masahiro Yamada authored
      
      
      The stacks section is the same for all BL linker scripts.
      
      Move it to the common header file.
      
      Change-Id: Ibd253488667ab4f69702d56ff9e9929376704f6c
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      a926a9f6
    • Masahiro Yamada's avatar
      bl1: remove '.' from stacks section in linker script · b9f7b57d
      Masahiro Yamada authored
      Only BL1 specifies '.' in the address field of the stacks section.
      
      Commit 4f59d835 ("Make BL1 RO and RW base addresses configurable")
      added '.' on purpose but the commit message does not help to understand
      why.
      
      This commit gets rid of it in order to factor out the stacks section
      into include/common/bl_common.ld.h
      
      I compared the build result for PLAT=qemu.
      
      'aarch64-linux-gnu-nm -n build/qemu/release/bl1/bl1.elf' will change
      as follows:
      
      @@ -336,8 +336,8 @@
       000000000e04e0e0 d max_log_level
       000000000e04e0e4 D console_state
       000000000e04e0e5 D __DATA_RAM_END__
      -000000000e04e0e5 B __STACKS_START__
       000000000e04e100 b platform_normal_stacks
      +000000000e04e100 B __STACKS_START__
       000000000e04f100 b bl1_cpu_context
       000000000e04f100 B __BSS_START__
       000000000e04f100 B __STACKS_END__
      
      After this change, __STACKS_START__ will match to platform_normal_stacks,
      and I think it makes more sense.
      
      'aarch64-linux-gnu-objdump -h build/qemu/release/bl1/bl1.elf' will change
      as follows:
      
      @@ -9,11 +9,11 @@
                         CONTENTS, ALLOC, LOAD, READONLY, DATA
         2 .data         000000e5  000000000e04e000  0000000000004a60  0001e000  2**4
                         CONTENTS, ALLOC, LOAD, DATA
      -  3 stacks        0000101b  000000000e04e0e5  000000000e04e0e5  0001e0e5  2**6
      +  3 stacks        00001000  000000000e04e100  0000000000004b45  0001e100  2**6
                         ALLOC
      -  4 .bss          000007e0  000000000e04f100  000000000e04f100  0001e0e5  2**5
      +  4 .bss          000007e0  000000000e04f100  0000000000004b50  0001f100  2**5
                         ALLOC
      -  5 xlat_table    00006000  000000000e050000  000000000e050000  0001e0e5  2**12
      +  5 xlat_table    00006000  000000000e050000  0000000000004b45  00020000  2**12
                         ALLOC
         6 coherent_ram  00000000  000000000e056000  000000000e056000  0001f000  2**12
                         CONTENTS
      
      Sandrine pointed me to a useful document [1] to understand why LMAs of
      stacks, .bss, and xlat_table section have changed.
      
      Before this patch, they fell into this scenario:
       "If the section has a specific VMA address, then this is used as the
        LMA address as well."
      
      With this commit, the following applies:
       "Otherwise if a memory region can be found that is compatible with the
        current section, and this region contains at least one section, then
        the LMA is set so the difference between the VMA and LMA is the same
        as the difference between the VMA and LMA of the last section in the
        located region."
      
      Anyway, those three sections are not loaded, so the LMA changes will not
      be a problem. The size of bl1.bin is still the same.
      
      QEMU still boots successfully with this change.
      
      A good thing is, this fixes the error for the latest LLD. If I use the
      mainline LLVM, I see the following error. The alignment check will probably
      be included in the LLVM 11 release, so it is better to fix it now.
      
      $ PLAT=qemu CC=clang CROSS_COMPILE=aarch64-linux-gnu-
        [ snip ]
      ld.lld: error: address (0xe04e0e5) of section stacks is not a multiple of alignment (64)
      make: *** [Makefile:1050: build/qemu/release/bl1/bl1.elf] Error 1
      
      [1]: https://sourceware.org/binutils/docs/ld/Output-Section-LMA.html#Output-Section-LMA
      
      
      
      Change-Id: I3d2f3cc2858be8b3ce2eab3812a76d1e0b5f3a32
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      b9f7b57d
    • Sandrine Bailleux's avatar
  5. 23 Apr, 2020 4 commits
  6. 22 Apr, 2020 1 commit
  7. 21 Apr, 2020 2 commits
  8. 20 Apr, 2020 2 commits
  9. 17 Apr, 2020 6 commits
  10. 16 Apr, 2020 7 commits
  11. 15 Apr, 2020 6 commits
  12. 14 Apr, 2020 2 commits
  13. 13 Apr, 2020 1 commit
  14. 09 Apr, 2020 2 commits
  15. 07 Apr, 2020 1 commit