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 <raymondmaoca@gmail.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Add a new field SYSID_BOARD_RAM_SIZE_MB to sysinfo structure to store
the size of RAM in MB. dram_init can use this field to get the RAM size
via sysinfo driver.

Signed-off-by: Baocheng Su <baocheng.su@siemens.com>

This commit introduces a new API to the sysinfo module, allowing access
to data elements. This is particularly useful for handling data with
multiple instances, such as MAC addresses.

Signed-off-by: Baocheng Su <baocheng.su@siemens.com>

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 <huaqian.li@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Baocheng Su <baocheng.su@siemens.com>

Add sysinfo driver to retrieve smbios information (Type 4 and 7).
So that the smbios library can use it for getting values from the
hardware platform instead of device tree.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>

Add interface for sysinfo to access a data area from the platform.
This is useful to save/read a memory region of platform-specific
data.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>

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 <sjg@chromium.org>
Acked-by: Raymond Mao <raymond.mao@linaro.org>

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 <michal.simek@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

These headers follow the pattern:

| #if CONFIG_IS_ENABLED(FANCY_FEATURE)
|   void foo(void);
| #else
|   static inline void foo(void) { return -ENOSYS; }
| #endif

In the #else path ENOSYS is used, however linux/errno.h is not included.
If errno.h has not been included already the compiler errors out even
if the inline function is not referenced.

Make those headers self contained.

Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

At present only the model name is shown on start. Some boards want to
display more information. Add some more options to allow display of the
manufacturer as well as the version and date of any prior-stage
firmware.

This is useful for coreboot, at least. If other boards have more
information to display, it is easy to add it, now.

Signed-off-by: Simon Glass <sjg@chromium.org>