Ron Popov

Debugging GPU Memory Access

2026-07-29T00:00:00+00:00

</div>

Disclaimer
This blog contains a lot of content, and i don't feel like splitting it into multiple parts, it might be a bit long, there will be a TL;DR at the end </div> </section>
What's now?</h1></h1>
If you have been following my previous blogs, you will know i am building pomelo, an open source alternative to the stock homemenu. And since the homemenu, is a pretty critical part of the 3ds console, it's kinda harsh.
In the previous 3 blogs, i was talking about a low level issue. When a 3ds process starts, it requests from the kernel a memory region it can use as heap, and one it can use as linear heap - heap for storing textures and GPU stuff. The unique part about linear heap, is that it's continous in the physical memory as well. This is very important when storing buffers that the GPU will access, as the GPU doesn't have an MMU and works mostly with physical addresses.
For regular apps, libctru (open source 3ds SDK) just takes care of it, but when you are building a homemenu, it's not that simple...
After i fixed the linear heap allocation, i started having other issues, in mikage everything was working just fine. However on real hardware, the rendering failed and after some basic debugging, it's seems like the rendering process simply hangs :(

3ds GPU Rendering Process</h1></h1>
Before we talk about what is the issue that i experienced with pomelo, we need to learn a bit about the 3ds rendering process.
The 3ds has the PICA200 GPU that we will be talking about today. And a sysmodule called the GSP</code> module that acts as a driver for communicating with the GPU. We also have citro3d</code>, which is a usermode sdk, meaning the it's part of the app that wants to render stuff, that we will be using as an abstraction layer.
Assuming we have already initialized everything required for rendering, let's look at what happens every frame we render :)
Frame Init</h2> One of the most important parts of the rendering process is the gpuCmdBuffer</code>, it contains all the render instructions for the GPU, including textures to render, text, vectors (lines, rectangles). It also includes the physical addresses that point to the location of these textures, vectors in physical memory. Again, the GPU doesn't really know what virtaul memory is. The gpuCmdBuffer</code> is initialized by citro3d, and allocated in the linear heap of pomele, you should already know what is a linear heap from the previous blog :) We start by zeroing out the gpuCmdBuffer</code>, as we don't want any garbage or leftovers in that buffer. Adding Textures and Vectors</h2> Now is the time for us to get creative :) Pomelo now can draw the background, draw the game icons, add the game name and publisher to the frame, basically all the interesting stuff. All these actions are transformed into commands that are added to the command buffer. They are not actually rendered, only stored in a temporary buffer, waiting to be flushed to the GPU. Frame End</h2> Now is the Interesting part... After pomelo added all the textures and everything it wants to render, we have a gpuCmdBuffer</code> that is filled with instructions for the GPU to process and make the magic happen. Now there are 3 different calls to the GSP module to do in order to render the frame: 1. MemoryFill</h3> This tells the GPU to clean the VRAM memory. It is used to clear the previous frame before starting to render new stuff on top of it. 2. ProcessCommandList</h3> This call is the most complicated by far, so i want to focus on it a bit more. Also (spoiler alert), this is the call that caused pomelo to hang, we will talk more about it very soon. It tells the GSP module to render the beautiful gpuCmdBuffer</code> that we have built. We give the GSP module the Virtual Address of the gpuCmdBuffer</code> and it's size. The GSP module translates this virtual address into a physical address, that the GPU can actually use and access. Unlike other common operating systems, on the 3ds translating the virtual address to a physical address is fairly easy, in most cases it's simply a hardcoded offset between the two addresses. Then the GSP module is giving the GPU the physical address of the gpuCmdBuffer</code> and it's size, and the GPU does it's magic. 3. DisplayTransfer</h3> This call tells the GSP module to tell the GPU to start rendering all the processing it just did. Waiting for a Return Signal</h2> We will know that the GPU finished what the GSP module asked for, by receiving signals from the GPU that indicate it's status. Each such GSP call has a signal of it's own that indicates the action finished: PSC0 - Indicates the MemoryFill finished</li> P3D - Indicates the ProcessCommandList finished</li> PPF - Indicates the DisplayTransfer finished</li> </ul> Once we have received all 3 signals we can be sure that the GPU did it's job and the image should now show up on the console :) Diagram!</h2> Debugging The Issue</h1></h1> After we transfered Pomelo to use the System region in FCRAM, instead of the APP region, which you can read more about in the previous blogs. I suddenly noticed that pomelo started hanging shortly after booting... I would get some text on the top screen, but the bottom screen, where i actually rendered textures and pretty stuff, was empty. So i started adding print statements, and i very quickly learned that the part that was hanging pomelo was FrameEnd. So i continued debugging, and the issue was that we were waiting for a signal that the GPU never sent, but which signal is the missing one? I printed all the signals and stubbed each of the calls to the GSP module, to identify the GSP call that was causing the hang, and i learned that the culprit was ProcessCommandList</code>. Virtual Addr to Physical Addr Translation</h3> I wanted to test if the issue could be in the translation between virtual addr to physical addr by the GSP module. There were some changes to the address of VADDR in kernel version 2.44 of the 3ds kernel, and that was my first suspect. I did all sorts of random stuff to test it, but the final test was editing the GSP module itself to crash when sending the physical addr to the GPU. The crash would give us the register dump, which would contain the physical addr that was passed to the GPU. I used claude to find the exact point in the GSP module that we need to replace with svcBreak, and build me a patch file. Because this is a sysmodule and not a regular title, we can't use "Game Patching" like we did in the previous blog, we need to use "sysmodule patching", that works by giving Luma3ds a patch file to patch the real GSP module. This gave us two crash dumps, one for pomelo, and one for the real homemenu Pomelo GSP Module Crash Stock Homemenu GSP Module Crash The relevant register is R1, which contains the physical memory (after translation from virtual) of the gpuCmdBuffer that is transfered to the GPU by the GSP module. As you can see in the crash dumps, the physical address of the buffer that pomelo allocated is 0x280BBC00</code>. The physical address of the stock homemenu buffer is 0x28005AA0</code>. Hmmmm, it's not that same, but they are in the same region of memory, with a diff of around 0xB0000 bytes (~700KB), it's probably not substantial enough to be the reason for the hang :( What commands are being passed to the GPU?</h3> I was trying to get claude to fix the hanging GPU issue, not with much success :( But it did raise an interesting point. He saw i am using the stock font that comes with the console. Claude was thinking that the font was in some shared memory region that could be unreachable to the GPU. I was able to disprove this fairly quickly but this led to an interesting thought. If the ProcessCommandList call hangs the GPU, the reason could be one of that commands that the GPU tries to process? Maybe one of them tries to access some weird memory region and this hangs the GPU? Maybe one of the textures / vectors / whatever is passed to the GPU, is mapped in some weird memory region, that the GPU cannot access? There is only one way to find out! So we dumped the commands from the gpuCmdBuffer</code> by going over the buffer and parsing the commands in the buffer. In practice, they are all GPU Register Writes, as this is how most of the interaction between the GPU and the CPU works, by writing to GPU registers. One of them popped up right as i dumped the commands from the gpuCmdBuffer</code>, and it was the GPU Register called GPUREG_ATTRIBBUFFERS_LOC</code> This register is used as a base address for passing addresses of vertex buffer. When we want to point the GPU at the addr of a certain vertex buffer, we only need to give the GPU the offset from the base address, and that way we can save a couple of bytes :) When the GPU renders vertices (triangles and such, NOT TEXTURES), pomelo is expected to store all the data about the vertices in a buffer in it's own memory, and give the GPU the address of that buffer, which should be allocated in the linear heap. Access to the vertices buffers works by giving the GPU a base address + offset. But that is an important BUT - the GPU can only access the first 256MB from the base address, meaning the physical addresses that can be accesses are, base address -> base address + 256MB. Let's look at the numbers, shall we? The default base address in citro3d is 0x18000000</code>, The application region of FCRAM starts at 0x20000000</code>, The system region of FCRAM start at 0x28000000</code> (FCRAM System Region Start) - (Citro3d base address) = 0x28000000 - 0x18000000 = 0x10000000 = Exactly 256MB!</code></pre> Meaning, THE GPU CANNOT ACCESS THE SYSTEM REGION OF FCRAM! The border of the region which the GPU can access is exactly where the System Region of FCRAM starts! The Fix</h1></h1> The fix is as easy as bumping the value up to 0x20000000, and it fixes the issues. The obvious caveate is that we cannot store the vertices buffer in the address range between 0x18000000 - 0x20000000, now that region doesn't contain FCRAM, it contains VRAM and QTM Memory. I wasn't planning to use them anytime soon (and not really even sure how to do so), but this is something to be aware of. What This Means For Pomelo?</h1></h1> Now that pomelo is using the SYSTEM region of FCRAM, a lot of games that didn't previously boot, boot just fine now. Even big titles like Mario Kart 7, and the Pokemon games! This is one of the bigggest challenges i have faced when building Pomelo, and i think it's safe to say that we have solved most of the hard R&D parts in pomelo. Now, what we have left is making it more usable and actually a good UX, with things such as: Better shutdown sequence</li> Improve the return to menu sequence</li> Better UI</li> Show system stats</li> </ul> And much more... TL;DR</h1></h1> We changed pomelo to use SYSTEM region of FCRAM, instead of APPLICATION region of FCRAM.</li> When drawing a frame we give the GPU a vertices buffer that is stored in the linear heap. The access is done by specifying a base address, that is hardcoded in the SDK we are using, and also an offset from the base address.</li> The GPU can only access the 256MB of memory after the base address.</li> The new SYSTEM region is not part of those 256MB of memory that the GPU can access</li> We need to change the value of the base address in the SDK we are using.</li> </ol>

Homemenu Memory Shenanigans - Part 3 - Finalle! 2026-07-19T00:00:00+00:00 Where we left off</h1> If you missed the first part</a> If you missed the second part</a> tl;dr I wanted to know how much memory the real homemenu is requesting on real hardware</li> I patched the relevant svcControlMemory call to crash instead, which would dump the stack and register values - that contain the args passed to svcControlMemory, including size and etc...</li> The real homemenu is requesting ~13MB of linear heap, i can't even allocate 4MB</li> </ol> External Guidance</h1> I asked about my issue in a couple of forums, and @neobrain (one of the authors of mikage), suggested something interesting. At this point in time i wasn't sure if my issue was the program state, or the program settings, i will explain. When i say program state, i mean that i might have to setup the 3ds state in a different way to be able to allocate the linear heap. Maybe call some other IPC call, change the order of the IPC calls that i am performing, or something of that sort. Or it could be an issue with the program settings, aka, the headers of the homemenu that i am building. So @neobrain suggested i do an experiment to check if the issue is with the program itself, or maybe the headers. To explain that, we need to talk a bit about exheaders! ExHeaders</h3> Most 3ds titles are packaged into CXI files, also known as NCCH files. Those files contains multiple important pieces, but we will focus on 2 of them. The first of which is the code.bin</code> file, this is the executable itself. It's a file that contains the compiled instructions without any wrapper format (ELF or PE) at all, simply compiled instructions. The second interesting piece are the ExHeaders, these headers are signed by nintendo, and contain everything the 3ds system needs to know about the title to execute it. It contains a wide range of details such as: Section Sizes - the size of the TEXT section, BSS section and etc...</li> IPC & Syscall Access - to which services can i perform IPC calls? which syscalls can i call?</li> FCRAM Memory Region - in which region we would allocate your requested memory? This is the field i changed in the first part</li> A lot more random stuff - TitleId, Title Dependencies, FS Access...</li> </ul> The Experiment</h1> Let's build a code.bin file that 1 thing exactly, allocate a linear heap using svcControlMemory. Then run that code using the real homemenu exheaders, and using pomelo exheaders. That should tell us if the issue is in the code or in the exheaders. </div> Side Note I am using Luma3ds "game patching" for replacing the real homemenu code.bin</code> and exheader.bin</code> files with pomelo ones. Luma3ds does something interesting when replacing the original code.bin</code> and exheader.bin</code> files with the custom ones, and it is patching them in some cases. For examples when loading the homemenu code.bin</code> file (doesn't matter if the original or a patched one), it patches out some of the security checks that the homemenu performs, such as region checks, or DS flashcart whitelists. You can see the patching that luma3ds performs in patcher.c</a>, specifically in the function patchCode</code>. Since the code.bin i am building doesn't have the original region check logic, or the DS flashcart whitelist, the loader fails to patch the code.bin</code> file and crashes the system as a result. This is something i also encountered when building pomelo, and i fixed it in pomelo by injecting fake code that looks like the logic that luma3ds is trying to patch but is never actually executed, just so luma3ds would think that it was able to patch the homemenu. Since i wanted to keep this payload as simple as possible, in this case i rebuild luma3ds without the security checks, just for running the test payload. </div> </section> Code snippet</h2> I ran the following code that does 3 things: Call svcControlMemory</code> and tells it to allocate a 4MB linear heap</li> Copy the return code to R12</li> Crash the system using svcBreak</code>, so we could read the return code</li> </ul> .arm .global _start .equ MEMOP_ALLOC_LINEAR, 0x10003 @ MEMOP_LINEAR (0x10000) | MEMOP_ALLOC (3) .equ MEMPERM_RW, 0x3 @ MEMPERM_READ (1) | MEMPERM_WRITE (2) .equ ALLOC_SIZE, 0x400000 @ 4 MB _start: ldr r0, =MEMOP_ALLOC_LINEAR @ op mov r1, #0 @ addr0 mov r2, #0 @ addr1 ldr r3, =ALLOC_SIZE @ size ldr r4, =MEMPERM_RW @ perm svc 0x01 @ svcControlMemory mov r12, r0 @ stash result code where the crash screen shows it mov r0, #0 @ breakReason = BREAKREASON_PANIC svc 0x3C @ svcBreak</code></pre>Results</h2> I ran the code using the original homemenu exheaders, and using pomelo exheaders, and here is what i got Original Homemenu ExHeaders</h3> Pomelo ExHeaders</h3> AHA!</h2> We got our answer! The issue is in the ExHeaders! You can see in the crash dump of the original homemenu exheaders that the svcControlMemory</code> call succeeded, indicated by the value 0 in R12. And you can see that when i used pomelo ExHeaders, the value in R12 was 0xD86007F3</code>, which means the svcControlMemory</code> FAILED when using pomelo ExHeaders files. What Now?</h1> This really narrows down the root cause of our issue. Now i know i just need to make the ExHeaders of pomelo closer to the real ones and finally the heap allocation should work. I am using makerom</a> to build the exheaders of pomelo. And i am using a template.rsf</code> file to tell makerom which values to put in the pomelo exheaders. I dumped the CXI file of the original homemenu from my own console, and ran ctrtool</code> on it to extract the headers. I gave claude my current template.rsf</code> file and the desired homemenu exheaders, and told it to make my headers as close as possible to the real ones. Then, A couple of claude prompts later, I finally found the culprit! The culprit was the KernelVersion</code> value, which indicates for which kernel version that title was built and tested against. After setting the kernel version to 2.50</code>, the linear heap allocation worked! I started having other issues related to copying buffers from the linear heap to VRAM, but i think that is a story for another time :) The reason the kernelversion even makes a difference is that there were some changes to the virtual memory allocation in kernel version 2.44. The virtual address to which the physical memory was mapped, was changed in kernel version 2.44. Before 2.44, the virtual address to which heaps were mapped was 0x14000000</code>, and after 2.44 it was 0x30000000</code>. Even after understanding the connection between the kernel version and why it affects linear heap allocations, i am still not entirely sure why not setting a kernel version causes the allocation to fail. I would expect the OS to be backwards compatible with old games, taht were built for older kernels. Conclusion</h1> That was a pretty fun research, even tho it was pretty frustrating at times, but i think the most interesting part to take from there is the research itself, and hopefully you learned something new about 3ds heap allocation :) Like i said, i am now having other issues related to linear memory and VRAM, so i might write some more pretty soon :) Homemenu Memory Shenanigans - Part 2 2026-07-16T00:00:00+00:00 Where we left off</h1> If you missed the first part</a> tl;dr Some games are crashing as soon as they are launched, because they don't have enough RAM</li> I need to allocate my heaps in a different region of memory, dedicated for system apps, instead of the APPLICATION memory region</li> Pomelo fails to allocate a linear heap in the new memory region and crashes on boot :(</li> </ol> What is the linear heap?</h1> Linear is a heap that is used for GFX operations, such as storing textures and 3d models. The only thing that is special about it is that it's a single consecutive section in memory, unlike a regular heap allocation. In regular heaps the memory might be spread out across multiple sections in the physical memory. 3ds Error Codes</h1> Using the same technique that i used to pinpoint the exact svcBreak call that crashes the system, i can use it to also leak the returnCode from the svcControlMemory</code> (syscall that is used to allocate memory on the 3ds console). Now the code looks like this // Allocate the linear heap rc = svcControlMemory( &__ctru_linear_heap, 0x0, 0x0, __ctru_linear_heap_size, MEMOP_ALLOC_LINEAR, MEMPERM_READ | MEMPERM_WRITE ); if (R_FAILED(rc)) { asm volatile("mov r11, %0" : : "r"(rc)); asm volatile("mov r12, %0" : : "r"(0xEEEE0003)); svcBreak(USERBREAK_PANIC); }</code></pre> You can see in R11 that the error code svcControlMemory</code> returns is 0xD86007F3</code>! Something you should know about 3ds status code is that they are actually built from 4 different values that can be used to debug the crash: Description</li> Module</li> Summary</li> Level</li> </ul> After decoding the error code using 3dbrew docs</a>, i got the following values and their meaning Description : 0x3f3 (1011) - Out of memory Module : 0x1 (1) - Kernel Summary : 0x3 (3) - Out of resource Level : 0x1b (27) - Permanent</code></pre> Out of memory? That's weird... I am requesting the same amount of memory that the real homemenu is requesting. I got that number by running the real homemenu in mikage and searching for the svcControlMemory</code> the real homemenu is calling. Operation 0x3</code> is MEMOP_ALLOC, and operation 0x10003</code> is MEMOP_ALLOC_LINEAR. # Regular heap allocation - Around 3MB SVCControlMemory: addr0=0x08000000, addr1=0x00000000, size=0x304000, op=0x3, perm=0x3 # Linear heap allocation - Around 11MB SVCControlMemory: addr0=0x00000000, addr1=0x00000000, size=0xb64000, op=0x10003, perm=0x3</code></pre> Claude suggested the reason the linear heap allocation fails is because a linear heap requires a continuous section of memory, let's see how much memory i have available and if that makes sense Well, i have quite a lot of memory... Overall the system has around 255mb of ram, with 248mb available, however we are more interested specifically in the SYSTEM memory region, as only there we can allocate memory. This region has around 100mb of ram, with 95mb of ram available for allocation, so how could that be??? How much memory does the real homemenu allocate?</h1> When running the real homemenu in mikage it told me that the real homemenu is requesting around 11mb of linear heap memory, however when i request 11mb of linear heap memory using pomelo on real hardware, it crashes. I assume there's some diff between the way the homemenu does that on a real console and in mikage, and it's not farfetched that the console allocated more / less memory, based on the 3ds model (some models have more RAM than others). I tried to reverse engineer the real homemenu and attempt to find how much linear heap it requests and i couldn't find anything, so i really wanted to get this value somehow from the real hardware. Now, getting those numbers is a bit hard, we want to capture the homemenu performing a syscall (which is handled by the kernel). Even tho there are debuggers for physical consoles, i'm not really sure how i could go for debugging the homemenu or the kernel itself. I didn't really want to invest in using, or maybe even building something like this for a super specific use case (getting the amount of ram that the real homemenu is requesting). So i decided to do something super hacky, that worked! I dumped the code.bin</code> file from the stock homemenu to disassemble it and get its logic, as i said i found the linear heap svcControlMemory</code> call, but i couldn't find what is the value that is being passed to it, it seems like it is never initialized. So i decided to do the following, i patched the function call to svcControlMemory</code> with int 0x3C</code>, or in human language - svcBreak</code>. That means that instead of calling svcControlMemory</code>, the console will crash, and show me the registers and stack state when the call to svcControlMemory</code> was supposed to take place, from which i could extract the different variables that are passed to it, including how much memory is requested. ... 00146dac 00 20 a0 e3 mov r2,#0x0 00146db0 08 00 8d e2 add currentSize,sp,#0x8 00146db4 24 fb ff eb bl ctr::svcControlMemory <-- replace this opcode with "int 0x3C" 00146db8 02 11 10 e2 ands svcResult,currentSize,#0x80000000 00146dbc 00 f0 20 e3 nop ...</code></pre> So i patched the homemenu code.bin file, and used Luma3ds game patching to tell my console to use the patched code.bin file instead of the original homemenu, booted it up, aaaannnnnnddddddd I got this beautiful crash screen :) From here i could extract the total size that is requested for the linear heap from R4 - 0x00D00000, which is 13MB??? How does that make sense??? That's more than what we request in mikage, and i can't even get 4MB allocated, oof :( I then also patched the instruction after the call to svcControlMemory</code> to make sure the call succeeded, and it did. Temp Summary</h1> So what did we have here? The real homemenu is allocating 11MB when running in mikage</li> It allocates 13MB when running on real hardware</li> I can't allocate 4MB in the same memory region :(</li> </ul> More in the next one! Homemenu Memory Shenanigans - Part 1 2026-07-13T00:00:00+00:00 Why?</h1> While building Pomelo (which you can read more about in my previous blog</a>), i noticed that some games that pomelo tried to boot, would crash very quickly after they started - usually the more serious ones such as the mario and legend of zelda series. I assumed that i didn't initialize / handle something correctly, which caused some games to crash. One such game was "Super Mario 3D World", so i decided to take this one as an example, and assumed that getting it to boot, should fix the same issues that a lot of games had. How?</h1> I dumped the game from my console, and put it into ghidra to try and understand why the game was crashing. I would also mention that i got a pretty detailed stack dump from my 3ds console, including the state of all the registers, and the stack. I loaded the game binary into ghidra, and used the modern marvel of Artificial Intelligence to my help. I connected claude code to the ghidra MCP server, gave it the crash dump, and very quickly it gave me the answer i was looking for. The reason "Super Mario 3D World" was crashing, when the game boots, it checks how much RAM is has available for use, and if it doesn't have enough, it crashes :( But in that case, how does the game boot at all? After all pomelo uses much less memory than the stock homemenu, so what is the issue? And that's when i learned about 3ds FCRAM memory regions. FCRAM Memory Regions</h1> As you can see in this super useful diagram</a>, the 3ds FCRAM is where the heaps of all the different processes in the 3ds are allocated. The FCRAM is split into 3 sections: APPLICATION - For Games and Applications running on the 3ds system, such as "Mario Kart 7", "Super Mario 3D World" and etc...</li> BASE - Used by some of the sysmodules, and also the kernel itself.</li> SYSTEM - Used by the NS module, some system applets (system apps such as camera or settings menu), and most importantly the homemenu is using this section</li> </ul> AHA!</h1> The memory region that the title is using, is defined by the title itself. Titles will usually use the APPLICATION system region, and since titles are signed by Nintendo, this is not something that the author of the app can change. However on modded consoles, we can practically do whatever we want. In the case of pomelo, it is using the APPLICATION memory region, as you can see defined in the template.rsf</code> file that is used the build the CXI section MemoryType: Application</code></pre> AHA! Now everything makes sense! Because Pomelo is using the APPLICATION</code> system region, it's using some of the memory that is reserved for actual 3ds games, and when "Super Mario 3D World" is booting, it doesn't have the amount of memory that it expected. So the fix should be as simple as changing that to SYSTEM</code>, right? Sadly, it's not that simple.. Something is crashing :(</h1> Re-building Pomelo and running it on my modded console, i immediately got a crash :( The crash dump we got looked like this. As you can see we can see the state of each register, we also have the state of the stack in the bottom screen, however that is not relevant at the moment. The first interesting thing you can see here, is that the Exception Type is svcBreak</code>, which is a syscall that has a single purpose - crash the system. This means that some code somewhere, reached a state where it just couldn't continue and had no other choice, but to crash. The PC register pointed to the svcBreak</code> function, luckily we can use the LR register to see which function called svcBreak</code>, The LR function pointed to a function called __system_allocateHeaps</code>. The function __system_allocateHeaps</code> is a function that runs at a very early stage of the title boot, even before the main</code> function is executed. It kinda makes sense that by playing with the memory region in which the heap is allocated, we broke something related to heap allocations. Let's dig into this function and understand which specific section is crashing! The relevant function looked something like this // Retrieve handle to the resource limit object for our process Handle reslimit = 0; rc = svcGetResourceLimit(&reslimit, CUR_PROCESS_HANDLE); if (R_FAILED(rc)) svcBreak(USERBREAK_PANIC); // Retrieve information about total/used memory // and calculate how much memory we can allocate // ... // Allocate the application heap rc = svcControlMemory( &__ctru_heap, OS_HEAP_AREA_BEGIN, 0x0, __ctru_heap_size, MEMOP_ALLOC, MEMPERM_READ | MEMPERM_WRITE ); if (R_FAILED(rc)) svcBreak(USERBREAK_PANIC); // Allocate the linear heap rc = svcControlMemory( &__ctru_linear_heap, 0x0, 0x0, __ctru_linear_heap_size, MEMOP_ALLOC_LINEAR, MEMPERM_READ | MEMPERM_WRITE ); if (R_FAILED(rc)) svcBreak(USERBREAK_PANIC);</code></pre> As you can see, we have 3 svcBreak calls in this function, but how can we know which one is the relevant one? I used R12 as an error code register, in which i set a hardcoded value, just before the call to svcBreak. As svcBreak doesn't really change the value of the registers, that value would later show up in the register state dump i get when the console crashes. The updated code looked something like this // Retrieve handle to the resource limit object for our process Handle reslimit = 0; rc = svcGetResourceLimit(&reslimit, CUR_PROCESS_HANDLE); if (R_FAILED(rc)) { asm volatile("mov r12, %0" : : "r"(0xEEEE0001)); svcBreak(USERBREAK_PANIC); } // Retrieve information about total/used memory // and calculate how much memory we can allocate // ... // Allocate the application heap rc = svcControlMemory( &__ctru_heap, OS_HEAP_AREA_BEGIN, 0x0, __ctru_heap_size, MEMOP_ALLOC, MEMPERM_READ | MEMPERM_WRITE ); if (R_FAILED(rc)) { asm volatile("mov r12, %0" : : "r"(0xEEEE0002)); svcBreak(USERBREAK_PANIC); } // Allocate the linear heap rc = svcControlMemory( &__ctru_linear_heap, 0x0, 0x0, __ctru_linear_heap_size, MEMOP_ALLOC_LINEAR, MEMPERM_READ | MEMPERM_WRITE ); if (R_FAILED(rc)) { asm volatile("mov r12, %0" : : "r"(0xEEEE0003)); svcBreak(USERBREAK_PANIC); }</code></pre> And now i could pinpoint the exact svc call that failed and causes the system to crash! After running the code on my console, R12 had the value 0xEEEE0003</code>, which means that Pomelo fails to allocate the linear heap. Wrapping Up</h1> I feel like this is already kinda long, and i have quite a lot more to cover, so i have to split this blog into (hopefuly) 2 parts :) Introducing Pomelo 2026-07-09T00:00:00+00:00 Pomelo - An Alternative 3DS Homemenu!</h1> Hi Everyone, I am happy to share a project i was working on for the last couple of months called "Pomelo", which is an open-source alternative for the stock 3ds homemenu! Why?</h2> When i got my first 3ds console, a couple of months ago, i wanted to customize the homemenu UI of my console. I was quite surprised to see that the only customization mechanism was themes, and there was no alternative for the stock nintendo homemenu. Being in a time of my life where i had quite a lot of spare time, writing a homemenu for a console i know nothing about sounded like quite a cool project, that i really fell in love with over time. I started learning about 3ds hacking and very quickly learned of a very supportive community that has TON of knowledge about anything 3ds related. Which made the entire experience a lot more fun :) My goal with this project is to build an open source alternative to the stock nintendo homemenu, that would allow the community to customize and easily redesign. Currently Pomelo has a very limited set of features and changing the design requires writing C code :( I am hoping to implement a themes mechanism in the future, similar to the one nintendo has, but more flexible. Features</h2> The homemenu is a very integral part of the 3ds console, doing really, a TON of stuff behind the scenes. I don't think Pomelo would ever be able to have the full set of features that the stock homemenu has, however i do think that it is very close to having the important features, that will allow most users to use Pomelo as a daily driver. Currently Pomelo is still in development, the features i was focusing on are: Game Enumeration - Get a list of all the installed titles</li> Game Metadata - Show the name and icon of all the installed games</li> Game Launching - Launch one of the games that are installed on your console. This feature is pretty buggy, a lot of games crash very quickly or even don't boot at all.</li> </ul> Design</h2> As you can see in the screenshots below, i am still playing around with the design until i find something i like. Currently, my vibe is something retro, right now i'm trying to make it look like a NDS. Plans for the future</h2> First of all i want to focus on improving the Game Launching part, i understand this is one of the most important features of the 3ds homemenu. I want to get Pomelo to a state where users can actually use this as their daily driver. And then start with all the random QoL improvements. Installation</h2> Pomelo is using Luma3ds "Game Patching" to replace the stock nintendo homemenu, note that "Game Patching" is an optional feature, that has to be enabled. Currently i only tested it on my console which is a New 3DS US. Currently the project is still in very early development, the source code is available for those who wish to run it on their own consoles. For more details on installation, see the Github Repo</a> Feedback</h2> I would love to hear your feedback and thoughts on this project, however, please note that this is a side project of mine and i am working on it in my spare time, so please be patient <3 Testing</h2> Pomelo is using Luma3ds Game Patching to load itself, instead of the stock homemenu, in case something goes wrong, simply remove the Pomelo code.bin</code> and exheader.bin</code> files from the SDCard and the stock homemenu should boot as normal. However POMELO HAS NOT BEEN THOROUGHLY TESTED, USE AT YOUR OWN RISK. Screenshots!</h2> Pomelo running on real New 3DS hardware: Pomelo running in Mikage emulator:

Results</h2>
I ran the code using the original homemenu exheaders, and using pomelo exheaders, and here is what i got</p>

Original Homemenu ExHeaders</h3>
</p>

Pomelo ExHeaders</h3>
</p>

`Temp Summary</h1> So what did we have here?</p> The real homemenu is allocating 11MB when running in mikage</li> It allocates 13MB when running on real hardware</li> I can't allocate 4MB in the same memory region :(</li> </ul> More in the next one!</p>`

`Wrapping Up</h1> I feel like this is already kinda long, and i have quite a lot more to cover, so i have to split this blog into (hopefuly) 2 parts :)</p>`

Design</h2>
As you can see in the screenshots below, i am still playing around with the design until i find something i like. Currently, my vibe is something retro, right now i'm trying to make it look like a NDS.</p>

`Screenshots!</h2> Pomelo running on real New 3DS hardware:</p> </p> Pomelo running in Mikage emulator:</p> </p> </p> </p>`

Ron Popov

Debugging GPU Memory Access

Diagram!</h2>
</p>

Homemenu Memory Shenanigans - Part 3 - Finalle!

Homemenu Memory Shenanigans - Part 2

Homemenu Memory Shenanigans - Part 1

Introducing Pomelo

Pomelo - An Alternative 3DS Homemenu!</h1>
Hi Everyone, I am happy to share a project i was working on for the last couple of months called "Pomelo</strong>", which is an open-source alternative for the stock 3ds homemenu!</strong></p>

Ron Popov

Debugging GPU Memory Access

Diagram!</h2> </p>

The Experiment</h1> Let's build a code.bin file that 1 thing exactly, allocate a linear heap using svcControlMemory. Then run that code using the real homemenu exheaders, and using pomelo exheaders. That should tell us if the issue is in the code or in the exheaders.</p>

Results</h2> I ran the code using the original homemenu exheaders, and using pomelo exheaders, and here is what i got</p>

Original Homemenu ExHeaders</h3> </p>

Pomelo ExHeaders</h3> </p>

Temp Summary</h1> So what did we have here?</p> The real homemenu is allocating 11MB when running in mikage</li> It allocates 13MB when running on real hardware</li> I can't allocate 4MB in the same memory region :(</li> </ul> More in the next one!</p>

Wrapping Up</h1> I feel like this is already kinda long, and i have quite a lot more to cover, so i have to split this blog into (hopefuly) 2 parts :)</p>

Design</h2> As you can see in the screenshots below, i am still playing around with the design until i find something i like. Currently, my vibe is something retro, right now i'm trying to make it look like a NDS.</p>

Screenshots!</h2> Pomelo running on real New 3DS hardware:</p> </p> Pomelo running in Mikage emulator:</p> </p> </p> </p>

Diagram!</h2>
</p>

Results</h2>
I ran the code using the original homemenu exheaders, and using pomelo exheaders, and here is what i got</p>

Original Homemenu ExHeaders</h3>
</p>

Pomelo ExHeaders</h3>
</p>

`Temp Summary</h1> So what did we have here?</p> The real homemenu is allocating 11MB when running in mikage</li> It allocates 13MB when running on real hardware</li> I can't allocate 4MB in the same memory region :(</li> </ul> More in the next one!</p>`

`Wrapping Up</h1> I feel like this is already kinda long, and i have quite a lot more to cover, so i have to split this blog into (hopefuly) 2 parts :)</p>`

Design</h2>
As you can see in the screenshots below, i am still playing around with the design until i find something i like. Currently, my vibe is something retro, right now i'm trying to make it look like a NDS.</p>

`Screenshots!</h2> Pomelo running on real New 3DS hardware:</p> </p> Pomelo running in Mikage emulator:</p> </p> </p> </p>`