Homebrew Why did I bother with A9LH?

[nl255]

But sadly all nintendo needs to do is make the system not boot if a lower native firm is being loaded. But there will more than likely always be a way around it as long as you have a CFW already installed.

True, which I said if you look further up. And since NTR won't be updated the way around it will be to create a 10.3 emunand.

Actually if you read a bit back to the Luma3DS Nightly changes what Broke NTR in 11.0 was the Patching of svcBackdoor a Nightly while back readded this./ and i assume should a future update broke using the 10.2 Firmware.bin either NTR's devs will update or it'll be fixed in Luma.

No, that was to fix other stuff such as dynarec in Retroarch if you weren't using the 10.2 firmware.bin. Also, NTR's dev won't update it anymore as it has been discontinued. Fixing it in Luma (by patching out the nfirm version checks in future updates) may be possible but will likely not work forever. The issue is that NTR depends on hardcoded offsets in the kernel (ARM11 kernel, I believe). Thus the only real solution is to create a replacement for NTR which is harder than it sounds.

 

[RemixDeluxe]

While I can agree, I also feel if you are going to do something like this to your 3ds you should always research what you are doing to make sure you fully understand what it is before jumping on board and doing it. When I found a9lh I researched it for a bit to weigh the pros and cons before deciding it was something I wanted to do. IMO I prefer to know as much as I can about the hack before doing it.

I feel like a pamphlet should be made for Arm9loader installation and it should be titled "so you want to install Arm9loader - learn more today about its benefits"

 

[DarkenedMatter]

This post just looks like a cry for attention.

 

[RemixDeluxe]

Also can someone clue me in about this talk of Arm9loader 2.0?

If I already have Arm9loader installed will it take long to install this newer version?

 

[Hamstermascot]

Also can someone clue me in about this talk of Arm9loader 2.0?

If I already have Arm9loader installed will it take long to install this newer version?

Why would it need a 2.0? I thought it was already the almighty cfw people would want their babies from?

 

[RemixDeluxe]

Why would it need a 2.0? I thought it was already the almighty cfw people would want their babies from?

I read topics about a 2.0 and was interested to know more about it.

 

[moopas]

Pros

• Faster boot rate
• 100% boot rate
• Brick protection via boot options
• Updated sysnand
• Gba and dsi in sysnand
• Save SD space via no emunand

Cons

• If some random error, glitch, etc happens, and firm is updated, you are ROYALLY screwed unless hardmodded.
• Time to setup with mediocre brick possibility
• If emunand already boots decently, no real pros other than SD space and Gba/Dsi stuff.

All in all, if your emunand boot time and rate is decent (mine is 23 seconds with 99% bootrate), then no reason to use a9lh right now, and emunand with coldboot is actually truly safer, since if firm is updated SOMEHOW, then you always have the sysnand 100% untouched. So long as some random person doesnt accidentally hold the exact button combo to enter your sysnand and then proceed to update it.

Additionally, the a9lh v2.0 solely adds the ability to read larger payloads, completely useless at the moment, bbut could prove useful later. It's purely an optional future-proof.

 

[Dracari]

True, which I said if you look further up. And since NTR won't be updated the way around it will be to create a 10.3 emunand.



No, that was to fix other stuff such as dynarec in Retroarch if you weren't using the 10.2 firmware.bin. Also, NTR's dev won't update it anymore as it has been discontinued. Fixing it in Luma (by patching out the nfirm version checks in future updates) may be possible but will likely not work forever. The issue is that NTR depends on hardcoded offsets in the kernel (ARM11 kernel, I believe). Thus the only real solution is to create a replacement for NTR which is harder than it sounds.

theres been work on a vers for N3DS (video streaming) lats i looked and that the rest of Features would be implemented later when its stable for O3DS

 

[nl255]

theres been work on a vers for N3DS (video streaming) lats i looked and that the rest of Features would be implemented later when its stable for O3DS

Yes there is, however after that was released NTR was discontinued by the developer. However there is some work being done on bringing something like layerFS to cfw.

 

[Alex658]

Pros

• Faster boot rate
• 100% boot rate
• Brick protection via boot options
• Updated sysnand
• Gba and dsi in sysnand
• Save SD space via no emunand

Cons

• If some random error, glitch, etc happens, and firm is updated, you are ROYALLY screwed unless hardmodded.
• Time to setup with mediocre brick possibility
• If emunand already boots decently, no real pros other than SD space and Gba/Dsi stuff.

All in all, if your emunand boot time and rate is decent (mine is 23 seconds with 99% bootrate), then no reason to use a9lh right now, and emunand with coldboot is actually truly safer, since if firm is updated SOMEHOW, then you always have the sysnand 100% untouched. So long as some random person doesnt accidentally hold the exact button combo to enter your sysnand and then proceed to update it.

