I would like to replace build in dsdt table with my own. I need guide how to do it right way. I have modified dsdt.aml Any good soul willing to help me with that. I have try to do it with PhoenixTool and mmtool. mmtool dont wanna replace my modified AmiBoardinfo ffs with an error,even when i change a single byte using hexeditor. phoenixtool gave me a brick with a black screen and no post after replacing original file wich contains dsdt table with my modified. i dont know what i am doing wrong I dont wanna to someone do it for me but wanna to learn how to do it with phoenixtool. thx!
in phoenix tool click advanced then click dsdt options. check box allow user modify dsdt. add slic and it will let u change dsdt in DUMP folder of bios folder. if u add dsdt that doesnt work properly with windows it wont let u use some devices possibly. might have to add code if _OSI windows 2009 return this values for windows 2009 aka windows 7 else osx return code instead.
Sry man but i dont get dsdt in dump folder never. I only have module thats contains dsdt and its called 9F3A0016-AE55-4288-829D-D22FD344C347_1_47.rom When i hexedit this file then i get black screen after flashing this kind of bios. I have some success with changing dsdt like this but only when my new dsdt its same size like old one. i would like to insert much smaller from my first post. Could u plz try to do it for me since i have failed more than 10 times... main problem with this as i see it its that phoenixtool change 9F3A0016-AE55-4288-829D-D22FD344C347_1_47.rom after my edits with own or something ? This file become totally diferent from what i make....
ahh i see why its not workign. needs to be done from Structure button. decompress extracted the module and im able to see the dsdt... just not sure of the ending (might need original dsdt.aml extracted to see end) Code: B_PCI0LPCBSIOWh.....÷øôæ’I²Gƒ.….t^J#¶s."Ûk.D„.¹t±.aš.ÿ......³.è|×KyF‡¨¨ØÞå.+..W*fIöG‹†ó.Aó/.Lò9wדÔ.š:..'?ÁMÿÿÿÿ....... DEBUG BUFFER OVERFLOW!!!........€.Ñ’oI•M¾~.tˆ8+.............................EFI_LOAD_ERROR...........EFI_INVALID_PARAMETER....EFI_UNSUPPORTED..........EFI_BAD_BUFFER_SIZE......EFI_BUFFER_TOO_SMALL.....EFI_NOT_READY............EFI_DEVICE_ERROR.........EFI_WRITE_PROTECTED......EFI_OUT_OF_RESOURCES.....EFI_VOLUME_CORRUPTED.....EFI_VOLUME_FULL..........EFI_NO_MEDIA.............EFI_MEDIA_CHANGED........EFI_NOT_FOUND............EFI_ACCESS_DENIED........EFI_NO_RESPONSE..........EFI_NO_MAPPING...........EFI_TIMEOUT..............EFI_NOT_STARTED..........EFI_ALREADY_STARTED......EFI_ABORTED..............EFI_ICMP_ERROR...........EFI_TFTP_ERROR...........EFI_PROTOCOL_ERROR.......EFI_INCOMPATIBLE_VERSION.EFI_SECURITY_VIOLATION...EFI_CRC_ERROR............EFI_END_OF_MEDIA.........EFI_UNDEFINED_29.........EFI_UNDEFINED_30.........EFI_END_OF_FILE..........EFI_INVALID_LANGUAGE.....EFI_COMPROMISED_DATA............EFI_INTERRUPT_PENDING....EFI_REQUEST_UNLOAD_IMAGE.EFI_NOT_AVAILABLE_YET.........EFI_DBE_EOF..............EFI_DBE_BOF............................EFI_WARN_UNKNOWN_GLYPH....EFI_WARN_DELETE_FAILURE...EFI_WARN_WRITE_FAILURE....EFI_WARN_BUFFER_TOO_SMALL.ˆ..€....EFI_WARN_INTERRUPT_SOURCE_PENDING..EFI_WARN_INTERRUPT_SOURCE_QUIESCED...Status Code.............˜..€....€..€......*ÿ......*ÿ................,...¡1.[b•Ò.Ž?.*Éir;........................................................................................................................................................................À©...À......8¤*¤¨¤......ñ...÷øôæ’I²Gƒ.….t^J#$PIR..Ò..........................øixÜcxÜbxÜ`xÜ...*`xÜ............èkxÜcxÜ`xÜbxÜ...Ð`xÜixÜbxÜcxÜ...ØjxÜ............°`xÜcxÜbxÜaxÜ...à`xÜaxÜbxÜcxÜ....`xÜaxÜbxÜcxÜ!...axÜbxÜcxÜ`xÜ"...bxÜcxÜ`xÜaxÜ....cxÜ`xÜaxÜbxÜ....`xÜaxÜbxÜcxÜ....axÜbxÜcxÜ`xÜ....bxÜcxÜ`xÜaxÜ....cxÜ`xÜaxÜbxÜ....cxÜbxÜ`xÜhxÜ....`xÜaxÜbxÜcxÜ...0cxÜ`xÜaxÜbxÜ....`xÜaxÜbxÜcxÜ....axÜbxÜcxÜ`xÜ....bxÜcxÜ`xÜaxÜ....cxÜ`xÜaxÜbxÜ....`xÜ............ `xÜaxÜbxÜcxÜ.. .`xÜ.........!...`xÜaxÜbxÜcxÜ...ÈhxÜ...........¸Þ..............$XLT‘....ðÿPCI1....àÿRP01....áÿRP02....âÿRP03....ãÿRP04....äÿRP05....åÿRP06....æÿRP07....çÿRP08....ÿPCI0.....ÿPEG0.....ÿPEG1.....ÿPEG2....0ÿPEG3................$AIR..I................................................................................................................................................................................................................................................................................................. .......................................$APD....Àþ..........A.m.i.B.o.a.r.d.I.n.f.o..... anyways theres a replace button there u can replace the module with the modded module of dsdt. then check the box to compress inserted/replaced module. (but i get some error with jit compiler bla bla.. andyp might be of help) im not 100% sure of this one because all dsdt mods ive done are non EFI
i post start and end in this topic already. i already try this method before but have same jit error as you.
Could you retry with 2.16 If still fails post a screenshot, instructions of what you were doing exactly, and the relevant BIOSes/modules I need to reproduce. Thanks Andy
This won't fix the error, but make Phoenixtool to perform what you want. Load the EFI, choose manufacturer: other. At advanced tick no SLIC and tick allow user to modify other modules. Press go. The tool pauses. You find all the extracted modules in the DUMP folder. Do your modifications with the hexeditor right in the dump folder EXCHANGE the DSDT there. Your DSDT has become shorter from B57Bh to B066h bytes length. The right module should have an index 1 such like 9F3A0016-AE55-4288-829D-D22FD344C347_1_XX.ROM. Do not change its name in the folder, just its data! After you have done the modifications hit OK. The tool should detect the changes, replace the original module and repack the EFI just fine. It worked for me when I needed to modify own modules. The issue at andy's tool must be somewhere else at the tree view code branch....I guess. The contents are different the DUMP indexed file compared to the extracted module...means 9F3A0016-AE55-4288-829D-D22FD344C347.MOD(original).MOD uploaded by the OP is different compared to 9F3A0016-AE55-4288-829D-D22FD344C347_1_47.ROM in the DUMP folder. Andy, why is that? It seems to match the MMTOOL APTIO module extracted code, though. I assume the index file at the dump folder contains not the entire module code... @OP: So you have to go my way from scratch and DO NOT replace the entire module, the original seems to be different when extracted from tree view, just exchange the DSDT as you did before directly at 9F3A0016-AE55-4288-829D-D22FD344C347_1_47.ROM in the DUMP folder while the tool waits...
Thx i already try to do just as u say but something its not right. My modified .rom file get changet after phoenix tool do its job. Its not the same file as i hex edit it after phoenix make bios. file. After procedure u say mmtool cannot even open this kind of bios and it crash always. Could u plz help me with that and try it alone with files from first post. It would be really nice since i try it about 20-30 times without sucess.
Hi both, It is a bug and it isn't! I will try and explain. The treeview extracts a whole module including headers and submodule headers. When a module is replaced it expects the submodule headers to be correct. In this case the module - or more specifically the second submodule starting at 20h with the 4 byte submodule header of C1 C9 00 01 - where C9C1 is the size and 01 indicates it's compressed - has shrunk but you have not corrected this submodule header - this is causing the error. Likewise the compression header and the compressed (stored) submodules. Yen is right, the treeview code works only in complete modules. The SLIC modification code (and hence the files in DUMP when the EFI is first loaded) are submodule based - with filenames GUID_xxx_y.ROM - where xxx is an internal number and y is the submodule - in this case xxx_1 - the submodule header (and the next 9 bytes which are the compression header) are not written - it starts at byte 2Dh of the whole module and the (sub)module headers are regenerated at integration. This is really an artefact of the fact the tool was never really written with the treeview and complete freedom of module manipulation in mind, however from what I learnt from the AMI and Award tools the way it does it - basically deconstructing the EFI and reintegrating the bits that change, does lend itself to this - however its not perfect. I will add a check - its easy if the module shrinks, but more difficult if it grows especially if the submodule that grows has other submodules after it... the relative offsets would be all wrong in a way that is difficult to detect. Basically, for now, you will have to correct the sizes manually. Submodule manipulation from the treeview will take some time. Cheers Andy
Great, it worked. Thanks Andy for the explanation. So if I have got this right another way would be: Go to tree view and tick decompress extracted modules. Then extract the module to be modified. Then exchange the DSDT table and fill the remaining space with zero bytes (same way to mod, start offset of DSDT different, though). Then tick compress inserted / replaced modules. Then hit replace, original ROM gets .OLD extension