Homebrew [Re-release] BootCtr - A simple boot manager for 3DS

[m45t3r]

Ok, I think I found the problem. I don't know wtf is the problem with rxTools anyway for these issues, since this seems only to happen with rxTools (I was booting without any problems CakesFW), and only when rxTools is the default entry (using it as a alternative entry was fine).

For those who want to laugh (and understand a little of programming and C), this is the code for boot_fix now:

void boot_fix(int delay)
{
    // voodoo to improve rxTools boot rate
    gfxFlushBuffers();
    gfxSwapBuffers();
    gspWaitForVBlank();
    // actually delay boot for some ms
    svcSleepThread(delay * MS_TO_NS);
}

The build in the attachment includes the above fix for the rxTools boot rate problem. At least for me, it seems to work 100% (boot correctly 10/10 tries). I am going back to defaulting to CakesFW, so please test it and reports any issues.

 

[d0k3]

@d0k3, I don't know if you're still interested, however I discovered a way to make FTBrony to have a valid IP address almost everytime. Just set delay to 300 (or 5 seconds). I updated the documentation to make this clear.

Thank you! To be honest I'm using Mashers Grid Launcher plus my own BrahmaLoader XML loading method as boot manager now . Need something for when a Grid Launcher update goes wrong though, so I'll set up BootCTR again soon. Will let you know if it works.

 

[m45t3r]

Thank you! To be honest I'm using Mashers Grid Launcher plus my own BrahmaLoader XML loading method as boot manager now . Need something for when a Grid Launcher update goes wrong though, so I'll set up BootCTR again soon. Will let you know if it works.

Actually, now that I know what is causing the problem I could create a better solution (wait for a valid connection before booting the homebrew). However, I am pretty satisfied with this solution, even if sometimes I think 5 seconds is too much time (not that it matters too much for me, since I only boot FTBrony sometimes).

Edit: btw, you asked me what services are necessary for booting a simple bootloader like homebrew. If you're still interested, you may want to look at this commit: https://github.com/m45t3r/BootCtr/commit/44c9871e36aed63c1dcb65460f30733a030d6d25

 

[Aurora Wright]

The FTBrony delay is no longer needed with recent versions (I use 2.2 compiled from the repo). It waits for wifi to be available
Anyway, is it possible to make homebrew launched with HBL to return to it instead of bootCtr? It's actually annoying when you have a CFW set as default.

 

[kiwiis]

The FTBrony delay is no longer needed with recent versions (I use 2.2 compiled from the repo). It waits for wifi to be available
Anyway, is it possible to make homebrew launched with HBL to return to it instead of bootCtr? It's actually annoying when you have a CFW set as default.

Sure, just edit your Menuhax or HBLauncher payload so it points to something other than boot.3dsx. Be sure to point it to something else with the same string length (brew.3dsx, etc) or else it won't work.

The way I have it setup is so Menuhax loads boot.3dsx (BootCTR) but HBL loads from brew.3dsx (HBL) so there's no conflicts between the two.

 

[Aurora Wright]

Sure, just edit your Menuhax (or HBLauncher otherapp payload.bin) so it points to something other than boot.3dsx. Make sure you point it to something else with the same string length (brew.3dsx, etc) or else it won't work.

The way I have it setup is so Menuhax loads boot.3dsx (BootCTR) but HBL loads from brew.3dsx (HBL) so there's no conflicts between the two.

Yeah, I have that. Menuhax loads "boom.3dsx" which is BootCtr, which loads the HBL (boot.3dsx) with the Select button. However, if HBL loads an homebrew, it returns to bootctr when you quit it

 

[kiwiis]

You could use the HBLauncher CIA to get into HBL which would make things easier (unless you use HBL enough that having to go through EmuNAND each time is a hassle). As for booting them both off Menuhax with the same payload, I'm not sure there's a way..

Hopefully someone corrects me and I'm wrong.

 

[Aurora Wright]

You could use the HBLauncher CIA to get into HBL which would make things easier (unless you use HBL enough that having to go through EmuNAND each time is a hassle). As for booting them both off Menuhax with the same payload, I'm not sure there's a way..

Hopefully someone corrects me and I'm wrong.

If I had to guess, it's the menuhax payload which set ups in memory the path of the file that gets loaded when HBs return. Maybe it's possible to add a config option (to be used only for the HBL) to make bootctr overwrite it.

 

[suloku]

I was just about to suggest the very same thing: once bootctr is loaded it should go to the memory adress where the payload's "boot.3dsx" is stored and change it to something else since we only want bootctr on menuhax first launch

 

[kiwiis]

Hmm, since switching to the latest version posted in this thread, I've failed to boot GW's Launcher.dat and Cakes twice with a black screen. I was using the version before 1.3 (1.2?) for a while and they didn't fail in over a week with that version. I'm not sure if I can attribute that to bad luck or related to the rxTools fixes.

 

[piratesephiroth]

Ok, I think I found the problem. I don't know wtf is the problem with rxTools anyway for these issues, since this seems only to happen with rxTools (I was booting without any problems CakesFW), and only when rxTools is the default entry (using it as a alternative entry was fine).

For those who want to laugh (and understand a little of programming and C), this is the code for boot_fix now:

void boot_fix(int delay)
{
    // voodoo to improve rxTools boot rate
    gfxFlushBuffers();
    gfxSwapBuffers();
    gspWaitForVBlank();
    // actually delay boot for some ms
    svcSleepThread(delay * MS_TO_NS);
}

