Re: svn commit: r307326 - head/sys/boot/efi/loader

[Alexey Dokuchaev]

On Fri, Oct 14, 2016 at 05:10:53PM +, Doug Ambrisko wrote:
> New Revision: 307326
> URL: https://svnweb.freebsd.org/changeset/base/307326
> 
> Log:
>   In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel
>   etc. can find out where the SMBIOS entry point is located.  In pure
>   UEFI mode the BIOS is not mapped into the standard address space so the
>   SMBIOS table might not appear between 0xf and 0xf.  The
>   UEFI environment can report this the location of the anchor.  If it is
>   reported then expose it as hint.smbios.0.mem. [...]
>   
>   Linux exposes this information via the /sys/firmware/efi/systab file
>   which dmidecode looks at.  We should update dmidecode to do this the
>   FreeBSD way when we determine what that is!

We just did: https://svnweb.freebsd.org/changeset/ports/12 (sorry it
took us eight months).

./danfe
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Slawa Olhovchenkov]

On Wed, Oct 19, 2016 at 04:33:39PM -0600, Warner Losh wrote:

> On Wed, Oct 19, 2016 at 11:34 AM, John Baldwin  wrote:
> > On Wednesday, October 19, 2016 02:01:18 AM Warner Losh wrote:
> >> One of my systems would export these as sysctls:
> >>
> >> smbios.bios.reldate="07/05/2013"
> >> smbios.bios.vendor="American Megatrends Inc."
> >> smbios.bios.version="3.00"
> >> smbios.chassis.maker="Supermicro"
> >> smbios.chassis.serial="0123456789"
> >> smbios.chassis.tag="To Be Filled By O.E.M."
> >> smbios.chassis.version="0123456789"
> >> smbios.memory.enabled="268435456"
> >> smbios.planar.location="To be filled by O.E.M."
> >> smbios.planar.maker="Supermicro"
> >> smbios.planar.product="X9SRH-7F/7TF"
> >> smbios.planar.serial="VM13CS028237"
> >> smbios.planar.tag="To be filled by O.E.M."
> >> smbios.planar.version="0123456789"
> >> smbios.socket.enabled="1"
> >> smbios.socket.populated="1"
> >> smbios.system.family="To be filled by O.E.M."
> >> smbios.system.maker="Supermicro"
> >> smbios.system.product="X9SRH-7F/7TF"
> >> smbios.system.serial="0123456789"
> >> smbios.system.sku="To be filled by O.E.M."
> >> smbios.system.uuid="----002590e4d0ec"
> >> smbios.system.version="0123456789"
> >> smbios.version="2.7"
> >>
> >> though some of them are silly due to the BIOS writer being silly...
> >
> > So are you planning to just duplicate the existing kenv vars as sysctl
> > nodes?  Can't you parse the output of kenv instead?
> 
> I often get sysctl -a from ailing systems. I never or rarely get kenv.
> This adds to the information available when I'm looking into problems
> since it gives me more data about the system where the problem occurs.

Look like we need show-tech in base system
:)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Warner Losh]

On Wed, Oct 19, 2016 at 11:34 AM, John Baldwin  wrote:
> On Wednesday, October 19, 2016 02:01:18 AM Warner Losh wrote:
>> One of my systems would export these as sysctls:
>>
>> smbios.bios.reldate="07/05/2013"
>> smbios.bios.vendor="American Megatrends Inc."
>> smbios.bios.version="3.00"
>> smbios.chassis.maker="Supermicro"
>> smbios.chassis.serial="0123456789"
>> smbios.chassis.tag="To Be Filled By O.E.M."
>> smbios.chassis.version="0123456789"
>> smbios.memory.enabled="268435456"
>> smbios.planar.location="To be filled by O.E.M."
>> smbios.planar.maker="Supermicro"
>> smbios.planar.product="X9SRH-7F/7TF"
>> smbios.planar.serial="VM13CS028237"
>> smbios.planar.tag="To be filled by O.E.M."
>> smbios.planar.version="0123456789"
>> smbios.socket.enabled="1"
>> smbios.socket.populated="1"
>> smbios.system.family="To be filled by O.E.M."
>> smbios.system.maker="Supermicro"
>> smbios.system.product="X9SRH-7F/7TF"
>> smbios.system.serial="0123456789"
>> smbios.system.sku="To be filled by O.E.M."
>> smbios.system.uuid="----002590e4d0ec"
>> smbios.system.version="0123456789"
>> smbios.version="2.7"
>>
>> though some of them are silly due to the BIOS writer being silly...
>
> So are you planning to just duplicate the existing kenv vars as sysctl
> nodes?  Can't you parse the output of kenv instead?

I often get sysctl -a from ailing systems. I never or rarely get kenv.
This adds to the information available when I'm looking into problems
since it gives me more data about the system where the problem occurs.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[John Baldwin]

On Wednesday, October 19, 2016 02:01:18 AM Warner Losh wrote:
> One of my systems would export these as sysctls:
> 
> smbios.bios.reldate="07/05/2013"
> smbios.bios.vendor="American Megatrends Inc."
> smbios.bios.version="3.00"
> smbios.chassis.maker="Supermicro"
> smbios.chassis.serial="0123456789"
> smbios.chassis.tag="To Be Filled By O.E.M."
> smbios.chassis.version="0123456789"
> smbios.memory.enabled="268435456"
> smbios.planar.location="To be filled by O.E.M."
> smbios.planar.maker="Supermicro"
> smbios.planar.product="X9SRH-7F/7TF"
> smbios.planar.serial="VM13CS028237"
> smbios.planar.tag="To be filled by O.E.M."
> smbios.planar.version="0123456789"
> smbios.socket.enabled="1"
> smbios.socket.populated="1"
> smbios.system.family="To be filled by O.E.M."
> smbios.system.maker="Supermicro"
> smbios.system.product="X9SRH-7F/7TF"
> smbios.system.serial="0123456789"
> smbios.system.sku="To be filled by O.E.M."
> smbios.system.uuid="----002590e4d0ec"
> smbios.system.version="0123456789"
> smbios.version="2.7"
> 
> though some of them are silly due to the BIOS writer being silly...

So are you planning to just duplicate the existing kenv vars as sysctl
nodes?  Can't you parse the output of kenv instead?

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Warner Losh]

