enhancement request: setpci.mod to work on PCIe registers (0xfff) - currently limited to PCI registers (0xff)
Hello everybody, As per title, setpci.mod's setpci command can read/write up to 0xFF registers but returns an incorrect (0xFF) value for any registers beyond 0xFF.. There is a 4K PCIe configuration space (0xFFF) per device. eg: setpci -s 0:1f.0 0xf0.l -> returns correct value setpci -s 0:1f.0 0x200.l -> returns 0xff (incorrect) Extending setpci.mod in this way would bring it's functionality in line with EFI Shells 'mm' command that can read/write all 4K PCIe registers, as well as pciutils' setpci command that can do the same. Thank you ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Loading DSDT table using 'acpi' or some memory write command?
> How exactly do you find RSDP? On EFI RSDP should be retrieved from EFI
> Configuration Table, which grub tries to update. Please give as much
> details as possible.
Good point. I can get the RSDP from tools like 'ru.efi' or even with 'r-w
everything'.
However, 'lsacpi' won't tell me the new RSDP address after doing a 'acpi
dsdt.aml'.
Is there anyway of finding it out using the grub shell, or chainloading EFI
shell (or chainload grubx64.efi from EFI shell and exiting in case grub's
chainloading is restoring the ACPI tables)?
> Again - what address are you updating?
>
> We need to understand why it fails first. GRUB *does* attempt to
> override RSDP if it finds it.
On Tuesday, 28 March 2017, 1:12, Nando Eva wrote:
OK, I found the cause if the problem:
- the ACPI tables specified to the 'acpi' command are loaded to new addresses
and a new RSDT and XSDT created with pointers to them. This can be confirmed by
the 'lsacpi' command.
- the RSDP isn't updated to point to the new RSDT and XSDT.
So when chainload the OS, the original RSDT and XSDT are referenced from the
RSDP.
I'm now manually doing the 'acpi [DSDT]' table load, then a 'lsacpi -2' to find
the new RSDT+XSDT addresses and updating the RSDP via two write_dword memory
writes (though not doing checksum correction).
Can a pach be made for grub2 to correct this behaviour to be automated without
such manual intervention?
Thank you,Nando
On Tuesday, 28 February 2017, 5:21, Nando Eva wrote:
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, fin
Re: Loading DSDT table using 'acpi' or some memory write command?
OK, I found the cause if the problem:
- the ACPI tables specified to the 'acpi' command are loaded to new addresses
and a new RSDT and XSDT created with pointers to them. This can be confirmed by
the 'lsacpi' command.
- the RSDP isn't updated to point to the new RSDT and XSDT.
So when chainload the OS, the original RSDT and XSDT are referenced from the
RSDP.
I'm now manually doing the 'acpi [DSDT]' table load, then a 'lsacpi -2' to find
the new RSDT+XSDT addresses and updating the RSDP via two write_dword memory
writes (though not doing checksum correction).
Can a pach be made for grub2 to correct this behaviour to be automated without
such manual intervention?
Thank you,Nando
On Tuesday, 28 February 2017, 5:21, Nando Eva wrote:
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 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 o
Re: Loading DSDT table using 'acpi' or some memory write command?
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 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 th
Re: Loading DSDT table using 'acpi' or some memory write command?
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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Loading DSDT table using 'acpi' or some memory write command?
@Andrei Borzenkov, I've confirmed that any of the following do not alter the Win10 DSDT table across numerous Macbooks and my Dell E6540. acpi dsdt.amlacpi --load-only dsdt dsdt.amlacpi -2 dsdt.aml Followed by: chainloader /efi/Microsoft/Boot/bootmgfw.efi Clover has a DSDT override function and using it works on my Dell E6540. However it does it by writing to the UEFI firmware volume, which for Macbooks, has had one test instance of bricking the system. Any chance of a simple 'load_dsdt [file]' command that acquires the in-memory DSDT table address, checks it's size, then overwrites it with the file name specified if it's the same size or smaller? Or some function to write a file to a memory location like 'write_byte'. Maybe 'write_file'? Thank you,Nando On Friday, 24 February 2017, 3:00, Nando Eva wrote: Hi grub-devel, I'm endeavouring to pre-load a modified DSDT table using grub2. The syntax I've tried being as shown below, after which I chainload to Win10. This being done on a Dell E6540 with Win10 and grub 2.02 (or older.. tried many versions, same result). acpi /efi/dsdt.amlacpi --load-table dsdt /efi/dsdt.amlchainloader /efi/Boot/bootx64.efi Then I do 'acpidump -b' to peruse the DSDT table. In all cases, it remains the same system BIOS one, not my modified /efi/dsdt.aml one. I've also set 'set debug=all' and can see grub2 is reading my modified dsdt file and doing memory writes. So two questions: 1. Is 'acpi' not capable of loading a DSDT table for use with Win10? 2. if that is the case, is there some 'memload' or 'writefromfile' type command where I give a memory address and a file which grub2 can then write? The idea is simply to replace the existing DSDT at it's address with one given by the file of same size or smaller. Thank you,Nando ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Loading DSDT table using 'acpi' or some memory write command?
Hi grub-devel, I'm endeavouring to pre-load a modified DSDT table using grub2. The syntax I've tried being as shown below, after which I chainload to Win10. This being done on a Dell E6540 with Win10 and grub 2.02 (or older.. tried many versions, same result). acpi /efi/dsdt.amlacpi --load-table dsdt /efi/dsdt.amlchainloader /efi/Boot/bootx64.efi Then I do 'acpidump -b' to peruse the DSDT table. In all cases, it remains the same system BIOS one, not my modified /efi/dsdt.aml one. I've also set 'set debug=all' and can see grub2 is reading my modified dsdt file and doing memory writes. So two questions: 1. Is 'acpi' not capable of loading a DSDT table for use with Win10? 2. if that is the case, is there some 'memload' or 'writefromfile' type command where I give a memory address and a file which grub2 can then write? The idea is simply to replace the existing DSDT at it's address with one given by the file of same size or smaller. Thank you,Nando ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: New maintainer. 1.98 release.
Hi Vlad, Have the 'setpci' and "hdparm -X udma5" (set IDE transfer mode) been taken out of patch status and incorporated for release in 1.98? setpci in particularly will be very welcome for various PCI fixups. Regards, Nando 2010/3/2 Vladimir 'φ-coder/phcoder' Serbinenko > Hello, all. First of all I would like to announce that I was appointed > as a co-maintainer of GRUB. > I will release 1.98 in 24 hours. Feel free to update NEWS before then > > -- > Regards > Vladimir 'φ-coder/phcoder' Serbinenko > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Assistance with non-bios found HDD/cdrom booting
Hi Grub team,
I have connected a HDD to my optical drive port and find that Ubuntu can see
and mount that HDD. However, I'd like to be able to boot from it. If I do:
'ls'
-> shows hd0..
'insmod ata_pthru'
'insmod ntfs'
'ls'
-> shows ata0.. + additional partitions
set prefix=(ata0,1)/boot/grub
Problem is the sequence required to boot the Ubuntu or Windows partitions
off the shown ataxx partitions. I understand that Windows may need bios
INT10/INT13 services to boot, but Ubuntu does not. Can anyone list the
command sequence to boot Ubuntu off an ataxx ('insmod ata' or 'insmod
ata_pthru') non bios found IDE device?
I have also tried sbootmgr.dsk finding it sees the devices but upon
selecting the Ubuntu drive/partition off the optical port, it reboots the
system.
Any advice on how this can be done using grub2?
Nando
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Request: hdparm module with -X
Hi Christian, It's great to have hdparm output added. Another fixup that would be needed would be setting the ATAPI cable mode to be 80pin, rather than the slower 40pin. Users who add hard drives in place of PATA optical drives are liked affected. Eg: http://forum.notebookreview.com/showthread.php?p=5519419 (HP 2510P / optical drive caddy) http://www.gottabemobile.com/forum/forum_posts.asp?TID=8260&PID=55271 (Dell XT / not sure why) Comments/suggestions? Nando On Wed, Dec 9, 2009 at 11:17 PM, Christian Franke < christian.fra...@t-online.de> wrote: > Nando wrote: > > > > I was pleasantly surprised when I saw a hdparm module as part of > > grub2. So I tried the -X > > parameter as is provided by the linux command line finding it > > isn't implemented. eg: > > > > # hdparm -X udma5 /dev/sda > > > > Can the development team consider adding this feature? A number of > > ppl's bios is incorrectly setting interfaces to UDMA2/MDMA2, > > particularly on pata optical drive interfaces which users are using a > > 2.5" HDDs instead via an optical bay caddy. The workaround being to > > wait for a (slow) Linux/Windows boot and then typing the above > > commandline. Doing this at the grub2 bootloader level being more > > preferable. > > > > OK, added to my local TODO list :-) > > Please note that GRUB hdparm does only work in conjunction with the > ata+ata_pthru modules because a PC BIOS does not provide any ATA > pass-through functionality. A 'hdparm -X' would only help if the actual > boot works with ata.mod instead of biosdisk.mod. > > -- > Regards, > Christian Franke > > > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Easy grub2 installation for non Linux (Windows) systems?
Hi Christian, Thank you. I'll keep an eye open for the 1.97 Cygwin package. Regards, Nando On Wed, Dec 9, 2009 at 11:45 PM, Christian Franke < christian.fra...@t-online.de> wrote: > Nando wrote: > > For non Linux users, it is possible to load the grub2 package and > > modules on an ntfs filesystem? ... > > > > Yes, GRUB 1.97 builds and runs out-of-the-box on Cygwin. > (Note: requires previous binutils-20080624-2 due to a regression in ld > from binutils-2.19.51-1) > > 1.96 is available as a Cygwin package, 1.97 will be provided when > binutils regression is fixed. > > -- > Regards, > Christian Franke > > > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Easy grub2 installation for non Linux (Windows) systems?
Hi Grub2 Development team, I've worked with a colleague to successfully implement ICHxM SMBUS PLL overclocking using grub2 as described here: http://forum.notebookreview.com/showthread.php?p=5569693 This is great as it means an overclocked CPU state from the bootloader, providing a somewhat universal solution regardless of operating system being used. The module developed 'setfsb.mod' I presume must exist on a Linux partition. For non Linux users, it is possible to load the grub2 package and modules on an ntfs filesystem? If so, is there some easy to follow instructions on how to go about doing that? Nando ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Request: hdparm module with -X
Hi Grub2 Devel team, I was pleasantly surprised when I saw a hdparm module as part of grub2. So I tried the -X parameter as is provided by the linux command line finding it isn't implemented. eg: # hdparm -X udma5 /dev/sda Can the development team consider adding this feature? A number of ppl's bios is incorrectly setting interfaces to UDMA2/MDMA2, particularly on pata optical drive interfaces which users are using a 2.5" HDDs instead via an optical bay caddy. The workaround being to wait for a (slow) Linux/Windows boot and then typing the above commandline. Doing this at the grub2 bootloader level being more preferable. Nando ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] ntldr support
> Agree.
>
> A 'ntldr' or 'chainloader --ntldr' command is not mandatory. But it is
'nice to have' because it allows to boot even if the boot
> code (6 sectors) in the area > behind the PBR is not present for whatever
reason. See my previsions mail with the test case.
>
> --
> Regards,
> Christian Franke
I've just checked the 0.97 release and find the ntldr patch is not
included. What version of grub2 was the original ntldr.diff patch
against??
I would definitely would like to see this implemented. Plenty of ppl
out there with "bootmgr is missing" error messages requiring
Win7/Vista
bootup into recovery console to correct..This solution would rectify
that. Also means could bootup into XP or Win7/Vista with
separate entries in grub.conf, rather than navigating the Vista
bootloader to do it. Eg:
menuentry "XP on /dev/sda1" {
root (hd0,1)
ntldr /ntldr }
menuentry "Win7 on /dev/sda2" {
root (hd0,2)
ntldr /bootmgr }
Nando
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Feature Request: 32-bit mem write and 'setpci -s' type command in menu.lst
Hi Vlad, > able to do the equivalent of setpci by calculating the addresses > > needing memory writes. > Except pciconf space > Are you saying that write_dword will not write to pciconf space? > > > > write_dump ADDRESS FILE > > eg: write_dump 0xF800 dump_file > > > This has already been discussed and conclusion that it's too dangerous > to write to FS from grub2. If it's one time operation you can just boot > FreeDOS for it. IF it's not explain why do you need it on every boot > > I've like *read* a dump file into pciexbar memory space to overcome my wifi whitelisting. Currently doing this via a grub2 DOS Image entry explained at http://www.wimsbios.com/phpBB2/topic9388-135.html#53650 . To have such an ability would mean I could just add another menuitem "Ubunto [reverse whitelisting]" and bypass the need for the DOS bootimage. This ability would be further enhanced if a compressed dump file could be used to speed up the process. So I guess it should be a request for: - 'read_dump ADDRESS FILE' for mPCIe wifi whitelsting could be done within grub2. . - a 'setpci' type command to do pci-e pci-port bridge window fixups, amongst other things. Nando ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Feature Request: 32-bit mem write and 'setpci -s' type command in menu.lst
Hi Vlad, Thank you for this! Just what I was looking for. With pciexbar I'll be able to do the equivalent of setpci by calculating the addresses needing memory writes. Another question - is there any "write_dump" sort of command where I can give an address, a file and it writes the binary data of the file at the starting address up to the EOF marker? Would help overcome my mPCIe whitelisting where i have a DOS workaround in place to do exactly that. I see there is hexdump and dump but neither appear to provide such function. If it doesn't exist, can a request be made to add it? eg: write_dump ADDRESS FILE eg: write_dump 0xF800 dump_file Nando On Thu, Oct 22, 2009 at 10:51 PM, Vladimir 'phcoder' Serbinenko < phco...@gmail.com> wrote: > > write 0xFED93418 0xC330005 > look at write_dword > > > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Feature Request: 32-bit mem write and 'setpci -s' type command in menu.lst
Hi everyone, I wanted to ask if the following features could be added to grub? 1/ Ability to write to 32-bit memory space === I need to set my ICH8M chipset to enable the SMBUS, since the bios disables it. Rather than add the code to the kernel, I'd prefer to do it in grub. Grub4dos has such a facility but no such facility in grub's menu.lst. None that I found anyway. I need to write to following to have access ot my ICS PLL to be able to do overclocking: write 0xFED93418 0xC330005 2/ Ability to do a setpci -s type command == Also, if possible, could a small subset of 'setpci' be incorporated as well? I guess I could figure out the address I need to write to by calculation, but would be nice if I could do the equivalent of the following in grub, associated with a menu entry. This would help the DIY ViDock project that needs to setup PCI Bridge windows prior to Windows load, something that many bios doesn't do, neither does Windows. setpci -s 00:02.0 40l=20 Comments?? Suggestions?? Nando ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
pci-e config register modification in grub
Hi everyone, Wondering if grub2 can have an additional module added to do various pci-e Configuration Register fixups/modifications before launching into XP/Win7/Linux. Specifically I require: 1/ ability to modify PCI Bridge Configuration Registers for DIY ViDock project <http://forum.notebookreview.com/showthread.php?p=5324240> to allow the video card to work [ current workaround is boot DOS, use pcitool to do the mod, then use grub4dos to chainload the OS ] 2/ ability to restore a mini pci-e port's Extended PCI Configuration registers config to reverse HP bios whitelisting of wifi cards (See bottom of HP Mini pci-e wifi bios thread<http://www.wimsbios.com/phpBB2/topic9388-105.html>. No current tool can do this that I've found, with the DOS pcitool extending only to the 00-FF pci-e configuration registers, not the extended registers. I'm running Ubuntu 9.04 with grub as the bootloader. Can these features be added to grub via say the menu.lst file as well as some config file that can store the dump for (2) above?? Nando ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
