It is currently Tue Oct 15, 2019 10:14 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 136 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 10  Next
Author Message
PostPosted: Thu May 16, 2019 6:48 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1025
Yipieh, I got my screen output and backlight enable working. Currently it's only showing a striped bitmap, but it should be no issue to display text output instead of that test screen.

profi200 wrote:
There was no need to reverse engineer the GPU/LCD init code. It has been figured out long ago. Most of the register names are missing but it works well: https://github.com/derrekr/fastboot3DS/ ... gfx.c#L249 boot9strap has very similar code.
Good point. Using that might have been easier. But after disassembling the bootcode, I ended up writing my own code... it took a bit longer than 1-2 days though.
After extracting the GPU/LCD related code from the bootrom, I still about 2400 lines of messy video code. The most messy/buggy/confusing part was the table-based backlight initialization.
Those tables contain only one halfword each. But the bootrom tries to read more than one halfword from each table, and then does weird squaring and interpolation on those table value(s). I guess all that code could make sense with bigger tables, but with the 1-entry-only tables it's just crazy nonsense.

Then I spend some days on having made a silly mistake (most of my GPU register writes did hang the CPU... which turned out to be just caused by using a wrong I/O base address, kinda stupid).

And then I finally got a picture displayed, but the console powered off shortly after backlight enable. I got that fixed by setting 10202000h+240h (and +A40h) to 0020h. A bigger value like 0040h causes power-off. I am not sure what has happened there, part of the problem might be that I've replaced the top-screen backlight by a resistor (which may be too small for large brightness settings). But even then, my initialization should be same as for bootrom error messages (the bootrom does work okay, even with the resistor, but my own code behaves differently for some reason).
EDIT: Seems to be now working as with bootrom. I think the problem was caused by a bug in my I2C reading function for retriving MCU type/version (which had returned all FFh's, ie. lcd_type=F, and mcu_version=F.FF; correct would have been type=1 and ver=3.38hex).

profi200 wrote:
When i was measuring how much time/cycles the CPU spends waiting for a single byte I2C transfer (switched to using interrupts since) i got far over 10000 cyles on ARM11 (measured using the MPCore performance monitor)...
I had no problems at all with the power LED but i only use it as sleep indicator anyway.
Do you know what frequency that MPCore timer counts at? Bootrom code looks like... 134MHz?
And is that 10000 cycles for one raw I2C byte? Or a whole "Device+Index+Databyte" sequence with 3 bytes in total?
The delay is needed only after the last Databyte of each transfer. If you were doing only one transfer per frame, then you have had more than enough delay time.
Btw. I have edited the I2C delay stuff in previous post. The bootrom seems to aim at 2*188 cycles delay after last byte... although my early tests included a much longer DSi-style delay before each byte - which should have worked, too (theoretically, but somehow it didn't work in practice).

profi200 wrote:
Everything detects modified FIRM partitions by looking for the sighax signatures. That's it.
That's not so very suitable for detection. It would require to (RSA-)decrypt the signature and then examine if it contains normal padding bytes (or have a database with all currently known used sighax signatures (which could run into billions if somebody likes bruteforcing more and more variants).
And worst, the FIRM cannot by (AES-)decrypted without OTP dump, so impossible to examine the signatures at all (like, when you get a console, don't have a OTP dump, and want to patch it via hardmod - one could do that only with original FIRM, or with a backup-copy of the original FIRM stored in some unused eMMC sectors). But well, not so much of a problem if there's no standard for backups yet.

PSI wrote:
Hi nocash, I made an account to get a chance to talk to you. I'm also making a 3DS emulator: https://github.com/PSI-Rockin/Corgi3DS
My emulator runs the boot ROMs and successfully loads NATIVE_FIRM off the NAND. It doesn't get much further than that as Kernel11 needs MMU, but it's also capable of booting ARM9 payloads such as GodMode9 from an SD image.
Cool, nice to hear that there is someone doing low-level emulation for 3DS. The other low-level thing that I know of is the Teak/DSP emulation from wwylele, which is also quite impressive (although that part is most distant from the boot process).

Yeah, the MMU is keeping me away from adding 3DS support in no$gba, too. At the moment, I don't even know what page-size it is using. I have no clear picture of what needs to be done for emulating it.

Another small obstacle is that no$gba is currently designed to map most I/O ports to only ARM7, or only ARM9. Whilst 3DS seems to allow to access (many) I/O ports from either ARM9 or ARM11 (or both). Well, that isn't a major problem, but I may need to rewrite a bunch of code, instead of just re-using the old DSi emulation for 3DS.

The good thing about 3DS is that the bootroms are dumped meanwhile, so one can start emulation & research at power-up time. For the DSi, the bootroms are still undumped. And, when I had starting to emulate DSi, it wasn't even known how to decrypt the eMMC bootsectors, so emulation had to start excecution after the yet unknown boot process (that wasn't so funny to work that way).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Thu May 16, 2019 9:36 pm 
Offline

Joined: Mon May 13, 2019 5:32 pm
Posts: 15
The MMU is well-documented on ARM's official docs. I haven't looked too deeply into it, although I know a few things: it's completely accessed through CP15 registers, it works through a "page-walking" scheme (where the code provides pointers to page tables in memory to the MMU), and page sizes range from 4 KB to 16 MB. It seems rather complex, and there's also the issue of having to emulate access privileges...

The good news is that the boot ROMs don't need any MMU emulation at all, so you can feasibly get the boot ROM error screen just by pretending the NAND isn't there. It writes directly to framebuffer to display the error too. I do think you need timer emulation (and interrupts) to get the error screen however, and of course you need PXI (aka IPC).

To actually get a firmware or payload to boot is more involved. You need AES, SHA, and RSA hardware all implemented, and the eMMC protocol must obviously be implemented too. You will also need the OTP and the NAND CID: OTP is used to derive the console-unique keys to decrypt the NAND, and the CID is also used for decryption. The boot process is semi-documented on 3dbrew, so you get some idea of what's going on.


Top
 Profile  
 
PostPosted: Fri May 17, 2019 4:47 am 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 14
nocash wrote:
profi200 wrote:
There was no need to reverse engineer the GPU/LCD init code. It has been figured out long ago. Most of the register names are missing but it works well: https://github.com/derrekr/fastboot3DS/ ... gfx.c#L249 boot9strap has very similar code.

Those tables contain only one halfword each. But the bootrom tries to read more than one halfword from each table, and then does weird squaring and interpolation on those table value(s). I guess all that code could make sense with bigger tables, but with the 1-entry-only tables it's just crazy nonsense.

I have not reverse engineered that but usually everyone just dumps the backlight levels from HOME menu. Careful with these since there is apparently no safety limit on the backlight. In the early days someone caused his 3DS to heat up by setting the backlight regs very high.

nocash wrote:
profi200 wrote:
When i was measuring how much time/cycles the CPU spends waiting for a single byte I2C transfer (switched to using interrupts since) i got far over 10000 cyles on ARM11 (measured using the MPCore performance monitor)...
I had no problems at all with the power LED but i only use it as sleep indicator anyway.
Do you know what frequency that MPCore timer counts at? Bootrom code looks like... 134MHz?
And is that 10000 cycles for one raw I2C byte? Or a whole "Device+Index+Databyte" sequence with 3 bytes in total?
The delay is needed only after the last Databyte of each transfer. If you were doing only one transfer per frame, then you have had more than enough delay time.
Btw. I have edited the I2C delay stuff in previous post. The bootrom seems to aim at 2*188 cycles delay after last byte... although my early tests included a much longer DSi-style delay before each byte - which should have worked, too (theoretically, but somehow it didn't work in practice).

You should really take a look inside the ARM11 MPCore TRM. It's half the frequency of the CPU core so 134 MHz.
Frequency formula: http://infocenter.arm.com/help/topic/co ... JJEHG.html
General registers: http://infocenter.arm.com/help/topic/co ... 02s02.html
The performance monitor actually counts all cycles minus a few missed ones at start/reset so it runs at core frequency.

If i recall correctly it was the entire transfer including device and register select. Still very slow for a single byte reg write. In the very early days we polled the MCU from ARM11 (which of course was not a good idea). It worked fine without any delays (with the ARM11 having all caches on so it's really fast). It caused RTC drifts though which we did not notice until later.

nocash wrote:
profi200 wrote:
Everything detects modified FIRM partitions by looking for the sighax signatures. That's it.
That's not so very suitable for detection. It would require to (RSA-)decrypt the signature and then examine if it contains normal padding bytes (or have a database with all currently known used sighax signatures (which could run into billions if somebody likes bruteforcing more and more variants).
And worst, the FIRM cannot by (AES-)decrypted without OTP dump, so impossible to examine the signatures at all (like, when you get a console, don't have a OTP dump, and want to patch it via hardmod - one could do that only with original FIRM, or with a backup-copy of the original FIRM stored in some unused eMMC sectors). But well, not so much of a problem if there's no standard for backups yet.

There are only 2 known FIRM partition sighax signatures in the wild. Ours and the one boot9strap uses. It's enough to check hashes. Of course someone could bruteforce more but everyone is using these 2 only. Bruteforcing more is kinda pointless.
There are 2 different types of backups being made currently. Either full 1:1 eMMC copies or the most important files like OTP, sector one, movable.sed...
The tool almost everyone uses for this is: https://github.com/d0k3/GodMode9

nocash wrote:
Yeah, the MMU is keeping me away from adding 3DS support in no$gba, too. At the moment, I don't even know what page-size it is using. I have no clear picture of what needs to be done for emulating it.

It's actually not so hard. It's a massive step up from MPUs but it really is just a lookup table with attributes/permissions. 2 levels for <section (1 MiB). Then there are supersections which are basically just 16 sections (16 MiB).
Example code (not the nicest but works): https://github.com/derrekr/fastboot3DS/ ... ware/mmu.c
Documentation: http://infocenter.arm.com/help/topic/co ... BHIGI.html

Should be noted that the tables require quite some alignment for the MMU to perform well (all explained in the TRM and the ARM ARM (architecture reference manual).


Btw: A reminder on the #3dsdev IRC channel.


Top
 Profile  
 
PostPosted: Sat May 18, 2019 10:07 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1025
I am having troubles to extract the Wifi Firmware from the "NWM" module. Here, http://4dsdev.kuribo64.net/thread.php?pid=470#470 plutoo mentioned "Having a quick glance at NWM, it looks like it contains 3 different versions of wlan firmware, labeled 1, 4 and 5."

I have extracted the safe mode NWM .code file (and decompressed it). And had several quick glances (and longer glances) at the file, but I can't see anything "labeled 1, 4 and 5". Is there some table of contents with those 1,4,5 numbers/labels?

What I can find is this:
Code:
  Offset    Content
  3C879h    main code (with "A_INIT" string)
  3D96Ah    main code (with "A_INIT" string)
  451ADh    main code (with "A_INIT" string)
  4F380h    stub code (len 316h) (bytes 36 61 00 21 04 63 .. 1D F0)
  4F698h    stub data (len 38h?)
So there seem to be 3 different main versions (maybe for DSi, 3DS, and 3DS-local-multiplayer?), and, apparently only 1 version for the eeprom-loading stub. Additionally to main/stub, there might be also 1-3 database versions somewhere in the file.
Without table of contents it's hard to guess the exact start address, size, and target address of the above sections. The stub size seems to be 316h bytes... but I can't even find that size value in the .code file. Am I missing something obvious?

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sun May 19, 2019 6:12 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1025
Okay, I've found the DSi-style "00524C00h" load address, and alongsides also found all the other stuff at nearby addresses, including CMP opcodes for the "label 1,4,5" part. Instead of a table of contents, the addresses are just hardcoded constants in the literal pool. Base address seems to be 100000h, ie. ARM address 13D84Ch means file offset 3D84Ch.
Code:
  Offset
  07248h    value 00524C00h   ;dst for stub.data and/or main.code?          ;\
  0724Ch          00145142h ;src.end  ;\len 78F6h  (2nd main) (aka label 5) ;
  07250h          0013D84Ch ;src      ;/                                    ;/
  ...
  097C4h    cmp r0,1h         ;\
  097C8h    cmp r0,4h         ; "labels" for different main's
  097CCh    cmp r0,5h         ;/
  ...
  098E8h    value 00524C00h ;dst for stub.data and/or main.code             ;\
  098ECh          00145142h ;src.end  ;\len 78F6h  (2nd main) (aka label 5) ;
  098F0h          0013D84Ch ;src      ;/                                    ;/
  098F4h    value 0053FE18h ;dst for database?                          ;\
  098F8h          0014F380h       ;\len 1E8h (probably database?)       ;
  098FCh          0014F198h       ;/                                    ;/
  09900h    value 00527000h ;dst for stub.code (aka 927000h)            ;\
  09904h          0014F696h ;src.end ;\len 316h (stub.code)             ;
  09908h          0014F380h ;src     ;/         <-- file.offs = 4F380h  ;/
  0990Ch          0014F6D0h ;src.end ;\len 38h (stub.data)
  09910h          0014F698h ;src     ;/
  0991xh          ..
  09920h          0013D84Bh       ;\len FD3h (1st main) (aka label 1)
  09924h          0013C878h       ;/
  09928h          0014F197h       ;\len A053h (3rd main) (aka label 4)
  0992Ch          00145144h       ;/
Well, with that... I guess I could now try to upload the wifi firmware to the Xtensa CPU, and see what happens.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sun May 19, 2019 7:15 am 
Offline

Joined: Sun May 19, 2019 7:01 am
Posts: 6
bürp

so I see you're attempting to emulate the 3DS, good luck with this project

I have a few things to say, tho

nocash wrote:
Yeah, the MMU is keeping me away from adding 3DS support in no$gba, too. At the moment, I don't even know what page-size it is using. I have no clear picture of what needs to be done for emulating it.

Another small obstacle is that no$gba is currently designed to map most I/O ports to only ARM7, or only ARM9. Whilst 3DS seems to allow to access (many) I/O ports from either ARM9 or ARM11 (or both). Well, that isn't a major problem, but I may need to rewrite a bunch of code, instead of just re-using the old DSi emulation for 3DS.

The good thing about 3DS is that the bootroms are dumped meanwhile, so one can start emulation & research at power-up time. For the DSi, the bootroms are still undumped. And, when I had starting to emulate DSi, it wasn't even known how to decrypt the eMMC bootsectors, so emulation had to start excecution after the yet unknown boot process (that wasn't so funny to work that way).

if I were you, I would make a separate no$3ds/whatever emulator for this. the 3DS may share a lot of hardware with the DSi for backwards compatibility purposes, but for the purpose of running 3DS software, most of the underlying hardware is completely different.

I'd just worry that cramming all these consoles into one project would result in a bloated codebase, but eh, your choice.

other than that, well, have fun! emulating the 3DS at low level sounds like an interesting challenge.

--

also, if you're ever interested into updating the DS documentation: I have a whole pile of errata/additions sitting at the melonDS forum (I would link to the thread, but I'm afraid I might get hit by some spam protection, seeing as I'm a newb here)

there's also quite a bunch of low-level research on the 3D GPU thing it uses, but enough offtopicness


Top
 Profile  
 
PostPosted: Sun May 19, 2019 7:41 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21628
Location: NE Indiana, USA (NTSC)
Go ahead and post the link. We don't have a "no external links for new users" policy.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sun May 19, 2019 8:35 am 
Offline

Joined: Sun May 19, 2019 7:01 am
Posts: 6
'aight

general GBAtek addendum/errata
the development forum for more
3D GPU info here and here


Top
 Profile  
 
PostPosted: Wed May 22, 2019 10:10 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1025
profi200 wrote:
If i recall correctly it was the entire transfer including device and register select. Still very slow for a single byte reg write
Well, about 10000 cycles at 134MHz for 24bits... would be 3us per bit. Maybe not so fast for modern hardware, but also not too slow.

profi200 wrote:
There are only 2 known FIRM partition sighax signatures in the wild. Ours and the one boot9strap uses. It's enough to check hashes.
Yes, except, from my "hardmod without OTP dump" perspective: I couldn't decrypt the FIRM sectors without OTP, and thus couldn't check what kind of hashes are in there (and if I had OTP dump then I wouldn't need to check the hashes because I could just overwrite everything with my own FIRM code/header).
But well, my hardmod approach is probably quite uncommon, and most other people use softmod/exploits. On the other hand, there are probably a bunch of people with bricked consoles, then they would need hardmods (but yeah, I guess they would rarely know how to repair even simple issues like deleted files, so the hardmod won't really help in most cases).

---

I haven't looked into 3DS MMU yet, but "page walking" sounds a bit familar. As far as I remember, 80386 is having one table for larger memory blocks with pointers to tables for the smaller 4Kbyte page addresses (and access rights). I guess 3DS works similar.

PSI wrote:
To actually get a firmware or payload to boot is more involved. You need AES, SHA, and RSA hardware all implemented, and the eMMC protocol must obviously be implemented too. You will also need the OTP and the NAND CID: OTP is used to derive the console-unique keys to decrypt the NAND, and the CID is also used for decryption.
I already have all that program code from the DSi emulation (plus a newer SHA256 function for 3DS eMMC decoding). It would be quite some work to map that functions to the 3DS memory map - but at least I do have the code, and more or less know what to do with it.

Arisotura wrote:
if I were you, I would make a separate no$3ds/whatever emulator for this. the 3DS may share a lot of hardware with the DSi for backwards compatibility purposes, but for the purpose of running 3DS software, most of the underlying hardware is completely different.
I'd just worry that cramming all these consoles into one project would result in a bloated codebase, but eh, your choice.
Yeah, I had (originally) thought that 3DS emulation would require new emulator instead of adding 3DS support no$gba. But then... the 3DS does support GBA/NDS/DSi modes, so it would be contraproductive to start a new project with all that features removed.

At 1st glance the 3DS I/O map looks fairly different than DSi, but at 2nd glance it's merely using new base addresses for the old I/O ports. Well, and at 3rd glance there might be hundreds of other subtle differences that I am not aware of yet - but for now, I think I would start with expanding no$gba instead of starting a new emulator, I could still split projects later if needed.

The nastiest part is the MMU. Even if it's relative easy to emulate - it will slowdown the whole CPU emulation. It will require to translate all addresses, and also to check if sequential opcodes fetches are crossing into a new memory page. There it'll really make sense to use two different code versions: fast emulation without 3DS support, and a slower version with 3DS support.

But I am still miles away from emulating MMU or GPU. Before going there, I will first need to emulate the bootrom, and/or basic FIRM code.

Arisotura wrote:
also, if you're ever interested into updating the DS documentation: I have a whole pile of errata/additions
Thanks, yes, I am interested! Ah, on the other hand I am busy with 3DS at the moment (and for some of the older NDS specs I don't even remeber what I had written there years ago). Maybe I can go through the errata step-by-step, and post questions/comments in a separate thread... at times when I need a break from 3DS stuff : )

---

At the moment I am looking into porting Wifiboot from nds/dsi to 3ds. That does also require hundreds of subtle changes (memory map, I/O map, missing SWI function on 3DS, missing NDS-style 16bit DMA channels, different video hardware, and so on). But it should be doable, in 1-2 weeks or so.
The nice thing would be that it would allow to upload FIRM files directly without needing the 3DS OS at all. I guess that's something that wasn't done by anybody yet?
Currently I am still wifi-uploading my FIRM code to DSi, and then use the DSi to rewrite the hardmodded 3DS FIRM. It's working fine, except that I need to plug/unplug the 3DS from the DSi's SD/MMC slot for each upload (plus, I have only one battery charger, so one of two console regularily dies if I forget to switch them off after uploading).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Wed May 22, 2019 11:36 am 
Offline

Joined: Wed Mar 06, 2019 6:00 pm
Posts: 12
A bit off topic but

nocash wrote:
Currently I am still wifi-uploading my FIRM code to DSi, and then use the DSi to rewrite the hardmodded 3DS FIRM. It's working fine, except that I need to plug/unplug the 3DS from the DSi's SD/MMC slot for each upload (plus, I have only one battery charger, so one of two console regularily dies if I forget to switch them off after uploading).


1) Isn't it cool to upload things through WIFI to DS(i)? That speeds up the development time testing a lot. (https://bitbucket.org/Coto88/toolchaing ... server/src)

2) Also you are one the few DIY guys I know, I thought you already had a DIY male USB connector, by ripping the data cables and soldering the positive (+) and negative (-) ends with two DSi-3DS charger port connectors

I have two of these, one for plugging GBA/NDS/DSlite/DSi and the other exactly as above for DSi/3DS

edit:
nocash wrote:
The nastiest part is the MMU. Even if it's relative easy to emulate - it will slowdown the whole CPU emulation. It will require to translate all addresses, and also to check if sequential opcodes fetches are crossing into a new memory page. There it'll really make sense to use two different code versions: fast emulation without 3DS support, and a slower version with 3DS support.


3) the MPU emulation is very similar to MMU emulation (MPU stalls/changes CPU into dataabort/instruction abort if desired), except there is no translation tables but the region protector behaves the same. I planned to support MPU emulation in gbaemu4ds but I dropped the project.

The slowdown happens during CPU Read/Writes and checking the current MPU/MMU state. The problem is somewhat solved by saving up to n MPU/MMU "states". Also there is to consider the current AMBA 2.0 (AHB Bus Protocol) --> NDS(i)

and
AMBA 3 (AXI Bus Protocol) --> 3DS

implementation. Since the MPU/MMU will halt the processor(s) by an exact cycle duty depending on the ARM bus.

AMBA 2.0 (AHB Bus Protocol) vs AMBA 3 (AXI Bus Protocol):
http://tiny.cc/4aclvy


Top
 Profile  
 
PostPosted: Wed May 22, 2019 7:07 pm 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 14
nocash wrote:
Well, about 10000 cycles at 134MHz for 24bits... would be 3us per bit. Maybe not so fast for modern hardware, but also not too slow.

134 MHz is half of the ARM11's core clock. On New 3DS cores can even run up to 804 MHz (clock multiplier 1, 2 or 3).

nocash wrote:
At the moment I am looking into porting Wifiboot from nds/dsi to 3ds. That does also require hundreds of subtle changes (memory map, I/O map, missing SWI function on 3DS, missing NDS-style 16bit DMA channels, different video hardware, and so on). But it should be doable, in 1-2 weeks or so.
The nice thing would be that it would allow to upload FIRM files directly without needing the 3DS OS at all. I guess that's something that wasn't done by anybody yet?

No one has attempted this yet due to differences in hardware/WiFi module firmware and because it's super complex writing a driver and network stack for this monster. All that must be done on ARM11 since the IRQs are only routed to the ARM11 GIC[1] (generic interrupt controller).


[1] ARM doesn't actually call it GIC (for ARMv6 it seems to have no name at all?) but it's almost identical to the very first (official) GIC that was introduced in ARMv7. Really the only real difference seem to be the TrustZone support and a few changed registers. It's way more advanced than any the IRQ hardware used on 3DS ARM9 and on GBA/DS(i).


Top
 Profile  
 
PostPosted: Wed May 29, 2019 6:07 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1025
coto wrote:
1) Isn't it cool to upload things through WIFI to DS(i)? That speeds up the development time testing a lot.
Yup, wifi is very useful for testing things. Only, there seem to be fewer and fewer people wanting to test anything. Some years ago there've been at least a few people saying "generally interested, but don't know how to use WEP". And after adding WPA/WPA2 support... the scene reply has been a massive wall of silence : )

coto wrote:
The slowdown happens during CPU Read/Writes and checking the current MPU/MMU state. The problem is somewhat solved by saving up to n MPU/MMU "states".
You mean caching the MMU page addresses for the most recent memory pages... in emulation?
Hmmmm, hardware-caches should have zero overload, but I would think that searching for cache hits is very when doing it by software.
On the other hand, if there's a 90% chance for cache hits to occur on the first cache entry... then it might be relative fast, even in software.

coto wrote:
AMBA 2.0 (AHB Bus Protocol) vs AMBA 3 (AXI Bus Protocol): http://tiny.cc/4aclvy
What is that AXI stuff that everybody is talking about??? Is that really a thing?
The above doc doesn't look too useful, it doesn't have tech specs. And, giving it quick glance, it doesn't even help on getting a glimpse of an idea on what it is all about (except that it's a new and innovative name for memory addressing, or so).
What I have found out (in another document) is that AXI is supposed to stand for "Advanced eXtensible Interface".
The 3DS is said to have "AXI" registers at 1020F000h, and "AXI" WRAM at 1FF80000h. I've no idea what that means (the WRAM area seems to be just normal RAM mapped to both CPUs, so it looks about same as normal Main RAM, except that it's smaller, and perhaps a bit faster than Main RAM).

PSI wrote:
and of course you need PXI (aka IPC).
That! There, too! Why is everybody calling that PXI??? And what does PXI mean? Did Nintendo drop the original name, and rename it from IPC to PXI at some point?
It seems to have started on dsibrew. And now I am feeling surrounded by AXI and PXI, and I wouldn't be surprised if Dixie and Trixie were joining in soon.

profi200 wrote:
No one has attempted this yet due to differences in hardware/WiFi module firmware and because it's super complex writing a driver and network stack for this monster. All that must be done on ARM11 since the IRQs are only routed to the ARM11 GIC[1] (generic interrupt controller).
I think (or hope) that ARM9 interrupts registers have Wifi IRQs in bit18/bit19. Or well, if that isn't the case, then one could still forward IRQs from ARM11 to ARM9 if neccessary.

But yeah, tiny details like interrupts & timers are a "problem" when porting from NDS/DSi to 3DS. Well, not a real problem, but it was more work than expected to get that little boring details working. I spend the last some days on figuring out how 3DS IRQs are working, and adjusting about hundred NDS-specific parts in the wifiboot source code. I think I am now having most of the timer/irq stuff working. The wifiboot code is now booting up, with timers/irq's enabled, and then hangs in the SDIO init function (which is good, because I just wanted to reach that stage for now, so I can begin with the actual SDIO related coding).

ARM9 Interrupts:
There's this https://www.3dbrew.org/wiki/IRQ_Registers on 3dbrew. That looks straight like GBA/NDS/DSi. The problem is that the meaning of the separate bits is rather unclear. I assume that the abbreviations were ripped from some leaked devkit info, and nobody really means what they mean?
I can guess most bits. Except, what the fuck is a CGC??? And a CGC_DET? I've found some possible meanings on http://acronyms.thefreedictionary.com/CGC but even then... is it for crypto-graphic-cancer detection?

ARM11 Interrupts:
There's this https://www.3dbrew.org/wiki/ARM11_Interrupts on 3dbrew. There's the oppoite problem: The IRQ numbers are more less well described, but the registers aren't described at all (the weird InterruptData structure seems to refer to kernel RAM or so, not to the hardware registers).
What is relative obvious is that ARM11 bootrom handles interrupts via 17E00000h and up. And the wiki mysteriously refers to 17E00000h as "MPCore private memory region".
profi200 wrote:
You should really take a look inside the ARM11 MPCore TRM. It's half the frequency of the CPU core so 134 MHz.
Frequency formula: http://infocenter.arm.com/help/topic/co ... JJEHG.html
General registers: http://infocenter.arm.com/help/topic/co ... 02s02.html
Okay, thanks. I've downloaded the http://infocenter.arm.com/help/topic/co ... p0_trm.pdf linked on that pages, that seems to contain all info needed for ARM11 timers & interrupt registers. I've spend some days on copying the MPCore description into gbatek (and fixing the table formatting). I'll still need to erase all the trash: It's currently about 1100 lines for a few dozen of registers, including utterly useless references to tables and figures:
Code:
This section contains the information that you were looking for.
See Figure 1.2.4 for the information about what you are looking for.
Figure 1.2.4: The information that you were looking for.
  Bit  Name                Type  Description
  [0]  Aviation Disasters  R/W   0'b0 Disable
                                 1'b0 Enable
I don't know why anybody would create such documents. Is that some legal/warranty/safety thing? Like, the document most contain "Figures" for everything, and to be on the safe side, it must also assign a number like 1.2.4 to each figure, and it must explicitely state that the information is contained in figure 1.2.4? Hmmm, or maybe ARM just didn't know how to disable the "auto-generate figures" in their document editor. Personally, I think that the actual information gets lost among all those figure numbers.
PS. Going by the glossary, the meaning of MPCore is not defined. But, reading between the lines, I assume that MP stands for Multi Processing?

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Wed May 29, 2019 8:42 am 
Offline

Joined: Wed Mar 06, 2019 6:00 pm
Posts: 12
nocash wrote:
The above doc doesn't look too useful, it doesn't have tech specs. And, giving it quick glance, it doesn't even help on getting a glimpse of an idea on what it is all about (except that it's a new and innovative name for memory addressing, or so).


Dude. Just google around :

ARM AXI BUS (3DS)

ARM AHB BUS (NDS)
(reference:
http://www.eecs.umich.edu/courses/eecs3 ... e_SPEC.pdf)

The doc explains how to build devices from the outter (IDE-protocol) perspective. It´s the ARM bus. Also IIRC these use(d) master-slave setups and a legacy AXI-to-AHB unit which allows to add AHB devices onto AXI bus. If you search about it, things like MMU and the CPU require the ARM (current bus implementation used through it) bus to be understood first and then these will be emulated properly. (unlike relatively "wired" or "single" control bus, where glued hardware only looks up through a single master clock (CLK) signal and split activity through address and data bus-es). The ARM cores have control bus units for each masters-slave device hooked up to the ARM bus.

(Single) Control Bus definition:
https://en.wikipedia.org/wiki/Control_bus


Top
 Profile  
 
PostPosted: Wed May 29, 2019 9:14 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21628
Location: NE Indiana, USA (NTSC)
nocash wrote:
You mean caching the MMU page addresses for the most recent memory pages... in emulation?

Practical MMU hardware caches page addresses for recently accessed memory pages as a third specialized cache alongside the data and instruction caches. It's called a translation lookaside buffer (TLB). MIPS and some SPARC processors have only a TLB; software must move page table entries in and out of the TLB.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Wed May 29, 2019 10:19 am 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 14
nocash wrote:
Only, there seem to be fewer and fewer people wanting to test anything. Some years ago there've been at least a few people saying "generally interested, but don't know how to use WEP". And after adding WPA/WPA2 support... the scene reply has been a massive wall of silence : )

It's not about testing. It's getting increasingly more complicated and no one wants to spend the time + digging through huge docs or existing driver code like in the Linux kernel.

nocash wrote:
The 3DS is said to have "AXI" registers at 1020F000h, and "AXI" WRAM at 1FF80000h. I've no idea what that means (the WRAM area seems to be just normal RAM mapped to both CPUs, so it looks about same as normal Main RAM, except that it's smaller, and perhaps a bit faster than Main RAM).

These regs seem to be for prioritising. You can give certain bus masters more priority over others. AXIWRAM is probably used because that's what it is. It's attached to the AXI bus. I don't know where the term originated.

nocash wrote:
That! There, too! Why is everybody calling that PXI??? And what does PXI mean? Did Nintendo drop the original name, and rename it from IPC to PXI at some point?

It's the new official name. It was first found in symbols left in code iirc. Same for most other obscure names.

nocash wrote:
I think (or hope) that ARM9 interrupts registers have Wifi IRQs in bit18/bit19. Or well, if that isn't the case, then one could still forward IRQs from ARM11 to ARM9 if neccessary.

Forwarding IRQs would be pretty inefficent. The ARM11 is meant to handle applications, network and more. Fun fact: The WiFi bottleneck is in part due to the slow CPUs. Where i know this from? WiFi speed increased on New 3DS with higher clock :wink: The ARM9 would slow that down a bit more.

nocash wrote:
But yeah, tiny details like interrupts & timers are a "problem" when porting from NDS/DSi to 3DS. Well, not a real problem, but it was more work than expected to get that little boring details working. I spend the last some days on figuring out how 3DS IRQs are working, and adjusting about hundred NDS-specific parts in the wifiboot source code. I think I am now having most of the timer/irq stuff working. The wifiboot code is now booting up, with timers/irq's enabled, and then hangs in the SDIO init function (which is good, because I just wanted to reach that stage for now, so I can begin with the actual SDIO related coding).

ARM9 Interrupts:
There's this https://www.3dbrew.org/wiki/IRQ_Registers on 3dbrew. That looks straight like GBA/NDS/DSi. The problem is that the meaning of the separate bits is rather unclear. I assume that the abbreviations were ripped from some leaked devkit info, and nobody really means what they mean?
I can guess most bits. Except, what the fuck is a CGC??? And a CGC_DET? I've found some possible meanings on http://acronyms.thefreedictionary.com/CGC but even then... is it for crypto-graphic-cancer detection?

It's the same IRQ hardware on ARM9 as on DS(i). Only the master enable is missing but the CPSR I bit of the CPU does the same job. Where the weird names come from i explained above. It's from symbols left in the code. We don't touch SDKs and add that straight to 3dbrew since that can get 3dbrew in trouble (NDA breach and shit).

nocash wrote:
ARM11 Interrupts:
There's this https://www.3dbrew.org/wiki/ARM11_Interrupts on 3dbrew. There's the oppoite problem: The IRQ numbers are more less well described, but the registers aren't described at all (the weird InterruptData structure seems to refer to kernel RAM or so, not to the hardware registers).
What is relative obvious is that ARM11 bootrom handles interrupts via 17E00000h and up. And the wiki mysteriously refers to 17E00000h as "MPCore private memory region".
profi200 wrote:
You should really take a look inside the ARM11 MPCore TRM. It's half the frequency of the CPU core so 134 MHz.
Frequency formula: http://infocenter.arm.com/help/topic/co ... JJEHG.html
General registers: http://infocenter.arm.com/help/topic/co ... 02s02.html
Okay, thanks. I've downloaded the http://infocenter.arm.com/help/topic/co ... p0_trm.pdf linked on that pages, that seems to contain all info needed for ARM11 timers & interrupt registers. I've spend some days on copying the MPCore description into gbatek (and fixing the table formatting). I'll still need to erase all the trash: It's currently about 1100 lines for a few dozen of registers, including utterly useless references to tables and figures:
Code:
This section contains the information that you were looking for.
See Figure 1.2.4 for the information about what you are looking for.
Figure 1.2.4: The information that you were looking for.
  Bit  Name                Type  Description
  [0]  Aviation Disasters  R/W   0'b0 Disable
                                 1'b0 Enable
I don't know why anybody would create such documents. Is that some legal/warranty/safety thing? Like, the document most contain "Figures" for everything, and to be on the safe side, it must also assign a number like 1.2.4 to each figure, and it must explicitely state that the information is contained in figure 1.2.4? Hmmm, or maybe ARM just didn't know how to disable the "auto-generate figures" in their document editor. Personally, I think that the actual information gets lost among all those figure numbers.
PS. Going by the glossary, the meaning of MPCore is not defined. But, reading between the lines, I assume that MP stands for Multi Processing?

The regs are already documented so why copy the official doc from ARM? Don't get me wrong the ARM docs are confusing sometimes but it's all already documented in detail. And i don't know why it's formatted that way. Probably the usual bloated buisiness "it must look perfect" thing. Why we call it MPCore private memory region you probaly already figured out. It's ARM's official name. MPCore seems to be their name for multi core CPUs but they dropped it in ARMv7(?).


And regarding AXI:
It really doesn't matter. You don't need to know all of it unless you want to emulate on the transistor level. Only the delays/stalls and the prioritizing stuff is interesting for the average low level emu.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


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