similar to: First attempt to use DMI in a com32 module

From: Hung-chi Lihn <hlihn at google.com> In the current Lua.c32 DMI implementation, it is a flat table with dotted names in table entries. It also misses a number DMI sub-tables. This patch, cleans up the DMI table structure using Lua's nested table structure and adds all missing DMI sub-tables. If a DMI sub-table is not supported by the hardware (not filled), then the corresponding

The code was passing sizeof(char *) - not the length of the buffer - to strlcpy and snprintf. Change the function to take the length of the buffer as a parameter. Fixes the warning: argument to 'sizeof' in 'snprintf' call is the same expression as the destination; did you mean to provide an explicit length? Signed-off-by: Jonathan Boeing <jonathan.n.boeing at gmail.com>

On sebastian's request, I'm sending this patch. From : Sebastian Herbszt <herbszt at gmx.de> DMI code have some wrong offsets. This patch fixes this offsets and improve the grammar. Signed-off-by:Sebastian Herbszt <herbszt at gmx.de> -------------------------------------------------------------------------------- Les opinions et prises de position emises par le signataire

Hi again, this is the second part of the patch extending lua. This time it adds the dmi functions (com32/modules/dmi*) to lua: dmi.supported(): returns true if DMI is supported dmi.gettable(): returns array of key, value pairs containing system info Sorry, but this patch does not apply cleanly if [PATCH 1/2] was applied before. There's just one line to fix in com32/lua/src/linit.c

From : Erwan Velu <erwan.velu at free.fr> This patch add a new com32 module named dmi. It can parse DMI Hanldes number 0,1,2,3,4. Using a very simple API, you can read the values of the following "Handles" - BIOS - CHASSIS - SYSTEM - BASE_BOARD - PROCESSOR It's possible and easy to extend to many other Handles. A sample code program called dmitest shows how you can use and

From : Erwan Velu <erwan.velu at free.fr> This patch add the ability to read the long-mode flag from the processor. This helps you to know if the processor is x86_64 capable or not. So "dmi->processor.cpu_flags.lm " is a boolean that represent the "Long Mode" cpu flag. It also add two bugfix : - some cpu flags were shifted due to some "null" messages in

The speed value is available since version 2.3 of the SMBIOS specification. Set the default speed string to "Unknown" for older versions. - Sebastian Index: syslinux-3.74-20-g3b80c26/com32/gpllib/dmi/dmi.c =================================================================== --- syslinux-3.74-20-g3b80c26.orig/com32/gpllib/dmi/dmi.c +++ syslinux-3.74-20-g3b80c26/com32/gpllib/dmi/dmi.c @@

While playing with a recent machine I found that HDT was reporting "OUT OF SPEC" on a few items on a very new machine. Fumbling around, I found that it came from com32/gpllib/dmi/. I'm seeing two possible improvements: 1) When HDT sees that it's out of spec, report out of spec and when appropriate, the raw data. For example, for DMI 17 (Memory Module), Type 18h (DDR3), report

While playing with a recent machine I found that HDT was reporting "OUT OF SPEC" on a few items on a very new machine. Fumbling around, I found that it came from com32/gpllib/dmi/. I'm seeing two possible improvements: 1) When HDT sees that it's out of spec, report out of spec and when appropriate, the raw data. For example, for DMI 17 (Memory Module), Type 18h (DDR3), report

Hi, we use PXELINUX in our product to show a boot menu on client computers, with options like "Boot from local hard disk", "Install Windows", etc. Unfortunately, a lot of computers seem to have broken BIOSes and won't boot with the LOCALBOOT command, and need to be booted with chain.c32 instead. We also have encountered some computers where it works only the other way -

Bonjour Erwan Juste pour me remettre, on a gagn? ensemble la petite finale baby foot ? Grenoble chez HP, fin 2009 ;-) J'ai commenc? ? jouer avec le module LUA de syslinux et suis tomb? sur des plantages sur les fonctions DMI M?me probl?me avec le module dmitest, mais pas avec HDT Probl?me plus ou moins aleatoire selon les hardware (bug plus souvent constat? en VMware, mais pas sur mon

On Fri, Aug 14, 2015 at 4:41 AM, Erwan Velu via Syslinux <syslinux at zytor.com> wrote: > Hi folks, > > I've been off for a pretty long time and I'm trying to resume a little bit. > > While testing HDT I found some serious bugs in HDT's CLI mode but also took > the time to update the DMI detection tables. > > Please find my hw_update branch which is in

Le lundi 28 septembre 2020 19:04, Jim Fehlig <jfehlig@suse.com> a écrit : > On 9/28/20 5:21 AM, Mathieu Tarral wrote: > > > Hi, > > I'm facing an issue with libvirt and the LIBXL driver, failing when searching for DMI data in /sys. > > info : libvirt version: 5.0.0, package: 4+deb10u1 (Guido Günther agx@sigxcpu.org Thu, 05 Dec 2019 00:22:14 +0100) > > error

I'm running pxelinux configured to use the path /bios on the tftp server for all the comboot files. The problem is dmi,syslinux,vesa etc modules are not being loaded in lua. Syslinux.version() returns not found in global index as does dmi.supported() For k,v in pairs(package.loaded) do print (k,v) end; shows that these modules that are normally loaded by lua are not loading. I got an idea

Thanks for pointing this out. Applied in 3b3bc3675519e1530adab27480196eb3f1a458bc Note that I've been adding some code in that branch to support the tftp WRQ from libupload when running with lpxelinux. 2015-09-02 12:18 GMT+02:00 Gene Cumm <gene.cumm at gmail.com>: > On Fri, Aug 14, 2015 at 4:41 AM, Erwan Velu via Syslinux > <syslinux at zytor.com> wrote: > > Hi

Hi, I'm facing an issue with libvirt and the LIBXL driver, failing when searching for DMI data in /sys. info : libvirt version: 5.0.0, package: 4+deb10u1 (Guido Günther <agx@sigxcpu.org> Thu, 05 Dec 2019 00:22:14 +0100) error : udevGetDMIData:1719 : internal error: Failed to get udev device for syspath '/sys/devices/virtual/dmi/id' or '/sys/class/dmi/id' error :

Hi folks, I've been off for a pretty long time and I'm trying to resume a little bit. While testing HDT I found some serious bugs in HDT's CLI mode but also took the time to update the DMI detection tables. Please find my hw_update branch which is in sync with the current git tree. https://github.com/ErwanAliasr1/syslinux/commits/hw_update Erwan,

I'm network booting various systems via PXE using pxelinux, and I would like to select a specific kernel and kernel options based on the type of CPU and/or type of system (PAE, 64bit, vmx, etc.). I see that some of this capability is present (e.g. Erwan Velu's nice cpuid/dmi/pci code), but the infrastructure to make use of this information in the config file is missing. It looks like it

Hi all Is there any way to extract information (like what dmidecode provides) from within PXELINUX and, based on this information, selectively perform an action? What I'm trying to do is provide a method of flashing the BIOS of our HP Linux workstations but different workstations use different methods of updating the BIOSes. For example, the xw9300 uses 'rompaq' where the xw8400

While shuffling quite a few things around, this gets us closer to native, which clearly had a reason to do the DMI scan early. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-08/arch/i386/mm/ioremap-xen.c =================================================================== --- head-2007-02-08.orig/arch/i386/mm/ioremap-xen.c 2007-02-08 17:07:13.000000000 +0100 +++