Mailing List Archive: Conditional kernel selection based on CPUID/DMI info

Conditional kernel selection based on CPUID/DMI info

Jan 29, 2008, 9:34 AM

Post #1 of 12 (6607 views)

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 would be
fairly straight forward to create a custom com32 module to detect
whatever I want, but I don't see an easy way to translate that
information into the mechanism by which my kernel of choice is
selected. I've seen a patch that makes the 64bit/32bit distinction
and adds a special "default64" target. This is close, but breaks the
flexibility of the menu system and the user's ability to add
parameters to the command line or select from multiple configurations.

I see at least two possibilities here. One is to add variables and
conditionals to the configuration file parser (a scripting language
has been proposed), or parameter string substitution. The former
would be fairly complicated, and that is probably why it hasn't been
implemented. The latter has some history in a related DHCP patch that
went by a while ago, and is less intrusive (though less flexible).

What do people think of the following for a string substitution method?

DEFAULT linux

LABEL linux
KERNEL cpuselect.c32
APPEND ${LM?"x86_64":"i386"}/bzImage-${SMP?"smp":"up"}
initrd=${LM?"x86_64":"i386"}/initrd-${SMP?"smp":"up"} console=ttyS0

LABEL linux-single
KERNEL cpuselect.c32
APPEND ${LM?"x86_64":"i386"}/bzImage-${SMP?"smp":"up"}
initrd=${LM?"x86_64":"i386"}/initrd-${SMP?"smp":"up"} console=ttyS0
single

The parameters "LM" and "SMP" are Boolean values that are set in the
cpuselect.c32 module, and select the replacement text ala the C-like
conditional statement. This is just one of many ways to do something
like this, and it would seem a lot simpler than a full fledged
scripting language (it's all kept inside a module).

Am I reinventing the wheel here, or inventing a square wheel? :)

Craig

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

hpa at zytor

Jan 29, 2008, 12:05 PM

Post #2 of 12 (6453 views)

Permalink

Craig Johnston wrote:
>
> What do people think of the following for a string substitution method?
>
> DEFAULT linux
>
> LABEL linux
> KERNEL cpuselect.c32
> APPEND ${LM?"x86_64":"i386"}/bzImage-${SMP?"smp":"up"}
> initrd=${LM?"x86_64":"i386"}/initrd-${SMP?"smp":"up"} console=ttyS0
>
> LABEL linux-single
> KERNEL cpuselect.c32
> APPEND ${LM?"x86_64":"i386"}/bzImage-${SMP?"smp":"up"}
> initrd=${LM?"x86_64":"i386"}/initrd-${SMP?"smp":"up"} console=ttyS0
> single
>
> The parameters "LM" and "SMP" are Boolean values that are set in the
> cpuselect.c32 module, and select the replacement text ala the C-like
> conditional statement. This is just one of many ways to do something
> like this, and it would seem a lot simpler than a full fledged
> scripting language (it's all kept inside a module).
>
> Am I reinventing the wheel here, or inventing a square wheel? :)
>

I think we can consider a pattern-substitution module to be the
beginning of a scripting language. We should probably have it collect
information from as many sources as possible (CPUID, ...)

On the other hand, a fullblown scripting language probably would be easy
enough -- it's not really any different than what you're doing above.
It's just a matter of having the time to do it...

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

jalifrangis at authenticlick

Jan 29, 2008, 12:49 PM

Post #3 of 12 (6467 views)

Permalink

I think that the best place for something like this would be in the C32
modules,

I could work up a spec for the language / keywords and place it on the
wiki for comment, might take me a few days.

This is exactly the type of leap that syslinux needs.

-----Original Message-----
From: syslinux-bounces@zytor.com [mailto:syslinux-bounces@zytor.com] On
Behalf Of H. Peter Anvin
Sent: Tuesday, January 29, 2008 12:06 PM
To: For discussion of SYSLINUX and tftp-hpa
Subject: Re: [syslinux] Conditional kernel selection based on CPUID/DMI
info

