Hi ports@,

I know you are in lock at present and it's too late for 7.8 packages,
but I have made an update for sysutils/dmidecode (based on version 3.6)
that adds a new option to make it work on legacy-free UEFI systems,
plus several documentation and build improvements. A unified diff is
attached, created with cvs diff -uNp against the OPENBSD_7_7 branch.

Summary of changes

New -m option
On OpenBSD, dmidecode scans only /dev/mem in the Legacy BIOS area.
The -m option allows scanning of a 64kB range of /dev/mem starting from
a specified base address. This is useful on modern UEFI-only systems
where the SMBIOS entry point information is not present in the legacy
BIOS area 0xF0000– 0xFFFFF. The base address can be taken from the
dmesg, e.g.:

$ grep SMBIOS /var/run/dmesg.boot
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xa4df8000 (36 entries)

On some machines, specifying a slightly lower base address may be
necessary to find the _SM3_ pointer to the real entry point.

Other quality-of-life changes

- Updated dmidecode(8) to add previously-undocumented short options
found in the source. Added the new -m option.

- Added a pkg/README file with notes on usage on modern EFI systems.

- Compile-time warning fixes. Suppressed numerous pointer-alignment
warnings by adjusting types.h macros for WORD, DWORD, and QWORD. Added
#include <stdint.h> to source files where missing, to support this.

- made the -no-sysfs option the default on OpenBSD.

Rationale

On many newer amd64 machines, the kernel locates SMBIOS tables via EFI
and reports them in dmesg, but there is often no legacy BIOS entry point
in low memory, so dmidecode can't find an SMBIOS Entry Point. 
The -m option allows dmidecode to locate and parse those tables directly
via /dev/mem, without relying on EFI runtime variable or system-table
access. Behavior is unchanged when -m is not used.

Testing

Panasonic CF-SZ6 (OpenBSD 7.7-release/amd64) — no legacy SMBIOS pointer;
-m successfully decodes tables at EFI address.

Lenovo T470 (OpenBSD 7.8-beta/amd64) — same result as above.

Dell OptiPlex 3060 SFF (OpenBSD 7.7/amd64) — both vanilla dmidecode
(legacy F-segment) and -m 0xE0000 work correctly.

Verified normal output and no regressions when run without -m, tested
the missing short option-codes.

i386 testing would be welcome; I do not have compatible hardware
available.

Diff attached: dmidecode-m-option.diff

Comments, feedback?
OK to commit after unlock?
-- 
Chris Billington

• dmidecode-m-option.diff (13K)