Jump to content











Photo
- - - - -

Grub4DOS AHCI speed patch for memory maps

grub4dos ahci support patch

  • Please log in to reply
10 replies to this topic

#1 schtrom

schtrom

    Newbie

  • Members
  • 20 posts
  •  
    Germany

Posted 13 October 2013 - 07:16 AM

Download-Link: sourceforge.net/projects/grub4dosahcipatch

 

First many thanks to AHCI OSDev Wiki which helped me a lot to develop this patch. Keep in mind
that I am a noob when it comes down to coding and I need much assistance by code reuse. So try
not to laugh by looking at my sources. Better try to improve them!

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

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

Using this command searches PCI configuration space for all present AHCI controllers and
implemented ports. After setting this option every read to drive 0x80 with a block size of 32 MB
is redirected to the selected AHCI controller and port. This can speed up transfer rates if an
image file is mapped to RAM and may be loaded from an SSD. This option transfers a 32 MB block
per read command by using the ATA command READ DMA EXT. CONTR and PORT arguments start at zero,
where 0 corresponds to the 1st present AHCI controller / port found. If the option --showall is
used all AHCI controllers, ports and connected devices are displayed. If the option --showselected
is used the selected AHCI controller, port and connected device is displayed.

The AHCI support can be disabled during compile by using the configure command with the parameter
"--disable-ahci".

I increased the read block size from 8 MB to 32 MB, because this is the maximum data transfer size
we can get from an AHCI harddisk device at issuing one read command. This way we can read 65536
sectors at once. This patch was tested with a SSD connected to a SATA 300 motherboard. The normal
standard BIOS read took around 50 seconds when reading 3.5 GB to RAM with mem map. When using the
AHCI patch the same file from the same SSD was mapped to memory in around 12 seconds. I think SATA
600 should give even better results.

Pay attention that this AHCI 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, there was no extensive testing!

Another note to the maintainers of the Grub4DOS project namely tinybit and chenall. If you think
the AHCI support is worth being implemented into the productive code, feel free to include it in
any future builds. I am not sure how many users have the need for an AHCI patch at all. Keep up
the good work on the loader!

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. WinvBlock and Firadisk are working like a charm!

Greets
Kai Schtrom


Edited by schtrom, 13 October 2013 - 07:18 AM.


#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 October 2013 - 09:22 AM

schtrom,

first thing hallo and welcome.

Please add somewhere the EXACT version of grub4dos you used as "base".

There are several versions of 0.4.5c, distinguished by a code date, example: grub4dos-0.4.5c-2013-07-24 is "latest" one, grub4dos-0.4.5c-2013-03-03 is last "Featured" one.

 

:cheers:

Wonko



#3 schtrom

schtrom

    Newbie

  • Members
  • 20 posts
  •  
    Germany

Posted 13 October 2013 - 09:33 AM

I downloaded revision 359 of chenall's grub4dos over svn and modified it, but I think it should also work with a newer revision.



#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 October 2013 - 09:44 AM

I downloaded revision 359 of chenall's grub4dos over svn and modified it, but I think it should also work with a newer revision.

Ah, well, then there isn't AFAIK a way to "match" it to a release :ph34r:.

Let's hope that Chenall (or tinybit or Roytam, etc.) will see this thread and add your thingy to the "main" code.

 

:cheers:

Wonko



#5 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 16 October 2013 - 08:04 AM

Good work.

 

I have noticed the grub4dos system functions grub_malloc and grub_free are called. But, in my view, both functions have potential problems and need a rewrite, and the grub4dos system need a better design. I mean someone(the developer of the team or anyone else) should do those "system" work first, and then we could use the system relievedly.



#6 schtrom

schtrom

    Newbie

  • Members
  • 20 posts
  •  
    Germany

Posted 19 October 2013 - 03:31 PM