Craig Johnston wrote:
>
> What do people think of the following for a string substitution
method?
>
> DEFAULT linux
>
> LABEL linux
> KERNEL cpuselect.c32
> APPEND ${LM?"x86_64":"i386"}/bzImage-${SMP?"smp":"up"}
> initrd=${LM?"x86_64":"i386"}/initrd-${SMP?"smp":"up"} console=ttyS0
>
> LABEL linux-single
> KERNEL cpuselect.c32
> APPEND ${LM?"x86_64":"i386"}/bzImage-${SMP?"smp":"up"}
> initrd=${LM?"x86_64":"i386"}/initrd-${SMP?"smp":"up"} console=ttyS0
> single
>
> The parameters "LM" and "SMP" are Boolean values that are set in the
> cpuselect.c32 module, and select the replacement text ala the C-like
> conditional statement. This is just one of many ways to do something
> like this, and it would seem a lot simpler than a full fledged
> scripting language (it's all kept inside a module).
>
> Am I reinventing the wheel here, or inventing a square wheel? :)
>

I think we can consider a pattern-substitution module to be the
beginning of a scripting language. We should probably have it collect
information from as many sources as possible (CPUID, ...)

On the other hand, a fullblown scripting language probably would be easy

enough -- it's not really any different than what you're doing above.
It's just a matter of having the time to do it...

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

jhutz at cmu

Jan 29, 2008, 1:01 PM

Post #4 of 12 (6467 views)

Permalink

--On Tuesday, January 29, 2008 12:05:52 PM -0800 "H. Peter Anvin"
<hpa@zytor.com> wrote:

> Craig Johnston wrote:
>>
>> What do people think of the following for a string substitution method?
>>
>> DEFAULT linux
>>
>> LABEL linux
>> KERNEL cpuselect.c32
>> APPEND ${LM?"x86_64":"i386"}/bzImage-${SMP?"smp":"up"}
>> initrd=${LM?"x86_64":"i386"}/initrd-${SMP?"smp":"up"} console=ttyS0
>>
>> LABEL linux-single
>> KERNEL cpuselect.c32
>> APPEND ${LM?"x86_64":"i386"}/bzImage-${SMP?"smp":"up"}
>> initrd=${LM?"x86_64":"i386"}/initrd-${SMP?"smp":"up"} console=ttyS0
>> single
>>
>> The parameters "LM" and "SMP" are Boolean values that are set in the
>> cpuselect.c32 module, and select the replacement text ala the C-like
>> conditional statement. This is just one of many ways to do something
>> like this, and it would seem a lot simpler than a full fledged
>> scripting language (it's all kept inside a module).
>>
>> Am I reinventing the wheel here, or inventing a square wheel? :)
>>
>
> I think we can consider a pattern-substitution module to be the
> beginning of a scripting language. We should probably have it collect
> information from as many sources as possible (CPUID, ...)
>
> On the other hand, a fullblown scripting language probably would be easy
> enough -- it's not really any different than what you're doing above.
> It's just a matter of having the time to do it...

I've been meaning to send in a couple of things I wrote in the last few
weeks which might be relevant.

The first is lmcheck.asm, which is another variation on the usual 32/64
check. This one runs one of two labels (currently 'linux32' or 'linux64')
depending on whether we detect a 64-bit CPU, and passes along whatever
arguments were given to it. We use it with configuration like this:

label linux
kernel lmcheck.cbt
label linux32
kernel vmlinuz.32
append initrd=initrd32.img ks=nfs:server:/path
label linux64
kernel vmlinuz.64
append initrd=initrd64.img ks=nfs:server:/path

The second is bioschk.asm, which started out as a way to check for a
particularly annoying BIOS (Dell Optiplex GX620 version A11, on which USB
keyboard emulation breaks apparently on entering 32-bit protected mode).
I decided early that it should be configurable, and ended up writing a
scripting language complete with branching, limited user input, and the
ability to boot things. I've attached just the source, but there's also a
test suite.

-- Jeff

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

hpa at zytor

Jan 29, 2008, 1:47 PM

Post #5 of 12 (6469 views)

Permalink

Jacob Alifrangis wrote:
> I think that the best place for something like this would be in the C32
> modules,
>
> I could work up a spec for the language / keywords and place it on the
> wiki for comment, might take me a few days.
>
> This is exactly the type of leap that syslinux needs.

That would be awesome :)

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

hpa at zytor

Jan 29, 2008, 1:47 PM

Post #6 of 12 (6463 views)

Permalink

Jeffrey Hutzelman wrote:
>
> The second is bioschk.asm, which started out as a way to check for a
> particularly annoying BIOS (Dell Optiplex GX620 version A11, on which
> USB keyboard emulation breaks apparently on entering 32-bit protected
> mode).
> I decided early that it should be configurable, and ended up writing a
> scripting language complete with branching, limited user input, and the
> ability to boot things. I've attached just the source, but there's also
> a test suite.
>

