When compiling with android toolchain, there is an instruction
"str     q0, [x8],u-boot#16", but x8 is not 16bytes aligned,
this instruction will trigger sync abort.

So, following Linux kernel, only use general regs for arm64.
If not, compiler may use simd registers Q[x]. We need to avoid
using simd registers in U-Boot, because load/store Q[x] has
restriction that 128bits aligned when str/ldr.

Signed-off-by: Peng Fan <[email protected]>
(cherry picked from commit 186ccd8)
(cherry picked from commit 8f3f0d3)

When compiling with android toolchain, there is an instruction
"str     q0, [x8],u-boot#16", but x8 is not 16bytes aligned,
this instruction will trigger sync abort.

So, following Linux kernel, only use general regs for arm64.
If not, compiler may use simd registers Q[x]. We need to avoid
using simd registers in U-Boot, because load/store Q[x] has
restriction that 128bits aligned when str/ldr.

Signed-off-by: Peng Fan <[email protected]>
(cherry picked from commit 186ccd8)
(cherry picked from commit 8f3f0d3)

When compiling with android toolchain, there is an instruction
"str     q0, [x8],u-boot#16", but x8 is not 16bytes aligned,
this instruction will trigger sync abort.

So, following Linux kernel, only use general regs for arm64.
If not, compiler may use simd registers Q[x]. We need to avoid
using simd registers in U-Boot, because load/store Q[x] has
restriction that 128bits aligned when str/ldr.

Signed-off-by: Peng Fan <[email protected]>
(cherry picked from commit 186ccd8)
(cherry picked from commit 8f3f0d3)
(cherry picked from commit 3002af0)

Compiling U-Boot with ubsan/asan libraries and running it in sandbox
may lead to below backtrace:

 => avb init 0
 => avb verify
 ## Android Verified Boot 2.0 version 1.1.0
read_is_device_unlocked not supported yet
common/avb_verify.c:407:31: runtime error: division by zero
AddressSanitizer:DEADLYSIGNAL
Reviewed-by: Igor Opaniuk <[email protected]>

=================================================================
==9388==ERROR: AddressSanitizer: FPE on unknown address 0x0000004b467f \
    (pc 0x0000004b467f bp 0x000000000000 sp 0x7ffd899fe150 T0)
    #0 0x4b467e in mmc_byte_io common/avb_verify.c:407
    #1 0x4b4c47 in mmc_byte_io common/avb_verify.c:532
    #2 0x4b4c47 in read_from_partition common/avb_verify.c:533
    #3 0x69dc0d in load_and_verify_vbmeta lib/libavb/avb_slot_verify.c:560
    #4 0x6a1ee6 in avb_slot_verify lib/libavb/avb_slot_verify.c:1139
    #5 0x45dabd in do_avb_verify_part cmd/avb.c:245
    #6 0x4af77c in cmd_call common/command.c:499
    u-boot#7 0x4af77c in cmd_process common/command.c:538
    u-boot#8 0x46bafc in run_pipe_real common/cli_hush.c:1677
    u-boot#9 0x46bafc in run_list_real common/cli_hush.c:1875
    u-boot#10 0x46c780 in run_list common/cli_hush.c:2024
    u-boot#11 0x46c780 in parse_stream_outer common/cli_hush.c:3216
    u-boot#12 0x46d34b in parse_file_outer common/cli_hush.c:3299
    u-boot#13 0x4ad609 in cli_loop common/cli.c:217
    u-boot#14 0x4625ae in main_loop common/main.c:65
    u-boot#15 0x46f2d1 in run_main_loop common/board_r.c:648
    u-boot#16 0x640253 in initcall_run_list lib/initcall.c:30
    u-boot#17 0x46f9d0 in board_init_r common/board_r.c:879
    u-boot#18 0x40539b in main arch/sandbox/cpu/start.c:321
    u-boot#19 0x7fa94925f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    u-boot#20 0x408908 in _start (/srv/R/u-boot-master/u-boot+0x408908)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE common/avb_verify.c:407 in mmc_byte_io
==9388==ABORTING

Signed-off-by: Eugeniu Rosca <[email protected]>

Atish reports that on RISC-V, accessing the EFI variables causes
a kernel panic. An objdump of the file verifies that, since the
global pointer for efi_var_buf ends up in .GOT section which is
not mapped in virtual address space for Linux.

<snip of efi_var_mem_find>

0000000000000084 <efi_var_mem_find>:
  84:   715d                    addi    sp,sp,-80

