Linux-RISC-V Archive on lore.kernel.org
 help / Atom feed
* SBI extension proposal v2
@ 2018-11-10  2:42 atish.patra
  2018-11-10  2:42 ` Atish Patra
                   ` (3 more replies)
  0 siblings, 4 replies; 67+ messages in thread
From: atish.patra @ 2018-11-10  2:42 UTC (permalink / raw)
  To: linux-riscv

Hi,
I have updated the proposal based on feedback received on previous 
version. This version has a better scalable SBI Function ID
numbering scheme. I have adopted markdown formatting for github docs.

If you prefer a github interface, it's available here as well.

https://github.com/riscv/riscv-sbi-doc/pull/12

Looking forward to your feedback.

Regards,
Atish
------------------------------------------------------------------------

## Introduction:
This is a proposal to make SBI a flexible and extensible interface.
It is based on the foundation policy of RISC-V i.e. modularity and
openness. The proposal tries to introduces very few new mandatory SBI 
Functions, that are absolutely required to maintain backward 
compatibility. Everything else is optional so that it remains an open 
standard yet robust.

The current RISC-V SBI only defines a few mandatory functions such as
inter-processor interrupts (IPI) interface, reprogramming timer, serial
console, and memory barrier instructions. The existing SBI documentation
can be found here [1]. Many important functionalities such as power
management/cpu-hotplug are not yet defined due to difficulties in
accommodating modifications without breaking the backward compatibility
with the current interface.

The proposed design is inspired by Power State Coordination Interface 
(PSCI) from ARM world. However, it adds only two new mandatory SBI calls 
providing version information and supported Functions, unlike PSCI where 
a significant number of functions are mandatory. The version of the 
existing SBI will be defined as a minimum version(0.1) which will always 
be backward compatible. Similarly, any Linux kernel with a newer feature 
will fall back if an older version of SBI does not support the updated 
capabilities. Both the operating system and SEE can be implemented to be 
two way backward compatible.

## SBI Calling Conventions (TODO)
There are some suggestions[3] to distinguish between SBI function return 
value and SBI calling sequence return value. Here are the few possible 
discussed ideas.

1. Return a single value, but values in the range {-511, -1} are 
considered errors, whereas return values in the range {0, 2^XLEN-512} 
are considered success.

2. Every SBI function call may return the following structure
```
struct valerr {
   long value;
   long error;
};
```
According to the RISC-V ABI spec[4], both a0 & a1 registers can be used 
for function return values.

3. Introduce an extra argument that can return error by reference.
```
/* Returns the CPU that was started.
  * @err indicates an error ID if one occurred, otherwise 0.
  * @err can be NULL if no error detection is required.
*/
int start_cpu(int cpu_num,..., Error *err);
```
Both approaches (2 & 3) will work, but there will be two versions of 
existing SBI functions to maintain the compatibility.

## SBI Functions:

A SBI function is an individual feature that SBI interface provides to 
supervisor mode from machine mode. Each function ID is assigned as per 
below section.

#### SBI Function ID numbering scheme:
A Function Set is a group of SBI functions which collectively implement 
similar kind of feature/functionality. The function ID numbering scheme 
need to be scalable in the future. At the same time, function validation 
check should be as quick as possible. Keeping these two requirements in 
mind, a hybrid function ID scheme is proposed.

SBI Function ID is u32 type.

```
31            24                        0
-----------------------------------------
|O|            |                        |
-----------------------------------------
Function Set   | Function Type          |
```
Bit[31]    =  ID overflow bit

Bit[30:24] =  Function Set

Bit[23:0]  =  Function Type within Function Set

The Function set is Bits [31:24] describing both function set number and 
overflow bit. In the beginning, the overflow bit should be set to 
**zero** and the function Type per function set can be assigned by left 
shifting 1 bit at a time. The overflow bit can be set to one **only** 
when we need to allocate more than 24 functions per function set in 
future. Setting the overflow bit will indicate an integer function type 
scheme. Thus, there will more than enough function IDs available to use 
in the future. Refer appendix 1 for examples.

Here are few Function Sets for SBI v0.2:

| Function Set         | Value  | Description 
       |
| -------------------  |:------:| 
:--------------------------------------------|
| Base Functions       | 0x00   | Base Functions mandatory for any SBI 
version |
| HART PM Functions    | 0x01   | Hart UP/Down/Suspend Functions for 
per-Hart power management|
| System PM Functions  | 0x02   | System Shutdown/Reboot/Suspend for 
system-level power management|
| Vendor Functions     | 0x7f   | Vendor specific Functions|

N.B. There is a possibility that different vendors can choose to assign 
the same function numbers for different functionality. That's why vendor 
specific strings in Device Tree/ACPI or any other hardware description 
document can be used to verify if a specific Function belongs to the 
intended vendor or not.

# SBI Function List in both SBI v0.2 and v0.1

|Function Type              | Function Set      | ID(v0.2)     |ID (v0.1)  |
|---------------------------| ------------------|:------------:|:---------:|
| sbi_set_timer             | Base              | 0x00 000000  |0          |
| sbi_console_putchar       | Base              | 0x00 000001  |1          |
| sbi_console_getchar       | Base              | 0x00 000002  |2          |
| sbi_clear_ipi             | Base              | 0x00 000004  |3          |
| sbi_send_ipi              | Base              | 0x00 000008  |4          |
| sbi_remote_fence_i        | Base              | 0x00 000010  |5          |
| sbi_remote_sfence_vma     | Base              | 0x00 000020  |6          |
| sbi_remote_sfence_vma_asid| Base              | 0x00 000040  |7          |
| sbi_shutdown              | System PM         | 0x02 000000  |8          |
| sbi_system_reset          | System PM         | 0x02 000001  |-          |
| sbi_get_version           | Base              | 0x00 000080  |-          |
| sbi_get_function_mask     | Base              | 0x00 000100  |-          |
| sbi_get_function_count    | Base              | 0x00 000200  |-          |
| sbi_hart_up               | Hart PM           | 0x01 000000  |-          |
| sbi_hart_down             | Hart PM           | 0x01 000001  |-          |
| sbi_hart_suspend          | Hart PM           | 0x01 000002  |-          |
| sbi_hart_state            | Hart PM           | 0x01 000004  |-          |

#### Function Description

This section describes every newly introduced(in v0.2) function in 
details. Please refer to [1] for any v0.1 functions.

```
u32 sbi_get_version(void):
```
Returns the current SBI version implemented by the firmware.
version: uint32: Bits[31:16] Major Version
              Bits[15:0] Minor Version

The existing SBI version can be 0.1. The proposed version will be at 0.2
A different major version may indicate possible incompatible functions.
A different minor version must be compatible with each other even if
they have a higher number of features.

```
u32 sbi_get_function_mask(u32 ftype)
```
Given a function set type, it returns a bitmask of all functions IDs 
that are implemented for that function set.

```
u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long count):
```

This is a **reserved** function that should only be used if overflow bit 
in SBI function ID is set.

Accepts a start_Function_id as an argument and returns if 
start_Function_id to (start_Function_id + count - 1) are supported or not.

A count can help in minimizing the number of the M-mode traps by 
checking a range of SBI functions together.

```
int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
long priv)
```
Brings up "hartid" either during initial boot or after a sbi_hart_down
SBI call.

"start" points to a runtime-specified address where a hart can enter
into supervisor mode. This must be a physical address.

"priv" is a private data that caller can use to pass information about
execution context.

Return the appropriate SBI error code.

```
int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
long priv)
```
Suspends the calling hart to a particular power state. Suspended hart
will automatically wake-up based on some wakeup events at resume_entry
physical address.

"priv" is a private data that caller can use to pass information about
execution context. The SBI implementation must save a copy so that
caller can reuse while restoring hart from suspend.

Return the appropriate SBI error code.

```
int sbi_hart_down()
```
It powers off the hart and will be used in cpu-hotplug.
Only individual hart can remove itself from supervisor mode. It can be
moved to normal state only by sbi_hart_up function.

Return the appropriate SBI error code.

```
u32 sbi_hart_state(unsigned long hartid)
```
Returns the RISCV_POWER_STATE for a specific hartid. This will help make
kexec like functionality more robust.

```
void sbi_system_reset(u32 reset_type)
```
Reset the entire system.

## Return error code Table:
Here are the SBI return error codes defined.

| Error Type               | Value  |
| -------------------------|:------:|
|  SBI_ERR_SUCCESS         |  0     |
|  SBI_ERR_FAILURE         | -1     |
|  SBI_ERR_NOT_SUPPORTED   | -2     |
|  SBI_ERR_INVALID_PARAM   | -3     |
|  SBI_ERR_DENIED          | -4     |
|  SBI_ERR_INVALID_ADDRESS | -5     |


## Power State
A RISC-V core can exist in any of the following power states.

| Power states         | Value  | Description 
       |
| ------------------- 
|:------:|:---------------------------------------------|
| RISCV_HART_ON        | 0      | Powered up & operational. 
       |
| RISCV_HART_STANDBY   | 1      | Powered up but at reduced energy <br> 
consumption WFI instruction can be used to achieve this state|
| RISCV_HART_RETENTION | 2      | Deeper low power state. No reset <br> 
required but higher wakeup latency|
| RISCV_HART_OFF       | 3      | Powered off. Reset of the core 
required after power restore|

**_TODO_**:

We probably also need deeper hart power states or system-level power 
state reporting at some point, and non-HART components (caches, memory, 
etc).  Likely aligned with platform specs, once those start to show up.

## Implementation
Currently, SBI is implemented as a part of BBL. There is a different SBI 
implementation available in coreboot as well.

Alternatively, a separate open BSD/MIT licensed SBI project can be 
created that can be used by anybody to avoid this kind of SBI 
fragmentation. This project can generate both a firmware binary (to be 
executed directly in M mode) or a static library that can be used by 
different boot loaders. It will also help individual bootloaders
to either work from M or S mode without a separate SBI implementation.

## Conclusion
This proposal is far from perfect and absolutely any suggestion is 
welcome. Obviously, there are many other functionalities that can be 
added to this proposal. However, I just wanted to start with something 
that is an incremental change at best to kick off the discussion. The 
aim here is to initiate a discussion that can lead to a robust SBI 
specification.

## Reference:

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf

[2] https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.md

[3] https://github.com/riscv/riscv-sbi-doc/pull/9

[4] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md

## Appendix

1. Overflow Reserved bit example.

Let's choose function set type as Hart PM (0x1)

Function1 : 0x01 000001<br>
Function2 : 0x01 000002<br>
Function3 : 0x01 000004<br>
.<br>
.<br>
.<br>
Function24:0x01 800000<br>

At this point in future, Let's say we need more function IDs for Hart 
PM. The scheme can be switched to an integer scheme by setting the 
overflow bit.

Function25: 0x81 000001<br>
Function26: 0x81 000002<br>
Function27: 0x81 000003<br>
Function28: 0x81 000004<br>
.<br>
.<br>
Function34: 0x81 00000A<br>
.<br>

^ permalink raw reply	[flat|nested] 67+ messages in thread

* SBI extension proposal v2
  2018-11-10  2:42 SBI extension proposal v2 atish.patra
@ 2018-11-10  2:42 ` Atish Patra
  2018-11-10  5:12 ` [sw-dev] " lkcl
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 67+ messages in thread
From: Atish Patra @ 2018-11-10  2:42 UTC (permalink / raw)
  To: sw-dev, linux-riscv
  Cc: mark.rutland, Christoph Hellwig, Damien Le Moal, olof.johansson,
	alankao, abner.chang, anup, Palmer Dabbelt, Alexander Graf,
	Zong Li, Alistair Francis, paul.walmsley, Nick Kossifidis,
	andrew

Hi,
I have updated the proposal based on feedback received on previous 
version. This version has a better scalable SBI Function ID
numbering scheme. I have adopted markdown formatting for github docs.

If you prefer a github interface, it's available here as well.

https://github.com/riscv/riscv-sbi-doc/pull/12

Looking forward to your feedback.

Regards,
Atish
------------------------------------------------------------------------

## Introduction:
This is a proposal to make SBI a flexible and extensible interface.
It is based on the foundation policy of RISC-V i.e. modularity and
openness. The proposal tries to introduces very few new mandatory SBI 
Functions, that are absolutely required to maintain backward 
compatibility. Everything else is optional so that it remains an open 
standard yet robust.

The current RISC-V SBI only defines a few mandatory functions such as
inter-processor interrupts (IPI) interface, reprogramming timer, serial
console, and memory barrier instructions. The existing SBI documentation
can be found here [1]. Many important functionalities such as power
management/cpu-hotplug are not yet defined due to difficulties in
accommodating modifications without breaking the backward compatibility
with the current interface.

The proposed design is inspired by Power State Coordination Interface 
(PSCI) from ARM world. However, it adds only two new mandatory SBI calls 
providing version information and supported Functions, unlike PSCI where 
a significant number of functions are mandatory. The version of the 
existing SBI will be defined as a minimum version(0.1) which will always 
be backward compatible. Similarly, any Linux kernel with a newer feature 
will fall back if an older version of SBI does not support the updated 
capabilities. Both the operating system and SEE can be implemented to be 
two way backward compatible.

## SBI Calling Conventions (TODO)
There are some suggestions[3] to distinguish between SBI function return 
value and SBI calling sequence return value. Here are the few possible 
discussed ideas.

1. Return a single value, but values in the range {-511, -1} are 
considered errors, whereas return values in the range {0, 2^XLEN-512} 
are considered success.

2. Every SBI function call may return the following structure
```
struct valerr {
   long value;
   long error;
};
```
According to the RISC-V ABI spec[4], both a0 & a1 registers can be used 
for function return values.

3. Introduce an extra argument that can return error by reference.
```
/* Returns the CPU that was started.
  * @err indicates an error ID if one occurred, otherwise 0.
  * @err can be NULL if no error detection is required.
*/
int start_cpu(int cpu_num,..., Error *err);
```
Both approaches (2 & 3) will work, but there will be two versions of 
existing SBI functions to maintain the compatibility.

## SBI Functions:

A SBI function is an individual feature that SBI interface provides to 
supervisor mode from machine mode. Each function ID is assigned as per 
below section.

#### SBI Function ID numbering scheme:
A Function Set is a group of SBI functions which collectively implement 
similar kind of feature/functionality. The function ID numbering scheme 
need to be scalable in the future. At the same time, function validation 
check should be as quick as possible. Keeping these two requirements in 
mind, a hybrid function ID scheme is proposed.

SBI Function ID is u32 type.

```
31            24                        0
-----------------------------------------
|O|            |                        |
-----------------------------------------
Function Set   | Function Type          |
```
Bit[31]    =  ID overflow bit

Bit[30:24] =  Function Set

Bit[23:0]  =  Function Type within Function Set

The Function set is Bits [31:24] describing both function set number and 
overflow bit. In the beginning, the overflow bit should be set to 
**zero** and the function Type per function set can be assigned by left 
shifting 1 bit at a time. The overflow bit can be set to one **only** 
when we need to allocate more than 24 functions per function set in 
future. Setting the overflow bit will indicate an integer function type 
scheme. Thus, there will more than enough function IDs available to use 
in the future. Refer appendix 1 for examples.

Here are few Function Sets for SBI v0.2:

| Function Set         | Value  | Description 
       |
| -------------------  |:------:| 
:--------------------------------------------|
| Base Functions       | 0x00   | Base Functions mandatory for any SBI 
version |
| HART PM Functions    | 0x01   | Hart UP/Down/Suspend Functions for 
per-Hart power management|
| System PM Functions  | 0x02   | System Shutdown/Reboot/Suspend for 
system-level power management|
| Vendor Functions     | 0x7f   | Vendor specific Functions|

N.B. There is a possibility that different vendors can choose to assign 
the same function numbers for different functionality. That's why vendor 
specific strings in Device Tree/ACPI or any other hardware description 
document can be used to verify if a specific Function belongs to the 
intended vendor or not.

# SBI Function List in both SBI v0.2 and v0.1

|Function Type              | Function Set      | ID(v0.2)     |ID (v0.1)  |
|---------------------------| ------------------|:------------:|:---------:|
| sbi_set_timer             | Base              | 0x00 000000  |0          |
| sbi_console_putchar       | Base              | 0x00 000001  |1          |
| sbi_console_getchar       | Base              | 0x00 000002  |2          |
| sbi_clear_ipi             | Base              | 0x00 000004  |3          |
| sbi_send_ipi              | Base              | 0x00 000008  |4          |
| sbi_remote_fence_i        | Base              | 0x00 000010  |5          |
| sbi_remote_sfence_vma     | Base              | 0x00 000020  |6          |
| sbi_remote_sfence_vma_asid| Base              | 0x00 000040  |7          |
| sbi_shutdown              | System PM         | 0x02 000000  |8          |
| sbi_system_reset          | System PM         | 0x02 000001  |-          |
| sbi_get_version           | Base              | 0x00 000080  |-          |
| sbi_get_function_mask     | Base              | 0x00 000100  |-          |
| sbi_get_function_count    | Base              | 0x00 000200  |-          |
| sbi_hart_up               | Hart PM           | 0x01 000000  |-          |
| sbi_hart_down             | Hart PM           | 0x01 000001  |-          |
| sbi_hart_suspend          | Hart PM           | 0x01 000002  |-          |
| sbi_hart_state            | Hart PM           | 0x01 000004  |-          |

#### Function Description

This section describes every newly introduced(in v0.2) function in 
details. Please refer to [1] for any v0.1 functions.

```
u32 sbi_get_version(void):
```
Returns the current SBI version implemented by the firmware.
version: uint32: Bits[31:16] Major Version
              Bits[15:0] Minor Version

The existing SBI version can be 0.1. The proposed version will be at 0.2
A different major version may indicate possible incompatible functions.
A different minor version must be compatible with each other even if
they have a higher number of features.

```
u32 sbi_get_function_mask(u32 ftype)
```
Given a function set type, it returns a bitmask of all functions IDs 
that are implemented for that function set.

```
u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long count):
```

This is a **reserved** function that should only be used if overflow bit 
in SBI function ID is set.

Accepts a start_Function_id as an argument and returns if 
start_Function_id to (start_Function_id + count - 1) are supported or not.

A count can help in minimizing the number of the M-mode traps by 
checking a range of SBI functions together.

```
int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
long priv)
```
Brings up "hartid" either during initial boot or after a sbi_hart_down
SBI call.

"start" points to a runtime-specified address where a hart can enter
into supervisor mode. This must be a physical address.

"priv" is a private data that caller can use to pass information about
execution context.

Return the appropriate SBI error code.

```
int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
long priv)
```
Suspends the calling hart to a particular power state. Suspended hart
will automatically wake-up based on some wakeup events at resume_entry
physical address.

"priv" is a private data that caller can use to pass information about
execution context. The SBI implementation must save a copy so that
caller can reuse while restoring hart from suspend.

Return the appropriate SBI error code.

```
int sbi_hart_down()
```
It powers off the hart and will be used in cpu-hotplug.
Only individual hart can remove itself from supervisor mode. It can be
moved to normal state only by sbi_hart_up function.

Return the appropriate SBI error code.

```
u32 sbi_hart_state(unsigned long hartid)
```
Returns the RISCV_POWER_STATE for a specific hartid. This will help make
kexec like functionality more robust.

```
void sbi_system_reset(u32 reset_type)
```
Reset the entire system.

## Return error code Table:
Here are the SBI return error codes defined.

| Error Type               | Value  |
| -------------------------|:------:|
|  SBI_ERR_SUCCESS         |  0     |
|  SBI_ERR_FAILURE         | -1     |
|  SBI_ERR_NOT_SUPPORTED   | -2     |
|  SBI_ERR_INVALID_PARAM   | -3     |
|  SBI_ERR_DENIED          | -4     |
|  SBI_ERR_INVALID_ADDRESS | -5     |


## Power State
A RISC-V core can exist in any of the following power states.

| Power states         | Value  | Description 
       |
| ------------------- 
|:------:|:---------------------------------------------|
| RISCV_HART_ON        | 0      | Powered up & operational. 
       |
| RISCV_HART_STANDBY   | 1      | Powered up but at reduced energy <br> 
consumption WFI instruction can be used to achieve this state|
| RISCV_HART_RETENTION | 2      | Deeper low power state. No reset <br> 
required but higher wakeup latency|
| RISCV_HART_OFF       | 3      | Powered off. Reset of the core 
required after power restore|

**_TODO_**:

We probably also need deeper hart power states or system-level power 
state reporting at some point, and non-HART components (caches, memory, 
etc).  Likely aligned with platform specs, once those start to show up.

## Implementation
Currently, SBI is implemented as a part of BBL. There is a different SBI 
implementation available in coreboot as well.

Alternatively, a separate open BSD/MIT licensed SBI project can be 
created that can be used by anybody to avoid this kind of SBI 
fragmentation. This project can generate both a firmware binary (to be 
executed directly in M mode) or a static library that can be used by 
different boot loaders. It will also help individual bootloaders
to either work from M or S mode without a separate SBI implementation.

## Conclusion
This proposal is far from perfect and absolutely any suggestion is 
welcome. Obviously, there are many other functionalities that can be 
added to this proposal. However, I just wanted to start with something 
that is an incremental change at best to kick off the discussion. The 
aim here is to initiate a discussion that can lead to a robust SBI 
specification.

## Reference:

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf

[2] https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.md

[3] https://github.com/riscv/riscv-sbi-doc/pull/9

[4] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md

## Appendix

1. Overflow Reserved bit example.

Let's choose function set type as Hart PM (0x1)

Function1 : 0x01 000001<br>
Function2 : 0x01 000002<br>
Function3 : 0x01 000004<br>
.<br>
.<br>
.<br>
Function24:0x01 800000<br>

At this point in future, Let's say we need more function IDs for Hart 
PM. The scheme can be switched to an integer scheme by setting the 
overflow bit.

Function25: 0x81 000001<br>
Function26: 0x81 000002<br>
Function27: 0x81 000003<br>
Function28: 0x81 000004<br>
.<br>
.<br>
Function34: 0x81 00000A<br>
.<br>

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10  2:42 SBI extension proposal v2 atish.patra
  2018-11-10  2:42 ` Atish Patra
@ 2018-11-10  5:12 ` " lkcl
  2018-11-10  5:12   ` Luke Kenneth Casson Leighton
  2018-11-10 14:50   ` mick
  2018-11-10  5:36 ` david.abdurachmanov
  2018-11-12  4:33 ` mick
  3 siblings, 2 replies; 67+ messages in thread
From: lkcl @ 2018-11-10  5:12 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com> wrote:

> ## Conclusion
> This proposal is far from perfect and absolutely any suggestion is
> welcome. Obviously, there are many other functionalities that can be
> added to this proposal. However, I just wanted to start with something
> that is an incremental change at best to kick off the discussion. The
> aim here is to initiate a discussion that can lead to a robust SBI
> specification.

 very cool, atish.

 i would very much like to see the optional addition of multiple
serial lines, by adding a getchar and putchar function that takes just
one extra argument: the serial line index.

 there are a lot of different uses to which mult-serial lines may be put:

 * boot message separation from console login
 * boot management separation from other purposes (u-boot/coreboot)
 * virtual /dev/ttyS0-3
 * clean UPS reporting and management
 * remote virtual machine power management (power-on / off)
 * simple bog-standard multiple virtual login consoles
 * separation of debug messages (stdout/stderr) to ease debugging and
development
 * remote and virtual OpenOCD and kernel debugging without disrupting
the main serial console
 * PPP serial links.

this latter is one that i am particularly interested in, as i would
like to be able to boot a full GNU/Linux OS on spike, given the lower
barrier to entry in making modifications and experimenting with spike
than it is with qemu.

 if spike were able, through a multi-serial SBI interface, to have a
PPP serial line, it would be possible to run a root NFS (or other
network block device) without having to sacrifice console access.  it
would be possible to create an initramfs from a lower-capability
system like buildroot, containing PPP, enable it, and pivot-root out
to a full stock GNU/Linux OS such as debian or fedora.

 so there are huge benefits, reducing the development barrier to entry
into RISC-V experimentation and debugging, and opening up a much wider
range of capabilities and possibilities for machine and virtual system
management.

l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10  5:12 ` [sw-dev] " lkcl
@ 2018-11-10  5:12   ` Luke Kenneth Casson Leighton
  2018-11-10 14:50   ` mick
  1 sibling, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-10  5:12 UTC (permalink / raw)
  To: atish.patra
  Cc: mark.rutland, hch, Damien.LeMoal, olof.johansson, alankao,
	abner.chang, Anup Patel, Palmer Dabbelt, agraf, zong,
	Alistair.Francis, paul.walmsley, mick, sw-dev, linux-riscv,
	Andrew Waterman

On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com> wrote:

> ## Conclusion
> This proposal is far from perfect and absolutely any suggestion is
> welcome. Obviously, there are many other functionalities that can be
> added to this proposal. However, I just wanted to start with something
> that is an incremental change at best to kick off the discussion. The
> aim here is to initiate a discussion that can lead to a robust SBI
> specification.

 very cool, atish.

 i would very much like to see the optional addition of multiple
serial lines, by adding a getchar and putchar function that takes just
one extra argument: the serial line index.

 there are a lot of different uses to which mult-serial lines may be put:

 * boot message separation from console login
 * boot management separation from other purposes (u-boot/coreboot)
 * virtual /dev/ttyS0-3
 * clean UPS reporting and management
 * remote virtual machine power management (power-on / off)
 * simple bog-standard multiple virtual login consoles
 * separation of debug messages (stdout/stderr) to ease debugging and
development
 * remote and virtual OpenOCD and kernel debugging without disrupting
the main serial console
 * PPP serial links.

this latter is one that i am particularly interested in, as i would
like to be able to boot a full GNU/Linux OS on spike, given the lower
barrier to entry in making modifications and experimenting with spike
than it is with qemu.

 if spike were able, through a multi-serial SBI interface, to have a
PPP serial line, it would be possible to run a root NFS (or other
network block device) without having to sacrifice console access.  it
would be possible to create an initramfs from a lower-capability
system like buildroot, containing PPP, enable it, and pivot-root out
to a full stock GNU/Linux OS such as debian or fedora.

 so there are huge benefits, reducing the development barrier to entry
into RISC-V experimentation and debugging, and opening up a much wider
range of capabilities and possibilities for machine and virtual system
management.

l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10  2:42 SBI extension proposal v2 atish.patra
  2018-11-10  2:42 ` Atish Patra
  2018-11-10  5:12 ` [sw-dev] " lkcl
@ 2018-11-10  5:36 ` david.abdurachmanov
  2018-11-10  5:36   ` David Abdurachmanov
       [not found]   ` <CA++6G0BTdybjhqaXm9EhAz0HsgpwfozK6OEL7DuzbS48RbEChA@mail.gmail.com>
  2018-11-12  4:33 ` mick
  3 siblings, 2 replies; 67+ messages in thread
From: david.abdurachmanov @ 2018-11-10  5:36 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 3:42 AM Atish Patra <atish.patra@wdc.com> wrote:
>
[..]

> 2. Every SBI function call may return the following structure
> ```
> struct valerr {
>    long value;
>    long error;
> };
> ```

[..]

> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
> long priv)

A small nictpick, but could we have consistent typing/language in the document?
I see you use "long", and even mix "int" and "u32" in a single definition.

If I look into PSCI I see:
```
SMC32 uint32
SMC64 uint64
entry_point_address
```
which leaves less interpretation for my eyes. For example, "long" can be
32-bit or 64-bit long depending on a few things and thus easier to make
mistake interpreting the spec.

I would suggest to use (u)int32/(u)uint64/friends and something
similar to SMC{32,64}
if needed.

david

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10  5:36 ` david.abdurachmanov
@ 2018-11-10  5:36   ` David Abdurachmanov
       [not found]   ` <CA++6G0BTdybjhqaXm9EhAz0HsgpwfozK6OEL7DuzbS48RbEChA@mail.gmail.com>
  1 sibling, 0 replies; 67+ messages in thread
From: David Abdurachmanov @ 2018-11-10  5:36 UTC (permalink / raw)
  To: atish.patra
  Cc: mark.rutland, hch, Damien.LeMoal, olof.johansson, alankao, Chang,
	Abner \(HPS SW/FW Technologist\),
	anup, Palmer Dabbelt, Alexander Graf, zong, Alistair.Francis,
	paul.walmsley, mick, sw-dev, linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 3:42 AM Atish Patra <atish.patra@wdc.com> wrote:
>
[..]

> 2. Every SBI function call may return the following structure
> ```
> struct valerr {
>    long value;
>    long error;
> };
> ```

[..]

> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
> long priv)

A small nictpick, but could we have consistent typing/language in the document?
I see you use "long", and even mix "int" and "u32" in a single definition.

If I look into PSCI I see:
```
SMC32 uint32
SMC64 uint64
entry_point_address
```
which leaves less interpretation for my eyes. For example, "long" can be
32-bit or 64-bit long depending on a few things and thus easier to make
mistake interpreting the spec.

I would suggest to use (u)int32/(u)uint64/friends and something
similar to SMC{32,64}
if needed.

david

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10  5:12 ` [sw-dev] " lkcl
  2018-11-10  5:12   ` Luke Kenneth Casson Leighton
