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.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.
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).
Do you know what frequency that MPCore timer counts at? Bootrom code looks like... 134MHz?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.
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).
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).profi200 wrote:Everything detects modified FIRM partitions by looking for the sighax signatures. That's it.
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.
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).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.
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).