It is currently Fri Sep 20, 2019 3:47 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 119 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Author Message
PostPosted: Sun Jun 23, 2019 2:58 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1007
PSI wrote:
Indeed they do. The XDMA functions take a set of parameters and then create the bytecode based upon those parameters.
Oops, okay, I'll need to look closer (I had looked only for "pre-compiled" code blocks, not for on-the-fly generated code).
Apropos: bytecode. ARM11 could also support "Jazelle" bytecode (additionally to ARM/THUMB/THUMB2). I forgot to ask if 3DS is supporting that Jazelle stuff... does it?

PSI wrote:
Something I found completely mystifying is that when decrypting the FIRM, Boot9 sets two NDMA channels to mode 15 (eMMC->AES, AES->SHA). I use a hackish method to handle this, but I don't know how exactly these channels are supposed to be triggered.

Ah, yes, looks as if they are both running in parallel with the same startup mode. To some level that might work if AES is so fast that AES->SHA can be started immediately after eMMC->AES. But that would work only if some priority/ordering stuff would ensure eMMC->AES to be executed first, but the bootrom code is doing it excactly the other way around (starting AES->SHA before eMMC->AES (unless I've missed something that might be manually transferring the first block elsewhere)).

How about this: Bit0-9 in NDMAxCNT registers were unused on DSi. But on 3DS, Bit0-4 are R/W (bit5-9 seem to be always 0). The bootrom is using bit3 and bit4 as so:
Code:
eMMC-->AES with startup=0Fh and bit3=1
AES-->SHA with startup=0Fh and bit4=1
I guess that explains how to distinguish between the two channels with same startup mode. I don't know what the bits are doing exactly though. Maybe some extra startup-condition flags? Or a whole set of further startup modes? Possibly used only when bit24-27 are set to 0Fh? Or whatever generic priority/order settings?

With some luck, there might be also a SDIO Wifi startup mode hidden in bit0-4, for use with my ARM9 wifi code : )

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Tue Jun 25, 2019 5:29 am 
Offline

Joined: Sun May 19, 2019 7:01 am
Posts: 5
re: NDMA startup bits

probably, yeah. I guess this mechanism also allows to easily implement DSi compatibility (by simply disabling/masking out the extra bits). as in DSi mode, neither SD/MMC nor AES would be mapped to the ARM9.


Top
 Profile  
 
PostPosted: Wed Jul 10, 2019 5:34 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1007
Released wifiboot v2.6 and no$gba v2.9e
http://problemkaputt.de/wifiboot.htm
http://problemkaputt.de/gba.htm
The main news is allowing to upload 3DS .firm files from no$gba utility menu to 3DS consoles.

That is my first 3DS program : )
And it's even a useful one... at least for people whom are coding .firm files.
Which is probably meaning useful to 3-5 people, but anyways.

I've posted that in the wifi thread, too. See there: viewtopic.php?f=23&t=18065&p=240698 for release notes, and some new extra details on the 3DS (and DSi) wifi firmwares.

fastboot
Uploading fastboot via wifi seems to work fine. Maybe that can be useful for testing new fastboot versions.
The first & last fastboot options seem to hang though (continue booting & credits).
What is continue booting supposed to do? Continue where from, and where to?
In the fastboot filemenu I can see lots of eMMC folders, but don't know if there are any bootable files in any of the folders. Is it possible to boot the GBA/DSi firms? Or would that require further code (for selecting a GBA rom-image, or DSiware title before startingt the gba/nds firm).
It would be nice to be able to boot the 3DS native firm, either from firm1 partition, or from the firm folder (or is continue booting supposed to do that)?

profi200 wrote:
Pressing the power button will do nothing but trigger the MCU interrupt notifying the running OS. When you hold it for at least 3 seconds it will force poweroff after another ~7 seconds.
Yes, seems to work like that. But holding 3 seconds is a bit risky in practice (if you hold only 2.99 seconds then you can wait until your face turns blue and then start all over again), so it's better to try to hold 5 seconds.
I've meanwhile also added code for reading the button state via I2C bus from MCU, allow to power-off by tapping the power button. It's working - almost.