@ 2018-11-10 14:50   ` mick
  2018-11-10 14:50     ` Nick Kossifidis
  2018-11-10 15:48     ` lkcl
  1 sibling, 2 replies; 67+ messages in thread
From: mick @ 2018-11-10 14:50 UTC (permalink / raw)
  To: linux-riscv

???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????:
> On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com> 
> wrote:
> 
>> ## Conclusion
>> This proposal is far from perfect and absolutely any suggestion is
>> welcome. Obviously, there are many other functionalities that can be
>> added to this proposal. However, I just wanted to start with something
>> that is an incremental change at best to kick off the discussion. The
>> aim here is to initiate a discussion that can lead to a robust SBI
>> specification.
> 
>  very cool, atish.
> 
>  i would very much like to see the optional addition of multiple
> serial lines, by adding a getchar and putchar function that takes just
> one extra argument: the serial line index.
> 
>  there are a lot of different uses to which mult-serial lines may be 
> put:
> 
>  * boot message separation from console login
>  * boot management separation from other purposes (u-boot/coreboot)
>  * virtual /dev/ttyS0-3
>  * clean UPS reporting and management
>  * remote virtual machine power management (power-on / off)
>  * simple bog-standard multiple virtual login consoles
>  * separation of debug messages (stdout/stderr) to ease debugging and
> development
>  * remote and virtual OpenOCD and kernel debugging without disrupting
> the main serial console
>  * PPP serial links.
> 
> this latter is one that i am particularly interested in, as i would
> like to be able to boot a full GNU/Linux OS on spike, given the lower
> barrier to entry in making modifications and experimenting with spike
> than it is with qemu.
> 
>  if spike were able, through a multi-serial SBI interface, to have a
> PPP serial line, it would be possible to run a root NFS (or other
> network block device) without having to sacrifice console access.  it
> would be possible to create an initramfs from a lower-capability
> system like buildroot, containing PPP, enable it, and pivot-root out
> to a full stock GNU/Linux OS such as debian or fedora.
> 
>  so there are huge benefits, reducing the development barrier to entry
> into RISC-V experimentation and debugging, and opening up a much wider
> range of capabilities and possibilities for machine and virtual system
> management.
> 
> l.


The current SBI says that console_getchar/console_putchar are for the 
debug
console but on Linux we use them for the main console on earlyprintk. I
think it's misleading and we should at least have an argument to chose
between the main console and an optional debug console, or rename
them to debug_console_getchar/debug_console_putchar and 
main_console_getchar/
main_console_putchar.

However I don't think that argument should be the serial line. Different
vendors may use different serial lines for the main console / debug 
console,
the caller doesn't know which serial line maps to which console, so the 
SBI
should be more abstract and use something like a console id where e.g. 0 
is
main console an 1 is debug.

Regards,
Nick

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 14:50   ` mick
@ 2018-11-10 14:50     ` Nick Kossifidis
  2018-11-10 15:48     ` lkcl
  1 sibling, 0 replies; 67+ messages in thread
From: Nick Kossifidis @ 2018-11-10 14:50 UTC (permalink / raw)
  To: Luke Kenneth Casson Leighton
  Cc: mark.rutland, hch, Damien.LeMoal, olof.johansson, alankao,
	abner.chang, Anup Patel, Palmer Dabbelt, agraf, zong,
	atish.patra, sw-dev, paul.walmsley, mick, Alistair.Francis,
	linux-riscv, Andrew Waterman

Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε:
> On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com> 
> wrote:
> 
>> ## Conclusion
>> This proposal is far from perfect and absolutely any suggestion is
>> welcome. Obviously, there are many other functionalities that can be
>> added to this proposal. However, I just wanted to start with something
>> that is an incremental change at best to kick off the discussion. The
>> aim here is to initiate a discussion that can lead to a robust SBI
>> specification.
> 
>  very cool, atish.
> 
>  i would very much like to see the optional addition of multiple
> serial lines, by adding a getchar and putchar function that takes just
> one extra argument: the serial line index.
> 
>  there are a lot of different uses to which mult-serial lines may be 
> put:
> 
>  * boot message separation from console login
>  * boot management separation from other purposes (u-boot/coreboot)
>  * virtual /dev/ttyS0-3
>  * clean UPS reporting and management
>  * remote virtual machine power management (power-on / off)
>  * simple bog-standard multiple virtual login consoles
>  * separation of debug messages (stdout/stderr) to ease debugging and
> development
>  * remote and virtual OpenOCD and kernel debugging without disrupting
> the main serial console
>  * PPP serial links.
> 
> this latter is one that i am particularly interested in, as i would
> like to be able to boot a full GNU/Linux OS on spike, given the lower
> barrier to entry in making modifications and experimenting with spike
> than it is with qemu.
> 
>  if spike were able, through a multi-serial SBI interface, to have a
> PPP serial line, it would be possible to run a root NFS (or other
> network block device) without having to sacrifice console access.  it
> would be possible to create an initramfs from a lower-capability
> system like buildroot, containing PPP, enable it, and pivot-root out
> to a full stock GNU/Linux OS such as debian or fedora.
> 
>  so there are huge benefits, reducing the development barrier to entry
> into RISC-V experimentation and debugging, and opening up a much wider
> range of capabilities and possibilities for machine and virtual system
> management.
> 
> l.


The current SBI says that console_getchar/console_putchar are for the 
debug
console but on Linux we use them for the main console on earlyprintk. I
think it's misleading and we should at least have an argument to chose
between the main console and an optional debug console, or rename
them to debug_console_getchar/debug_console_putchar and 
main_console_getchar/
main_console_putchar.

However I don't think that argument should be the serial line. Different
vendors may use different serial lines for the main console / debug 
console,
the caller doesn't know which serial line maps to which console, so the 
SBI
should be more abstract and use something like a console id where e.g. 0 
is
main console an 1 is debug.

Regards,
Nick

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
       [not found]   ` <CA++6G0BTdybjhqaXm9EhAz0HsgpwfozK6OEL7DuzbS48RbEChA@mail.gmail.com>
@ 2018-11-10 15:09     ` mick
  2018-11-10 15:09       ` Nick Kossifidis
  0 siblings, 1 reply; 67+ messages in thread
From: mick @ 2018-11-10 15:09 UTC (permalink / raw)
  To: linux-riscv

???? 2018-11-10 07:47, Andrew Waterman ??????:
> On Fri, Nov 9, 2018 at 9:37 PM David Abdurachmanov
> <david.abdurachmanov@gmail.com> wrote:
> 
>> On Sat, Nov 10, 2018 at 3:42 AM Atish Patra <atish.patra@wdc.com>
>> wrote:
>>> 
>> [..]
>> 
>>> 2. Every SBI function call may return the following structure
>>> ```
>>> struct valerr {
>>> long value;
>>> long error;
>>> };
>>> ```
>> 
>> [..]
>> 
>>> int sbi_hart_suspend(u32 state, unsigned long resume_entry,
>> unsigned
>>> long priv)
>> 
>> A small nictpick, but could we have consistent typing/language in
>> the document?
>> I see you use "long", and even mix "int" and "u32" in a single
>> definition.
>> 
>> If I look into PSCI I see:
>> ```
>> SMC32 uint32
>> SMC64 uint64
>> entry_point_address
>> ```
>> which leaves less interpretation for my eyes. For example, "long"
>> can be
>> 32-bit or 64-bit long depending on a few things and thus easier to
>> make
>> mistake interpreting the spec.
>> 
>> I would suggest to use (u)int32/(u)uint64/friends and something
>> similar to SMC{32,64}
>> if needed.
> 
> Note, however, that the same spec is meant to be used for both RV32
> and RV64 systems, so some degree of type parameterization is
> necessary.
> 
>> david

We should definitely use typed integers for clarity but there is no
issue on how the structs will be formatted since the current calling
convention provides a pointer to the struct (so it's type is void*)
and the numbers passed through the SBI are 32bit ints (u32) so they
fit on both 32, 64 and 128bit registers. As long as we stick with
this calling convention of passing pointers and 32bit ints, we
should be fine.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 15:09     ` mick
@ 2018-11-10 15:09       ` Nick Kossifidis
  0 siblings, 0 replies; 67+ messages in thread
From: Nick Kossifidis @ 2018-11-10 15:09 UTC (permalink / raw)
  To: Andrew Waterman
  Cc: mark.rutland, Christoph Hellwig, Damien.LeMoal, Olof Johansson.,
	alankao, Chang, Abner, David Abdurachmanov, Anup Patel,
	Palmer Dabbelt, agraf, Zong Li, atish.patra, sw-dev,
	Paul Walmsley, mick, Alistair.Francis, linux-riscv

Στις 2018-11-10 07:47, Andrew Waterman έγραψε:
> On Fri, Nov 9, 2018 at 9:37 PM David Abdurachmanov
> <david.abdurachmanov@gmail.com> wrote:
> 
>> On Sat, Nov 10, 2018 at 3:42 AM Atish Patra <atish.patra@wdc.com>
>> wrote:
>>> 
>> [..]
>> 
>>> 2. Every SBI function call may return the following structure
>>> ```
>>> struct valerr {
>>> long value;
>>> long error;
>>> };
>>> ```
>> 
>> [..]
>> 
>>> int sbi_hart_suspend(u32 state, unsigned long resume_entry,
>> unsigned
>>> long priv)
>> 
>> A small nictpick, but could we have consistent typing/language in
>> the document?
>> I see you use "long", and even mix "int" and "u32" in a single
>> definition.
>> 
>> If I look into PSCI I see:
>> ```
>> SMC32 uint32
>> SMC64 uint64
>> entry_point_address
>> ```
>> which leaves less interpretation for my eyes. For example, "long"
>> can be
>> 32-bit or 64-bit long depending on a few things and thus easier to
>> make
>> mistake interpreting the spec.
>> 
>> I would suggest to use (u)int32/(u)uint64/friends and something
>> similar to SMC{32,64}
>> if needed.
> 
> Note, however, that the same spec is meant to be used for both RV32
> and RV64 systems, so some degree of type parameterization is
> necessary.
> 
>> david

We should definitely use typed integers for clarity but there is no
issue on how the structs will be formatted since the current calling
convention provides a pointer to the struct (so it's type is void*)
and the numbers passed through the SBI are 32bit ints (u32) so they
fit on both 32, 64 and 128bit registers. As long as we stick with
this calling convention of passing pointers and 32bit ints, we
should be fine.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 14:50   ` mick
  2018-11-10 14:50     ` Nick Kossifidis
@ 2018-11-10 15:48     ` lkcl
  2018-11-10 15:48       ` Luke Kenneth Casson Leighton
                         ` (2 more replies)
  1 sibling, 3 replies; 67+ messages in thread
From: lkcl @ 2018-11-10 15:48 UTC (permalink / raw)
  To: linux-riscv

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> ???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????:
> > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
> > wrote:
> >
> >> ## Conclusion
> >> This proposal is far from perfect and absolutely any suggestion is
> >> welcome. Obviously, there are many other functionalities that can be
> >> added to this proposal. However, I just wanted to start with something
> >> that is an incremental change at best to kick off the discussion. The
> >> aim here is to initiate a discussion that can lead to a robust SBI
> >> specification.
> >
> >  very cool, atish.
> >
> >  i would very much like to see the optional addition of multiple
> > serial lines, by adding a getchar and putchar function that takes just
> > one extra argument: the serial line index.
> >
> >  there are a lot of different uses to which mult-serial lines may be
> > put:
> >
> >  * boot message separation from console login
> >  * boot management separation from other purposes (u-boot/coreboot)
> >  * virtual /dev/ttyS0-3
> >  * clean UPS reporting and management
> >  * remote virtual machine power management (power-on / off)
> >  * simple bog-standard multiple virtual login consoles
> >  * separation of debug messages (stdout/stderr) to ease debugging and
> > development
> >  * remote and virtual OpenOCD and kernel debugging without disrupting
> > the main serial console
> >  * PPP serial links.
> >
> > this latter is one that i am particularly interested in, as i would
> > like to be able to boot a full GNU/Linux OS on spike, given the lower
> > barrier to entry in making modifications and experimenting with spike
> > than it is with qemu.
> >
> >  if spike were able, through a multi-serial SBI interface, to have a
> > PPP serial line, it would be possible to run a root NFS (or other
> > network block device) without having to sacrifice console access.  it
> > would be possible to create an initramfs from a lower-capability
> > system like buildroot, containing PPP, enable it, and pivot-root out
> > to a full stock GNU/Linux OS such as debian or fedora.
> >
> >  so there are huge benefits, reducing the development barrier to entry
> > into RISC-V experimentation and debugging, and opening up a much wider
> > range of capabilities and possibilities for machine and virtual system
> > management.
> >
> > l.
>
>
> The current SBI says that console_getchar/console_putchar are for the
> debug
> console but on Linux we use them for the main console on earlyprintk.

 ... yeah exactly.  and what if something goes wrong, you want to be
able to interact over openocd without interfering with that
earlyprintk, particularly during that critical first bringup phase of
real-world silicon?

> I
> think it's misleading and we should at least have an argument to chose
> between the main console and an optional debug console, or rename
> them to debug_console_getchar/debug_console_putchar and
> main_console_getchar/
> main_console_putchar.

 i initially thought of proposing that, however:

 (1) the API already exists with "single console". it would therefore
be disruptive to change that

 (2) if adding something called debug_console_{get/put}char, it might
as well take advantage of the opportunity to be extended and made
generic, and have the extra argument added

> However I don't think that argument should be the serial line. Different
> vendors may use different serial lines for the main console / debug
> console,
> the caller doesn't know which serial line maps to which console, so the
> SBI
> should be more abstract and use something like a console id where e.g. 0
> is
> main console an 1 is debug.

 yes, it should [have]: my feeling is, it's a little late in the game
given that it's almost certainly baked into pre-existing hardware, by
now, so the next best thing is a new function call.

l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 15:48     ` lkcl
@ 2018-11-10 15:48       ` Luke Kenneth Casson Leighton
  2018-11-10 16:46       ` rminnich
  2018-11-10 17:43       ` mick
  2 siblings, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-10 15:48 UTC (permalink / raw)
  To: mick
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, Anup Patel, Palmer Dabbelt, Alexander Graf, zong,
	atish.patra, sw-dev, paul.walmsley, Alistair.Francis,
	linux-riscv, Andrew Waterman

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε:
> > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
> > wrote:
> >
> >> ## Conclusion
> >> This proposal is far from perfect and absolutely any suggestion is
> >> welcome. Obviously, there are many other functionalities that can be
> >> added to this proposal. However, I just wanted to start with something
> >> that is an incremental change at best to kick off the discussion. The
> >> aim here is to initiate a discussion that can lead to a robust SBI
> >> specification.
> >
> >  very cool, atish.
> >
> >  i would very much like to see the optional addition of multiple
> > serial lines, by adding a getchar and putchar function that takes just
> > one extra argument: the serial line index.
> >
> >  there are a lot of different uses to which mult-serial lines may be
> > put:
> >
> >  * boot message separation from console login
> >  * boot management separation from other purposes (u-boot/coreboot)
> >  * virtual /dev/ttyS0-3
> >  * clean UPS reporting and management
> >  * remote virtual machine power management (power-on / off)
> >  * simple bog-standard multiple virtual login consoles
> >  * separation of debug messages (stdout/stderr) to ease debugging and
> > development
> >  * remote and virtual OpenOCD and kernel debugging without disrupting
> > the main serial console
> >  * PPP serial links.
> >
> > this latter is one that i am particularly interested in, as i would
> > like to be able to boot a full GNU/Linux OS on spike, given the lower
> > barrier to entry in making modifications and experimenting with spike
> > than it is with qemu.
> >
> >  if spike were able, through a multi-serial SBI interface, to have a
> > PPP serial line, it would be possible to run a root NFS (or other
> > network block device) without having to sacrifice console access.  it
> > would be possible to create an initramfs from a lower-capability
> > system like buildroot, containing PPP, enable it, and pivot-root out
> > to a full stock GNU/Linux OS such as debian or fedora.
> >
> >  so there are huge benefits, reducing the development barrier to entry
> > into RISC-V experimentation and debugging, and opening up a much wider
> > range of capabilities and possibilities for machine and virtual system
> > management.
> >
> > l.
>
>
> The current SBI says that console_getchar/console_putchar are for the
> debug
> console but on Linux we use them for the main console on earlyprintk.

 ... yeah exactly.  and what if something goes wrong, you want to be
able to interact over openocd without interfering with that
earlyprintk, particularly during that critical first bringup phase of
real-world silicon?

> I
> think it's misleading and we should at least have an argument to chose
> between the main console and an optional debug console, or rename
> them to debug_console_getchar/debug_console_putchar and
> main_console_getchar/
> main_console_putchar.

 i initially thought of proposing that, however:

 (1) the API already exists with "single console". it would therefore
be disruptive to change that

 (2) if adding something called debug_console_{get/put}char, it might
as well take advantage of the opportunity to be extended and made
generic, and have the extra argument added

> However I don't think that argument should be the serial line. Different
> vendors may use different serial lines for the main console / debug
> console,
> the caller doesn't know which serial line maps to which console, so the
> SBI
> should be more abstract and use something like a console id where e.g. 0
> is
> main console an 1 is debug.

 yes, it should [have]: my feeling is, it's a little late in the game
given that it's almost certainly baked into pre-existing hardware, by
now, so the next best thing is a new function call.

l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 15:48     ` lkcl
  2018-11-10 15:48       ` Luke Kenneth Casson Leighton
@ 2018-11-10 16:46       ` rminnich
  2018-11-10 16:46         ` ron minnich
                           ` (4 more replies)
  2018-11-10 17:43       ` mick
  2 siblings, 5 replies; 67+ messages in thread
From: rminnich @ 2018-11-10 16:46 UTC (permalink / raw)
  To: linux-riscv

At Google and other places, we've been struggling now for years with
overly complex firmware that is implemented incorrectly, enabling
exploits and other bad things. The list of things vendors get wrong in
firmware, both enabling exploits and enabling others to enable
exploits, is long and it continues to this day. There is an
unbelievable amount of money out there all involving firmware
exploits, very little of it involving nice people.

I'm currently working on deleting all use of the x86 version of M
mode, i.e. SMM. There are many proposals out there for deleting SMM
from the architecture. I've also shown at a talk in 2017 how we could
redirect SMM interrupts back into the kernel. We're also removing all
use of callbacks into UEFI on x86. We're almost there.

Which is why I'm a bit unhappy to see this (to me) cancerous growth in
proposals for M- mode code. PPP in firmware? Really? multiple serial
devices? really? We've been here before, in the 1970s, with something
called the BIOS. If you're not familiar with it, go take a look, or
you can take my word for it that these proposals implement that idea.
We spent over 20 years freeing ourselves from it on x86. Why go back
to a 50 year old model on a CPU designed to be in use for 50 years?

My early understanding of M mode was that it was an Alpha PALCode like
thing, enabling access to resources that were behind a privilege wall.
I did not like it that much, but I was OK: it was very limited in
function, and the kernel could replace it, or at least measure it. I
also accept that every cpu vendor uses m mode like things (e.g. ARM
TF) for reasonable purposes and also (let's be honest here)  for
dealing with chipset mistakes. But that does not mean you need to
recreate BIOS.

The SBI should be hard to add to, deliberately. It should be used only
when there are no possible alternatives. It needs to be open source
and held in common. It should be possible for a kernel to replace or
at least measure it. And, further, there needs to be some work done on
why you add to it, and why you don't, with bias against adding to it.
This proposal works against those ideals, as it explicitly enables
vendor-specific forks of the SBI. Sure, this can happen, but why make
it so easy?

see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.

Also, I've had discussions with some security folks in our firmware
community about the fact that the PMP can be used in a way that the
kernel can not measure the SBI, since SBI might read-protect itself.
This is a real step backwards, FYI. Not sure if it can be changed at
this point.

ron
p.s. For interleaving debug and console output firmware, use the
oldest trick in the book: ASCII is 7 bits. Since console out is 8
bits, reserve 128 values for console out, and 128 for debug stream,
and if the debug stream needs 8 bit for some words, you know what to
do. It's very easy and doesn't require that we add multiple UART
support to SBI.
On Sat, Nov 10, 2018 at 7:49 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
> >
> > ???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????:
> > > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
> > > wrote:
> > >
> > >> ## Conclusion
> > >> This proposal is far from perfect and absolutely any suggestion is
> > >> welcome. Obviously, there are many other functionalities that can be
> > >> added to this proposal. However, I just wanted to start with something
> > >> that is an incremental change at best to kick off the discussion. The
> > >> aim here is to initiate a discussion that can lead to a robust SBI
> > >> specification.
> > >
> > >  very cool, atish.
> > >
> > >  i would very much like to see the optional addition of multiple
> > > serial lines, by adding a getchar and putchar function that takes just
> > > one extra argument: the serial line index.
> > >
> > >  there are a lot of different uses to which mult-serial lines may be
> > > put:
> > >
> > >  * boot message separation from console login
> > >  * boot management separation from other purposes (u-boot/coreboot)
> > >  * virtual /dev/ttyS0-3
> > >  * clean UPS reporting and management
> > >  * remote virtual machine power management (power-on / off)
> > >  * simple bog-standard multiple virtual login consoles
> > >  * separation of debug messages (stdout/stderr) to ease debugging and
> > > development
> > >  * remote and virtual OpenOCD and kernel debugging without disrupting
> > > the main serial console
> > >  * PPP serial links.
> > >
> > > this latter is one that i am particularly interested in, as i would
> > > like to be able to boot a full GNU/Linux OS on spike, given the lower
> > > barrier to entry in making modifications and experimenting with spike
> > > than it is with qemu.
> > >
> > >  if spike were able, through a multi-serial SBI interface, to have a
> > > PPP serial line, it would be possible to run a root NFS (or other
> > > network block device) without having to sacrifice console access.  it
> > > would be possible to create an initramfs from a lower-capability
> > > system like buildroot, containing PPP, enable it, and pivot-root out
> > > to a full stock GNU/Linux OS such as debian or fedora.
> > >
> > >  so there are huge benefits, reducing the development barrier to entry
> > > into RISC-V experimentation and debugging, and opening up a much wider
> > > range of capabilities and possibilities for machine and virtual system
> > > management.
> > >
> > > l.
> >
> >
> > The current SBI says that console_getchar/console_putchar are for the
> > debug
> > console but on Linux we use them for the main console on earlyprintk.
>
>  ... yeah exactly.  and what if something goes wrong, you want to be
> able to interact over openocd without interfering with that
> earlyprintk, particularly during that critical first bringup phase of
> real-world silicon?
>
> > I
> > think it's misleading and we should at least have an argument to chose
> > between the main console and an optional debug console, or rename
> > them to debug_console_getchar/debug_console_putchar and
> > main_console_getchar/
> > main_console_putchar.
>
>  i initially thought of proposing that, however:
>
>  (1) the API already exists with "single console". it would therefore
> be disruptive to change that
>
>  (2) if adding something called debug_console_{get/put}char, it might
> as well take advantage of the opportunity to be extended and made
> generic, and have the extra argument added
>
> > However I don't think that argument should be the serial line. Different
> > vendors may use different serial lines for the main console / debug
> > console,
> > the caller doesn't know which serial line maps to which console, so the
> > SBI
> > should be more abstract and use something like a console id where e.g. 0
> > is
> > main console an 1 is debug.
>
>  yes, it should [have]: my feeling is, it's a little late in the game
> given that it's almost certainly baked into pre-existing hardware, by
> now, so the next best thing is a new function call.
>
> l.
>
> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe at groups.riscv.org.
> To post to this group, send email to sw-dev at groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ%3D44A%40mail.gmail.com.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 16:46       ` rminnich
@ 2018-11-10 16:46         ` ron minnich
  2018-11-10 17:40         ` lkcl
                           ` (3 subsequent siblings)
  4 siblings, 0 replies; 67+ messages in thread
From: ron minnich @ 2018-11-10 16:46 UTC (permalink / raw)
  To: Luke Kenneth Casson Leighton
  Cc: mark.rutland, Christoph Hellwig, Damien.LeMoal, Olof Johansson,
	alankao, abner.chang, Anup Patel, Palmer Dabbelt, agraf, zong,
	atish.patra, sw-dev, Paul Walmsley, mick, Alistair.Francis,
	linux-riscv, Andrew Waterman

At Google and other places, we've been struggling now for years with
overly complex firmware that is implemented incorrectly, enabling
exploits and other bad things. The list of things vendors get wrong in
firmware, both enabling exploits and enabling others to enable
exploits, is long and it continues to this day. There is an
unbelievable amount of money out there all involving firmware
exploits, very little of it involving nice people.

I'm currently working on deleting all use of the x86 version of M
mode, i.e. SMM. There are many proposals out there for deleting SMM
from the architecture. I've also shown at a talk in 2017 how we could
redirect SMM interrupts back into the kernel. We're also removing all
use of callbacks into UEFI on x86. We're almost there.

Which is why I'm a bit unhappy to see this (to me) cancerous growth in
proposals for M- mode code. PPP in firmware? Really? multiple serial
devices? really? We've been here before, in the 1970s, with something
called the BIOS. If you're not familiar with it, go take a look, or
you can take my word for it that these proposals implement that idea.
We spent over 20 years freeing ourselves from it on x86. Why go back
to a 50 year old model on a CPU designed to be in use for 50 years?

My early understanding of M mode was that it was an Alpha PALCode like
thing, enabling access to resources that were behind a privilege wall.
I did not like it that much, but I was OK: it was very limited in
function, and the kernel could replace it, or at least measure it. I
also accept that every cpu vendor uses m mode like things (e.g. ARM
TF) for reasonable purposes and also (let's be honest here)  for
dealing with chipset mistakes. But that does not mean you need to
recreate BIOS.

The SBI should be hard to add to, deliberately. It should be used only
when there are no possible alternatives. It needs to be open source
and held in common. It should be possible for a kernel to replace or
at least measure it. And, further, there needs to be some work done on
why you add to it, and why you don't, with bias against adding to it.
This proposal works against those ideals, as it explicitly enables
vendor-specific forks of the SBI. Sure, this can happen, but why make
it so easy?

see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.

Also, I've had discussions with some security folks in our firmware
community about the fact that the PMP can be used in a way that the
kernel can not measure the SBI, since SBI might read-protect itself.
This is a real step backwards, FYI. Not sure if it can be changed at
this point.

ron
p.s. For interleaving debug and console output firmware, use the
oldest trick in the book: ASCII is 7 bits. Since console out is 8
bits, reserve 128 values for console out, and 128 for debug stream,
and if the debug stream needs 8 bit for some words, you know what to
do. It's very easy and doesn't require that we add multiple UART
support to SBI.
On Sat, Nov 10, 2018 at 7:49 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
> >
> > Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε:
> > > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
> > > wrote:
> > >
> > >> ## Conclusion
> > >> This proposal is far from perfect and absolutely any suggestion is
> > >> welcome. Obviously, there are many other functionalities that can be
> > >> added to this proposal. However, I just wanted to start with something
> > >> that is an incremental change at best to kick off the discussion. The
> > >> aim here is to initiate a discussion that can lead to a robust SBI
> > >> specification.
> > >
> > >  very cool, atish.
> > >
> > >  i would very much like to see the optional addition of multiple
> > > serial lines, by adding a getchar and putchar function that takes just
> > > one extra argument: the serial line index.
> > >
> > >  there are a lot of different uses to which mult-serial lines may be
> > > put:
> > >
> > >  * boot message separation from console login
> > >  * boot management separation from other purposes (u-boot/coreboot)
> > >  * virtual /dev/ttyS0-3
> > >  * clean UPS reporting and management
> > >  * remote virtual machine power management (power-on / off)
> > >  * simple bog-standard multiple virtual login consoles
> > >  * separation of debug messages (stdout/stderr) to ease debugging and
> > > development
> > >  * remote and virtual OpenOCD and kernel debugging without disrupting
> > > the main serial console
> > >  * PPP serial links.
> > >
> > > this latter is one that i am particularly interested in, as i would
> > > like to be able to boot a full GNU/Linux OS on spike, given the lower
> > > barrier to entry in making modifications and experimenting with spike
> > > than it is with qemu.
> > >
> > >  if spike were able, through a multi-serial SBI interface, to have a
> > > PPP serial line, it would be possible to run a root NFS (or other
> > > network block device) without having to sacrifice console access.  it
> > > would be possible to create an initramfs from a lower-capability
> > > system like buildroot, containing PPP, enable it, and pivot-root out
> > > to a full stock GNU/Linux OS such as debian or fedora.
> > >
> > >  so there are huge benefits, reducing the development barrier to entry
> > > into RISC-V experimentation and debugging, and opening up a much wider
> > > range of capabilities and possibilities for machine and virtual system
> > > management.
> > >
> > > l.
> >
> >
> > The current SBI says that console_getchar/console_putchar are for the
> > debug
> > console but on Linux we use them for the main console on earlyprintk.
>
>  ... yeah exactly.  and what if something goes wrong, you want to be
> able to interact over openocd without interfering with that
> earlyprintk, particularly during that critical first bringup phase of
> real-world silicon?
>
> > I
> > think it's misleading and we should at least have an argument to chose
> > between the main console and an optional debug console, or rename
> > them to debug_console_getchar/debug_console_putchar and
> > main_console_getchar/
> > main_console_putchar.
>
>  i initially thought of proposing that, however:
>
>  (1) the API already exists with "single console". it would therefore
> be disruptive to change that
>
>  (2) if adding something called debug_console_{get/put}char, it might
> as well take advantage of the opportunity to be extended and made
> generic, and have the extra argument added
>
> > However I don't think that argument should be the serial line. Different
> > vendors may use different serial lines for the main console / debug
> > console,
> > the caller doesn't know which serial line maps to which console, so the
> > SBI
> > should be more abstract and use something like a console id where e.g. 0
> > is
> > main console an 1 is debug.
>
>  yes, it should [have]: my feeling is, it's a little late in the game
> given that it's almost certainly baked into pre-existing hardware, by
> now, so the next best thing is a new function call.
>
> l.
>
> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
> To post to this group, send email to sw-dev@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ%3D44A%40mail.gmail.com.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 16:46       ` rminnich
  2018-11-10 16:46         ` ron minnich
@ 2018-11-10 17:40         ` lkcl
  2018-11-10 17:40           ` Luke Kenneth Casson Leighton
  2018-11-10 17:41         ` sam.falvo
                           ` (2 subsequent siblings)
  4 siblings, 1 reply; 67+ messages in thread
From: lkcl @ 2018-11-10 17:40 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 4:46 PM ron minnich <rminnich@gmail.com> wrote:

> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware?

 no, ron, absolutely not, that would not make any sense at all:
getting what is otherwise a userspace pppd into firmware would be a
nightmare as it would require a huge amount of POSIX support dragged
in with it.

 it would be ppp running in spike userspace (buildroot in an
initramfs), where the linux kernel would have absolutely standard ppp
modules compiled up, the serial data drops down to spike over the
proposed modified SBI, which, on having support for the proposed
addition, will take an extra command-line option "spike
--serial-line-0-redirect-cmd='pppd'" which gets it into the host, and
the guest spike OS gets network in a dead straightforward fashion, for
very little in the way of code and ABI modifications.

 it's a cut/paste job, for goodness sake, in the pre-existing SBI
implementations, just adding an extra argument.

 it's real simple, and has absolutely nothing to do with the [crazed!]
idea of porting a userspace ppp POSIX daemon into u-boot/coreboot.  i
mean, you *could* do it but you'd be insane to consider it, and there
are better options for the more complex systems... which don't *have*
to use the proposed idea.

 the alternative to achieve the same desired goal is to re-wire all of
the u-boot/coreboot source code and use some form of serial line
"framing" protocol, to emulate multiple virtual serial lines over the
single SBI console.  and rewrite openocd to support it.  and. and.
and. and.

 that's a lairy nightmare waiting to happen, and, on early debug of
real silicon where you're hand-programming the PLL and the serial
port's outputting crap because you've no idea of the baud rate, you
wouldn't see ASCII characters if you got it right, you'd see framing
crap instead and couldn't plug in simple minicom, it'd have to be a
*modified* version of minicom.  etc. etc. etc. etc.


> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.

 naah.  see above.  it's a lot more complex and fragile than that.

l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:40         ` lkcl
@ 2018-11-10 17:40           ` Luke Kenneth Casson Leighton
  0 siblings, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-10 17:40 UTC (permalink / raw)
  To: ron minnich
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, Anup Patel, Palmer Dabbelt, Alexander Graf, zong,
	atish.patra, sw-dev, paul.walmsley, mick, Alistair.Francis,
	linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 4:46 PM ron minnich <rminnich@gmail.com> wrote:

> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware?

 no, ron, absolutely not, that would not make any sense at all:
getting what is otherwise a userspace pppd into firmware would be a
nightmare as it would require a huge amount of POSIX support dragged
in with it.

 it would be ppp running in spike userspace (buildroot in an
initramfs), where the linux kernel would have absolutely standard ppp
modules compiled up, the serial data drops down to spike over the
proposed modified SBI, which, on having support for the proposed
addition, will take an extra command-line option "spike
--serial-line-0-redirect-cmd='pppd'" which gets it into the host, and
the guest spike OS gets network in a dead straightforward fashion, for
very little in the way of code and ABI modifications.

 it's a cut/paste job, for goodness sake, in the pre-existing SBI
implementations, just adding an extra argument.

 it's real simple, and has absolutely nothing to do with the [crazed!]
idea of porting a userspace ppp POSIX daemon into u-boot/coreboot.  i
mean, you *could* do it but you'd be insane to consider it, and there
are better options for the more complex systems... which don't *have*
to use the proposed idea.

 the alternative to achieve the same desired goal is to re-wire all of
the u-boot/coreboot source code and use some form of serial line
"framing" protocol, to emulate multiple virtual serial lines over the
single SBI console.  and rewrite openocd to support it.  and. and.
and. and.

 that's a lairy nightmare waiting to happen, and, on early debug of
real silicon where you're hand-programming the PLL and the serial
port's outputting crap because you've no idea of the baud rate, you
wouldn't see ASCII characters if you got it right, you'd see framing
crap instead and couldn't plug in simple minicom, it'd have to be a
*modified* version of minicom.  etc. etc. etc. etc.


> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.

 naah.  see above.  it's a lot more complex and fragile than that.

l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 16:46       ` rminnich
  2018-11-10 16:46         ` ron minnich
  2018-11-10 17:40         ` lkcl
@ 2018-11-10 17:41         ` sam.falvo
  2018-11-10 17:41           ` Samuel Falvo II
                             ` (2 more replies)
  2018-11-10 17:41         ` olof
  2018-11-11  3:58         ` atish.patra
  4 siblings, 3 replies; 67+ messages in thread
From: sam.falvo @ 2018-11-10 17:41 UTC (permalink / raw)
  To: linux-riscv

on sat, nov 10, 2018 at 8:46 am ron minnich <rminnich@gmail.com> wrote:
> which is why i'm a bit unhappy to see this (to me) cancerous growth in
> proposals for m- mode code. ppp in firmware? really? multiple serial

i'm inclined to agree with the overall sentiment of the concerns
raised herein (omitted for brevity), but i feel that it might go a bit
too far.

the bios has its roots with cp/m, i think we all can agree with this,
and there the bios was well-matched to its task: booting cp/m.
nothing more, nothing less.

you had i/o routines for teletype output, keyboard input, paper tape
input, and punch output.  as well, you had basic primitives for
reading and writing sectors on mass storage devices.  and, unless you
were porting cp/m itself to a completely new platform, you never had
to *really* worry about the physical constraints of those mass storage
devices.  maximum number of sectors and tracks were about the extent
of things.  you never had to call back into anything, either.

in other words, bios was a *library*, not a *framework.*  it was
*deliberately* designed and scoped to just deal with booting into a
cp/m environment.

originally, the pc bios was built the same way -- it was what you used
to boot pc-dos (nee ms-dos).

only *later* did massive api changes get lumped into the bios.  things
like protected memory support, acpi power mode settings, etc. all but
required changing the bios away from being a library and into more of
a framework/miniature os unto itself.

i think the real lessons to be learned here are:

1) the bios interface was dictated by the demands of booting and
running a preferred (though not the only) os.  in other words, the
*os* dictated the bios interface.  bios literally was what one would
call a "hal" (hardware abstraction layer) these days.  the fact that
others have technically used bios to boot into other, non-sanctioned
oses over the years is, technically, an abuse of the interface that
just happens to work.

2) bios was strictly a library.  the maximum extent to which bios was
a framework stopped firmly at loading in the master boot record and
dispatching control to it.  from then on, you were utterly on your
own.  note: no security hoo-haw here.  no signed anything.  no pe
executables.  no rom-filesystems.  no dedicated uefi partitions.  et.
al.  just read in 512b to 1kb of raw binary blob, and run it.  that's
it.  from then on, bios was a library first and always.  anything we
come up with for an sbi must, in my opinion, behave the same way.

