| Age | Commit message (Collapse) | Author |
|---|
|
This commit implements SMBIOS Type 19 (Memory Array Mapped Address)
generation with a hybrid approach supporting both:
1. Explicit definition via Device Tree 'smbios' node:
Child node under '/smbios/smbios/memory-array-mapped-address' will be
used to populate as individual Type 19 structure directly.
- Properties follow SMBIOS field names with lowercase letters and
hyphen-separated words (e.g., 'starting-address', 'ending-address',
'partition-width', etc.).
- This method supports precise platform-defined overrides and system
descriptions.
2. Fallback to automatic DT-based discovery:
If child node under '/smbios/smbios/memory-array-mapped-address' does
not exist, the implementation will:
- Scan all top-level 'memory@' nodes to populate Type 19 structure with
inferred size and location data.
- Scan nodes named or marked as 'memory-controller' and parse
associated 'dimm@' subnodes (if present) to extract DIMM sizes and
map them accordingly.
This dual-mode support enables flexible firmware SMBIOS reporting while
aligning with spec-compliant naming and runtime-detected memory topology.
Type 19 support is under GENERATE_SMBIOS_TABLE_VERBOSE to avoid
increasing rom size for those platforms which only require basic SMBIOS
support.
Signed-off-by: Raymond Mao <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
This commit implements SMBIOS Type 17 (Memory Device) generation with a
hybrid approach supporting both:
1. Explicit definition via Device Tree 'smbios' node:
Child node under '/smbios/smbios/memory-device' will be used to
populate as individual Type 17 structure directly.
- Properties follow SMBIOS field names with lowercase letters and
hyphen-separated words (e.g., 'physical-memory-array-handle',
' memory-error-information-handle', 'configured-memory-speed', etc.).
- This method supports precise platform-defined overrides and system
descriptions.
2. Fallback to automatic DT-based discovery:
If child node under '/smbios/smbios/memory-device' does not exist,
the implementation will:
- Scan all top-level 'memory@' nodes to populate Type 17 structure with
inferred size and location data.
- Scan nodes named or marked as 'memory-controller' and parse
associated 'dimm@' subnodes (if present) to extract DIMM sizes and
map them accordingly.
This dual-mode support enables flexible firmware SMBIOS reporting while
aligning with spec-compliant naming and runtime-detected memory topology.
Type 17 support is under GENERATE_SMBIOS_TABLE_VERBOSE to avoid
increasing rom size for those platforms which only require basic SMBIOS
support.
Signed-off-by: Raymond Mao <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
This commit implements SMBIOS Type 16 (Physical Memory Array)
generation with a hybrid approach supporting both:
1. Explicit definition via Device Tree 'smbios' node:
Child node under '/smbios/smbios/memory-array' will be used to
populate as individual Type 16 structure directly.
- Properties follow SMBIOS field names with lowercase letters and
hyphen-separated words (e.g., 'memory-error-correction',
'maximum-capacity', 'extended-maximum-capacity', etc.).
- This method supports precise platform-defined overrides and system
descriptions.
2. Fallback to automatic DT-based discovery:
If child node under '/smbios/smbios/memory-array' does not exist,
the implementation will:
- Scan all top-level 'memory@' nodes to populate Type 16 structure with
inferred size and location data.
- Scan nodes named or marked as 'memory-controller' and parse
associated 'dimm@' subnodes (if present) to extract DIMM sizes and
map them accordingly.
This dual-mode support enables flexible firmware SMBIOS reporting while
aligning with spec-compliant naming and runtime-detected memory topology.
Type 16 support is under GENERATE_SMBIOS_TABLE_VERBOSE to avoid
increasing rom size for those platforms which only require basic SMBIOS
support.
Signed-off-by: Raymond Mao <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
This commit introduces support for generating SMBIOS Type 9 (System Slot)
tables using a hybrid approach:
1. Explicit Device Tree definitions:
Child node under '/smbios/smbios/system-slot' will be interpreted as
individual slot definitions.
- Each child represents a slot (e.g., isa, pcmcia, etc.).
- Properties follow the SMBIOS specification using lowercase
hyphen-separated names such as 'slot-type', 'slot-id',
'segment-group-number', 'bus-number', 'slot-information', etc.
- This approach allows full customization of each system slot and is
especially suitable for platforms with well-defined slot topology.
2. Automatic detection fallback:
If child node under '/smbios/smbios/system-slot' does not exist, the
implementation will scan the entire device tree for nodes whose
'device_type' matches known slot-related types ("pci", "isa", "pcmcia",
etc.).
- When a match is found, default values or heuristics are applied to
populate to the System Slot table.
- This mode is useful for platforms that lack explicit SMBIOS nodes
but still expose slot topology via standard DT conventions.
Together, two approaches ensure that SMBIOS Type 9 entries are available
whether explicitly described or automatically derived.
Signed-off-by: Raymond Mao <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
Some smbios types can have multiple instances (e.g. Type 7, 9, 16, 17,
19), thus the 'handle' argument should be a pointer so that the value
can be accumulated when writing all the instances.
This also fix the observed duplicated Type 7 handles.
Fixes: bcf456dd369e ("smbios: add detailed smbios information")
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
If there is no UCLASS_SYSINFO device available, parent_node will be
ofnode_null(). Calling ofnode_find_subnode() then triggers an assertion:
drivers/core/ofnode.c:598: ofnode_find_subnode: Assertion `ofnode_valid(node)' failed.
Check for a valid parent_node, not just that OF_CONTROL is enabled.
Fixes: 44ffb6f0ecaf ("smbios: Allow properties to come from the device tree")
Signed-off-by: Samuel Holland <[email protected]>
|
|
Allow for the sysinfo drivers to provide a system UUID to SMBIOS. Will
be first used by the IOT2050 boards.
Signed-off-by: Li Hua Qian <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Signed-off-by: Baocheng Su <[email protected]>
|
|
Raymond Mao <[email protected]> says:
Motivations for changes:
Current SMBIOS library and command-line tool is not fully matching with
the requirements:
1. Missing support for other mandatory types (#7, #9, #16, #17, #19).
2. Only a few platforms support SMBIOS node from the device tree.
3. Values of some fields are hardcoded in the library other than fetching
from the device hardware.
4. Embedded data with dynamic length is not supported (E.g. Contained
Object Handles in Type #2 and Contained Elements in Type #3)
Changes:
1. Refactor the SMBIOS library and command-line tool to better align with
the SMBIOS spec.
2. Create an arch-specific driver for all aarch64-based platforms to fetch
SMBIOS private data from the device hardware (processor and cache).
3. Create a sysinfo driver to poppulate platform SMBIOS private data.
4. Add generic SMBIOS DTS file for arm64 platforms for those common strings
and values which cannot be retrieved from the system registers.
Vendors can create their own SMBIOS node using this as an example.
For those boards without SMBIOS nodes, this DTS file can be included to
have a generic SMBIOS information of the system.
5. Add support for Type #7 (Cache Information) and link its handles to
Type #4.
6. To minimize size-growth for those platforms which have not sufficient
ROM spaces or the platforms which don't need detailed SMBIOS
information, new added fields are only being built when kconfig
GENERATE_SMBIOS_TABLE_VERBOSE is selected.
Once this patch is acceptted, subsequent patch sets will add other missing
types (#9, #16, #17, #19).
Tests:
To test this with QEMU arm64, please follow the guide on dt_qemu.rst to
get a merged DT to run with.
```
qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \
| dtc - -o merged.dtb
qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \
-dtb merged.dtb
```
Link: https://lore.kernel.org/r/[email protected]
|
|
Add detailed SMBIOS information as following:
1. Missing fields in Type #3 and #4
2. Type #7
Add support to dynamic length of contained object handles and
elements.
As SMBIOS is a fundamental feature which is enabled for all
boards, in order to avoid increasing rom size, all detailed SMBIOS
information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE.
Board maintainers can determine whether to select this feature.
Signed-off-by: Raymond Mao <[email protected]>
|
|
Current smbios library does not fully match to the specification.
It hardcodes values instead of exposing values from the device.
It does not reserve the space to support dynamic length for
contained object handles or elements and misses the handling of
a few of fields.
The refactoring of this patch includes:
1. Expose values from device via sysinfo interface.
2. Replace smbios_add_prop with smbios_add_prop_si to allow getting
string values from sysinfo.
3. Add smbios_get_val_si to get values from sysinfo or device tree.
4. Use sysinfo_get_data to get data area.
5. Reserve the space of contained object handles and elements.
6. Miscellaneous fixes in smbios.
Signed-off-by: Raymond Mao <[email protected]>
|
|
Move the smbios field definitions to a separated simple headfile,
which is a prerequisite to be included by dts files.
Add new definitions for cache information.
This patch also includes a few of code optimizations in smbios.
Signed-off-by: Raymond Mao <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
include display_options.h to address build warning:
lib/smbios.c: In function ‘smbios_update_version’:
lib/smbios.c:305:9: warning: implicit declaration of function ‘print_buffer’
[-Wimplicit-function-declaration]
print_buffer((ulong)ptr, ptr, 1, old_len + 1, 0);
^~~~~~~~~~~~
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
We are about to add a large number of new entries. Update the prefix to
be a little shorter.
For SMBIOS items, use SYSID_SM_ (for System Management) which is enough
to distinguish it. For now at least, it seems that most items will be
for SMBIOS.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Raymond Mao <[email protected]>
|
|
U-Boot claims to create SMBIOS 3.7 tables. The type 0 table has
a field Extended BIOS ROM Size since version 3.1.
BIOS ROM sizes of 16 MiB or above must be written to this field.
Add and fill the missing field.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Since write_smbios_table() returns an address, we cannot use it to
return and error number. Also, failing on sysinfo_detect() breaks
existing boards, e.g. chromebook_link
Correct this by logging and swallowing the error.
Signed-off-by: Simon Glass <[email protected]>
Fixes: a5a57562856 ("lib: smbios: Detect system properties via...")
|
|
Code is pretty much supports only DT properties and completely ignore
information coming from sysinfo driver.
Code is calling smbios_add_prop() which calls with
smbios_add_prop_si(SYSINFO_ID_NONE). But SYSINFO_ID_NONE can't
differentiate different entries from sysinfo driver.
That's why introduce separate SYSINFO macros which can be used in sysinfo
driver and passed to smbios structure.
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Currently code looks like that it sysinfo drivers are supported but
actually none checking that system is detected. That's why call
sysinfo_detect() to make sure that priv->detected in sysinfo uclass is
setup hence information from driver can be passed to smbios.
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
If SYSINFO support isn't enabled, it's a given that uclass_first_device
for UCLASS_SYSINFO will not find anything, therefore let's skip the test
entirely.
This allows to get rid of the following debug message that may be
confusing:
Cannot find uclass for id 118: please add the UCLASS_DRIVER() declaration for this UCLASS_... id
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
We should not use the reserved value 0x00 for the wake up type but
use 0x02 (Unknown).
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
In the SMBIOS 3 entry point the Structure Table Maximum Size field was
incorrectly named max_struct_size. A Maximum Structure Size field only
exists in the SMBIOS 2.1 entry point and has a different meaning.
Call the Structure Table Length field table_maximum_size.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Only the SMBIOS 2.1 entry point has a field for the maximum structure size.
As we have switched to an SMBIOS 3 entry point remove the superfluous
calculation.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The chassis handle field in the type 2 structure must point to the handle
of the type 3 structure.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
The SMBIOS specification describes: "If a string field references no string,
a null (0) is placed in that string field."
Accordingly we should avoid writing a string "Unknown" to the SMBIOS table.
dmidecode displays 'Not Specified' if the string number is 0.
Commit 00a871d34e2f ("smbios: empty strings in smbios_add_string()")
correctly identified that strings may not have length 0 as two
consecutive NULs indentify the end of the string list. But the suggested
solution did not match the intent of the SMBIOS specification.
Fixes: 00a871d34e2f ("smbios: empty strings in smbios_add_string()")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
When no string is present in a table, next_ptr points to the same
location as eos. When calculating the string table length, we would only
reserve one \0. By spec a SMBIOS table has to end with two \0\0 when no
strings a present.
Signed-off-by: Matthias Brugger <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Add description for parameter sysinfo_id of function get_str_from_dt().
Fixes: 07c9e683a484 ("smbios: Allow a few values to come from sysinfo")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
commit 738b34668f28 ("smbios: Fallback to the default DT if sysinfo nodes are missing")
allowed the code to fallback and fill in SMBIOS tables with properties
from the compatible and product nodes of the DT, in case the
'smbios,sysinfo' node is missing.
That works fine for Type1/2 tables, but for other types we need to
match the smbios,sysinfo subnode name as well. So add it to the
smbios_ctx and check it during the sysinfo <-> DT mathcing
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
sysinfo_str is a bit too long and makes indentation weird. Shorten it
to si_str.
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
A SMBIOS 3 entry point has a different length than an SMBIOS 2.1 entry
point.
Fixes: 70924294f375 ("smbios: Use SMBIOS 3.0 to support an address above 4GB")
Fixes: 1c5f6fa3883d ("smbios: Drop support for SMBIOS2 tables")
Addresses-Coverity-ID: 477212 ("Wrong sizeof argument")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Many value of processor type exceed 0xff and have to be stored as u16
value. In the type 4 table set processor_family = 0xfe signaling that
field processor_family2 is used and write the actual value into the
processor_family2 field.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
These tables are a pain since there is no way to handle memory above
4GB. Use SMBIOS3 always.
This should hopefully not create problems on x86 devices, since SMBIOS3
was released seven years ago (2015).
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
|
|
All callers handle this alignment, so drop the unnecessary code. This
simplifies things a little.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
When the SMBIOS table is written to an address above 4GB a 32-bit table
address is not large enough.
Use an SMBIOS3 table in that case.
Note that we cannot use efi_allocate_pages() since this function has
nothing to do with EFI. There is no equivalent function to allocate
memory below 4GB in U-Boot. One solution would be to create a separate
malloc() pool, or just always put the malloc() pool below 4GB.
- Use log_debug() for warning
- Rebase on Heinrich's smbios.h patch
- Set the checksum for SMBIOS3
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Move all of this logic into the else clause, since it will not be used
for SMBIOS3
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
In preparation for adding support for SMBIOS3 move this code into an
else statement. There is no functional change.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
In order to fill in the SMBIOS tables U-Boot currently relies on a
"u-boot,sysinfo-smbios" compatible node. This is fine for the boards
that already include such nodes. However with some recent EFI changes,
the majority of boards can boot up distros, which usually rely on
things like dmidecode etc for their reporting. For boards that
lack this special node the SMBIOS output looks like:
System Information
Manufacturer: Unknown
Product Name: Unknown
Version: Unknown
Serial Number: Unknown
UUID: Not Settable
Wake-up Type: Reserved
SKU Number: Unknown
Family: Unknown
This looks problematic since most of the info are "Unknown". The DT spec
specifies standard properties containing relevant information like
'model' and 'compatible' for which the suggested format is
<manufacturer,model>. Unfortunately the 'model' string found in DTs is
usually lacking the manufacturer so we can't use it for both
'Manufacturer' and 'Product Name' SMBIOS entries reliably.
So let's add a last resort to our current smbios parsing. If none of
the sysinfo properties are found, scan for those information in the
root node of the device tree. Use the 'model' to fill the 'Product
Name' and the first value of 'compatible' for the 'Manufacturer', since
that always contains one.
pre-patch:
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Unknown
Product Name: Unknown
Version: Unknown
Serial Number: 100000000bb24ceb
UUID: 30303031-3030-3030-3061-613234636435
Wake-up Type: Reserved
SKU Number: Unknown
Family: Unknown
[...]
and post patch:
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: raspberrypi
Product Name: Raspberry Pi 4 Model B Rev 1.1
Version: Unknown
Serial Number: 100000000bb24ceb
UUID: 30303031-3030-3030-3061-613234636435
Wake-up Type: Reserved
SKU Number: Unknown
Family: Unknown
[...]
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Tested-by: Peter Robinson <[email protected]>
|
|
If a value is not valid during the DT or SYSINFO parsing, we explicitly
set that to "Unknown Product" and "Unknown" for the product and
manufacturer respectively. It's cleaner if we move the checks insisde
smbios_add_prop_si() and provide an alternative string in case the
primary is NULL or empty
pre-patch dmidecode
<snip>
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Unknown
Product Name: Unknown Product
Version: Not Specified
Serial Number: Not Specified
UUID: Not Settable
Wake-up Type: Reserved
SKU Number: Not Specified
Family: Not Specified
[...]
post-patch dmidecode:
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Unknown
Product Name: Unknown
Version: Unknown
Serial Number: Unknown
UUID: Not Settable
Wake-up Type: Reserved
SKU Number: Unknown
Family: Unknown
[...]
While at it make smbios_add_prop_si() add a string directly if the prop
node is NULL and replace smbios_add_string() calls with
smbios_add_prop_si(ctx, NULL, ....)
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Tested-by: Peter Robinson <[email protected]>
|
|
SMBIOS tables only support 32bit addresses. If we don't have memory here
handle the error gracefully:
* on x86_64 fail to start U-Boot
* during UEFI booting ignore the missing table
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
BIOS Release Date must be in format mm/dd/yyyy and must be release date.
U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
generated from current build timestamp.
Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
better approximation of U-Boot release date than current build timestamp.
Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
Some operating systems are using BIOS Release Date for detecting when was
SMBIOS table filled or if it could support some feature (e.g. BIOS from
1990 cannot support features invented in 2000). So this change also ensures
that recompiling U-Boot from same sources but in different year does not
change behavior of some operating systems.
Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
so remove it from global autogenerated files and also from Makefile.
Signed-off-by: Pali Rohár <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Commit e4f8e543f1a9("smbios: Drop the unused Kconfig options")
break SMBIOS tables. The reason is that the patch drops the Kconfig
options *after* removing the code using them, but that changes the semantics
of the code completely. Prior to the change a non NULL value was used in
the 'product' and 'manufacturer ' fields.
Chapter 6.2 of the DMTF spec requires Manufacturer and Product Name to be
non-null on some of the tables. So let's add sane defaults for Type1/2/3.
* Before the patchset:
<snip>
Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
Manufacturer: Not Specified
Product Name: Not Specified
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Features:
Board is a hosting board
Location In Chassis: Not Specified
Chassis Handle: 0x0000
Type: Motherboard
Invalid entry length (0). DMI table is broken! Stop.
* After the patchset:
<snip>
Handle 0x0005, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Handle 0x0006, DMI type 127, 4 bytes
End Of Table
Fixes: e4f8e543f1a9 ("smbios: Drop the unused Kconfig options")
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
We currently define the EFI support of an SMBIOS table as the third bit of
"BIOS Characteristics Extension Byte 1". The latest DMTF spec defines it
on "BIOS Characteristics Extension Byte 2".
Signed-off-by: Ilias Apalodimas <[email protected]>
Remove superfluous assignment.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Use 'Return:' instead of '@return:'.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
When U-Boot is booted from coreboot the SMBIOS tables are written by
coreboot, not U-Boot. The existing method of updating the BIOS version
string does not work in that case, since gd->smbios_version is only set
when U-Boot writes the tables.
Add a new function which allows the version to be updated by parsing the
tables and writing the string in the correct place. Since coreboot
provides a pointer to the SMBIOS tables in its sysinfo structure, this
makes it easy to do the update.
Signed-off-by: Simon Glass <[email protected]>
|
|
While static configuration is useful it cannot cover every case. Sometimes
board revisions are encoded in resistor straps and must be read at
runtime.
The easiest way to provide this information is via sysinfo, since the
board can then provide a driver to read whatever is needed.
Add some standard sysinfo options for this, and use them to obtain the
required information.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
At present the version string is obtained from PLAIN_VERSION. Some boards
may want to configure this using the device tree, since the build system
can more easily insert things there after U-Boot itself is built. Add this
option to the code.
Also in some cases the version needs to be generated programmatically,
such as when it is stored elsewhere in the ROM and must be read first.
To handle this, keep a pointer around so that it can be updated later.
This works by storing the last string in the context, since it is easier
than passing out a little-used extra parameter.
Provide a function to update the version string.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Add a new member to the context struct which tracks the end of the string
table. This allows us to avoid recalculating this at the end.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
We can store this in the context and avoid passing it to each function.
This makes it easier to follow and will also allow keeping track of the
end of the string table (in future patches).
Add an 'eos' field to the context and create a function to set it up.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
At present we pass the ofnode to each function. We also pass the 'eos'
pointer for adding new strings. We don't track the current end of the
string table, so have smbios_string_table_len() to find that.
The code can be made more efficient if it keeps information in a
context struct. This also makes it easier to add more features.
As a first step, switch the ofnode parameter to be a context pointer.
Update smbios_add_prop() at the same time to avoid changing the same
lines of code in consecutive patches.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
We may as well include the U-Boot release information in the type-0 table
since it is designed for that purpose.
U-Boot uses release versions based on the year and month. The year cannot
fit in a byte, so drop the century.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
This type is not used outside the smbios.c file so there is no need for it
to be in the header file. Move it.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
