grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Nando Eva <nando4eva@ymail.com>
To: "grub-devel@gnu.org" <grub-devel@gnu.org>
Subject: Re: Loading DSDT table using 'acpi' or some memory write command?
Date: Mon, 27 Feb 2017 18:21:46 +0000 (UTC)	[thread overview]
Message-ID: <1893359760.2685777.1488219706759@mail.yahoo.com> (raw)
In-Reply-To: <144480689.2460565.1488208393781@mail.yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 5390 bytes --]

Vladimir 'phcoder' Serbinenko wrote:

I reproduced the bug. I'm investigating

>> Apparently finish_boot_services rewrites acpi tables. It's possible to workaround this, possibly by using acpi table protocol. >> But it's certainely not for 2.02 at this point.
Thank you for investigating the issue. Earlier I did a test to check to see if UEFI chainloading was altering ACPI tables. I did this by:
1. performing two grub2 "write_dword" console memory commands to enable ASPM in the ACPI FADT (FACP on my system) table as per http://smackerelofopinion.blogspot.com.au/2011/03/making-sense-of-pcie-aspm.html 

2. then chainloaded from Grub2 to windows: chainloader /efi/Microsoft/Boot/bootmgfw.efi
The ASPM enabling change was there as found by using r-w everything and reported by 'powercfg /energy', indicating the UEFI chainloading isn't, at least for ACPI FADT (FACP), altering the in-memory table.
As the DSDT table is much larger, I can't really write_dword it. Hence asking for some other memory loading module.
As another lead, I found the mentioned finish_boot_services routine in mm.c, quoted below. Would you mind pointing out which code is rewriting the ACPI tables?
Thank you,Nando

---grub_err_t
grub_efi_finish_boot_services (grub_efi_uintn_t *outbuf_size, void *outbuf,
                   grub_efi_uintn_t *map_key,
                   grub_efi_uintn_t *efi_desc_size,
                   grub_efi_uint32_t *efi_desc_version)
{
  grub_efi_boot_services_t *b;
  grub_efi_status_t status;

#if defined (__i386__) || defined (__x86_64__)
  const grub_uint16_t apple[] = { 'A', 'p', 'p', 'l', 'e' };
  int is_apple;

  is_apple = (grub_memcmp (grub_efi_system_table->firmware_vendor,
               apple, sizeof (apple)) == 0);
#endif

  while (1)
    {
      if (grub_efi_get_memory_map (&finish_mmap_size, finish_mmap_buf, &finish_key,
                   &finish_desc_size, &finish_desc_version) < 0)
    return grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");

      if (outbuf && *outbuf_size < finish_mmap_size)
    return grub_error (GRUB_ERR_IO, "memory map buffer is too small");

      finish_mmap_buf = grub_malloc (finish_mmap_size);
      if (!finish_mmap_buf)
    return grub_errno;

      if (grub_efi_get_memory_map (&finish_mmap_size, finish_mmap_buf, &finish_key,
                   &finish_desc_size, &finish_desc_version) <= 0)
    {
      grub_free (finish_mmap_buf);
      return grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
    }

      b = grub_efi_system_table->boot_services;
      status = efi_call_2 (b->exit_boot_services, grub_efi_image_handle,
               finish_key);
      if (status == GRUB_EFI_SUCCESS)
    break;

      if (status != GRUB_EFI_INVALID_PARAMETER)
    {
      grub_free (finish_mmap_buf);
      return grub_error (GRUB_ERR_IO, "couldn't terminate EFI services");
    }

      grub_free (finish_mmap_buf);
      grub_printf ("Trying to terminate EFI services again\n");
    }
  grub_efi_is_finished = 1;
  if (outbuf_size)
    *outbuf_size = finish_mmap_size;
  if (outbuf)
    grub_memcpy (outbuf, finish_mmap_buf, finish_mmap_size);
  if (map_key)
    *map_key = finish_key;
  if (efi_desc_size)
    *efi_desc_size = finish_desc_size;
  if (efi_desc_version)
    *efi_desc_version = finish_desc_version;

#if defined (__i386__) || defined (__x86_64__)
  if (is_apple)
    stop_broadcom ();
#endif

  return GRUB_ERR_NONE;
}


Nando 

    On Tuesday, 28 February 2017, 2:13, Nando Eva <nando4eva@ymail.com> wrote:
 

 Andrei Borzenkov wrote:
>> That's more or less what grub tries to do. We cannot really overwrite
>> ACPI tables because they may be located in read-only memory, but it
>> attempts to create EBDA and place new RSDP there and update EBDA
>> address as well as update RSDP pointer in EFI system table. I would
>> suggest trying to load something else (like Linux) and check whether
>> it sees new or old table.

This user had 'acpi' also fail to replace the FACS ACPI table on Linux:
https://bbs.archlinux.org/viewtopic.php?id=190258 

The DSDT I require is for Win10. Win10 has a registry override method to replace a DSDT but requires test signing mode to do it, along with some app restrictions/incompatibilities. 

I require a pre-boot DSDT override method to overcome Win10 test signing mode AND have my required DSDT table loaded. Just need an in-memory DSDT subsitution tool to do it.  

I have been able to accomplish this using MBR boot because the tools exist. For the more popular UEFI,I have yet to find a load-file-into-memory-location tool to make it possible. Only things are the multiboot file encapsulation, hexedit and write_dword. All not the right fit. 

Any chance the grub-devel team can help out here with either a load-file-to-memory-location module/tool (where I need to find the address) or specifically one that does a in-memory DSDT override by overwriting the existing table? Of course, ppl with read-only memory can't use it just like I imagine would be the case with the current 'acpi' method. 

Thank you,
Nando


   

[-- Attachment #2: Type: text/html, Size: 12528 bytes --]

  reply	other threads:[~2017-02-27 18:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1736729449.4676062.1487865639993.ref@mail.yahoo.com>
2017-02-23 16:00 ` Loading DSDT table using 'acpi' or some memory write command? Nando Eva
2017-02-24 16:32   ` Andrei Borzenkov
2017-02-27 11:29   ` Nando Eva
2017-02-27 13:42     ` Andrei Borzenkov
2017-02-27 15:13       ` Vladimir 'phcoder' Serbinenko
2017-02-27 15:31         ` Vladimir 'phcoder' Serbinenko
2017-02-27 15:13     ` Nando Eva
2017-02-27 18:21       ` Nando Eva [this message]
2017-03-27 14:12         ` Nando Eva
2017-03-27 16:55           ` Andrei Borzenkov
2017-03-29 17:45           ` Nando Eva
2017-03-30  4:03             ` Andrei Borzenkov
2017-04-01  9:09             ` Andrei Borzenkov
2017-04-01 15:24               ` [PATCH] acpi: add missing efi_call wrapper to acpi command Andrei Borzenkov
2017-04-02  8:27                 ` Vladimir 'phcoder' Serbinenko
2017-04-04 18:18               ` [PATCH] acpi: do not attempt to create EBDA on EFI (was: Loading DSDT table using 'acpi' or some memory write command?) Andrei Borzenkov

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=1893359760.2685777.1488219706759@mail.yahoo.com \
    --to=nando4eva@ymail.com \
    --cc=grub-devel@gnu.org \
    /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).