oh, btw, before people get the idea that uefi allows per-partition
filesystems, please note that os/2 used "micro-filesystem drivers" to
achieve this same effect with nothing more sophisticated than the
partition table located in a dos 3.3 mbr.  don't drink the uefi
kool-aid.

3) corrallary to (2): because bios was just a library, you could throw
it away en mass at any time (and after booting into the os of your
choice, it frequently was).  you could, if you were clever enough with
page tables and the like, even replace the bios with your own image if
you wanted to.  this speaks to what ron has discussed in prior threads
over the concerns of not being able to replace m-mode software.

4) support for multiple devices is not necessarily a bad thing; just,
don't go hog wild with it.  there's no need to support 256 possible
serial ports, for example.  ok, you have a debugger interface, a
resident console, and maybe one more for auxiliary purposes (for
example, my kestrel-3 design so far needs *two* serial interfaces to
the host pc, one which is the user's console, and one which is used to
access mass storage).  each of these devices should have their own
read/write interface, thus making it impeccably clear in the source
code what it is you're trying to do.  no need to "open" things.

my point here is, going back to the needs of the *os* and not the bios
for bios' sake, the interface exposed by the bios should match the
overall expectations of the os you're booting.  in my case, i *need*
two serial interfaces for my prototype computer to function: ergo, it
makes perfect sense for my firmware to provide support for two serial
interfaces.  for the linux, this need not be the case; maybe only one
interface is required.

> the sbi should be hard to add to, deliberately. it should be used only
> when there are no possible alternatives. it needs to be open source
> and held in common. it should be possible for a kernel to replace or
> at least measure it. and, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.

i'm reposting this block of test because i agree completely with it,
and want to point out that it doesn't contradict what i wrote above.

> p.s. for interleaving debug and console output firmware, use the
> oldest trick in the book: ascii is 7 bits. since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. it's very easy and doesn't require that we add multiple uart
> support to sbi.

another option is to use escape sequences preceding each output.
escape byte 1 would mean "future bytes are sent to the debugger",
while byte 2 would mean "future bytes are intended for console
output."  this gives you support for all 8-bits (if your debugger
interface happens to be binary), with the occasional overhead of
escaping escape bytes.

trivial to implement both on the receiving and transmitting sides,
possibly even simpler than the bit-7-target-address approach above.
the only disadvantage is that it's stateful; but if you have a serial
connection reliable enough to use with a binary debugging interface,
it'll almost certainly be reliable enough for this too.

-- 
samuel a. falvo ii

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:41         ` sam.falvo
@ 2018-11-10 17:41           ` Samuel Falvo II
  2018-11-10 17:42           ` lkcl
  2018-11-10 17:43           ` sam.falvo
  2 siblings, 0 replies; 67+ messages in thread
From: Samuel Falvo II @ 2018-11-10 17:41 UTC (permalink / raw)
  To: ron minnich
  Cc: mark.rutland, hch, Damien.LeMoal, olof.johansson, alankao, Chang,
	Abner, Anup Patel, Palmer Dabbelt, agraf, zong, atish.patra,
	sw-dev, paul.walmsley, mick, Alistair.Francis,
	Luke Kenneth Casson Leighton, linux-riscv, Andrew Waterman

on sat, nov 10, 2018 at 8:46 am ron minnich <rminnich@gmail.com> wrote:
> which is why i'm a bit unhappy to see this (to me) cancerous growth in
> proposals for m- mode code. ppp in firmware? really? multiple serial

i'm inclined to agree with the overall sentiment of the concerns
raised herein (omitted for brevity), but i feel that it might go a bit
too far.

the bios has its roots with cp/m, i think we all can agree with this,
and there the bios was well-matched to its task: booting cp/m.
nothing more, nothing less.

you had i/o routines for teletype output, keyboard input, paper tape
input, and punch output.  as well, you had basic primitives for
reading and writing sectors on mass storage devices.  and, unless you
were porting cp/m itself to a completely new platform, you never had
to *really* worry about the physical constraints of those mass storage
devices.  maximum number of sectors and tracks were about the extent
of things.  you never had to call back into anything, either.

in other words, bios was a *library*, not a *framework.*  it was
*deliberately* designed and scoped to just deal with booting into a
cp/m environment.

originally, the pc bios was built the same way -- it was what you used
to boot pc-dos (nee ms-dos).

only *later* did massive api changes get lumped into the bios.  things
like protected memory support, acpi power mode settings, etc. all but
required changing the bios away from being a library and into more of
a framework/miniature os unto itself.

i think the real lessons to be learned here are:

1) the bios interface was dictated by the demands of booting and
running a preferred (though not the only) os.  in other words, the
*os* dictated the bios interface.  bios literally was what one would
call a "hal" (hardware abstraction layer) these days.  the fact that
others have technically used bios to boot into other, non-sanctioned
oses over the years is, technically, an abuse of the interface that
just happens to work.

2) bios was strictly a library.  the maximum extent to which bios was
a framework stopped firmly at loading in the master boot record and
dispatching control to it.  from then on, you were utterly on your
own.  note: no security hoo-haw here.  no signed anything.  no pe
executables.  no rom-filesystems.  no dedicated uefi partitions.  et.
al.  just read in 512b to 1kb of raw binary blob, and run it.  that's
it.  from then on, bios was a library first and always.  anything we
come up with for an sbi must, in my opinion, behave the same way.

oh, btw, before people get the idea that uefi allows per-partition
filesystems, please note that os/2 used "micro-filesystem drivers" to
achieve this same effect with nothing more sophisticated than the
partition table located in a dos 3.3 mbr.  don't drink the uefi
kool-aid.

3) corrallary to (2): because bios was just a library, you could throw
it away en mass at any time (and after booting into the os of your
choice, it frequently was).  you could, if you were clever enough with
page tables and the like, even replace the bios with your own image if
you wanted to.  this speaks to what ron has discussed in prior threads
over the concerns of not being able to replace m-mode software.

4) support for multiple devices is not necessarily a bad thing; just,
don't go hog wild with it.  there's no need to support 256 possible
serial ports, for example.  ok, you have a debugger interface, a
resident console, and maybe one more for auxiliary purposes (for
example, my kestrel-3 design so far needs *two* serial interfaces to
the host pc, one which is the user's console, and one which is used to
access mass storage).  each of these devices should have their own
read/write interface, thus making it impeccably clear in the source
code what it is you're trying to do.  no need to "open" things.

my point here is, going back to the needs of the *os* and not the bios
for bios' sake, the interface exposed by the bios should match the
overall expectations of the os you're booting.  in my case, i *need*
two serial interfaces for my prototype computer to function: ergo, it
makes perfect sense for my firmware to provide support for two serial
interfaces.  for the linux, this need not be the case; maybe only one
interface is required.

> the sbi should be hard to add to, deliberately. it should be used only
> when there are no possible alternatives. it needs to be open source
> and held in common. it should be possible for a kernel to replace or
> at least measure it. and, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.

i'm reposting this block of test because i agree completely with it,
and want to point out that it doesn't contradict what i wrote above.

> p.s. for interleaving debug and console output firmware, use the
> oldest trick in the book: ascii is 7 bits. since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. it's very easy and doesn't require that we add multiple uart
> support to sbi.

another option is to use escape sequences preceding each output.
escape byte 1 would mean "future bytes are sent to the debugger",
while byte 2 would mean "future bytes are intended for console
output."  this gives you support for all 8-bits (if your debugger
interface happens to be binary), with the occasional overhead of
escaping escape bytes.

trivial to implement both on the receiving and transmitting sides,
possibly even simpler than the bit-7-target-address approach above.
the only disadvantage is that it's stateful; but if you have a serial
connection reliable enough to use with a binary debugging interface,
it'll almost certainly be reliable enough for this too.

-- 
samuel a. falvo ii

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 16:46       ` rminnich
                           ` (2 preceding siblings ...)
  2018-11-10 17:41         ` sam.falvo
@ 2018-11-10 17:41         ` olof
  2018-11-10 17:41           ` Olof Johansson
                             ` (3 more replies)
  2018-11-11  3:58         ` atish.patra
  4 siblings, 4 replies; 67+ messages in thread
From: olof @ 2018-11-10 17:41 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote:
>
> At Google and other places, we've been struggling now for years with
> overly complex firmware that is implemented incorrectly, enabling
> exploits and other bad things. The list of things vendors get wrong in
> firmware, both enabling exploits and enabling others to enable
> exploits, is long and it continues to this day. There is an
> unbelievable amount of money out there all involving firmware
> exploits, very little of it involving nice people.
>
> I'm currently working on deleting all use of the x86 version of M
> mode, i.e. SMM. There are many proposals out there for deleting SMM
> from the architecture. I've also shown at a talk in 2017 how we could
> redirect SMM interrupts back into the kernel. We're also removing all
> use of callbacks into UEFI on x86. We're almost there.
>
> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware? Really? multiple serial
> devices? really? We've been here before, in the 1970s, with something
> called the BIOS. If you're not familiar with it, go take a look, or
> you can take my word for it that these proposals implement that idea.
> We spent over 20 years freeing ourselves from it on x86. Why go back
> to a 50 year old model on a CPU designed to be in use for 50 years?
>
> My early understanding of M mode was that it was an Alpha PALCode like
> thing, enabling access to resources that were behind a privilege wall.
> I did not like it that much, but I was OK: it was very limited in
> function, and the kernel could replace it, or at least measure it. I
> also accept that every cpu vendor uses m mode like things (e.g. ARM
> TF) for reasonable purposes and also (let's be honest here)  for
> dealing with chipset mistakes. But that does not mean you need to
> recreate BIOS.
>
> The SBI should be hard to add to, deliberately. It should be used only
> when there are no possible alternatives. It needs to be open source
> and held in common. It should be possible for a kernel to replace or
> at least measure it. And, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.
> This proposal works against those ideals, as it explicitly enables
> vendor-specific forks of the SBI. Sure, this can happen, but why make
> it so easy?

There's a tension between letting people do the messy things that real
hardware sometimes needs without polluting higher layers in the
software stack, and letting them do too much of things that _should_
be handled in the upper layers. I have yet to find a solution that
doesn't need tweaking over time, the pendulum tends to swing back and
forth into "too far" in both directions sometimes.

The case of console is in this case pretty simple: It's intended for
early boot for very simplistic environments (before the rest of the
kernel is up, etc). Keeping the SBI console around beyond early boot,
and somehow trying to optimize for it for those use cases is a
misdirected effort; that's what native drivers are for.

Having to do fine-grained arbitration of device ownership between
firmware and kernel at runtime is usually error prone and awkward and
best to avoid.


> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.

Sure, it helps for 2 channels. And then beyond that you need a more
complex protocol. Either way, it's not a problem we need to solve here
and now.


-Olof

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:41         ` olof
@ 2018-11-10 17:41           ` Olof Johansson
  2018-11-10 17:47           ` lkcl
                             ` (2 subsequent siblings)
  3 siblings, 0 replies; 67+ messages in thread
From: Olof Johansson @ 2018-11-10 17:41 UTC (permalink / raw)
  To: rminnich
  Cc: Mark Rutland, Christoph Hellwig, Damien.LeMoal, olof johansson,
	alankao, abner.chang, Anup Patel, Palmer Dabbelt, Alexander Graf,
	zong, atish.patra, sw-dev, paul.walmsley, mick, Alistair.Francis,
	lkcl, linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote:
>
> At Google and other places, we've been struggling now for years with
> overly complex firmware that is implemented incorrectly, enabling
> exploits and other bad things. The list of things vendors get wrong in
> firmware, both enabling exploits and enabling others to enable
> exploits, is long and it continues to this day. There is an
> unbelievable amount of money out there all involving firmware
> exploits, very little of it involving nice people.
>
> I'm currently working on deleting all use of the x86 version of M
> mode, i.e. SMM. There are many proposals out there for deleting SMM
> from the architecture. I've also shown at a talk in 2017 how we could
> redirect SMM interrupts back into the kernel. We're also removing all
> use of callbacks into UEFI on x86. We're almost there.
>
> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware? Really? multiple serial
> devices? really? We've been here before, in the 1970s, with something
> called the BIOS. If you're not familiar with it, go take a look, or
> you can take my word for it that these proposals implement that idea.
> We spent over 20 years freeing ourselves from it on x86. Why go back
> to a 50 year old model on a CPU designed to be in use for 50 years?
>
> My early understanding of M mode was that it was an Alpha PALCode like
> thing, enabling access to resources that were behind a privilege wall.
> I did not like it that much, but I was OK: it was very limited in
> function, and the kernel could replace it, or at least measure it. I
> also accept that every cpu vendor uses m mode like things (e.g. ARM
> TF) for reasonable purposes and also (let's be honest here)  for
> dealing with chipset mistakes. But that does not mean you need to
> recreate BIOS.
>
> The SBI should be hard to add to, deliberately. It should be used only
> when there are no possible alternatives. It needs to be open source
> and held in common. It should be possible for a kernel to replace or
> at least measure it. And, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.
> This proposal works against those ideals, as it explicitly enables
> vendor-specific forks of the SBI. Sure, this can happen, but why make
> it so easy?

There's a tension between letting people do the messy things that real
hardware sometimes needs without polluting higher layers in the
software stack, and letting them do too much of things that _should_
be handled in the upper layers. I have yet to find a solution that
doesn't need tweaking over time, the pendulum tends to swing back and
forth into "too far" in both directions sometimes.

The case of console is in this case pretty simple: It's intended for
early boot for very simplistic environments (before the rest of the
kernel is up, etc). Keeping the SBI console around beyond early boot,
and somehow trying to optimize for it for those use cases is a
misdirected effort; that's what native drivers are for.

Having to do fine-grained arbitration of device ownership between
firmware and kernel at runtime is usually error prone and awkward and
best to avoid.


> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.

Sure, it helps for 2 channels. And then beyond that you need a more
complex protocol. Either way, it's not a problem we need to solve here
and now.


-Olof

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:41         ` sam.falvo
  2018-11-10 17:41           ` Samuel Falvo II
@ 2018-11-10 17:42           ` lkcl
  2018-11-10 17:42             ` Luke Kenneth Casson Leighton
  2018-11-10 17:51             ` sam.falvo
  2018-11-10 17:43           ` sam.falvo
  2 siblings, 2 replies; 67+ messages in thread
From: lkcl @ 2018-11-10 17:42 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 5:39 PM Samuel Falvo II <sam.falvo@gmail.com> wrote:

> on sat, nov 10, 2018 at 8:46 am ron minnich <rminnich@gmail.com> wrote:
> > which is why i'm a bit unhappy to see this (to me) cancerous growth in
> > proposals for m- mode code. ppp in firmware? really? multiple serial
>
> i'm inclined to agree with the overall sentiment of the concerns
> raised herein (omitted for brevity), but i feel that it might go a bit
> too far.

 it's also not an appropriate argument.  nobody sensible would port a
POSIX pppd from userspace into boot-level firmware.  the argument also
ignores the dozens of other advantageous potential use-cases.

l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:42           ` lkcl
@ 2018-11-10 17:42             ` Luke Kenneth Casson Leighton
  2018-11-10 17:51             ` sam.falvo
  1 sibling, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-10 17:42 UTC (permalink / raw)
  To: Samuel Falvo II
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, ron minnich, sw-dev, paul.walmsley, mick,
	Alistair.Francis, linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 5:39 PM Samuel Falvo II <sam.falvo@gmail.com> wrote:

> on sat, nov 10, 2018 at 8:46 am ron minnich <rminnich@gmail.com> wrote:
> > which is why i'm a bit unhappy to see this (to me) cancerous growth in
> > proposals for m- mode code. ppp in firmware? really? multiple serial
>
> i'm inclined to agree with the overall sentiment of the concerns
> raised herein (omitted for brevity), but i feel that it might go a bit
> too far.

 it's also not an appropriate argument.  nobody sensible would port a
POSIX pppd from userspace into boot-level firmware.  the argument also
ignores the dozens of other advantageous potential use-cases.

l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:41         ` sam.falvo
  2018-11-10 17:41           ` Samuel Falvo II
  2018-11-10 17:42           ` lkcl
@ 2018-11-10 17:43           ` sam.falvo
  2018-11-10 17:43             ` Samuel Falvo II
  2 siblings, 1 reply; 67+ messages in thread
From: sam.falvo @ 2018-11-10 17:43 UTC (permalink / raw)
  To: linux-riscv

Sorry for being all lower-case; I composed my text in Vim, and when I
copied it to the clipboard, I must have issued a command that
lowercased everything accidentally.

On Sat, Nov 10, 2018 at 9:41 AM Samuel Falvo II <sam.falvo@gmail.com> wrote:
> i'm inclined to agree with the overall sentiment of the concerns
> raised herein (omitted for brevity), but i feel that it might go a bit
> too far.

-- 
Samuel A. Falvo II

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:43           ` sam.falvo
@ 2018-11-10 17:43             ` Samuel Falvo II
  0 siblings, 0 replies; 67+ messages in thread
From: Samuel Falvo II @ 2018-11-10 17:43 UTC (permalink / raw)
  To: ron minnich
  Cc: mark.rutland, hch, Damien.LeMoal, olof.johansson, alankao, Chang,
	Abner, Anup Patel, Palmer Dabbelt, agraf, zong, atish.patra,
	sw-dev, paul.walmsley, mick, Alistair.Francis,
	Luke Kenneth Casson Leighton, linux-riscv, Andrew Waterman

Sorry for being all lower-case; I composed my text in Vim, and when I
copied it to the clipboard, I must have issued a command that
lowercased everything accidentally.

On Sat, Nov 10, 2018 at 9:41 AM Samuel Falvo II <sam.falvo@gmail.com> wrote:
> i'm inclined to agree with the overall sentiment of the concerns
> raised herein (omitted for brevity), but i feel that it might go a bit
> too far.

-- 
Samuel A. Falvo II

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 15:48     ` lkcl
  2018-11-10 15:48       ` Luke Kenneth Casson Leighton
  2018-11-10 16:46       ` rminnich
@ 2018-11-10 17:43       ` mick
  2018-11-10 17:43         ` Nick Kossifidis
  2018-11-10 17:51         ` lkcl
  2 siblings, 2 replies; 67+ messages in thread
From: mick @ 2018-11-10 17:43 UTC (permalink / raw)
  To: linux-riscv

???? 2018-11-10 17:48, Luke Kenneth Casson Leighton ??????:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> ???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????:
>> > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
>> > wrote:
>> >
>> >> ## Conclusion
>> >> This proposal is far from perfect and absolutely any suggestion is
>> >> welcome. Obviously, there are many other functionalities that can be
>> >> added to this proposal. However, I just wanted to start with something
>> >> that is an incremental change at best to kick off the discussion. The
>> >> aim here is to initiate a discussion that can lead to a robust SBI
>> >> specification.
>> >
>> >  very cool, atish.
>> >
>> >  i would very much like to see the optional addition of multiple
>> > serial lines, by adding a getchar and putchar function that takes just
>> > one extra argument: the serial line index.
>> >
>> >  there are a lot of different uses to which mult-serial lines may be
>> > put:
>> >
>> >  * boot message separation from console login
>> >  * boot management separation from other purposes (u-boot/coreboot)
>> >  * virtual /dev/ttyS0-3
>> >  * clean UPS reporting and management
>> >  * remote virtual machine power management (power-on / off)
>> >  * simple bog-standard multiple virtual login consoles
>> >  * separation of debug messages (stdout/stderr) to ease debugging and
>> > development
>> >  * remote and virtual OpenOCD and kernel debugging without disrupting
>> > the main serial console
>> >  * PPP serial links.
>> >
>> > this latter is one that i am particularly interested in, as i would
>> > like to be able to boot a full GNU/Linux OS on spike, given the lower
>> > barrier to entry in making modifications and experimenting with spike
>> > than it is with qemu.
>> >
>> >  if spike were able, through a multi-serial SBI interface, to have a
>> > PPP serial line, it would be possible to run a root NFS (or other
>> > network block device) without having to sacrifice console access.  it
>> > would be possible to create an initramfs from a lower-capability
>> > system like buildroot, containing PPP, enable it, and pivot-root out
>> > to a full stock GNU/Linux OS such as debian or fedora.
>> >
>> >  so there are huge benefits, reducing the development barrier to entry
>> > into RISC-V experimentation and debugging, and opening up a much wider
>> > range of capabilities and possibilities for machine and virtual system
>> > management.
>> >
>> > l.
>> 
>> 
>> The current SBI says that console_getchar/console_putchar are for the
>> debug
>> console but on Linux we use them for the main console on earlyprintk.
> 
>  ... yeah exactly.  and what if something goes wrong, you want to be
> able to interact over openocd without interfering with that
> earlyprintk, particularly during that critical first bringup phase of
> real-world silicon?
> 

What does openocd has to do with the console ? Earlyprintk is output
only btw. The point here is that we need to update the documentation
because it's misleading, we don't have a debug console on the current
SBI, just a console.

>> I
>> think it's misleading and we should at least have an argument to chose
>> between the main console and an optional debug console, or rename
>> them to debug_console_getchar/debug_console_putchar and
>> main_console_getchar/
>> main_console_putchar.
> 
>  i initially thought of proposing that, however:
> 
>  (1) the API already exists with "single console". it would therefore
> be disruptive to change that
> 
>  (2) if adding something called debug_console_{get/put}char, it might
> as well take advantage of the opportunity to be extended and made
> generic, and have the extra argument added
> 

I'm not in favor of main_console_getchar/debug_console_getchar etc, I
just wanted to point out that the API should be clear about what
console is to be used, not by using a serial line id but an id
that describes its usage.

>> However I don't think that argument should be the serial line. 
>> Different
>> vendors may use different serial lines for the main console / debug
>> console,
>> the caller doesn't know which serial line maps to which console, so 
>> the
>> SBI
>> should be more abstract and use something like a console id where e.g. 
>> 0
>> is
>> main console an 1 is debug.
> 
>  yes, it should [have]: my feeling is, it's a little late in the game
> given that it's almost certainly baked into pre-existing hardware, by
> now, so the next best thing is a new function call.
> 
> l.

Late in the game ? Who's game ? Is there any "standard" way out there
for mapping consoles to serial line indices ?

Regards,
Nick

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:43       ` mick
@ 2018-11-10 17:43         ` Nick Kossifidis
  2018-11-10 17:51         ` lkcl
  1 sibling, 0 replies; 67+ messages in thread
From: Nick Kossifidis @ 2018-11-10 17:43 UTC (permalink / raw)
  To: Luke Kenneth Casson Leighton
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, Anup Patel, Palmer Dabbelt, Alexander Graf, zong,
	atish.patra, sw-dev, paul.walmsley, mick, Alistair.Francis,
	linux-riscv, Andrew Waterman

Στις 2018-11-10 17:48, Luke Kenneth Casson Leighton έγραψε:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε:
>> > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
>> > wrote:
>> >
>> >> ## Conclusion
>> >> This proposal is far from perfect and absolutely any suggestion is
>> >> welcome. Obviously, there are many other functionalities that can be
>> >> added to this proposal. However, I just wanted to start with something
>> >> that is an incremental change at best to kick off the discussion. The
>> >> aim here is to initiate a discussion that can lead to a robust SBI
>> >> specification.
>> >
>> >  very cool, atish.
>> >
>> >  i would very much like to see the optional addition of multiple
>> > serial lines, by adding a getchar and putchar function that takes just
>> > one extra argument: the serial line index.
>> >
>> >  there are a lot of different uses to which mult-serial lines may be
>> > put:
>> >
>> >  * boot message separation from console login
>> >  * boot management separation from other purposes (u-boot/coreboot)
>> >  * virtual /dev/ttyS0-3
>> >  * clean UPS reporting and management
>> >  * remote virtual machine power management (power-on / off)
>> >  * simple bog-standard multiple virtual login consoles
>> >  * separation of debug messages (stdout/stderr) to ease debugging and
>> > development
>> >  * remote and virtual OpenOCD and kernel debugging without disrupting
>> > the main serial console
>> >  * PPP serial links.
>> >
>> > this latter is one that i am particularly interested in, as i would
>> > like to be able to boot a full GNU/Linux OS on spike, given the lower
>> > barrier to entry in making modifications and experimenting with spike
>> > than it is with qemu.
>> >
>> >  if spike were able, through a multi-serial SBI interface, to have a
>> > PPP serial line, it would be possible to run a root NFS (or other
>> > network block device) without having to sacrifice console access.  it
>> > would be possible to create an initramfs from a lower-capability
>> > system like buildroot, containing PPP, enable it, and pivot-root out
>> > to a full stock GNU/Linux OS such as debian or fedora.
>> >
>> >  so there are huge benefits, reducing the development barrier to entry
>> > into RISC-V experimentation and debugging, and opening up a much wider
>> > range of capabilities and possibilities for machine and virtual system
>> > management.
>> >
>> > l.
>> 
>> 
>> The current SBI says that console_getchar/console_putchar are for the
>> debug
>> console but on Linux we use them for the main console on earlyprintk.
> 
>  ... yeah exactly.  and what if something goes wrong, you want to be
> able to interact over openocd without interfering with that
> earlyprintk, particularly during that critical first bringup phase of
> real-world silicon?
> 