I would be a lot happier putting this in C code (as a COM32 module),
though. I'm trying to reduce the size of the assembly core rather than
have it grow. I'd like to actually get rid of most of it over time.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

jhutz at cmu

Jan 29, 2008, 2:24 PM

Post #7 of 12 (6454 views)

Permalink

--On Tuesday, January 29, 2008 01:47:47 PM -0800 "H. Peter Anvin"
<hpa@zytor.com> wrote:

> Jeffrey Hutzelman wrote:
>>
>> The second is bioschk.asm, which started out as a way to check for a
>> particularly annoying BIOS (Dell Optiplex GX620 version A11, on which
>> USB keyboard emulation breaks apparently on entering 32-bit protected
>> mode).
>> I decided early that it should be configurable, and ended up writing a
>> scripting language complete with branching, limited user input, and the
>> ability to boot things. I've attached just the source, but there's also
>> a test suite.
>>
>
> I would be a lot happier putting this in C code (as a COM32 module),
> though. I'm trying to reduce the size of the assembly core rather than
> have it grow. I'd like to actually get rid of most of it over time.

So far, I've avoided any com32 modules. Previous comboot modules I've done
have been farily trivial and com32 seemed more effort than it was worth.
That's clearly not the case here, and doing it in C would be quite a bit
more maintainable, but it wouldn't have met my need -- the original purpose
of the bioschk module was to detect a buggy BIOS that made user interaction
from a com32 module impossible. What actually happened was that I deployed
new menus using menu.c32 instead of PXE's built-in menu capability, and our
staff started complaining that they could no longer select anything from
the menu!

The bug is not in SYSLINUX, BTW. I'm pretty sure it's been discussed here
before, and Dell has acknowledged it. Unfortunately, that was over a year
ago, and the platform in question is officially EOL, so there's not much
hope of a fix from them. Their own BIOS updater run under MEMDISK has the
same problem; I had to put together a version that would boot and do the
update without asking for confirmation.

-- Jeff

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

hpa at zytor

Jan 29, 2008, 2:54 PM

Post #8 of 12 (6463 views)

Permalink

Jeffrey Hutzelman wrote:
>
> So far, I've avoided any com32 modules. Previous comboot modules I've done
> have been farily trivial and com32 seemed more effort than it was worth.
> That's clearly not the case here, and doing it in C would be quite a bit
> more maintainable, but it wouldn't have met my need -- the original purpose
> of the bioschk module was to detect a buggy BIOS that made user interaction
> from a com32 module impossible. What actually happened was that I deployed
> new menus using menu.c32 instead of PXE's built-in menu capability, and our
> staff started complaining that they could no longer select anything from
> the menu!
>
> The bug is not in SYSLINUX, BTW. I'm pretty sure it's been discussed here
> before, and Dell has acknowledged it. Unfortunately, that was over a year
> ago, and the platform in question is officially EOL, so there's not much
> hope of a fix from them. Their own BIOS updater run under MEMDISK has the
> same problem; I had to put together a version that would boot and do the
> update without asking for confirmation.
>

I recently fixed an interaction between Dell BIOSes and SYSLINUX (it was
a syslinux bug which only bit when COM32 modules where invoked.) The
only other Dell bug that I know about off the top of my head only bit
with isolinux.

I looked for the discussion you described, couldn't find it offhand. I
found a problem with OptiPlex GX620, said to be fixed in BIOS version
A12 (the bug was present only in version A11, supposedly), is this the one?

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

jhutz at cmu

Jan 29, 2008, 5:37 PM

Post #9 of 12 (6465 views)

Permalink

--On Tuesday, January 29, 2008 02:54:53 PM -0800 "H. Peter Anvin"
<hpa@zytor.com> wrote:

> Jeffrey Hutzelman wrote:
>>
>> So far, I've avoided any com32 modules. Previous comboot modules I've
>> done have been farily trivial and com32 seemed more effort than it was
>> worth. That's clearly not the case here, and doing it in C would be
>> quite a bit more maintainable, but it wouldn't have met my need -- the
>> original purpose of the bioschk module was to detect a buggy BIOS that
>> made user interaction from a com32 module impossible. What actually
>> happened was that I deployed new menus using menu.c32 instead of PXE's
>> built-in menu capability, and our staff started complaining that they
>> could no longer select anything from the menu!
>>
>> The bug is not in SYSLINUX, BTW. I'm pretty sure it's been discussed
>> here before, and Dell has acknowledged it. Unfortunately, that was
>> over a year ago, and the platform in question is officially EOL, so
>> there's not much hope of a fix from them. Their own BIOS updater run
>> under MEMDISK has the same problem; I had to put together a version
>> that would boot and do the update without asking for confirmation.
>>
>
> I recently fixed an interaction between Dell BIOSes and SYSLINUX (it was
> a syslinux bug which only bit when COM32 modules where invoked.) The
> only other Dell bug that I know about off the top of my head only bit
> with isolinux.
>
> I looked for the discussion you described, couldn't find it offhand. I
> found a problem with OptiPlex GX620, said to be fixed in BIOS version
> A12 (the bug was present only in version A11, supposedly), is this the
> one?