On Wed, Oct 19, 2016 at 12:20 AM, John Baldwin <j...@freebsd.org> wrote:
> On Tuesday, October 18, 2016 11:44:52 PM Warner Losh wrote:
>> On Mon, Oct 17, 2016 at 11:40 AM, John Baldwin <j...@freebsd.org> wrote:
>> > On Friday, October 14, 2016 12:25:54 PM Warner Losh wrote:
>> >> On Oct 14, 2016 11:55 AM, "Doug Ambrisko" <ambri...@ambrisko.com> wrote:
>> >> >
>> >> > On Fri, Oct 14, 2016 at 10:33:15AM -0700, Ravi Pokala wrote:
>> >> > | -Original Message-
>> >> > | > From: <owner-src-committ...@freebsd.org> on behalf of Doug Ambrisko 
>> >> > <
>> >> ambri...@ambrisko.com>
>> >> > | > Date: 2016-10-14, Friday at 10:27
>> >> > | > To: Warner Losh <i...@bsdimp.com>
>> >> > | > Cc: Doug Ambrisko <ambri...@freebsd.org>, src-committers <
>> >> src-committ...@freebsd.org>, "svn-src-...@freebsd.org" <
>> >> svn-src-...@freebsd.org>, "svn-src-head@freebsd.org" <
>> >> svn-src-head@freebsd.org>
>> >> > | > Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader
>> >> > | >
>> >> > | > On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote:
>> >> > | > | Love the functionality, but don't like using the 'hint' namespace
>> >> for
>> >> > | > | this. Can we change it now before too many things depend on it? We
>> >> had
>> >> > | > | similar issues in ACPI and moved it to the 'acpi' space. Can we 
>> >> > move
>> >> > | > | this to the 'smbios' space please?
>> >> > | > |
>> >> > | > | The reason is that 'hint' is special and sometimes filtered out, 
>> >> > so
>> >> it
>> >> > | > | is a poor choice to export data from the boot loader to the 
>> >> > kernel.
>> >> > | >
>> >> > | > The reason I picked hint was it could be put /boot/device.hints
>> >> > | > to make it work as well and that it was a hint.  Other standards in
>> >> the
>> >> > | > future might use other methods.  Looking back over the email I had
>> >> > | > with John he had suggested hint.smbios.0.anchor to make this look
>> >> > | > different.  This code had been hanging around for so long I forgot
>> >> > | > about that and we were using hint.smbios.0.mem in our shipping code
>> >> base.
>> >> > | >
>> >> > | > However, I hope that nothing would use this except for smbios(4) and
>> >> > | > for people to make smbios(4) useful for this info.
>> >> > |
>> >> > | Doug's looking at me when he says that. :-)
>> >> > |
>> >> > | We talked about this last night at BAFUG; right now, even if smbios(4)
>> >> > | is able to find the SMBIOS info -- it currently only looks at the
>> >> > | aforementioned 0xf - 0xf range, so it can't find it on UEFI --
>> >> > | smbios(4) doesn't actually provide any interface for that information.
>> >> > | Doug and I have talked about making smbios(4) useful, by parsing the
>> >> > | data and providing KPIs and APIs, for years now; I think I'll 
>> >> > *finally*
>> >> > | have the time and motivation to do so "soon".
>> >> >
>> >> > I've actually talked to a few people.  However, your the first to
>> >> > step up.  This needs to be designed and will take some time and
>> >> > review.  I would hope that except for smbios(4), nothing else would
>> >> > use this kenv but there is nothing to prevent that :-(  I could name
>> >> > it super_secret_dont_use.
>> >> >
>> >> > BTW, to get you started this patch prevents smbios(4) from blowing 
>> >> > chunks
>> >> > when it gets a anchor in high memory and works on legacy machines.
>> >> >
>> >> > --- /sys/x86/bios/smbios.c  2013-10-01 14:28:25.0 -0700
>> >> > +++ ./smbios.c  2016-04-11 11:58:03.234969000 -0700
>> >> > @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD: release/9.2.0/sys/x8
>> >> >  #include 
>> >> >  #include 
>> >> >  #include 
>> >> > +#include 
>> >> >
>> >> >  #include 
>> >

Re: svn commit: r307326 - head/sys/boot/efi/loader

[John Baldwin]

On Tuesday, October 18, 2016 11:44:52 PM Warner Losh wrote:
> On Mon, Oct 17, 2016 at 11:40 AM, John Baldwin <j...@freebsd.org> wrote:
> > On Friday, October 14, 2016 12:25:54 PM Warner Losh wrote:
> >> On Oct 14, 2016 11:55 AM, "Doug Ambrisko" <ambri...@ambrisko.com> wrote:
> >> >
> >> > On Fri, Oct 14, 2016 at 10:33:15AM -0700, Ravi Pokala wrote:
> >> > | -Original Message-
> >> > | > From: <owner-src-committ...@freebsd.org> on behalf of Doug Ambrisko <
> >> ambri...@ambrisko.com>
> >> > | > Date: 2016-10-14, Friday at 10:27
> >> > | > To: Warner Losh <i...@bsdimp.com>
> >> > | > Cc: Doug Ambrisko <ambri...@freebsd.org>, src-committers <
> >> src-committ...@freebsd.org>, "svn-src-...@freebsd.org" <
> >> svn-src-...@freebsd.org>, "svn-src-head@freebsd.org" <
> >> svn-src-head@freebsd.org>
> >> > | > Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader
> >> > | >
> >> > | > On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote:
> >> > | > | Love the functionality, but don't like using the 'hint' namespace
> >> for
> >> > | > | this. Can we change it now before too many things depend on it? We
> >> had
> >> > | > | similar issues in ACPI and moved it to the 'acpi' space. Can we 
> >> > move
> >> > | > | this to the 'smbios' space please?
> >> > | > |
> >> > | > | The reason is that 'hint' is special and sometimes filtered out, so
> >> it
> >> > | > | is a poor choice to export data from the boot loader to the kernel.
> >> > | >
> >> > | > The reason I picked hint was it could be put /boot/device.hints
> >> > | > to make it work as well and that it was a hint.  Other standards in
> >> the
> >> > | > future might use other methods.  Looking back over the email I had
> >> > | > with John he had suggested hint.smbios.0.anchor to make this look
> >> > | > different.  This code had been hanging around for so long I forgot
> >> > | > about that and we were using hint.smbios.0.mem in our shipping code
> >> base.
> >> > | >
> >> > | > However, I hope that nothing would use this except for smbios(4) and
> >> > | > for people to make smbios(4) useful for this info.
> >> > |
> >> > | Doug's looking at me when he says that. :-)
> >> > |
> >> > | We talked about this last night at BAFUG; right now, even if smbios(4)
> >> > | is able to find the SMBIOS info -- it currently only looks at the
> >> > | aforementioned 0xf - 0xf range, so it can't find it on UEFI --
> >> > | smbios(4) doesn't actually provide any interface for that information.
> >> > | Doug and I have talked about making smbios(4) useful, by parsing the
> >> > | data and providing KPIs and APIs, for years now; I think I'll *finally*
> >> > | have the time and motivation to do so "soon".
> >> >
> >> > I've actually talked to a few people.  However, your the first to
> >> > step up.  This needs to be designed and will take some time and
> >> > review.  I would hope that except for smbios(4), nothing else would
> >> > use this kenv but there is nothing to prevent that :-(  I could name
> >> > it super_secret_dont_use.
> >> >
> >> > BTW, to get you started this patch prevents smbios(4) from blowing chunks
> >> > when it gets a anchor in high memory and works on legacy machines.
> >> >
> >> > --- /sys/x86/bios/smbios.c  2013-10-01 14:28:25.0 -0700
> >> > +++ ./smbios.c  2016-04-11 11:58:03.234969000 -0700
> >> > @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD: release/9.2.0/sys/x8
> >> >  #include 
> >> >  #include 
> >> >  #include 
> >> > +#include 
> >> >
> >> >  #include 
> >> >  #include 
> >> > @@ -59,7 +60,7 @@ struct smbios_softc {
> >> >  };
> >> >
> >> >  #defineRES2EPS(res)((struct smbios_eps
> >> *)rman_get_virtual(res))
> >> > -#defineADDR2EPS(addr)  ((struct smbios_eps
> >> *)BIOS_PADDRTOVADDR(addr))
> >> > +#defineADDR2EPS(addr)  ((struct smbios_eps *)PHYS_TO_DMAP(addr))
> >> >
> >> >  static devclass_t  smbios_dev

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Warner Losh]

