Jump to content











Photo
- - - - -

Grub4DOS AHCI / NVMe speed patch for memory maps

grub4dos ahci nvme

  • Please log in to reply
11 replies to this topic

#1 schtrom

schtrom

    Newbie

  • Members
  • 14 posts
  •  
    Germany

Posted 27 October 2018 - 03:36 PM

Download-Link: sourceforge.net/projects/grub4dosahcipatch

 

Grub4DOS AHCI / NVMe speed patch for memory maps

This package includes the following directories:
- bin -> compiled grldr version 0.4.5c with AHCI / NVMe support
- patch -> ahcinvme.patch for updating stock grub 0.4.5c source code
- src -> all changed and additional source code files used with grub 0.4.5c

The AHCI and NVMe support can be enabled by using the additional grub menu commands "ahci"
and "nvme". We can set the following parameters with the new commands:

ahci --set-drive=DRIVE --set-controller=CONTR --set-port=PORT [--showall] [--showselected]
nvme --set-drive=DRIVE --set-controller=CONTR [--showall] [--showselected]

Using these commands searches PCI configuration space for all present AHCI / NVMe controllers.
After setting this option every read to DRIVE is redirected to the selected AHCI / NVMe
controller. The CONTR and PORT arguments start at zero, where 0 corresponds to the 1st present
AHCI / NVMe controller / port found. If the option --showall is used, all AHCI / NVMe
controllers, ports and connected devices are displayed. If the option --showselected is used,
the selected AHCI / NVMe controller, port and connected device is displayed. The argument
--uninit uninitializes all AHCI / NVMe controllers. This command was implemented to speed up
transfer rates if an image file is loaded from an AHCI / NVMe SSD and mapped to RAM.

The AHCI / NVMe support can not be disabled anymore during compile with the configure command.
We removed this feature to make the code simpler.

The standard read block size is now always 32 MB, because this is the maximum data transfer
size we can get from an AHCI hard disk device at issuing one read command. If an image file
is mapped to RAM we get a speed of 550 MB/s with a Samsung 840 Pro SSD and 3 GB/s for a
Samsung 960 EVO NVMe SSD.

Pay attention that this AHCI / NVMe addition is only useful if you load the images from SSD to RAM.
Loading a disk image directly or using a normal platter HDD does not increase the read speed much.
Use this patch with care on your own risk!

Because we added some parameters to the AHCI and NVMe command line we wanna show you two sample
menu entries for both RAM disk mappings:

title Win10 - RAMDISK AHCI
ahci --set-drive=0x80 --set-controller=0 --set-port=0 --showselected
find --set-root --ignore-floppies /win10.vhd
map --mem /win10.vhd (hd0)
map --hook
ahci --uninit
root (hd0,0)
chainloader /bootmgr

title Win10 - RAMDISK NVMe
nvme --set-drive=0x80 --set-controller=0 --showselected
find --set-root --ignore-floppies /win10.vhd
map --mem /win10.vhd (hd0)
map --hook
nvme --uninit
root (hd0,0)
chainloader /bootmgr

You should always include the new "--uninit" parameter directly after the "map --hook" command.
This stops the redirection of drive 0x80 (hd0) to the AHCI / NVMe read procedure. The drive
number should always match the real BIOS drive number for the system, otherwise the system may
hang.

Many thanks to all the developers and forum members of reboot pro for making it possible to boot
a full-sized Windows from RAM and harddisk image.

Greets
Kai Schtrom


  • ReTokener likes this

#2 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 147 posts

Posted 27 October 2018 - 07:08 PM

Hi Kai

Previous version was very good, thanks for sharing this new build.

I´m going test it in the next days.

 

 Regards   T.



#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14520 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 28 October 2018 - 05:58 PM

Good.news. :)

 

Only to confirm how grumpy and old I am, and for the record, there is however NO such thing as grub4dos 0.4.5c.

 

