On Thu, Feb 20, 2014 at 04:27:27PM +0100, Gerd Hoffmann wrote: > On Mi, 2014-02-19 at 15:40 -0500, Gabriel L. Somlo wrote: > > So I gave up on that relatively quickly, as there's no easy and > > convenient way to "harvest" a binary of just one table type from > > a host that works the way I want it... :( > > "dmidecode --type 2" ?
That doesn't work with --dump-bin, to get me something I could just load with "-smbios file=<foo>". On Wed, Feb 19, 2014 at 11:20:37PM +0100, Laszlo Ersek wrote: > If you want to export a new table whole-sale (SMBIOS_TABLE_ENTRY), > then > you don't have to modify SeaBIOS. However, in qemu: > - you either need to pass single-table blobs on the qemu command > line, or > - patch qemu so that it internally prepares the *complete* table for > the > boot firmware (meaning you must encode knowledge about formatted vs. > unformatted fields in qemu -- you must set up the unformatted area > and > the string indices yourself). (*) > > You have to encode the formatted vs. unformatted knowledge > *somewhere*. > You can push it around (qemu command line, qemu code, seabios code), > but > you have to encode it explicitly somewhere. > > (Writing the SMBIOS patches for OVMF (type0 and type1) took me three > days of *uninterrupted* misery ^W coding.) > > Preferably, (*) should be implemented, because then SeaBIOS and OVMF > can > both profit immediately. O:-) At this point, the question is "cut'n'paste from SeaBIOS" vs. rewrite the table generation routines from scratch in QEMU? I remember ACPI was mostly cut'n'pasted into QEMU, so would that be an OK starting point for SMBIOS as well ? I looked at licenses, and the SeaBIOS smbios.c file is gplv3, whereas the current smbios.c in QEMU is some combination of gplv2 and gplv2+. Any thoughts on whether that's a problem, legally speaking ? Thanks, --Gabriel