Yeah I was also unsure of all the strange grub_malloc stuff. I really don't know if they calculate the complete free memory shown at the loader screen with the help of the grub_malloc function. So if I reserve 32 MB static memory instead of 8 where this is "placed" in RAM. Btw I uploaded a new version dated 14/10/2013 to sourceforge. This may fix some problems. I changed the AhciInit a bit to not intefere with the INT13 calls.

 

Thanks for looking into the code!



#7 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 19 October 2013 - 06:27 PM

Dear schtrom

Thank you for this new version.  :thumbsup:  

It rocks!!

1gb image (ima or vhd file format) loaded within seconds.

Tested on Intel AHCI controller.

 

Very good patch for RAM loaders.  :clapping:

For me this worked:

-added a line in menu.lst to load ahci on the fly.

(my bootdrive is the hdd on controller#0 port#4)

 

 

title FIRADISK-XP 1302 ima - Memory mapped \n AHCI - USB3

ahci --set-controller=0 --set-port=4 --showall --showselected

find --set-root --ignore-floppies /FIRA_1302.ima

map --mem /FIRA_1302.ima (hd0)

map --hook

root (hd0,0)

chainloader /ntldr

 

Serious T.



#8 schtrom

schtrom

    Newbie

  • Members
  • 20 posts
  •  
    Germany

Posted 23 February 2014 - 09:49 AM

New version V1.2 uploaded!

 

Changes V1.2

--------------------
- AMD AHCI controller hang at identify device command
  For some if not all AMD AHCI controllers the identify device command hangs the controller if the
  data byte count of the PRDT is equal to the real transfer size of 0x200. We should set this field
  always one less than the transfer byte count. For identify device command we now use 0x1FF as PRDT
  data byte count.


  • Tokener likes this

#9 schtrom

schtrom

    Newbie

  • Members
  • 20 posts
  •  
    Germany

Posted 01 June 2014 - 09:23 AM

New version V1.3 uploaded!

 

Changes V1.3
--------------------

- HP Intel AHCI controller hang at device enumeration
  For some Intel AHCI controllers on HP machines the controller hangs at device enumeration. We restructered the AHCI code

  completely based on Microsoft's StorAhci StorPort Miniport Driver. The device detection and controller interaction should now

  work better than in previous versions.
- Grub4Dos AHCI manual command mode changed
  It is now possible to view the AHCI controller and the connected devices in manual command mode without entering the

  arguments "--set-controller" and "--set-port". You can enter the single argument "--showall" to see on which controller or port

  a HDD is connected.


  • Tokener likes this

#10 L A M A

L A M A

    Silver Member

  • Advanced user
  • 540 posts
  •  
    United Nations

Posted 26 June 2014 - 09:05 PM

Hi :) I've been in contact with "Yann Collet" (developer of lz4 algorithm). In our exchange of words, he mentioned...

A quick look at the karyonix's lzma source code shows that it is a relatively complex piece of code, even at interface level. lz4 should dramatically simplify this situation.

Nonetheless, even if lz4 can be called easily, the problem is that the real code to adapt is the caller code. And that's the part where I, or any other developer, would need guidance. There is basically no way to guess that part from the outside. An insider knowledge is required.

so, I've invited him to THIS thread (IMHO, this appears to be the right thread). If he shows up, I hope you all welcome him here...

edit:

I had a rough time lately, with a public assault on LZ4 security, which I now have to fight and debunk on the communication front. This is likely to hamper my ability to get some free time within the next few days. I'll see what I can do when I get out of this situation.

http://fastcompressi...d-bug-myth.html

#11 sixcentgeorge

sixcentgeorge

    Frequent Member

  • Advanced user
  • 191 posts
  •  
    France

Posted 22 August 2014 - 05:20 PM

i wonder if you also updated the gzip support ? i mean that grub4dos can only use gzipped files that are smaller than 4 Go ...

that would help for some use of smaller usb sticks [ that are never enough big ...;{ ] that need less power than big sized ...

[my 8 Go use only 100mA , the 16-32 200 mA ....i have a stick made for wintogo with 64 Go that consumes 500mA....]






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users