grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB loader support for RISC-V Linux


From: Nikita Ermakov
Subject: Re: GRUB loader support for RISC-V Linux
Date: Wed, 19 May 2021 18:26:42 +0300

Hi!

I'm sorry for such a long delay.
I rebased Ard's patches to the current master branch and then rebased
Atish's patches on top of the Ard's patches. It almost worked, except
that load_file2 and device_path GUIDs were allocated on a stack and
therefore were overridden outside of the function scope. This [1]
commit fixes that.
The branch with the work could be found here [2].

I prepared a QEMU image with this GRUB for demonstration.
The QEMU image could be found here [3] (SHA1:
911270c583248c656b9a105910344b96e8c6ad02).
The default password for root is:
Login: root
Password: alt

For convenience one could use the OpenSBI+U-Boot payload for QEMU from
this RPM package [4].
$ rpm2cpio opensbi-firmware-generic-0.9-alt1.noarch.rpm | cpio -idv
./usr/share/opensbi/generic/firmware/fw_payload.bin
$ qemu-system-riscv64 -nographic -machine virt -bios
./usr/share/opensbi/generic/firmware/fw_payload.bin -m 2G -smp cpus=4
-drive file=regular-jeos-systemd-alpha20210519-riscv64.qcow2c,id=hd0
-device virtio-blk-device,drive=hd0 -netdev
user,id=eth0,hostfwd=tcp::6660-:22 -device
virtio-net-device,netdev=eth0

A little snippet from the Linux kernel booting:

Loading Linux vmlinuz ...
Loading initial ramdisk ...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services and installing virtual address map...
[    0.000000] Linux version 5.11.8-un-def-alt1.rv64
(builder@localhost.localdomain) (gcc-9 (GCC) 9.2.1 20190827 (ALT
9.2.1-alt3), GNU ld (GNU Binutils) 2.31.1.20181202) #1 SMP Thu Apr 8
12:07:41 UTC 2021
[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] efi: EFI v2.80 by Das U-Boot
[    0.000000] efi: RTPROP=0xfe72f020 SMBIOS=0xfe72b000 MEMRESERVE=0xdcb31020
[    0.000000] OF: fdt: Ignoring memory block 0x80000000 - 0x80020000
[    0.000000] OF: fdt: Ignoring memory range 0x80020000 - 0x80200000
[    0.000000] Initial ramdisk at: 0x(____ptrval____) (4009984 bytes)


[1] 
http://git.altlinux.org/people/arei/public/grub.git?p=grub.git;a=commit;h=cd03f6d285c91d39b819fe635c592602265ef6ce
[2] 
http://git.altlinux.org/people/arei/public/grub.git?p=grub.git;a=shortlog;h=refs/heads/wip-efi
[3] 
http://ftp.altlinux.org/pub/people/arei/images/grub-efi/regular-jeos-systemd-alpha20210519-riscv64.qcow2c
[4] 
http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/riscv64/Sisyphus/noarch/RPMS.classic/opensbi-firmware-generic-0.9-alt1.noarch.rpm

On Sat, 10 Apr 2021 at 11:18, Nikita Ermakov <arei@altlinux.org> wrote:
>
> Hei,
>
> On Thu, 8 Apr 2021 at 18:26, Daniel Kiper <dkiper@net-space.pl> wrote:
> >
> > Hey,
> >
> > On Wed, Apr 07, 2021 at 06:48:54PM +0300, Nikita Ermakov wrote:
> > > Hi Atish,
> > >
> > > Thank you for the answer.
> > >
> > > On Sun, 4 Apr 2021 at 18:42, Atish Patra <Atish.Patra@wdc.com> wrote:
> > > > Hi Nikita,
> > > > Yes. It was discussed earlier that we should consolidate riscv &
> > > > ARM64 implementation as the ARM64 has a very generic implementation.
> > > > RISC-V should also use LOAD_FILE2 always.
> >
> > I was going to ask about it at some point. So, I am happy that you
> > brought this up guys.
> >
> > > > However, I couldn’t get time to revise the patches. I am on leave
> > > > until May. Is it possible to revise your patch series based on above
> > > > suggestions ? You can takeover my patches if you want or just start
> > > > from the scratch.
> > >
> > > Yes, I will try to implement these suggestions.
> >
> > May I ask you to take a look at [1] too? This patch set waits for review
> > but I think it is good starting point. Or at least reference point...
> >
> Sure!
>
> > Daniel
> >
> > [1] https://lists.gnu.org/archive/html/grub-devel/2020-10/msg00124.html
>

--
Thanks,
Nikita
B8 00 4C CD 21



reply via email to

[Prev in Thread] Current Thread [Next in Thread]