There are a zillion versions of 0.4.5c (105 of them on Chenall's site) of which the latest is 0.4.5c-2016-01-18.

 

If this is the patched one (I seem not being able to understand which version it is, all I can find is "GRUB4DOS 0.4.5c 2018-10-27" which is fine, because of the recompiling after the patch), it would be IMHO a good thing to specify which exact version as before or later there would be some mixup of versions (as an example since the patched one has only grldr and not grub.exe).

 

:duff:

Wonko



#4 schtrom

schtrom

    Newbie

  • Members
  • 14 posts
  •  
    Germany

Posted 10 November 2018 - 08:04 AM

Hi Wonko,

 

you are right we are both old and grumpy! The Grub4Dos 0.4.5c versioning is a mess. Therefore I uploaded my code base of Grub4Dos 0.4.5c to sourceforge. At the past I used the SVN repository with revision number 359 to download the base sources. This source code base is contained in the archive named

 

grub4dos_0.4.5c_svn_revision_359_source.rar.

 

It was downloaded some time ago with the following SVN command:

svn co -r 359 http://grub4dos-chen...e.com/svn/trunkgrub4dos

 

The SVN repository with revision number 359 is no longer present, therefore I uploaded it to make building your own GRUB4DOS loader based on my patches easier.

 

I hope this helps someone!



#5 Sinity

Sinity
  • Members
  • 4 posts
  •  
    Poland

Posted A week ago

Hi. I've got a problem with this patch - in your example, you use 'find' command after switching to nvme. When I do that, grub4dos either hangs or there's a reboot. Grub4dos also hangs on 'ls' command, or even typing '(' and then tab. When I run nvme command with '-showselected' option, it seems to correctly detect the controller & drive(samsung 960 evo).

 

I'm trying to use it to boot windows 10 after kexec - unfortunately interrupt 13h doesn't work after that.

 

Only thing that works so far is having windows 10 partition on another, non-nvme ssd. Then I kexec grub.exe(grub4dos, unpatched), with bootable grub2 in initramfs, and chainload that grub2. Then, I use 'nativedisk' command in grub2 which gives me access to all hdd's and ssd's except nvme. I set root&prefix variables to a partition which has your patched 'grldr' file, and I run "ntldr /grldr".

 

At this point, if Windows 10 is on non-nvme partition, I can map that to (hd0), run "root (hd0,0)", and run "chainloader /bootmgr", "boot". And that works.

 

I've also tried to install only windows bootloader on non-nvme partition, and after mapping that partition as (hd0,0) it can read BCD files and such; but it fails on loading /Windows/system32/winloader.exe.

 

I've also found info that this change in linux: https://git.kernel.o...0ca907e50a53d41 is what causes int 13h to fail. But after commenting out code which does that, it still doesn't work.

 

Any ideas how to get it to work?

 

Maybe problem is that after 'nvme' command grub4dos tries to read... something from non-nvme drive? But grldr is just a single binary, so it should be in ram.

 

Also, it's not because if kexec - if I run patched grub4dos from grub2 after a reboot, it also causes hang or reboot. I've also tried putting grldr onto nvme ssd, rebooting, chainloading that and then running nvme command & find. Also causes reboot.


Edited by Sinity, A week ago.


#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14520 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

NOT at all what you asked, but it doesn't seem to me that the "find" is needed at all.

What happens with (i am assuming that the win10.vhd is on (hd0,0)):

 

nvme --set-drive=0x80 --set-controller=0 --showselected
map --mem (hd0,0)/win10.vhd (hd0)
map --hook
nvme --uninit
root (hd0,0)
chainloader /bootmgr

 

:duff:

Wonko



#7 Sinity

Sinity
  • Members
  • 4 posts
  •  
    Poland

Posted A week ago

I don't have Windows image (*.vhd), it's just Windows installed onto a partition. I'm not sure how to apply this example for my situation. Maybe I'd try rootnoverify (hd0,0) directly after "nvme -set-drive=0x80...." command, or run "nvme --uninit" between "nvme..." and "rootnoverify"?

 

I will try it.

 

Edit: I've tried it, didn't work :(

 

Here's what I did exactly, to maximize chances of success:

 

1. I've copied grldr directly onto the same nvme partition as Windows I'm trying to boot

2. I've rebooted.

3. From grub2(which is also on the same nvme partition), I've ran just insmod fat, insmod ntfs, ntldr /grldr, boot.

4. In Grub4Dos, I've tried:

   a) "nvme --set-drive=0x80 --set-controller=0 --showselected", "nvme --uninit", "rootnoverify (hd0,0)", "chainloader /bootmgr"

   b ) "nvme --set-drive=0x80 --set-controller=0 --showselected", "nvme --uninit", "rootnoverify (hd0,0)", "chainloader /bootmgr"

 

 

Result from a): read error 25 or something like that.

Result from b ): reboot directly after running "chainloader /bootmgr".

 

 