* objdump -dr
0000000000000086 <.LCFI2>:
  86:   e0a2                    sd  s0,64(sp)
  88:   fc26                    sd  s1,56(sp)
  8a:   e486                    sd  ra,72(sp)
  8c:   f84a                    sd  s2,48(sp)
  8e:   f44e                    sd  s3,40(sp)
  90:   f052                    sd  s4,32(sp)
  92:   ec56                    sd  s5,24(sp)
  94:   00000497            auipc   s1,0x0
            94: R_RISCV_GOT_HI20    efi_var_buf
  98:   0004b483            ld  s1,0(s1) # 94 <.LCFI2+0xe>
            98: R_RISCV_PCREL_LO12_I    .L0
            98: R_RISCV_RELAX   *ABS*

* objdump -t
0000000000000084 g     F .text.efi_runtime  00000000000000b8 efi_var_mem_find

With the patch applied:

* objdump -dr
0000000000000086 <.LCFI2>:
  86:   e0a2                    sd  s0,64(sp)
  88:   fc26                    sd  s1,56(sp)
  8a:   e486                    sd  ra,72(sp)
  8c:   f84a                    sd  s2,48(sp)
  8e:   f44e                    sd  s3,40(sp)
  90:   f052                    sd  s4,32(sp)
  92:   ec56                    sd  s5,24(sp)
  94:   00000497            auipc   s1,0x0
            94: R_RISCV_PCREL_HI20  .LANCHOR0
            94: R_RISCV_RELAX   *ABS*
  98:   00048493            mv  s1,s1
            98: R_RISCV_PCREL_LO12_I    .L0
            98: R_RISCV_RELAX   *ABS*

* objdump -t
0000000000000008 l     O .data.efi_runtime  0000000000000008 efi_var_buf

On arm64 this works, because there's no .GOT entries for this
and everything is converted to relative references.

