efi_loader/RISC-V: misaligned load when running grubriscv64.efi

[Heinrich Schuchardt]

Am 30. Juli 2020 22:11:39 MESZ schrieb Heinrich Schuchardt <xypron.glpk at gmx.de>:
>Am 30. Juli 2020 20:31:47 MESZ schrieb Atish Patra
><atishp at atishpatra.org>:
>>On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt
>><xypron.glpk at gmx.de> wrote:
>>>
>>> On 30.07.20 12:16, Sean Anderson wrote:
>>> > On 7/30/20 6:03 AM, Heinrich Schuchardt wrote:
>>> >> Dear Sean,
>>> >>
>>> >> when trying to run grubriscv64.efi from the
>>> >> trini/u-boot-gitlab-ci-runner:bionic-20200526-18Jun2020 Docker
>>image on
>>> >> a MAIXDUINO the relocations are not naturally aligned:
>>> >>
>>> >> lib/efi_loader/efi_image_loader.c(133) efi_loader_relocate():
>>> >>
>>> >>     efi_reloc 000000008030a000, offset 0x101e, type 10
>>> >>
>>> >> Here we are trying to change an u64 at 0x8030B01E:
>>> >>
>>> >>     uint64_t *x64 = efi_reloc + offset;
>>> >>     *x64 += (uint64_t)delta;
>>> >>
>>> >> This leads to an exception in function efi_loader_relocate():
>>> >>
>>> >>     Unhandled exception: Load address misaligned
>>> >>     EPC: 00000000805a95ac RA: 00000000805a953a TVAL:
>>000000008030b01e
>>> >>     EPC: 000000008001c5ac RA: 000000008001c53a reloc
>>> >>
>>> >> The GRUB image is available here:
>>> >>
>>> >>
>>https://gist.github.com/xypron/522a91962248e9c3888d8554cb61ad2c/raw/b959661626b38a738673a9efb2f398b2fabd5c77/grubriscv64.efi
>>> >>
>>> >> On QEMU the GRUB image is executed without problems:
>>> >>
>>> >> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/132919
>>> >>
>>> >> The UEFI specification requires for the ARM platform that
>>unaligned
>>> >> support is enabled. This is why we have implemented function
>>> >> allow_unaligned().
>>> >>
>>> >> On RISC-V we have not yet implemented allow_unaligned() yet. Is
>>there a
>>> >> way to switch RISCV64 CPUs especially the Kendryte K210 into a
>>mode
>>> >> supporting unaligned access?
>>> >
>>> > AFAIK RISC-V has no requirement that un-aligned loads/stores
>>complete. I
>>> > believe the recommended solution is to install a trap handler
>which
>>> > completes the un-aligned load through a series of aligned loads
>and
>>then
>>> > returns back to the application. For an example of such an
>>> > implementation, check out arch/riscv/kernel/traps_misaligned.c in
>>Linux.
>>> > This may be too complex for U-Boot, so perhaps you can simply
>>disallow
>>> > unaligned accesses?
>>> >
>>> > --Sean
>>> >
>>>
>>> Working around the problem inside U-Boot is easy (just some memcpy()
>>> calls) but the GRUB image itself also makes unaligned accesses:
>>>
>>> Unhandled exception: Load address misaligned
>>> EPC: 000000008030b004 RA: 00000000805a4eca TVAL: 000000008030b02e
>>> EPC: 000000007fd7e004 RA: 0000000080017eca reloc
>>>
>>> UEFI image [0x000000008030a000:0x0000000080433fff] pc=0x1004
>>>
>>> This is what I found in "RISC-V Unprivileged ISA V20191213"
>>>
>>> "Loads  and  stores  where  the  effective  address  is  not 
>>naturally
>>> aligned to the referenced datatype (i.e., on a four-byte boundary
>for
>>> 32-bit accesses, and a two-byte boundary for 16-bit accesses) have
>>> behavior dependent on the EEI. An EEI may guarantee that misaligned
>>> loads and stores are fully supported, and so the software running
>>inside
>>> the execution environment will never experience a contained or fatal
>>> address-misaligned trap."
>>>
>>> @Leif
>>> Should GRUB be built with -mstrict-align for RISC-V?
>>>
>>
>>That shouldn't be necessary. Any real board with an MMU that can boot
>>Linux needs
>>a SBI provider such as OpenSBI. OpenSBI already implements a
>misaligned
>>handler.
>>
>>Are we planning to support EFI booting for NoMMU platforms ? As per my
>>understanding
>>runtime services need to be mapped through kernel page tables.
>>
>
>My interest is to have an affordable hardware platform where I can test
>U-Boot's UEFI sub-system on RISC-V.
>
>With 6 MiB usable RAM. (2 MiB reserved for AI) we probably won't get
>further than running GRUB.
>
>Can OpenSBI be built for the Kendryte K210 SoC? What is the size of
>OpenSBI?

Yes: 
https://github.com/riscv/opensbi/tree/master/platform/kendryte/k210

So we should try if we can run U-Boot with OpenSBI on the platform.

>
>Best regards
>
>Heinrich
>
>>> @Ard
>>> How about the EFI part of the Linux kernel?
>>>
>>> Best regards
>>>
>>> Heinrich