* efi_loader/RISC-V: misaligned load when running grubriscv64.efi
@ 2020-07-30 10:03 Heinrich Schuchardt
2020-07-30 10:16 ` Sean Anderson
0 siblings, 1 reply; 12+ messages in thread
From: Heinrich Schuchardt @ 2020-07-30 10:03 UTC (permalink / raw)
To: u-boot
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?
Best regards
Heinrich
^ permalink raw reply [flat|nested] 12+ messages in thread
* efi_loader/RISC-V: misaligned load when running grubriscv64.efi
2020-07-30 10:03 efi_loader/RISC-V: misaligned load when running grubriscv64.efi Heinrich Schuchardt
@ 2020-07-30 10:16 ` Sean Anderson
2020-07-30 11:04 ` Heinrich Schuchardt
0 siblings, 1 reply; 12+ messages in thread
From: Sean Anderson @ 2020-07-30 10:16 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* efi_loader/RISC-V: misaligned load when running grubriscv64.efi
2020-07-30 10:16 ` Sean Anderson
@ 2020-07-30 11:04 ` Heinrich Schuchardt
0 siblings, 0 replies; 12+ messages in thread
From: Heinrich Schuchardt @ 2020-07-30 11:04 UTC (permalink / raw)
To: u-boot
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?
@Ard
How about the EFI part of the Linux kernel?
Best regards
Heinrich
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi_loader/RISC-V: misaligned load when running grubriscv64.efi
@ 2020-07-30 11:04 ` Heinrich Schuchardt
0 siblings, 0 replies; 12+ messages in thread
From: Heinrich Schuchardt @ 2020-07-30 11:04 UTC (permalink / raw)
To: Sean Anderson, Leif Lindholm
Cc: Alexander Graf, U-Boot Mailing List, Rick Chen, Daniel Kiper,
GRUB mailing list, Ard Biesheuvel
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?
@Ard
How about the EFI part of the Linux kernel?
Best regards
Heinrich
^ permalink raw reply [flat|nested] 12+ messages in thread
* efi_loader/RISC-V: misaligned load when running grubriscv64.efi
2020-07-30 11:04 ` Heinrich Schuchardt
@ 2020-07-30 18:31 ` Atish Patra
-1 siblings, 0 replies; 12+ messages in thread
From: Atish Patra @ 2020-07-30 18:31 UTC (permalink / raw)
To: u-boot
On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt <xypron.glpk@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.
> @Ard
> How about the EFI part of the Linux kernel?
>
> Best regards
>
> Heinrich
--
Regards,
Atish
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi_loader/RISC-V: misaligned load when running grubriscv64.efi
@ 2020-07-30 18:31 ` Atish Patra
0 siblings, 0 replies; 12+ messages in thread
From: Atish Patra @ 2020-07-30 18:31 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Sean Anderson, Leif Lindholm, Alexander Graf,
U-Boot Mailing List, Rick Chen, Daniel Kiper, GRUB mailing list,
Ard Biesheuvel
On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt <xypron.glpk@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.
> @Ard
> How about the EFI part of the Linux kernel?
>
> Best regards
>
> Heinrich
--
Regards,
Atish
^ permalink raw reply [flat|nested] 12+ messages in thread
* efi_loader/RISC-V: misaligned load when running grubriscv64.efi
2020-07-30 18:31 ` Atish Patra
@ 2020-07-30 20:11 ` Heinrich Schuchardt
-1 siblings, 0 replies; 12+ messages in thread
From: Heinrich Schuchardt @ 2020-07-30 20:11 UTC (permalink / raw)
To: u-boot
Am 30. Juli 2020 20:31:47 MESZ schrieb Atish Patra <atishp@atishpatra.org>:
>On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt
><xypron.glpk@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?
Best regards
Heinrich
>> @Ard
>> How about the EFI part of the Linux kernel?
>>
>> Best regards
>>
>> Heinrich
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi_loader/RISC-V: misaligned load when running grubriscv64.efi
@ 2020-07-30 20:11 ` Heinrich Schuchardt
0 siblings, 0 replies; 12+ messages in thread
From: Heinrich Schuchardt @ 2020-07-30 20:11 UTC (permalink / raw)
To: Atish Patra
Cc: Sean Anderson, Leif Lindholm, Alexander Graf,
U-Boot Mailing List, Rick Chen, Daniel Kiper, GRUB mailing list,
Ard Biesheuvel
Am 30. Juli 2020 20:31:47 MESZ schrieb Atish Patra <atishp@atishpatra.org>:
>On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt
><xypron.glpk@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?
Best regards
Heinrich
>> @Ard
>> How about the EFI part of the Linux kernel?
>>
>> Best regards
>>
>> Heinrich
^ permalink raw reply [flat|nested] 12+ messages in thread
* efi_loader/RISC-V: misaligned load when running grubriscv64.efi
2020-07-30 20:11 ` Heinrich Schuchardt
@ 2020-07-30 20:19 ` Heinrich Schuchardt
-1 siblings, 0 replies; 12+ messages in thread
From: Heinrich Schuchardt @ 2020-07-30 20:19 UTC (permalink / raw)
To: u-boot
Am 30. Juli 2020 22:11:39 MESZ schrieb Heinrich Schuchardt <xypron.glpk@gmx.de>:
>Am 30. Juli 2020 20:31:47 MESZ schrieb Atish Patra
><atishp@atishpatra.org>:
>>On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt
>><xypron.glpk@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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi_loader/RISC-V: misaligned load when running grubriscv64.efi
@ 2020-07-30 20:19 ` Heinrich Schuchardt
0 siblings, 0 replies; 12+ messages in thread
From: Heinrich Schuchardt @ 2020-07-30 20:19 UTC (permalink / raw)
To: Atish Patra
Cc: Sean Anderson, Leif Lindholm, Alexander Graf,
U-Boot Mailing List, Rick Chen, Daniel Kiper, GRUB mailing list,
Ard Biesheuvel
Am 30. Juli 2020 22:11:39 MESZ schrieb Heinrich Schuchardt <xypron.glpk@gmx.de>:
>Am 30. Juli 2020 20:31:47 MESZ schrieb Atish Patra
><atishp@atishpatra.org>:
>>On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt
>><xypron.glpk@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
^ permalink raw reply [flat|nested] 12+ messages in thread
* efi_loader/RISC-V: misaligned load when running grubriscv64.efi
2020-07-30 20:19 ` Heinrich Schuchardt
@ 2020-07-30 21:10 ` Atish Patra
-1 siblings, 0 replies; 12+ messages in thread
From: Atish Patra @ 2020-07-30 21:10 UTC (permalink / raw)
To: u-boot
On Thu, Jul 30, 2020 at 1:19 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> Am 30. Juli 2020 22:11:39 MESZ schrieb Heinrich Schuchardt <xypron.glpk@gmx.de>:
> >Am 30. Juli 2020 20:31:47 MESZ schrieb Atish Patra
> ><atishp@atishpatra.org>:
> >>On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt
> >><xypron.glpk@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.
> >
Yeah. For U-Boot UEFI subsystem verification kendryte is a good choice.
But we shouldn't try to boot Linux via grub on that platform :)
> >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?
>
Usually, OpenSBI firmware size is around ~100 KB.
> 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
>
--
Regards,
Atish
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi_loader/RISC-V: misaligned load when running grubriscv64.efi
@ 2020-07-30 21:10 ` Atish Patra
0 siblings, 0 replies; 12+ messages in thread
From: Atish Patra @ 2020-07-30 21:10 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Sean Anderson, Leif Lindholm, Alexander Graf,
U-Boot Mailing List, Rick Chen, Daniel Kiper, GRUB mailing list,
Ard Biesheuvel
On Thu, Jul 30, 2020 at 1:19 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> Am 30. Juli 2020 22:11:39 MESZ schrieb Heinrich Schuchardt <xypron.glpk@gmx.de>:
> >Am 30. Juli 2020 20:31:47 MESZ schrieb Atish Patra
> ><atishp@atishpatra.org>:
> >>On Thu, Jul 30, 2020 at 4:04 AM Heinrich Schuchardt
> >><xypron.glpk@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.
> >
Yeah. For U-Boot UEFI subsystem verification kendryte is a good choice.
But we shouldn't try to boot Linux via grub on that platform :)
> >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?
>
Usually, OpenSBI firmware size is around ~100 KB.
> 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
>
--
Regards,
Atish
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-07-30 21:10 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-30 10:03 efi_loader/RISC-V: misaligned load when running grubriscv64.efi Heinrich Schuchardt
2020-07-30 10:16 ` Sean Anderson
2020-07-30 11:04 ` Heinrich Schuchardt
2020-07-30 11:04 ` Heinrich Schuchardt
2020-07-30 18:31 ` Atish Patra
2020-07-30 18:31 ` Atish Patra
2020-07-30 20:11 ` Heinrich Schuchardt
2020-07-30 20:11 ` Heinrich Schuchardt
2020-07-30 20:19 ` Heinrich Schuchardt
2020-07-30 20:19 ` Heinrich Schuchardt
2020-07-30 21:10 ` Atish Patra
2020-07-30 21:10 ` Atish Patra
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.