Relation to platform Devicetree

[repnop]

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.

[vlsunil]

+1.... I have the same question regarding the purpose.

[changab]

Besides the use case of the external debugger that can read the CS to discover the HART features for debugging purposes(@timsifive can add more on this), CS also provides the hardware features of HART which can't be described by DT in a static way. The "static data structure" mentioned in this spec refers to the read only data structure that goes with the HART, but is not with the platform.

Your statement makes sense if the processor is fixed on the platform and the customer is not able to change it, the device tree can sever this use case well. However, if you consider the 2 or 4 sockets platform which is not delivered to customers with processors full populated, customers can add the different SKUs of the same generation RISC-V processor which may have different hardware features, then system firmware can discover the hardware feature dynamically at early power stage, execute the different code path, and turn it into other data structures such as DT or SMBIOS for the next phase firmware or OS usage. Or on the desktop platform, the system firmware can support few models of RISC-V processors. Configuration structure servers the purpose of dynamic HART feature discovery. Furthermore, instead of putting FDT into the processor, ASN.1 has a very compact binary encoding that is suitable for tiny to large scale platforms.

And yes, the Unified Discover mentioned in the platform spec refers to access method mentioned in this spec. CS will be converted and merged into DT for those HART features that can't be hardcoded in DT.

[vlsunil]

How does config structure get updated for drop-in processor features? If it again needs reflashing, why not provide a new DTB itself? If the new socket itself has some kind of memory with this information, how does single config structure address work for multiple sockets?

[vlsunil]

Sorry I just saw that it can be part of per socket SPI ROM and each hart can access its own using the same address. Do we allow drop-in sockets with different schema?

[repnop]

However, if you consider the 2 or 4 sockets platform which is not delivered to customers with processors full populated, customers can add the different SKUs of the same generation RISC-V processor which may have different hardware features, then system firmware can discover the hardware feature dynamically at early power stage, execute the different code path, and turn it into other data structures such as DT or SMBIOS for the next phase firmware or OS usage.

Okay this makes a lot more sense now, thank you! It wasn't obvious to me that this would be something that's part of the CPU itself, rather it sounded much more like something analogous to a system wide Devicetree, just different, so it would probably be worthwhile IMO to expand a bit on that in the specification to make things a bit more clear.

Furthermore, instead of putting FDT into the processor, ASN.1 has a very compact binary encoding that is suitable for tiny to large scale platforms.

While I can definitely understand the desire to use something like ASN.1's UPER format to have a compact binary format, I believe that ASN.1 has a lot of issues that make it a poor choice for most things, but I'll open another issue sometime soon to discuss those points specifically. :+1:

[changab]

ow does config structure get updated for drop-in processor features? If it again needs reflashing, why not provide a new DTB itself?

Do we allow drop-in sockets with different schema?

What does the drop-in socket exactly mean? The schema is defined by this TG to support the official RISC-V extensions. each HART can has its own values that declared follow the schema. OEM proprietary schema is also allowed, just OEM has to provide the firmware driver to consume those values and turns it into DT because only OEM knows those values.

[changab]

Okay this makes a lot more sense now, thank you! It wasn't obvious to me that this would be something that's part of the CPU itself, rather it sounded much more like something analogous to a system wide Devicetree, just different, so it would probably be worthwhile IMO to expand a bit on that in the specification to make things a bit more clear.

Sure. We are now revising the spec. We can make it more clear. Thanks.

[changab]

How does config structure get updated for drop-in processor features?

Suppose the CS shouldn't be changed (or updated) because the hardware features are fixed in HART. Unless there are some special use cases that can fuse the feature. In that case, the CS should be updated to reflect the latest HW feature availability by the processor firmware (I don't know if that exists. Maybe the zero stage boot loader or even earlier?). This is agnostic to FW because FW only simply reads CS from the pointer indicated in CSR.

If it again needs reflashing, why not provide a new DTB itself?

Update firmware is a big risk to customers especially to the servers just for supporting the different SKUs of one generation of RISC-V processors. Update DTB doesn't help because we don't know the socket #1 would be installed with SKU1 or SKU2 processor.

[vlsunil]

Thanks Abner. It clarifies many things to me.

I understand the schema is getting defined by RVI or OEM. But my question is, will there be multiple versions of the schema within RVI itself? For ex : If crypto has 10 different extensions today and schema is frozen, then maybe 1 year down the line if there is a requirement to add a new extension within crypto, would it need a new schema?Or there can be a completely new group of extensions. If so, does the new schema need to be integrated with the decoder(m-mode FW)? In that context, I had this question whether we allow sockets with different schema or should the same schema be used but there can be differences in extensions implemented between different sockets?

Sorry, this question could be because of my ignorance of how asn encoder/decoder and schema works.

[changab]

For those ISA or HART features that may have extensions in the future, we can use ASN.1 notation "..." in the schema.

crypto ::=  {
  a INTEGER  (0..255),
  b BOOLEAN,
 ...
}

If crypto adds more extension, then can have the notation "[[ ]]" for the new extension. We can also give the new extension a version. For example,

crypto ::=  {
  a INTEGER  (0..255),
  b BOOLEAN,
...,
[[2:  
   new definition
]],
...
}

which means version 2 of crypto schema.

If so, does the new schema need to be integrated with the decoder(m-mode FW)?

Yes, we should also update the decoder when we release a new schema.

[vlsunil]

Got it!. Thank you very much!