The issue with the bricks is that the install should be completely deterministic. (As of the latest version) install A9LH fully (FIRM0 + FIRM1 + stage2), put NAND key1 in place of key2, put a jump to stage1 at a certain offset, reboot. FIRM0 is "corrupted" and leaves stage1 behind, Kernel9 in FIRM1 decrypts to garbage with the second instruction being a jump to the offset I mentioned and the first instruction never being executed, so stage1 executes after the reboot, loads stage2, which loads arm9loaderhax.bin (which is SafeA9LHInstaller again), which uses the OTP hash to make the install permanent with the proper key2.
In my tests I've never encountered any bricks, and I have investigated the possible causes:
- memory corruption in the middle of the reboot? nope. I made a FCRAM and ARM9 memory tester and after a lot of testing by multiple people not a single case was reported.
- failure to init screens or take over the ARM11 due to timing issues or something? nope, put them after the install ends and there were still bricks.
- memory corruption due to a bug in CakeBrah or something? I changed the install method to execute stage1 instead of code left in memory and a brick was reported yesterday.
Yesterday I had another guess and I pushed a new version, if bricks happen with it I'm at a loss.