Hi All,
As per our discussion during the Platform HSC meeting today, I have
scheduled an additional meeting Mon Oct 25th 2021 at 8AM PST.

The topics for this additional meeting are
1. Whether M-mode features should be included in the Platform Spec?
2. Any others?

Meeting info
Zoom meeting: https://zoom.us/j/2786028446
Passcode: 901897

Or iPhone one-tap :
US: +16465588656,,2786028466# or +16699006833,,2786028466# Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 278 602 8446
International numbers available:
https://zoom.us/zoomconference?m=_R0jyyScMETN7-xDLLRkUFxRAP07A-_

Regards
Kumar

The question of "whether M-mode features should be included in the Platform Spec" is a reasonable one.  However, it probably makes sense to take the conversation up to a higher level first, to see if we can align on what the intended goals of the (OS-A) platform specification should be.  It's pretty clear from the meeting today that different participants have different points of view.

To me the goal of the OS-A platform specification, at this point in time, is to support commercial Linux distribution vendor operating systems, like RHEL, SuSE, etc.  These requirements seem likely to be more restrictive that what the non-commercial Linux/BSD distribution vendors would require, so it could be possible to support both of these groups by defining the goal of the specification this way.  This is not meant to foreclose work towards any unrelated goals such as facilitating a PC-like BIOS commercial ecosystem via an M-mode common PC platform specification, or defining an Android platform specification, or whatever else the marketplace deems useful.  It's just meant to focus our efforts on what should be relatively low-hanging fruit by constraining the scope of the specification.  Any other platform specifications can be developed separately from a specification targeting the OS distributions.

From this point of view, the key question to me becomes, "Should commercial Linux vendors care about what's going on in M-mode, as long as the interface between M-mode and the S-mode operating system is well-defined?"  

Once we can align on a common goal, I'd submit that our challenge then becomes to get the right stakeholders together in a RISC-V forum (rather than private vendor meetings) to talk through their requirements, and to translate them into something useful.  If folks think that the system OEMs then need their own M-mode and hardware platform specification, folks can bring them to the platform specification table and try to hammer out something that's useful for them.  But that shouldn't affect nor block the platform specification that is intended to apply to commercial Linux distribution vendors.

- Paul

But the current question applies to the OS-A Base platform and the question of how much flexibility it should provide for the sake of providing a broader umbrella over what types of systems can claim compliance.  The answer to that tension will be different for a "Base" platform versus more targeted platforms (e.g. HPC, automotive, mobile, server, ...).

The OS-A specification in its current form is not suitable as a base specification for many verticals.  For example, most likely Android integrators won't care at all about ACPI or PCIe.

- Paul

On 10/18/21 22:53, Paul Walmsley wrote:

The question of "whether M-mode features should be included in the Platform Spec" is a reasonable one.  However, it probably makes sense to take the conversation up to a higher level first, to see if we can align on what the intended goals of the (OS-A) platform specification should be.  It's pretty clear from the meeting today that different participants have different points of view.
To me the goal of the OS-A platform specification, at this point in time, is to support commercial Linux distribution vendor operating systems, like RHEL, SuSE, etc.  These requirements seem likely to be more restrictive that what the non-commercial Linux/BSD distribution vendors would require, so it could be possible to support both of these groups by defining the goal of the specification this way.  This is not meant to foreclose work towards any unrelated goals such as facilitating a PC-like BIOS commercial ecosystem via an M-mode common PC platform specification, or defining an Android platform specification, or whatever else the marketplace deems useful.  It's just meant to focus our efforts on what should be relatively low-hanging fruit by constraining the scope of the specification.  Any other platform specifications can be developed separately from a specification targeting the OS distributions.
From this point of view, the key question to me becomes, "Should commercial Linux vendors care about what's going on in M-mode, as long as the interface between M-mode and the S-mode operating system is well-defined?"

Your question can be boiled down to: Who provides the M-mode firmware?

Currently RISC-V boards like the Nezha D1 and the SiFive HiFive Unmatched come with an SD-card image that contains OpenSBI, U-Boot and the operating system.

Here are examples of OpenSBI packages provided by major Linux distributions:

https://packages.debian.org/sid/opensbi
https://launchpad.net/ubuntu/+source/opensbi
https://build.opensuse.org/package/show/hardware:boot/opensbi
http://riscv.rocks/koji/buildinfo?buildID=195824

The same situation is known in the ARM world. For many boards you have to supply the EL3 firmware and the UEFI firmware with the operating system.

So yes, the Linux distributions care about what is going on in M-mode. I do not expect this situation to change for IoT class devices.

The situation may be different for server grade platforms where I would expect the platform vendors to provide EDK II or equivalent firmware with the hardware.

Best regards

