#178972 - nocash - Thu May 10, 2018 3:08 pm
Just released unlaunch.dsi v0.8 - Unlaunch is the first ever (released) bootcode exploit for DSi. It's gaining control of the CPUs before even starting the launcher.
Installation should work on all retail DSi consoles, regardless of region or firmware version. The are two installation methods...
Via DSiware exploits: Start "unlaunch.dsi" and click "Install Now".
Via Hardmod: Append "unlaunch.dsi" at the end of the file "title.tmd" in folder ""title\00030017\484E41xx\content" (the "xx" varies per region), and
set read-only attribute for all files in that folder (else some firmware tools will delete them when seeing the modified .tmd file).
Once when installed, it will start "bootcode.dsi" from SD card almost immediately after power-up (eg. that could be renamed dslink.nds file for wifi-uploading code from PC to DSi). Or, if "bootcode.dsi" doesn't exist then it will resume booting the normal firmware (with some patches for skipping healthsafety and unlocking homebrew code).
unlaunch.dsi can be downloaded on the no$gba webpage:
http://problemkaputt.de/gba.htm
unlaunch v0.8 should be stable, but better backup your eMMC before installing it (you should do so anyways before messing with DSi system files).
Code: Select all
v0.8 10 May 2018
- added one more patch wildcard for firmware v1.4.5E
v0.7 08 May 2018
- write-protects ALL files/folders in launcher content folder (xcept . and ..)
- added hotkey: hold button A to skip bootcode.dsi (and force normal launcher)
- installer: moved arm7entry from 37f8000h to 2380000h (better for 4swordhax?)
- when starting bootcode.dsi: skips GIF display, keeps I2C warmboot flag
- added more patches to launcher (rsa) and bootcode (gif instead whitescreen)
- rebuilds whole eMMC Info at 2FFD7BCh (in case destroyed by some exploit)
- uses faster 4bit sdmmc mode (if detected/supported)
- more specific error messages for fat mismatch, bad mbr/vbr, etc
- skips DSi DISPSTAT wait when (trying to) run in NDS mode
v0.6 24 Apr 2018
- write-protects .tmd file (prevent Data Managment from deleting it)
v0.5 23 Apr 2018
- first public release
v000 01 Apr 2018
- discovered exploitable .tmd filesize in bootcode disassembly
#178973 - siamese - Thu May 10, 2018 5:27 pm
I have recently installed your excellent Unlaunch 0.6 which makes HiyaCFW wo rk just fine, looking the great modifications you´ve made on Unlaunch 0.8 makes me ask you this noob question, is there a direct way to upgrade from 0.6 to 0.8? Thanks for your excellent work
#178974 - Apache Thunder - Thu May 10, 2018 5:31 pm
Upgrading Unlaunch is just like installing it on a new system. Just run Unlaunch as your boot.nds file for Sudokuhax or other exploit. Though for me Unlaunch's installer still doesn't run correctly on hardware if booted via 4swordshax. In that case you could launch it through hbmenu instead.
Unlaunch has the ability to replace/update existing installations of Unlaunch.
So just install it like normal. ;)
#178976 - nocash - Thu May 10, 2018 6:30 pm
Yes, for upgrading to newer versions, just run the installer another time (eg. rename unlaunch.dsi to bootcode.dsi on SD card).
I don't have an eMMC image with 4swordhax. Did anybody debug it in no$gba? As far as I know, 4swordhax+unlaunch is working in no$gba (unlike as on hardware), but maybe one can see some uncommon initialization stuff in the debugger (wram mapping, scfg settings, sdmmc state, PU settings, and the like), or try to enable warnings with Ctrl+E, maybe that gives some hints on the issue. I guess uit can't be a big deal when examing the actual binary code (I've also looked at 4swordhax source code - but I've no idea what the various files are supposed to do, and the problem might come from the 4sword game rather than from the source code anyways).
The person that can't get the SD card reading working is the one with the "freshly formatted" SD card, right? I wouldn't know a way to solve that issues, at least not without knowing the MBR/VBR formatting, the card capacity, or results from testing different cards on different consoles.
While looking at sdmmc registers, I've solved the purpose on the "last" used & completely unknown sdmmc register: 40048F6h. It's containing a write-protect flag for eMMC (similar to the write-protect sensor for SD/MMC slot). I don't know if there's a solder pad for that bit on the CPU chip. But the firmware is clearly using that bit for that purpose (it's checking that eMMC or SD/MMC write-protect bits, alongsides with also checking the temporary/permanent write-protect flags in the CSD registers).
#179016 - Apache Thunder - Wed May 16, 2018 6:08 pm
Something that might be related to report. Ahezard was reporting issues with touch screen not working in games booted with patched Launcher via HiyaCFW.
One of the patches you made caused the issue:
Code: Select all
026C4DA6 THUMB.MOV R0,3Eh force supported languages (EUR)
If you have implemented this patch in Unlaunch, users of Jap/Korean consoles may be having problems with touchscreen not working in stuff booted from System Menu.
I'm led to believe you did implement this patch in Unlaunch because I think this user was seeing this issue even on Unlaunch CFW:
[mod note: link to piracy removed]
I think this patch either needs to be changed or removed. I have no idea why this happens but given that it's a minor patch it can probably just be shelved for now. Ahezard is reporting no issues with Unlaunch on Jap region console though. Maybe the Korean one is worse off somehow...
Although maybe the patch was meant to be region specific? I think HiyaCFW only used the "Eur" version of the patch assuming you have other versions of it that are different depending on region of console Unlaunch is being used on. So maybe not impacting Unlaunch. But I don't know how this patch is supposed to work so I thought I'd still bring it up just incase.
#179022 - nocash - Thu May 17, 2018 3:29 pm
Got the SDIO Wifi Firmware upload working! That's probably solving the biggest issue in using the console without the original nintendo launcher. I've already had some code that mimmicked the wifi firmware upload (made when testing how to emulate the upload in no$gba). But it was still a bit more difficult than expected:
SDIO does mainly rely on CMD52 and CMD53, although there are also some init commands (CMD5, plus some normal SD commands). But looking at no$gba SD/MMC (and SDIO) log, one can see that launcher starts right off with CMD52, so I thought that CMD5 isn't needed... but it turned out that the initial CMD52 fails after coldboot - and launcher does then issue CMD5 several times, plus CMD3 and CMD7, and does then go on with the usualy CMD52/53 stuff.
Two other important things are setting BPTWL[30h]=13h (that was known to affect wifi LED, but it's also required for working Wifi/SDIO init), and clearing 4004C04h.bit8 (to select DSi-Wifi instead of NDS-Wifi, else the newer AR6013G chips fail on "SDIO function 1" commands).
Well, and basically that's everything needed. But I screwed up my code (used "ldr r0,[src]" instead of "ldr r0,=src" when setting the wifi database address). So, without realizing that silly mistake... I just realized that it did somehow hang in the WMI phase, and spent another 3 days on trying to find further (hypothetically) required initialization steps (like further SDIO IRQ sources, or initializing the old NDS wifi BB/RF registers, messing with more BPTWL registers, or activating the FOUT signal on the DSi's RTC chip, and so on).
Anyways, it's now working, and only needs some clean-up before release. On warmboot it's quite fast: it's just restarting the already uploaded wifi firmware without noticable delays (except a minimal delay the final WMI handshake). On coldboot, there seems to be huge delay (several 100ms) on uploading the LZ compressed data (especially on DWM-W015 which has a bigger LZ data block) - I am wondering if it would be faster to decompress the LZ stuff on ARM CPU side, and then upload the uncompressed data - of course that should be even slower, but the decompression code on the Xtensa CPU side doesn't really look very professional, and larger uncompressed uploads might be actually faster than compressed uploads... gotta try that.
And the bottom line: I am afraid that nobody will care about it...
Currently the main advantage is that dslink will be working even on DWM-W024 boards right after coldboot (=interesting only for devrs).
The other huge advantage is that SDIO Wifi should be also ready for use (=interesting for future generations only, as there isn't any SDIO Wifi homebrew yet).
The disadvantage is that current customized firmwares won't work (unless resetting the atheros hardware before starting the customized nintendo launcher).
And, well, the average users probably never heard about SDIO and probably hardly care about those advantages or disadvantages at all ; )
---
Oh, and a side note: I've finally dumped the AR6013G Wifi ROM: Used size is around 34000h bytes used, plus C000h trailing zeroes. CRC32 for the full 512Kbyte area is 4B2AF04Dh. Hmmm, so I seem to have ended up being the first person to have dumped the ROMs for AR6002G and (unexpectedly) also AR6013G. Unexpectedly because I had released the open source "dsdump" tool for that purpose about two years ago, but it looks as if nobody ever used it - until I got my own AR6013G chip a few weeks ago : / : )
#179036 - nocash - Sat May 19, 2018 6:16 pm
So I got the wifi firmware init working on both wifi board types, and swapped in the W015 board for final testing, just to make sure that the code still worked with that board - it didn't. It just hangs in WMI handshake : /
After trying to fix it, I swapped back to W024 - that stopped working, too : (
Long story short: The RTC's FOUT pin initialization turned out to be actually required for wifi - but as RTC is battery backed, it's needed only after battery removal. Phew, I already had the feeling that wifi subtly distinguishes between coldboot, warmboot, softboot, and whatever - but I wouldn't have thought that it could depend on battery removal : )
#179039 - Apache Thunder - Sat May 19, 2018 7:51 pm
You mentioned the wifi thing possibly breaking being able to launch custom firmwares. (like HiyaCFW?)
In that case you could simply use a unused region in the NTR header of the SRL to change that option. Would be a good compromise for those who want to use custom firmwares.
I never really thought about Wifi not being available for homebrew booted directly from Unlaunch.... So it's definitely something that would need to be taken care of. But yeah, ability to disable that if needed would be good. Maybe 0x160 region could be used for this. It's an unused gap between the NTR header and the TWL extended header. Checking for a bit here would be good since user can toggle that without having to fix the header CRC. (and it's not like the RSA-SHA1 over at 0xF80 will mean anything with Unlaunch anyways. :P )
#179082 - ahezard - Wed Jun 06, 2018 11:50 pm
Since I have updated to unlaunch 0.8 I have noted a touchscreen issue (no more working on dsiware and cart game) on my JPN dsi xl when I run the unlaunch integrated patched launcher (by removing the sd card).
I have investigated this issue with Apache Thunder and it turns out that non english firmware have this behavior when the following part of the launcher is patched (address is for 1.4 launcher) :
026C4DA6 THUMB.MOV R0,3Eh force supported languages (EUR)
I suppose you integrated this patch or something similar on the latest unlaunch version. Could it be possible to deactivate it? or to have a specific JPN/KOR release (same problem is confirmed on KOR dsi).
#179084 - TheLegendofMario - Thu Jun 07, 2018 9:40 pm
Could you add a Payload loader similar to Luma3DS? So you can name stuff for example " x_(homebrewappname).nds" or "X.nds" or "x_boot.nds" or "X_Bootcode.dsi", but obviously different for each button. It would make running HBmenu and UnLaunch installer easier.
#179089 - nocash - Mon Jun 11, 2018 3:35 pm
Spent some weeks on implementing proper memory and I/O initialization to get the loader for bootcode.dsi compatible with official DSiware titles. It's also initializing sound/touchscreen - which, I think, it didn't yet work with neither homebrew nor official titles, although nobody seems to have noticed that issue.
For DSiware titles, next unlaunch version is creating a proper Device List with "sdmc:/bootcode.dsi" for the executable and "sdmc:/bootcode.pub/.prv" for the public/private.sav data file(s), whereas, I've been using flipnote for testing.
It worked quite well in no$gba, but failed badly on hardware - after some days I figured out that New WRAM wasn't mapped at all - and the reason was MBK9 not working as expected (old theory was that it selects whether "ARM9 or ARM7" may write to MBK1-5, but actually it's selecting "ARM9 or NOBODY", ie. ARM7 can NEVER write to MBK1-5, and only ARM9 can so).
After fixing that, it booted up okay, but complained about "download" error (aka meaning that the .sav file wasn't properly created when "downloading" the game from dsi shop).
Using "nand:/.../public.sav" worked, but mysteriously neither "sdmc:/../public.sav" nor "sdmc:/bootcode.pub" worked : / just when I was about to give up, I figured trying to define "sdmc" prior to defining "dataPub", and that did actually fix the issue!
In other words, Nintendo doesn't support forward references in the Device List, so it's best to move "sdmc" to the first list entry, so one can redirect virtual devices to it. Theoretically one could also redirect "nand" and "nand2" to become virtual devices on "sdmc" (not tested if that's working, as it would cause double-indirections with "virtual-virtual devices).
Apache Thunder wrote:You mentioned the wifi thing possibly breaking being able to launch custom firmwares. (like HiyaCFW?)
Yes, sorts of, but turned out that I've been wrong: The original launcher is issuing a reset via RESET_CONTROL, so it should boot fine even if the wifi firmware was already installed.
The other thing that might break some homebrews is that next unlaunch version is applying more cart header entries (SCFG,MBK,WRAMBANK etc), but that should be easy to fix.
ahezard wrote:I have noted a touchscreen issue... on my JPN dsi xl... turns out that non english firmware have this behavior when the following part of the launcher is patched...force supported languages (EUR)
Yup, that patch is already removed (in next update) for compatiblity with KOR region, good to know that the problem occurred in JPN region as well. The patch was kinda useless anyways (it did unlock european languages - but without actually allowing to select any of those unlocked languages in system settings).
TheLegendofMario wrote:Could you add a Payload loader similar to Luma3DS? So you can name stuff for example " x_(homebrewappname).nds" or "X.nds" or "x_boot.nds" or "X_Bootcode.dsi", but obviously different for each button.
You mean like loading a different file when holding down X button? Already added something like that when testing the flipnote stuff (pressing X causes to load "bootthis.dsi" instead of "bootcode.dsi").
#179090 - Apache Thunder - Mon Jun 11, 2018 9:38 pm
nocash wrote:After fixing that, it booted up okay, but complained about "download" error (aka meaning that the .sav file wasn't properly created when "downloading" the game from dsi shop).
Using "nand:/.../public.sav" worked
Oh yeah, games can't create new sav container files. DSi Shop always does that on install. Even Launcher won't do it for you. If installing a game manually one always had to create a blank sav file of the correct save else the game won't work properly.
As for the MBK thing, yeah I noticed that I couldn't set Arm9's MBK stuff from arm7 when I was initially working on early pre-HiyaCFW loader for booting up custom stage2.
Also MBK registers 6, 7 and 8 have separate values for Arm7 and Arm9? I recall having to set different values for those on Arm9 and having Arm7 write it's own values for those when I was adding code to set MBK to correct values for NTR games with NTR Launcher. I assume you've accounted for this as well?
Being that Unlaunch will be able to start DSiWare, will that include being able to start a custom copy of Launcher? That would be neat and would be able to skip the super hacky method of launching a modified stage2 built into a SRL via HiyaCFW with is basically a stripped down modified version of hbmenu's bootstrap code. Wintermute isn't really happy with how that's being used. :P
Would be nice if we can skip that part. :D
#179091 - nocash - Tue Jun 12, 2018 12:50 am
Apache Thunder wrote:If installing a game manually one always had to create a blank sav file of the correct save else the game won't work properly.
Good that you mention that, I noticed that it needs the sav file to exist (and just used a copy of the eMMC file), but I don't know what
needs to be in the file as minimum requirement...
Does it work with a zerofilled file (without any preformatted FAT12 in it)?
Does it require the file to have the correct filesize (or just need the filename to exist in directory)? Well, I guess it's better to have the right filesize anyways, to prevent problems when the SD card is full & the file is too small).
Apache Thunder wrote:Also MBK registers 6, 7 and 8 have separate values for Arm7 and Arm9?
Yes, MBK6-8 are separate registers on ARM7 and ARM9 side. The other's are single registers mirrored to both sides. The access rights are a bit zigzagged, MBK1-5 being writeable by ARM9 only, but ARM7 being able to write to MBK9, and that can be used to prevent ARM9 from writing MBK1-5.
On a side-note: Bit24-25 of the "MBK9" value in cart-header are copied to ARM9 WRAMCNT register (for ROM carts that should be always 03h, otherwise the ROM cart would encounter different mapping on NDS vs DSi consoles; but for DSiware/DSiFirmware titles it can be other than 03h).
Apache Thunder wrote:Being that Unlaunch will be able to start DSiWare, will that include being able to start a custom copy of Launcher?
Theoretically yes, but at the moment I've tested flipnote only. And the launcher is a bit special as it requires a few extra incoming parameters in memory (eg. the keys in wram/itcm), though, the other way around, it does need less pre-initialization than DSiware's since it's doing that stuff on it's own.
Anyways, I am close to having reproduced the whole functionality of the launcher - so one won't really need the original launcher anymore (if I get around to add a title select menu allowing to boot titles from SD, eMMC, or ROM cartridge slot) (plus some internal stuff for switching to NDS mode when needed, and parsing long filenames for DSiware on SD/MMC to short filenames; for squeezing them into the 64-byte device list entries).
#179092 - Apache Thunder - Tue Jun 12, 2018 1:59 am
Oh neat. A Launcher replacement would be pretty cool. Would free one from the 39 title limit and the hard coded nand capacity limit (Can SD redirect to large SD cards, but Launcher errors out when you use more space then what nand normally has)
As for the save files having to be present. I've been able to get away with blank zero filled files. The game is able to fill the file with the correct data. The only requirement is the file has to be present and the correct size as defined in the DSi extended header region that defines the public/private save size. (have not tested apps that require private.sav, but I assume that would work in a similar manner)
Loading launcher may work provided you aren't clearing those keys from ram/itcm. I recall I no longer needed to write the keys back with Unlaunch in HiyaCFW's launcher (though I now skip the launcher and just load the stage2 SRL directly with Unlaunch). I didn't even have to alter MBK registers or place anything in ram before hand.
But perhaps that could change with Unlaunch 0.9. You could always check for Launcher's game code in the NTR header when going to boot an SRL and do a little less init stuff and keeping ram/itcm keys in place.
Also I hope you make the DSiWare Launcher replacement a seperate SRL at some point. WOuld be nice to see that working on 3DS as well. I have not been able to get Stage2 to boot correctly on 3DS. Shows an error code. I recall a year back I managed to get it to boot Launcher (but launcher would halt on error). But I don't remember how I managed that. I might have inserted Stage2 as an SRL directly into the twlBg CXI which normally contains the stripped down dev Launcher. (TWL_FIRM has a proper boot2/stage2 section stored in twlBG's ExeFS code like with dev launcher but there isn't enough room for the full retail stage2. :( )
I tried redirecting stage2 to SD like on DSi to avoid the crypto related issues I would have on 3DS since twlN partition crypto is a bit different then on 3DS. No dice yet. Could avoid all that if your launcher replacement could run on 3DS too. :D
#179093 - wintermute - Tue Jun 12, 2018 11:56 am
Apache Thunder wrote:[HiyaCFW with is basically a stripped down modified version of hbmenu's bootstrap code. Wintermute isn't really happy with how that's being used. :P
What I'm not happy with is people taking carefully constructed code, bodging the life out of it and turning it into a complete maintenance nightmare.
Ultimately the thing I care most about is that people can use devkitARM + the supporting libraries to make their own apps easily. When you com along, fork stuff, change stuff around so it can never be upstreamed then use it to promote yourself without even bothering to acknowledge just how much of a head start you got thanks to years of work I put into this then I get annoyed.
You have no idea how much of my time gets sucked away trying to help people who have ended up in a mess because of people forking toolchain related things and/or building unmaintainable things on top of the them.
In some cases people have had to reinstall their entire OS because of some insane tutorial (and I really wish I was joking).
There are at least a dozen consoles that will
never work again because of inappropriate hackery made to fwTool, including several 3DSes.
There are other things that seriously annoy me about "the scene" but one of the worst is people taking code I made public then using it to try and compete and having the brass neck to ask for donations for all the work they put in -
especially when they provide instructions that wreck a perfectly functioning toolchain install.
#179094 - Apache Thunder - Tue Jun 12, 2018 2:36 pm
- Snip - - EDIT -
Wintermute, I'm not going to get argue about this here. It's off topic.
#179096 - nocash - Thu Jun 14, 2018 5:06 pm
Triple update: no$gba + wifiboot + unlaunch
http://problemkaputt.de/gba.htm
Best update all three files (they are each improving handling dsi cartridge header entries, and may be incompatible with their older revisions (among others because wifiboot+unlaunch lacked some cart header entries)).
No$gba - the emulation (and gbatek specs) are now covering more ARM7 SCFG registers, ie. stuff that was rev-engineered after unlaunch allowed to mess with those SCFG registers.
Code: Select all
no$gba - 14 Jun 2018 - version 2.9
- webpage: added credit card payment option - plz send money if you like my work
- dsi/exploit: released unlaunch.dsi (first ever released dsi bootcode exploit)
- utility/upload: added dslink-compatible wifi upload function (nds/dsi only)
- utility/upload: wifiboot 2.1 dslink-clone (proper cache init/initback)
- utility/upload: wifiboot 2.0 dslink-clone (dwm-w024 and arm7i/arm9i areas)
- dsi/emu/cartloader/help: takes WRAMCNT from MSBs of MBK9 entry in cartheader
- dsi/emu: mirrors read-only SCFG_EXT7 bits from SCFG_EXT9 and vice-versa
- arm/cpu/help: notes on cache clean vs invalidate and cache-write-bufferability
- dsi/help: added caution of forward references in Device List structure
- dsi/cartloader: rejects large modcrypt areas (eg. crypt.size>arm7i.size)
- dsi/cartloader: supports small modcrypt areas (eg. crypt.start>arm7i.start)
- dsi/modcrypt/help: added notes of several weird modcrypt corner cases
- arm/debug: I/O map cpmem9 shows PU dc/cc/wb (data/code cache and wbufferable)
- spi/powerman: emulates dslite/dsi registers: powerman[4] and powerman[10h]
- dsi/korea/help: notes korean font file (diff names, crisp clear, less tiles)
- dsi/korea/help: korean firmware version numbering as in china, 1.4.6 is newest
- dsi/help: added note on smaller cert.sys files (for korea or before dsi-shop?)
- dsi/wifi/emu: emulates sdio cmd5,cmd3,cmd7,cmd15 and reset_control.bit8
- nds/wifi/help: added description for 48080DAh W_RX_LEN_CROP register
- dsi/wifi/help: sdio init via cmd5,cmd3,cmd7,cmd15, rtc.fout, scfg/gpio etc
- dsi/wifi/help: added sdio pins on daughterboard and pinout for ar6013g chip
- dsi/sdmmc/help: described 40048F6h (bit0 = SD_WRPROTECT_2 for eMMC chip)
- dsi/scfg/help: details on scfg_ext7 and scfg_a7rom, updated mbk chapter
- dsi/scfg/emu: emulates scfg_ext7 and scfg_a7rom access right bits
- dsi/scfg/emu: emulates arm9.mbk1-5 writes in respect to arm7.mbk9 setting
- dsi/emu: removed most in_32 notyet warnings, added more out_xx notyet warnings
- dsi/mmc/emu: warning if .mmc file without footer (need CID and Console ID)
- dsi/help: added notes on bits in SCFG_A9ROM/A7ROM being set-once bits
- dsi/wifi/help: described 4004C04h.bit8 needed for DWM-W024 in NDS-wifi mode
- dsi/sdmmc/help: notes on SEND_OP_COND, and on ALL_GET_CID vs max CARD_CLK_CTL
- dsi/exploits/help: added some notes on recently released exploits and tools
- dsi/biosdumping/help: notes on voltage errors and CE2 idea from dark_samus
- dsi/help: added info on valid ARM9+ARM7+ARM9i+ARM7i areas for NDS and DSi mode
- dsi/help: added info on RSA signatures for newer non-whitelisted NDS carts
- dsi/carthdr/help: added notes on Access Control entry (request AES keys)
- dsi/carthdr/help: digest, modcrypt, twl-total can be ZERO (optional entries)
- dsi/sdmmc: added provisions for SDHC emulation, filesys viewer supports FAT32
- arm9/emu: allows exception vectors at 00000000h or FFFF0000h (thanks dave)
- dsi/help: added details on ECC keys/certificates (using ECC curve sect233r1)
- carthdr/help: added some more cart headers entries for dsi (and nds with rsa)
- help: specs for DSi RTC extras (up counter, alarm date, and FOUT selection)
- debug/elf: processes/skips dwarf4/dwarf5 DW_FORM tags (for homebrew PSX games)
Wifiboot (aka dslink clone) - contains some new initialization stuff, including support for modcrypt/blowfish encrypted files (or throwing a warning message on encrypted files if the blowfish key isn't available).
And, no$gba utility menu does now how have a wifi upload function (select Wifi instead of a Parallel Port number in no$gba setup, then press Alt+U, U, and there you go).
Code: Select all
wifiboot v2.1 - 14 Jun 2018
- added valid DSi cart header (needed to be sure to stay in DSi mode)
- supports blowfish/secure_area (requires rom/itcm) and modcrypted dsi areas
- supports SCFG, MBK's, WRAMBANK settings from dsi cart header
- supports "cleaning" dirty cache lines (for PU cache write-bufferability)
Unlaunch - contains similar initializations as in wifiboot, and all those important power-up initializations for the Wifi+Touchscreen+Sound hardware.
Two things yet uninitialized are Camera and Teak (whereof, Launcher doesn't do any relevant Teak init either, yet it does some Camera init, but not sure if camera titles do rely on that, or if they reproduce the same init on their own (what I've tested is running my own homebrew camera viewer, and at least that worked fine - so it shouldn't be too difficult to get commercial camera titles working if there are any problems with them)).
Code: Select all
unlaunch.dsi v0.9 - 14 Jun 2018
- creates device list in ram (with names sdmc:/bootcode/bootthis.dsi/pub/prv)
- uses lz77 compressed arm9 code to squeeze all new features into 80kbyte file
- moved gif decoder buffer to address not conflicting with cart loader
- loads TWLCFG0.dat, HWINFO_S.dat, and HWINFO_N.dat to main ram structures
- added touchscreen/sound controller init (required for working sound output)
- new patch: prevent original launcher from black-filling engine-a-palette
- proper cache init/initback with cleaning dirty lines before invalidating
- supports blowfish/secure_area (requires rom/itcm) and modcrypted dsi areas
- loader: applies cartheader MBK values for entry and for arm7/arm9 loading
- loader: applies cartheader WRAMBANK and SCFG_EXT7 values before entry
- added hotkey: hold button X to load "bootthis.dsi" instead of "bootcode.dsi"
- removed patch supported languages (caused touchscreen issues in korea/japan)
- initializes wifi related hardware (rtc.fout, bptwl[30h], gpio_wifi)
- uploads wifi firmware before starting bootcode.dsi (cmd5/upload/init/wmi)
#179097 - Apache Thunder - Thu Jun 14, 2018 5:38 pm
Ok, my DSi is not available for testing at the moment, but tried it on 3DS. I did manage to get Unlaunch 0.8 to run on 3DS by converting Stage2 into a CIA (using similar parameters as Launcher except I use Stage2's MBK values in the header). This version of Stage2 has the SD redirect patch so I don't have to deal with TWL_FIRM's odd crypto scheme with TWLN which isn't quite the same as on DSi.
It will even boot Launcher. But Launcher sits on white screen for a bit then shows error screen. Maybe related to the next part regarding how 0.9 behaves. (this is also a SD patched Launcher so I have all my system files on SD instead to avoid crypto issues with 3DS's version of DSi nand)
0.9 no longer works on 3DS. Hangs on the "Cannot load Wifi Firmware" error. So unless this part becomes optional in some way in 1.0 Unlaunch, I can no longer test it on 3DS. :(
Also with Unlaunch 0.9 we can no longer load SD patched Launcher from SD. Looks like we'd have to use SD patch on Launcher that's on nand instead. Something new you added breaks HiyaCFW/reloading of stage2 to allow launching a custom CFW instead of Unlaunch CFW. :(
Maybe still show this error, but allow skipping it with start button or something? I think uploading wifi firmware may not be a thing on 3DS which is why Launcher shows error when booted via 0.8 Unlaunch. (I did ensure some files required for normal boot are present on twln partition. On 3DS, twln partition is missing twlcfg files and sys folder stuff as well as not containing anything in ticket folder due to CTR nand containing the tickets instead)
As I recall my patched SD redirected Launcher no longer cares about tickets not being present so I know missing tickets aren't the issue and with Unlaunch'es patches as well. I only added SD redirect patch to the version of Launcher I'm starting with Unlaunch to avoid conflicts with your patch system and as I recall on my DSi I was able to install NTR Launcher to nand without a ticket with Unlaunch 0.8.
As for Launcher not booting up on 3DS, might be due to wifi firmware thing or perhaps region. I do know TWL_FIRM reports as "A" in the region byte when checking the firmware version in DSi System Settings. HNAA is the game code for dev launcher built into TWL_FIRM's twlbg process. Stage2 even attempts to boot a HNAA version of Launcher as I had to name the folder path to match that to ensure it loads the TMD with the unlaunch payload. It might also be mistaking it for a dev DSi because 32MB ram mode is available on TWL_FIRM. DSiWare doesn't seem to care about this normally though else people wouldn't be able to run their DSiWare games on 3DS...
Since I can't generate a matching HWINFO_S.dat combo on 3DS as it's not normally present on TWLN partition, I reuse one from my DSi. Stage2 won't boot Launcher due to this. I only get Launcher to start via Unlaunch 0.8. But no longer via 0.9 due to the wifi error you added. :(
Also, can you clarify on what filenames/paths it expects for bootcode.dsi and the related sav files seeing that you are setting up device list as well so that DSiWare could possibly be booted with this.
#179098 - nocash - Thu Jun 14, 2018 7:15 pm
I didn't knew that people were using unlaunch on 3DS, and don't what that would be good for (?) - except for testing if it's working.
Or is there some good reason for using unlaunch on 3DS? I thought 3DS already had some way to run DSiware/homebrews.
Wifi Firmware should be a different version on 3DS, but maybe it's installed just the same way as on DSi. Does the wifi firmware file exist at all, ie this file:
\title\0003000f\484e4341\content\000000vv.app ?
I think somebody mentioned that 3DS has similar data stored in some FIRM file, so I guess the above .app file doesn`'t exist there.
Also possible that 3DS had already initialized wifi before switching to DSi mode - so one could skip wifi init completely.
The other new files loaded are:
\sys\HWINFO_S.dat
\sys\HWINFO_N.dat
\shared1\TWLCFG0.dat
Do any of that three files exist on 3DS? I don't know if games are allowed to access that files, or if they are restricted to access the copies of that files in RAM. In the latter case, it's perfectly correct to load them within unlaunch so games could use the RAM data (at least so on DSi, on 3DS it may be different).
Filenames are x:\bootcode.dsi x:\bootcode.pub x:\bootcode.prv for the executable and public.sav private.sav files. When pressing X it's bootthis instead bootcode accordingly.
At the moment that feature is mainly for myself testing if I were able to load flipnote. If somebody could test if it's also working for DSi Camera or DSi Browser or ither stuuf would be interesting.
For Launcher: I think launcher ignores the incoming Device List (so it won't use x:\bootcode.dsi x:\bootcode.prv unless you have patched it do so).
Okay, aside from 3DS issues... I hope unlaunch v0.9 works on all all DSi versions/firmwares and with all DSi exploits (current version newly relies on the cart header being present at 2FFFE00h, which might cause troubles with some exploits? on the other hand, the new cache init might fix the issue in 4swordhax?)
#179099 - Apache Thunder - Thu Jun 14, 2018 7:48 pm
The files not present on 3DS are the hwinfo dat files, shared1 folder, and most of the sys folder. Only the the font table file is present as well as the log files (even though I don't think TWL_FIRM ever writes to them)
Right now I'm the only one really testing Unlaunch on 3DS. I had brought it up only because I had revisted trying to get DSI System Menu to boot up on 3DS which currently doesn't want to work. Either do to odd region detection of TWL_FIRM/thinking it's on dev console or due to the wifi thing.
I don't think the wifi firmware SRL is normally present on 3DS. I did install it though as I did a full system update from within DSi System Settings on 3DS. (It had issues moving the SRLs to their final locations which I had to do manually with each SRL it downloaded, but it did generate valid tickets for them) so the firmware SRL currently on my twln partitions was from DSi System Settings downloading it from NUS. Pretty sure Wifi is always ready on 3DS since boot2/dev launcher probably handle that and that's a component stored internally in TWL_FIRM and isn't something you can skip without heavy modifications to TWL_FIRM.
Using unlaunch on 3DS will only really make sense once you decide to make a menu and do the full on Launcher replacement thing. Users could use it to get around the limitations of 3DS's TWL mode. On 3DS TWLN partition is slightly smaller in size then DSi and is also subject to the 39 title limit just as on DSi. So this could see some use there perhaps. Plus having easy access to saves due to them being present on SD instead of internal nand would make things easier.
Would like to see custom versions of Launcher being bootable off SD like in 0.8. Maybe implement a button combo for doing a straight clean boot of bootcode.dsi without all the extra features added in 0.9? Or just have a simpler load procedure just for Launcher if it detects that bootcode.dsi is Launcher (which could be detected by seeing if the game codes match the ones that Launcher uses). That would allow mods of Launcher with out having to mess with the one installed on NAND. We did try to start Launcher as bootcode.dsi in Unlaunch 0.9, but Ahezard said it didn't work. :(
Shutterbug2000 managed to do some "theming" of Launcher by modifying it to load NitroFS content off SD instead of the SRL. He hasn't released anything for that publicly yet, but that's another thing that would be hard to do in unlaunch 0.9 due to the new loading system. :(
Here's an idea of what something like that would look like:
http://i.imgur.com/ZSw5nR5.jpg
Would be great if we could do that without mucking around with NAND. :D
#179100 - nocash - Fri Jun 15, 2018 1:35 pm
You can't use DSi System Menu on 3DS for the same reasons that unlaunch v0.9 won't work on 3DS. And you can't use the DSi wifi firmware for 3DS wifi hardware.
I could disable some of the new features in unlaunch v0.9 when detecting 3DS hardware, but still not sure what that would be good for - aside from trying to boot DSi System Menu (and that won't work anyways, or if you still want to try that, stick with v0.8 for now).
Apart from 3DS, I am not aware of any issues where things got worse with v0.9 on DSi hardware. Though you seem to suggest to allow to downgrade the v0.9 functionality to v0.8 state for... which reason?
#179101 - Apache Thunder - Fri Jun 15, 2018 4:55 pm
Well as I said. On 0.9 we can't run custom versions of Launche on DSi anymore since we can't get Launcher or Stage2 to run again from Unlaunch since you changed how it loads bootcode.dsi. :(
#179102 - nocash - Fri Jun 15, 2018 8:40 pm
So your stage2 code doesn't work on DSi? You didn't said that. You only said that stage2 doesn't work on 3DS, and that ahezard said that launcher doesn't work on DSi.
Check the cart header for your stage2 stuff, SCFG_EXT bits should be all set, and MBK values should be same as for original stage2.
#179103 - Apache Thunder - Fri Jun 15, 2018 9:21 pm
Yeah Stage2 has the correct MBK values and SCFG bits. At least most of the ones that matter. You didn't change what code you used to load binaries into ram right? If you switched to nds-bootloader as a base for loading arm binaries into ram then that would break loading stage2 SRL because the stage2 SRL has arm7 and arm9 go to the same ram address. But that ram address is set up by MBK to be unique to each CPU. So arm7 can't load arm9's binary to that address because it would just overwrite arm7's binary at that address since arm7 can't access arm9's version of that address.
Arm9 has to do the load and it looks like with unlaunch 0.8 where it did work you hooked stage2 to load it or used your own code that still ran separately on each CPU?
EDIT: Now that I recall I have a bootstub on arm9 that moves the arm9 binary to the proper location since I couldn't figure out how to get nds-bootloader to do it and I never tested one without that on previous versions of unlaunch. My stage2 binary has arm9 binary load to 0x2000800 The special bootstub was setup to load from that as the entry point so that it can copy the rest of the binary to the final location. it then jumps to it and starts arm9 from there. Possible you changed MPU code in 0.9 and that could be breaking that process?
I don't know if Unlaunch has arm9 load the SRL binary or if you have arm7 do both just like nds-bootloader. If not, maybe try and have arm9 do it. Might solve the problem. But I don't know. I doubt it's the stuff you changed/added regarding the device list stuff since stage2 will just clear ram and reset that with it's own device list entry in preperation of booting Launcher so I'm thinking the MBK/WRAM stuff you added may be breaking it. That and wifi init perhaps.
#179104 - wintermute - Fri Jun 15, 2018 11:15 pm
Please note that discussion of "backup" loading is off topic in this forum.
http://forum.gbadev.org/viewtopic.php?t=9484
#179107 - nocash - Sun Jun 17, 2018 5:21 pm