I've also tried to enable debugging; only thing of note is that after initializing nvme '(' + tab caused many messages to appear(too many to fit the screen). Something about mismatch between sector count of BIOS and actual sector count, drive geometry etc. These errors also showed after "nvme --uninit".


Edited by Sinity, A week ago.


#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14520 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

Then I don't get it (really I don't get it :frusty: ).

 

The nvme patch is intended to make the loading to RAM faster.

 

If you are NOT loading to RAM it makes no sense whatsoever to use it, just use "normal" grub4dos.

 

The generic  idea is AFAICU:

1) open a "special", "faster", "temporary" channel between nvme and RAM

2) copy (faster) from nvme to RAM

3) close the channel and resume normal operation

 

For *some reasons* in your particular setup the opening (or closing, or both) of this "privileged channel" doesn't work properly, but since you are not copying anything to RAM, you simply don't *need* it.

 

Or am I missing (or you are not telling) something? :dubbio:

 

:duff:

Wonko



#9 Sinity

Sinity
  • Members
  • 4 posts
  •  
    Poland

Posted A week ago

I understand that this patch is intended to do something else, but I'm trying to use it as a nvme driver - an int 13h replacement. Essentially the same thing as grub2's "nativedisk" command - which works for AHCI. Unfortunately grub2 doesn't have nvme driver.

 

"normal" Grub4Dos doesn't work - if I boot it via kexec, then it doesn't detect any drives. Because int 13h doesn't work.

 

I think it is supposed to work. I will try to compile it with some additional logging, to see where it fails.



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14520 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

I understand that this patch is intended to do something else, but I'm trying to use it as a nvme driver - an int 13h replacement. Essentially the same thing as grub2's "nativedisk" command - which works for AHCI. Unfortunately grub2 doesn't have nvme driver.

 

"normal" Grub4Dos doesn't work - if I boot it via kexec, then it doesn't detect any drives. Because int 13h doesn't work.

 

I think it is supposed to work. I will try to compile it with some additional logging, to see where it fails.

Yep, but It is not that it is intended to do something else, it is that it only does something else, which actually prevents its use as a nvme driver, from what I understand, the sheer moment you --uninit it, the nvme loses *everything*.

 

If - for whatever reasons - your kexec kills int 13h (or more loosely BIOS interrupts/services) then grub4dos simply won't work (as it relies on int13h or more loosely on BIOS interrupts/services).

 

In the old times kexec did work by using a passed configfile directive to grub.exe:

http://reboot.pro/to...-kexecgrub4dos/

 

but it may also depend on specific motherboard/BIOS:

http://reboot.pro/to...hat-runs-win10/

 

:duff:

Wonko

 

P.S.: tinybit did start something about the matter, but it wasn't ever followed/it never evolved, so it is a JFYI:

http://reboot.pro/to...exec-l-grubexe/



#11 Sinity

Sinity
  • Members
  • 4 posts
  •  
    Poland

Posted A week ago

Yes, it couldn't work with --uninit. But without uniniting, from the description, it seems like it should just replace the int 13h - like for example grub2's nativedisk.

 

I've noticed that ls (hd0, 3)/ works correctly. Which is my Windows system partition. So I've installed windows bootloader onto that, and I was even able to run chainloader /bootmgr. But after boot it just rebooted my PC. So I think that maybe it doesn't really replace int 13h - just replaces calls to int 13h inside grub4dos itself. Or windows boot loader tries to access partition 0 for some reason.

 

Anyway, I think I've confused myself during all these tests - "nvme" always fails after kexec, grub4dos immediately hangs after issuing it even without any parameters. I thought it worked, but apparently not.

 

I think the only reasonable solutions are somehow patching int 13h so it doesn't fail after kexec, or writing nvme driver for grub2 :(



#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14520 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

If you can "reach" (hd0,3) but the bootmgr in it fails, you may try to use a "Vista boot floppy", i.e. a floppy image containing BOOTMGR and the \boot\BCD that you can store on (hd0,3) and map --mem.

Maybe it works. :unsure:, since it can "find itself" and when the BOOTMGR switches to protected mode and re-enumerates the devices it may find the actual Windows install volume.

 

Anyway, you are also using an additional layer that is GRUB2, which may (or may not) complicate the matter.

 

It is not clear to me if you actually tested exactly the methods in the posts I linked to (that again may or may not work) :unsure:.

 

The only reasonable solution is IMHO to correct the kexec so that it works as it should (and as it used to work, as said).

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users