- Joined
- May 8, 2008
- Messages
- 2,395
- Trophies
- 0
- Location
- Istanbul
- Website
- www.tepetaklak.com
- XP
- 387
- Country
Taking a close look on wii's memory map figured out something... Firstly this is only for those that can use trucha signed discs
At the very bottom of the table in the wiibrew article (http://www.wiibrew.org/wiki/Memory_Map)
0x80003F00 0x132c100 (~19.2MB) Standard application executable area
0x81330000 0x4d0000 (~4.8MB) Loader executable area
In loader executable area our system menu resides, and once a disc put into the wii, system runs the apploader and apploader tells the system the memory sections of the initial executable (main.dol) and it's loaded into above defined standard application executable area...
on a sane wii, if the disc is autoboot system boots the code loaded into the standard application executable area..
on a wii with "system files corrupted" error the dol is not booted yet it's loaded into the standard executable area...
so the result is, system menu can be patched with the apploader to jump to the dol loaded...
of course to proove my theory we need examples of people bricked with the same error and can't boot an autoboot disc either from recovery menu or from the warning screen...
If I find time, I'll test on my non-bricked wii with a non-autoboot disc if it's like that...
For those interested, there is code and explanation as to how system menu can be patched using the freeloader's apploader below
http://forum.wiibrew.org/read.php?8,1693,page=2
by the way,
jumping is not straight forward, here below c code taken from front sd elf loader (which is taken from gecko os) should be implemented without doing any ogc calls
ep is the pointer to the dol entry point
interrupt disabling and enabling is just two inline assembly defines, below is generic ppc code libogc also contains these defines
At the very bottom of the table in the wiibrew article (http://www.wiibrew.org/wiki/Memory_Map)
0x80003F00 0x132c100 (~19.2MB) Standard application executable area
0x81330000 0x4d0000 (~4.8MB) Loader executable area
In loader executable area our system menu resides, and once a disc put into the wii, system runs the apploader and apploader tells the system the memory sections of the initial executable (main.dol) and it's loaded into above defined standard application executable area...
on a sane wii, if the disc is autoboot system boots the code loaded into the standard application executable area..
on a wii with "system files corrupted" error the dol is not booted yet it's loaded into the standard executable area...
so the result is, system menu can be patched with the apploader to jump to the dol loaded...
of course to proove my theory we need examples of people bricked with the same error and can't boot an autoboot disc either from recovery menu or from the warning screen...
If I find time, I'll test on my non-bricked wii with a non-autoboot disc if it's like that...
For those interested, there is code and explanation as to how system menu can be patched using the freeloader's apploader below
http://forum.wiibrew.org/read.php?8,1693,page=2
by the way,
jumping is not straight forward, here below c code taken from front sd elf loader (which is taken from gecko os) should be implemented without doing any ogc calls
Code:
__IOS_ShutdownSubsystems ();
_CPU_ISR_Disable (level);
__exception_closeall ();
ep();
_CPU_ISR_Restore (level);
ep is the pointer to the dol entry point
interrupt disabling and enabling is just two inline assembly defines, below is generic ppc code libogc also contains these defines
Code:
#define PPC_MSR_DISABLE_MASK 0x00008000
#define _CPU_ISR_Disable( _isr_cookie ) \
ÂÂÂÂ{ register u32 _disable_mask = PPC_MSR_DISABLE_MASK; \
ÂÂÂÂÂÂ_isr_cookie = 0; \
ÂÂÂÂÂÂasm volatile ( \
ÂÂÂÂÂÂÂÂÂÂ"mfmsr %0; andc %1,%0,%1; mtmsr %1" : \
ÂÂÂÂÂÂÂÂÂÂ"=&r" ((_isr_cookie)), "=&r" ((_disable_mask)) : \
ÂÂÂÂÂÂÂÂÂÂ"0" ((_isr_cookie)), "1" ((_disable_mask)) \
ÂÂÂÂÂÂÂÂÂÂ); \
ÂÂÂÂ}
#define _CPU_ISR_Enable( _isr_cookie )ÂÂ\
ÂÂÂÂ{ \
ÂÂÂÂÂÂ asm volatile ( "mtmsr %0" : \
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ "=r" ((_isr_cookie)) : \
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ "0" ((_isr_cookie))); \
ÂÂÂÂ}