Yes, that's the one. Note that while the issue was introduced in A11 and
Dell said the issue _would be_ fixed in A12, no such version was ever
released. We're a little behind, but not much -- the problem occurs with
3.53, and as I mentioned, also with the memdisk in that version. At some
point I'll try something newer, but that requires forward-porting a patch I
have yet to send you, and I haven't found the time to look at it.

-- Jeff

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

hpa at zytor

Jan 29, 2008, 6:30 PM

Post #10 of 12 (6447 views)

Permalink

Jeffrey Hutzelman wrote:
>
> Yes, that's the one. Note that while the issue was introduced in A11 and
> Dell said the issue _would be_ fixed in A12, no such version was ever
> released. We're a little behind, but not much -- the problem occurs with
> 3.53, and as I mentioned, also with the memdisk in that version. At some
> point I'll try something newer, but that requires forward-porting a patch I
> have yet to send you, and I haven't found the time to look at it.
>

The implication was, though, that downgrading to A10 should work as
well. Don't know what other issues that would introduce, though.

It would be nice to figure out a workaround, but it's almost impossible
without access to a specimen.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

jhutz at cmu

Jan 29, 2008, 6:48 PM

Post #11 of 12 (6456 views)

Permalink

--On Tuesday, January 29, 2008 06:30:52 PM -0800 "H. Peter Anvin"
<hpa@zytor.com> wrote:

> Jeffrey Hutzelman wrote:
>>
>> Yes, that's the one. Note that while the issue was introduced in A11
>> and Dell said the issue _would be_ fixed in A12, no such version was
>> ever released. We're a little behind, but not much -- the problem
>> occurs with 3.53, and as I mentioned, also with the memdisk in that
>> version. At some point I'll try something newer, but that requires
>> forward-porting a patch I have yet to send you, and I haven't found the
>> time to look at it.
>>
>
> The implication was, though, that downgrading to A10 should work as
> well. Don't know what other issues that would introduce, though.

Right, and that's exactly what we do -- the script I feed to bioschk.cbt
checks for this particular BIOS, and if you have it, offers to boot a BIOS
updater that will downgrade you to A10. Otherwise it runs menu.c32 as
usual.

> It would be nice to figure out a workaround, but it's almost impossible
> without access to a specimen.

I agree. I have such a box I can use for testing, but no easy way to
provide remote access to its console. And while I can spend some of my own
time on the issue, I doubt my employer will be interested in shipping you
the box. :-)

-- Jeff

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Re: Conditional kernel selection based on CPUID/DMI info [ In reply to ]

sbrown7 at umbc

Jan 30, 2008, 6:32 AM

Post #12 of 12 (6469 views)

Permalink

On Tue, 29 Jan 2008, Jeffrey Hutzelman wrote:

>> I looked for the discussion you described, couldn't find it offhand. I
>> found a problem with OptiPlex GX620, said to be fixed in BIOS version
>> A12 (the bug was present only in version A11, supposedly), is this the
>> one?
>
> Yes, that's the one. Note that while the issue was introduced in A11 and
> Dell said the issue _would be_ fixed in A12, no such version was ever
> released. We're a little behind, but not much -- the problem occurs with
> 3.53, and as I mentioned, also with the memdisk in that version. At some
> point I'll try something newer, but that requires forward-porting a patch I
> have yet to send you, and I haven't found the time to look at it.

What we ended up doing here on some Dells that had broken BIOSes was just
back-revving them. It may have been the 620s, but I really don't
remember. Older versions are available on the Dell site... somewhere.
You may need to get the location from your salesrep -- a good tweak might
be a statement like "Those Intel Macs sure look good..."

Steve Brown
sbrown7@umbc.edu

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Mailing List Archive

Mailing List Archive

Attached Files: