Am 30. Juli 2020 22:11:39 MESZ schrieb Heinrich Schuchardt <xypron.g...@gmx.de>: >Am 30. Juli 2020 20:31:47 MESZ schrieb Atish Patra ><ati...@atishpatra.org>: >>On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt >><xypron.g...@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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
