riscv/configuration-structure

RISC-V Configuration Structure

configuration-structure's Issues

Universal Scalable Firmware

Involving the EDK II and U-Boot community a Universal Scalable Firmware Specification has been developped. We should try to be conformant with that specification or to contribute to it. Cf.
https://universalscalablefirmware.github.io/documentation/2_universal_payload.html#payload-interfaces

Questions or clarifications on configuration structure yaml and schema

Hi,

There are a few questions/issues formulating the configuration structure yaml.

1. The schema has a TODO against trace actions 2-4. The intention is to use traceOnSupported, traceOffSupported, traceNotifySupported. Can you let us know if this is alright?

2. The schema has icount, itrigger, etrigger and mcontrol6 to be optional. Not mentioning any of these would mean its not supported?

3. haltGroupCount and resumeGroupCount support values of integer 1 to 31 in the schema. Absence of halt group and resume group would need them to be 0. Is it a schema issue?

4. How do we imply that the Quick Access Command is not supported in the yaml? I see in the schema that QuickAccessCommand ::= SEQUENCE { supported = NULL, …}

5. If the dscratch registers are not implemented, the hartinfo will have nscratch to be 0 and dataaccess in yaml to be none: NULL. Does that sound right?

Thanks in advance for your help.

Regards,
Swaraj

Tool.py to generate human-readable string of schema type for debugging purpose

Generate human-readable string in Cschema C-header file which can be referred by C decoder to display more information for the debugging purpose.

VLEN specified though RVVConfig?

Why does schema use RVVConfig to describe vlen and not the Zvl* extensions?

Upgrade CI to leverage the last containerized version provided by RVI

@sqzsq I'm opening this to register that I willl submit an upgrade soon. That will require some changes which will improve the build process and make it a bit simpler.

Relation to platform Devicetree

Hi all,

After reading through this specification, I have some questions regarding the purpose of it when compared with Devicetree system discovery and whether its meant to supplement or replace it.

This document specifies syntax, semantics, discovery method, and access method for a static data structure that can accommodate implementation parameters of RISC-V standards beyond what can be easily put into CSRs.

It seems to me that the information that this specification wants to provide to M-mode software could just as well be put into the devicetree itself (and if missing, the M-mode software could then fallback to some default assumptions or other discovery methods). This has the added benefit of not needing to bring in an entire ASN.1 parser (which I believe has an entire other host of issues that I would like to discuss in a separate issue sometime soon) to retrieve the extra information (as it stands right now, at least). The "static data structure" seems to imply that the devicetrees are generated on the fly, as well as this portion of the specification:

Often system firmware will take the information it has learned from the system description as well as through other methods, and encode it into a different industry-standard data structure (like Devicetree). This structure is then passed to the subsequent boot process.

But I don't think that statement is quite accurate with the hardware I've seen (though I could be wrong!), usually the devicetree is hardcoded into the firmware whenever its built (example I was able to find here), as creating FDTs is somewhat non-trivial at that level as its going to require some kind of memory allocation and fixups. So the devicetree is already a "static data structure" that I would hedge bets on almost all M-mode firmware already including an FDT parser, so what advantage does the Configuration Structure provide over including additional properties in the devicetree for the system, especially in terms of the software complexity required to support the CS in its current form?

And related to that, the RISC-V Platform Specification says this about hardware discovery:

2.1.6.2. Hardware Discovery Mechanisms

Device Tree (DT) is the required mechanism for system description.

Platforms must support the Unified Discovery specification for all pre-boot information population [20].

(Is this specification part of the Unified Discovery specification that it references?)

Which means that every platform-spec-compliant board (as well as most others since it seems to be the de facto standard for system descriptions) will already have a devicetree required to actually describe the system in the first place.

Convert the project to docs-template

The Config documentation need to be in the RISC-V format. I've discussed getting there with @timsifive and he agreed to let me take a look at this.

Four things were needed:

1. Import of docs-template project into a subdirectory (docs-template)
2. Addition of symbolic links in the resources/ and resources/images/ directories for the fonts/ themes/ and images/ (RISC-V)
3. Updates to the Makefile to use more options on asciidoctor build
4. Updates to the main .adoc file to include more variables for the build

I got it working and inadvertently pushed my updates back to main in commit #19430d9. Sorry about that!!!

If anyone sees problems with the updates, feel free to reach out or add information to this issue. I'll leave it open until we've had a chance to discuss it more and prove things are working as expected.

