02-07-2013, 08:13 PM
Wotcher chaps, first post hope I've put it in the right place...
I am experimenting with a couple of AMI BIOSes which are causing me difficulties because they have multiple modules with the same ID (0xE1), and AMIMMWIN, MMTOOL and so forth do not like this.
Extracting the modules I seem to be OK with since I can just copy the relevant chunk out of the BIOS image by hand using "cat foo.rom | tail -c +(start position + 1) | head -c (length)".
It's re-inserting them that is the problem since the tools only seem to allow me to insert the first one. On trying to insert the second, they complain that the module already exists in the BIOS image and there seems to be no way to specify that this is not a problem in this instance.
With option ROM modules (ID 0x20) or language modules (ID 0x21) they are distinguished from each other by their vendor:device IDs or country code:flags values. These ID 0xE1 modules, however, do not have such things, the segment:offset values are shown as 0 in all cases.
So, firstly, is there some incantation to persuade the tools to stop complaining? I can't find any such in the documentation or on Google.
If not, how about putting the modules in by hand? I can't find the format documented anywhere either. Does the BIOS simply scan through all the modules using data in the modules themselves to identify where each one starts and ends, in which case I could more or less just reverse my extraction method, or is there a table of start addresses or something which needs to be updated as well?
Or is my best bet likely to be something like hacking the binaries of the tools to disable the duplicate-module check?
Please don't suggest anything too Windows-specific as I am on Linux and am running the tools under wine (so I have the problem that most versions of them crash under wine on top of the problem of random BIOS corruption from the horrendous bugginess of the tools themselves... is this rubbish really what professional motherboard engineers make BIOSes with?) On the other hand I am not worried about flashing a dud image since I have a standalone programmer, so I can recover, it's just highly inconvenient because the programmer runs off the parallel port so is horribly slow).
Thanks in advance...
I am experimenting with a couple of AMI BIOSes which are causing me difficulties because they have multiple modules with the same ID (0xE1), and AMIMMWIN, MMTOOL and so forth do not like this.
Extracting the modules I seem to be OK with since I can just copy the relevant chunk out of the BIOS image by hand using "cat foo.rom | tail -c +(start position + 1) | head -c (length)".
It's re-inserting them that is the problem since the tools only seem to allow me to insert the first one. On trying to insert the second, they complain that the module already exists in the BIOS image and there seems to be no way to specify that this is not a problem in this instance.
With option ROM modules (ID 0x20) or language modules (ID 0x21) they are distinguished from each other by their vendor:device IDs or country code:flags values. These ID 0xE1 modules, however, do not have such things, the segment:offset values are shown as 0 in all cases.
So, firstly, is there some incantation to persuade the tools to stop complaining? I can't find any such in the documentation or on Google.
If not, how about putting the modules in by hand? I can't find the format documented anywhere either. Does the BIOS simply scan through all the modules using data in the modules themselves to identify where each one starts and ends, in which case I could more or less just reverse my extraction method, or is there a table of start addresses or something which needs to be updated as well?
Or is my best bet likely to be something like hacking the binaries of the tools to disable the duplicate-module check?
Please don't suggest anything too Windows-specific as I am on Linux and am running the tools under wine (so I have the problem that most versions of them crash under wine on top of the problem of random BIOS corruption from the horrendous bugginess of the tools themselves... is this rubbish really what professional motherboard engineers make BIOSes with?) On the other hand I am not worried about flashing a dud image since I have a standalone programmer, so I can recover, it's just highly inconvenient because the programmer runs off the parallel port so is horribly slow).
Thanks in advance...