On Mon, Oct 17, 2016 at 11:40 AM, John Baldwin <j...@freebsd.org> wrote:
> On Friday, October 14, 2016 12:25:54 PM Warner Losh wrote:
>> On Oct 14, 2016 11:55 AM, "Doug Ambrisko" <ambri...@ambrisko.com> wrote:
>> >
>> > On Fri, Oct 14, 2016 at 10:33:15AM -0700, Ravi Pokala wrote:
>> > | -Original Message-
>> > | > From: <owner-src-committ...@freebsd.org> on behalf of Doug Ambrisko <
>> ambri...@ambrisko.com>
>> > | > Date: 2016-10-14, Friday at 10:27
>> > | > To: Warner Losh <i...@bsdimp.com>
>> > | > Cc: Doug Ambrisko <ambri...@freebsd.org>, src-committers <
>> src-committ...@freebsd.org>, "svn-src-...@freebsd.org" <
>> svn-src-...@freebsd.org>, "svn-src-head@freebsd.org" <
>> svn-src-head@freebsd.org>
>> > | > Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader
>> > | >
>> > | > On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote:
>> > | > | Love the functionality, but don't like using the 'hint' namespace
>> for
>> > | > | this. Can we change it now before too many things depend on it? We
>> had
>> > | > | similar issues in ACPI and moved it to the 'acpi' space. Can we move
>> > | > | this to the 'smbios' space please?
>> > | > |
>> > | > | The reason is that 'hint' is special and sometimes filtered out, so
>> it
>> > | > | is a poor choice to export data from the boot loader to the kernel.
>> > | >
>> > | > The reason I picked hint was it could be put /boot/device.hints
>> > | > to make it work as well and that it was a hint.  Other standards in
>> the
>> > | > future might use other methods.  Looking back over the email I had
>> > | > with John he had suggested hint.smbios.0.anchor to make this look
>> > | > different.  This code had been hanging around for so long I forgot
>> > | > about that and we were using hint.smbios.0.mem in our shipping code
>> base.
>> > | >
>> > | > However, I hope that nothing would use this except for smbios(4) and
>> > | > for people to make smbios(4) useful for this info.
>> > |
>> > | Doug's looking at me when he says that. :-)
>> > |
>> > | We talked about this last night at BAFUG; right now, even if smbios(4)
>> > | is able to find the SMBIOS info -- it currently only looks at the
>> > | aforementioned 0xf - 0xf range, so it can't find it on UEFI --
>> > | smbios(4) doesn't actually provide any interface for that information.
>> > | Doug and I have talked about making smbios(4) useful, by parsing the
>> > | data and providing KPIs and APIs, for years now; I think I'll *finally*
>> > | have the time and motivation to do so "soon".
>> >
>> > I've actually talked to a few people.  However, your the first to
>> > step up.  This needs to be designed and will take some time and
>> > review.  I would hope that except for smbios(4), nothing else would
>> > use this kenv but there is nothing to prevent that :-(  I could name
>> > it super_secret_dont_use.
>> >
>> > BTW, to get you started this patch prevents smbios(4) from blowing chunks
>> > when it gets a anchor in high memory and works on legacy machines.
>> >
>> > --- /sys/x86/bios/smbios.c  2013-10-01 14:28:25.0 -0700
>> > +++ ./smbios.c  2016-04-11 11:58:03.234969000 -0700
>> > @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD: release/9.2.0/sys/x8
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >
>> >  #include 
>> >  #include 
>> > @@ -59,7 +60,7 @@ struct smbios_softc {
>> >  };
>> >
>> >  #defineRES2EPS(res)((struct smbios_eps
>> *)rman_get_virtual(res))
>> > -#defineADDR2EPS(addr)  ((struct smbios_eps
>> *)BIOS_PADDRTOVADDR(addr))
>> > +#defineADDR2EPS(addr)  ((struct smbios_eps *)PHYS_TO_DMAP(addr))
>> >
>> >  static devclass_t  smbios_devclass;
>> >
>> > @@ -71,19 +72,26 @@ static int  smbios_modevent (module_t, in
>> >
>> >  static int smbios_cksum(struct smbios_eps *);
>> >
>> > +static unsigned long addr;
>> > +static SYSCTL_NODE(_hw, OID_AUTO, smbios, CTLFLAG_RD, 0,
>> > +"SMBIOS driver parameters");
>> > +SYSCTL_LONG(_hw_smbios, OID_AUTO, mem, CTLFLAG_RW,
>> > +, 0, "");
>> >

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Bruce Simpson]

On 17/10/16 21:23, Bruce Simpson wrote:

On 17/10/16 18:40, John Baldwin wrote:

I'm a bit hesitant to do all the type parsing in the kernel vs userland.
However, I think having smbios(4) export a /dev/smbios that you can
either
read() or mmap() to access the table would be very convenient and let you
keep the bits to parse the table in userland (and not require root if we
allow read-only access to mortals on /dev/foo).


This is probably a bit left-field, but I'm wondering if both methods
(expose-to-loader-kenv and user-space-accessible devfs node) can be
re-used for things like the Linux-oriented kernel environment page
exported by SYSLINUX/PXELINUX memdisk, which I've used with some success
to boot FreeBSD installers in heterogeneous private cloud/lab setups.


PS Hit send too soon -- the main reason a FreeBSD installer, or image 
wrapper for a FreeBSD installer tool (akin to the Debian style of 
network driven installer), would need access to the memdisk's ACPI-style 
table (containing boot & textual 'environment' page, filled out by the 
TFTP boot server, perhaps by scripted means) is...


...where it can't intuit all system configuration settings by reference 
to its primary MAC address alone, or where it needs network bootstrap 
information to proceed with other provisioning methods (straight to 
Puppet/Ansible, and/or fetching a list of pkgng pkgs to grab from some 
trusted package server).


The code required would just pretty much resemble what you guys are 
doing for EFI right now, but for BIOS-era systems (of which we've got a 
large installed base, and mass provisioning those would be great, for 
the sake of recycling.)

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Bruce Simpson]

On 17/10/16 18:40, John Baldwin wrote:

I'm a bit hesitant to do all the type parsing in the kernel vs userland.
However, I think having smbios(4) export a /dev/smbios that you can either
read() or mmap() to access the table would be very convenient and let you
keep the bits to parse the table in userland (and not require root if we
allow read-only access to mortals on /dev/foo).


This is probably a bit left-field, but I'm wondering if both methods 
(expose-to-loader-kenv and user-space-accessible devfs node) can be 
re-used for things like the Linux-oriented kernel environment page 
exported by SYSLINUX/PXELINUX memdisk, which I've used with some success 
to boot FreeBSD installers in heterogeneous private cloud/lab setups.


It exports this information using an ACPI-like table in that BIOS HBA 
type area in x86 address space, but the table is not DSDT linked (it's 
not produced by the BIOS).