The build in the attachment includes the above fix for the rxTools boot rate problem. At least for me, it seems to work 100% (boot correctly 10/10 tries). I am going back to defaulting to CakesFW, so please test it and reports any issues.

Tried it like 5 times in my O3DS and rxtools didn't boot once (didn't even get to the splash screen)

 

[Aurora Wright]

@m45t3r if apt is removed, payload loading is broken on New3DS (it's not a delay issue, even 10 seconds crashes). It works fine without those other 2 services you removed.

 

[suloku]

I was just about to suggest the very same thing: once bootctr is loaded it should go to the memory adress where the payload's "boot.3dsx" is stored and change it to something else since we only want bootctr on menuhax first launch

Quoting myself because someone made me realize that the homemenuhax payload has two boot.3dsx strings:
- First string: 3dsx file that will be booted by menuhax.
- Seconds string: 3dsx file the payload will return to.

So via hex editing now my system boots to boot.3dsx, but will return to boo1.3dsx, allowing me to forget about autoboot if what I want is homebrew.

 

[m45t3r]

The FTBrony delay is no longer needed with recent versions (I use 2.2 compiled from the repo). It waits for wifi to be available
Anyway, is it possible to make homebrew launched with HBL to return to it instead of bootCtr? It's actually annoying when you have a CFW set as default.

Good to know. So I am probably using a old version (got from starter.zip). Gotta to update.

If I had to guess, it's the menuhax payload which set ups in memory the path of the file that gets loaded when HBs return. Maybe it's possible to add a config option (to be used only for the HBL) to make bootctr overwrite it.

If you can find the piece of code from HBL or something that do this, and show it to me, I can implement (if it isn't too much work).

Hmm, since switching to the latest version posted in this thread, I've failed to boot GW's Launcher.dat and Cakes twice with a black screen. I was using the version before 1.3 (1.2?) for a while and they didn't fail in over a week with that version. I'm not sure if I can attribute that to bad luck or related to the rxTools fixes.

Voodoo™ seems to make everything that isn't rxTools somewhat less reliable. I am still thinking what should I do.

Edit: however, it still seems to be pretty reliable (I had only one boot failure so far after the changes). I am thinking if I should put the Voodoo™ fix as a option that is set by default, however can be disabled for those who're having decreased boot rate chance. I will only do this if the boot rate decrease by a good margin (for now, it seems just bad luck).

Tried it like 5 times in my O3DS and rxtools didn't boot once (didn't even get to the splash screen)

Pretty sure you're doing something wrong so. It works for me.

@m45t3r if apt is removed, payload loading is broken on New3DS (it's not a delay issue, even 10 seconds crashes). It works fine without those other 2 services you removed.

Ok, going to revert the last commit. It is really bad that I don't have a N3DS to test my changes.

 

[Aurora Wright]

Quoting myself because someone made me realize that the homemenuhax payload has two boot.3dsx strings:
- First string: 3dsx file that will be booted by menuhax.
- Seconds string: 3dsx file the payload will return to.

So via hex editing now my system boots to boot.3dsx, but will return to boo1.3dsx, allowing me to forget about autoboot if what I want is homebrew.

This doesn't work with N3DS (return is dependent on the first string), I'm going to test with an O3DS...

 

[suloku]

This doesn't work with N3DS (return is dependent on the first string), I'm going to test with an O3DS...

Works on my n3ds EUR 9.2.0 (first boot to boot.3dsx, any return from homebrew to boot1.3dsx)
Make sure you are editing the correct menuhax payload, I first made the mistake to use the highest version I had on sdcard and realized it was the 10.3 payload.

 

[m45t3r]

@kiwiis I did review my changes in Voodoo™ fix and they're probably correct, at least looking at the code from ctrulib. So for now, continue to test, if there is more boot failures please report. If this issue is too common I will add an option to disable Voodoo™. However, at least for me, I had only one boot failure after Voodoo™, and I will simple atribute this failure to bad luck (actually, everytime I change this code I have one or two boot failures until everything stabilizes; yeah, I know, crazy right?).

@piratesephiroth Did you set a delay value for rxTools? If so, is this value 100-150? If yes, so this is the problem. I recently changed the way that this value is used. This is documented here. TL;DR: remove delay option or set to 1500 or something.

 

[MrMandraque]

hello,
Is it possible to have a list with apps name? like this?

[KEY_B]
name = toto CFW
path = /3ds/tito/code.bin
payload = 1
offset = 0x12000

Like ctrboot manager or GRUB list.

Thank you.

 

[Xenosaiga]

hello,
Is it possible to have a list with apps name? like this?

[KEY_B]
name = toto CFW
path = /3ds/tito/code.bin
payload = 1
offset = 0x12000

Like ctrboot manager or GRUB list.

Thank you.

More than likely... NO

This is a lightweight launcher. No menu at all.

 

[piratesephiroth]

@kiwiis I did review my changes in Voodoo™ fix and they're probably correct, at least looking at the code from ctrulib. So for now, continue to test, if there is more boot failures please report. If this issue is too common I will add an option to disable Voodoo™. However, at least for me, I had only one boot failure after Voodoo™, and I will simple atribute this failure to bad luck (actually, everytime I change this code I have one or two boot failures until everything stabilizes; yeah, I know, crazy right?).

@piratesephiroth Did you set a delay value for rxTools? If so, is this value 100-150? If yes, so this is the problem. I recently changed the way that this value is used. This is documented here. TL;DR: remove delay option or set to 1500 or something.

yep, it was that delay value