Hacking cIOSX rev21d2x: Yet Another Hot Fix!!!!

  • Thread starter Thread starter davebaol
  • Start date Start date
  • Views Views 1,249,804
  • Replies Replies 3,354
  • Likes Likes 11

Did d2x work for you?

  • Yes, I had an issue with the official cios and d2x fixed it

    Votes: 93 48.2%
  • Yes, but everything was already working for me with the official cios

    Votes: 82 42.5%
  • No, and I posted what goes wrong

    Votes: 9 4.7%
  • No, and I won't report what goes wrong because I am a troll

    Votes: 9 4.7%

  • Total voters
    193
R2-D2199 said:
@dragbe:
Great work on the installer.
I have added the hermes cIOS to your installer.
You can create a "multi cIOS installer".
Here is the sourcecode: http://www.mediafire.com/?z4v23n1eddzztt1
I have made changes in the patchmii_core.c and CIOSMAPS.xml.
multi cIOS installer = may be the next project but with a different approach knowing that it will be built from d2x cIOS installer source code. Nevertheless, all the mods of d2x cIOS installer that supports more cIOS are welcome --> thank you
WiiPower said:
R2-D2199 said:
@WiiPower:

I think that the version of the base IOS could be added.
[...]
Right, i consider this useful. Could be displayed in those syscheck apps.

baseiosversion field is not vital and provides no added value to a report syscheck. Moreover, it is known implicitly for given base and version of a CIOS.
QUOTEAnd i would like something like magicword = 0xDeadBeef or similar
I prefer that magicword is a kind of metadata (number of bytes to read from the offset 0x20 in the tmd). magicword should allow to detect any changes (new fields for example) of the iosinfo data block.
QUOTE(bnm81002 @ May 22 2011, 07:37 PM)
only my USB drive is connected, nothing else
unplug your USB drive
 
dragbe said:
QUOTE said:
And i would like something like magicword = 0xDeadBeef or similar
I prefer that magicword is a kind of metadata (number of bytes to read from the offset 0x20 in the tmd). magicword should allow to detect any changes (new fields for example) of the iosinfo data block.
I agree with WiiPower that the 1st agreement/version should be the FINAL as mentioned before.
Therefore I see no need of the magicword getting used the way you describe, sorry.
We should keep it simple and compact.
 
IceIceBird said:
I agree with WiiPower that the 1st agreement/version should be the FINAL as mentioned before.
Therefore I see no need of the magicword getting used the way you describe, sorry.
I also hope that this structure remains fixed but I prefer a value more consistent compared with the value 0xDeadBeef that I find a little folk. If people want to use the value 0xDeadBeef, so be it, no problems for me.
 
dragbe said:
IceIceBird said:
I agree with WiiPower that the 1st agreement/version should be the FINAL as mentioned before.
Therefore I see no need of the magicword getting used the way you describe, sorry.
I also hope that this structure remains fixed but I prefer a value more consistent compared with the value 0xDeadBeef that I find a little folk. If people want to use the value 0xDeadBeef, so be it, no problems for me.

Maybe a combination of both? One magic word to determine that there is info in the tmd and then one version number.

so, 0xbeeeeeef + 0x00000001 ?

And 0xbeeeeeef is the value i used for testing, it's still just a suggestion until somebody comes up with something better. Like 23*42*X+Y, whatever, be creative. What was the main number of that guy that told the world was going to end?
 
WiiPower said:
dragbe said:
IceIceBird said:
I agree with WiiPower that the 1st agreement/version should be the FINAL as mentioned before.
Therefore I see no need of the magicword getting used the way you describe, sorry.
I also hope that this structure remains fixed but I prefer a value more consistent compared with the value 0xDeadBeef that I find a little folk. If people want to use the value 0xDeadBeef, so be it, no problems for me.

Maybe a combination of both? One magic word to determine that there is info in the tmd and then one version number.

so, 0xbeeeeeef + 0x00000001 ?

And 0xbeeeeeef is the value i used for testing, it's still just a suggestion until somebody comes up with something better. Like 23*42*X+Y, whatever, be creative. What was the main number of that guy that told the world was going to end?

