Re: [PATCH 0/2] Implement a grub loader for RISC-V LINUX

[Atish Patra]

On Fri, 2020-01-17 at 03:20 +0000, Chester Lin wrote:
> Hi Alex, Atish and Anup,
> 
> On Thu, Jan 16, 2020 at 02:27:55PM +0100, Alexander Graf wrote:
> > On 16.01.20 14:14, Atish Patra wrote:
> > > Sent from my iPhone
> > > 
> > > > On Jan 16, 2020, at 10:06 PM, Alexander Graf <address@hidden>
> > > > wrote:
> > > > 
> > > > Hi Chester,
> > > > 
> > > > > On 16.01.20 11:21, Chester Lin wrote:
> > > > > Implement an initial version of riscv loader and related
> > > > > commands to load
> > > > > and run linux kernel and initrd on RISC-V. I tested this
> > > > > series based on
> > > > > the following configuration:
> > > > > 
> > > > >    - QEMU 4.2.50 (machine: virt)
> > > > >    - OpenSBI v0.5-51
> > > > >    - U-Boot 2020.01-rc5
> > > > >    - grub 2.04
> > > > >    - linux-kernel v5.4
> > > > >    - openSUSE-Tumbleweed-20191103
> > > > 
> > > > Thanks a lot for tackling this problem - it's been on the back
> > > > burner for way too long :). Unfortunately this patch set loads
> > > > grub via UEFI, but then does not execute Linux using the UEFI
> > > > protocol. While that's a nice hack for starters, it severely
> > > > limits the extensibility of the boot flow going forward.
> > > > 
> > > > IIRC either Anup or Atish wanted to work on a UEFI boot stub
> > > > for Linux. We could then just unify the ARM and RISC-V UEFI
> > > > boot paths in grub and use that common code to run Linux via
> > > > the UEFI stub.
> > > > 
> > > > 
> > > Yes. I am working on it. In fact, I got Linux kernel booting via
> > > bootefi command last week. I have tried to use as much as ARM
> > > stub code possible which will help in unifying them in future.
> > > 
> > > I am yet to add UEFI run time services. But I was thinking to
> > > post a RFC series with EFI stub code first and work on run time
> > > services after that. Let me know if you think that’s not a good
> > > idea.
> > 
> > I think that's a great idea. It will also unblock any work to move
> > this
> > patch to boot using the UEFI protocol.
> > 
> > 
> > Alex
> > 
> 
> It's a huge progress! thank you for letting me know about this great
> news. BTW,
> it seems that u-boot uses a specific approach to unblock non-boot
> harts which are
> looped by the wfi command. I wonder if we have any plan to move this
> operation
> to the OS side? For example, let non-boot harts keep waiting until
> linux kernel
> unblocks them. It seems that HSM (Hart State Managment Extension) is
> still under
> development, would we rely on this extension to implement CPU
> online/offline
> functions for RISC-V?
> 

Yes. I am currently working on HSM extension in Linux. OpenSBI
implementation is done.


> I raise this question because I think it could be complicated for
> grub to manage
> non-boot harts which are blocked in u-boot stage if no general data
> structure or
> boottime service provided by the previous bootloader [e.g, u-boot or
> UEFI FW].
> Otherwise the efi-call start_image should specifically handle it but
> that also
> means UEFI or other kinds of bootloader must follow it as well.
> 

With HSM, single core will boot all the way to Linux and bring up all
the other harts via hsm calls from OpenSBI. There will be only single
hart available in U-Boot during booting. As a result, grub won't need
to manage non-boot harts.

My current plan is to send HSM patches first and send EFI stub patches
once I test them on top of HSM series to boot all the harts.

> Thanks for your patience,
> Chester

-- 
Regards,
Atish