I can certainly try with upstream, will report how it goes. The code is
Linux-centric with a nod to FreeBSD in places.

I tried for some time to read the entry point info through efi ioctls,
to try and avoid the need for a new option, but it seems there is very
little standardisation of efi table guids despite the SMBIOS spec
specifying them. My three test machines were all different.

If there was a read-only sysctl like 'hw.smbios' added on boot alongside
hw.model, hw.serialno (etc) that seem to come from EFI, that might be
easier to implement in the area of the efi-scanning code in dmidecode,
which is Linux/FreeBSD only as it stands. But that's beyond my skills
to implement. 
For FreeBSD, it reads a kernel hint [1]. 
Parsing our dmesg buffer seems a little fragile. Then that would avoid
having to enable kern.allowkmem and messing with /dev/mem, which is not
something I am greatly happy about.

Chris

[1] https://svnweb.freebsd.org/base?view=revision&revision=307326

On Sat, 11 Oct 2025 10:29:23 +0100
Stuart Henderson <stu@spacehopper.org> wrote:

> these changes are bigger than we'd usually like to make in porrts,
> even the simple ones like adding short flags to the summary will
> make it harder to updste. can you see about getting them included
> upstream (probably via their mailing list) instead?
> 
> if they're committed upstream then I don't mind pulling the patches
> across before they make a new release, because then we can just
> remove patches again when updating.
> 
> On 2025/10/11 15:19, Chris Billington wrote:
> > 
> > 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
> 
> 


-- 
Chris Billington <emulti@disroot.org>