Again, my apologies for the push to master!
-Jeff

should we use AsciiDoc format instead of LaTeX?

Clarify the wording of "static" and "embedding" in spec

• CS is "static" to the user of CS.
• "Embedding" implied a CS is not modifiable? (CS may be modified before it is exposed to mconfigpt)

Configuration structure is static

In the latest draft I don't see it mentioned that the configuration structure is static. I think it's important to clarify that the structure is the same every time it's read. It does not dynamically change between power-ups (e.g. when a USB device is plugged in).

C decoder to display human-readable string when it parses binary

This is for the debugging purposes, rely on #16

Decoder to handle the schema-type which has zero count of entry

Stop decoding binary or skipping the piece of binary if the configuration structure type has no entries defined in schema_types structure. For example, quick_access_command in schema-limited.json5.

Empty configuration structure entry causes compiler error

For example in scheman.json5, quick_access_command doesn't have any descriptions as below,
quick_access_command: {
// There are no options. If the option exists, then the feature is implemented.
},
That generates an empty entry in schema.c with an unknown size compiler error on Visual Studio C.

What is the purpose of an empty configuration structure defined in shcema?

List of discoverable capabilities?

Is there a list published for what sort of capabilities can be discovered using unified discovery?
For instance are any of the following in scope?

• CSR WARL field encodings and WPRI field position
• Address translation cache information
• Cache information
• Cache block size
• Reservation set size
• time frequency and resolution
• Number of HPM counters
• Number of debug triggers and trigger capabilities
• Addresses of memory mapped peripherals - IMSIC, PLIC, mtime, etc.
• core cycles frequency
• etc.

The way of storage for CS (Configuration Structure) and mconfigtr CSR

1. What are the requirements or suggestions for the CS storage method: RAM, ROM, or non-volatile efuse?

2. Is the mconfigtr CSR burned into efuse after tape-out? or it is written into firmware after tape-out, or it can be written by firmware after the boot?

3. Whether the mconfigtr can be read only after the core is powered on, or it can be read by a debugger from outside the cluster?

Comments/questions

I have several comments and questions which I'll lump into one issue for convenience.

1. Section 2.1.2:

Each of those triggers can be one of 4 types

There are at least 5 trigger types: icount, itrigger, etrigger, mcontrol6, tmexttrigger. Maybe more if you count mcontrol and legacy SiFive triggers (which are both deprecated) and custom triggers (which are not). So something more vague like "several" is better than a fixed value.

2. Also in 2.1.2:

It’s permissible for features to be implemented, but not in all combinations.

That sentence was confusing for me. Maybe something like "It's permissible for features to be implemented in some combinations but not other combinations."

3. In section 4.2 "Extending the Schema" it's not clear to me if step 4 involves official ratification of the proposed extension. Mainly, I want to know if step 5 only happens for ratified extensions and not for draft versions.

4. Section 4.3 item 4:

Some INTEGERs, such as number of harts, might have a large range but are usually small numbers. Leave those without upper bound instead of using the absolute highest value they could have. Example: hartid INTEGER (0..MAX)

That example appears to violate its own suggestion by including an upper bound. Or is the idea that MAX is a variable instead of a fixed value? If so, that could be clearer (from the perspective of someone who doesn't know ASN.1).

5. Section 6.1:

The binary Configuration Structure is accessible by performing reads on the system bus.

System bus access is optional in the debug spec, so if it's not implemented then does this whole thing fall apart with respect to the external debugger?

6. Section 7 has a typo here:

following the format descriped in the schema

7. A couple of places refer to the value of XLEN. XLEN means the size of integer registers in the current mode, though the current mode is not static and the CS is. When referring to the value of XLEN, does that mean DXLEN (which is fixed)? Does it mean MXLEN (which software might be able to change but presumably won't change dynamically)? Or does CS contain something like SLXEN (1..2) and UXLEN (1..2) if those values can be changed by software?

8. Section 7.3 implies at the end that pointers are 8 bytes. Is this CS standard forward-compatible with RV128?

9. The second paragraph in section 8.2 is missing a period at the end.

10. Does this support describing custom extensions, custom triggers, custom satp.MODE values, custom CSRs, etc.? If a particular custom extension is popular enough, debuggers would presumably support it and want to detect it.

write tool that detects conflicts in CS

At best it's worth a warning. At worst it's invalid, depending on what exactly ends up going into the spec.