| Last online: 04.22.2014
Okay, that file shows the first 1MB and last 1MB trimmed but the data in between (1MB-15MB) returning the old test data. Might be the way the firmware works or a problem with it. If you still have the file on disk you could check if GC has changed any of the remaining blocks.
Zitat von @JSebastian im Beitrag #86
I have checked endless amounts of laptops and desktops... Ranging from low-end up to high-end... UEFI Based and ACPI Based... All brands, sizes and colors...
Don't know if this helps because I am not really sure what you are asking but this is for my MSI GE60 laptop with W8.1
Zitat von Plastixx im Beitrag #1
Is it at all possible to update from ME 188.8.131.525 to ME 8.x? I would like to run an Ivey Bridge CPU with the HM67. Difficulty aside, is this 100% impossible or no?
It has been a long time since I have played with modifying ME7 to ME8 for ASUS P67. Before Ivybridge ASUS had officially stated on the Hardforum ASUS P67 BIOS thread (now strangely removed) that it was impossible to even update ME7 to a later version because of being locked by Intel but that was soon proven to be incorrect. At that time I did get a functioning change from ME7 to ME8 before Ivybridge was released for use with Sandybridge but since ASUS went on to make the modifications for ME8 and SNB/IVB shortly before IVB release there was no need to go further.
IIRC changing just the ME Firmware from 7 to 8 is not enough. The BIOS drivers used for the ME firmware need to be updated too in order for the BIOS to be able to communicate with the ME Firmware. For IVB support there would need to be a lot of modifications to other modules. Microcode itself is not so important, this is just an update to fix errata for the CPU and add or remove special features. Technically the CPU should run without any microcode update, if it halts on lack of it then it is most likely the BIOS refusing to continue rather than the CPU not being able to operate. I have run a desktop and laptop successfully before without any microcode update.
Possibly you could get it working but it will involve a hell of a lot of work and would be extremely time consuming and difficult. Use of an SPI programmer would be a must IMO unless you want to pay exorbitant fees and wait for someone else to fix your broken BIOS.
Here's a >link<
to a mobile QM67 modified from ME7 to ME8 with added IVB support but note that it was done by the manufacturer. ;)
Unless you want to learn from this adventure it would probably be better to sell the HM67 and buy a new laptop.
Zitat von felix im Beitrag #85
Modded bios v1001 for ASUS Rampage Formula ( X48/ICH9R) with
>"Universally TRIM modified" Intel RST RAID ROM v184.108.40.2067 with TRIM in RAID0 support<
Thank you for reporting back felix, appreciate it. Without people such as yourself showing others it can work on older systems it is hard to prove if the hardware is not available for testing. Now any ICH8R users with RAID0 SSD's ;)
@Martin_Q I have modified the original trim program to create a 16MB file. If you have time it would be interesting to see your results. After running the program on your RAID0 drive leave the computer idle for an hour or so still powered up before checking it. I don't know how aggressive your drive firmware is but hopefully that should be plenty of time. If you find it is only partly trimmed, that is some parts still contain the word "Test" then perhaps you would zip it up and post it back. Although it generates a 16MB file it does compress very easily. For instance the original file will double zip to less than 1kB.
EDIT: Unfortunately I'm not going to be able to look at this as going overseas, maybe in a couple of months if your still curious.
That looks better. Perhaps with those drives the trim doesn't work the same as todays drives. For instance with my plextors a trim will unmap the LBA's and any further reads to those LBA's returns data from the a special part of the buffer rather than the flash media. Perhaps your trim enabled firmware does not work as efficiently and some time is needed for GC to actually go ahead and clean up.
This could possibly be tested by using a bigger file, say 1 or 2MB, trimming and leaving the computer idle for some time.
The second program does not use a txtfile, it just checks the trim function on sectors 48-55 which are normally not used by the OS and are outside the filesystem. However some special software may use these, niche bootloaders for instance, so best to make sure they are free before deciding to attempt trimming them or back them up and restore after the test. If checked with a disk editor they are usually just zero's when not used. You could also use the disk editor to put some other values there if a visual indication of trim is required and trim returns zero's.
The first program which used a textfile would normally not show the word "Test" after successful trim.
This is not the same as the file one which was a file test. This one is a disk test. Post #29
Results can be confusing as Windows tends to cache reads from disks so if it has a copy in cache and you trim it may read from the cache instead of the disk. Did you try Send4kTrim?
Zitat von Martin_Q im Beitrag #30
I don't know why it didn't work earlier, because I think I already tested old ROM-new RST)...
Trim can be strange sometimes. Good to hear you have some success from your perseverance.
Zitat von Martin_Q im Beitrag #28
"The operation has completed successfully". What does that mean ?
It means the operation was accepted by the driver but if you are using 11.5+ RST the filter driver iastorF will report that even if trim failed unlike 11.2. Going by the time it took to complete I would say it was probably unsuccessful. Normally the text file would not show "test" if trim were successful.
This program may be a bit more definitive and can be run from any disk as all OS disks are tested. However, it is hard coded to sectors 48 to 55 which are normally in "no man's land" and not so check if that's the case first.
Would you try the following program placed somewhere on your RAID0 drive. It will write a file "TrimTest01.txt" the size of one cluster (usually 4kB) and trim it without deletion. The file contains the word "Test" repeated.
Note that this is just a rough test to try and see what is going on, possibly buggy, and not intended as a fully fledged trim tester.
Zitat von Martin_Q im Beitrag #23
but trim is still not working :-(
Thank you for the SS Martin.
So why does trim not work? The problem is not with the OROM, this just provides a feature bit to the OS driver (RST) and ultimately the RST driver is responsible for passing on the trim command. The only things that I could think of are possibly...
1. The driver is specifically blocking on ICH9R.
2. The DisableDeleteNotify is not set to 0 in the OS
3. The updated SSD firmware doesn't work as expected. Not sure if this was actually tested in 2010 due to people not having the tools. Possibly trim is not deterministic and is working but still returning the old data until GC kicks in.
Number 2 is easy to check, I'll see if I can come up with a method for 1 and 3.
Zitat von Martin_Q im Beitrag #17
Is there any possibility to check the Firmware Version within the RAID array ?
You could try HWInfo32 or CrystalDiskInfo.
Thank you for trying that Martin. If you are not understandably fed up by now I would like to know which SSD's you are using.
Probably a good idea. It is an old board but FWIW I tried 12.9 RST on the EP45 (ICH10R) and trim still worked with 8.0 OROM. Only strange thing I noticed is that 12.9 now reports the OROM version and ASU doesn't ! Opposite of RST 11.2.
I could see how the message from ASU could be misinterpreted into thinking that trim does not work on any drives.
@Martin_Q I would not rely on ASU for trim testing, try trimcheck instead. After first run wait 30 seconds then run again, if negative try either reboot or a quick disk check without fixes.
Edit: I just downloaded ASU and this is what I get.
Is this the message you are referring too? That just means that "some drives" may not respond as you can see in my own test bottom right which doesn't trigger trim but actually sends the command, the WDC HDD and Sandisk USB Flash do not support sending trim. Note that ASU reports OROM version but RST 11.2 does not. 0.0.0.0
Regarding installation of W7, did you copy the files from the DVD to the USB drive? Might be worth downloading the ISO from digitalriver (MS agent) and try again.
Possibly your BIOS can not deal with loading OROMs that are larger than 64k into memory.
Here's a modded 8.0 you could try. Note that these older ROMs seem a bit more finicky with checksum so added csum correction at end of file padding. I just did a quick test on P45 and seems okay with 11.2 driver. The RAID0 array was not the boot disk so that I have not tried.
Perhaps when there's no help in using the larger OROM then just have to settle for the smaller older trim enabled OROM.
Attached 10.1 OROM trim enabled.