similar to: Conditional kernel selection based on CPUID/DMI info

I've been using syslinux on my own Linux recovery CDs for almost a year now, and in that time I've found it useful to be able to automatically load a 64-bit-capable kernel if the CPU supports it. I'd like to share my efforts and submit this patch for syslinux-3.31. It adds a new config file keyword, 'default64', which overrides the default image if a 64-bit CPU is detected.

I stumbled across the following patch and wondered if it wouldn't be a good idea to have it included. http://foldingcd.svn.sourceforge.net/viewvc/*checkout*/foldingcd/trunk/folding_cd/patches/syslinux-3.51-64bit.patch?revision=5 It adds a default64 keyword and detection of a 64bit processor. It could be useful for mixed environments. The patch is against 3.51, but looks like it would port

Brief discussion thread - http://lkml.org/lkml/2010/6/29/355 Added VMware detection via cpuid.Mimic'd VMware's balloon driver's init-time check(cpuid followed by dmi-checks). Moved the existing logic into a simple function to achieve that. Tested virt-what.in(ran as a script) and virt-what-cpuid-helper within a Linux guest on ESX. Thanks. Signed-off-by: Chetan Loke <loke.c at

Brief discussion thread - http://lkml.org/lkml/2010/6/29/355 Added VMware detection via cpuid.Mimic'd VMware's balloon driver's init-time check(cpuid followed by dmi-checks). Moved the existing logic into a simple function to achieve that. Tested virt-what.in(ran as a script) and virt-what-cpuid-helper within a Linux guest on ESX. Thanks. Signed-off-by: Chetan Loke <loke.c at

Hi Peter/Erwan et al, With my incredibly limited understanding of all things com32, years ago, I managed to write a com32 module to tell PXE users their MAC address, machine make, model and whether they were on a 32 or 64 bit processor. Users found this very useful when trying to re-image the 8,000 odd boxes spread round the globe. This was hugely based on Erwan Velu's dmitest.c circa 3.20.

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

Hi, I have a particular situation that syslinux could access a i2c bus to get some data from specific device that my hardware has. Based on these data, syslinux should or not to boot. It's feasible to create some i2c infraestructure to syslinux access i2c bus? It could be used to something more than only my needs? I digged in gpxe code and it has code to provide some i2c functionality.

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 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 @@

This is a first attempt to make the DMI table accessible in a com32 module. This patch applies to the latest syslinux (3.20-pre11). It will add some headers in com32/include/dmi and three files in com32/modules/. dmi.c This is the core program that makes the dmi tables accessible. dmi_utils.c Just a small util file to display some more complicated messages dmitest.c The program

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 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

How will this fare? I am planning on putting an asterisk box for my brother in the Philippines but they only have dialup internet. I want them to be able to use a telephone set on a phonejack or linejack card and call me and vice versa via VOIP. My setup in the US is working already with a broadband cable connection. I am thinking that dialup may not work because of the bandwidth required

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 -

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

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

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,

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

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