From 9dd86897766e474e764a3c60554f5a239de290e9 Mon Sep 17 00:00:00 2001 From: chaoskagami Date: Fri, 20 May 2016 16:07:13 -0400 Subject: [PATCH] Okay, I understand how to fix the sysmodule size to grow now. Ugh. --- source/patch/module.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/source/patch/module.c b/source/patch/module.c index ccc6cd9..b3c0cc8 100644 --- a/source/patch/module.c +++ b/source/patch/module.c @@ -43,16 +43,16 @@ int patch_modules() { uint32_t need_units = (module->contentSize - sysmodule->contentSize); fprintf(stderr, "Module: Would grow %d units but NYI\n", need_units); continue; - // FIXME - Adjust sysmodule section and FIRM NCCH. This is not correct. -/* fprintf(stderr, "Module: Grow %d units\n", module->contentSize - sysmodule->contentSize); - // Location to shuffle to. - uint8_t* move_to = ((uint8_t*)sysmodule + (module->contentSize + need_units) * 0x200); - uint8_t* move_from = ((uint8_t*)sysmodule + module->contentSize * 0x200); - uint32_t copy_size = 0x10000; // FIXME - Add a safe way to properly calculate the half of NCCH we need to copy. This is okay for now. + // TODO - so in a nutshell, the reason Luma works is because it relocates + // the sysmodule section to its final location while fixing the size. + // Once stuff is at the right place, it no longer cares about its' size. - memmove(move_to, move_from, copy_size); */ - // TODO - This is hackish and possibly incorrect. It needs testing. + // Cakes performs an in-place resize and leaves the copy for later; essentially, + // this means I need to scale EVERYTHING after the increase, and adjust NCCH sections accordingly. + + // It would be hella easier to just patch at the final location in memory; + // and this was actually mentioned on Luma's issues. } // Move the remaining modules closer -- 2.39.5