[PATCH] SMBIOS scan for loader (Was: Re: R3000Z Laptop Status)

[Jung-uk Kim]

On Monday 21 March 2005 02:40 pm, John Baldwin wrote:
> On Monday 21 March 2005 02:11 pm, Jung-uk Kim wrote:
> > On Monday 21 March 2005 01:28 pm, Scott Long wrote:
> > > Astrodog wrote:
> > > >>>>>>>I was wondering if the R3000Z fixes have been committed
> > > >>>>>>> to the RELENG_5 branch, I don't see anything on the
> > > >>>>>>> lists about it. Should I expect 5.4 to work with the
> > > >>>>>>> R3000 line?
> > > >>>>>>
> > > >>>>>>Yes.  hint.atkbd.0.flags="0x9" is all you need now.  Try
> > > >>>>>> the latest snapshot and let us know.
> > > >>>>>>
> > > >>>>>>Thanks,
> > > >>>>>>
> > > >>>>>>Jung-uk Kim
> > > >>>>>
> > > >>>>>Is there any way that these systems can be detected at
> > > >>>>> runtime and have the work-arounds be automatically
> > > >>>>> activated?
> > > >>>>
> > > >>>>I believe DMI-based quirk table is the only way but we
> > > >>>> don't want to do that, right?
> > > >>>>
> > > >>>>Jung-uk Kim
> > > >>>>
> > > >>>>>Scott
> > > >>>
> > > >>>Well, it's gross, but it's not impossible to do.  Is there a
> > > >>>technical reason why we wouldn't want this?
> > > >>
> > > >>The only technical reason that I can think of is some systems
> > > >> (e. g., IBM e345 and e346 Opteron servers) have DMI
> > > >> structures in ACPI NVS area, which is not accessible from
> > > >> early stage.  If you want to do something like that, you
> > > >> will have to add gross hack in pmap.c to temporarily map it,
> > > >> I think.
> > > >>
> > > >>>Are there any alternatives, like detecting a signature in
> > > >>> ACPI, either a text string or a certain bit of ASL
> > > >>> bytecode?
> > > >>
> > > >>We already have the quirk for this broken BIOS.  However,
> > > >> keyboard probing happens way earlier to use this quirk. :-(
> > > >>
> > > >>Jung-uk Kim
> > > >>
> > > >>>Scott
> > > >
> > > > Something that came up originally, when this issue was first
> > > > noticed, was trying to figure out what, if any platforms,
> > > > would have problems if this was made to apply to all AMD64
> > > > machines, and use the flag to drive an opt-out. In as far as
> > > > I'm aware, no AMD64-based machines are effected if you just
> > > > "break" the keyboard test functionality, though I'm not
> > > > certain this is a path worth looking at, since its still a
> > > > bit ugly.
> > >
> > > My number 1 concern is that 5.4-RELEASE 'Just Works' when you
> > > load it onto a machine.  Undocumented and under-documented
> > > work-arounds are very hard to manage and don't help users that
> > > aren't intimately familiar with the problem.  This is a place
> > > where ("Alert!  Don the asbestos skivvies now!") adding an
> > > option to ("I'm warning you! Prepare for flamage!") beastie.4th
> > > might be a good idea.
> >
> > One possibility is adding DMI scan code in loader and passing
> > BIOS ID strings to kernel because loader can easily call BIOS
> > function calls. This won't require ugly hack in kernel space.
>
> I like this approach better.  We already provide hints to ACPI via
> the loader.

I had some time last week and wrote the patch.  This patch exports the 
following environment variables to loader:

hint.smbios.0.enabled		"YES" when SMBIOS is detected

hint.smbios.0.bios.vendor	BIOS vendor
hint.smbios.0.bios.version	BIOS version
hint.smbios.0.bios.reldate	BIOS release date

hint.smbios.0.system.maker	System manufacturer
hint.smbios.0.system.product	System product name
hint.smbios.0.system.version	System version number

hint.smbios.0.planar.maker	Base board manufacturer
hint.smbios.0.planar.product	Base board product name
hint.smbios.0.planar.version	Base board version number

hint.smbios.0.chassis.maker	Enclosure manufacturer
hint.smbios.0.chassis.version	Enclosure version

If you think the information is excessive, you can comment them out.  
You can change the variable names if you don't like them. ;-)

Cheers,

Jung-uk Kim

* Postscript: Matthew,

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/bios/smbios.c

has the wrong SMBIOS EPS structure.  According to 'System Management 
BIOS Reference Specification, v2.4 Final 
(http://www.dmtf.org/standards/published_documents/DSP0134.pdf)' page 
13-14, correct structure is something like this:

/*
 * SMBIOS Entry Point Structure
 */
struct smbios_eps {
	u_int8_t	Anchor[4];		/* '_SM_' */
	u_int8_t	Checksum;
	u_int8_t	Length;

	u_int8_t	SMBIOS_Major;
	u_int8_t	SMBIOS_Minor;
	u_int16_t	Max_Size;
	u_int8_t	Revision;
	u_int8_t	Formatted_Area[5];

	u_int8_t	Intermediate_Anchor[5];	/* '_DMI_' */
	u_int8_t	Intermediate_Checksum;

	u_int16_t	Structure_Table_Length;
	u_int32_t	Structure_Table_Address;
	u_int16_t	Structure_Count;

	u_int8_t	SMBIOS_BCD_Revision;
} __packed;

Just FYI...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smbios.diff
Type: text/x-diff
Size: 7246 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050523/64d1f689/smbios.bin