Zitat von HAZArD im Beitrag #15

---

Zitat von lordkag im Beitrag #13

---

@HAZArD

Since I wanted to test the new RAID modules, I modded this for you. Only if it will fail I might look into downgrading to latest working version. You have to understand that most of the work is done in hex and it is also a lot of work to get the fake module to the right size. Here is what I updated:

AHCI = updated from 3.1.0.0 to 3.1.2.0
RAID + MISC.SIG = updated from 3.0.1540.59 to 3.3.1540.11
Realtek Lan = updated from PXE 2.39 to PXE+RPL 2.59
Microcode CPUID 10A0 = updated from 010000BF (17.02.2010) to 010000DC (24.10.2011)

I also have some updates for VBIOS, but they are marked as DDR3, as opposed to yours DDR2.

Please report your findings.

---

uhhhhuuuu that's awesome this afternoon I'll try to flash it Thank a ton lordkag I'll report the results.
Just two things...
- why AHCI = updated from 3.1.0.0 to 3.1.2.0 and not to 3.2.1.0?
- why RAID + MISC.SIG = updated from 3.0.1540.59 to 3.3.1540.11 and not to AMD RAID ROM v3.3.1540.19?

---

@HAZArD

I have mixed the numbers and updated to an older version. So here it is the same BIOS file with AHCI 3.2.1.0 (and a corresponding dummy.bin).
Your board has a 1002-4392 RAID controller, so I provided the latest 3.3.1540.11 for this ID. It was extracted from a Biostar BIOS file and has the needed 4392 ID, but I can't guarantee that they didn't made a mistake when labeling. So please test the RAID function on some spare drives with no important data. If it fails, I will downgrade to 3.2.1540.16

Zitat von lordkag im Beitrag #17

---

@HAZArD

I have mixed the numbers and updated to an older version. So here it is the same BIOS file with AHCI 3.2.1.0 (and a corresponding dummy.bin).
Your board has a 1002-4392 RAID controller, so I provided the latest 3.3.1540.11 for this ID. It was extracted from a Biostar BIOS file and has the needed 4392 ID, but I can't guarantee that they didn't made a mistake when labeling. So please test the RAID function on some spare drives with no important data. If it fails, I will downgrade to 3.2.1540.16

---

ok here we are again even this works fabulously I need to find two hard drive and test them in raid 0 and I'll report the results
allow me one thing lordkag I feel right now that everything will work

Hi lordkag found two hard drives and tested :'( oprom 3.3.1540.11 doesn' work I can' t build the raid across the function it stops with this errror message: "checksum is error for misc.bin please make sure misc.bin file is complete" may U update with the previous rom as U said? Thank U so much man

@HAZArD

There are 3 possible reasons. Biostar mixed the components and added a wrong MISC.SIG in the BIOS file that provided this 3.3.1540.11 (RAID + MISC.SIG). But I checked with other 3.3.1540.11 modules from 1002-4393 and they are not the same as these ones. The second reason could be that these are only for AMI, since they were found in AMI BIOS and they were compressed. But I decompressed the modules before inserting them and added the decompressed MISC.SIG as it is, without the extra padding, which would not have messed the checksum in the first place.

The third reason could be that I haven't cleared the area before adding this (smaller than original) UI750.BIN and some of the extra bytes got counted in this file. Please test the files attached, which have no extra bits of information in the area of misc.bin/MISC.SIG. If you still have the same error, then I will add the previous working ROM - 3.2.1540.15.

Edited: files removed.

Zitat von lordkag im Beitrag #21

---

@HAZArD

There are 3 possible reasons. Biostar mixed the components and added a wrong MISC.SIG in the BIOS file that provided this 3.3.1540.11 (RAID + MISC.SIG). But I checked with other 3.3.1540.11 modules from 1002-4393 and they are not the same as these ones. The second reason could be that these are only for AMI, since they were found in AMI BIOS and they were compressed. But I decompressed the modules before inserting them and added the decompressed MISC.SIG as it is, without the extra padding, which would not have messed the checksum in the first place.

The third reason could be that I haven't cleared the area before adding this (smaller than original) UI750.BIN and some of the extra bytes got counted in this file. Please test the files attached, which have no extra bits of information in the area of misc.bin/MISC.SIG. If you still have the same error, then I will add the previous working ROM - 3.2.1540.15.

---

I have attached more test files. Flash them in order, test RAID and post your findings. The first two are still using 3.3.x, but with a few more bytes, to check some things. If it still fails, then either the MISC.SIG is corrupted or only works for AMI BIOS. The last three are with 3.2.x, but are using different approach to handle the bigger sized MISC.SIG. I will write more after your tests, because I have found some new things that maybe are worth mentioning, but could also be meaningless.

Edited: uploaded final working mod with 3.2.1540.11

Zitat von lordkag im Beitrag #23

---

I have attached more test files. Flash them in order, test RAID and post your findings. The first two are still using 3.3.x, but with a few more bytes, to check some things. If it still fails, then either the MISC.SIG is corrupted or only works for AMI BIOS. The last three are with 3.2.x, but are using different approach to handle the bigger sized MISC.SIG. I will write more after your tests, because I have found some new things that maybe are worth mentioning, but could also be meaningless.

---

@HAZArD

I have found the checksum control byte and uploaded 2 more test files, the last ones. If this still fails, then it needs the misc.bin to be compressed and this only works for AMI, not Award. Test mod6b only if mod6a fails.

I will write tomorrow all the things related to this modding. Please test them as soon as possible, so I can remove all the test files and keep only the working ones, in case someone comes here with the same board. I would keep mod5a or mod5c for 3.2.1540.15 and mod6a for 3.3.1540.11.

Edited: files removed

Zitat von lordkag im Beitrag #25

---

@HAZArD

I have found the checksum control byte and uploaded 2 more test files, the last ones. If this still fails, then it needs the misc.bin to be compressed and this only works for AMI, not Award. Test mod6b only if mod6a fails.

I will write tomorrow all the things related to this modding. Please test them as soon as possible, so I can remove all the test files and keep only the working ones, in case someone comes here with the same board. I would keep mod5a or mod5c for 3.2.1540.15 and mod6a for 3.3.1540.11.

---

It is too bad that this hasn't worked. It appears series 3.3.x was only released for AMI. What I have found working on your BIOS, that could be used with this compelling guide.

The values from the Hole structure table are the base that provide the real value when multiplied with 1000. Example: 0C = C000, 04 = 4000, 10 = 10000, 0E = E000



The BIOS and cbrom don't care about the size of the hole, as long as it fits the module. CBROM will not relocate any bytes if the new module/hole is bigger than original. For instance, in your case you are restricted to F000 bytes for hole2, otherwise you will override the information about hole used space, which starts at 1F000. So the hole2 can only fill 10000-1F000.



Maybe this can be worked around by altering the starting address of the holes, but I wouldn't test this without backup measures. The hole seems to have a checksum byte that is ignored in most cases. So, if you want to do a proper inserting in hole area, do this: release, make sure it fits the hole area - otherwise patch with the new size, double check that the new module will not override other information, fill the hole area with FF (not 00), add the new module with cbrom, correct the checksum as bellow, re-add the new module with cbrom to have all the checksums in place.



Starting with 3.3.x RAID modules, AMD has also added a checksum control for MISC.SIG. For MISC.SIG the 0A offset is used to get the checksum to 00, for main RAID module is the 08 offset. This hasn't been tested yet. The 3.2.1540.15 module seems to have a bad checksum, but I haven't seen anyone complain about that.