Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions dtschema/schemas/chosen.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -167,6 +167,12 @@ properties:
will assign devices in its usual manner, otherwise it will not try to
assign devices and instead use them as they are configured already.

smbios3-entrypoint:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about smbios3-start or -base? This the start of the tables and 'entry point' sounds more like you have jump to it. Do we care about the size of the tables? I suppose people can decode the header when they want to find out, but it is common to include both an address and a size for properties which refer to memory (e.g. 'reg').

I assume that v3 is the only valid version at present and v2 is not really used anymore.

In a devicetree environment it would be better to include the information from the SMBIOS tables in a full devicetree schema, but that's a problem for another year :-)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about smbios3-start or -base? This the start of the tables and 'entry point' sounds more like you have jump to it.

It is not the start of the tables. It is the address of a separate structure in memory that contains the version information and the actual address of the tables, and those could be somewhere else in memory entirely (for x86 legacy reasons). This structure is what the DMTF SMBIOS spec calls entrypoint and so I don't think we should be inventing our own terminology here.

Note that there is existing tooling such as dmidecode that expects to be able to access the entrypoint structure directly, and so omitting things or re-inventing them is going to be problematic for compatibility.

Do we care about the size of the tables? I suppose people can decode the header when they want to find out, but it is common to include both an address and a size for properties which refer to memory (e.g. 'reg').

The entrypoint structure has a fixed size.

I assume that v3 is the only valid version at present and v2 is not really used anymore.

There is no v2. It is called SMBIOS3 because SMBIOS 3.x was the first version to describe a variant of the entrypoint that can accommodate a 64-bit address for the table array.

In a devicetree environment it would be better to include the information from the SMBIOS tables in a full devicetree schema, but that's a problem for another year :-)

I don't see how that would be useful. There is already spec outside of DT that describes all of this - what would be the added value of duplicating this elsewhere?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I understand this is a header and the tables could be elsewhere. So what are the semantics of that? Should we require that the tables be immediately after this 'entry header'? If the tables are elsewhere, does that mean we have a reserved-memory section?

Re the SMBIOS spec, having written a generator and parsers for it, it is pretty a pretty ugly and old-fashioned format which could be implemented nicely in devicetree.

$ref: types.yaml#/definitions/address
maxItems: 1
description:
The physical address of the SMBIOSv3 entry point structure.

stdout-path:
$ref: types.yaml#/definitions/string
pattern: '^[a-zA-Z0-9@/,+\-._]*(:[0-9]*[noe]?[78]?[r]?)?$'
Expand Down