What does openocd has to do with the console ? Earlyprintk is output
only btw. The point here is that we need to update the documentation
because it's misleading, we don't have a debug console on the current
SBI, just a console.

>> I
>> think it's misleading and we should at least have an argument to chose
>> between the main console and an optional debug console, or rename
>> them to debug_console_getchar/debug_console_putchar and
>> main_console_getchar/
>> main_console_putchar.
> 
>  i initially thought of proposing that, however:
> 
>  (1) the API already exists with "single console". it would therefore
> be disruptive to change that
> 
>  (2) if adding something called debug_console_{get/put}char, it might
> as well take advantage of the opportunity to be extended and made
> generic, and have the extra argument added
> 

I'm not in favor of main_console_getchar/debug_console_getchar etc, I
just wanted to point out that the API should be clear about what
console is to be used, not by using a serial line id but an id
that describes its usage.

>> However I don't think that argument should be the serial line. 
>> Different
>> vendors may use different serial lines for the main console / debug
>> console,
>> the caller doesn't know which serial line maps to which console, so 
>> the
>> SBI
>> should be more abstract and use something like a console id where e.g. 
>> 0
>> is
>> main console an 1 is debug.
> 
>  yes, it should [have]: my feeling is, it's a little late in the game
> given that it's almost certainly baked into pre-existing hardware, by
> now, so the next best thing is a new function call.
> 
> l.

Late in the game ? Who's game ? Is there any "standard" way out there
for mapping consoles to serial line indices ?

Regards,
Nick

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:41         ` olof
  2018-11-10 17:41           ` Olof Johansson
@ 2018-11-10 17:47           ` lkcl
  2018-11-10 17:47             ` Luke Kenneth Casson Leighton
                               ` (3 more replies)
  2018-11-10 17:54           ` mick
  2018-11-10 17:59           ` rminnich
  3 siblings, 4 replies; 67+ messages in thread
From: lkcl @ 2018-11-10 17:47 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:

> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.

 spike (which is only around 7,000 lines of code) doesn't have native
drivers, and qemu is too heavy-duty to consider adding custom
extensions and experimental research onto.

 with nothing in spike *other* than the serial console, it's the only
way in and out.

 l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:47           ` lkcl
@ 2018-11-10 17:47             ` Luke Kenneth Casson Leighton
  2018-11-10 17:59             ` mick
                               ` (2 subsequent siblings)
  3 siblings, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-10 17:47 UTC (permalink / raw)
  To: Olof Johansson
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, ron minnich, sw-dev, paul.walmsley, mick,
	Alistair.Francis, linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:

> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.

 spike (which is only around 7,000 lines of code) doesn't have native
drivers, and qemu is too heavy-duty to consider adding custom
extensions and experimental research onto.

 with nothing in spike *other* than the serial console, it's the only
way in and out.

 l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:42           ` lkcl
  2018-11-10 17:42             ` Luke Kenneth Casson Leighton
@ 2018-11-10 17:51             ` sam.falvo
  2018-11-10 17:51               ` Samuel Falvo II
  2018-11-10 17:55               ` lkcl
  1 sibling, 2 replies; 67+ messages in thread
From: sam.falvo @ 2018-11-10 17:51 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 9:43 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>  it's also not an appropriate argument.  nobody sensible would port a
> POSIX pppd from userspace into boot-level firmware.  the argument also
> ignores the dozens of other advantageous potential use-cases.

Regrettably, if it's one thing we've all learned from PC clone
manufacturers and BIOS vendors, it's that they're not sensible.
They're not reasonable.  And they're anything but sane.

Servers designed for use in data centers are on the market right now
with adapters fully equipped with TCP/IP stacks in firmware *just* to
give a remote operator control over a computer's PS/2 or serial ports,
for instance.

You can bank that it'll happen with RISC-V as well.

-- 
Samuel A. Falvo II

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:51             ` sam.falvo
@ 2018-11-10 17:51               ` Samuel Falvo II
  2018-11-10 17:55               ` lkcl
  1 sibling, 0 replies; 67+ messages in thread
From: Samuel Falvo II @ 2018-11-10 17:51 UTC (permalink / raw)
  To: Luke Kenneth Casson Leighton
  Cc: mark.rutland, hch, Damien.LeMoal, olof.johansson, alankao, Chang,
	Abner, atish.patra, Anup Patel, Palmer Dabbelt, agraf, zong,
	ron minnich, sw-dev, paul.walmsley, mick, Alistair.Francis,
	linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 9:43 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>  it's also not an appropriate argument.  nobody sensible would port a
> POSIX pppd from userspace into boot-level firmware.  the argument also
> ignores the dozens of other advantageous potential use-cases.

Regrettably, if it's one thing we've all learned from PC clone
manufacturers and BIOS vendors, it's that they're not sensible.
They're not reasonable.  And they're anything but sane.

Servers designed for use in data centers are on the market right now
with adapters fully equipped with TCP/IP stacks in firmware *just* to
give a remote operator control over a computer's PS/2 or serial ports,
for instance.

You can bank that it'll happen with RISC-V as well.

-- 
Samuel A. Falvo II

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:43       ` mick
  2018-11-10 17:43         ` Nick Kossifidis
@ 2018-11-10 17:51         ` lkcl
  2018-11-10 17:51           ` Luke Kenneth Casson Leighton
  1 sibling, 1 reply; 67+ messages in thread
From: lkcl @ 2018-11-10 17:51 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 5:45 PM Nick Kossifidis <mick@ics.forth.gr> wrote:

> >  yes, it should [have]: my feeling is, it's a little late in the game
> > given that it's almost certainly baked into pre-existing hardware, by
> > now, so the next best thing is a new function call.
> >
> > l.
>
> Late in the game ? Who's game ? Is there any "standard" way out there
> for mapping consoles to serial line indices ?

 any implementor that has put a SBI v1.0 into a boot ROM in production
silicon (or even has put it into a design that's already had USD $5m+
of engineering time and testing done), would be absolutely screwed by
changes to v1.0 SBI.

 if however... if a way could be found to negotiate v1.0 being as-is,
and v2.0 declaring that there was an extra argument? yeah that would
work.

 i don't mind either way: i just really need to not have to have the
financial burden of augmenting and maintaining special ports of half a
dozen applications including minicom.

l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:51         ` lkcl
@ 2018-11-10 17:51           ` Luke Kenneth Casson Leighton
  0 siblings, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-10 17:51 UTC (permalink / raw)
  To: mick
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, Anup Patel, Palmer Dabbelt, Alexander Graf, zong,
	atish.patra, sw-dev, paul.walmsley, Alistair.Francis,
	linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 5:45 PM Nick Kossifidis <mick@ics.forth.gr> wrote:

> >  yes, it should [have]: my feeling is, it's a little late in the game
> > given that it's almost certainly baked into pre-existing hardware, by
> > now, so the next best thing is a new function call.
> >
> > l.
>
> Late in the game ? Who's game ? Is there any "standard" way out there
> for mapping consoles to serial line indices ?

 any implementor that has put a SBI v1.0 into a boot ROM in production
silicon (or even has put it into a design that's already had USD $5m+
of engineering time and testing done), would be absolutely screwed by
changes to v1.0 SBI.

 if however... if a way could be found to negotiate v1.0 being as-is,
and v2.0 declaring that there was an extra argument? yeah that would
work.

 i don't mind either way: i just really need to not have to have the
financial burden of augmenting and maintaining special ports of half a
dozen applications including minicom.

l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:41         ` olof
  2018-11-10 17:41           ` Olof Johansson
  2018-11-10 17:47           ` lkcl
@ 2018-11-10 17:54           ` mick
  2018-11-10 17:54             ` Nick Kossifidis
  2018-11-10 17:59           ` rminnich
  3 siblings, 1 reply; 67+ messages in thread
From: mick @ 2018-11-10 17:54 UTC (permalink / raw)
  To: linux-riscv

???? 2018-11-10 19:41, Olof Johansson ??????:
> On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote:
>> 
>> At Google and other places, we've been struggling now for years with
>> overly complex firmware that is implemented incorrectly, enabling
>> exploits and other bad things. The list of things vendors get wrong in
>> firmware, both enabling exploits and enabling others to enable
>> exploits, is long and it continues to this day. There is an
>> unbelievable amount of money out there all involving firmware
>> exploits, very little of it involving nice people.
>> 
>> I'm currently working on deleting all use of the x86 version of M
>> mode, i.e. SMM. There are many proposals out there for deleting SMM
>> from the architecture. I've also shown at a talk in 2017 how we could
>> redirect SMM interrupts back into the kernel. We're also removing all
>> use of callbacks into UEFI on x86. We're almost there.
>> 
>> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
>> proposals for M- mode code. PPP in firmware? Really? multiple serial
>> devices? really? We've been here before, in the 1970s, with something
>> called the BIOS. If you're not familiar with it, go take a look, or
>> you can take my word for it that these proposals implement that idea.
>> We spent over 20 years freeing ourselves from it on x86. Why go back
>> to a 50 year old model on a CPU designed to be in use for 50 years?
>> 
>> My early understanding of M mode was that it was an Alpha PALCode like
>> thing, enabling access to resources that were behind a privilege wall.
>> I did not like it that much, but I was OK: it was very limited in
>> function, and the kernel could replace it, or at least measure it. I
>> also accept that every cpu vendor uses m mode like things (e.g. ARM
>> TF) for reasonable purposes and also (let's be honest here)  for
>> dealing with chipset mistakes. But that does not mean you need to
>> recreate BIOS.
>> 
>> The SBI should be hard to add to, deliberately. It should be used only
>> when there are no possible alternatives. It needs to be open source
>> and held in common. It should be possible for a kernel to replace or
>> at least measure it. And, further, there needs to be some work done on
>> why you add to it, and why you don't, with bias against adding to it.
>> This proposal works against those ideals, as it explicitly enables
>> vendor-specific forks of the SBI. Sure, this can happen, but why make
>> it so easy?
> 
> There's a tension between letting people do the messy things that real
> hardware sometimes needs without polluting higher layers in the
> software stack, and letting them do too much of things that _should_
> be handled in the upper layers. I have yet to find a solution that
> doesn't need tweaking over time, the pendulum tends to swing back and
> forth into "too far" in both directions sometimes.
> 
> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.
> 
> Having to do fine-grained arbitration of device ownership between
> firmware and kernel at runtime is usually error prone and awkward and
> best to avoid.
> 
> 

+1

>> p.s. For interleaving debug and console output firmware, use the
>> oldest trick in the book: ASCII is 7 bits. Since console out is 8
>> bits, reserve 128 values for console out, and 128 for debug stream,
>> and if the debug stream needs 8 bit for some words, you know what to
>> do. It's very easy and doesn't require that we add multiple UART
>> support to SBI.
> 
> Sure, it helps for 2 channels. And then beyond that you need a more
> complex protocol. Either way, it's not a problem we need to solve here
> and now.
> 

+1, most people will just use minicom/picocom to do their job, not 
implement
a protocol over serial for splitting main console from debug console.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:54           ` mick
@ 2018-11-10 17:54             ` Nick Kossifidis
  0 siblings, 0 replies; 67+ messages in thread
From: Nick Kossifidis @ 2018-11-10 17:54 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Mark Rutland, Christoph Hellwig, Damien.LeMoal, olof johansson,
	alankao, abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, rminnich, sw-dev, paul.walmsley, mick,
	Alistair.Francis, lkcl, linux-riscv, Andrew Waterman

Στις 2018-11-10 19:41, Olof Johansson έγραψε:
> On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote:
>> 
>> At Google and other places, we've been struggling now for years with
>> overly complex firmware that is implemented incorrectly, enabling
>> exploits and other bad things. The list of things vendors get wrong in
>> firmware, both enabling exploits and enabling others to enable
>> exploits, is long and it continues to this day. There is an
>> unbelievable amount of money out there all involving firmware
>> exploits, very little of it involving nice people.
>> 
>> I'm currently working on deleting all use of the x86 version of M
>> mode, i.e. SMM. There are many proposals out there for deleting SMM
>> from the architecture. I've also shown at a talk in 2017 how we could
>> redirect SMM interrupts back into the kernel. We're also removing all
>> use of callbacks into UEFI on x86. We're almost there.
>> 
>> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
>> proposals for M- mode code. PPP in firmware? Really? multiple serial
>> devices? really? We've been here before, in the 1970s, with something
>> called the BIOS. If you're not familiar with it, go take a look, or
>> you can take my word for it that these proposals implement that idea.
>> We spent over 20 years freeing ourselves from it on x86. Why go back
>> to a 50 year old model on a CPU designed to be in use for 50 years?
>> 
>> My early understanding of M mode was that it was an Alpha PALCode like
>> thing, enabling access to resources that were behind a privilege wall.
>> I did not like it that much, but I was OK: it was very limited in
>> function, and the kernel could replace it, or at least measure it. I
>> also accept that every cpu vendor uses m mode like things (e.g. ARM
>> TF) for reasonable purposes and also (let's be honest here)  for
>> dealing with chipset mistakes. But that does not mean you need to
>> recreate BIOS.
>> 
>> The SBI should be hard to add to, deliberately. It should be used only
>> when there are no possible alternatives. It needs to be open source
>> and held in common. It should be possible for a kernel to replace or
>> at least measure it. And, further, there needs to be some work done on
>> why you add to it, and why you don't, with bias against adding to it.
>> This proposal works against those ideals, as it explicitly enables
>> vendor-specific forks of the SBI. Sure, this can happen, but why make
>> it so easy?
> 
> There's a tension between letting people do the messy things that real
> hardware sometimes needs without polluting higher layers in the
> software stack, and letting them do too much of things that _should_
> be handled in the upper layers. I have yet to find a solution that
> doesn't need tweaking over time, the pendulum tends to swing back and
> forth into "too far" in both directions sometimes.
> 
> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.
> 
> Having to do fine-grained arbitration of device ownership between
> firmware and kernel at runtime is usually error prone and awkward and
> best to avoid.
> 
> 

+1

>> p.s. For interleaving debug and console output firmware, use the
>> oldest trick in the book: ASCII is 7 bits. Since console out is 8
>> bits, reserve 128 values for console out, and 128 for debug stream,
>> and if the debug stream needs 8 bit for some words, you know what to
>> do. It's very easy and doesn't require that we add multiple UART
>> support to SBI.
> 
> Sure, it helps for 2 channels. And then beyond that you need a more
> complex protocol. Either way, it's not a problem we need to solve here
> and now.
> 

+1, most people will just use minicom/picocom to do their job, not 
implement
a protocol over serial for splitting main console from debug console.


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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:51             ` sam.falvo
  2018-11-10 17:51               ` Samuel Falvo II
@ 2018-11-10 17:55               ` lkcl
  2018-11-10 17:55                 ` Luke Kenneth Casson Leighton
  2018-11-10 18:03                 ` sam.falvo
  1 sibling, 2 replies; 67+ messages in thread
From: lkcl @ 2018-11-10 17:55 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 5:48 PM Samuel Falvo II <sam.falvo@gmail.com> wrote:

> On Sat, Nov 10, 2018 at 9:43 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> >  it's also not an appropriate argument.  nobody sensible would port a
> > POSIX pppd from userspace into boot-level firmware.  the argument also
> > ignores the dozens of other advantageous potential use-cases.
>
> Regrettably, if it's one thing we've all learned from PC clone
> manufacturers and BIOS vendors, it's that they're not sensible.
> They're not reasonable.  And they're anything but sane.
>
> Servers designed for use in data centers are on the market right now
> with adapters fully equipped with TCP/IP stacks in firmware *just* to
> give a remote operator control over a computer's PS/2 or serial ports,
> for instance.
>
> You can bank that it'll happen with RISC-V as well.

 *snort* yeah.  is that a good enough reason to terminate all and any
discussion of enhancing a general-purpose generic API that has several
other beneficial use-cases?  reminds me of the adage "guns don't kill
people: people kill people".

l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:55               ` lkcl
@ 2018-11-10 17:55                 ` Luke Kenneth Casson Leighton
  2018-11-10 18:03                 ` sam.falvo
  1 sibling, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-10 17:55 UTC (permalink / raw)
  To: Samuel Falvo II
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, ron minnich, sw-dev, paul.walmsley, mick,
	Alistair.Francis, linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 5:48 PM Samuel Falvo II <sam.falvo@gmail.com> wrote:

> On Sat, Nov 10, 2018 at 9:43 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> >  it's also not an appropriate argument.  nobody sensible would port a
> > POSIX pppd from userspace into boot-level firmware.  the argument also
> > ignores the dozens of other advantageous potential use-cases.
>
> Regrettably, if it's one thing we've all learned from PC clone
> manufacturers and BIOS vendors, it's that they're not sensible.
> They're not reasonable.  And they're anything but sane.
>
> Servers designed for use in data centers are on the market right now
> with adapters fully equipped with TCP/IP stacks in firmware *just* to
> give a remote operator control over a computer's PS/2 or serial ports,
> for instance.
>
> You can bank that it'll happen with RISC-V as well.

 *snort* yeah.  is that a good enough reason to terminate all and any
discussion of enhancing a general-purpose generic API that has several
other beneficial use-cases?  reminds me of the adage "guns don't kill
people: people kill people".

l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:41         ` olof
                             ` (2 preceding siblings ...)
  2018-11-10 17:54           ` mick
@ 2018-11-10 17:59           ` rminnich
  2018-11-10 17:59             ` ron minnich
  3 siblings, 1 reply; 67+ messages in thread
From: rminnich @ 2018-11-10 17:59 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 9:42 AM Olof Johansson <olof@lixom.net> wrote:

> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.
>
> Having to do fine-grained arbitration of device ownership between
> firmware and kernel at runtime is usually error prone and awkward and
> best to avoid.


Totally agree. OK, so, at least we don't need the "index" in the SBI
call to pick a console, right?

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:59           ` rminnich
@ 2018-11-10 17:59             ` ron minnich
  0 siblings, 0 replies; 67+ messages in thread
From: ron minnich @ 2018-11-10 17:59 UTC (permalink / raw)
  To: olof
  Cc: mark.rutland, Christoph Hellwig, Damien.LeMoal, Olof Johansson,
	alankao, abner.chang, Anup Patel, Palmer Dabbelt, agraf, zong,
	atish.patra, sw-dev, Paul Walmsley, mick, Alistair.Francis,
	Luke Kenneth Casson Leighton, linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 9:42 AM Olof Johansson <olof@lixom.net> wrote:

> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.
>
> Having to do fine-grained arbitration of device ownership between
> firmware and kernel at runtime is usually error prone and awkward and
> best to avoid.


Totally agree. OK, so, at least we don't need the "index" in the SBI
call to pick a console, right?

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:47           ` lkcl
  2018-11-10 17:47             ` Luke Kenneth Casson Leighton
@ 2018-11-10 17:59             ` mick
  2018-11-10 17:59               ` Nick Kossifidis
                                 ` (2 more replies)
  2018-11-10 18:02             ` olof
  2018-11-13  1:22             ` michaeljclark
  3 siblings, 3 replies; 67+ messages in thread
From: mick @ 2018-11-10 17:59 UTC (permalink / raw)
  To: linux-riscv

???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> 
>> The case of console is in this case pretty simple: It's intended for
>> early boot for very simplistic environments (before the rest of the
>> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> and somehow trying to optimize for it for those use cases is a
>> misdirected effort; that's what native drivers are for.
> 
>  spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.
> 
>  with nothing in spike *other* than the serial console, it's the only
> way in and out.
> 
>  l.

Anything more than a main/debug console is too much for the SBI, its
goal is to be used early on in the boot process until the OS or the
bare metal app takes control. Having multiple serial lines through
the SBI for things like PPP, UPS, virtual consoles and all the stuff
you mentioned is out of scope. Boot an OS and use the standard UART
drivers for accessing the serial lines. If there are no drivers
or support on spike, it's open source ! Also you may always use
the vendor specific SBI that Atish proposes here for adding that
functionality, having this on the base SBI is not the right
approach IMHO.

Regards,
Nick

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 17:59             ` mick
@ 2018-11-10 17:59               ` Nick Kossifidis
  2018-11-10 18:01               ` rminnich
  2018-11-10 19:39               ` lkcl
  2 siblings, 0 replies; 67+ messages in thread
From: Nick Kossifidis @ 2018-11-10 17:59 UTC (permalink / raw)
  To: Luke Kenneth Casson Leighton
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, ron minnich, mick, sw-dev, paul.walmsley,
	Olof Johansson, Alistair.Francis, linux-riscv, Andrew Waterman

Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> 
>> The case of console is in this case pretty simple: It's intended for
>> early boot for very simplistic environments (before the rest of the
>> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> and somehow trying to optimize for it for those use cases is a
>> misdirected effort; that's what native drivers are for.
> 
>  spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.
> 
>  with nothing in spike *other* than the serial console, it's the only
> way in and out.
> 
>  l.

Anything more than a main/debug console is too much for the SBI, its
goal is to be used early on in the boot process until the OS or the
bare metal app takes control. Having multiple serial lines through
the SBI for things like PPP, UPS, virtual consoles and all the stuff
you mentioned is out of scope. Boot an OS and use the standard UART
drivers for accessing the serial lines. If there are no drivers
or support on spike, it's open source ! Also you may always use
the vendor specific SBI that Atish proposes here for adding that
functionality, having this on the base SBI is not the right
approach IMHO.

Regards,
Nick

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:59             ` mick
  2018-11-10 17:59               ` Nick Kossifidis
@ 2018-11-10 18:01               ` rminnich
  2018-11-10 18:01                 ` ron minnich
  2018-11-10 19:33                 ` lkcl
  2018-11-10 19:39               ` lkcl
  2 siblings, 2 replies; 67+ messages in thread
From: rminnich @ 2018-11-10 18:01 UTC (permalink / raw)
  To: linux-riscv

Actually, as long as the option remains to let the kernel replace the
SBI with something else, I'm not that worried about what vendors put
in it. But that option needs to remain there.
On Sat, Nov 10, 2018 at 9:59 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >
> >> The case of console is in this case pretty simple: It's intended for
> >> early boot for very simplistic environments (before the rest of the
> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> and somehow trying to optimize for it for those use cases is a
> >> misdirected effort; that's what native drivers are for.
> >
> >  spike (which is only around 7,000 lines of code) doesn't have native
> > drivers, and qemu is too heavy-duty to consider adding custom
> > extensions and experimental research onto.
> >
> >  with nothing in spike *other* than the serial console, it's the only
> > way in and out.
> >
> >  l.
>
> Anything more than a main/debug console is too much for the SBI, its
> goal is to be used early on in the boot process until the OS or the
> bare metal app takes control. Having multiple serial lines through
> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> you mentioned is out of scope. Boot an OS and use the standard UART
> drivers for accessing the serial lines. If there are no drivers
> or support on spike, it's open source ! Also you may always use
> the vendor specific SBI that Atish proposes here for adding that
> functionality, having this on the base SBI is not the right
> approach IMHO.
>
> Regards,
> Nick

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 18:01               ` rminnich
@ 2018-11-10 18:01                 ` ron minnich
  2018-11-10 19:33                 ` lkcl
  1 sibling, 0 replies; 67+ messages in thread
From: ron minnich @ 2018-11-10 18:01 UTC (permalink / raw)
  To: mick
  Cc: mark.rutland, Christoph Hellwig, Damien.LeMoal, Olof Johansson,
	alankao, abner.chang, Anup Patel, Palmer Dabbelt, Alexander Graf,
	zong, atish.patra, sw-dev, Paul Walmsley, olof, Alistair.Francis,
	Luke Kenneth Casson Leighton, linux-riscv, Andrew Waterman