Additionally, the a9lh v2.0 solely adds the ability to read larger payloads, completely useless at the moment, bbut could prove useful later. It's purely an optional future-proof.

May i know what is your setup to achieve this, and what payloads have you used?
Bootmanager or booting directly into emunand with unlinked nands?

 

[Ev1l0rd]

• 1 More GB free on your SD.
  
• Guaranteed boot - no menuhax related fails.
• Permanent CFW - Nintendo can't patch it.
• Brick protection (with the caveat that you still need a NAND backup).
  
• All the benefits of using updated SysNAND rather than EmuNAND, without the disadvantages. Examples include: Better battery life, DSi and GBA games work without needing to install twice.

Particularly the last three are appealing IMO.

 

[moopas]

May i know what is your setup to achieve this, and what payloads have you used?
Bootmanager or booting directly into emunand with unlinked nands?

I'm not sure exactly which payloads I am using, but it was released just around the time that downgrading became available from memchunkhax/sysupdater. I downgraded and have been using the same payload since. My setup is bootctr straight into reinand on 11.0 emunand. I am using menuhax of course, 9.2 sysnand, and the MH4U special edition N3DS. 64GB SDXC class 1 card. Boot time is roughly 24 seconds, and since the downgrade months back, I have only had a boot failure twice, even though I turn off my 3DS after every session.

* edit * unlinked nands

 

[The Real Jdbye]

I dunno, I've heard of some people updating their emuNAND and also having sysNAND updated. That was quite a while ago, though, and I dunno how common that is now.

Those people did something dumb like entering data management and exiting back to system settings (which reboots the 3DS into sysNAND) or exiting system settings completely thus rebooting back into sysNAND, and therefore updated their sysNAND instead of emuNAND.

That happens when the Nands are linked. If you unlink them you're basicly dualbooting. If the nands are linked they're still part of eachother. Like having a virtual machine on your 3ds.

No, it doesn't. I wish people would stop spreading this misinformation. The only thing linked NANDs share is SD card data. They are completely isolated from eachother because all sysNAND reads/writes are redirected to emuNAND, so there's no way to even access sysNAND from emuNAND.

No, you can downgrade from 11.0 via a9lh/luma because luma patches out the downgrade checks (as of version 5.5, if you try to downgrade 11.0 on luma 5.4 or lower it won't work and you will have to restore a nand backup). The way I understand it, the bootloader loads firm0 (or firm1 if firm0 is corrupt and then firm0/firm1 loads native_firm which then loads everything else. If you don't have firmware.bin in the luma folder, then it will load native_firm from ctrnand just like on a stock system and then patch it as it is loaded into memory. If you do have firmware.bin in the luma folder then it will load native_firm from the firmware.bin file. In other words, when you have firmware.bin in sd:/luma you are essentially running a frankenfirmware. That is, you are running 11.0 but with the 10.2 kernel. And what NTR requires is the 10.2 kernel.

Almost correct, firm0/firm1 (A9LH) loads Luma or another CFW which then loads a patched NATIVE_FIRM that loads everything else. On a normal (non-A9LH) system firm0/firm1 actually contains NATIVE_FIRM.
NTR also requires a compatible home menu version, luckily this is contained in BootNTR which is open source, so if we're lucky, NTR will always be usable on the latest firmware version.

True, which I said if you look further up. And since NTR won't be updated the way around it will be to create a 10.3 emunand.

No, that was to fix other stuff such as dynarec in Retroarch if you weren't using the 10.2 firmware.bin. Also, NTR's dev won't update it anymore as it has been discontinued. Fixing it in Luma (by patching out the nfirm version checks in future updates) may be possible but will likely not work forever. The issue is that NTR depends on hardcoded offsets in the kernel (ARM11 kernel, I believe). Thus the only real solution is to create a replacement for NTR which is harder than it sounds.

Actually NTR too relies on svcBackdoor since it uses ARM11 kernel to patch the system. But that doesn't really matter since svcBackdoor still exists in 10.2 firm.

I read topics about a 2.0 and was interested to know more about it.

You don't need 2.0, it only allows for slightly bigger payloads and there's nothing that needs that yet, installing it is a bit risky since you have to overwrite the existing A9LH, best just stay on v1 for now.

 

[Majickhat55]

Why didn't you ask these questions BEFORE putting in the time? Also if you didn't know what it did why would you even install it? On the other hand, if you DID know what it did and complained about the install time for no real "perks" why did you even do it when Menuhax/CFW/EmuNAND was working fine. This thread makes no sense......