Having a coherent means of dealing with it would be very useful, as such 
FreeBSD installers (which I've deployed as mfsBSD images) can then 
basically re-use what's been done for EFI variables for those legacy 
systems which don't support/can't use EFI network boot. As yet, I've not 
tried this with 64-bit EFI systems.


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[John Baldwin]

On Friday, October 14, 2016 12:25:54 PM Warner Losh wrote:
> On Oct 14, 2016 11:55 AM, "Doug Ambrisko" <ambri...@ambrisko.com> wrote:
> >
> > On Fri, Oct 14, 2016 at 10:33:15AM -0700, Ravi Pokala wrote:
> > | -Original Message-
> > | > From: <owner-src-committ...@freebsd.org> on behalf of Doug Ambrisko <
> ambri...@ambrisko.com>
> > | > Date: 2016-10-14, Friday at 10:27
> > | > To: Warner Losh <i...@bsdimp.com>
> > | > Cc: Doug Ambrisko <ambri...@freebsd.org>, src-committers <
> src-committ...@freebsd.org>, "svn-src-...@freebsd.org" <
> svn-src-...@freebsd.org>, "svn-src-head@freebsd.org" <
> svn-src-head@freebsd.org>
> > | > Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader
> > | >
> > | > On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote:
> > | > | Love the functionality, but don't like using the 'hint' namespace
> for
> > | > | this. Can we change it now before too many things depend on it? We
> had
> > | > | similar issues in ACPI and moved it to the 'acpi' space. Can we move
> > | > | this to the 'smbios' space please?
> > | > |
> > | > | The reason is that 'hint' is special and sometimes filtered out, so
> it
> > | > | is a poor choice to export data from the boot loader to the kernel.
> > | >
> > | > The reason I picked hint was it could be put /boot/device.hints
> > | > to make it work as well and that it was a hint.  Other standards in
> the
> > | > future might use other methods.  Looking back over the email I had
> > | > with John he had suggested hint.smbios.0.anchor to make this look
> > | > different.  This code had been hanging around for so long I forgot
> > | > about that and we were using hint.smbios.0.mem in our shipping code
> base.
> > | >
> > | > However, I hope that nothing would use this except for smbios(4) and
> > | > for people to make smbios(4) useful for this info.
> > |
> > | Doug's looking at me when he says that. :-)
> > |
> > | We talked about this last night at BAFUG; right now, even if smbios(4)
> > | is able to find the SMBIOS info -- it currently only looks at the
> > | aforementioned 0xf - 0xf range, so it can't find it on UEFI --
> > | smbios(4) doesn't actually provide any interface for that information.
> > | Doug and I have talked about making smbios(4) useful, by parsing the
> > | data and providing KPIs and APIs, for years now; I think I'll *finally*
> > | have the time and motivation to do so "soon".
> >
> > I've actually talked to a few people.  However, your the first to
> > step up.  This needs to be designed and will take some time and
> > review.  I would hope that except for smbios(4), nothing else would
> > use this kenv but there is nothing to prevent that :-(  I could name
> > it super_secret_dont_use.
> >
> > BTW, to get you started this patch prevents smbios(4) from blowing chunks
> > when it gets a anchor in high memory and works on legacy machines.
> >
> > --- /sys/x86/bios/smbios.c  2013-10-01 14:28:25.0 -0700
> > +++ ./smbios.c  2016-04-11 11:58:03.234969000 -0700
> > @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD: release/9.2.0/sys/x8
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -59,7 +60,7 @@ struct smbios_softc {
> >  };
> >
> >  #defineRES2EPS(res)((struct smbios_eps
> *)rman_get_virtual(res))
> > -#defineADDR2EPS(addr)  ((struct smbios_eps
> *)BIOS_PADDRTOVADDR(addr))
> > +#defineADDR2EPS(addr)  ((struct smbios_eps *)PHYS_TO_DMAP(addr))
> >
> >  static devclass_t  smbios_devclass;
> >
> > @@ -71,19 +72,26 @@ static int  smbios_modevent (module_t, in
> >
> >  static int smbios_cksum(struct smbios_eps *);
> >
> > +static unsigned long addr;
> > +static SYSCTL_NODE(_hw, OID_AUTO, smbios, CTLFLAG_RD, 0,
> > +"SMBIOS driver parameters");
> > +SYSCTL_LONG(_hw_smbios, OID_AUTO, mem, CTLFLAG_RW,
> > +, 0, "");
> > +
> >  static void
> >  smbios_identify (driver_t *driver, device_t parent)
> >  {
> > device_t child;
> > -   u_int32_t addr;
> > int length;
> > int rid;
> >
> > if (!device_is_alive(parent))
> > return;
> >
> > -   addr = bios_sigsearch(SMBIOS_START, SMBIOS_SIG, SMBIOS_LEN,
> > -

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Doug Ambrisko]

On Fri, Oct 14, 2016 at 12:25:54PM -0600, Warner Losh wrote:
|On Oct 14, 2016 11:55 AM, "Doug Ambrisko" <[1]ambri...@ambrisko.com>
|wrote:
|>
|> On Fri, Oct 14, 2016 at 10:33:15AM -0700, Ravi Pokala wrote:
|> | -Original Message-
|> | > From: <[2]owner-src-committ...@freebsd.org> on behalf of Doug
|Ambrisko <[3]ambri...@ambrisko.com>
|> | > Date: 2016-10-14, Friday at 10:27
|> | > To: Warner Losh <[4]i...@bsdimp.com>
|> | > Cc: Doug Ambrisko <[5]ambri...@freebsd.org>, src-committers
|<[6]src-committ...@freebsd.org>, "[7]svn-src-...@freebsd.org"
|<[8]svn-src-...@freebsd.org>, "[9]svn-src-head@freebsd.org"
|<[10]svn-src-head@freebsd.org>
|> | > Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader
|> | >
|> | > On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote:
|> | > | Love the functionality, but don't like using the 'hint'
|namespace for
|> | > | this. Can we change it now before too many things depend on it?
|We had
|> | > | similar issues in ACPI and moved it to the 'acpi' space. Can we
|move
|> | > | this to the 'smbios' space please?
|> | > |
|> | > | The reason is that 'hint' is special and sometimes filtered
|out, so it
|> | > | is a poor choice to export data from the boot loader to the
|kernel.
|> | >
|> | > The reason I picked hint was it could be put /boot/device.hints
|> | > to make it work as well and that it was a hint.  Other standards
|in the
|> | > future might use other methods.  Looking back over the email I
|had
|> | > with John he had suggested hint.smbios.0.anchor to make this look
|> | > different.  This code had been hanging around for so long I
|forgot
|> | > about that and we were using hint.smbios.0.mem in our shipping
|code base.
|> | >
|> | > However, I hope that nothing would use this except for smbios(4)
|and
|> | > for people to make smbios(4) useful for this info.
|> |
|> | Doug's looking at me when he says that. :-)
|> |
|> | We talked about this last night at BAFUG; right now, even if
|smbios(4)
|> | is able to find the SMBIOS info -- it currently only looks at the
|> | aforementioned 0xf - 0xf range, so it can't find it on UEFI
|--
|> | smbios(4) doesn't actually provide any interface for that
|information.
|> | Doug and I have talked about making smbios(4) useful, by parsing
|the
|> | data and providing KPIs and APIs, for years now; I think I'll
|*finally*
|> | have the time and motivation to do so "soon".
|>
|> I've actually talked to a few people.  However, your the first to
|> step up.  This needs to be designed and will take some time and
|> review.  I would hope that except for smbios(4), nothing else would
|> use this kenv but there is nothing to prevent that :-(  I could name
|> it super_secret_dont_use.
|>
|> BTW, to get you started this patch prevents smbios(4) from blowing
|chunks
|> when it gets a anchor in high memory and works on legacy machines.
|>
|> --- /sys/x86/bios/smbios.c  2013-10-01 14:28:25.0 -0700
|> +++ ./smbios.c  2016-04-11 11:58:03.234969000 -0700
|> @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD: release/9.2.0/sys/x8
|>  #include 
|>  #include 
|>  #include 
|> +#include 
|>
|>  #include 
|>  #include 
|> @@ -59,7 +60,7 @@ struct smbios_softc {
|>  };
|>
|>  #defineRES2EPS(res)((struct smbios_eps
|*)rman_get_virtual(res))
|> -#defineADDR2EPS(addr)  ((struct smbios_eps
|*)BIOS_PADDRTOVADDR(addr))
|> +#defineADDR2EPS(addr)  ((struct smbios_eps
|*)PHYS_TO_DMAP(addr))
|>
|>  static devclass_t  smbios_devclass;
|>
|> @@ -71,19 +72,26 @@ static int  smbios_modevent (module_t, in
|>
|>  static int smbios_cksum(struct smbios_eps *);
|>
|> +static unsigned long addr;
|> +static SYSCTL_NODE(_hw, OID_AUTO, smbios, CTLFLAG_RD, 0,
|> +"SMBIOS driver parameters");
|> +SYSCTL_LONG(_hw_smbios, OID_AUTO, mem, CTLFLAG_RW,
|> +, 0, "");
|> +
|>  static void
|>  smbios_identify (driver_t *driver, device_t parent)
|>  {
|> device_t child;
|> -   u_int32_t addr;
|> int length;
|> int rid;
|>
|> if (!device_is_alive(parent))
|> return;
|>
|> - 

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Warner Losh]

On Oct 14, 2016 11:55 AM, "Doug Ambrisko" <ambri...@ambrisko.com> wrote:
>
> On Fri, Oct 14, 2016 at 10:33:15AM -0700, Ravi Pokala wrote:
> | -Original Message-
> | > From: <owner-src-committ...@freebsd.org> on behalf of Doug Ambrisko <
ambri...@ambrisko.com>
> | > Date: 2016-10-14, Friday at 10:27
> | > To: Warner Losh <i...@bsdimp.com>
> | > Cc: Doug Ambrisko <ambri...@freebsd.org>, src-committers <
src-committ...@freebsd.org>, "svn-src-...@freebsd.org" <
svn-src-...@freebsd.org>, "svn-src-head@freebsd.org" <
svn-src-head@freebsd.org>
> | > Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader
> | >
> | > On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote:
> | > | Love the functionality, but don't like using the 'hint' namespace
for
> | > | this. Can we change it now before too many things depend on it? We
had
> | > | similar issues in ACPI and moved it to the 'acpi' space. Can we move
> | > | this to the 'smbios' space please?
> | > |
> | > | The reason is that 'hint' is special and sometimes filtered out, so
it
> | > | is a poor choice to export data from the boot loader to the kernel.
> | >
> | > The reason I picked hint was it could be put /boot/device.hints
> | > to make it work as well and that it was a hint.  Other standards in
the
> | > future might use other methods.  Looking back over the email I had
> | > with John he had suggested hint.smbios.0.anchor to make this look
> | > different.  This code had been hanging around for so long I forgot
> | > about that and we were using hint.smbios.0.mem in our shipping code
base.
> | >
> | > However, I hope that nothing would use this except for smbios(4) and
> | > for people to make smbios(4) useful for this info.
> |
> | Doug's looking at me when he says that. :-)
> |
> | We talked about this last night at BAFUG; right now, even if smbios(4)
> | is able to find the SMBIOS info -- it currently only looks at the
> | aforementioned 0xf - 0xf range, so it can't find it on UEFI --
> | smbios(4) doesn't actually provide any interface for that information.
> | Doug and I have talked about making smbios(4) useful, by parsing the
> | data and providing KPIs and APIs, for years now; I think I'll *finally*
> | have the time and motivation to do so "soon".
>
> I've actually talked to a few people.  However, your the first to
> step up.  This needs to be designed and will take some time and
> review.  I would hope that except for smbios(4), nothing else would
> use this kenv but there is nothing to prevent that :-(  I could name
> it super_secret_dont_use.
>
> BTW, to get you started this patch prevents smbios(4) from blowing chunks
> when it gets a anchor in high memory and works on legacy machines.
>
> --- /sys/x86/bios/smbios.c  2013-10-01 14:28:25.0 -0700
> +++ ./smbios.c  2016-04-11 11:58:03.234969000 -0700
> @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD: release/9.2.0/sys/x8
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -59,7 +60,7 @@ struct smbios_softc {
>  };
>
>  #defineRES2EPS(res)((struct smbios_eps
*)rman_get_virtual(res))
> -#defineADDR2EPS(addr)  ((struct smbios_eps
*)BIOS_PADDRTOVADDR(addr))
> +#defineADDR2EPS(addr)  ((struct smbios_eps *)PHYS_TO_DMAP(addr))
>
>  static devclass_t  smbios_devclass;
>
> @@ -71,19 +72,26 @@ static int  smbios_modevent (module_t, in
>
>  static int smbios_cksum(struct smbios_eps *);
>
> +static unsigned long addr;
> +static SYSCTL_NODE(_hw, OID_AUTO, smbios, CTLFLAG_RD, 0,
> +"SMBIOS driver parameters");
> +SYSCTL_LONG(_hw_smbios, OID_AUTO, mem, CTLFLAG_RW,
> +, 0, "");
> +
>  static void
>  smbios_identify (driver_t *driver, device_t parent)
>  {
> device_t child;
> -   u_int32_t addr;
> int length;
> int rid;
>
> if (!device_is_alive(parent))
> return;
>
> -   addr = bios_sigsearch(SMBIOS_START, SMBIOS_SIG, SMBIOS_LEN,
> - SMBIOS_STEP, SMBIOS_OFF);
> +   if (resource_long_value("smbios", 0, "mem", ) != 0 ||
> +   addr == 0)
> +   addr = bios_sigsearch(SMBIOS_START, SMBIOS_SIG,
SMBIOS_LEN,
> + SMBIOS_STEP, SMBIOS_OFF);
> if (addr != 0) {
> rid = 0;
> length = ADDR2EPS(addr)->length;
>
> Note I don't plan to commit this since it doesn't really do much and we
> need a lot more.

I was planning on exporting all smbios stuff via sysctl.

You can still put non hints.* in device.hints too.

I can rework things a bit to be more complete is you like...

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Doug Ambrisko]

On Fri, Oct 14, 2016 at 10:33:15AM -0700, Ravi Pokala wrote:
| -Original Message-
| > From: <owner-src-committ...@freebsd.org> on behalf of Doug Ambrisko 
<ambri...@ambrisko.com>
| > Date: 2016-10-14, Friday at 10:27
| > To: Warner Losh <i...@bsdimp.com>
| > Cc: Doug Ambrisko <ambri...@freebsd.org>, src-committers 
<src-committ...@freebsd.org>, "svn-src-...@freebsd.org" 
<svn-src-...@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>
| > Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader
| > 
| > On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote:
| > | Love the functionality, but don't like using the 'hint' namespace for
| > | this. Can we change it now before too many things depend on it? We had
| > | similar issues in ACPI and moved it to the 'acpi' space. Can we move
| > | this to the 'smbios' space please?
| > | 
| > | The reason is that 'hint' is special and sometimes filtered out, so it
| > | is a poor choice to export data from the boot loader to the kernel.
| > 
| > The reason I picked hint was it could be put /boot/device.hints
| > to make it work as well and that it was a hint.  Other standards in the
| > future might use other methods.  Looking back over the email I had
| > with John he had suggested hint.smbios.0.anchor to make this look
| > different.  This code had been hanging around for so long I forgot
| > about that and we were using hint.smbios.0.mem in our shipping code base.
| > 
| > However, I hope that nothing would use this except for smbios(4) and
| > for people to make smbios(4) useful for this info.
| 
| Doug's looking at me when he says that. :-)
| 
| We talked about this last night at BAFUG; right now, even if smbios(4) 
| is able to find the SMBIOS info -- it currently only looks at the 
| aforementioned 0xf - 0xf range, so it can't find it on UEFI -- 
| smbios(4) doesn't actually provide any interface for that information. 
| Doug and I have talked about making smbios(4) useful, by parsing the 
| data and providing KPIs and APIs, for years now; I think I'll *finally* 
| have the time and motivation to do so "soon".

I've actually talked to a few people.  However, your the first to
step up.  This needs to be designed and will take some time and
review.  I would hope that except for smbios(4), nothing else would
use this kenv but there is nothing to prevent that :-(  I could name
it super_secret_dont_use.

BTW, to get you started this patch prevents smbios(4) from blowing chunks
when it gets a anchor in high memory and works on legacy machines.

--- /sys/x86/bios/smbios.c  2013-10-01 14:28:25.0 -0700
+++ ./smbios.c  2016-04-11 11:58:03.234969000 -0700
@@ -38,6 +38,7 @@ __FBSDID("$FreeBSD: release/9.2.0/sys/x8
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -59,7 +60,7 @@ struct smbios_softc {
 };
 
 #defineRES2EPS(res)((struct smbios_eps *)rman_get_virtual(res))
-#defineADDR2EPS(addr)  ((struct smbios_eps *)BIOS_PADDRTOVADDR(addr))
+#defineADDR2EPS(addr)  ((struct smbios_eps *)PHYS_TO_DMAP(addr))
 
 static devclass_t  smbios_devclass;
 
@@ -71,19 +72,26 @@ static int  smbios_modevent (module_t, in
 
 static int smbios_cksum(struct smbios_eps *);
 
+static unsigned long addr;
+static SYSCTL_NODE(_hw, OID_AUTO, smbios, CTLFLAG_RD, 0,
+"SMBIOS driver parameters");
+SYSCTL_LONG(_hw_smbios, OID_AUTO, mem, CTLFLAG_RW,
+, 0, "");
+
 static void
 smbios_identify (driver_t *driver, device_t parent)
 {
device_t child;
-   u_int32_t addr;
int length;
int rid;
 
if (!device_is_alive(parent))
return;
 
-   addr = bios_sigsearch(SMBIOS_START, SMBIOS_SIG, SMBIOS_LEN,
- SMBIOS_STEP, SMBIOS_OFF);
+   if (resource_long_value("smbios", 0, "mem", ) != 0 ||
+   addr == 0)
+   addr = bios_sigsearch(SMBIOS_START, SMBIOS_SIG, SMBIOS_LEN,
+ SMBIOS_STEP, SMBIOS_OFF);
if (addr != 0) {
rid = 0;
length = ADDR2EPS(addr)->length;

Note I don't plan to commit this since it doesn't really do much and we
need a lot more.

Thanks,

Doug A.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Ravi Pokala]

-Original Message-
> From: <owner-src-committ...@freebsd.org> on behalf of Doug Ambrisko 
> <ambri...@ambrisko.com>
> Date: 2016-10-14, Friday at 10:27
> To: Warner Losh <i...@bsdimp.com>
> Cc: Doug Ambrisko <ambri...@freebsd.org>, src-committers 
> <src-committ...@freebsd.org>, "svn-src-...@freebsd.org" 
> <svn-src-...@freebsd.org>, "svn-src-head@freebsd.org" 
> <svn-src-head@freebsd.org>
> Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader
> 
> On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote:
> | Love the functionality, but don't like using the 'hint' namespace for
> | this. Can we change it now before too many things depend on it? We had
> | similar issues in ACPI and moved it to the 'acpi' space. Can we move
> | this to the 'smbios' space please?
> | 
> | The reason is that 'hint' is special and sometimes filtered out, so it
> | is a poor choice to export data from the boot loader to the kernel.
> 
> The reason I picked hint was it could be put /boot/device.hints
> to make it work as well and that it was a hint.  Other standards in the
> future might use other methods.  Looking back over the email I had
> with John he had suggested hint.smbios.0.anchor to make this look
> different.  This code had been hanging around for so long I forgot
> about that and we were using hint.smbios.0.mem in our shipping code base.
> 
> However, I hope that nothing would use this except for smbios(4) and
> for people to make smbios(4) useful for this info.

Doug's looking at me when he says that. :-)

We talked about this last night at BAFUG; right now, even if smbios(4) is able 
to find the SMBIOS info -- it currently only looks at the aforementioned 
0xf - 0xf range, so it can't find it on UEFI -- smbios(4) doesn't 
actually provide any interface for that information. Doug and I have talked 
about making smbios(4) useful, by parsing the data and providing KPIs and APIs, 
for years now; I think I'll *finally* have the time and motivation to do so 
"soon".

-Ravi (rpokala@)

> Thanks,
> 
> Doug A.



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Doug Ambrisko]

On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote:
| Love the functionality, but don't like using the 'hint' namespace for
| this. Can we change it now before too many things depend on it? We had
| similar issues in ACPI and moved it to the 'acpi' space. Can we move
| this to the 'smbios' space please?
| 
| The reason is that 'hint' is special and sometimes filtered out, so it
| is a poor choice to export data from the boot loader to the kernel.

The reason I picked hint was it could be put /boot/device.hints
to make it work as well and that it was a hint.  Other standards in the
future might use other methods.  Looking back over the email I had
with John he had suggested hint.smbios.0.anchor to make this look
different.  This code had been hanging around for so long I forgot
about that and we were using hint.smbios.0.mem in our shipping code base.

However, I hope that nothing would use this except for smbios(4) and
for people to make smbios(4) useful for this info.

Thanks,

Doug A.
 
| On Fri, Oct 14, 2016 at 11:10 AM, Doug Ambrisko  wrote:
| > Author: ambrisko
| > Date: Fri Oct 14 17:10:53 2016
| > New Revision: 307326
| > URL: https://svnweb.freebsd.org/changeset/base/307326
| >
| > Log:
| >   In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel
| >   etc. can find out where the SMBIOS entry point is located.  In pure
| >   UEFI mode the BIOS is not mapped into the standard address space so the
| >   SMBIOS table might not appear between 0xf and 0xf.  The
| >   UEFI environment can report this the location of the anchor.  If it is
| >   reported then expose it as hint.smbios.0.mem.  This can then be used
| >   by other tools.  However, we should make smbios(4) useful and have it
| >   take this value and provide accesor function so ipmi(4) etc. don't
| >   have to parse and figure things about the SMBIOS table.  I have some
| >   simple patches to smbios(4) to expose this address as sysctl and
| >   for ipmi(4) to get the base address.  However, the real fix is to
| >   have ipmi(4) ask smbios(4) for what it wants and have smbios(4)
| >   parse it out and return it.  This would make smbios(4) useful and reduce
| >   duplicated code.  If this address doesn't point to the anchor then
| >   finding SMBIOS info. will fail as if this didn't exist.  So there should
| >   be no harm.
| >
| >   With this change and the following hack, dmidecode works on a bunch of
| >   UEFI machines that I tested:
| >
| > if kenv hint.smbios.0.mem > /dev/null
| > then
| >   mkdir -p /sys/firmware/efi
| >   mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi
| >   echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab
| > fi
| >
| >   Linux exposes this information via the /sys/firmware/efi/systab file which
| >   dmidecode looks at.  We should update dmidecode to do this the FreeBSD
| >   way when we determine what that is!
| >
| >   Reviewed by:  jhb
| >
| > Modified:
| >   head/sys/boot/efi/loader/main.c
| >
| > Modified: head/sys/boot/efi/loader/main.c
| > 
==
| > --- head/sys/boot/efi/loader/main.c Fri Oct 14 17:04:07 2016
(r307325)
| > +++ head/sys/boot/efi/loader/main.c Fri Oct 14 17:10:53 2016
(r307326)
| > @@ -235,6 +235,7 @@ main(int argc, CHAR16 *argv[])
| > uint64_t pool_guid;
| > UINTN k;
| > int has_kbd;
| > +   char buf[40];
| >
| > archsw.arch_autoload = efi_autoload;
| > archsw.arch_getdev = efi_getdev;
| > @@ -447,6 +448,9 @@ main(int argc, CHAR16 *argv[])
| > for (k = 0; k < ST->NumberOfTableEntries; k++) {
| > guid = >ConfigurationTable[k].VendorGuid;
| > if (!memcmp(guid, , sizeof(EFI_GUID))) {
| > +   snprintf(buf, sizeof(buf), "%p",
| > +   ST->ConfigurationTable[k].VendorTable);
| > +   setenv("hint.smbios.0.mem", buf, 1);
| > 
smbios_detect(ST->ConfigurationTable[k].VendorTable);
| > break;
| > }
| > @@ -603,7 +607,8 @@ command_configuration(int argc, char *ar
| > else if (!memcmp(guid, , sizeof(EFI_GUID)))
| > printf("ACPI 2.0 Table");
| > else if (!memcmp(guid, , sizeof(EFI_GUID)))
| > -   printf("SMBIOS Table");
| > +   printf("SMBIOS Table %p",
| > +   ST->ConfigurationTable[i].VendorTable);
| > else if (!memcmp(guid, , sizeof(EFI_GUID)))
| > printf("DXE Table");
| > else if (!memcmp(guid, , sizeof(EFI_GUID)))
| >
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to 

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Ravi Pokala]

-Original Message-
> From: <owner-src-committ...@freebsd.org> on behalf of Warner Losh 
> <i...@bsdimp.com>
> Date: 2016-10-14, Friday at 10:16
> To: Doug Ambrisko <ambri...@freebsd.org>
> Cc: src-committers <src-committ...@freebsd.org>, "svn-src-...@freebsd.org" 
> <svn-src-...@freebsd.org>, "svn-src-head@freebsd.org" 
> <svn-src-head@freebsd.org>
> Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader
> 
> Love the functionality,

Ditto! Thank you Doug! :-)

> but don't like using the 'hint' namespace for
> this. Can we change it now before too many things depend on it? We had
> similar issues in ACPI and moved it to the 'acpi' space. Can we move
> this to the 'smbios' space please?
> 
> The reason is that 'hint' is special and sometimes filtered out, so it
> is a poor choice to export data from the boot loader to the kernel.

Loader already exports a bunch of stuff as "smbios.*" kenv variables. So 
perhaps "smbios.addr" or somesuch?

Thanks,

Ravi (rpokala@)

> Warner
> 
> On Fri, Oct 14, 2016 at 11:10 AM, Doug Ambrisko <ambri...@freebsd.org> wrote:
>> Author: ambrisko
>> Date: Fri Oct 14 17:10:53 2016
>> New Revision: 307326
>> URL: https://svnweb.freebsd.org/changeset/base/307326
>>
>> Log:
>>   In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel
>>   etc. can find out where the SMBIOS entry point is located.  In pure
>>   UEFI mode the BIOS is not mapped into the standard address space so the
>>   SMBIOS table might not appear between 0xf and 0xf.  The
>>   UEFI environment can report this the location of the anchor.  If it is
>>   reported then expose it as hint.smbios.0.mem.  This can then be used
>>   by other tools.  However, we should make smbios(4) useful and have it
>>   take this value and provide accesor function so ipmi(4) etc. don't
>>   have to parse and figure things about the SMBIOS table.  I have some
>>   simple patches to smbios(4) to expose this address as sysctl and
>>   for ipmi(4) to get the base address.  However, the real fix is to
>>   have ipmi(4) ask smbios(4) for what it wants and have smbios(4)
>>   parse it out and return it.  This would make smbios(4) useful and reduce
>>   duplicated code.  If this address doesn't point to the anchor then
>>   finding SMBIOS info. will fail as if this didn't exist.  So there should
>>   be no harm.
>>
>>   With this change and the following hack, dmidecode works on a bunch of
>>   UEFI machines that I tested:
>>
>> if kenv hint.smbios.0.mem > /dev/null
>> then
>>   mkdir -p /sys/firmware/efi
>>   mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi
>>   echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab
>> fi
>>
>>   Linux exposes this information via the /sys/firmware/efi/systab file which
>>   dmidecode looks at.  We should update dmidecode to do this the FreeBSD
>>   way when we determine what that is!
>>
>>   Reviewed by:  jhb
>>
>> Modified:
>>   head/sys/boot/efi/loader/main.c
>>
>> Modified: head/sys/boot/efi/loader/main.c
>> ==
>> --- head/sys/boot/efi/loader/main.c Fri Oct 14 17:04:07 2016
>> (r307325)
>> +++ head/sys/boot/efi/loader/main.c Fri Oct 14 17:10:53 2016
>> (r307326)
>> @@ -235,6 +235,7 @@ main(int argc, CHAR16 *argv[])
>> uint64_t pool_guid;
>> UINTN k;
>> int has_kbd;
>> +   char buf[40];
>>
>> archsw.arch_autoload = efi_autoload;
>> archsw.arch_getdev = efi_getdev;
>> @@ -447,6 +448,9 @@ main(int argc, CHAR16 *argv[])
>> for (k = 0; k < ST->NumberOfTableEntries; k++) {
>> guid = >ConfigurationTable[k].VendorGuid;
>> if (!memcmp(guid, , sizeof(EFI_GUID))) {
>> +   snprintf(buf, sizeof(buf), "%p",
>> +   ST->ConfigurationTable[k].VendorTable);
>> +   setenv("hint.smbios.0.mem", buf, 1);
>> smbios_detect(ST->ConfigurationTable[k].VendorTable);
>> break;
>> }
>> @@ -603,7 +607,8 @@ command_configuration(int argc, char *ar
>> else if (!memcmp(guid, , sizeof(EFI_GUID)))
>> printf("ACPI 2.0 Table");
>> else if (!memcmp(guid, , sizeof(EFI_GUID)))
>> -   printf("SMBIOS Table");
>> +   printf("SMBIOS Table %p",
>> +   ST->ConfigurationTable[i].VendorTable);
>> else if (!memcmp(guid, , sizeof(EFI_GUID)))
>> printf("DXE Table");
>> else if (!memcmp(guid, , sizeof(EFI_GUID)))
>>



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Warner Losh]

Love the functionality, but don't like using the 'hint' namespace for
this. Can we change it now before too many things depend on it? We had
similar issues in ACPI and moved it to the 'acpi' space. Can we move
this to the 'smbios' space please?

The reason is that 'hint' is special and sometimes filtered out, so it
is a poor choice to export data from the boot loader to the kernel.

Warner

On Fri, Oct 14, 2016 at 11:10 AM, Doug Ambrisko  wrote:
> Author: ambrisko
> Date: Fri Oct 14 17:10:53 2016
> New Revision: 307326
> URL: https://svnweb.freebsd.org/changeset/base/307326
>
> Log:
>   In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel
>   etc. can find out where the SMBIOS entry point is located.  In pure
>   UEFI mode the BIOS is not mapped into the standard address space so the
>   SMBIOS table might not appear between 0xf and 0xf.  The
>   UEFI environment can report this the location of the anchor.  If it is
>   reported then expose it as hint.smbios.0.mem.  This can then be used
>   by other tools.  However, we should make smbios(4) useful and have it
>   take this value and provide accesor function so ipmi(4) etc. don't
>   have to parse and figure things about the SMBIOS table.  I have some
>   simple patches to smbios(4) to expose this address as sysctl and
>   for ipmi(4) to get the base address.  However, the real fix is to
>   have ipmi(4) ask smbios(4) for what it wants and have smbios(4)
>   parse it out and return it.  This would make smbios(4) useful and reduce
>   duplicated code.  If this address doesn't point to the anchor then
>   finding SMBIOS info. will fail as if this didn't exist.  So there should
>   be no harm.
>
>   With this change and the following hack, dmidecode works on a bunch of
>   UEFI machines that I tested:
>
> if kenv hint.smbios.0.mem > /dev/null
> then
>   mkdir -p /sys/firmware/efi
>   mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi
>   echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab
> fi
>
>   Linux exposes this information via the /sys/firmware/efi/systab file which
>   dmidecode looks at.  We should update dmidecode to do this the FreeBSD
>   way when we determine what that is!
>
>   Reviewed by:  jhb
>
> Modified:
>   head/sys/boot/efi/loader/main.c
>
> Modified: head/sys/boot/efi/loader/main.c
> ==
> --- head/sys/boot/efi/loader/main.c Fri Oct 14 17:04:07 2016
> (r307325)
> +++ head/sys/boot/efi/loader/main.c Fri Oct 14 17:10:53 2016
> (r307326)
> @@ -235,6 +235,7 @@ main(int argc, CHAR16 *argv[])
> uint64_t pool_guid;
> UINTN k;
> int has_kbd;
> +   char buf[40];
>
> archsw.arch_autoload = efi_autoload;
> archsw.arch_getdev = efi_getdev;
> @@ -447,6 +448,9 @@ main(int argc, CHAR16 *argv[])
> for (k = 0; k < ST->NumberOfTableEntries; k++) {
> guid = >ConfigurationTable[k].VendorGuid;
> if (!memcmp(guid, , sizeof(EFI_GUID))) {
> +   snprintf(buf, sizeof(buf), "%p",
> +   ST->ConfigurationTable[k].VendorTable);
> +   setenv("hint.smbios.0.mem", buf, 1);
> smbios_detect(ST->ConfigurationTable[k].VendorTable);
> break;
> }
> @@ -603,7 +607,8 @@ command_configuration(int argc, char *ar
> else if (!memcmp(guid, , sizeof(EFI_GUID)))
> printf("ACPI 2.0 Table");
> else if (!memcmp(guid, , sizeof(EFI_GUID)))
> -   printf("SMBIOS Table");
> +   printf("SMBIOS Table %p",
> +   ST->ConfigurationTable[i].VendorTable);
> else if (!memcmp(guid, , sizeof(EFI_GUID)))
> printf("DXE Table");
> else if (!memcmp(guid, , sizeof(EFI_GUID)))
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r307326 - head/sys/boot/efi/loader

[Doug Ambrisko]

Author: ambrisko
Date: Fri Oct 14 17:10:53 2016
New Revision: 307326
URL: https://svnweb.freebsd.org/changeset/base/307326

Log:
  In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel
  etc. can find out where the SMBIOS entry point is located.  In pure
  UEFI mode the BIOS is not mapped into the standard address space so the
  SMBIOS table might not appear between 0xf and 0xf.  The
  UEFI environment can report this the location of the anchor.  If it is
  reported then expose it as hint.smbios.0.mem.  This can then be used
  by other tools.  However, we should make smbios(4) useful and have it
  take this value and provide accesor function so ipmi(4) etc. don't
  have to parse and figure things about the SMBIOS table.  I have some
  simple patches to smbios(4) to expose this address as sysctl and
  for ipmi(4) to get the base address.  However, the real fix is to
  have ipmi(4) ask smbios(4) for what it wants and have smbios(4)
  parse it out and return it.  This would make smbios(4) useful and reduce
  duplicated code.  If this address doesn't point to the anchor then
  finding SMBIOS info. will fail as if this didn't exist.  So there should
  be no harm.
  
  With this change and the following hack, dmidecode works on a bunch of
  UEFI machines that I tested:
  
if kenv hint.smbios.0.mem > /dev/null
then
  mkdir -p /sys/firmware/efi
  mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi
  echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab
fi
  
  Linux exposes this information via the /sys/firmware/efi/systab file which
  dmidecode looks at.  We should update dmidecode to do this the FreeBSD
  way when we determine what that is!
  
  Reviewed by:  jhb

Modified:
  head/sys/boot/efi/loader/main.c

Modified: head/sys/boot/efi/loader/main.c
==
--- head/sys/boot/efi/loader/main.c Fri Oct 14 17:04:07 2016
(r307325)
+++ head/sys/boot/efi/loader/main.c Fri Oct 14 17:10:53 2016
(r307326)
@@ -235,6 +235,7 @@ main(int argc, CHAR16 *argv[])
uint64_t pool_guid;
UINTN k;
int has_kbd;
+   char buf[40];
 
archsw.arch_autoload = efi_autoload;
archsw.arch_getdev = efi_getdev;
@@ -447,6 +448,9 @@ main(int argc, CHAR16 *argv[])
for (k = 0; k < ST->NumberOfTableEntries; k++) {
guid = >ConfigurationTable[k].VendorGuid;
if (!memcmp(guid, , sizeof(EFI_GUID))) {
+   snprintf(buf, sizeof(buf), "%p",
+   ST->ConfigurationTable[k].VendorTable);
+   setenv("hint.smbios.0.mem", buf, 1);
smbios_detect(ST->ConfigurationTable[k].VendorTable);
break;
}
@@ -603,7 +607,8 @@ command_configuration(int argc, char *ar
else if (!memcmp(guid, , sizeof(EFI_GUID)))
printf("ACPI 2.0 Table");
else if (!memcmp(guid, , sizeof(EFI_GUID)))
-   printf("SMBIOS Table");
+   printf("SMBIOS Table %p",
+   ST->ConfigurationTable[i].VendorTable);
else if (!memcmp(guid, , sizeof(EFI_GUID)))
printf("DXE Table");
else if (!memcmp(guid, , sizeof(EFI_GUID)))
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"