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 --]
next prev parent 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).