hwreport: describe a machine onto a USB stick, from a Linux-style /sys

hwreport writes one folder to the first read-write FAT mount, or mounts
the first USB stick that takes vfat itself and unmounts it afterwards:
summary.txt (machine, firmware, CPU, memory, every PCI and USB device
with its driver or "-- no driver"), dmesg.txt, lspci.txt in the shape of
lspci -nnk -xxx, lsusb.txt, dmi.txt, memmap.txt, the ACPI tables as raw
.dat files iasl -d reads, and copies of /proc. Serials, the UUID and the
MSDM/SLIC tables (a Windows licence key) are left out.

It reads /sys, which is new: sysfs at Linux's paths and in Linux's
formats -- /sys/bus/pci/devices with uevent, config and resource,
/sys/bus/usb/devices, /sys/firmware/acpi/tables, dmi/tables, memmap
and efi, /sys/class/dmi/id. toybox's lspci and lsusb work unmodified
against it. The USB core now keeps a table of attached devices for it.

The machine's name comes from SMBIOS (kernel/dev/dmi.c). The UEFI loader
hands over the entry point from the configuration table, the kernel
falls back to the 0xF0000 scan, and the log gets Linux's "DMI:" line.

Two bugs found on the way:

- The loader handed over at most 40 memory-map entries, in firmware
  order. A laptop's UEFI map is 60-150 descriptors with RAM above 4 GB
  listed last, so that is what was dropped. The entries now have their
  own area at 0x31000 with room for 256, are sorted before merging, and
  the kernel's 32 usable regions keep the largest when there are more.
- MemTotal and sysinfo's totalram were PHYSTOP, an address, which counts
  the PCI hole: a 6 GB machine reported 8. Now the usable RAM, summed.

usb.ids moves to /usr/share/hwdata, where lsusb looks for it, and
pci.ids joins it (`make pci-ids`, BSD-3-Clause like usb.ids).

Checked under QEMU q35: the report written to a FAT32 stick, fsck.fat
clean, DSDT.dat disassembled by iasl on the host, lspci -k and lsusb
showing names, 6 GB of RAM seen as 6137 MB.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4

include/schboot.h

@@ -85,16 +85,18 @@
 #define SCHBOOT_MEDIA_SEG     0x3000
 #define SCHBOOT_MEDIA_OFF     0x101
 
-// The E820 memory map: a uint32 count, then that many 24-byte entries. Capped
-// at 32 so a pathological firmware cannot run past the buffer; the map ends at
-// 0x508, which is what leaves 0x600 free below.
+// The E820 memory map: a uint32 count at BASE+0x200, and the entries, 24 bytes
+// each, in a page-and-a-half of their own from BASE+0x1000.
+//
+// The entries used to sit between the count and the RSDP field, which left
+// room for 40. A laptop's UEFI map is 60 to 150 descriptors, and even after
+// the loader merges neighbours of the same type the RAM above 4 GB -- which
+// the firmware lists last -- was what fell off the end: a 16 GB machine came
+// up with 2 or 3 of it. 256 is more than any map seen merges to, and the area
+// it takes, 0x31000-0x32800, is clear of everything else at BASE.
 #define SCHBOOT_E820_COUNT    (SCHBOOT_BASE + 0x200)
-#define SCHBOOT_E820_MAP      (SCHBOOT_BASE + 0x208)
-/* 40, not 32. The map lives at SCHBOOT_E820_MAP (BASE+0x208) and the next
- * field is SCHBOOT_RSDP_ADDR at BASE+0x600, so there are 1016 bytes and each
- * entry is 24 -- 42 fit. Real UEFI firmware produces far more descriptors than
- * QEMU's, and the headroom costs nothing that was being used. */
-#define SCHBOOT_E820_MAX      40
+#define SCHBOOT_E820_MAP      (SCHBOOT_BASE + 0x1000)
+#define SCHBOOT_E820_MAX      256
 
 // Where the loader leaves the ACPI RSDP, as a little-endian 64-bit physical
 // address. Zero means "not provided, go and look for it yourself".
@@ -164,6 +166,17 @@
 // BGRX in memory, so format 0 is the one that needs its channels swapped.
 #define SCHBOOT_FB_FORMAT     (SCHBOOT_BASE + 0x634)   /* uint32           */
 
+// The SMBIOS entry point, from the UEFI configuration table: the 64-bit
+// "_SM3_" one when the firmware has it, else the 32-bit "_SM_". Zero means
+// none was handed over, and the kernel scans 0xF0000-0xFFFFF the BIOS way.
+// It is what names the machine -- vendor, model, firmware version -- in
+// /sys/class/dmi/id, and on UEFI the scan alone finds nothing on most laptops.
+#define SCHBOOT_SMBIOS_ADDR   (SCHBOOT_BASE + 0x638)   /* uint64, physical */
+// SCHBOOT_EFI_MAGIC when the UEFI loader booted this kernel, which is what
+// /sys/firmware/efi existing means on Linux.
+#define SCHBOOT_EFI_FLAG      (SCHBOOT_BASE + 0x640)   /* uint32           */
+#define SCHBOOT_EFI_MAGIC     0x21494645u              /* "EFI!"           */
+
 #ifndef __ASSEMBLER__
 
 struct sch64_header {