Actually, as long as the option remains to let the kernel replace the
SBI with something else, I'm not that worried about what vendors put
in it. But that option needs to remain there.
On Sat, Nov 10, 2018 at 9:59 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >
> >> The case of console is in this case pretty simple: It's intended for
> >> early boot for very simplistic environments (before the rest of the
> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> and somehow trying to optimize for it for those use cases is a
> >> misdirected effort; that's what native drivers are for.
> >
> >  spike (which is only around 7,000 lines of code) doesn't have native
> > drivers, and qemu is too heavy-duty to consider adding custom
> > extensions and experimental research onto.
> >
> >  with nothing in spike *other* than the serial console, it's the only
> > way in and out.
> >
> >  l.
>
> Anything more than a main/debug console is too much for the SBI, its
> goal is to be used early on in the boot process until the OS or the
> bare metal app takes control. Having multiple serial lines through
> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> you mentioned is out of scope. Boot an OS and use the standard UART
> drivers for accessing the serial lines. If there are no drivers
> or support on spike, it's open source ! Also you may always use
> the vendor specific SBI that Atish proposes here for adding that
> functionality, having this on the base SBI is not the right
> approach IMHO.
>
> Regards,
> Nick

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:47           ` lkcl
  2018-11-10 17:47             ` Luke Kenneth Casson Leighton
  2018-11-10 17:59             ` mick
@ 2018-11-10 18:02             ` olof
  2018-11-10 18:02               ` Olof Johansson
  2018-11-10 19:34               ` lkcl
  2018-11-13  1:22             ` michaeljclark
  3 siblings, 2 replies; 67+ messages in thread
From: olof @ 2018-11-10 18:02 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 9:47 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>
> > The case of console is in this case pretty simple: It's intended for
> > early boot for very simplistic environments (before the rest of the
> > kernel is up, etc). Keeping the SBI console around beyond early boot,
> > and somehow trying to optimize for it for those use cases is a
> > misdirected effort; that's what native drivers are for.
>
>  spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.
>
>  with nothing in spike *other* than the serial console, it's the only
> way in and out.

I'll repeat myself:

"trying to optimize for those use cases is a misdirected effort".
Trying to optimize your experience on spike at the cost of simplicity
for everybody else is the wrong thing to do.


-Olof

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 18:02             ` olof
@ 2018-11-10 18:02               ` Olof Johansson
  2018-11-10 19:34               ` lkcl
  1 sibling, 0 replies; 67+ messages in thread
From: Olof Johansson @ 2018-11-10 18:02 UTC (permalink / raw)
  To: lkcl
  Cc: Mark Rutland, Christoph Hellwig, Damien.LeMoal, olof johansson,
	alankao, abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, rminnich, sw-dev, paul.walmsley, mick,
	Alistair.Francis, linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 9:47 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>
> > The case of console is in this case pretty simple: It's intended for
> > early boot for very simplistic environments (before the rest of the
> > kernel is up, etc). Keeping the SBI console around beyond early boot,
> > and somehow trying to optimize for it for those use cases is a
> > misdirected effort; that's what native drivers are for.
>
>  spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.
>
>  with nothing in spike *other* than the serial console, it's the only
> way in and out.

I'll repeat myself:

"trying to optimize for those use cases is a misdirected effort".
Trying to optimize your experience on spike at the cost of simplicity
for everybody else is the wrong thing to do.


-Olof

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:55               ` lkcl
  2018-11-10 17:55                 ` Luke Kenneth Casson Leighton
@ 2018-11-10 18:03                 ` sam.falvo
  2018-11-10 18:03                   ` Samuel Falvo II
  1 sibling, 1 reply; 67+ messages in thread
From: sam.falvo @ 2018-11-10 18:03 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 9:55 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>  *snort* yeah.  is that a good enough reason to terminate all and any
> discussion of enhancing a general-purpose generic API that has several
> other beneficial use-cases?  reminds me of the adage "guns don't kill
> people: people kill people".

I think you are misunderstanding what I'm writing.

My tale is one of caution, not prevention.  I'm OK with having a BIOS.
History shows that the problems on the PC platform all started when
the BIOS *disappeared*; when it *stopped* *being* a BIOS.

My claim is that Ron's reaction is, while well-intentioned and has
solid roots in first-hand experience, nonetheless a bit extreme.  Not
having any BIOS at all is, in my estimation, worse than having one
that is 50 years old.

-- 
Samuel A. Falvo II

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 18:03                 ` sam.falvo
@ 2018-11-10 18:03                   ` Samuel Falvo II
  0 siblings, 0 replies; 67+ messages in thread
From: Samuel Falvo II @ 2018-11-10 18:03 UTC (permalink / raw)
  To: Luke Kenneth Casson Leighton
  Cc: mark.rutland, hch, Damien.LeMoal, olof.johansson, alankao, Chang,
	Abner, atish.patra, Anup Patel, Palmer Dabbelt, agraf, zong,
	ron minnich, sw-dev, paul.walmsley, mick, Alistair.Francis,
	linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 9:55 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>  *snort* yeah.  is that a good enough reason to terminate all and any
> discussion of enhancing a general-purpose generic API that has several
> other beneficial use-cases?  reminds me of the adage "guns don't kill
> people: people kill people".

I think you are misunderstanding what I'm writing.

My tale is one of caution, not prevention.  I'm OK with having a BIOS.
History shows that the problems on the PC platform all started when
the BIOS *disappeared*; when it *stopped* *being* a BIOS.

My claim is that Ron's reaction is, while well-intentioned and has
solid roots in first-hand experience, nonetheless a bit extreme.  Not
having any BIOS at all is, in my estimation, worse than having one
that is 50 years old.

-- 
Samuel A. Falvo II

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 18:01               ` rminnich
  2018-11-10 18:01                 ` ron minnich
@ 2018-11-10 19:33                 ` lkcl
  2018-11-10 19:33                   ` Luke Kenneth Casson Leighton
  1 sibling, 1 reply; 67+ messages in thread
From: lkcl @ 2018-11-10 19:33 UTC (permalink / raw)
  To: linux-riscv

On Sat, Nov 10, 2018 at 6:02 PM ron minnich <rminnich@gmail.com> wrote:

> Actually, as long as the option remains to let the kernel replace the
> SBI with something else, I'm not that worried about what vendors put
> in it. But that option needs to remain there.

 i remember you saying, when the boot discussion came up a couple
weeks ago, and agree absolutely: the option in real hardware to shut
off and replace whatever's got you up and running is critical.

 there's a huge range of uses to which SBI is (and can be) put: i
threw some ideas out there, i feel it's important to bear that in
mind.  it's not just used for booting, it's also got simulation,
debugging, development and critical first silicon bring-up potential,
out-of-band remote power management potential uses, virtual management
potential, and shed-loads more.

l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 19:33                 ` lkcl
@ 2018-11-10 19:33                   ` Luke Kenneth Casson Leighton
  0 siblings, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-10 19:33 UTC (permalink / raw)
  To: ron minnich
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, Olof Johansson, sw-dev, paul.walmsley,
	mick, Alistair.Francis, linux-riscv, Andrew Waterman

On Sat, Nov 10, 2018 at 6:02 PM ron minnich <rminnich@gmail.com> wrote:

> Actually, as long as the option remains to let the kernel replace the
> SBI with something else, I'm not that worried about what vendors put
> in it. But that option needs to remain there.

 i remember you saying, when the boot discussion came up a couple
weeks ago, and agree absolutely: the option in real hardware to shut
off and replace whatever's got you up and running is critical.

 there's a huge range of uses to which SBI is (and can be) put: i
threw some ideas out there, i feel it's important to bear that in
mind.  it's not just used for booting, it's also got simulation,
debugging, development and critical first silicon bring-up potential,
out-of-band remote power management potential uses, virtual management
potential, and shed-loads more.

l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 18:02             ` olof
  2018-11-10 18:02               ` Olof Johansson
@ 2018-11-10 19:34               ` lkcl
  2018-11-10 19:34                 ` Luke Kenneth Casson Leighton
  1 sibling, 1 reply; 67+ messages in thread
From: lkcl @ 2018-11-10 19:34 UTC (permalink / raw)
  To: linux-riscv

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 6:03 PM Olof Johansson <olof@lixom.net> wrote:

> "trying to optimize for those use cases is a misdirected effort".
> Trying to optimize your experience on spike at the cost of simplicity
> for everybody else is the wrong thing to do.

 i hear you on why you believe it's an optimisation: i get it, it's a
public API.  that's why i put out a shed-load of other potential
use-cases.

l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 19:34               ` lkcl
@ 2018-11-10 19:34                 ` Luke Kenneth Casson Leighton
  0 siblings, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-10 19:34 UTC (permalink / raw)
  To: Olof Johansson
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, ron minnich, sw-dev, paul.walmsley, mick,
	Alistair.Francis, linux-riscv, Andrew Waterman

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 6:03 PM Olof Johansson <olof@lixom.net> wrote:

> "trying to optimize for those use cases is a misdirected effort".
> Trying to optimize your experience on spike at the cost of simplicity
> for everybody else is the wrong thing to do.

 i hear you on why you believe it's an optimisation: i get it, it's a
public API.  that's why i put out a shed-load of other potential
use-cases.

l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:59             ` mick
  2018-11-10 17:59               ` Nick Kossifidis
  2018-11-10 18:01               ` rminnich
@ 2018-11-10 19:39               ` lkcl
  2018-11-10 19:39                 ` Luke Kenneth Casson Leighton
  2018-11-11  3:15                 ` mick
  2 siblings, 2 replies; 67+ messages in thread
From: lkcl @ 2018-11-10 19:39 UTC (permalink / raw)
  To: linux-riscv

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >
> >> The case of console is in this case pretty simple: It's intended for
> >> early boot for very simplistic environments (before the rest of the
> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> and somehow trying to optimize for it for those use cases is a
> >> misdirected effort; that's what native drivers are for.
> >
> >  spike (which is only around 7,000 lines of code) doesn't have native
> > drivers, and qemu is too heavy-duty to consider adding custom
> > extensions and experimental research onto.
> >
> >  with nothing in spike *other* than the serial console, it's the only
> > way in and out.
> >
> >  l.
>
> Anything more than a main/debug console is too much for the SBI, its
> goal is to be used early on in the boot process until the OS or the
> bare metal app takes control.

 nooo, that's just _one_ use to which it's being put.

> Having multiple serial lines through
> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> you mentioned is out of scope.

 why?

> Boot an OS and use the standard UART
> drivers for accessing the serial lines. If there are no drivers
> or support on spike, it's open source !

 this is a common misconception that "because it's open source anyone
can do what they want".  code costs money.  servers to host code cost
money.  answering the emails where people expect "free" support
because you're hosting the only public version of that server costs
money.

 i'm an ethical libre developer: i can't go footing the bill for other
people to sponge off my efforts all the time, i've had 20 years of
people doing that and i'm f*****g well not putting up with it on this
project.

 so no, mick, sorry, not buying the argument "it's open source".

l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-10 19:39               ` lkcl
@ 2018-11-10 19:39                 ` Luke Kenneth Casson Leighton
  2018-11-11  3:15                 ` mick
  1 sibling, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-10 19:39 UTC (permalink / raw)
  To: mick
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, ron minnich, sw-dev, paul.walmsley,
	Olof Johansson, Alistair.Francis, linux-riscv, Andrew Waterman

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >
> >> The case of console is in this case pretty simple: It's intended for
> >> early boot for very simplistic environments (before the rest of the
> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> and somehow trying to optimize for it for those use cases is a
> >> misdirected effort; that's what native drivers are for.
> >
> >  spike (which is only around 7,000 lines of code) doesn't have native
> > drivers, and qemu is too heavy-duty to consider adding custom
> > extensions and experimental research onto.
> >
> >  with nothing in spike *other* than the serial console, it's the only
> > way in and out.
> >
> >  l.
>
> Anything more than a main/debug console is too much for the SBI, its
> goal is to be used early on in the boot process until the OS or the
> bare metal app takes control.

 nooo, that's just _one_ use to which it's being put.

> Having multiple serial lines through
> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> you mentioned is out of scope.

 why?

> Boot an OS and use the standard UART
> drivers for accessing the serial lines. If there are no drivers
> or support on spike, it's open source !

 this is a common misconception that "because it's open source anyone
can do what they want".  code costs money.  servers to host code cost
money.  answering the emails where people expect "free" support
because you're hosting the only public version of that server costs
money.

 i'm an ethical libre developer: i can't go footing the bill for other
people to sponge off my efforts all the time, i've had 20 years of
people doing that and i'm f*****g well not putting up with it on this
project.

 so no, mick, sorry, not buying the argument "it's open source".

l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 19:39               ` lkcl
  2018-11-10 19:39                 ` Luke Kenneth Casson Leighton
@ 2018-11-11  3:15                 ` mick
  2018-11-11  3:15                   ` Nick Kossifidis
  2018-11-11  7:14                   ` lkcl
  1 sibling, 2 replies; 67+ messages in thread
From: mick @ 2018-11-11  3:15 UTC (permalink / raw)
  To: linux-riscv

???? 2018-11-10 21:39, Luke Kenneth Casson Leighton ??????:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
>> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >
>> >> The case of console is in this case pretty simple: It's intended for
>> >> early boot for very simplistic environments (before the rest of the
>> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> and somehow trying to optimize for it for those use cases is a
>> >> misdirected effort; that's what native drivers are for.
>> >
>> >  spike (which is only around 7,000 lines of code) doesn't have native
>> > drivers, and qemu is too heavy-duty to consider adding custom
>> > extensions and experimental research onto.
>> >
>> >  with nothing in spike *other* than the serial console, it's the only
>> > way in and out.
>> >
>> >  l.
>> 
>> Anything more than a main/debug console is too much for the SBI, its
>> goal is to be used early on in the boot process until the OS or the
>> bare metal app takes control.
> 
>  nooo, that's just _one_ use to which it's being put.
> 
>> Having multiple serial lines through
>> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> you mentioned is out of scope.
> 
>  why?
> 

Because the firmware is meant to be something minimal, not to replace 
the
OS. Let me ask you this, if you want to change UART speed or settings in
general would you also ask for an SBI call for that ? What's coming up
next ? Adding networking support for example ? Where do you put the 
barrier
on firmware's complexity / scope ?

>> Boot an OS and use the standard UART
>> drivers for accessing the serial lines. If there are no drivers
>> or support on spike, it's open source !
> 
>  this is a common misconception that "because it's open source anyone
> can do what they want".  code costs money.  servers to host code cost
> money.  answering the emails where people expect "free" support
> because you're hosting the only public version of that server costs
> money.
> 

Even if we decide that the SBI gets extended for accessing different
serial lines, someone will have to write code for that e.g. on BBL or on
OpenSBI, coreboot etc. If we follow your logic, maintaining, hosting
and supporting this also costs money. So what's the point here ? That
it's easier to implement it there for everyone than write a UART driver
for spike ?

By the way spike is an ISA simulator, I don't see why it should emulate
UART ports, last time I checked it didn't, so someone will need to write
code for that, more money ! You can use QEMU for that where you can have
as many UARTs as you want and the drivers for them are already available
for you.

>  i'm an ethical libre developer: i can't go footing the bill for other
> people to sponge off my efforts all the time, i've had 20 years of
> people doing that and i'm f*****g well not putting up with it on this
> project.
> 
>  so no, mick, sorry, not buying the argument "it's open source".
> 
> l.

Don't assume you are the only one.

Regards,
Nick

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-11  3:15                 ` mick
@ 2018-11-11  3:15                   ` Nick Kossifidis
  2018-11-11  7:14                   ` lkcl
  1 sibling, 0 replies; 67+ messages in thread
From: Nick Kossifidis @ 2018-11-11  3:15 UTC (permalink / raw)
  To: Luke Kenneth Casson Leighton
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, Olof Johansson, ron minnich, sw-dev,
	paul.walmsley, mick, Alistair.Francis, linux-riscv,
	Andrew Waterman

Στις 2018-11-10 21:39, Luke Kenneth Casson Leighton έγραψε:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
>> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >
>> >> The case of console is in this case pretty simple: It's intended for
>> >> early boot for very simplistic environments (before the rest of the
>> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> and somehow trying to optimize for it for those use cases is a
>> >> misdirected effort; that's what native drivers are for.
>> >
>> >  spike (which is only around 7,000 lines of code) doesn't have native
>> > drivers, and qemu is too heavy-duty to consider adding custom
>> > extensions and experimental research onto.
>> >
>> >  with nothing in spike *other* than the serial console, it's the only
>> > way in and out.
>> >
>> >  l.
>> 
>> Anything more than a main/debug console is too much for the SBI, its
>> goal is to be used early on in the boot process until the OS or the
>> bare metal app takes control.
> 
>  nooo, that's just _one_ use to which it's being put.
> 
>> Having multiple serial lines through
>> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> you mentioned is out of scope.
> 
>  why?
> 

Because the firmware is meant to be something minimal, not to replace 
the
OS. Let me ask you this, if you want to change UART speed or settings in
general would you also ask for an SBI call for that ? What's coming up
next ? Adding networking support for example ? Where do you put the 
barrier
on firmware's complexity / scope ?

>> Boot an OS and use the standard UART
>> drivers for accessing the serial lines. If there are no drivers
>> or support on spike, it's open source !
> 
>  this is a common misconception that "because it's open source anyone
> can do what they want".  code costs money.  servers to host code cost
> money.  answering the emails where people expect "free" support
> because you're hosting the only public version of that server costs
> money.
> 

Even if we decide that the SBI gets extended for accessing different
serial lines, someone will have to write code for that e.g. on BBL or on
OpenSBI, coreboot etc. If we follow your logic, maintaining, hosting
and supporting this also costs money. So what's the point here ? That
it's easier to implement it there for everyone than write a UART driver
for spike ?

By the way spike is an ISA simulator, I don't see why it should emulate
UART ports, last time I checked it didn't, so someone will need to write
code for that, more money ! You can use QEMU for that where you can have
as many UARTs as you want and the drivers for them are already available
for you.

>  i'm an ethical libre developer: i can't go footing the bill for other
> people to sponge off my efforts all the time, i've had 20 years of
> people doing that and i'm f*****g well not putting up with it on this
> project.
> 
>  so no, mick, sorry, not buying the argument "it's open source".
> 
> l.

Don't assume you are the only one.

Regards,
Nick


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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 16:46       ` rminnich
                           ` (3 preceding siblings ...)
  2018-11-10 17:41         ` olof
@ 2018-11-11  3:58         ` atish.patra
  2018-11-11  3:58           ` Atish Patra
  4 siblings, 1 reply; 67+ messages in thread
From: atish.patra @ 2018-11-11  3:58 UTC (permalink / raw)
  To: linux-riscv

On 11/10/18 8:46 AM, ron minnich wrote:
> At Google and other places, we've been struggling now for years with
> overly complex firmware that is implemented incorrectly, enabling
> exploits and other bad things. The list of things vendors get wrong in
> firmware, both enabling exploits and enabling others to enable
> exploits, is long and it continues to this day. There is an
> unbelievable amount of money out there all involving firmware
> exploits, very little of it involving nice people.
> 
> I'm currently working on deleting all use of the x86 version of M
> mode, i.e. SMM. There are many proposals out there for deleting SMM
> from the architecture. I've also shown at a talk in 2017 how we could
> redirect SMM interrupts back into the kernel. We're also removing all
> use of callbacks into UEFI on x86. We're almost there.
> 
> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware? Really? multiple serial
> devices? really? We've been here before, in the 1970s, with something
> called the BIOS. If you're not familiar with it, go take a look, or
> you can take my word for it that these proposals implement that idea.
> We spent over 20 years freeing ourselves from it on x86. Why go back
> to a 50 year old model on a CPU designed to be in use for 50 years?
> 
> My early understanding of M mode was that it was an Alpha PALCode like
> thing, enabling access to resources that were behind a privilege wall.
> I did not like it that much, but I was OK: it was very limited in
> function, and the kernel could replace it, or at least measure it. I
> also accept that every cpu vendor uses m mode like things (e.g. ARM
> TF) for reasonable purposes and also (let's be honest here)  for
> dealing with chipset mistakes. But that does not mean you need to
> recreate BIOS.
> 
> The SBI should be hard to add to, deliberately. It should be used only
> when there are no possible alternatives. It needs to be open source
> and held in common. 

I completely agree with this. Once we finalize a decent SBI spec, any 
additional SBI call should be vetted through community and added only if 
**absolutely** necessary. I had echoed same thoughts for a request about 
adding SBI calls for perf & trigger modules in the mailing list.

It should be possible for a kernel to replace or
> at least measure it. And, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.
> This proposal works against those ideals, as it explicitly enables
> vendor-specific forks of the SBI. Sure, this can happen, but why make
> it so easy?
> 

I think the larger picture might have lost somewhere because of the 
verbosity of the proposal. The idea of adding vendor extension support 
in SBI is to allow them provide a standard mechanism to facilitate this.
In absence of that, vendor might adopt different approaches to support 
their feature leading a lot of chaos. Vendors can not go and add 
anything in the Linux kernel(just a example, SBI is still OS agnostic) 
as well.

Example:
http://lists.infradead.org/pipermail/linux-riscv/2018-November/002086.html

I am not sure which part in the proposal led to the conclusion that 
adding vendor-specific forks will super easy. I am more than happy to 
correct it.

> see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.
> 

Thanks a lot for the review. I am going through the suggestions.


Regards,
Atish
> Also, I've had discussions with some security folks in our firmware
> community about the fact that the PMP can be used in a way that the
> kernel can not measure the SBI, since SBI might read-protect itself.
> This is a real step backwards, FYI. Not sure if it can be changed at
> this point.
> 
> ron
> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.
> On Sat, Nov 10, 2018 at 7:49 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
>>
>> ---
>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>>
>> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>>>
>>> ???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????:
>>>> On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
>>>> wrote:
>>>>
>>>>> ## Conclusion
>>>>> This proposal is far from perfect and absolutely any suggestion is
>>>>> welcome. Obviously, there are many other functionalities that can be
>>>>> added to this proposal. However, I just wanted to start with something
>>>>> that is an incremental change at best to kick off the discussion. The
>>>>> aim here is to initiate a discussion that can lead to a robust SBI
>>>>> specification.
>>>>
>>>>   very cool, atish.
>>>>
>>>>   i would very much like to see the optional addition of multiple
>>>> serial lines, by adding a getchar and putchar function that takes just
>>>> one extra argument: the serial line index.
>>>>
>>>>   there are a lot of different uses to which mult-serial lines may be
>>>> put:
>>>>
>>>>   * boot message separation from console login
>>>>   * boot management separation from other purposes (u-boot/coreboot)
>>>>   * virtual /dev/ttyS0-3
>>>>   * clean UPS reporting and management
>>>>   * remote virtual machine power management (power-on / off)
>>>>   * simple bog-standard multiple virtual login consoles
>>>>   * separation of debug messages (stdout/stderr) to ease debugging and
>>>> development
>>>>   * remote and virtual OpenOCD and kernel debugging without disrupting
>>>> the main serial console
>>>>   * PPP serial links.
>>>>
>>>> this latter is one that i am particularly interested in, as i would
>>>> like to be able to boot a full GNU/Linux OS on spike, given the lower
>>>> barrier to entry in making modifications and experimenting with spike
>>>> than it is with qemu.
>>>>
>>>>   if spike were able, through a multi-serial SBI interface, to have a
>>>> PPP serial line, it would be possible to run a root NFS (or other
>>>> network block device) without having to sacrifice console access.  it
>>>> would be possible to create an initramfs from a lower-capability
>>>> system like buildroot, containing PPP, enable it, and pivot-root out
>>>> to a full stock GNU/Linux OS such as debian or fedora.
>>>>
>>>>   so there are huge benefits, reducing the development barrier to entry
>>>> into RISC-V experimentation and debugging, and opening up a much wider
>>>> range of capabilities and possibilities for machine and virtual system
>>>> management.
>>>>
>>>> l.
>>>
>>>
>>> The current SBI says that console_getchar/console_putchar are for the
>>> debug
>>> console but on Linux we use them for the main console on earlyprintk.
>>
>>   ... yeah exactly.  and what if something goes wrong, you want to be
>> able to interact over openocd without interfering with that
>> earlyprintk, particularly during that critical first bringup phase of
>> real-world silicon?
>>
>>> I
>>> think it's misleading and we should at least have an argument to chose
>>> between the main console and an optional debug console, or rename
>>> them to debug_console_getchar/debug_console_putchar and
>>> main_console_getchar/
>>> main_console_putchar.
>>
>>   i initially thought of proposing that, however:
>>
>>   (1) the API already exists with "single console". it would therefore
>> be disruptive to change that
>>
>>   (2) if adding something called debug_console_{get/put}char, it might
>> as well take advantage of the opportunity to be extended and made
>> generic, and have the extra argument added
>>
>>> However I don't think that argument should be the serial line. Different
>>> vendors may use different serial lines for the main console / debug
>>> console,
>>> the caller doesn't know which serial line maps to which console, so the
>>> SBI
>>> should be more abstract and use something like a console id where e.g. 0
>>> is
>>> main console an 1 is debug.
>>
>>   yes, it should [have]: my feeling is, it's a little late in the game
>> given that it's almost certainly baked into pre-existing hardware, by
>> now, so the next best thing is a new function call.
>>
>> l.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe at groups.riscv.org.
>> To post to this group, send email to sw-dev at groups.riscv.org.
>> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ%3D44A%40mail.gmail.com.
> 

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-11  3:58         ` atish.patra
@ 2018-11-11  3:58           ` Atish Patra
  0 siblings, 0 replies; 67+ messages in thread
From: Atish Patra @ 2018-11-11  3:58 UTC (permalink / raw)
  To: ron minnich, Luke Kenneth Casson Leighton
  Cc: mark.rutland, Christoph Hellwig, Damien Le Moal, Olof Johansson,
	alankao, abner.chang, Anup Patel, Palmer Dabbelt, agraf, zong,
	Alistair Francis, Paul Walmsley, mick, sw-dev, linux-riscv,
	Andrew Waterman

On 11/10/18 8:46 AM, ron minnich wrote:
> At Google and other places, we've been struggling now for years with
> overly complex firmware that is implemented incorrectly, enabling
> exploits and other bad things. The list of things vendors get wrong in
> firmware, both enabling exploits and enabling others to enable
> exploits, is long and it continues to this day. There is an
> unbelievable amount of money out there all involving firmware
> exploits, very little of it involving nice people.
> 
> I'm currently working on deleting all use of the x86 version of M
> mode, i.e. SMM. There are many proposals out there for deleting SMM
> from the architecture. I've also shown at a talk in 2017 how we could
> redirect SMM interrupts back into the kernel. We're also removing all
> use of callbacks into UEFI on x86. We're almost there.
> 
> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware? Really? multiple serial
> devices? really? We've been here before, in the 1970s, with something
> called the BIOS. If you're not familiar with it, go take a look, or
> you can take my word for it that these proposals implement that idea.
> We spent over 20 years freeing ourselves from it on x86. Why go back
> to a 50 year old model on a CPU designed to be in use for 50 years?
> 
> My early understanding of M mode was that it was an Alpha PALCode like
> thing, enabling access to resources that were behind a privilege wall.
> I did not like it that much, but I was OK: it was very limited in
> function, and the kernel could replace it, or at least measure it. I
> also accept that every cpu vendor uses m mode like things (e.g. ARM
> TF) for reasonable purposes and also (let's be honest here)  for
> dealing with chipset mistakes. But that does not mean you need to
> recreate BIOS.
> 
> The SBI should be hard to add to, deliberately. It should be used only
> when there are no possible alternatives. It needs to be open source
> and held in common. 

I completely agree with this. Once we finalize a decent SBI spec, any 
additional SBI call should be vetted through community and added only if 
**absolutely** necessary. I had echoed same thoughts for a request about 
adding SBI calls for perf & trigger modules in the mailing list.

It should be possible for a kernel to replace or
> at least measure it. And, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.
> This proposal works against those ideals, as it explicitly enables
> vendor-specific forks of the SBI. Sure, this can happen, but why make
> it so easy?
> 

I think the larger picture might have lost somewhere because of the 
verbosity of the proposal. The idea of adding vendor extension support 
in SBI is to allow them provide a standard mechanism to facilitate this.
In absence of that, vendor might adopt different approaches to support 
their feature leading a lot of chaos. Vendors can not go and add 
anything in the Linux kernel(just a example, SBI is still OS agnostic) 
as well.

Example:
http://lists.infradead.org/pipermail/linux-riscv/2018-November/002086.html

I am not sure which part in the proposal led to the conclusion that 
adding vendor-specific forks will super easy. I am more than happy to 
correct it.

> see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.
> 

Thanks a lot for the review. I am going through the suggestions.


Regards,
Atish
> Also, I've had discussions with some security folks in our firmware
> community about the fact that the PMP can be used in a way that the
> kernel can not measure the SBI, since SBI might read-protect itself.
> This is a real step backwards, FYI. Not sure if it can be changed at
> this point.
> 
> ron
> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.
> On Sat, Nov 10, 2018 at 7:49 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
>>
>> ---
>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>>
>> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>>>
>>> Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε:
>>>> On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
>>>> wrote:
>>>>
>>>>> ## Conclusion
>>>>> This proposal is far from perfect and absolutely any suggestion is
>>>>> welcome. Obviously, there are many other functionalities that can be
>>>>> added to this proposal. However, I just wanted to start with something
>>>>> that is an incremental change at best to kick off the discussion. The
>>>>> aim here is to initiate a discussion that can lead to a robust SBI
>>>>> specification.
>>>>
>>>>   very cool, atish.
>>>>
>>>>   i would very much like to see the optional addition of multiple
>>>> serial lines, by adding a getchar and putchar function that takes just
>>>> one extra argument: the serial line index.
>>>>
>>>>   there are a lot of different uses to which mult-serial lines may be
>>>> put:
>>>>
>>>>   * boot message separation from console login
>>>>   * boot management separation from other purposes (u-boot/coreboot)
>>>>   * virtual /dev/ttyS0-3
>>>>   * clean UPS reporting and management
>>>>   * remote virtual machine power management (power-on / off)
>>>>   * simple bog-standard multiple virtual login consoles
>>>>   * separation of debug messages (stdout/stderr) to ease debugging and
>>>> development
>>>>   * remote and virtual OpenOCD and kernel debugging without disrupting
>>>> the main serial console
>>>>   * PPP serial links.
>>>>
>>>> this latter is one that i am particularly interested in, as i would
>>>> like to be able to boot a full GNU/Linux OS on spike, given the lower
>>>> barrier to entry in making modifications and experimenting with spike
>>>> than it is with qemu.
>>>>
>>>>   if spike were able, through a multi-serial SBI interface, to have a
>>>> PPP serial line, it would be possible to run a root NFS (or other
>>>> network block device) without having to sacrifice console access.  it
>>>> would be possible to create an initramfs from a lower-capability
>>>> system like buildroot, containing PPP, enable it, and pivot-root out
>>>> to a full stock GNU/Linux OS such as debian or fedora.
>>>>
>>>>   so there are huge benefits, reducing the development barrier to entry
>>>> into RISC-V experimentation and debugging, and opening up a much wider
>>>> range of capabilities and possibilities for machine and virtual system
>>>> management.
>>>>
>>>> l.
>>>
>>>
>>> The current SBI says that console_getchar/console_putchar are for the
>>> debug
>>> console but on Linux we use them for the main console on earlyprintk.
>>
>>   ... yeah exactly.  and what if something goes wrong, you want to be
>> able to interact over openocd without interfering with that
>> earlyprintk, particularly during that critical first bringup phase of
>> real-world silicon?
>>
>>> I
>>> think it's misleading and we should at least have an argument to chose
>>> between the main console and an optional debug console, or rename
>>> them to debug_console_getchar/debug_console_putchar and
>>> main_console_getchar/
>>> main_console_putchar.
>>
>>   i initially thought of proposing that, however:
>>
>>   (1) the API already exists with "single console". it would therefore
>> be disruptive to change that
>>
>>   (2) if adding something called debug_console_{get/put}char, it might
>> as well take advantage of the opportunity to be extended and made
>> generic, and have the extra argument added
>>
>>> However I don't think that argument should be the serial line. Different
>>> vendors may use different serial lines for the main console / debug
>>> console,
>>> the caller doesn't know which serial line maps to which console, so the
>>> SBI
>>> should be more abstract and use something like a console id where e.g. 0
>>> is
>>> main console an 1 is debug.
>>
>>   yes, it should [have]: my feeling is, it's a little late in the game
>> given that it's almost certainly baked into pre-existing hardware, by
>> now, so the next best thing is a new function call.
>>
>> l.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
>> To post to this group, send email to sw-dev@groups.riscv.org.
>> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ%3D44A%40mail.gmail.com.
> 


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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-11  3:15                 ` mick
  2018-11-11  3:15                   ` Nick Kossifidis
@ 2018-11-11  7:14                   ` lkcl
  2018-11-11  7:14                     ` Luke Kenneth Casson Leighton
                                       ` (2 more replies)
  1 sibling, 3 replies; 67+ messages in thread
From: lkcl @ 2018-11-11  7:14 UTC (permalink / raw)
  To: linux-riscv

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> ???? 2018-11-10 21:39, Luke Kenneth Casson Leighton ??????:
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
> > wrote:
> >>
> >> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >> >
> >> >> The case of console is in this case pretty simple: It's intended for
> >> >> early boot for very simplistic environments (before the rest of the
> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> >> and somehow trying to optimize for it for those use cases is a
> >> >> misdirected effort; that's what native drivers are for.
> >> >
> >> >  spike (which is only around 7,000 lines of code) doesn't have native
> >> > drivers, and qemu is too heavy-duty to consider adding custom
> >> > extensions and experimental research onto.
> >> >
> >> >  with nothing in spike *other* than the serial console, it's the only
> >> > way in and out.
> >> >
> >> >  l.
> >>
> >> Anything more than a main/debug console is too much for the SBI, its
> >> goal is to be used early on in the boot process until the OS or the
> >> bare metal app takes control.
> >
> >  nooo, that's just _one_ use to which it's being put.
> >
> >> Having multiple serial lines through
> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> >> you mentioned is out of scope.
> >
> >  why?
> >
>
> Because the firmware is meant to be something minimal, not to replace
> the
> OS. Let me ask you this, if you want to change UART speed or settings in
> general would you also ask for an SBI call for that ?

 of course, not, nick.  it's a simple cut/paste of the existing
console getchar/putchar code.  you're beginning to alarm me by making
this out to be much more complex than it is.

 if i'd thought it was a good idea to propose an SBI call to change
UART speed or settings, i would have said so.  there's absolutely no
need to make it *look* like i've proposed that.  doing so - putting
words into someone else's mouth - is unethical, and i'd appreciate it
if you could stop doing it.


> What's coming up next ?

 nothing, nick.  just one extra parameter to the console
getchar/putchar function [or a duplicate function which does] that's
all.

> Adding networking support for example ?

 of course not.  why on earth would that make sense?  how on earth
would networking fit into a 16k Boot ROM?

 i feel that you're arguing and throwing up straw-man questions for
arguments' sake, here, hoping that one of them will stick, and that by
ignoring the positive aspects of the (incredibly simple)
cut/paste-style minimalist proposal and throwing as many "bad" ones
out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
questions you're asking?


> Where do you put the
> barrier
> on firmware's complexity / scope ?

 at the exact same point that you do, under the circumstances and
context in which you're looking at and from.

 now, can you recognise that there are *other* needs and requirements
as well, beyond the ones that you have?

> By the way spike is an ISA simulator, I don't see why it should emulate
> UART ports, last time I checked it didn't,

 ah, nick, i get the feeling you're deliberately looking for ways to
be obstructive, and also fundamentally misunderstanding how the
getchar / putchar code works.

 spike provides a minimal implementation of the SBI, via libfesvr.
the data that goes to the getchar/putchar function is ultimately
redirected to a minimalist stdin / stdout implementation.  there *is*
no call to UART ports.

 come on, man, be a little less adversarial: it makes life easier for everyone.


> so someone will need to write
> code for that, more money !

 i'll happily do it, as i need it.  it's a straight cut/paste of
pre-existing code.

> You can use QEMU for that where you can have
> as many UARTs as you want and the drivers for them are already available
> for you.

 i *can't*.  qemu is too complex and i've invested 2 months of
personal money - without funding or grants from any corporation or
institution - into spike, precisely because it's only 7,000 lines of
code.

 modifying qemu is too much.  i've seen signs that they're moving into
JIT optimisation territory, which is far too complex to get involved
with.

spike is simple, it's straightforward, it's fast, and it works.


> >  i'm an ethical libre developer: i can't go footing the bill for other
> > people to sponge off my efforts all the time, i've had 20 years of
> > people doing that and i'm f*****g well not putting up with it on this
> > project.
> >
> >  so no, mick, sorry, not buying the argument "it's open source".
> >
> > l.
>
> Don't assume you are the only one.

 good to hear.

now... can i ask you if you could possibly turn down the adversarial
straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
effort on your part to maintain, and makes it really really difficult
for everyone to have to read, "no, that's not right, no, that's not
true either, no, i didn't say that at all" and so on.

what do you think?


l.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-11  7:14                   ` lkcl
@ 2018-11-11  7:14                     ` Luke Kenneth Casson Leighton
  2018-11-11 13:17                     ` mick
  2018-11-12  2:08                     ` palmer
  2 siblings, 0 replies; 67+ messages in thread
From: Luke Kenneth Casson Leighton @ 2018-11-11  7:14 UTC (permalink / raw)
  To: mick
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, ron minnich, sw-dev, paul.walmsley,
	Olof Johansson, Alistair.Francis, linux-riscv, Andrew Waterman

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> Στις 2018-11-10 21:39, Luke Kenneth Casson Leighton έγραψε:
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
> > wrote:
> >>
> >> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >> >
> >> >> The case of console is in this case pretty simple: It's intended for
> >> >> early boot for very simplistic environments (before the rest of the
> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> >> and somehow trying to optimize for it for those use cases is a
> >> >> misdirected effort; that's what native drivers are for.
> >> >
> >> >  spike (which is only around 7,000 lines of code) doesn't have native
> >> > drivers, and qemu is too heavy-duty to consider adding custom
> >> > extensions and experimental research onto.
> >> >
> >> >  with nothing in spike *other* than the serial console, it's the only
> >> > way in and out.
> >> >
> >> >  l.
> >>
> >> Anything more than a main/debug console is too much for the SBI, its
> >> goal is to be used early on in the boot process until the OS or the
> >> bare metal app takes control.
> >
> >  nooo, that's just _one_ use to which it's being put.
> >
> >> Having multiple serial lines through
> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> >> you mentioned is out of scope.
> >
> >  why?
> >
>
> Because the firmware is meant to be something minimal, not to replace
> the
> OS. Let me ask you this, if you want to change UART speed or settings in
> general would you also ask for an SBI call for that ?

 of course, not, nick.  it's a simple cut/paste of the existing
console getchar/putchar code.  you're beginning to alarm me by making
this out to be much more complex than it is.

 if i'd thought it was a good idea to propose an SBI call to change
UART speed or settings, i would have said so.  there's absolutely no
need to make it *look* like i've proposed that.  doing so - putting
words into someone else's mouth - is unethical, and i'd appreciate it
if you could stop doing it.


> What's coming up next ?

 nothing, nick.  just one extra parameter to the console
getchar/putchar function [or a duplicate function which does] that's
all.

> Adding networking support for example ?

 of course not.  why on earth would that make sense?  how on earth
would networking fit into a 16k Boot ROM?

 i feel that you're arguing and throwing up straw-man questions for
arguments' sake, here, hoping that one of them will stick, and that by
ignoring the positive aspects of the (incredibly simple)
cut/paste-style minimalist proposal and throwing as many "bad" ones
out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
questions you're asking?


> Where do you put the
> barrier
> on firmware's complexity / scope ?

 at the exact same point that you do, under the circumstances and
context in which you're looking at and from.

 now, can you recognise that there are *other* needs and requirements
as well, beyond the ones that you have?

> By the way spike is an ISA simulator, I don't see why it should emulate
> UART ports, last time I checked it didn't,

 ah, nick, i get the feeling you're deliberately looking for ways to
be obstructive, and also fundamentally misunderstanding how the
getchar / putchar code works.

 spike provides a minimal implementation of the SBI, via libfesvr.
the data that goes to the getchar/putchar function is ultimately
redirected to a minimalist stdin / stdout implementation.  there *is*
no call to UART ports.

 come on, man, be a little less adversarial: it makes life easier for everyone.


> so someone will need to write
> code for that, more money !

 i'll happily do it, as i need it.  it's a straight cut/paste of
pre-existing code.

> You can use QEMU for that where you can have
> as many UARTs as you want and the drivers for them are already available
> for you.

 i *can't*.  qemu is too complex and i've invested 2 months of
personal money - without funding or grants from any corporation or
institution - into spike, precisely because it's only 7,000 lines of
code.

 modifying qemu is too much.  i've seen signs that they're moving into
JIT optimisation territory, which is far too complex to get involved
with.

spike is simple, it's straightforward, it's fast, and it works.


> >  i'm an ethical libre developer: i can't go footing the bill for other
> > people to sponge off my efforts all the time, i've had 20 years of
> > people doing that and i'm f*****g well not putting up with it on this
> > project.
> >
> >  so no, mick, sorry, not buying the argument "it's open source".
> >
> > l.
>
> Don't assume you are the only one.

 good to hear.

now... can i ask you if you could possibly turn down the adversarial
straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
effort on your part to maintain, and makes it really really difficult
for everyone to have to read, "no, that's not right, no, that's not
true either, no, i didn't say that at all" and so on.

what do you think?


l.

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-11  7:14                   ` lkcl
  2018-11-11  7:14                     ` Luke Kenneth Casson Leighton
@ 2018-11-11 13:17                     ` mick
  2018-11-11 13:17                       ` Nick Kossifidis
  2018-11-12  2:08                     ` palmer
  2 siblings, 1 reply; 67+ messages in thread
From: mick @ 2018-11-11 13:17 UTC (permalink / raw)
  To: linux-riscv

???? 2018-11-11 09:14, Luke Kenneth Casson Leighton ??????:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> ???? 2018-11-10 21:39, Luke Kenneth Casson Leighton ??????:
>> > ---
>> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>> >
>> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
>> > wrote:
>> >>
>> >> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
>> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >> >
>> >> >> The case of console is in this case pretty simple: It's intended for
>> >> >> early boot for very simplistic environments (before the rest of the
>> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> >> and somehow trying to optimize for it for those use cases is a
>> >> >> misdirected effort; that's what native drivers are for.
>> >> >
>> >> >  spike (which is only around 7,000 lines of code) doesn't have native
>> >> > drivers, and qemu is too heavy-duty to consider adding custom
>> >> > extensions and experimental research onto.
>> >> >
>> >> >  with nothing in spike *other* than the serial console, it's the only
>> >> > way in and out.
>> >> >
>> >> >  l.
>> >>
>> >> Anything more than a main/debug console is too much for the SBI, its
>> >> goal is to be used early on in the boot process until the OS or the
>> >> bare metal app takes control.
>> >
>> >  nooo, that's just _one_ use to which it's being put.
>> >
>> >> Having multiple serial lines through
>> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> >> you mentioned is out of scope.
>> >
>> >  why?
>> >
>> 
>> Because the firmware is meant to be something minimal, not to replace
>> the
>> OS. Let me ask you this, if you want to change UART speed or settings 
>> in
>> general would you also ask for an SBI call for that ?
> 
>  of course, not, nick.  it's a simple cut/paste of the existing
> console getchar/putchar code.  you're beginning to alarm me by making
> this out to be much more complex than it is.
> 
>  if i'd thought it was a good idea to propose an SBI call to change
> UART speed or settings, i would have said so.  there's absolutely no
> need to make it *look* like i've proposed that.  doing so - putting
> words into someone else's mouth - is unethical, and i'd appreciate it
> if you could stop doing it.
> 
> 

Sorry that wasn't my intention, my intention was to understand what you
want to achieve. On the one hand you mentioned that you want an SBI
API change so that you can better work with spike, on the other hand
in order to convince the rest of us that this is a good approach for
the SBI API, you mentioned some examples that to me look like
overengineering at this point. I would never e.g. use getchar/putchar 
for
example for PPP etc. On another example you mentioned using this serial
line for providing networking with spike. My questions are honest, I'm
not trying to put words on your mouth.

>> What's coming up next ?
> 
>  nothing, nick.  just one extra parameter to the console
> getchar/putchar function [or a duplicate function which does] that's
> all.
> 

ACK and as I told you on my first reply, my only concern there is that
this argument shouldn't be about serial line indices but about "types"
so that (since this thing is going to end up on actual hardware) vendors
don't mess up. If you say serial line 0 for example and your code 
assumes
this is the main console, another vendor might put the debug console 
there
or an auxiliary console. By using a console id instead of a serial line
index, you can hide this on the firmware and deal with it there.

>> Adding networking support for example ?
> 
>  of course not.  why on earth would that make sense?  how on earth
> would networking fit into a 16k Boot ROM?
> 

I don't know, why on earth should a 16k Boot ROM be used for accessing
multiple serial lines for PPP, UPS etc ? To me that's the work of an OS,
the same OS that will handle the running of PPP/UPS monitor/whatever.
If you use such examples you should expect that people will assume the
worst (I'm not the only one that assumed the worst btw), and that's what
any reviewer should do.

>  i feel that you're arguing and throwing up straw-man questions for
> arguments' sake, here, hoping that one of them will stick, and that by
> ignoring the positive aspects of the (incredibly simple)
> cut/paste-style minimalist proposal and throwing as many "bad" ones
> out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
> questions you're asking?
> 

The positive aspects of supporting multiple serial lines through the SBI
getchar/putchar code that you mention are not clear to me, that's why 
I'm
asking what's the purpose of this other than a hack to get around
limitations on spike. Supporting PPP for example without being able
to set serial parameters is a hack and we shouldn't be discussing that
in the context of the SBI.

>> Where do you put the
>> barrier
>> on firmware's complexity / scope ?
> 
>  at the exact same point that you do, under the circumstances and
> context in which you're looking at and from.
> 
>  now, can you recognise that there are *other* needs and requirements
> as well, beyond the ones that you have?
> 

I can understand changing the current SBI and adding an extra argument 
to
chose between a main and a debug console (not by serial line index as I
mentioned above but through a console id argument). Could you please 
help
me understand why you want support for more ports than that on the base 
SBI ?

You mentioned the following...

> * boot message separation from console login

ACK I agree on that, that's what the debug uart can be used for, lots
of people are doing that. However if by boot messages you mean anything
other than dmesg output, you need syslog for that and a /dev/tty* entry
for the debug (or any other) console. To me providing this through a 
driver
that's just a wrapper around the SBI and provides only a small subset of
what a tty driver should provide is fundamentally wrong.

That's why I believe the SBI should only be used for earlyprintk and in
general for things before the OS boots. Once the OS boots we should
have proper UART support.

> * boot management separation from other purposes (u-boot/coreboot)

That makes more sense, at least in this case everything is built-in
on u-boot/coreboot so using a different way of accessing the
main and the debug console shouldn't be a big deal. However I still
don't see any value here for more consoles than main/debug.

> * virtual /dev/ttyS0-3
> * clean UPS reporting and management
> * remote virtual machine power management (power-on / off)
> * simple bog-standard multiple virtual login consoles

To me this is way off, we have networking for that, why on earth should
anyone use serial ports ?

> * separation of debug messages (stdout/stderr) to ease debugging and
> development
> * remote and virtual OpenOCD and kernel debugging without disrupting
> the main serial console
> * PPP serial links.

So again you'll need /dev/tty* for that, which should be handled by
a proper UART driver. Especially for the PPP, unless all you want to
do is hack your way through.

>> By the way spike is an ISA simulator, I don't see why it should 
>> emulate
>> UART ports, last time I checked it didn't,
> 
>  ah, nick, i get the feeling you're deliberately looking for ways to
> be obstructive, and also fundamentally misunderstanding how the
> getchar / putchar code works.
> 
>  spike provides a minimal implementation of the SBI, via libfesvr.
> the data that goes to the getchar/putchar function is ultimately
> redirected to a minimalist stdin / stdout implementation.  there *is*
> no call to UART ports.
> 

So as I said spike doesn't emulate UART ports, and it shouldn't, it's an
ISA simulator, it doesn't and shouldn't emulate devices.

>  come on, man, be a little less adversarial: it makes life easier for 
> everyone.
> 
> 
>> so someone will need to write
>> code for that, more money !
> 
>  i'll happily do it, as i need it.  it's a straight cut/paste of
> pre-existing code.
> 

So what's the issue ? You can patch spike and add your custom SBI calls
(vendor-specific) on libfesvr and you are done with it. Why should this
extension about multiple serial lines, so that you can do your hacks 
when
testing on spike, should be on the base SBI ?

>> You can use QEMU for that where you can have
>> as many UARTs as you want and the drivers for them are already 
>> available
>> for you.
> 
>  i *can't*.  qemu is too complex and i've invested 2 months of
> personal money - without funding or grants from any corporation or
> institution - into spike, precisely because it's only 7,000 lines of
> code.
> 
>  modifying qemu is too much.  i've seen signs that they're moving into
> JIT optimisation territory, which is far too complex to get involved
> with.
> 
> spike is simple, it's straightforward, it's fast, and it works.
> 
> 

What are you trying to do ? Test a specific piece of code / ISA 
extension
etc or emulate a full blown system ? If you just want networking support
on spike let's talk about this instead, that's not an issue regarding 
the
SBI.

>> >  i'm an ethical libre developer: i can't go footing the bill for other
>> > people to sponge off my efforts all the time, i've had 20 years of
>> > people doing that and i'm f*****g well not putting up with it on this
>> > project.
>> >
>> >  so no, mick, sorry, not buying the argument "it's open source".
>> >
>> > l.
>> 
>> Don't assume you are the only one.
> 
>  good to hear.
> 
> now... can i ask you if you could possibly turn down the adversarial
> straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
> effort on your part to maintain, and makes it really really difficult
> for everyone to have to read, "no, that's not right, no, that's not
> true either, no, i didn't say that at all" and so on.
> 
> what do you think?
> 
> 
> l.

I think that on a technical discussion labeling your peers as 
"obstructive"
and "adversarial" and bringing non-technical arguments like funding 
issues
etc and how ethical/libre developer you are to the table is not 
appropriate.
I never judged your intentions or characterized you in any way, I'd 
expect
from you to do the same.

Regards,
Nick

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-11 13:17                     ` mick
@ 2018-11-11 13:17                       ` Nick Kossifidis
  0 siblings, 0 replies; 67+ messages in thread
From: Nick Kossifidis @ 2018-11-11 13:17 UTC (permalink / raw)
  To: Luke Kenneth Casson Leighton
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, Olof Johansson, ron minnich, sw-dev,
	paul.walmsley, mick, Alistair.Francis, linux-riscv,
	Andrew Waterman

Στις 2018-11-11 09:14, Luke Kenneth Casson Leighton έγραψε:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> Στις 2018-11-10 21:39, Luke Kenneth Casson Leighton έγραψε:
>> > ---
>> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>> >
>> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
>> > wrote:
>> >>
>> >> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
>> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >> >
>> >> >> The case of console is in this case pretty simple: It's intended for
>> >> >> early boot for very simplistic environments (before the rest of the
>> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> >> and somehow trying to optimize for it for those use cases is a
>> >> >> misdirected effort; that's what native drivers are for.
>> >> >
>> >> >  spike (which is only around 7,000 lines of code) doesn't have native
>> >> > drivers, and qemu is too heavy-duty to consider adding custom
>> >> > extensions and experimental research onto.
>> >> >
>> >> >  with nothing in spike *other* than the serial console, it's the only
>> >> > way in and out.
>> >> >
>> >> >  l.
>> >>
>> >> Anything more than a main/debug console is too much for the SBI, its
>> >> goal is to be used early on in the boot process until the OS or the
>> >> bare metal app takes control.
>> >
>> >  nooo, that's just _one_ use to which it's being put.
>> >
>> >> Having multiple serial lines through
>> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> >> you mentioned is out of scope.
>> >
>> >  why?
>> >
>> 
>> Because the firmware is meant to be something minimal, not to replace
>> the
>> OS. Let me ask you this, if you want to change UART speed or settings 
>> in
>> general would you also ask for an SBI call for that ?
> 
>  of course, not, nick.  it's a simple cut/paste of the existing
> console getchar/putchar code.  you're beginning to alarm me by making
> this out to be much more complex than it is.
> 
>  if i'd thought it was a good idea to propose an SBI call to change
> UART speed or settings, i would have said so.  there's absolutely no
> need to make it *look* like i've proposed that.  doing so - putting
> words into someone else's mouth - is unethical, and i'd appreciate it
> if you could stop doing it.
> 
> 

Sorry that wasn't my intention, my intention was to understand what you
want to achieve. On the one hand you mentioned that you want an SBI
API change so that you can better work with spike, on the other hand
in order to convince the rest of us that this is a good approach for
the SBI API, you mentioned some examples that to me look like
overengineering at this point. I would never e.g. use getchar/putchar 
for
example for PPP etc. On another example you mentioned using this serial
line for providing networking with spike. My questions are honest, I'm
not trying to put words on your mouth.

>> What's coming up next ?
> 
>  nothing, nick.  just one extra parameter to the console
> getchar/putchar function [or a duplicate function which does] that's
> all.
> 

ACK and as I told you on my first reply, my only concern there is that
this argument shouldn't be about serial line indices but about "types"
so that (since this thing is going to end up on actual hardware) vendors
don't mess up. If you say serial line 0 for example and your code 
assumes
this is the main console, another vendor might put the debug console 
there
or an auxiliary console. By using a console id instead of a serial line
index, you can hide this on the firmware and deal with it there.

>> Adding networking support for example ?
> 
>  of course not.  why on earth would that make sense?  how on earth
> would networking fit into a 16k Boot ROM?
> 

I don't know, why on earth should a 16k Boot ROM be used for accessing
multiple serial lines for PPP, UPS etc ? To me that's the work of an OS,
the same OS that will handle the running of PPP/UPS monitor/whatever.
If you use such examples you should expect that people will assume the
worst (I'm not the only one that assumed the worst btw), and that's what
any reviewer should do.

>  i feel that you're arguing and throwing up straw-man questions for
> arguments' sake, here, hoping that one of them will stick, and that by
> ignoring the positive aspects of the (incredibly simple)
> cut/paste-style minimalist proposal and throwing as many "bad" ones
> out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
> questions you're asking?
> 

The positive aspects of supporting multiple serial lines through the SBI
getchar/putchar code that you mention are not clear to me, that's why 
I'm
asking what's the purpose of this other than a hack to get around
limitations on spike. Supporting PPP for example without being able
to set serial parameters is a hack and we shouldn't be discussing that
in the context of the SBI.

>> Where do you put the
>> barrier
>> on firmware's complexity / scope ?
> 
>  at the exact same point that you do, under the circumstances and
> context in which you're looking at and from.
> 
>  now, can you recognise that there are *other* needs and requirements
> as well, beyond the ones that you have?
> 

I can understand changing the current SBI and adding an extra argument 
to
chose between a main and a debug console (not by serial line index as I
mentioned above but through a console id argument). Could you please 
help
me understand why you want support for more ports than that on the base 
SBI ?

You mentioned the following...

> * boot message separation from console login

ACK I agree on that, that's what the debug uart can be used for, lots
of people are doing that. However if by boot messages you mean anything
other than dmesg output, you need syslog for that and a /dev/tty* entry
for the debug (or any other) console. To me providing this through a 
driver
that's just a wrapper around the SBI and provides only a small subset of
what a tty driver should provide is fundamentally wrong.

That's why I believe the SBI should only be used for earlyprintk and in
general for things before the OS boots. Once the OS boots we should
have proper UART support.

> * boot management separation from other purposes (u-boot/coreboot)

That makes more sense, at least in this case everything is built-in
on u-boot/coreboot so using a different way of accessing the
main and the debug console shouldn't be a big deal. However I still
don't see any value here for more consoles than main/debug.

> * virtual /dev/ttyS0-3
> * clean UPS reporting and management
> * remote virtual machine power management (power-on / off)
> * simple bog-standard multiple virtual login consoles

To me this is way off, we have networking for that, why on earth should
anyone use serial ports ?

> * separation of debug messages (stdout/stderr) to ease debugging and
> development
> * remote and virtual OpenOCD and kernel debugging without disrupting
> the main serial console
> * PPP serial links.

So again you'll need /dev/tty* for that, which should be handled by
a proper UART driver. Especially for the PPP, unless all you want to
do is hack your way through.

>> By the way spike is an ISA simulator, I don't see why it should 
>> emulate
>> UART ports, last time I checked it didn't,
> 
>  ah, nick, i get the feeling you're deliberately looking for ways to
> be obstructive, and also fundamentally misunderstanding how the
> getchar / putchar code works.
> 
>  spike provides a minimal implementation of the SBI, via libfesvr.
> the data that goes to the getchar/putchar function is ultimately
> redirected to a minimalist stdin / stdout implementation.  there *is*
> no call to UART ports.
> 

So as I said spike doesn't emulate UART ports, and it shouldn't, it's an
ISA simulator, it doesn't and shouldn't emulate devices.

>  come on, man, be a little less adversarial: it makes life easier for 
> everyone.
> 
> 
>> so someone will need to write
>> code for that, more money !
> 
>  i'll happily do it, as i need it.  it's a straight cut/paste of
> pre-existing code.
> 

So what's the issue ? You can patch spike and add your custom SBI calls
(vendor-specific) on libfesvr and you are done with it. Why should this
extension about multiple serial lines, so that you can do your hacks 
when
testing on spike, should be on the base SBI ?

>> You can use QEMU for that where you can have
>> as many UARTs as you want and the drivers for them are already 
>> available
>> for you.
> 
>  i *can't*.  qemu is too complex and i've invested 2 months of
> personal money - without funding or grants from any corporation or
> institution - into spike, precisely because it's only 7,000 lines of
> code.
> 
>  modifying qemu is too much.  i've seen signs that they're moving into
> JIT optimisation territory, which is far too complex to get involved
> with.
> 
> spike is simple, it's straightforward, it's fast, and it works.
> 
> 

What are you trying to do ? Test a specific piece of code / ISA 
extension
etc or emulate a full blown system ? If you just want networking support
on spike let's talk about this instead, that's not an issue regarding 
the
SBI.

>> >  i'm an ethical libre developer: i can't go footing the bill for other
>> > people to sponge off my efforts all the time, i've had 20 years of
>> > people doing that and i'm f*****g well not putting up with it on this
>> > project.
>> >
>> >  so no, mick, sorry, not buying the argument "it's open source".
>> >
>> > l.
>> 
>> Don't assume you are the only one.
> 
>  good to hear.
> 
> now... can i ask you if you could possibly turn down the adversarial
> straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
> effort on your part to maintain, and makes it really really difficult
> for everyone to have to read, "no, that's not right, no, that's not
> true either, no, i didn't say that at all" and so on.
> 
> what do you think?
> 
> 
> l.

I think that on a technical discussion labeling your peers as 
"obstructive"
and "adversarial" and bringing non-technical arguments like funding 
issues
etc and how ethical/libre developer you are to the table is not 
appropriate.
I never judged your intentions or characterized you in any way, I'd 
expect
from you to do the same.

Regards,
Nick

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-11  7:14                   ` lkcl
  2018-11-11  7:14                     ` Luke Kenneth Casson Leighton
  2018-11-11 13:17                     ` mick
@ 2018-11-12  2:08                     ` palmer
  2018-11-12  2:08                       ` Palmer Dabbelt
  2 siblings, 1 reply; 67+ messages in thread
From: palmer @ 2018-11-12  2:08 UTC (permalink / raw)
  To: linux-riscv

On Sat, 10 Nov 2018 23:14:40 PST (-0800), lkcl at lkcl.net wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>>
>> ???? 2018-11-10 21:39, Luke Kenneth Casson Leighton ??????:
>> > ---
>> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>> >
>> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
>> > wrote:
>> >>
>> >> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
>> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >> >
>> >> >> The case of console is in this case pretty simple: It's intended for
>> >> >> early boot for very simplistic environments (before the rest of the
>> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> >> and somehow trying to optimize for it for those use cases is a
>> >> >> misdirected effort; that's what native drivers are for.
>> >> >
>> >> >  spike (which is only around 7,000 lines of code) doesn't have native
>> >> > drivers, and qemu is too heavy-duty to consider adding custom
>> >> > extensions and experimental research onto.
>> >> >
>> >> >  with nothing in spike *other* than the serial console, it's the only
>> >> > way in and out.
>> >> >
>> >> >  l.
>> >>
>> >> Anything more than a main/debug console is too much for the SBI, its
>> >> goal is to be used early on in the boot process until the OS or the
>> >> bare metal app takes control.
>> >
>> >  nooo, that's just _one_ use to which it's being put.
>> >
>> >> Having multiple serial lines through
>> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> >> you mentioned is out of scope.
>> >
>> >  why?
>> >
>>
>> Because the firmware is meant to be something minimal, not to replace
>> the
>> OS. Let me ask you this, if you want to change UART speed or settings in
>> general would you also ask for an SBI call for that ?
>
>  of course, not, nick.  it's a simple cut/paste of the existing
> console getchar/putchar code.  you're beginning to alarm me by making
> this out to be much more complex than it is.
>
>  if i'd thought it was a good idea to propose an SBI call to change
> UART speed or settings, i would have said so.  there's absolutely no
> need to make it *look* like i've proposed that.  doing so - putting
> words into someone else's mouth - is unethical, and i'd appreciate it
> if you could stop doing it.
>
>
>> What's coming up next ?
>
>  nothing, nick.  just one extra parameter to the console
> getchar/putchar function [or a duplicate function which does] that's
> all.
>
>> Adding networking support for example ?
>
>  of course not.  why on earth would that make sense?  how on earth
> would networking fit into a 16k Boot ROM?
>
>  i feel that you're arguing and throwing up straw-man questions for
> arguments' sake, here, hoping that one of them will stick, and that by
> ignoring the positive aspects of the (incredibly simple)
> cut/paste-style minimalist proposal and throwing as many "bad" ones
> out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
> questions you're asking?
>
>
>> Where do you put the
>> barrier
>> on firmware's complexity / scope ?
>
>  at the exact same point that you do, under the circumstances and
> context in which you're looking at and from.
>
>  now, can you recognise that there are *other* needs and requirements
> as well, beyond the ones that you have?
>
>> By the way spike is an ISA simulator, I don't see why it should emulate
>> UART ports, last time I checked it didn't,
>
>  ah, nick, i get the feeling you're deliberately looking for ways to
> be obstructive, and also fundamentally misunderstanding how the
> getchar / putchar code works.
>
>  spike provides a minimal implementation of the SBI, via libfesvr.
> the data that goes to the getchar/putchar function is ultimately
> redirected to a minimalist stdin / stdout implementation.  there *is*
> no call to UART ports.
>
>  come on, man, be a little less adversarial: it makes life easier for everyone.
>
>
>> so someone will need to write
>> code for that, more money !
>
>  i'll happily do it, as i need it.  it's a straight cut/paste of
> pre-existing code.
>
>> You can use QEMU for that where you can have
>> as many UARTs as you want and the drivers for them are already available
>> for you.
>
>  i *can't*.  qemu is too complex and i've invested 2 months of
> personal money - without funding or grants from any corporation or
> institution - into spike, precisely because it's only 7,000 lines of
> code.
>
>  modifying qemu is too much.  i've seen signs that they're moving into
> JIT optimisation territory, which is far too complex to get involved
> with.
>
> spike is simple, it's straightforward, it's fast, and it works.
>
>
>> >  i'm an ethical libre developer: i can't go footing the bill for other
>> > people to sponge off my efforts all the time, i've had 20 years of
>> > people doing that and i'm f*****g well not putting up with it on this
>> > project.
>> >
>> >  so no, mick, sorry, not buying the argument "it's open source".
>> >
>> > l.
>>
>> Don't assume you are the only one.
>
>  good to hear.
>
> now... can i ask you if you could possibly turn down the adversarial
> straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
> effort on your part to maintain, and makes it really really difficult
> for everyone to have to read, "no, that's not right, no, that's not
> true either, no, i didn't say that at all" and so on.
>
> what do you think?

Luke: You may be used to posting on the sw-dev and isa-dev mailing lists where 
this kind of post appears to be acceptable.  In case you didn't notice, you've 
now managed to get linux-riscv on your CC list.  I've already dropped all the 
@riscv.org lists from my inbox because they're worthless, but work actually 
happens on linux-riscv and I'd like it to continue being useful.

Please keep the noise down.

Thanks!

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-12  2:08                     ` palmer
@ 2018-11-12  2:08                       ` Palmer Dabbelt
  0 siblings, 0 replies; 67+ messages in thread
From: Palmer Dabbelt @ 2018-11-12  2:08 UTC (permalink / raw)
  To: lkcl
  Cc: mark.rutland, Christoph Hellwig, Damien.LeMoal, olof.johansson,
	alankao, abner.chang, atish.patra, anup, agraf, zong,
	Olof Johansson, rminnich, sw-dev, Paul Walmsley, mick,
	Alistair Francis, linux-riscv, Andrew Waterman

On Sat, 10 Nov 2018 23:14:40 PST (-0800), lkcl@lkcl.net wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>>
>> Στις 2018-11-10 21:39, Luke Kenneth Casson Leighton έγραψε:
>> > ---
>> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>> >
>> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
>> > wrote:
>> >>
>> >> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
>> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >> >
>> >> >> The case of console is in this case pretty simple: It's intended for
>> >> >> early boot for very simplistic environments (before the rest of the
>> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> >> and somehow trying to optimize for it for those use cases is a
>> >> >> misdirected effort; that's what native drivers are for.
>> >> >
>> >> >  spike (which is only around 7,000 lines of code) doesn't have native
>> >> > drivers, and qemu is too heavy-duty to consider adding custom
>> >> > extensions and experimental research onto.
>> >> >
>> >> >  with nothing in spike *other* than the serial console, it's the only
>> >> > way in and out.
>> >> >
>> >> >  l.
>> >>
>> >> Anything more than a main/debug console is too much for the SBI, its
>> >> goal is to be used early on in the boot process until the OS or the
>> >> bare metal app takes control.
>> >
>> >  nooo, that's just _one_ use to which it's being put.
>> >
>> >> Having multiple serial lines through
>> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> >> you mentioned is out of scope.
>> >
>> >  why?
>> >
>>
>> Because the firmware is meant to be something minimal, not to replace
>> the
>> OS. Let me ask you this, if you want to change UART speed or settings in
>> general would you also ask for an SBI call for that ?
>
>  of course, not, nick.  it's a simple cut/paste of the existing
> console getchar/putchar code.  you're beginning to alarm me by making
> this out to be much more complex than it is.
>
>  if i'd thought it was a good idea to propose an SBI call to change
> UART speed or settings, i would have said so.  there's absolutely no
> need to make it *look* like i've proposed that.  doing so - putting
> words into someone else's mouth - is unethical, and i'd appreciate it
> if you could stop doing it.
>
>
>> What's coming up next ?
>
>  nothing, nick.  just one extra parameter to the console
> getchar/putchar function [or a duplicate function which does] that's
> all.
>
>> Adding networking support for example ?
>
>  of course not.  why on earth would that make sense?  how on earth
> would networking fit into a 16k Boot ROM?
>
>  i feel that you're arguing and throwing up straw-man questions for
> arguments' sake, here, hoping that one of them will stick, and that by
> ignoring the positive aspects of the (incredibly simple)
> cut/paste-style minimalist proposal and throwing as many "bad" ones
> out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
> questions you're asking?
>
>
>> Where do you put the
>> barrier
>> on firmware's complexity / scope ?
>
>  at the exact same point that you do, under the circumstances and
> context in which you're looking at and from.
>
>  now, can you recognise that there are *other* needs and requirements
> as well, beyond the ones that you have?
>
>> By the way spike is an ISA simulator, I don't see why it should emulate
>> UART ports, last time I checked it didn't,
>
>  ah, nick, i get the feeling you're deliberately looking for ways to
> be obstructive, and also fundamentally misunderstanding how the
> getchar / putchar code works.
>
>  spike provides a minimal implementation of the SBI, via libfesvr.
> the data that goes to the getchar/putchar function is ultimately
> redirected to a minimalist stdin / stdout implementation.  there *is*
> no call to UART ports.
>
>  come on, man, be a little less adversarial: it makes life easier for everyone.
>
>
>> so someone will need to write
>> code for that, more money !
>
>  i'll happily do it, as i need it.  it's a straight cut/paste of
> pre-existing code.
>
>> You can use QEMU for that where you can have
>> as many UARTs as you want and the drivers for them are already available
>> for you.
>
>  i *can't*.  qemu is too complex and i've invested 2 months of
> personal money - without funding or grants from any corporation or
> institution - into spike, precisely because it's only 7,000 lines of
> code.
>
>  modifying qemu is too much.  i've seen signs that they're moving into
> JIT optimisation territory, which is far too complex to get involved
> with.
>
> spike is simple, it's straightforward, it's fast, and it works.
>
>
>> >  i'm an ethical libre developer: i can't go footing the bill for other
>> > people to sponge off my efforts all the time, i've had 20 years of
>> > people doing that and i'm f*****g well not putting up with it on this
>> > project.
>> >
>> >  so no, mick, sorry, not buying the argument "it's open source".
>> >
>> > l.
>>
>> Don't assume you are the only one.
>
>  good to hear.
>
> now... can i ask you if you could possibly turn down the adversarial
> straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
> effort on your part to maintain, and makes it really really difficult
> for everyone to have to read, "no, that's not right, no, that's not
> true either, no, i didn't say that at all" and so on.
>
> what do you think?

Luke: You may be used to posting on the sw-dev and isa-dev mailing lists where 
this kind of post appears to be acceptable.  In case you didn't notice, you've 
now managed to get linux-riscv on your CC list.  I've already dropped all the 
@riscv.org lists from my inbox because they're worthless, but work actually 
happens on linux-riscv and I'd like it to continue being useful.

Please keep the noise down.

Thanks!

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* SBI extension proposal v2
  2018-11-10  2:42 SBI extension proposal v2 atish.patra
                   ` (2 preceding siblings ...)
  2018-11-10  5:36 ` david.abdurachmanov
@ 2018-11-12  4:33 ` mick
  2018-11-12  4:33   ` Nick Kossifidis
  2018-12-04 23:22   ` [sw-dev] " Atish Patra
  3 siblings, 2 replies; 67+ messages in thread
From: mick @ 2018-11-12  4:33 UTC (permalink / raw)
  To: linux-riscv

Hello Atish,

???? 2018-11-10 04:42, Atish Patra ??????:
> Hi,
> I have updated the proposal based on feedback received on previous
> version. This version has a better scalable SBI Function ID
> numbering scheme. I have adopted markdown formatting for github docs.
> 
> If you prefer a github interface, it's available here as well.
> 
> https://github.com/riscv/riscv-sbi-doc/pull/12
> 
> Looking forward to your feedback.
> 
> Regards,
> Atish
> ------------------------------------------------------------------------
> 
> ## Introduction:
> This is a proposal to make SBI a flexible and extensible interface.
> It is based on the foundation policy of RISC-V i.e. modularity and
> openness. The proposal tries to introduces very few new mandatory SBI
> Functions, that are absolutely required to maintain backward
> compatibility. Everything else is optional so that it remains an open
> standard yet robust.
> 
> The current RISC-V SBI only defines a few mandatory functions such as
> inter-processor interrupts (IPI) interface, reprogramming timer, serial
> console, and memory barrier instructions. The existing SBI 
> documentation
> can be found here [1]. Many important functionalities such as power
> management/cpu-hotplug are not yet defined due to difficulties in
> accommodating modifications without breaking the backward compatibility
> with the current interface.
> 
> The proposed design is inspired by Power State Coordination Interface
> (PSCI) from ARM world. However, it adds only two new mandatory SBI
> calls providing version information and supported Functions, unlike
> PSCI where a significant number of functions are mandatory. The
> version of the existing SBI will be defined as a minimum version(0.1)
> which will always be backward compatible. Similarly, any Linux kernel
> with a newer feature will fall back if an older version of SBI does
> not support the updated capabilities. Both the operating system and
> SEE can be implemented to be two way backward compatible.
> 

Let's remove any references to Linux, it can be misleading since
this is supposed to be used by every OS.

> ## SBI Calling Conventions (TODO)
> There are some suggestions[3] to distinguish between SBI function
> return value and SBI calling sequence return value. Here are the few
> possible discussed ideas.
> 
> 1. Return a single value, but values in the range {-511, -1} are
> considered errors, whereas return values in the range {0, 2^XLEN-512}
> are considered success.
> 

I'm thinking about compatibility between a 64bit firmware and a 32bit
supervisor and vice-versa. If we report back values that can't fit
within 32bits, this is going to break things.

> 2. Every SBI function call may return the following structure
> ```
> struct valerr {
>   long value;
>   long error;
> };
> ```
> According to the RISC-V ABI spec[4], both a0 & a1 registers can be
> used for function return values.
> 

This makes sense, however let's allow for this to be extensible,
there may be SBI calls that want to return something more, there
may also be SBI calls that are asynchronous so it's a good idea I
think to also include the function id there. Also please let's use
typed integers instead. How about something like this:

struct sbi_report {
  uint32_t status;
  uint32_t value;
  uint32_t function_id;
  uint8_t has_payload;
  uint16_t payload_size;
  /* 1 byte hole */
  void payload[];
};

> 3. Introduce an extra argument that can return error by reference.
> ```
> /* Returns the CPU that was started.
>  * @err indicates an error ID if one occurred, otherwise 0.
>  * @err can be NULL if no error detection is required.
> */
> int start_cpu(int cpu_num,..., Error *err);
> ```
> Both approaches (2 & 3) will work, but there will be two versions of
> existing SBI functions to maintain the compatibility.
> 

If we keep the first field of sbi_report as the status code then
3 is equivalent to 2. If you just want to get the status/error code
you cast the pointer to uint32_t* instead of struct sbi_report*.

My vote goes for (1 || 2 with the mods above), meaning that I
believe we should support both, 1 for simple functions that
just want to return a value and 2 for more complex functions
that want to also return a payload or that distinguish the
return value from an error code. Alternatively I'd go with
just 2 with the mods above, since it covers both cases.

> ## SBI Functions:
> 
> A SBI function is an individual feature that SBI interface provides to
> supervisor mode from machine mode. Each function ID is assigned as per
> below section.
> 

As I mentioned on the previous version of your proposal
I'd like to be able to call these functions from U and
HS/HU modes as well. I think having a limitation for
accessing M mode only from S mode is wrong.

> #### SBI Function ID numbering scheme:
> A Function Set is a group of SBI functions which collectively
> implement similar kind of feature/functionality. The function ID
> numbering scheme need to be scalable in the future. At the same time,
> function validation check should be as quick as possible. Keeping
> these two requirements in mind, a hybrid function ID scheme is
> proposed.
> 
> SBI Function ID is u32 type.
> 
> ```
> 31            24                        0
> -----------------------------------------
> |O|            |                        |
> -----------------------------------------
> Function Set   | Function Type          |
> ```
> Bit[31]    =  ID overflow bit
> 
> Bit[30:24] =  Function Set
> 
> Bit[23:0]  =  Function Type within Function Set
> 
> The Function set is Bits [31:24] describing both function set number
> and overflow bit. In the beginning, the overflow bit should be set to
> **zero** and the function Type per function set can be assigned by
> left shifting 1 bit at a time. The overflow bit can be set to one
> **only** when we need to allocate more than 24 functions per function
> set in future. Setting the overflow bit will indicate an integer
> function type scheme. Thus, there will more than enough function IDs
> available to use in the future. Refer appendix 1 for examples.
> 
> Here are few Function Sets for SBI v0.2:
> 
> | Function Set         | Value  | Description       |
> | -------------------  |:------:| 
> :--------------------------------------------|
> | Base Functions       | 0x00   | Base Functions mandatory for any SBI 
> version |
> | HART PM Functions    | 0x01   | Hart UP/Down/Suspend Functions for
> per-Hart power management|
> | System PM Functions  | 0x02   | System Shutdown/Reboot/Suspend for
> system-level power management|
> | Vendor Functions     | 0x7f   | Vendor specific Functions|
> 
> N.B. There is a possibility that different vendors can choose to
> assign the same function numbers for different functionality. That's
> why vendor specific strings in Device Tree/ACPI or any other hardware
> description document can be used to verify if a specific Function
> belongs to the intended vendor or not.
> 
> # SBI Function List in both SBI v0.2 and v0.1
> 
> |Function Type              | Function Set      | ID(v0.2)     |ID 
> (v0.1)  |
> |---------------------------| 
> ------------------|:------------:|:---------:|
> | sbi_set_timer             | Base              | 0x00 000000  |0       
>    |
> | sbi_console_putchar       | Base              | 0x00 000001  |1       
>    |
> | sbi_console_getchar       | Base              | 0x00 000002  |2       
>    |
> | sbi_clear_ipi             | Base              | 0x00 000004  |3       
>    |
> | sbi_send_ipi              | Base              | 0x00 000008  |4       
>    |
> | sbi_remote_fence_i        | Base              | 0x00 000010  |5       
>    |
> | sbi_remote_sfence_vma     | Base              | 0x00 000020  |6       
>    |
> | sbi_remote_sfence_vma_asid| Base              | 0x00 000040  |7       
>    |
> | sbi_shutdown              | System PM         | 0x02 000000  |8       
>    |
> | sbi_system_reset          | System PM         | 0x02 000001  |-       
>    |
> | sbi_get_version           | Base              | 0x00 000080  |-       
>    |
> | sbi_get_function_mask     | Base              | 0x00 000100  |-       
>    |
> | sbi_get_function_count    | Base              | 0x00 000200  |-       
>    |
> | sbi_hart_up               | Hart PM           | 0x01 000000  |-       
>    |
> | sbi_hart_down             | Hart PM           | 0x01 000001  |-       
>    |
> | sbi_hart_suspend          | Hart PM           | 0x01 000002  |-       
>    |
> | sbi_hart_state            | Hart PM           | 0x01 000004  |-       
>    |
> 

While I agree with the concept of categorizing functions, I think the
implementation is a bit complicated. We can just have function id
ranges instead of wasting a byte for encoding a category within the
function id. Also this approach will be backwards compatible with the
function ids we already have on current SBI.

Encoding function sets and a bitmask for functions, along with
the overflow bit on the function id seems overly complicated to me
and I don't see what we gain from this. We are wasting bits for
sets that may have only a few functions and need to support
overflow for sets that are larger than 24 functions which is not
that much, especially if you take vendor sets into account.
I understand that you want this bitmask for reporting back the list
of available functions per set but this can be done differently. For
example we can use introduce a function called sbi_call_check(uint32_t
function_id) and expect SBI_ERR_SUCCESS or SBI_ERR_NOT_SUPPORTED.

Also with regards to the DT/ACPI the hardware vendor doesn't always
imply firmware vendor. I think we should be more specific here.
Also needing a side channel to understand which vendor specific
function we are calling is suboptimal. We might want to call
a vendor specific SBI call for example before parsing DT or
ACPI.

I believe we should use GUIDs for vendor specific function calls
instead of function ids. Normally these are 128bit long (RFC 4122)
but we can get away with 64bits. Instead of allowing a range of
function ids for vendors, we can just specify one call to rule
them all, something like:

int sbi_vendor_call(uint32_t vfid_high, uint32_t vfid_low, void* arg)

under the hood this can be an SBI call e.g. with fid 0x10000000 that
takes 3 arguments (already supported), with the pointer on the 3rd
argument to point to a struct with the vendor call arguments on
call, and a pointer contain a struct sbi_report on return.

> #### Function Description
> 
> This section describes every newly introduced(in v0.2) function in
> details. Please refer to [1] for any v0.1 functions.
> 
> ```
> u32 sbi_get_version(void):
> ```
> Returns the current SBI version implemented by the firmware.
> version: uint32: Bits[31:16] Major Version
>              Bits[15:0] Minor Version
> 
> The existing SBI version can be 0.1. The proposed version will be at 
> 0.2
> A different major version may indicate possible incompatible functions.
> A different minor version must be compatible with each other even if
> they have a higher number of features.
> 
> ```
> u32 sbi_get_function_mask(u32 ftype)
> ```
> Given a function set type, it returns a bitmask of all functions IDs
> that are implemented for that function set.
> 
> ```
> u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long 
> count):
> ```
> 
> This is a **reserved** function that should only be used if overflow
> bit in SBI function ID is set.
> 
> Accepts a start_Function_id as an argument and returns if
> start_Function_id to (start_Function_id + count - 1) are supported or
> not.
> 
> A count can help in minimizing the number of the M-mode traps by
> checking a range of SBI functions together.
> 

As I mentioned above I thing this complicates things and forces a
suboptimal function id encoding. We can instead introduce something
like sbi_call_check() instead. As for the vendor calls, we can also
introduce:

int sbi_vendor_call_check(uint32_t vfid_high, uint32_t vfid_low);

Another reason I find sbi_vendor_call/sbi_vendor_call_check better
is because the function names follow the rest of the namespace scheme.
I'll come back to that later on.

> ```
> int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
> long priv)
> ```
> Brings up "hartid" either during initial boot or after a sbi_hart_down
> SBI call.
> 
> "start" points to a runtime-specified address where a hart can enter
> into supervisor mode. This must be a physical address.
> 
> "priv" is a private data that caller can use to pass information about
> execution context.
> 
> Return the appropriate SBI error code.
> 
> ```
> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
> long priv)
> ```
> Suspends the calling hart to a particular power state. Suspended hart
> will automatically wake-up based on some wakeup events at resume_entry
> physical address.
> 
> "priv" is a private data that caller can use to pass information about
> execution context. The SBI implementation must save a copy so that
> caller can reuse while restoring hart from suspend.
> 
> Return the appropriate SBI error code.
> 
> ```
> int sbi_hart_down()
> ```
> It powers off the hart and will be used in cpu-hotplug.
> Only individual hart can remove itself from supervisor mode. It can be
> moved to normal state only by sbi_hart_up function.
> 
> Return the appropriate SBI error code.
> 
> ```
> u32 sbi_hart_state(unsigned long hartid)
> ```
> Returns the RISCV_POWER_STATE for a specific hartid. This will help 
> make
> kexec like functionality more robust.
> 

I still think that it would be better to have sbi_hart_set_state and
sbi_hart_get_state instead of having different calls for different
states but I guess it's a matter of taste. Could we at least
use sbi_hart_get_state instead of sbi_hart_state to be consistent
with the rest of the calls that contain get/set on their name ?

> ```
> void sbi_system_reset(u32 reset_type)
> ```
> Reset the entire system.
> 

Could we please rename sbi_shutdown to sbi_system_shutdown so that
it's consistent with the _system_ namespace/category ?

> ## Return error code Table:
> Here are the SBI return error codes defined.
> 
> | Error Type               | Value  |
> | -------------------------|:------:|
> |  SBI_ERR_SUCCESS         |  0     |
> |  SBI_ERR_FAILURE         | -1     |
> |  SBI_ERR_NOT_SUPPORTED   | -2     |
> |  SBI_ERR_INVALID_PARAM   | -3     |
> |  SBI_ERR_DENIED          | -4     |
> |  SBI_ERR_INVALID_ADDRESS | -5     |
> 
> 

Since success is not error, could we call them status codes or just
return codes instead ?

Thank you for your time and effort on this !

Regards,
Nick

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: SBI extension proposal v2
  2018-11-12  4:33 ` mick
@ 2018-11-12  4:33   ` Nick Kossifidis
  2018-12-04 23:22   ` [sw-dev] " Atish Patra
  1 sibling, 0 replies; 67+ messages in thread
From: Nick Kossifidis @ 2018-11-12  4:33 UTC (permalink / raw)
  To: Atish Patra
  Cc: mark.rutland, Christoph Hellwig, Damien Le Moal, olof.johansson,
	alankao, abner.chang, anup, Palmer Dabbelt, Alexander Graf,
	Zong Li, Alistair Francis, paul.walmsley, Nick Kossifidis,
	sw-dev, linux-riscv, andrew

Hello Atish,

Στις 2018-11-10 04:42, Atish Patra έγραψε:
> Hi,
> I have updated the proposal based on feedback received on previous
> version. This version has a better scalable SBI Function ID
> numbering scheme. I have adopted markdown formatting for github docs.
> 
> If you prefer a github interface, it's available here as well.
> 
> https://github.com/riscv/riscv-sbi-doc/pull/12
> 
> Looking forward to your feedback.
> 
> Regards,
> Atish
> ------------------------------------------------------------------------
> 
> ## Introduction:
> This is a proposal to make SBI a flexible and extensible interface.
> It is based on the foundation policy of RISC-V i.e. modularity and
> openness. The proposal tries to introduces very few new mandatory SBI
> Functions, that are absolutely required to maintain backward
> compatibility. Everything else is optional so that it remains an open
> standard yet robust.
> 
> The current RISC-V SBI only defines a few mandatory functions such as
> inter-processor interrupts (IPI) interface, reprogramming timer, serial
> console, and memory barrier instructions. The existing SBI 
> documentation
> can be found here [1]. Many important functionalities such as power
> management/cpu-hotplug are not yet defined due to difficulties in
> accommodating modifications without breaking the backward compatibility
> with the current interface.
> 
> The proposed design is inspired by Power State Coordination Interface
> (PSCI) from ARM world. However, it adds only two new mandatory SBI
> calls providing version information and supported Functions, unlike
> PSCI where a significant number of functions are mandatory. The
> version of the existing SBI will be defined as a minimum version(0.1)
> which will always be backward compatible. Similarly, any Linux kernel
> with a newer feature will fall back if an older version of SBI does
> not support the updated capabilities. Both the operating system and
> SEE can be implemented to be two way backward compatible.
> 

Let's remove any references to Linux, it can be misleading since
this is supposed to be used by every OS.

> ## SBI Calling Conventions (TODO)
> There are some suggestions[3] to distinguish between SBI function
> return value and SBI calling sequence return value. Here are the few
> possible discussed ideas.
> 
> 1. Return a single value, but values in the range {-511, -1} are
> considered errors, whereas return values in the range {0, 2^XLEN-512}
> are considered success.
> 

I'm thinking about compatibility between a 64bit firmware and a 32bit
supervisor and vice-versa. If we report back values that can't fit
within 32bits, this is going to break things.

> 2. Every SBI function call may return the following structure
> ```
> struct valerr {
>   long value;
>   long error;
> };
> ```
> According to the RISC-V ABI spec[4], both a0 & a1 registers can be
> used for function return values.
> 

This makes sense, however let's allow for this to be extensible,
there may be SBI calls that want to return something more, there
may also be SBI calls that are asynchronous so it's a good idea I
think to also include the function id there. Also please let's use
typed integers instead. How about something like this:

struct sbi_report {
  uint32_t status;
  uint32_t value;
  uint32_t function_id;
  uint8_t has_payload;
  uint16_t payload_size;
  /* 1 byte hole */
  void payload[];
};

> 3. Introduce an extra argument that can return error by reference.
> ```
> /* Returns the CPU that was started.
>  * @err indicates an error ID if one occurred, otherwise 0.
>  * @err can be NULL if no error detection is required.
> */
> int start_cpu(int cpu_num,..., Error *err);
> ```
> Both approaches (2 & 3) will work, but there will be two versions of
> existing SBI functions to maintain the compatibility.
> 

If we keep the first field of sbi_report as the status code then
3 is equivalent to 2. If you just want to get the status/error code
you cast the pointer to uint32_t* instead of struct sbi_report*.

My vote goes for (1 || 2 with the mods above), meaning that I
believe we should support both, 1 for simple functions that
just want to return a value and 2 for more complex functions
that want to also return a payload or that distinguish the
return value from an error code. Alternatively I'd go with
just 2 with the mods above, since it covers both cases.

> ## SBI Functions:
> 
> A SBI function is an individual feature that SBI interface provides to
> supervisor mode from machine mode. Each function ID is assigned as per
> below section.
> 

As I mentioned on the previous version of your proposal
I'd like to be able to call these functions from U and
HS/HU modes as well. I think having a limitation for
accessing M mode only from S mode is wrong.

> #### SBI Function ID numbering scheme:
> A Function Set is a group of SBI functions which collectively
> implement similar kind of feature/functionality. The function ID
> numbering scheme need to be scalable in the future. At the same time,
> function validation check should be as quick as possible. Keeping
> these two requirements in mind, a hybrid function ID scheme is
> proposed.
> 
> SBI Function ID is u32 type.
> 
> ```
> 31            24                        0
> -----------------------------------------
> |O|            |                        |
> -----------------------------------------
> Function Set   | Function Type          |
> ```
> Bit[31]    =  ID overflow bit
> 
> Bit[30:24] =  Function Set
> 
> Bit[23:0]  =  Function Type within Function Set
> 
> The Function set is Bits [31:24] describing both function set number
> and overflow bit. In the beginning, the overflow bit should be set to
> **zero** and the function Type per function set can be assigned by
> left shifting 1 bit at a time. The overflow bit can be set to one
> **only** when we need to allocate more than 24 functions per function
> set in future. Setting the overflow bit will indicate an integer
> function type scheme. Thus, there will more than enough function IDs
> available to use in the future. Refer appendix 1 for examples.
> 
> Here are few Function Sets for SBI v0.2:
> 
> | Function Set         | Value  | Description       |
> | -------------------  |:------:| 
> :--------------------------------------------|
> | Base Functions       | 0x00   | Base Functions mandatory for any SBI 
> version |
> | HART PM Functions    | 0x01   | Hart UP/Down/Suspend Functions for
> per-Hart power management|
> | System PM Functions  | 0x02   | System Shutdown/Reboot/Suspend for
> system-level power management|
> | Vendor Functions     | 0x7f   | Vendor specific Functions|
> 
> N.B. There is a possibility that different vendors can choose to
> assign the same function numbers for different functionality. That's
> why vendor specific strings in Device Tree/ACPI or any other hardware
> description document can be used to verify if a specific Function
> belongs to the intended vendor or not.
> 
> # SBI Function List in both SBI v0.2 and v0.1
> 
> |Function Type              | Function Set      | ID(v0.2)     |ID 
> (v0.1)  |
> |---------------------------| 
> ------------------|:------------:|:---------:|
> | sbi_set_timer             | Base              | 0x00 000000  |0       
>    |
> | sbi_console_putchar       | Base              | 0x00 000001  |1       
>    |
> | sbi_console_getchar       | Base              | 0x00 000002  |2       
>    |
> | sbi_clear_ipi             | Base              | 0x00 000004  |3       
>    |
> | sbi_send_ipi              | Base              | 0x00 000008  |4       
>    |
> | sbi_remote_fence_i        | Base              | 0x00 000010  |5       
>    |
> | sbi_remote_sfence_vma     | Base              | 0x00 000020  |6       
>    |
> | sbi_remote_sfence_vma_asid| Base              | 0x00 000040  |7       
>    |
> | sbi_shutdown              | System PM         | 0x02 000000  |8       
>    |
> | sbi_system_reset          | System PM         | 0x02 000001  |-       
>    |
> | sbi_get_version           | Base              | 0x00 000080  |-       
>    |
> | sbi_get_function_mask     | Base              | 0x00 000100  |-       
>    |
> | sbi_get_function_count    | Base              | 0x00 000200  |-       
>    |
> | sbi_hart_up               | Hart PM           | 0x01 000000  |-       
>    |
> | sbi_hart_down             | Hart PM           | 0x01 000001  |-       
>    |
> | sbi_hart_suspend          | Hart PM           | 0x01 000002  |-       
>    |
> | sbi_hart_state            | Hart PM           | 0x01 000004  |-       
>    |
> 

While I agree with the concept of categorizing functions, I think the
implementation is a bit complicated. We can just have function id
ranges instead of wasting a byte for encoding a category within the
function id. Also this approach will be backwards compatible with the
function ids we already have on current SBI.

Encoding function sets and a bitmask for functions, along with
the overflow bit on the function id seems overly complicated to me
and I don't see what we gain from this. We are wasting bits for
sets that may have only a few functions and need to support
overflow for sets that are larger than 24 functions which is not
that much, especially if you take vendor sets into account.
I understand that you want this bitmask for reporting back the list
of available functions per set but this can be done differently. For
example we can use introduce a function called sbi_call_check(uint32_t
function_id) and expect SBI_ERR_SUCCESS or SBI_ERR_NOT_SUPPORTED.

Also with regards to the DT/ACPI the hardware vendor doesn't always
imply firmware vendor. I think we should be more specific here.
Also needing a side channel to understand which vendor specific
function we are calling is suboptimal. We might want to call
a vendor specific SBI call for example before parsing DT or
ACPI.

I believe we should use GUIDs for vendor specific function calls
instead of function ids. Normally these are 128bit long (RFC 4122)
but we can get away with 64bits. Instead of allowing a range of
function ids for vendors, we can just specify one call to rule
them all, something like:

int sbi_vendor_call(uint32_t vfid_high, uint32_t vfid_low, void* arg)

under the hood this can be an SBI call e.g. with fid 0x10000000 that
takes 3 arguments (already supported), with the pointer on the 3rd
argument to point to a struct with the vendor call arguments on
call, and a pointer contain a struct sbi_report on return.

> #### Function Description
> 
> This section describes every newly introduced(in v0.2) function in
> details. Please refer to [1] for any v0.1 functions.
> 
> ```
> u32 sbi_get_version(void):
> ```
> Returns the current SBI version implemented by the firmware.
> version: uint32: Bits[31:16] Major Version
>              Bits[15:0] Minor Version
> 
> The existing SBI version can be 0.1. The proposed version will be at 
> 0.2
> A different major version may indicate possible incompatible functions.
> A different minor version must be compatible with each other even if
> they have a higher number of features.
> 
> ```
> u32 sbi_get_function_mask(u32 ftype)
> ```
> Given a function set type, it returns a bitmask of all functions IDs
> that are implemented for that function set.
> 
> ```
> u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long 
> count):
> ```
> 
> This is a **reserved** function that should only be used if overflow
> bit in SBI function ID is set.
> 
> Accepts a start_Function_id as an argument and returns if
> start_Function_id to (start_Function_id + count - 1) are supported or
> not.
> 
> A count can help in minimizing the number of the M-mode traps by
> checking a range of SBI functions together.
> 

As I mentioned above I thing this complicates things and forces a
suboptimal function id encoding. We can instead introduce something
like sbi_call_check() instead. As for the vendor calls, we can also
introduce:

int sbi_vendor_call_check(uint32_t vfid_high, uint32_t vfid_low);

Another reason I find sbi_vendor_call/sbi_vendor_call_check better
is because the function names follow the rest of the namespace scheme.
I'll come back to that later on.

> ```
> int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
> long priv)
> ```
> Brings up "hartid" either during initial boot or after a sbi_hart_down
> SBI call.
> 
> "start" points to a runtime-specified address where a hart can enter
> into supervisor mode. This must be a physical address.
> 
> "priv" is a private data that caller can use to pass information about
> execution context.
> 
> Return the appropriate SBI error code.
> 
> ```
> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
> long priv)
> ```
> Suspends the calling hart to a particular power state. Suspended hart
> will automatically wake-up based on some wakeup events at resume_entry
> physical address.
> 
> "priv" is a private data that caller can use to pass information about
> execution context. The SBI implementation must save a copy so that
> caller can reuse while restoring hart from suspend.
> 
> Return the appropriate SBI error code.
> 
> ```
> int sbi_hart_down()
> ```
> It powers off the hart and will be used in cpu-hotplug.
> Only individual hart can remove itself from supervisor mode. It can be
> moved to normal state only by sbi_hart_up function.
> 
> Return the appropriate SBI error code.
> 
> ```
> u32 sbi_hart_state(unsigned long hartid)
> ```
> Returns the RISCV_POWER_STATE for a specific hartid. This will help 
> make
> kexec like functionality more robust.
> 

I still think that it would be better to have sbi_hart_set_state and
sbi_hart_get_state instead of having different calls for different
states but I guess it's a matter of taste. Could we at least
use sbi_hart_get_state instead of sbi_hart_state to be consistent
with the rest of the calls that contain get/set on their name ?

> ```
> void sbi_system_reset(u32 reset_type)
> ```
> Reset the entire system.
> 

Could we please rename sbi_shutdown to sbi_system_shutdown so that
it's consistent with the _system_ namespace/category ?

> ## Return error code Table:
> Here are the SBI return error codes defined.
> 
> | Error Type               | Value  |
> | -------------------------|:------:|
> |  SBI_ERR_SUCCESS         |  0     |
> |  SBI_ERR_FAILURE         | -1     |
> |  SBI_ERR_NOT_SUPPORTED   | -2     |
> |  SBI_ERR_INVALID_PARAM   | -3     |
> |  SBI_ERR_DENIED          | -4     |
> |  SBI_ERR_INVALID_ADDRESS | -5     |
> 
> 

Since success is not error, could we call them status codes or just
return codes instead ?

Thank you for your time and effort on this !

Regards,
Nick


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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* [sw-dev] SBI extension proposal v2
  2018-11-10 17:47           ` lkcl
                               ` (2 preceding siblings ...)
  2018-11-10 18:02             ` olof
@ 2018-11-13  1:22             ` michaeljclark
  2018-11-13  1:22               ` Michael Clark
  3 siblings, 1 reply; 67+ messages in thread
From: michaeljclark @ 2018-11-13  1:22 UTC (permalink / raw)
  To: linux-riscv



>> On 11/11/2018, at 6:47 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>> 
>> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> 
>> The case of console is in this case pretty simple: It's intended for
>> early boot for very simplistic environments (before the rest of the
>> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> and somehow trying to optimize for it for those use cases is a
>> misdirected effort; that's what native drivers are for.
> 
> spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.

Neither of those statements are completely true. Spike can have its hardware emulation capabilities expanded and QEMU is not unsuitable for experimental research. For example, we have been developing the CLIC interrupt controller model in QEMU.

We also could port VirtIO from RISCVEMU to spike. It would be nice to add the PLIC, CLIC and an NS16550A UART to spike so we can model the RISC-V ?virt? machine that is currently in QEMU.

That said, you are probably correct. A simulator like spike makes a little more sense for evolving the hardware models versus a heavy-weight fast-model emulator like QEMU.

> with nothing in spike *other* than the serial console, it's the only
> way in and out.

That?s likely to change.

There is bare metal code in BBL to support several console types (HTIF, SiFive UART, NS16550A). All of these except for HTIF have kernel device drivers. The main reason for the SBI console is to be used as a bring-up console before full device drivers have been developed and for simulation use-cases (running Linux in spike and HDL simulators).

Spike currently relies on HTIF for console and HTIF is not appropriate as a kernel device interface. HTIF is designed for tethered simulation as it relies on a front-end finding special ELF symbols used for host <-> target communications.

A polled-mode console interface is fine for debug but not appropriate for running something like pppd. Adding a tty layer (sbi_ioctl) to SBI is not a good idea. Note: an actual serial interface has several out-of-band interface to check link status and set baud rates, etc (as do the simple SBI drivers which have these details hardcoded). It?s a simple boot console.

Apologies Luke, this is not directed at you, rather it is directed at SBI.

I think we should seriously question any interface we add to SBI.

- Making SBI a library API is an invitation for binary blobs. It should remain an ECALL interface to fill in privilege boundary virtualization gaps i.e. functions that require M-mode privileges. It can?t or shouldn?t do this if it is linked to the kernel as a library. In the case it were a library the question is why not just document the hardware interface and add a driver to the kernel. For anything else, such as for virtualization; we should minimize address space footprint for anything that is not a device. Otherwise we should spend effort on defining standard hardware interfaces such as virtualizable interrupt controllers or PMUs.

- SBI shouldn?t be used as a wrapper to hide (as yet unspecified) hardware interfaces from the kernel. i.e. for example to hide a device aperture that contains configuration for both M-mode and S-mode interrupts or an interface for a function that we don?t yet have hardware for. It?s equally possible that we can make bad software interfaces.

There are some points up for discussion regards HALs.

There is a principle that functions that have typically been done in hardware can be simplified if certain aspects are devolved to software. This is valid.

We have this with S-mode timer and software interrupts which presently are delegated by the monitor who implements the SBI interface to configure or initiate them. This is not strictly because we don?t want to expose the hardware to Linux i.e. why not just write a driver in Linux? SBI is required here because these functions were initially only able to be executed in M-mode and it would violate a privilege boundary for Linux to run their code as Linux is a Supervisor. i.e. there was no direct interface for S-mode to configure or initiate software or timer interrupts.

I think the best approach is for folk to share their hardware interfaces and explore approaches that allow S-mode to operate autonomously whether M-mode exists or not. I.e. some models may require M-mode, and some models may support fully autonomous S-mode (the only M-mode function that exists is running on another core). e.g. Real-time.

Of course virtualization and real-time can be combined if the M-mode core can control interrupt routing tables on behalf of the running Supervisors. We could have multiple RTOS running with Supervisors that have pre-emptable User tasks and the virtual domains never need to enter M-mode, except perhaps for power on and power off. Maybe power management is in scope. One should probably chat to Linus about what he?d like to see... possibly not an in-kernel byte-code interpreter...


BTW Please do not swear on the list. Alex, Bruce, myself and the other posters have not written anything that warrants swearing at us. Many folk have been working away quietly in the open and the messages to the contrary are completely unfounded. Anyway this goes without saying. There is only one person swearing and shouting on this list.

Luke, you are incorrigible. Whether you are a bully or not is neither here nor there. Your behaviour on this mailing list is not acceptable. Try no shouting or swearing. Many have advised this before but there has been no change.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] SBI extension proposal v2
  2018-11-13  1:22             ` michaeljclark
@ 2018-11-13  1:22               ` Michael Clark
  0 siblings, 0 replies; 67+ messages in thread
From: Michael Clark @ 2018-11-13  1:22 UTC (permalink / raw)
  To: Luke Kenneth Casson Leighton
  Cc: mark.rutland, hch, Damien.LeMoal, Olof Johansson, alankao,
	abner.chang, atish.patra, Anup Patel, Palmer Dabbelt,
	Alexander Graf, zong, ron minnich, mick, sw-dev, paul.walmsley,
	Olof Johansson, Alistair.Francis, linux-riscv, Andrew Waterman



>> On 11/11/2018, at 6:47 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>> 
>> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> 
>> The case of console is in this case pretty simple: It's intended for
>> early boot for very simplistic environments (before the rest of the
>> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> and somehow trying to optimize for it for those use cases is a
>> misdirected effort; that's what native drivers are for.
> 
> spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.

Neither of those statements are completely true. Spike can have its hardware emulation capabilities expanded and QEMU is not unsuitable for experimental research. For example, we have been developing the CLIC interrupt controller model in QEMU.

We also could port VirtIO from RISCVEMU to spike. It would be nice to add the PLIC, CLIC and an NS16550A UART to spike so we can model the RISC-V “virt” machine that is currently in QEMU.

That said, you are probably correct. A simulator like spike makes a little more sense for evolving the hardware models versus a heavy-weight fast-model emulator like QEMU.

> with nothing in spike *other* than the serial console, it's the only
> way in and out.

That’s likely to change.

There is bare metal code in BBL to support several console types (HTIF, SiFive UART, NS16550A). All of these except for HTIF have kernel device drivers. The main reason for the SBI console is to be used as a bring-up console before full device drivers have been developed and for simulation use-cases (running Linux in spike and HDL simulators).

Spike currently relies on HTIF for console and HTIF is not appropriate as a kernel device interface. HTIF is designed for tethered simulation as it relies on a front-end finding special ELF symbols used for host <-> target communications.

A polled-mode console interface is fine for debug but not appropriate for running something like pppd. Adding a tty layer (sbi_ioctl) to SBI is not a good idea. Note: an actual serial interface has several out-of-band interface to check link status and set baud rates, etc (as do the simple SBI drivers which have these details hardcoded). It’s a simple boot console.

Apologies Luke, this is not directed at you, rather it is directed at SBI.

I think we should seriously question any interface we add to SBI.

- Making SBI a library API is an invitation for binary blobs. It should remain an ECALL interface to fill in privilege boundary virtualization gaps i.e. functions that require M-mode privileges. It can’t or shouldn’t do this if it is linked to the kernel as a library. In the case it were a library the question is why not just document the hardware interface and add a driver to the kernel. For anything else, such as for virtualization; we should minimize address space footprint for anything that is not a device. Otherwise we should spend effort on defining standard hardware interfaces such as virtualizable interrupt controllers or PMUs.

- SBI shouldn’t be used as a wrapper to hide (as yet unspecified) hardware interfaces from the kernel. i.e. for example to hide a device aperture that contains configuration for both M-mode and S-mode interrupts or an interface for a function that we don’t yet have hardware for. It’s equally possible that we can make bad software interfaces.

There are some points up for discussion regards HALs.

There is a principle that functions that have typically been done in hardware can be simplified if certain aspects are devolved to software. This is valid.

We have this with S-mode timer and software interrupts which presently are delegated by the monitor who implements the SBI interface to configure or initiate them. This is not strictly because we don’t want to expose the hardware to Linux i.e. why not just write a driver in Linux? SBI is required here because these functions were initially only able to be executed in M-mode and it would violate a privilege boundary for Linux to run their code as Linux is a Supervisor. i.e. there was no direct interface for S-mode to configure or initiate software or timer interrupts.

I think the best approach is for folk to share their hardware interfaces and explore approaches that allow S-mode to operate autonomously whether M-mode exists or not. I.e. some models may require M-mode, and some models may support fully autonomous S-mode (the only M-mode function that exists is running on another core). e.g. Real-time.

Of course virtualization and real-time can be combined if the M-mode core can control interrupt routing tables on behalf of the running Supervisors. We could have multiple RTOS running with Supervisors that have pre-emptable User tasks and the virtual domains never need to enter M-mode, except perhaps for power on and power off. Maybe power management is in scope. One should probably chat to Linus about what he’d like to see... possibly not an in-kernel byte-code interpreter...


BTW Please do not swear on the list. Alex, Bruce, myself and the other posters have not written anything that warrants swearing at us. Many folk have been working away quietly in the open and the messages to the contrary are completely unfounded. Anyway this goes without saying. There is only one person swearing and shouting on this list.

Luke, you are incorrigible. Whether you are a bully or not is neither here nor there. Your behaviour on this mailing list is not acceptable. Try no shouting or swearing. Many have advised this before but there has been no change.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: [sw-dev] Re: SBI extension proposal v2
  2018-11-12  4:33 ` mick
  2018-11-12  4:33   ` Nick Kossifidis
@ 2018-12-04 23:22   ` " Atish Patra
  1 sibling, 0 replies; 67+ messages in thread
From: Atish Patra @ 2018-12-04 23:22 UTC (permalink / raw)
  To: Nick Kossifidis
  Cc: mark.rutland, Christoph Hellwig, Damien Le Moal, olof.johansson,
	alankao, abner.chang, anup, Palmer Dabbelt, Alexander Graf,
	Zong Li, Alistair Francis, paul.walmsley, sw-dev, linux-riscv,
	andrew

On 11/11/18 8:34 PM, Nick Kossifidis wrote:
> Hello Atish,
> 

Apologies for not responding to this earlier. It got lost in the email 
flood. Thank you for reminding about this yesterday.

> Στις 2018-11-10 04:42, Atish Patra έγραψε:
>> Hi,
>> I have updated the proposal based on feedback received on previous
>> version. This version has a better scalable SBI Function ID
>> numbering scheme. I have adopted markdown formatting for github docs.
>>
>> If you prefer a github interface, it's available here as well.
>>
>> https://github.com/riscv/riscv-sbi-doc/pull/12
>>
>> Looking forward to your feedback.
>>
>> Regards,
>> Atish
>> ------------------------------------------------------------------------
>>
>> ## Introduction:
>> This is a proposal to make SBI a flexible and extensible interface.
>> It is based on the foundation policy of RISC-V i.e. modularity and
>> openness. The proposal tries to introduces very few new mandatory SBI
>> Functions, that are absolutely required to maintain backward
>> compatibility. Everything else is optional so that it remains an open
>> standard yet robust.
>>
>> The current RISC-V SBI only defines a few mandatory functions such as
>> inter-processor interrupts (IPI) interface, reprogramming timer, serial
>> console, and memory barrier instructions. The existing SBI
>> documentation
>> can be found here [1]. Many important functionalities such as power
>> management/cpu-hotplug are not yet defined due to difficulties in
>> accommodating modifications without breaking the backward compatibility
>> with the current interface.
>>
>> The proposed design is inspired by Power State Coordination Interface
>> (PSCI) from ARM world. However, it adds only two new mandatory SBI
>> calls providing version information and supported Functions, unlike
>> PSCI where a significant number of functions are mandatory. The
>> version of the existing SBI will be defined as a minimum version(0.1)
>> which will always be backward compatible. Similarly, any Linux kernel
>> with a newer feature will fall back if an older version of SBI does
>> not support the updated capabilities. Both the operating system and
>> SEE can be implemented to be two way backward compatible.
>>
> 
> Let's remove any references to Linux, it can be misleading since
> this is supposed to be used by every OS.
> 

ACK.

>> ## SBI Calling Conventions (TODO)
>> There are some suggestions[3] to distinguish between SBI function
>> return value and SBI calling sequence return value. Here are the few
>> possible discussed ideas.
>>
>> 1. Return a single value, but values in the range {-511, -1} are
>> considered errors, whereas return values in the range {0, 2^XLEN-512}
>> are considered success.
>>
> 
> I'm thinking about compatibility between a 64bit firmware and a 32bit
> supervisor and vice-versa. If we report back values that can't fit
> within 32bits, this is going to break things.
>
Yeah. That's valid point. I think we can keep both value & error to be 
uint32_t. We can clearly define uint64_t for for RV64GC and uint32_t for 
RV32GC if any functions require a 64bit value as an argument/return value.

Note: That's not my preferred choice. But it can be done.

>> 2. Every SBI function call may return the following structure
>> ```
>> struct valerr {
>>    long value;
>>    long error;
>> };
>> ```
>> According to the RISC-V ABI spec[4], both a0 & a1 registers can be
>> used for function return values.
>>
> 
> This makes sense, however let's allow for this to be extensible,
> there may be SBI calls that want to return something more, there
> may also be SBI calls that are asynchronous so it's a good idea I
> think to also include the function id there. Also please let's use
> typed integers instead. How about something like this:
> 

ACK for typed integers.

> struct sbi_report {
>    uint32_t status;
>    uint32_t value;
>    uint32_t function_id;
>    uint8_t has_payload;
>    uint16_t payload_size;
>    /* 1 byte hole */
>    void payload[];
> };
IMHO, that's overkill for SBI. Between error and value, I think we can 
cover all the cases.

> 
>> 3. Introduce an extra argument that can return error by reference.
>> ```
>> /* Returns the CPU that was started.
>>   * @err indicates an error ID if one occurred, otherwise 0.
>>   * @err can be NULL if no error detection is required.
>> */
>> int start_cpu(int cpu_num,..., Error *err);
>> ```
>> Both approaches (2 & 3) will work, but there will be two versions of
>> existing SBI functions to maintain the compatibility.
>>
> 
> If we keep the first field of sbi_report as the status code then
> 3 is equivalent to 2. If you just want to get the status/error code
> you cast the pointer to uint32_t* instead of struct sbi_report*.
> 
> My vote goes for (1 || 2 with the mods above), meaning that I
> believe we should support both, 1 for simple functions that
> just want to return a value and 2 for more complex functions
> that want to also return a payload or that distinguish the
> return value from an error code. Alternatively I'd go with
> just 2 with the mods above, since it covers both cases.
> 

Yeah 2 seems to be the best choice. We had a longer discussion about 
this during Linux Plumbers as well. Here are the notes in case you are 
interested.

https://etherpad.openstack.org/p/RISC-V

>> ## SBI Functions:
>>
>> A SBI function is an individual feature that SBI interface provides to
>> supervisor mode from machine mode. Each function ID is assigned as per
>> below section.
>>
> 
> As I mentioned on the previous version of your proposal
> I'd like to be able to call these functions from U and
> HS/HU modes as well. I think having a limitation for
> accessing M mode only from S mode is wrong.
> 

I understand your concern. However, this part of the specification is 
based on what is defined on privileged spec. I would like to keep it 
consistent with privileged spec.

>> #### SBI Function ID numbering scheme:
>> A Function Set is a group of SBI functions which collectively
>> implement similar kind of feature/functionality. The function ID
>> numbering scheme need to be scalable in the future. At the same time,
>> function validation check should be as quick as possible. Keeping
>> these two requirements in mind, a hybrid function ID scheme is
>> proposed.
>>
>> SBI Function ID is u32 type.
>>
>> ```
>> 31            24                        0
>> -----------------------------------------
>> |O|            |                        |
>> -----------------------------------------
>> Function Set   | Function Type          |
>> ```
>> Bit[31]    =  ID overflow bit
>>
>> Bit[30:24] =  Function Set
>>
>> Bit[23:0]  =  Function Type within Function Set
>>
>> The Function set is Bits [31:24] describing both function set number
>> and overflow bit. In the beginning, the overflow bit should be set to
>> **zero** and the function Type per function set can be assigned by
>> left shifting 1 bit at a time. The overflow bit can be set to one
>> **only** when we need to allocate more than 24 functions per function
>> set in future. Setting the overflow bit will indicate an integer
>> function type scheme. Thus, there will more than enough function IDs
>> available to use in the future. Refer appendix 1 for examples.
>>
>> Here are few Function Sets for SBI v0.2:
>>
>> | Function Set         | Value  | Description       |
>> | -------------------  |:------:|
>> :--------------------------------------------|
>> | Base Functions       | 0x00   | Base Functions mandatory for any SBI
>> version |
>> | HART PM Functions    | 0x01   | Hart UP/Down/Suspend Functions for
>> per-Hart power management|
>> | System PM Functions  | 0x02   | System Shutdown/Reboot/Suspend for
>> system-level power management|
>> | Vendor Functions     | 0x7f   | Vendor specific Functions|
>>
>> N.B. There is a possibility that different vendors can choose to
>> assign the same function numbers for different functionality. That's
>> why vendor specific strings in Device Tree/ACPI or any other hardware
>> description document can be used to verify if a specific Function
>> belongs to the intended vendor or not.
>>
>> # SBI Function List in both SBI v0.2 and v0.1
>>
>> |Function Type              | Function Set      | ID(v0.2)     |ID
>> (v0.1)  |
>> |---------------------------|
>> ------------------|:------------:|:---------:|
>> | sbi_set_timer             | Base              | 0x00 000000  |0
>>     |
>> | sbi_console_putchar       | Base              | 0x00 000001  |1
>>     |
>> | sbi_console_getchar       | Base              | 0x00 000002  |2
>>     |
>> | sbi_clear_ipi             | Base              | 0x00 000004  |3
>>     |
>> | sbi_send_ipi              | Base              | 0x00 000008  |4
>>     |
>> | sbi_remote_fence_i        | Base              | 0x00 000010  |5
>>     |
>> | sbi_remote_sfence_vma     | Base              | 0x00 000020  |6
>>     |
>> | sbi_remote_sfence_vma_asid| Base              | 0x00 000040  |7
>>     |
>> | sbi_shutdown              | System PM         | 0x02 000000  |8
>>     |
>> | sbi_system_reset          | System PM         | 0x02 000001  |-
>>     |
>> | sbi_get_version           | Base              | 0x00 000080  |-
>>     |
>> | sbi_get_function_mask     | Base              | 0x00 000100  |-
>>     |
>> | sbi_get_function_count    | Base              | 0x00 000200  |-
>>     |
>> | sbi_hart_up               | Hart PM           | 0x01 000000  |-
>>     |
>> | sbi_hart_down             | Hart PM           | 0x01 000001  |-
>>     |
>> | sbi_hart_suspend          | Hart PM           | 0x01 000002  |-
>>     |
>> | sbi_hart_state            | Hart PM           | 0x01 000004  |-
>>     |
>>
> 
> While I agree with the concept of categorizing functions, I think the
> implementation is a bit complicated. We can just have function id
> ranges instead of wasting a byte for encoding a category within the
> function id. Also this approach will be backwards compatible with the
> function ids we already have on current SBI.
> 
> Encoding function sets and a bitmask for functions, along with
> the overflow bit on the function id seems overly complicated to me
> and I don't see what we gain from this. We are wasting bits for
> sets that may have only a few functions and need to support
> overflow for sets that are larger than 24 functions which is not
> that much, especially if you take vendor sets into account.
> I understand that you want this bitmask for reporting back the list
> of available functions per set but this can be done differently. For
> example we can use introduce a function called sbi_call_check(uint32_t
> function_id) and expect SBI_ERR_SUCCESS or SBI_ERR_NOT_SUPPORTED.
> 

Yeah. I had that in the first version. I will drop the above complicated 
scheme.

> Also with regards to the DT/ACPI the hardware vendor doesn't always
> imply firmware vendor. I think we should be more specific here.
> Also needing a side channel to understand which vendor specific
> function we are calling is suboptimal. We might want to call
> a vendor specific SBI call for example before parsing DT or
> ACPI.
> 
> I believe we should use GUIDs for vendor specific function calls
> instead of function ids. Normally these are 128bit long (RFC 4122)
> but we can get away with 64bits. Instead of allowing a range of
> function ids for vendors, we can just specify one call to rule
> them all, something like:
> 
> int sbi_vendor_call(uint32_t vfid_high, uint32_t vfid_low, void* arg)
> 
> under the hood this can be an SBI call e.g. with fid 0x10000000 that
> takes 3 arguments (already supported), with the pointer on the 3rd
> argument to point to a struct with the vendor call arguments on
> call, and a pointer contain a struct sbi_report on return.
> 

Thanks for your inputs. We can discuss these in details during vendor 
SBI extension proposal.

>> #### Function Description
>>
>> This section describes every newly introduced(in v0.2) function in
>> details. Please refer to [1] for any v0.1 functions.
>>
>> ```
>> u32 sbi_get_version(void):
>> ```
>> Returns the current SBI version implemented by the firmware.
>> version: uint32: Bits[31:16] Major Version
>>               Bits[15:0] Minor Version
>>
>> The existing SBI version can be 0.1. The proposed version will be at
>> 0.2
>> A different major version may indicate possible incompatible functions.
>> A different minor version must be compatible with each other even if
>> they have a higher number of features.
>>
>> ```
>> u32 sbi_get_function_mask(u32 ftype)
>> ```
>> Given a function set type, it returns a bitmask of all functions IDs
>> that are implemented for that function set.
>>
>> ```
>> u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long
>> count):
>> ```
>>
>> This is a **reserved** function that should only be used if overflow
>> bit in SBI function ID is set.
>>
>> Accepts a start_Function_id as an argument and returns if
>> start_Function_id to (start_Function_id + count - 1) are supported or
>> not.
>>
>> A count can help in minimizing the number of the M-mode traps by
>> checking a range of SBI functions together.
>>
> 
> As I mentioned above I thing this complicates things and forces a
> suboptimal function id encoding. We can instead introduce something
> like sbi_call_check() instead. As for the vendor calls, we can also
> introduce:
> 
> int sbi_vendor_call_check(uint32_t vfid_high, uint32_t vfid_low);
> 
> Another reason I find sbi_vendor_call/sbi_vendor_call_check better
> is because the function names follow the rest of the namespace scheme.
> I'll come back to that later on.
> 



>> ```
>> int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
>> long priv)
>> ```
>> Brings up "hartid" either during initial boot or after a sbi_hart_down
>> SBI call.
>>
>> "start" points to a runtime-specified address where a hart can enter
>> into supervisor mode. This must be a physical address.
>>
>> "priv" is a private data that caller can use to pass information about
>> execution context.
>>
>> Return the appropriate SBI error code.
>>
>> ```
>> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
>> long priv)
>> ```
>> Suspends the calling hart to a particular power state. Suspended hart
>> will automatically wake-up based on some wakeup events at resume_entry
>> physical address.
>>
>> "priv" is a private data that caller can use to pass information about
>> execution context. The SBI implementation must save a copy so that
>> caller can reuse while restoring hart from suspend.
>>
>> Return the appropriate SBI error code.
>>
>> ```
>> int sbi_hart_down()
>> ```
>> It powers off the hart and will be used in cpu-hotplug.
>> Only individual hart can remove itself from supervisor mode. It can be
>> moved to normal state only by sbi_hart_up function.
>>
>> Return the appropriate SBI error code.
>>
>> ```
>> u32 sbi_hart_state(unsigned long hartid)
>> ```
>> Returns the RISCV_POWER_STATE for a specific hartid. This will help
>> make
>> kexec like functionality more robust.
>>
> 
> I still think that it would be better to have sbi_hart_set_state and
> sbi_hart_get_state instead of having different calls for different
> states but I guess it's a matter of taste. Could we at least
> use sbi_hart_get_state instead of sbi_hart_state to be consistent
> with the rest of the calls that contain get/set on their name ?
> 

ACK.

>> ```
>> void sbi_system_reset(u32 reset_type)
>> ```
>> Reset the entire system.
>>
> 
> Could we please rename sbi_shutdown to sbi_system_shutdown so that
> it's consistent with the _system_ namespace/category ?
> 

ACK. However, sbi_shutdown is already a part of legacy APIs. So it has 
to be supported that way.

The power management SBI extension, we will use the consistent naming.

>> ## Return error code Table:
>> Here are the SBI return error codes defined.
>>
>> | Error Type               | Value  |
>> | -------------------------|:------:|
>> |  SBI_ERR_SUCCESS         |  0     |
>> |  SBI_ERR_FAILURE         | -1     |
>> |  SBI_ERR_NOT_SUPPORTED   | -2     |
>> |  SBI_ERR_INVALID_PARAM   | -3     |
>> |  SBI_ERR_DENIED          | -4     |
>> |  SBI_ERR_INVALID_ADDRESS | -5     |
>>
>>
> 
> Since success is not error, could we call them status codes or just
> return codes instead ?
> 

Yup. Return code is ok.


Regards,
Atish
> Thank you for your time and effort on this !
> 
> Regards,
> Nick
> 



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

^ permalink raw reply	[flat|nested] 67+ messages in thread

end of thread, back to index

Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-10  2:42 SBI extension proposal v2 atish.patra
2018-11-10  2:42 ` Atish Patra
2018-11-10  5:12 ` [sw-dev] " lkcl
2018-11-10  5:12   ` Luke Kenneth Casson Leighton
2018-11-10 14:50   ` mick
2018-11-10 14:50     ` Nick Kossifidis
2018-11-10 15:48     ` lkcl
2018-11-10 15:48       ` Luke Kenneth Casson Leighton
2018-11-10 16:46       ` rminnich
2018-11-10 16:46         ` ron minnich
2018-11-10 17:40         ` lkcl
2018-11-10 17:40           ` Luke Kenneth Casson Leighton
2018-11-10 17:41         ` sam.falvo
2018-11-10 17:41           ` Samuel Falvo II
2018-11-10 17:42           ` lkcl
2018-11-10 17:42             ` Luke Kenneth Casson Leighton
2018-11-10 17:51             ` sam.falvo
2018-11-10 17:51               ` Samuel Falvo II
2018-11-10 17:55               ` lkcl
2018-11-10 17:55                 ` Luke Kenneth Casson Leighton
2018-11-10 18:03                 ` sam.falvo
2018-11-10 18:03                   ` Samuel Falvo II
2018-11-10 17:43           ` sam.falvo
2018-11-10 17:43             ` Samuel Falvo II
2018-11-10 17:41         ` olof
2018-11-10 17:41           ` Olof Johansson
2018-11-10 17:47           ` lkcl
2018-11-10 17:47             ` Luke Kenneth Casson Leighton
2018-11-10 17:59             ` mick
2018-11-10 17:59               ` Nick Kossifidis
2018-11-10 18:01               ` rminnich
2018-11-10 18:01                 ` ron minnich
2018-11-10 19:33                 ` lkcl
2018-11-10 19:33                   ` Luke Kenneth Casson Leighton
2018-11-10 19:39               ` lkcl
2018-11-10 19:39                 ` Luke Kenneth Casson Leighton
2018-11-11  3:15                 ` mick
2018-11-11  3:15                   ` Nick Kossifidis
2018-11-11  7:14                   ` lkcl
2018-11-11  7:14                     ` Luke Kenneth Casson Leighton
2018-11-11 13:17                     ` mick
2018-11-11 13:17                       ` Nick Kossifidis
2018-11-12  2:08                     ` palmer
2018-11-12  2:08                       ` Palmer Dabbelt
2018-11-10 18:02             ` olof
2018-11-10 18:02               ` Olof Johansson
2018-11-10 19:34               ` lkcl
2018-11-10 19:34                 ` Luke Kenneth Casson Leighton
2018-11-13  1:22             ` michaeljclark
2018-11-13  1:22               ` Michael Clark
2018-11-10 17:54           ` mick
2018-11-10 17:54             ` Nick Kossifidis
2018-11-10 17:59           ` rminnich
2018-11-10 17:59             ` ron minnich
2018-11-11  3:58         ` atish.patra
2018-11-11  3:58           ` Atish Patra
2018-11-10 17:43       ` mick
2018-11-10 17:43         ` Nick Kossifidis
2018-11-10 17:51         ` lkcl
2018-11-10 17:51           ` Luke Kenneth Casson Leighton
2018-11-10  5:36 ` david.abdurachmanov
2018-11-10  5:36   ` David Abdurachmanov
     [not found]   ` <CA++6G0BTdybjhqaXm9EhAz0HsgpwfozK6OEL7DuzbS48RbEChA@mail.gmail.com>
2018-11-10 15:09     ` mick
2018-11-10 15:09       ` Nick Kossifidis
2018-11-12  4:33 ` mick
2018-11-12  4:33   ` Nick Kossifidis
2018-12-04 23:22   ` [sw-dev] " Atish Patra

Linux-RISC-V Archive on lore.kernel.org

Archives are clonable: git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \
		linux-riscv@lists.infradead.org infradead-linux-riscv@archiver.kernel.org
	public-inbox-index linux-riscv


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv


AGPL code for this site: git clone https://public-inbox.org/ public-inbox