As soon as I manage to make the php script download the file from github, it should be easy enough to check if it is OK by checking the hash. I've written most of the script, it's only lacking the json parsing to find the latest release now.I'm including the sha512 files now because I'd rather that users actually verify it. The updater application's author rehosting releases being one major reason. I don't think he'd tamper with it, but better safe than sorry. Web servers get hijacked all the time. Thanks.
As I look more and more at HANS I realize I can't use it as-is, so no inbuilt solution for a while. Though on the topic of romfs redirects, etc - @Steveice10 PR'd offsets for 11.0 FIRMs to BootNTR. If you build BootNTR from git you can use NTR with the latest native FIRM, it seems. I'd still strongly recommend against this due to it being effectively dead (BootNTR just gets NTR into memory.)
make -C host/bdfe clean
make[1]: Entering directory `/d/corbenik/host/bdfe'
rm -f bdfe
rm -f *.o
make[1]: Leaving directory `/d/corbenik/host/bdfe'
rm -rf out build
make -C host/bdfe
make[1]: Entering directory `/d/corbenik/host/bdfe'
g++ -c -Wall -Werror -g -DOSSD_TARGET=OSSD_IF_LINUX main.c -o main.o
g++ -c -Wall -Werror -g -DOSSD_TARGET=OSSD_IF_LINUX bdf.c -o bdf.o
g++ -Wall -Werror -g -o bdfe main.o bdf.o
make[1]: Leaving directory `/d/corbenik/host/bdfe'
./host/conv-font-bin.sh
mkdir -p out/corbenik/bits
cp host/termfont.bin out/corbenik/bits/
...
make -C bits
make[2]: Entering directory `/d/NTR/corbenik/external/bits'
arm-none-eabi-as -o backdoor.o backdoor.s
arm-none-eabi-ld -T link.ld -o backdoor.elf backdoor.o
arm-none-eabi-objcopy -O binary backdoor.elf backdoor.bin
arm-none-eabi-as -o stub.o stub.s
arm-none-eabi-ld -T link.ld -o stub.elf stub.o
arm-none-eabi-objcopy -O binary stub.elf stub.bin
arm-none-eabi-as -o emunand.o emunand.s
arm-none-eabi-ld -T link.ld -o emunand.elf emunand.o
arm-none-eabi-objcopy -O binary emunand.elf emunand.bin
arm-none-eabi-as -o reboot_hook.o reboot_hook.s
arm-none-eabi-ld -T link.ld -o reboot_hook.elf reboot_hook.o
arm-none-eabi-objcopy -O binary reboot_hook.elf reboot_hook.bin
arm-none-eabi-as -o reboot_code.o reboot_code.s
arm-none-eabi-ld -T link.ld -o reboot_code.elf reboot_code.o
arm-none-eabi-objcopy -O binary reboot_code.elf reboot_code.bin
rm stub.elf backdoor.o reboot_code.o reboot_hook.elf emunand.o reboot_code.elf backdoor.elf reboot_hook.o emunand.elf stub.o
make[2]: Leaving directory `/d/corbenik/external/bits'
make -C screeninit
make[2]: Entering directory `/d/corbenik/external/screeninit'
arm-none-eabi-gcc -Wall -Wextra -MMD -MP -mthumb -mthumb-interwork -mcpu=mpcore -mfloat-abi=hard -fno-builtin -std=c11 -Wno-main -O2 -flto -ffast-math -c -o build/main.o source/main.c
arm-none-eabi-as -mcpu=mpcore -mfloat-abi=hard -o build/start.o source/start.s
arm-none-eabi-gcc -nostdlib -T linker.ld -o build/screeninit.elf build/main.o build/start.o
arm-none-eabi-objcopy -S -O binary build/screeninit.elf build/screeninit.bin
make[2]: Leaving directory `/d/corbenik/external/screeninit'
mkdir -p ../out/corbenik/module
mkdir -p ../out/corbenik/bits
mkdir -p ../out/corbenik/bits
cp loader/loader.cxi ../out/corbenik/module/loader.cxi
cp bits/backdoor.bin ../out/corbenik/bits/backdoor.bin
cp bits/emunand.bin ../out/corbenik/bits/emunand.bin
cp bits/reboot_hook.bin ../out/corbenik/bits/reboot_hook.bin
cp bits/reboot_code.bin ../out/corbenik/bits/reboot_code.bin
cp screeninit/build/screeninit.bin ../out/corbenik/bits/screeninit.bin
make[1]: Leaving directory `/d/corbenik/external'@chaoskagami
I don't know what you did and what i did, but it's compiling fine again under windows 10 x64 from command prompt! (don't even need cywin shell to build)
even with latest ctrulib installed
MinGW is a lot better than cygwin in my opinion. I didn't even need to rewrite some of the sh to bat, because MinGW comes with a bunch of gnu tools, like grep.
My Micro SD setup
My Micro SD setup
What's wrong with it? Does this happen because of EmuNAND being not right after the FAT32 partition?
NAND takes up 3866624 sectors so the first sector of NAND is X+0 and the last one is X+3866623 (0 - 3866623 total 3866624 sectors together). Since X+3866623=62333951, X=58467328. That's why I used this sector as a start one
Same junk size. Should test it with RedNAND later (since my New 3DS has 1.9G EmuNAND/1.2G RedNAND)
NAND takes up 3866624 sectors so the first sector of NAND is X+0 and the last one is X+3866623 (0 - 3866623 total 3866624 sectors together). Since X+3866623=62333951, X=58467328. That's why I used this sector as a start one
Anyways, tried this with 58467327 start sector and 62333950/62333951 end sectors, got nothing