* objdump -dr (identical pre-post patch, only the new function shows up)
00000000000000b4 <efi_var_mem_find>:
  b4:   aa0003ee    mov x14, x0
  b8:   9000000a    adrp    x10, 0 <efi_var_mem_compare>
            b8: R_AARCH64_ADR_PREL_PG_HI21  .data.efi_runtime
  bc:   91000140    add x0, x10, #0x0
            bc: R_AARCH64_ADD_ABS_LO12_NC   .data.efi_runtime
  c0:   aa0103ed    mov x13, x1
  c4:   79400021    ldrh    w1, [x1]
  c8:   aa0203eb    mov x11, x2
  cc:   f9400400    ldr x0, [x0, #8]
  d0:   b940100c    ldr w12, [x0, #16]
  d4:   8b0c000c    add x12, x0, x12

So let's switch efi_var_buf to static and create a helper function for
anyone that needs to update it.

Fixes: e01aed4 ("efi_loader: Enable run-time variable support for tee based variables")
Reported-by: Atish Patra <[email protected]>
Tested-by: Atish Patra <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>

…-dram-size to rcm-tx018-develop

* commit 'dde8ec86b52553911c53697caa25bee3de7540dd':
  Fix show dram size

When compiling with android toolchain, there is an instruction
"str     q0, [x8],u-boot#16", but x8 is not 16bytes aligned,
this instruction will trigger sync abort.

So, following Linux kernel, only use general regs option to IMX8 and
IMX8M aarch64 only.
If not, compiler may use simd registers Q[x]. We need to avoid
using simd registers in U-Boot, because load/store Q[x] has
restriction that 128bits aligned when str/ldr.

Signed-off-by: Peng Fan <[email protected]>
(cherry picked from commit 186ccd8)
(cherry picked from commit 8f3f0d3)
(cherry picked from commit 3002af0)
(cherry picked from commit ad1f02f)

When compiling with android toolchain, there is an instruction
"str     q0, [x8],u-boot#16", but x8 is not 16bytes aligned,
this instruction will trigger sync abort.

So, following Linux kernel, only use general regs option to IMX8 and
IMX8M aarch64 only.
If not, compiler may use simd registers Q[x]. We need to avoid
using simd registers in U-Boot, because load/store Q[x] has
restriction that 128bits aligned when str/ldr.

Signed-off-by: Peng Fan <[email protected]>
(cherry picked from commit 186ccd8)
(cherry picked from commit 8f3f0d3)
(cherry picked from commit 3002af0)
(cherry picked from commit ad1f02f)
(cherry picked from commit 2472b4b)
(cherry picked from commit b24017f2173093309092dbc636a73d28f4f0a1cb)

Added the I2C driver

When compiling with android toolchain, there is an instruction
"str     q0, [x8],u-boot#16", but x8 is not 16bytes aligned,
this instruction will trigger sync abort.

So, following Linux kernel, only use general regs option to IMX8 and
IMX8M aarch64 only.
If not, compiler may use simd registers Q[x]. We need to avoid
using simd registers in U-Boot, because load/store Q[x] has
restriction that 128bits aligned when str/ldr.

Signed-off-by: Peng Fan <[email protected]>
(cherry picked from commit 186ccd8)
(cherry picked from commit 8f3f0d3)
(cherry picked from commit 3002af0)
(cherry picked from commit ad1f02f)
(cherry picked from commit 2472b4b)
(cherry picked from commit b24017f2173093309092dbc636a73d28f4f0a1cb)

When compiling with android toolchain, there is an instruction
"str     q0, [x8],u-boot#16", but x8 is not 16bytes aligned,
this instruction will trigger sync abort.

So, following Linux kernel, only use general regs option to IMX8 and
IMX8M aarch64 only.
If not, compiler may use simd registers Q[x]. We need to avoid
using simd registers in U-Boot, because load/store Q[x] has
restriction that 128bits aligned when str/ldr.

Signed-off-by: Peng Fan <[email protected]>
(cherry picked from commit 186ccd8)
(cherry picked from commit 8f3f0d3)
(cherry picked from commit 3002af0)
(cherry picked from commit ad1f02f)
(cherry picked from commit 2472b4b)
(cherry picked from commit b24017f2173093309092dbc636a73d28f4f0a1cb)

Raymond Mao <[email protected]> says:

Motivations for changes:
Current SMBIOS library and command-line tool is not fully matching with
the requirements:
1. Missing support for other mandatory types (u-boot#7, u-boot#9, u-boot#16, u-boot#17, u-boot#19).
2. Only a few platforms support SMBIOS node from the device tree.
3. Values of some fields are hardcoded in the library other than fetching
   from the device hardware.
4. Embedded data with dynamic length is not supported (E.g. Contained
   Object Handles in Type u-boot#2 and Contained Elements in Type u-boot#3)

Changes:
1. Refactor the SMBIOS library and command-line tool to better align with
   the SMBIOS spec.
2. Create an arch-specific driver for all aarch64-based platforms to fetch
   SMBIOS private data from the device hardware (processor and cache).
3. Create a sysinfo driver to poppulate platform SMBIOS private data.
4. Add generic SMBIOS DTS file for arm64 platforms for those common strings
   and values which cannot be retrieved from the system registers.
   Vendors can create their own SMBIOS node using this as an example.
   For those boards without SMBIOS nodes, this DTS file can be included to
   have a generic SMBIOS information of the system.
5. Add support for Type u-boot#7 (Cache Information) and link its handles to
   Type u-boot#4.
6. To minimize size-growth for those platforms which have not sufficient
   ROM spaces or the platforms which don't need detailed SMBIOS
   information, new added fields are only being built when kconfig
   GENERATE_SMBIOS_TABLE_VERBOSE is selected.

Once this patch is acceptted, subsequent patch sets will add other missing
types (u-boot#9, u-boot#16, u-boot#17, u-boot#19).

Tests:
To test this with QEMU arm64, please follow the guide on dt_qemu.rst to
get a merged DT to run with.
```
qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
cat  <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \
  | dtc - -o merged.dtb
qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \
  -dtb merged.dtb
```

Link: https://lore.kernel.org/r/[email protected]

Raymond Mao <[email protected]> says:

Motivations for changes:
Current SMBIOS library and command-line tool is not fully matching with
the requirements:
1. Missing support for other mandatory types (#7, #9, #16, #17, #19).
2. Only a few platforms support SMBIOS node from the device tree.
3. Values of some fields are hardcoded in the library other than fetching
   from the device hardware.
4. Embedded data with dynamic length is not supported (E.g. Contained
   Object Handles in Type #2 and Contained Elements in Type #3)

Changes:
1. Refactor the SMBIOS library and command-line tool to better align with
   the SMBIOS spec.
2. Create an arch-specific driver for all aarch64-based platforms to fetch
   SMBIOS private data from the device hardware (processor and cache).
3. Create a sysinfo driver to poppulate platform SMBIOS private data.
4. Add generic SMBIOS DTS file for arm64 platforms for those common strings
   and values which cannot be retrieved from the system registers.
   Vendors can create their own SMBIOS node using this as an example.
   For those boards without SMBIOS nodes, this DTS file can be included to
   have a generic SMBIOS information of the system.
5. Add support for Type #7 (Cache Information) and link its handles to
   Type #4.
6. To minimize size-growth for those platforms which have not sufficient
   ROM spaces or the platforms which don't need detailed SMBIOS
   information, new added fields are only being built when kconfig
   GENERATE_SMBIOS_TABLE_VERBOSE is selected.

Once this patch is acceptted, subsequent patch sets will add other missing
types (#9, #16, #17, #19).

Tests:
To test this with QEMU arm64, please follow the guide on dt_qemu.rst to
get a merged DT to run with.
```
qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
cat  <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \
  | dtc - -o merged.dtb
qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \
  -dtb merged.dtb
```

Link: https://lore.kernel.org/r/[email protected]