grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrey Borzenkov <arvidjaar@gmail.com>
To: Holger Goetz <holgerg@hgsys.de>
Cc: grub-devel@gnu.org
Subject: Re: Obtaining the UUID of the system for a PXE boot
Date: Tue, 23 Jul 2013 20:45:03 +0400	[thread overview]
Message-ID: <20130723204503.16520724@opensuse.site> (raw)
In-Reply-To: <51EEAE57.8070700@hgsys.de>

В Tue, 23 Jul 2013 18:24:55 +0200
Holger Goetz <holgerg@hgsys.de> пишет:

> Hi,
> 
> looks i could need some help here.
> 
> I've moved the smbios module from commands/i386 to commands and added 
> some casts to make the compiler happy. As I need a x86_64-efi grub.
> What i see now is that the "_SM_" signature is not found: "Failed to 
> locate entry point structure"  some added grub_dprintf's show all zeros 
> in the memory area.
> Actually when i use the "dump" command to display the memory in the area 
> that gets swiped (0xf0000..0x10000) it (also) only displays "00"s.
> Is there some memory mapping required in x86_64 mode to access the 
> memory area properly? I did cross check w/ the Linux kernel efi code and 
> syslinux all basically do the same searching.
> 

You need to fetch SMBIOS table address from EFI system table. See as
example
https://git.ipxe.org/ipxe.git/blob/HEAD:/src/interface/efi/efi_smbios.c

You can use grub_machine_acpi_get_rsdpv2() as example implementation.
Just add SMBIOS GUID and any sanity checks as required.


> Thanks,
> Holger
> 
> 
> 
> On 19.07.2013 18:31, David Michael wrote:
> > Hi,
> >
> > On Fri, Jul 19, 2013 at 10:24 AM, Holger Goetz <holgerg@hgsys.de> wrote:
> >> Yes it's towards the right direction. But it is 32bit only if i understand
> >> correctly, and it basically is a memory access to fixed/hardcoded  MEMORY
> >> address (0x80000001). to pick the veondor id and machine info.
> > It's true that I've mostly been using the module on 32-bit virtual
> > machines, so it hasn't really been tested elsewhere.  However, I'm not
> > sure I understand what you mean by the hard-coded memory address.  The
> > first function grub_smbios_locate_eps searches for the SMBIOS entry
> > point structure as described in the spec.  The table entries are then
> > read at the table address found in the EPS, not a hard-coded location.
> >
> >> I have only 64bit - UEFI here - therefore the approach w/ first searching
> >> the SMBIOS infoblock in memory is probably required. And then properly walk
> >> through the info-tables/blocks to get to the UUID entry. It doesn'T need to
> >> be a fixed info to be retrieved from the SMBIOS memory - maybe a generic
> >> function to query/search a specific entry and return that to be assigned to
> >> a variable would be more flexible.
> > The module's command-line interface does use a (dumb) query/search
> > method.  You can specify the desired entry's type and/or handle and
> > the data to retrieve from it.  For example the following command
> > prints the machine name (i.e. the string at offset 5 in an entry with
> > type 1).
> >
> >          smbios -t 1 -s 5
> >
> > I think you may have found the first patch I sent in that old thread,
> > which was for different functionality.  The SMBIOS module can be
> > downloaded from the list archive[1].
> >
> > Unfortunately it doesn't have any convenient functions to output a
> > usable UUID.  It shouldn't take much to add one: the variable "entry"
> > in the "main" function is a pointer to the matched entry, so entry[8]
> > through entry[23] is the UUID in a call "smbios -t 1 ...".  I've
> > verified these bytes correspond to dmidecode output on my physical
> > hardware with the following.
> >
> >          for i in 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
> >          do smbios -t 1 -b $i
> >          done
> >
> > If the module isn't salvageable on UEFI, maybe I can send out an
> > updated version whenever I upgrade to such a system.
> >
> > Thanks.
> >
> > David
> >
> > [1] https://lists.gnu.org/archive/html/grub-devel/2013-04/binx8am8MvVSh.bin
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> 



      reply	other threads:[~2013-07-23 16:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <51E67DC2.1090609@hgsys.de>
     [not found] ` <CAA91j0XETaDEh16K0WJ3p5hNxxVXWk-PDBh2Gp-TYq6UjvRetw@mail.gmail.com>
     [not found]   ` <51E7C5F0.5000308@hgsys.de>
     [not found]     ` <20130718193501.629d9c69@opensuse.site>
2013-07-19 14:24       ` Obtaining the UUID of the system for a PXE boot Holger Goetz
2013-07-19 16:31         ` David Michael
2013-07-19 21:08           ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-07-20 14:23           ` Holger Goetz
2013-07-23 16:24           ` Holger Goetz
2013-07-23 16:45             ` Andrey Borzenkov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130723204503.16520724@opensuse.site \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    --cc=holgerg@hgsys.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).