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

[Chester Lin]

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?

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.

Thanks for your patience,
Chester