The nasty thing is that one must tap for at least 0.25 seconds or so, and, there seems to be a delayed power-led fade-out effect. It's just enough time that you can turn away without ever knowing if you have really successfully switched off the console, unless you take the time to control the result 1-2 seconds later.
I am normally not the kind of person who is returning home several times to double-check if the lights were really turned off. But this nasty nag-nag-nagging nag-nag-nintendo power button is driving me crazy : [ ; /

Reading between the lines on the I2C register page on 3dbrew, it sounds as if it were possible to dump & disassemble the MCU firmware? Is that right? And is it also possible to install a patched MCU firmware?

If yes, then one could adjust the power button tapping delay. I guess that would be the only way to get the undelayed button state (when displaying the MCU registers, there seem to be no bits getting toggled when pressing the button, unless it's pressed & held for about 0.25s).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Thu Jul 11, 2019 2:08 pm 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 14
Regarding NDMA startup modes: I did a few tests and and these new bits seem to be totally different startup modes probably primarily for device<-->device transfers. Initially i thought maybe they map 1:1 to the regular startup modes + the immediate bit but hey are different. That's all i know.

nocash wrote:
Released wifiboot v2.6 and no$gba v2.9e
http://problemkaputt.de/wifiboot.htm
http://problemkaputt.de/gba.htm
The main news is allowing to upload 3DS .firm files from no$gba utility menu to 3DS consoles.

That's nice. But my primary problem with the code of wifiboot is it's barely useful for the remaining devs working with bare metal since it's 100% asm which is comparable with reverse engineering code (except the symbols are known here) and it's tied to your codebase. So if i wanted to code a bare metal homebrew today that uses WiFi i would look at your code and immediately forget the idea. No offense but that's probably what many will do.


nocash wrote:
fastboot
Uploading fastboot via wifi seems to work fine. Maybe that can be useful for testing new fastboot versions.
The first & last fastboot options seem to hang though (continue booting & credits).
What is continue booting supposed to do? Continue where from, and where to?
In the fastboot filemenu I can see lots of eMMC folders, but don't know if there are any bootable files in any of the folders. Is it possible to boot the GBA/DSi firms? Or would that require further code (for selecting a GBA rom-image, or DSiware title before startingt the gba/nds firm).
It would be nice to be able to boot the 3DS native firm, either from firm1 partition, or from the firm folder (or is continue booting supposed to do that)?

It should not hang at all. Since it's working with every other known chainloader i'ts likely a bug on your end. Do you properly disable and flush caches before jumping to the FIRM entrypoints? Especially the ARM11 needs this since it apparently still has icache hits even after the icache is disabled(?). At least it behaves strangely if you don't do proper cache maintenance which i have seen many times in the past.

Continue is exactly what it says. If the bootloader got interrupted by holding HOME to show the menu it will continue booting the boot slot it would have booted without holding HOME. It will boot nothing by default. You need to configure the boot slots. And it can't boot anything but FIRM files (it can also boot from the second FIRM partition (firm1) but his is not normally enabled to protect noobs (hint: A special key combo on the credits screen)). As said GBA and DS(i) mode has not been looked into much and there is no known open source implementation of AGB/TWL_FIRM.

nocash wrote:
Yes, seems to work like that. But holding 3 seconds is a bit risky in practice (if you hold only 2.99 seconds then you can wait until your face turns blue and then start all over again), so it's better to try to hold 5 seconds.
I've meanwhile also added code for reading the button state via I2C bus from MCU, allow to power-off by tapping the power button. It's working - almost.

I don't understand your problem? Hold the button, slowly count up to 3 and done? Works 95% here.

nocash wrote:
The nasty thing is that one must tap for at least 0.25 seconds or so, and, there seems to be a delayed power-led fade-out effect. It's just enough time that you can turn away without ever knowing if you have really successfully switched off the console, unless you take the time to control the result 1-2 seconds later.
I am normally not the kind of person who is returning home several times to double-check if the lights were really turned off. But this nasty nag-nag-nagging nag-nag-nintendo power button is driving me crazy : [ ; /

???? For real i don't get it.

nocash wrote:
Reading between the lines on the I2C register page on 3dbrew, it sounds as if it were possible to dump & disassemble the MCU firmware? Is that right? And is it also possible to install a patched MCU firmware?

If yes, then one could adjust the power button tapping delay. I guess that would be the only way to get the undelayed button state (when displaying the MCU registers, there seem to be no bits getting toggled when pressing the button, unless it's pressed & held for about 0.25s).

Disclaimer: I'm not responsible if you permanently brick your 3DS. Yes IT IS THAT DANGEROUS! There are no checks whatsoever and if the firmware is bricked to the point the firmware upload fails there is no known way to recover it even externally.

MCU firmware images can be found in the MCU system module code (iirc). Upload is writing a magic value immediately followed by the entire image. I have never done it and you should neither. There is not even an emulator to test the MCU firmware. All the propritary ones are for different MCUs and not this apparently custom design (which is based on some other MCU but it's not the same!). Architecture is RL78.


Top
 Profile  
 
PostPosted: Sat Jul 13, 2019 3:21 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1007
Fastboot credits hangs, but it recovers when pressing B button. I assume that it is displaying something on the top screen during the hang? (which could be seen only when having working top screen backlight connector).
Continue booting just hangs. I didn't press HOME at all, but yes, I haven't selected anything, so if it is supposed to boot nothing by default, then the hang might just be the intended effect. For the caches, I am doing this on ARM9 and ARM11 before booting the uploaded .firm file:
Code:
for3ds_flushdisable_code_cache:
 mov  r0,p15,0,c1,c0,0                  ;\
 bic  r0,1 shl 12  ;code cache          ;
 mov  p15,0,c1,c0,0,r0                  ;/
 mov  r0,0                                                      ;\
 mov  p15,0,c7,c5,0,r0 ;=0 ;Invalidate Entire Instruction Cache ;/
 bx   lr
I hope that is properly disabling the 3ds code caches? For the data caches, I didn't even try to enable them yet since that would require setting up PU on ARM9, and MMU on ARM11.

NDMA registers SAD/DAD/TCNT/WCNT are having a weird effect: They "fail" when doing a R/W test on the I/O area (making it appear as if the registers were read-only, even when the DMA was stopped, but that can't be true).
That odd effect is caused by NDMAGNT.bit0=1, but it works as normal (=as on DSi) when clearing that bit. The bit affects "SAD/DAD/TCNT/WCNT register reading (0=Return written value, 1=Return current value)".
The written values are the "start/reload" values that remain unchanged during/after transfer. The current values are internal registers that get (re-)loaded at transfer start, and increase/decrease during transfer.

Source code I am familar with people saying that I am a non-free coder when not releasing my source code, this was the first time that somebody had objections when I did release the sources. The difference between bare metal and 100% asm is also new to me. You got me pretty shaken up emotionally yesterday ; )
With my source code with labels & gbatek dsi wifi specs, it might take 1-2 weeks to implement wifi. Without that, I don't know, it took me about 3 years to figure out how to use the sdio stuff, but maybe the workforce of the 3ds community could do it in less time.
Anyways - if there are really those remaining devs that want to use wifi - I could answer questions, and I can also add some comments about the source code structure...
The 3DS related stuff is marked as "target_3ds" (which should be a non-issue), the SDIO stuff is marked "with_dsi_wifi" (that's also pretty simple when knowing how to use which BMI and WMI commands; but it's getting a bit more complex because WPA/WPA2 EAPOL packets must be handled manually, but that's all documented in gbatek).
The source is organized in chapters with ;: markers (eg. load wificore.a22 in No$gba -> Utility -> Edit File, then press F6+C to see what I mean. If they really want to do C coding then they could use existing code for TCP/UDP/ARP/DHCP stuff (eg. use the dswifi arm9 code, or something else), and it appears to be common to use polarssl for MD5/SHA1/AES in dsi/3ds in scene, ie. they could just ignore more than 80% of my asm code. But my best recommendation would be to port their codebase to asm. NDS wifi is marked as "with_nds_wifi" one could omit that on 3DS (and DSi).

Wifiboot binary: Did somebody test the wifiboot.firm file on 3DS? It would be interesting if it's working over there, too, especially the WPA/WPA2 part (in the 3DS version, I've currently tested WEP only).
Of course, feedback on DSi wifiboot would be also nice, ie. feedback if it's working with other access points (other than the ones that I had used at home).

Power button: Part of the problem is that it's not just the LED refusing to go off immediatly, it's also the whole screen keeping to display a picture a while after power off. As workaround, I'll clear the framebuffer (or better disable backlights) before power-off, so the user gets some sense that the button was tapped long enough.
Ah, I just noticed that fastboot is using that trick, too. So I guess somebody there must have been struggling with the unresponsive button, too.
Hmmm, for a reboot without power-off, I should probably go into using the HOME button; assuming that it is sorts of intended for such purposes (*). The person who had donated the 3DS said the HOME button was a bit worn out... but it seems to be still working (in a more responsive way than the power button).
(*) as far as I remeber it does bring up a japanese message box (so I am still scared about fiddling with that button).

Architecture is RL78. Thanks, that's very useful to know! Alright, I've written a disassembler for it yesterday, and found an old message from somebody mentioning where to find the code block in the MCU .app files. The disassembly looks okay... except, there seem to be 1000h bytes missing in the middle of the code block (or is it two blocks?), the reset vector is fine, but the other exception vectors point to 4Axxh (whilst the actual handlers show up at 3Axxh).
The "custom design" thing is for the SFR hardware registers & things like I2C and GPIO bits? Is that part of the hardware already rev-engineered & documented on 3dbrew, or elsewhere?
EDIT: https://3dbrew.org/wiki/Hardware has two broken links for "RL78 ISA" and "RL78 hardware manual (registers)" are that docs still available somewhere?
If I can brick the console via MCU writes, that might be a nice way to get rid of it ; ) especially as the upper backlight is already broken anyways.

Btw. if somebody wants to donate a 3DS-console (or New3DS.XL-mainboard with intact top-screen connector): I would be very interested in both (two or three games would be also nice to get an idea about what the console is good for).
Doing rev-engineering with lower-screen-only is possible - but the viewing angle is terrible (I have put the console onto a cardboard box on the floor so I can see something; but with working top-screen I could just have it located in front of me on the table (and it might also become easier to reach for the power button that way)).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sat Jul 13, 2019 5:11 pm 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 14
nocash wrote:
Fastboot credits hangs, but it recovers when pressing B button. I assume that it is displaying something on the top screen during the hang? (which could be seen only when having working top screen backlight connector).
Continue booting just hangs. I didn't press HOME at all, but yes, I haven't selected anything, so if it is supposed to boot nothing by default, then the hang might just be the intended effect. For the caches, I am doing this on ARM9 and ARM11 before booting the uploaded .firm file:
Code:
for3ds_flushdisable_code_cache:
 mov  r0,p15,0,c1,c0,0                  ;\
 bic  r0,1 shl 12  ;code cache          ;
 mov  p15,0,c1,c0,0,r0                  ;/
 mov  r0,0                                                      ;\
 mov  p15,0,c7,c5,0,r0 ;=0 ;Invalidate Entire Instruction Cache ;/
 bx   lr
I hope that is properly disabling the 3ds code caches? For the data caches, I didn't even try to enable them yet since that would require setting up PU on ARM9, and MMU on ARM11.

Yeah, duh when the topscreen is broken of course it appears as if it would hang but it's displaying on the topscreen. Continue should display an error (on the topscreen) if there is no slot configured.

On ARM11 there is a bit more to do than on ARM9 because the pipeline and stuff changed: https://github.com/derrekr/fastboot3DS/ ... art.s#L226
At the beginning of that file i embedded a bit of documentation for the control register bits.

nocash wrote:
NDMA registers SAD/DAD/TCNT/WCNT are having a weird effect: They "fail" when doing a R/W test on the I/O area (making it appear as if the registers were read-only, even when the DMA was stopped, but that can't be true).
That odd effect is caused by NDMAGNT.bit0=1, but it works as normal (=as on DSi) when clearing that bit. The bit affects "SAD/DAD/TCNT/WCNT register reading (0=Return written value, 1=Return current value)".
The written values are the "start/reload" values that remain unchanged during/after transfer. The current values are internal registers that get (re-)loaded at transfer start, and increase/decrease during transfer.

Not tested beyond what i said. The regs seem to be a bit buggy anyway. At least the CNT reg doesn't always keep the exact bits written for some reason. But i'm not sure since it was years ago i noticed this.

nocash wrote:
Source code I am familar with people saying that I am a non-free coder when not releasing my source code, this was the first time that somebody had objections when I did release the sources. The difference between bare metal and 100% asm is also new to me. You got me pretty shaken up emotionally yesterday ; )
With my source code with labels & gbatek dsi wifi specs, it might take 1-2 weeks to implement wifi. Without that, I don't know, it took me about 3 years to figure out how to use the sdio stuff, but maybe the workforce of the 3ds community could do it in less time.
Anyways - if there are really those remaining devs that want to use wifi - I could answer questions, and I can also add some comments about the source code structure...
The 3DS related stuff is marked as "target_3ds" (which should be a non-issue), the SDIO stuff is marked "with_dsi_wifi" (that's also pretty simple when knowing how to use which BMI and WMI commands; but it's getting a bit more complex because WPA/WPA2 EAPOL packets must be handled manually, but that's all documented in gbatek).
The source is organized in chapters with ;: markers (eg. load wificore.a22 in No$gba -> Utility -> Edit File, then press F6+C to see what I mean. If they really want to do C coding then they could use existing code for TCP/UDP/ARP/DHCP stuff (eg. use the dswifi arm9 code, or something else), and it appears to be common to use polarssl for MD5/SHA1/AES in dsi/3ds in scene, ie. they could just ignore more than 80% of my asm code. But my best recommendation would be to port their codebase to asm. NDS wifi is marked as "with_nds_wifi" one could omit that on 3DS (and DSi).

I'm not saying you should not release your source code. Rather the opposite. The only problem is it's not compatible with any other existing code which forces us to basically "reverse engineer" your code and write our own version. And bare metal doesn't mean writing everything in asm :wink: I would go as far as saying 95% of bare metal code written after 2000 is C and a little bit of C++. You can see we have only written small parts in asm in fastboot3DS because these parts are better handled that way than a higher level language.

polarssl is not needed. We have a full implementation of all the crypto hardware in https://github.com/derrekr/fastboot3DS/ ... e/crypto.c
For AES there is even DMA support. Software AES and SHA1/256 i tried many years ago and i can tell you you don't want that (it's slower than a slug). Also on a side note SHA combined with NDMA takes twice as long as with CPU for some reason. Possibly SHA has a bug slowing down DMA.

nocash wrote:
Wifiboot binary: Did somebody test the wifiboot.firm file on 3DS? It would be interesting if it's working over there, too, especially the WPA/WPA2 part (in the 3DS version, I've currently tested WEP only).
Of course, feedback on DSi wifiboot would be also nice, ie. feedback if it's working with other access points (other than the ones that I had used at home).

Not tried yet. Personally i wanted to make myself a hardware assisted FIRM uploader/debugger for a while using the SPI interface of the gamecard slot. That thing can go up to 16 MHz with the new "CARDSPI" interface and even supports "quad SPI" so it's plenty fast. CARDSPI has been fully figured out by the way and 3dbrew has been updated with all details including a little bug.

nocash wrote:
Power button: Part of the problem is that it's not just the LED refusing to go off immediatly, it's also the whole screen keeping to display a picture a while after power off. As workaround, I'll clear the framebuffer (or better disable backlights) before power-off, so the user gets some sense that the button was tapped long enough.
Ah, I just noticed that fastboot is using that trick, too. So I guess somebody there must have been struggling with the unresponsive button, too.
Hmmm, for a reboot without power-off, I should probably go into using the HOME button; assuming that it is sorts of intended for such purposes (*). The person who had donated the 3DS said the HOME button was a bit worn out... but it seems to be still working (in a more responsive way than the power button).
(*) as far as I remeber it does bring up a japanese message box (so I am still scared about fiddling with that button).

We always clear all framebuffers before turning on the screens. On poweroff we first turn off the screens because it will shutdown noticeably faster that way. The delay is there to make the screens go black before they turn off because otherwise they seem to show a bit of garbage until all pixels have reset themselfes. This is not a big deal in my opinion but derrek wanted that. It's not visible normally anyway until you shine a flashlight on the screens.

nocash wrote:
Architecture is RL78. Thanks, that's very useful to know! Alright, I've written a disassembler for it yesterday, and found an old message from somebody mentioning where to find the code block in the MCU .app files. The disassembly looks okay... except, there seem to be 1000h bytes missing in the middle of the code block (or is it two blocks?), the reset vector is fine, but the other exception vectors point to 4Axxh (whilst the actual handlers show up at 3Axxh).
The "custom design" thing is for the SFR hardware registers & things like I2C and GPIO bits? Is that part of the hardware already rev-engineered & documented on 3dbrew, or elsewhere?
EDIT: https://3dbrew.org/wiki/Hardware has two broken links for "RL78ISA" and "RL78 hardware manual (registers)" are that docs still available somewhere?
If I can brick the console via MCU writes, that might be a nice way to get rid of it ; ) especially as the upper backlight is already broken anyways.

Btw. if somebody wants to donate a 3DS-console (or New3DS.XL-mainboard with intact top-screen connector): I would be very interested in both (two or three games would be also nice to get an idea about what the console is good for).
Doing rev-engineering with lower-screen-only is possible - but the viewing angle is terrible (I have put the console onto a cardboard box on the floor so I can see something; but with working top-screen I could just have it located in front of me on the table (and it might also become easier to reach for the power button that way)).

There are some different/new hardware blocks/registers from what i heard but i never touched MCU reverse engineering. Only few ever tried to reverse engineer the MCU firmware and these people may still have these pdfs. I could not find them on a quick search.
Bricking to have a reason to throw away electronics. What a waste :roll:


Top
 Profile  
 
PostPosted: Sat Jul 13, 2019 7:28 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1007
If somebody buys me a new new3dsXL mainboard, then you can get the old one with the broken backlight connector and protect it from getting wasted.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Tue Jul 16, 2019 2:46 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1007
profi200 wrote:
The [NDMA] regs seem to be a bit buggy anyway. At least the CNT reg doesn't always keep the exact bits written for some reason. But i'm not sure since it was years ago i noticed this.
One reason might be that NDMA registers are read-only during transfers (probably including most or all bits in NDMAxCNT register, except bit31). If there are other situations where NDMAxCNT doesn't contain the expected value... would be interesting to know when that happens (if you happen to come across the effect again).

Yes, using hardware for AES/SHA1 should work on 3DS, and it might save 2-3Kbyte code, but it's just needed for the EAPOL handshake so there's little performance gain. MD5 isn't possible via 3DS hardware (as far as I know), if you want to run wifi on ARM11 then you might also dig out your software libraries before tunneling the AES key wrap to the ARM9 hardware. Anyways, first step would be WEP or Open network, so EAPOL doesn't really matter for getting started.

profi200 wrote:
On poweroff we first turn off the screens because it will shutdown noticeably faster that way.
I am not really noticing that... the LED afterglow in fastboot looks about same as in wifiboot (but of course, the screen goes black earlier if you make it black; which is what I wanted to do in next wifiboot update, too).


RL78 SFR's: There are loads of "RL78 hardware manuals", the SFR register list is hidden in the "CPU Architecture, Processor Registers" chapter. The first hardware manual that I came across was "RL78/G13", so I spent a whole night on extracting the register list, converting it to ascii text, and then making the disassembler to display the SFR register descriptions automatically for each opcode.
The result looks more or less correct... but there are some differences: There can be 16 ports (0..15), but RL78/G13 doesn't have all of the corresponding registers defined (and 3DS uses some of the missing ones). And worse, there are registers at FFF3Ch, FFF9Fh, FFFBEh, FFFC0h, FFFC4h, F0017h, F00C0h, F00C4h, F00F2h, F0501h, F0510h-F0512h, F0538h, F0540h-F0542h, F0550h-F0554h, which don't match with RL78/G13 at all.

Searching for FFF3Ch, there are datasheets with various conflicting meanings:
Code:
  FFF3CH Multiplication data register B(L)
  FFF3CH Serial communication pin select register 0
  FFF3CH D/A conversion value setting register
  FFF3CH Input switch control register
Some datasheets have various registers moved to completely different addresses, looks as if I was lucky with RL78/G13, as it does appear to match up (roughly) with 3DS.
The 78K0R/K C3-L E3-L datasheet looks even more promising, as it's containing most of the unknown SFRs (and, btw, has different meaning for FFF90h, and lacks Timers 10-17 and lacks IICA 1 (aka 2nd I2C registers), and has ADPC moved to F0017h, which does all seem to match up with 3DS MCU firmware (it does have a lot of extra registers at F0540h and up, that part doesn't seem to exist on 3DS, fortunately)).

The 3DS special area is a F0501h..F0554h, which doesn't seem to match any datasheets. Of those, F0540h-F0554h appear to be simply the missing 2nd I2C port registers; and the other ones might be also standard registers moved that addresses...?

Comparing all those SFR lists & searching for subtle differences can be terrorizing. But I hope that I do now known the most probable meanings of most SFRs, so I can start with the actual MCU code disassembly.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Tue Jul 16, 2019 6:42 am 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 14
Regarding waste: Search on ebay for a cheap, bricked 3DS where the description says the blue power LED shortly blinks. This is almost certainly a "arm9loaderhax/boot9sstrap brick" where it can't find the boot.firm on the SD card powering off as a result. There are many ignorant/uninformed people who let others mod their 3DS or they bought "pre-loaded/hacked" ones.


nocash wrote:
profi200 wrote:
The [NDMA] regs seem to be a bit buggy anyway. At least the CNT reg doesn't always keep the exact bits written for some reason. But i'm not sure since it was years ago i noticed this.
One reason might be that NDMA registers are read-only during transfers (probably including most or all bits in NDMAxCNT register, except bit31). If there are other situations where NDMAxCNT doesn't contain the expected value... would be interesting to know when that happens (if you happen to come across the effect again).

Yes, using hardware for AES/SHA1 should work on 3DS, and it might save 2-3Kbyte code, but it's just needed for the EAPOL handshake so there's little performance gain. MD5 isn't possible via 3DS hardware (as far as I know), if you want to run wifi on ARM11 then you might also dig out your software libraries before tunneling the AES key wrap to the ARM9 hardware. Anyways, first step would be WEP or Open network, so EAPOL doesn't really matter for getting started.

I would still use the AES engine even if you only need to use it once. It's much faster than software AES and not much harder to use.

nocash wrote:
profi200 wrote:
On poweroff we first turn off the screens because it will shutdown noticeably faster that way.
I am not really noticing that... the LED afterglow in fastboot looks about same as in wifiboot (but of course, the screen goes black earlier if you make it black; which is what I wanted to do in next wifiboot update, too).

You are not seeing this because there is a delay in the poweroff function as said. Trust me, powering off the screens and backlight speeds up shutdown a lot.


Regarding wifiboot: I tried it once and it was connecting fine it seems. Have not tried uploading anything (this is a bit annoying since i have to run No$GBA through wine). How is it even getting the AP SSID, security and key? NVRAM is separate from the WiFi slots configured in 3DS mode as far as i know. It can only be configured through the DS settings.

You are setting the brightness of the screens quite high. I would go much lower. It will be fine in practice. Also it triggers the famous screen init bug where one or both screens glitch out or show a blackscreen instead of the framebuffer. A few ones even shutdown. On my N3DS XL it's always the topscreen which doesn't quite want to work. Theoretically all 2/3DS models are affected but in practice it's almost always New 3DS consoles having this issue and even more so N3DS consoles with one or 2 IPS panels like mine (mine has an IPS topscreen). We still have not figured out why this is happening but 2 workarounds helped a lot preventing this: Directly after writing to the MCU reg for turning on LCDs and backlight wait 3 ms not doing anything. And the second thing that helps is not spamming the MCU with reg reads or writes (for example polling for the power/HOME button). Use IRQs instead.

edit:
I tried now to upload a firm file and it's hanging no matter what i do. No$GBA finds the right IP but that's about it. The entire thing hangs and i have to close it in the task manager. The 3DS side seems to hang aswell but the power button still works. Same with dslink except the PC side closes gracefully as soon as i poweroff the 3DS.

It seems connecting to the AP also fails after a failed upload attempt. Booting to HOME menu once fixes it (probably because nwm is reuploading the firmware blob?).


Top
 Profile  
 
PostPosted: Wed Jul 17, 2019 1:55 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1007
profi200 wrote:
I tried now to upload a firm file and it's hanging no matter what i do. No$GBA finds the right IP but that's about it. The entire thing hangs and i have to close it in the task manager.
Might be a network problem, or a problem with the .firm file.
Did you try uploading the wifiboot.firm file? So wifiboot will simply reboot itself. That's tested many times, and should work.
Does the progress bar in no$gba upload box show any progress?

With the IP shown in upload box it's apparently almost fully working (ie. connecting to access point & sending the UDP messages), and it's only the last step with the TCP messages that doesn't work. The only reason I could think of is that UDP is sent as broadcast from PC to 3DS, whilst TCP is sent directly to the local IP of the 3DS. Maybe your router/network/access point is somehow delivering broadcast messages only?

profi200 wrote:
Same with dslink except the PC side closes gracefully as soon as i poweroff the 3DS.
Dslink can't upload .firm files... I assume you were using it for uploading .nds/.dsi files to the 3DS in nds/dsi mode?
If that is having the same problem then it's apparently not a bug in my wifiboot/3ds code. At least if dslink is tested & working for other 3DS users.
Btw. there is also a "3dslink" for .3dsx files. I think that's using the 3DS OS function for wifi, so that would be using completely different code. If that doesn't work either, then it's definetly a problem with your network, not with the 3ds software.

profi200 wrote:
It seems connecting to the AP also fails after a failed upload attempt. Booting to HOME menu once fixes it (probably because nwm is reuploading the firmware blob?).
What is a HOME menu? The 3DS equivalent for DSi Launcher? Well, yeah, I guess so, I've just never seen that menu (except in japanese gui, and I guess it's called differently there).
Anyways - I don't know what is going wrong.
If you did power-off after failed upload, then wifiboot should re-upload the wifi firmware at next power-on, and everything should work fine.
If you know a way to reset without power-off after failed upload, then wifiboot would merely restart the wifi-firmware (without re-uploading it), and that should work fine, too.

profi200 wrote:
run No$GBA through wine
The protocol is (almost) same as dslink. If you want to, you could use dslink (host) source code, and change the two UDP strings, and replace the TCP transfer blocks by the FIRM header & FIRM blocks (might be possible in 5-10 minutes). The protocol's are described here: http://problemkaputt.de/gbatek.htm#dswi ... otprotocol

profi200 wrote:
How is it even getting the AP SSID, security and key?
The access point data is stored in Wifi-FLASH, same as on DSi, http://problemkaputt.de/gbatek.htm#dsfi ... cesspoints
Or is 3DS storing that data elsewhere? Even then, it would probably copy it to Wifi-FLASH for DSi compatibility.

profi200 wrote:
You are setting the brightness of the screens quite high. I would go much lower.
It should use the default brightness as in bootrom blue screen. But now that you mention it, if I would have the screens in front of my eyes, then I would probably prefer a lower setting, too. Hint: Put it on a cardboard box on the floor, then the viewing angle & backlight are nice : )
Or tweak the "arm11_lcd_set_reg_240h_level" function in lcd3ds.a22 to use a smaller value in "r1". The incoming "r1" value is calculated based on GPU register 244h, and then passed to GPU register 240h (as done in bootrom). I don't really understand why the bootrom is doing that... but I assume that one (or both) of that registers are backlight or brightness related?

