CakesForeveryWan
CakesForeveryWan copied to clipboard
mid-kid
*hax loader black screens
Currently the way I'm loading Cakes is with CtrBootManager. The 3dsx loader just black screen on my n3ds... Is it becuase it doesn't support hax 2.5?
It does support hax 2.5 (CTRBM uses the same code for loading .dat files). Try loading it as boot.3dsx, or from HBL.
Been experiencing this bug on both my o3ds. However, only my EU 3ds one experience it the most (around 20%).
Experienced it mostly after a forced reboot (Smash, Settings, HBL)
I have a few requests for you guys to try out to narrow down the possible cause of the problem:
- Try loading the rxTools nightlies the same way (rxTools.3dsx)
- Try using the CakeBrah version included in CTRBM, by putting something like the thing behind this ordered list in the config file (markdown screws up formatting if I put it behind this text).
- If the last point doesn't work, try adding
autobootfix = 200
title = "CakesFW";
path = "/Cakes.dat";
offset = "0x12000";
- If this test turns out to be positive, the problem is how the Cakes payload is started.
- If this test turns out to be positive, it's an error I may have recently added in CakeBrah.
- If this test turns out to be positive, I'm not exactly sure what autobootfix means, but it's probably a timing error or something.
- If everything turns out to be negative, It's something that's been here for way longer, but I haven't noticed until now.
I run n3ds 9.0.0-20 U and the five times I have booted have worked fine. EDIT: are you on 9.2?
That's the problem with this bug: It only happens to select people and I've yet to find someone with enough patience to sit with me a few hours and debug it. 9.2 only updated home menu. That doesn't make much difference.
@mid-kid What's weird is rxTools 3dsx never worked for me either. I found a modified/weird rxTools 3dsx that works for me though. Yes the CakeBrah version included with CTRBM works. It's currently how I'm loading Cakes FW and ReiNAND. The ReiNAND 3dsx doesn't work for me either since it uses the same way Cakes does.
There's not many issues anyway, so this issue is fine here (Can't move all the messages). Thanks for explaining the problem, that helps a lot. It's probably a problem introduced between whatever version CTRBM uses and the current one.
A new version of CTRBM has been released. Funny thing, it was forced to use submodules for an old ctrulib and CakeBrah so that it could continue to load Cake payloads.
Thing is, I did my own port of CTRBM that used to most up-to-date ctrulib and CakeBrah, and libhax. I can still boot rxTools and HBL. I'm unsure how to verify that CakeBrah is working, though (is being able to boot rxTools proof of that?). I've tried to load a lot of older *.dat archives I've found lying around, and I've been unable to boot them using an offset of zero in CTRBM. Whenever I try to load these *.dat files, I get the dark screen described earlier. Funny thing, when I try to load them in CtrBootManager 1.2 (the last version before the one that came out today), it looks like the screen begins to be drawn black but only the first few columns become black before the screen stops updating. Thoughts? I am capable of compiling and testing things as well, if I'm only nudged in the right direction.
Never load them at offset zero, that's where the spider payload is located. The arm9 payload is located at 0x12000, which is what you want. Also, I see no reason why newer version of CakeBrah wouldn't work with it. Sure, the library has changed a few functions, but that's easily updated.
Thanks for the pointer. I'll try loading EmuNAND9.dat again. Although I'm pretty sure I tested by changing the offset to 0x12000... I'll return with more info once I have that (btw, I'm active on #3dshacks as Gelex, I can provide faster feedback through there).
EDIT: I did update the functions so it does compile. I haven't yet tested it with offset 0x12000, I think. I'll make a new post once I do.