Heinrich

Once we can align on a common goal, I'd submit that our challenge then becomes to get the right stakeholders together in a RISC-V forum (rather than private vendor meetings) to talk through their requirements, and to translate them into something useful.  If folks think that the system OEMs then need their own M-mode and hardware platform specification, folks can bring them to the platform specification table and try to hammer out something that's useful for them.  But that shouldn't affect nor block the platform specification that is intended to apply to commercial Linux distribution vendors.
- Paul
On 10/18/21 12:05 PM, Kumar Sankaran wrote:

Hi All,
As per our discussion during the Platform HSC meeting today, I have
scheduled an additional meeting Mon Oct 25th 2021 at 8AM PST.

The topics for this additional meeting are
1. Whether M-mode features should be included in the Platform Spec?
2. Any others?

Meeting info
Zoom meeting:https://zoom.us/j/2786028446
Passcode: 901897

Or iPhone one-tap :
US: +16465588656,,2786028466# or +16699006833,,2786028466# Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 278 602 8446
International numbers available:
https://zoom.us/zoomconference?m=_R0jyyScMETN7-xDLLRkUFxRAP07A-_

Regards
Kumar

On 10/18/21 23:37, Paul Walmsley wrote:

On 10/18/21 12:59 PM, Greg Favor wrote:

But the current question applies to the OS-A Base platform and the question of how much flexibility it should provide for the sake of providing a broader umbrella over what types of systems can claim compliance.  The answer to that tension will be different for a "Base" platform versus more targeted platforms (e.g. HPC, automotive, mobile, server, ...).

The OS-A specification in its current form is not suitable as a base specification for many verticals.  For example, most likely Android integrators won't care at all about ACPI or PCIe.

ACPI and PCIe are not required in the main OS-A profile but in the server extension.

Best regards

Heinrich

On 10/18/21 22:53, Paul Walmsley wrote:

The question of "whether M-mode features should be included in the Platform Spec" is a reasonable one.  However, it probably makes sense to take the conversation up to a higher level first, to see if we can align on what the intended goals of the (OS-A) platform specification should be.  It's pretty clear from the meeting today that different participants have different points of view.


To me the goal of the OS-A platform specification, at this point in time, is to support commercial Linux distribution vendor operating systems, like RHEL, SuSE, etc.  These requirements seem likely to be more restrictive that what the non-commercial Linux/BSD distribution vendors would require, so it could be possible to support both of these groups by defining the goal of the specification this way.  This is not meant to foreclose work towards any unrelated goals such as facilitating a PC-like BIOS commercial ecosystem via an M-mode common PC platform specification, or defining an Android platform specification, or whatever else the marketplace deems useful.  It's just meant to focus our efforts on what should be relatively low-hanging fruit by constraining the scope of the specification.  Any other platform specifications can be developed separately from a specification targeting the OS distributions.


 From this point of view, the key question to me becomes, "Should commercial Linux vendors care about what's going on in M-mode, as long as the interface between M-mode and the S-mode operating system is well-defined?"

Your question can be boiled down to: Who provides the M-mode firmware?

I would agree that this is a corollary to my original question ;-)

Currently RISC-V boards like the Nezha D1 and the SiFive HiFive Unmatched come with an SD-card image that contains OpenSBI, U-Boot and the operating system.

Here are examples of OpenSBI packages provided by major Linux distributions:

https://packages.debian.org/sid/opensbi
https://launchpad.net/ubuntu/+source/opensbi
https://build.opensuse.org/package/show/hardware:boot/opensbi
http://riscv.rocks/koji/buildinfo?buildID=195824

The same situation is known in the ARM world. For many boards you have to supply the EL3 firmware and the UEFI firmware with the operating system.

Ironically, with the Unmatched board, we at SiFive seriously considered putting OpenSBI and U-Boot on the onboard SPI flash.  That way, only a rootfs would need to go onto the SD card.  We've had Linux distribution folks insist that this was the right way to go, because the distributions didn't want to deal with the randomness of the low-level platform interface.  Ultimately we felt that since the "firmware" part of the stack was still in a high level of flux, it was easier to support a situation where everything was on the SD card -- even though we had to disappoint some distribution folks in doing so.  Probably most development boards will always have such an option, to load the entire "firmware" stack from removable media.

So yes, the Linux distributions care about what is going on in M-mode. I do not expect this situation to change for IoT class devices.

Linux distributions on x86 devices, IoT or otherwise, don't expect to replace the BIOS or FSP.  Historically many ARM devices haven't supported bootloader replacements (i.e., the bootloader is locked).  I personally appreciate having the freedom to do so myself.   But I am not sure that this should be incorporated as a requirement into a platform specification that is intended to span a broad range of use cases.

- Paul