profi200 wrote:
Also it triggers the famous screen init bug where one or both screens glitch out or show a blackscreen
I've never experienced that on my New3DS. But... there is a test screen pattern in the "arm11_fill_to_mem_words" function in lcd3ds.a22, that might look like a glitch on the top screen (if you have working top screen backlights).

If you should want to edit wifiboot source code: I am afraid that it works only if you store the source files in no$gba's "stuff" sub-directory. Then edit lcd3ds.a22 or whatever. Then use Utility/AssembleFile in no$gba for the main file (wifiboot.a22).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Wed Jul 17, 2019 5:29 am 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 14
nocash wrote:
profi200 wrote:
I tried now to upload a firm file and it's hanging no matter what i do. No$GBA finds the right IP but that's about it. The entire thing hangs and i have to close it in the task manager.
Might be a network problem, or a problem with the .firm file.
Did you try uploading the wifiboot.firm file? So wifiboot will simply reboot itself. That's tested many times, and should work.
Does the progress bar in no$gba upload box show any progress?

It's not a network problem. I heard from others they have the exact same problem. I tried a freshly compiled fastboot FIRM file for this and i'm 100% sure that one is not corrupt since it boots fine from the SD card. Sending wifiboot.FIRM itself is also failing. With sending wifiboot itself it goes as far as showing reading FIRM sections on the 3DS side but hangs at 0%. No$GBA also hangs at 0%.

nocash wrote:
With the IP shown in upload box it's apparently almost fully working (ie. connecting to access point & sending the UDP messages), and it's only the last step with the TCP messages that doesn't work. The only reason I could think of is that UDP is sent as broadcast from PC to 3DS, whilst TCP is sent directly to the local IP of the 3DS. Maybe your router/network/access point is somehow delivering broadcast messages only?

Everything else does work fine. Just not wifiboot.

nocash wrote:
profi200 wrote:
Same with dslink except the PC side closes gracefully as soon as i poweroff the 3DS.
Dslink can't upload .firm files... I assume you were using it for uploading .nds/.dsi files to the 3DS in nds/dsi mode?
If that is having the same problem then it's apparently not a bug in my wifiboot/3ds code. At least if dslink is tested & working for other 3DS users.
Btw. there is also a "3dslink" for .3dsx files. I think that's using the 3DS OS function for wifi, so that would be using completely different code. If that doesn't work either, then it's definetly a problem with your network, not with the 3ds software.

I gave dslink a shot since your docs don't mention dslink will not work for FIRM files but knowing it may not work. 3dslink and everything else made for 3DS userland works just fine with the minor annoyance of connection problems (everyone has these and it's caused by Nintendos buggy socket implementation).

nocash wrote:
profi200 wrote:
It seems connecting to the AP also fails after a failed upload attempt. Booting to HOME menu once fixes it (probably because nwm is reuploading the firmware blob?).
What is a HOME menu? The 3DS equivalent for DSi Launcher? Well, yeah, I guess so, I've just never seen that menu (except in japanese gui, and I guess it's called differently there).
Anyways - I don't know what is going wrong.
If you did power-off after failed upload, then wifiboot should re-upload the wifi firmware at next power-on, and everything should work fine.
If you know a way to reset without power-off after failed upload, then wifiboot would merely restart the wifi-firmware (without re-uploading it), and that should work fine, too.

What you are seeing (and where you can start DS/3DS games) if you boot the regular firmware or rather OS since that's what it really is.
I checked again and this seems to be rather some sort of timeout. Booting quickly into HOS (horizon OS) and back into wifiboot makes the connection fail again but after a connection test in HOS it also goes away (and this connection test connects unusually fast to the AP aswell and succeeds).
Also of note is when it fails to connect it prints out some kind of hexdump and that's it.

nocash wrote:
profi200 wrote:
How is it even getting the AP SSID, security and key?
The access point data is stored in Wifi-FLASH, same as on DSi, http://problemkaputt.de/gbatek.htm#dsfi ... cesspoints
Or is 3DS storing that data elsewhere? Even then, it would probably copy it to Wifi-FLASH for DSi compatibility.

I thought that is stored somewhere else than NVRAM.

nocash wrote:
profi200 wrote:
Also it triggers the famous screen init bug where one or both screens glitch out or show a blackscreen
I've never experienced that on my New3DS. But... there is a test screen pattern in the "arm11_fill_to_mem_words" function in lcd3ds.a22, that might look like a glitch on the top screen (if you have working top screen backlights).

No, it's showing this weird pattern on another 3DS but on the N3DS XL it's showing a fading out glitched image of the bootloader instead of that pattern. This may happen on one or both screens. It's different for every (affected) 2/3DS. A few ones even just turn off completely


Top
 Profile  
 
PostPosted: Thu Jul 18, 2019 2:19 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1007
Wayback machine doesn't have the 3dbrew "RL78 hardware manual" document archived, but it was probably wrong anyways (the 3dbrew I2C Registers page contains some mistakes that could be explained only by using the wrong datasheet: It's mentioning an "ITMC" register and a "prohibited bit" in the RTC, that would hint on RL78/G13 datasheet. And it's also mentioning a "leap year" feature, which doesn't match up with any datasheets that I've seen).
The 78K0R/KC3-L, 78K0R/KE3-L datasheet seems to be a lot closer to the 3DS MCU registers. The ITMC is actually RSUBC, and there is no prohibited bit, and most likely also no leap year counter (other than the regular year counter itself). What is nice on the 3dbrew I2C page is that it mentions the "ticks" values for the power button timings, making it very easy to find & patch that values.

MCU firmware uploading appears to done by writing 3 ascii characters for unlocking, and then writing the 4000h bytes firmware image. There is a backup copy, so there should be little risk of bricking anything by transfer errors.
The two things that could brick are: Successfully uploading bugged code. And mixing old backup with incompletely uploaded new code (to avoid that, one should probably upload new/unique IDs to 1FF6h, 2000h, 4FF6h.
The MCU memory map is a bit odd...
Code:
00000h..00FFFh  Code part 1
01000h..01FFFh  Code part 1 copy    ;\uploaded firmware is
02000h..04FFFh  Code part 2         ;/written here
05000h..07FFFh  Code part 2 copy
EFFD0h..EFFD1h  Unknown
F0000h..F07FFh  Extra SFR's
F2000h..Fxxxxh  Partial mirror of Code part 2
Fxxxxh..FFFFFh  RAM and SFR's
After upload, if okay: part 1 should be swapped (via a hardware feature), and if failed: part 2 should be restored (via a software generated backup). Or so, I haven't tested that.

profi200 wrote:
It's not a network problem. I heard from others they have the exact same problem... Sending wifiboot.FIRM itself is also failing. With sending wifiboot itself it goes as far as showing reading FIRM sections on the 3DS side but hangs at 0%.
Okay, if it shows reading FIRM sections and 0%, then it does have passed through three TCP packets (for FIRM header, and Info Block, and response). And it does have set the RTC time from the Info Block, and it does have read the Length value of the first FIRM block. And it has sensed that the length of that block is nonzero (else it wouldn't show 0%).

It doesn't make sense that the above works differently when uploading wifiboot.firm than fastboot.firm (at that point it didn't even interprete the FIRM header contents, apart from checking if Length of 1st block is nonzero). Maybe the difference was just a random effect?
Some ideas for random effects...
  • Wine+no$gba doesn't work as it should? Would be nice to know if wine+no$gba works for uploading .nds/.dsi titles to .nds/.dsi consoles. I haven't found any tester that yet.
  • I2C bus is unstable on some consoles, and might hang when setting the RTC? If you reset the RTC time to 00:00:00, does wifiboot display the correct time (not the 00:00:00 setting), and does wifiboot update the MCU's RTC registers. so you can see the correct RTC time outside of wifiboot, too?
  • I am not doing too much memory/cache initializations. Could fastboot have something in different state than bootrom? Like caches, or memory access rights or the like.
  • As by now, only WEP is tested and working on 3DS. WPA/WPA2 and open network are still untested on 3DS (they should work, and UDP is apparently working in your network, there is a small chance that something goes wrong, eg. there might be a WPA bug causing memory corruption or the like).

profi200 wrote:
I checked again and this seems to be rather some sort of timeout...
Also of note is when it fails to connect it prints out some kind of hexdump and that's it.
That hexdump contains the error code, I would at least need the first two lines of that dump. And also the previous line before the dump, to know where it had occurred.

profi200 wrote:
No, it's showing this weird pattern on another 3DS but on the N3DS XL it's showing a fading out glitched image of the bootloader instead of that pattern. This may happen on one or both screens. It's different for every (affected) 2/3DS. A few ones even just turn off completely
Hmmm, I could try to add that delay that you mentioned. All those effects have been observed in wifiboot?
Not using I2C transfers because some people say that they can't get them working on their consoles isn't a good option.
I would need of the affected consoles, so I could try to identify and fix the issue.
Or, keep in mind that Nintendo is doing that 188*2 cycle delay between I2C transfer (between last data byte & following device number of next transfer). Maybe doing that fixes the issue.
And of course one should take care that IRQ handlers or other CPU/Cores don't use I2C while other I2C transfers are in progress.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sat Jul 20, 2019 5:05 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1007
Power button functionality is (almost) fully working - even without patching the MCU firmware!

Removing the 7s delay: This delay is actually variable, the insane default setting can be changed via MCU register 24h (which is, rather misleadingly, called the "watchdog" register on 3dbrew). Changing that value is very good (especially for rev-engineering that includes crashing once and then), one might need to restore the default before starting other titles though (in case some of them rely on the insane delay):
Code:
MCU[24h] - Forced Power Off delay
  Delay in 16 "tick" units (0=Never, 1=Fastest, 5Dh=InsaneDefault)


Removing the slowly dying led delay: The delay is because the power-off function in firmware decreases the current LED brightness downto zero. That means the delay can be eliminated by setting the LED brightness to zero before issuing power-off. This can be done by selecting Power Led mode 04h via MCU register 29h:
Code:
MCU[29h] - Power LED mode
  First byte (Power LED mode):
    00h   = fade to brightness MCU[28h] with battery check
    01h   = fade to brightness MCU[28h]
    02h   = pulsating fade on/off with battery check
    03h   = fade to brightness 00h
    04h   = instantly set brightness 00h
    05h   = instantly set brightness FFh
    06h   = Blinking RED (affects Power+Notification LEDs)
    Other = Same as 00h
  Further bytes (optional, if any written):
    Power LED Blink pattern (default is 55h,55h,55h,55h)


Removing the tap-holding delay: That was actually already documented on 3dbrew, I had just missed that detail. Reading 13h bytes from MCU register 7Fh returns some system info, including the "raw button states" in the last byte, so one can poll the power button directly - and power off immediately when it gets pressed. It's unfortunate that one needs to read/skip the preceeding 12h bytes to reach the relevant byte, but it's more than worth getting lag-less button support.

The only thing that would require MCU patching is the 3s button hold delay when the console has crashed, changing that to 1s or a bit less would be quite nice, I still planning to give it a try someday.

profi200 wrote:
Trust me, powering off the screens and backlight speeds up shutdown a lot.

Okay, I have tried - but I see no difference. You mean writing MCU[22h] with "push" and "backlight" off flags? A lot means many milliseconds? And the effect is visibile on screen/leds? Or do I need an amperemeter and oscilloscope the measure the shutdown? I am almost thinking that the speedup occurs only with OS code, or C libraries.

profi200 wrote:
I tried now to upload a firm file and it's hanging no matter what i do.

I've just tried booting wifiboot from SD card via fastboot. When doing that, the following wifi-upload hangs after 4%. I have never had that problem when booting wifiboot via bootrom. So that seems to be a bug in fastboot... something not cleaned up properly to restore that same state as for bootrom.

I've also tried booting another firm via fastboot, that hangs completely (while still showing the fastboot menu screen):
Attachment:
diag3ds.ZIP [6.81 KiB]
Downloaded 64 times

This file doesn't use and doesn't initialize any caches, and there is only one firm section (used for both arm9 and arm11). It's also lacking some further initializations (ie. IRQs and DMAs should be disabled before starting the file). The screen output is same as in wifiboot, so that part should work, but something else makes it hang when starting it via fastboot.
EDIT: That diag3ds file doesn't init ARM9 stack, so that might hang (I've loaded it via a bootstub that did init the stack). But, fastboot doesn't even seem to start the file, instead it waits for button B then "returns" to fastboot, that makes me think that it does display a "load error" message on top screen?

PS. uhm, why is the tool called fastboot? It looks more like being on the slowish side, especially when booting. There seems to be a 1s delay before showing the menu. I am sure that you could remove that delay (or get away with only 100ms or less).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sat Jul 20, 2019 8:07 pm 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 14
nocash wrote:
It doesn't make sense that the above works differently when uploading wifiboot.firm than fastboot.firm (at that point it didn't even interprete the FIRM header contents, apart from checking if Length of 1st block is nonzero). Maybe the difference was just a random effect?
Some ideas for random effects...
  • Wine+no$gba doesn't work as it should? Would be nice to know if wine+no$gba works for uploading .nds/.dsi titles to .nds/.dsi consoles. I haven't found any tester that yet.
  • I2C bus is unstable on some consoles, and might hang when setting the RTC? If you reset the RTC time to 00:00:00, does wifiboot display the correct time (not the 00:00:00 setting), and does wifiboot update the MCU's RTC registers. so you can see the correct RTC time outside of wifiboot, too?
  • I am not doing too much memory/cache initializations. Could fastboot have something in different state than bootrom? Like caches, or memory access rights or the like.
  • As by now, only WEP is tested and working on 3DS. WPA/WPA2 and open network are still untested on 3DS (they should work, and UDP is apparently working in your network, there is a small chance that something goes wrong, eg. there might be a WPA bug causing memory corruption or the like).

profi200 wrote:
I checked again and this seems to be rather some sort of timeout...
Also of note is when it fails to connect it prints out some kind of hexdump and that's it.
That hexdump contains the error code, I would at least need the first two lines of that dump. And also the previous line before the dump, to know where it had occurred.

profi200 wrote:
No, it's showing this weird pattern on another 3DS but on the N3DS XL it's showing a fading out glitched image of the bootloader instead of that pattern. This may happen on one or both screens. It's different for every (affected) 2/3DS. A few ones even just turn off completely
Hmmm, I could try to add that delay that you mentioned. All those effects have been observed in wifiboot?
Not using I2C transfers because some people say that they can't get them working on their consoles isn't a good option.
I would need of the affected consoles, so I could try to identify and fix the issue.
Or, keep in mind that Nintendo is doing that 188*2 cycle delay between I2C transfer (between last data byte & following device number of next transfer). Maybe doing that fixes the issue.
And of course one should take care that IRQ handlers or other CPU/Cores don't use I2C while other I2C transfers are in progress.

It could have been by luck it got that far i don't know.

Not tested uploading DS(i) homebrew on a DS(i). On 3DS your wifiboot in DSi mode gets stuck at "connecting" and i could not find dslink since WinterMute has removed all releases and it doesn't compile. I'm not gonna change network security for this since open or WEP is pretty risky. It's WPA2-PSK (AES) here.

I don't know about any RTC problems and booting the wifiboot FIRM actually show the correct time. When it hangs the displayed time stops updating.

The only difference is it's disabling icache on ARM11 while boot11 leaves it on (as per the TRM icache can actually be on without the MMU) which doesn't make a difference. Leaving it off even reduces the chance of problems.

Not gonna do WEP as said. You should not use WEP or open either. You are responsible for everything someone does over your internet connection if it can be proven you have not secured WiFi properly.

Editing this later with the hexdump.
Quote:
...
CRYPT: WPA2-AES 00 48
DOMAIN: 0188 3FFE

00150201

01 02 15 00 08 00 03 10
00 00 34 31 C4 CD 87 6E
05 00 00 02 06 00 AA 00
...


It's happening as soon as wifiboot inits the screens. Delays don't prevent it 100% but make it far less likely. And MCU spamming increases the chance of it happening aswell.



nocash wrote:
profi200 wrote:
Trust me, powering off the screens and backlight speeds up shutdown a lot.

Okay, I have tried - but I see no difference. You mean writing MCU[22h] with "push" and "backlight" off flags? A lot means many milliseconds? And the effect is visibile on screen/leds? Or do I need an amperemeter and oscilloscope the measure the shutdown? I am almost thinking that the speedup occurs only with OS code, or C libraries.

I don't know what you are doing but here the time between fading blue LED and and button press noticeably decreases when turning off the screens beforehand. And i mean power button + no screen deinit at all vs power button + powering off the screens via MCU reg write and resetting the GPU/LCD hardware.

nocash wrote:
I've just tried booting wifiboot from SD card via fastboot. When doing that, the following wifi-upload hangs after 4%. I have never had that problem when booting wifiboot via bootrom. So that seems to be a bug in fastboot... something not cleaned up properly to restore that same state as for bootrom.

I've also tried booting another firm via fastboot, that hangs completely (while still showing the fastboot menu screen):
Attachment:
diag3ds.ZIP

This file doesn't use and doesn't initialize any caches, and there is only one firm section (used for both arm9 and arm11). It's also lacking some further initializations (ie. IRQs and DMAs should be disabled before starting the file). The screen output is same as in wifiboot, so that part should work, but something else makes it hang when starting it via fastboot.

Everything else works running it from fb3DS. Note that it's meant to be installed in a FIRM partition on the eMMC (ideally both firm0/1).

...you can't expect it to boot something that has broken section hashes. It won't boot anything that is not playing by the rules (hash checks must pass and all sections must be in whitelisted regions) and you are again not seeing the error displayed. Pressing B makes it go back. Fixing the section hash manually makes this FIRM power off immediately.

nocash wrote:
PS. uhm, why is the tool called fastboot? It looks more like being on the slowish side, especially when booting. There seems to be a 1s delay before showing the menu. I am sure that you could remove that delay (or get away with only 100ms or less).

Again you are not seeing what's going on. It's displaying a splash on the topscreen. The duration is configurable in Boot setup --> Change splash but it requires the topscreen to see what's going on. Alternatively add "SPLASH_DURATION = 500" (500 ms which is the minimum) to sdmc:/3ds/fastbootcfg.txt to make it a bit faster. There is also a boot mode selection which allows to disable booting to the menu or displaying a splash before trying to boot slots. Quiet for example will show nothing but errors (if any happen) and otherwise it will straight boot to the next best configured FIRM. In quiet mode with configured slot this is pretty damn fast (around 400 ms including loading a big FIRM file from the SD card).

edit:
Uploading the attached FIRM file using No$GBA hangs not even displaying 0%.


Top
 Profile  
 
PostPosted: Sun Jul 21, 2019 8:32 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1007
Ooops, yes, I didn't have the .fix directive in diag3ds for fixing the sha256's, thanks.
Immeditialy powering down in diag3ds happens if you have button a/b pressed (I guess you did so in fastboot menu).
Well, at least you do now know how immediately powering off looks like, without the led fade-out delay.

I've spent the whole day on trying to figure out why wifiboot doesn't work with fastboot. I didn't found the problem. But noticed some other issues.

Fastboot seems to destroy the "LDR PC,[$+4]" opcodes in the exception handlers. That's causing diag3ds to hang upon data aborts (in the memdump screens) (because it's setting only vector at address $+4, but not the LDR opcode in the preceeding word).

Fastboot seems to have some of the New3DS-only CFG11 registers set to nonzero values (unlike when booting from bootrom).
For example, reading 10141300h (CFG11_MPCORE_CLKCNT) returns 00018001h. That would be bit16=unknown?, bit15=busy???, bit0=enable something.
I've tried to reset the New3DS-related CFG11 registers to zero, but that didn't help (but I don't know if it's that easy, or if one must reset them in a specfic order).

Running out of ideas, I've tried to add a huge wait-by-loop delay in wifiboot (to see how fast the arm11 cpu is running; with code cache enabled). The delay takes 10s when booted from bootrom, but with fastboot it comes out as 15 second delay.

If you have hardmod, then you could simply install wifiboot as firm0, I am quite optimistic that it will boot perfectly (or if it doesn't work then you would need the hardmod to uninstall it).

_________________
homepage - patreon


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 119 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group