Maybe 0xc105c105, 0x20121221, 0x20380101 or something like that ?
wink.gif
 
I'm adding new code to the DIP module and now I get this error:
QUOTE said:
/arm-eabi/bin/ld.exe: dip-plugin.elf.orig section `.text' will not fit in region `exe'
/arm-eabi/bin/ld.exe: section .data loaded at [13801000,1380100b] overlaps section .text loaded at [13800020,1380101f]
/arm-eabi/bin/ld.exe: region `exe' overflowed by 32 bytes
collect2: ld returned 1 exit status
make: *** [dip-plugin.elf] Error 1

This is an excerpt from the current link.ld
Code:
/* Sections area */ 
MEMORY {
ÂÂÂÂtableÂÂÂÂÂÂÂÂ: ORIGIN = 0x0, LENGTH = 0x4000
ÂÂÂÂexe(rwx)ÂÂÂÂ: ORIGIN = 0x13800000, LENGTH = 0x1000
ÂÂÂÂram(rw)ÂÂÂÂÂÂÂÂ: ORIGIN = 0x13801000, LENGTH = 0x3000
}

__exe_start_phys__ÂÂÂÂÂÂÂÂ= 0x13800000;
__ram_start_phys__ÂÂÂÂÂÂÂÂ= 0x13801000;

I resized both exe and ram sections so that the module size remains unchanged:
CODE/* Sections area */
MEMORY {
ÂÂÂÂtableÂÂÂÂÂÂÂÂ: ORIGIN = 0x0, LENGTH = 0x4000
ÂÂÂÂexe(rwx)ÂÂÂÂ: ORIGIN = 0x13800000, LENGTH = 0x1200
ÂÂÂÂram(rw)ÂÂÂÂÂÂÂÂ: ORIGIN = 0x13801200, LENGTH = 0x2E00
}

__exe_start_phys__ÂÂÂÂÂÂÂÂ= 0x13800000;
__ram_start_phys__ÂÂÂÂÂÂÂÂ= 0x13801200;
and now those errors are gone, but unfortunately I get the kernel error "Unable to map region...." at runtime.
What am I missing?
unsure.gif
 
You must not change those values? Save those 32 bytes of memory somewhere. I know it can be difficult, but it should be possible, i had to do it several times for my GC stuff. 6 KB total memory, 2 KB reserved for the dvd buffer.
 
Nah there must be a way.
Also I need to add even more code to the DIP module.
If nobody knows how to resize successfully the sections of a module then my last chance is to remove the useless fat support from the DIP module, but they are just 3 small functions so really a few bytes.
frown.gif


EDIT
I could also move the new code to a different module but this would be a dirty workaround implying an useless interaction between modules. I really don't like it.
 
How long will it take until you check irc when there's something you ask me? I'd say you can remove FAT and decrypted disc support. Maybe we can try to optimize the module's code before trying something with possible unknown side-effects?
 
WiiPower said:
How long will it take until you check irc when there's something you ask me? I'd say you can remove FAT and decrypted disc support. Maybe we can try to optimize the module's code before trying something with possible unknown side-effects?
I'll be on irc later, now I'm at work.
And I'm asking everybody.
nyanya.gif
 
Ok problem solved
grog.gif

Code:
/* Sections area */ 
MEMORY {
ÂÂÂÂtableÂÂÂÂÂÂÂÂ: ORIGIN = 0x0, LENGTH = 0x4000
ÂÂÂÂexe(rwx)ÂÂÂÂ: ORIGIN = 0x13800000, LENGTH = 0x2000
ÂÂÂÂram(rw)ÂÂÂÂÂÂÂÂ: ORIGIN = 0x13802000, LENGTH = 0x2000
}

__exe_start_phys__ÂÂÂÂÂÂÂÂ= 0x13800000;
__ram_start_phys__ÂÂÂÂÂÂÂÂ= 0x13802000;
I think it was just a matter of memory alignment.
And it seems 0x2000 bytes are enough ram for DIP module.

Oh, a new exciting d2x update is coming in a few hours.
Keep your eyes peeled!
biggrin.gif
 
Thanks a lot for this enhanced ios! I tried v4 this evening, only one cios for most of games and for mighty channel, it's nearly perfect!.
But I have a little problem ,I can't use anymore my iso forwarder made with Wad2Iso, when I have the d2x with ios 38 as base. Though it worked with cios38 r17.
Is it caused by the iso forwarder (something about the revision number for ios 249) or by differences between cios38 r17 and cios38 r21d2x?
thanks for your help
smile.gif
 
AFAIK forwarder ISOs always required a hermes cIOS to load properly

just change it to use cIOS222 to load forwarder ISOs, it's a simple solution, but if it's even on davebaol to do list it's bound to be near the bottom of it for sure
 
cIOSX d2x v5 alpha1

IOS reload and WBFS through USB/SD

Two days ago WiiPower has discovered how to reinitialize the usb device after an ios reload (BTW thanks once again XFlak because it was only made possible by ModMii, without which he wouldn't have been able to do this).
WiiPower's solution was simple but effective: the usb device is reinitialized just before the system reads the disc id.
However after exiting a game and trying to launch a new one I get a system slow down making mandatory a reboot (maybe my WODE interferes).
So I investigated the problem and discovered that the issue disappears after patching the init_dvd_driver function of the original Nintendo DI module, so that it also initializes the usb device.

This is just an alpha release, so...
  • At the moment only base 56 is supported.
  • At the moment only WBFS file system is supported (no FAT, NTFS, EXT, ....).
  • At the moment only NeoGamma R9 beta48 works for it. Remember to set Block IOS Reload = For discs.
  • At the moment no valid md5 is provided for ModMii verification
  • However DVD, USB and SD cards are supported
We need your feedback before patching all the other base IOSs.


How to build and install


[*]Download and install ModMii v4.5.5 or higher[*]Download d2x v5alpha1 from mirror 1 or mirror 2[*]Remove the old "d2x-beta" folder (if it already exists) from ModMii's folder named "modules"[*]Unpack the folder "d2x-beta" inside ModMii's folder named "modules"[*]Launch ModMii[*]Enter "I Agree"[*]Enter "4" to navigate to Download Page 4[*]Add to the download queue all the d2x wads you need, for example "249d2x56" (remember, only base 56 is supported at the mo)[*]Enter "D" to download selected files[*]Enter "Y" to start downloading[*]Install the wad files with a Wad Manager[*]You're done! Please test and report
yaywii.gif
 
davebaol said:
[*]Download and install ModMii v4.5.5 or higher[*]Download d2x v5alpha1 from mirror 1 or mirror 2[*]Unpack the folder "d2x-beta" inside ModMii's folder named "modules"[*]Launch ModMii[*]Enter "I Agree"[*]Enter "4" to navigate to Download Page 4[*]Add to the download queue all the d2x wads you need, for example "249d2x56" (remember, only base 56 is supported at the mo)[*]Enter "D" to download selected files[*]Enter "Y" to start downloading[*]Install the wad files with a Wad Manager[*]You're done! Please test and report
yaywii.gif

You should add a step that tells the user to remove the old beta folder if it already exist
 
davebaol said:
...
At the moment only NeoGamma R9 beta48 works for it. Remember to set Block IOS Reload = No disc.
...

Wrong..
In Neogamma set Block IOS Reload = For Discs .
WiiPower will probably fix this in next beta
wink.gif



  • Tested Wii Sport Resort and the video works.
  • Tested Metriod Prime Tri and it works.
  • Tested 3 games in a row and no slowdown detected
    wink.gif
 
IceIceBird said:
davebaol said:
...
At the moment only NeoGamma R9 beta48 works for it. Remember to set Block IOS Reload = No disc.
...

Wrong..
In Neogamma set Block IOS Reload = For Discs .
WiiPower will probably fix this in next beta
wink.gif



  • Tested Wii Sport Resort and the video works.
  • Tested Metriod Prime Tri and it works.
Uff! You're so picky!
biggrin.gif
 

Site & Scene News

Popular threads in this forum