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
This commit is contained in:
parent
edc4e0537d
commit
eab13241a0
25 changed files with 2520 additions and 65 deletions
|
|
@ -52,8 +52,11 @@ and `entry.S` so the two cannot disagree.
|
|||
| `+0x000` | VBE-shaped mode info: LFB address, stride, width, height, depth |
|
||||
| `+0x100` | Verbose-boot flag |
|
||||
| `+0x101` | Boot medium (`1` = CD; `0` = not stated) |
|
||||
| `+0x200` | E820 entry count, then up to 40 × 24-byte entries |
|
||||
| `+0x200` | E820 entry count |
|
||||
| `+0x600` | ACPI RSDP physical address, or 0 |
|
||||
| `+0x638` | SMBIOS entry point physical address, or 0 |
|
||||
| `+0x640` | `"EFI!"` when the UEFI loader booted the kernel |
|
||||
| `+0x1000` | the E820 entries, up to 256 × 24 bytes |
|
||||
|
||||
Two of these exist because of specific failures worth knowing about.
|
||||
|
||||
|
|
@ -65,8 +68,14 @@ interrupt routing — and the machine boots to a prompt on polled serial output
|
|||
and then ignores every keystroke, which looks like a broken console rather than
|
||||
a missing table.
|
||||
|
||||
**The E820 cap is 40 entries, not 32.** Real UEFI firmware produces far more
|
||||
descriptors than QEMU's, and the space was already there.
|
||||
**The E820 entries have an area of their own**, room for 256. They used to sit
|
||||
between the count and the RSDP, which held 40, and a laptop's UEFI map is 60 to
|
||||
150 descriptors. The firmware lists RAM above 4 GB last, so that was what fell
|
||||
off: a 16 GB machine came up with 2 or 3 GB of it.
|
||||
|
||||
**The SMBIOS entry point is passed the same way as the RSDP**, from the
|
||||
configuration table, preferring the 64-bit `_SM3_` one. It names the machine in
|
||||
the boot log's `DMI:` line and in `/sys/class/dmi/id`.
|
||||
|
||||
### Choosing a display, on a machine that has more than one
|
||||
|
||||
|
|
@ -174,13 +183,14 @@ schos: memory map larger than the loader's buffer (status 0x8000000000000005)
|
|||
QEMU's own map needs 5664 bytes — 118 descriptors — so the real number on
|
||||
hardware is larger still, and 256 KB is 5461 descriptors.)
|
||||
|
||||
**A second limit is nearby and is only a warning.** `SCHBOOT_E820_MAX` is 40
|
||||
entries, fixed by the hand-off block's layout. `build_e820()` merges adjacent
|
||||
regions of the same type, so 40 survives a long map — but if it ever truncates,
|
||||
what gets dropped is the *high* end (the map arrives sorted, and `phystop` is
|
||||
capped below 4 GB regardless). It now says so on screen as well as on the
|
||||
serial line, because by that point `print()` goes to a port a laptop does not
|
||||
have.
|
||||
**A second limit is nearby and is only a warning.** `SCHBOOT_E820_MAX` is 256
|
||||
entries. `build_e820()` sorts the descriptors by address first (the
|
||||
specification does not promise an ordered map) and then merges neighbours of
|
||||
the same type, so a long map fits easily. If one ever truncates, it says so on
|
||||
screen as well as on the serial line, because by that point `print()` goes to a
|
||||
port a laptop does not have. The kernel keeps at most 32 usable regions; past
|
||||
that, the smallest give way to larger ones, so what is lost is crumbs rather
|
||||
than whatever was listed last.
|
||||
|
||||
### Two signals for a machine that cannot speak
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue