On Wed, 2020-06-03 at 12:16 -0400, Jonathan Behrens wrote:

Is a specification for bootloader behavior considered in scope for
the platform spec? Describing the initial register state and boot
address alignment suggests that it is, but there's also more that
goes into a modern bootloader than just that. Is the idea that what
we're defining would be used to load GRUB or similar, and that
bootloader would chainload the actual OS using a more sophisticated
interface (like say Multiboot2)? Relatedly, where would UEFI fit into
all of this?

For boot loader behavior specification, the plan is to follow EBBR for
embedded devices. Currently, there are ongoing efforts to support UEFI
in Linux kernel and EDK2 for RISC-V. Once, all the changes are
available, RISC-V will be EBBR compliant.

We just need to modify EBBR to make generic embedded boot requirement
specification rather than an ARM specific one.

It is much more complicated for server class platforms and needs a lot
more attention.

Jonathan

On Wed, Jun 3, 2020 at 2:27 AM Andrew Waterman via lists.riscv.org <
andrew=sifive.com@...> wrote:

On Tue, Jun 2, 2020 at 8:36 PM Greg Favor <gfavor@...>
wrote:

On Tue, Jun 2, 2020 at 7:46 PM Andrew Waterman <andrew@...

wrote:
Since standard binary distributions don’t cope well with
extensions being rolled out at a rapid clip, my thinking is
that we should batch extensions together and roll them out
periodically, say, every couple years. Hopefully this makes it
easier for HW vendors to chart their roadmaps, too.

I completely agree. So maybe the initial "level 1" platform spec
is just RV64GC. We would have liked to have the basic Zb*
extensions included, but if the train has left the station for
current standard binary Linux distros, then oh well (sadly).

It left the station a couple years ago, so don’t feel like you
barely missed it.

Btw, are there really "standard" binary Linux distros for RISC-V
currently available?

I’ve only personally used Debian, but that’s a “yes”.

One last thought and observation: Since this platform spec
probably won't be finalized for a while (although I am all for
sooner the better), it seems like Level 1 will be lagging the
ecosystem and not until Level 2 will the platform spec provide
leadership to the hardware and software ecosystem.

I would separate ABI from platform here. User-visible ISA features
are a heavier lift, since they affect orders of magnitude more
software. I imagine there’s more flexibility on the user-invisible
stuff, as long as the changes can be masked with device drivers,
SBI stuff, etc.

This is like what happened with ARM SBSA - where Level 0
reflected the state of early / legacy systems and then it wasn't
until Level 1 that SBSA provided some leadership to where the
hardware and software ecosystem should be heading towards. Both
levels were defined pretty much concurrently.

The point maybe is just that we should work to lay down a next
level spec fairly soon behind establishment of the first level
spec.

Yeah.

Greg

--
Regards,
Atish