RE: 5.2-rc1 boot on Unleashed

[Anup Patel <Anup.Patel@wdc.com>]

> -----Original Message-----
> From: linux-riscv <linux-riscv-bounces@lists.infradead.org> On Behalf Of
> Troy Benjegerdes
> Sent: Saturday, May 25, 2019 7:46 PM
> To: Anup Patel <anup@brainfault.org>
> Cc: Palmer Dabbelt <palmer@sifive.com>; Björn Töpel
> <bjorn.topel@gmail.com>; Anup Patel <Anup.Patel@wdc.com>; Atish Patra
> <Atish.Patra@wdc.com>; Lukas Auer <lukas.auer@aisec.fraunhofer.de>;
> Paul Walmsley <paul.walmsley@sifive.com>; linux-riscv@lists.infradead.org;
> Bin Meng <bmeng.cn@gmail.com>
> Subject: Re: 5.2-rc1 boot on Unleashed
> 
> 
> 
> > On May 25, 2019, at 3:06 AM, Anup Patel <anup@brainfault.org> wrote:
> >
> > Hi Troy,
> >
> > On Thu, May 23, 2019 at 3:45 AM Troy Benjegerdes
> > <troy.benjegerdes@sifive.com> wrote:
> >>
> >>
> >>> On May 22, 2019, at 3:43 PM, Paul Walmsley
> <paul.walmsley@sifive.com> wrote:
> >>>
> >>> + Anup, Troy
> >>>
> >>> On Wed, 22 May 2019, Atish Patra wrote:
> >>>
> >>>> On 5/22/19 9:42 AM, Paul Walmsley wrote:
> >>>>> Am checking on this now and hope to have some conclusion on it this
> week.
> >>>>
> >>>> Thanks. Any chance you can take a look at the U-Boot clock driver
> >>>> to patch it as per the DT changes ?
> >>>
> >>> I probably won't have the chance to get to it for a while.  Looks
> >>> like Anup was the one who posted the clock driver to U-Boot - can he
> >>> take a look at it?
> >>>
> >>> We've also asked Troy to look at upstream U-boot related issues, but
> >>> I'm unsure when patches will start flowing upstream.
> >>>
> >>>
> >>> - Paul
> >>
> >> Once I figure out why I’m getting TX timeouts on the macb driver and
> have something working I can start upstreaming the u-boot patches.
> >>
> >> For now, the work-in-progress is at
> >> https://github.com/sifive/u-boot/tree/sandbox
> >
> > Based on your commits in above GitRepo, it seems you are trying entire
> > U-Boot in M-mode.
> >
> > Current boot-flow of S-mode U-Boot is:
> > ZSBL (M-mode) -> FSBL (M-mode) -> OpenSBI/BBL (M-mode) -> U-Boot
> > (S-mode)
> >
> > The U-Boot SPL can perfectly replace SiFive FSBL to have following
> > boot-flow:
> > ZSBL (M-mode) -> U-Boot SPL (M-mode) -> OpenSBI/BBL (M-mode) -> U-
> Boot
> > (S-mode)
> >
> > Can you explain advantages of using full U-Boot M-mode to replace FSBL
> > as compared to U-Boot SPL M-mode replacing FSBL ?
> >
> > Regards,
> > Anup
> 
> The current flow in Freedom-u-sdk (with
> https://github.com/sifive/HiFive_U-Boot) is this:
> ZSBL (M-mode) -> U-Boot (M-mode) -> BBL -> Linux kernel
> 
> The major driver for full U-Boot M-mode is automated regression testing and
> being able to load the SBI interface (BBL or OpenSBI) and linux kernel via
> TFTP.

This is a very specific use-case. The RISC-V boot flow should be compliant with
major architectures (ARM/ARM64 and x86) so that it's very easy (and boring)
for folks (familiar with these major architectures) to try-out RISC-V.

To achieve this, we need to ensure that users are able to boot kernel Image
and Image.gz without embedding it in OpenSBI/BBL. In fact, we also need to
ensure that users can update SBI runtime (OpenSBI/BBL) and bootloader
(i.e. U-Boot) separately.

If we try to address above requirements then we end-up having U-Boot S-mode
(or any S-mode bootloader) as last stage before kernel and SBI runtime will be
before U-Boot S-mode as separate binary.

Due to above, we have come-up with FW_JUMP and FW_DYNAMIC firmwares
in OpenSBI. These firmwares don't embed Linux kernel or Bootloader binary
and can be loaded separately.

> 
> I do agree U-Boot SPL is a very good idea, I have been working on replicating
> the functionality of the old HiFive U-boot first and then once that works I
> think it will be a lot easier to work out the SPL option.

Yes, U-Boot SPI (M-mode) will be the right way to go and it will fit in lot
of use-cases.

Regards,
Anup
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv