dswifi ASM port, and bugs in dswifi HLL version

Discussion in 'NDS - Emulation and Homebrew' started by nocash123, Nov 3, 2016.

  1. nocash123
    OP

    Newcomer nocash123 Advanced Member

    Joined:
    Aug 4, 2015
    Messages:
    63
    Country:
    Afghanistan
    Here's the dswifi librbary ported to ASM code. I've been busy on that project for the past five weeks, and just finished the port yesterday, it's still untested, still lacks some basic subfunctions (like memcopy), and I've probably screwed up a lot of things and the code is probably still totally bugged.

    Anyways, during porting, I've naturally had to 'review' every single line of code in the original HLL versions, and came across a bunch of bugs & oddities in the original code. For details, check the ASM file, and search for comments with tags "BUGGED", "BLAH", and "uh":

    View attachment 67769 - dswifi ASM port (new ASM code, with comments on HLL bugs)
    View attachment 67770 - dswifi HLL code (just for reference: the original HLL code, merged into a single txt file)

    EDIT: Hmmm, above links have no permission to view the attachment(?) alternately try thes links (should be working, unless that "temp hash" expires at some point; or unless it should work only with my own IP):
    http://gbatemp.net/attachments/dswifi01-txt.67769/?temp_hash=1582d05735d506a4e68e6c28013f9808 - ASM
    http://gbatemp.net/attachments/dswifi00-txt.67770/?temp_hash=1582d05735d506a4e68e6c28013f9808 - HLL
    (if somebody knows how to use the forums "ATTACH" feature please PM me, just using the attachment number enclosed in ATTACH and /ATTACH doesn't seem to work out)

    Tag BUGGED indicates real bugs (unless I've totally misunderstood the code). For example, checksum calculation looks wrong in some cases (carry-out handling, or checksum-zero handling), the checksumming should work in most cases, but it might produce transmission errors at 1:65535 chance (possibly passing okay if retransmissions are done with different headers & different checksums). Some other bugs include cropping the transfer length to the bigger of two values (instead of the smaller value).

    Tag BLAH (no offense) indicates useless/unused functions & variables. Some if of it is subjective though (the "extern" definitions are (only) useless when merging the whole source code into a single file; and some of the unused variables might have some purpose for debug/status stuff).

    Tag uh indicates stuff that's unclear to me. Some of it might be bugged, or it might be actually working and intended as-is (but would be nice to get some comments/confirmations that explain how/why it's working).

    The function names are 99% same as in the original code, so it should be easy to naviagate between the comments in the ASM file and the original code in the HLL files. Main difference is that I've prefixed some functions names by "arm7_" or "arm9_", just remove that prefixes to get the original name.

    PS. what I am actually up to is trying to make some wifi uploader that works more reliable than dslink, and preferably also smaller; my current binary is 32Kbytes, and it could be compressed to around 16Kbytes, but it's still too big for DSi cartridge exploits with only have 8Kbytes of save memory, but maybe I can throw away some components: DNS shouldn't be needed for local networks, and Stephen suggested that one could also use non-TCP transmissions, and, not sure if one needs DHCP and IP addresses at all... or could one also use the DS(i)'s MAC address directly from within local networks?
     
    Last edited by nocash123, Nov 3, 2016
  2. dark_samus3

    Member dark_samus3 GBAtemp Addict

    Joined:
    May 30, 2015
    Messages:
    2,298
    Country:
    United States
    for the saves stuff, why not look into compression for the code, that might help (I know it helped a lot for some 3ds related stuff) as for the rest of it, I haven't looked it over yet, but looks like it might be neat
     
  3. elhobbs

    Member elhobbs GBAtemp Advanced Fan

    Joined:
    Jul 28, 2008
    Messages:
    673
    Country:
    United States
    not sure if this is of any interest to you but I did do some work with wifi for the ds and refactored the dswifi code a bit for a peer to peer version of cquake. this uses fnet instead of the dswifi protocol stack. cquake only used udp but I did do some minimal tests with tcp/ip and it was working. this supports connecting to an AP or acting as a AP for other ds consoles to connect to.
    https://storage.googleapis.com/goog.../code.google.com/cquake/cnquake_src_062813.7z
     
  4. reprep

    Member reprep GBAtemp Advanced Fan

    Joined:
    Jul 5, 2012
    Messages:
    831
    Country:
    Turkey
    Can't wait to use this on my The Biggest Loser dsi cartridge. Hope you can make it fit on 8kbit. Also dslink doesn't work on DWM-W024 boards so my dsi xl cant run it. Hope this works on all versions.
     
  5. nocash123
    OP

    Newcomer nocash123 Advanced Member

    Joined:
    Aug 4, 2015
    Messages:
    63
    Country:
    Afghanistan
    Got it working! Source code in ASM and binaries are here: http://gbatemp.net/attachments/dswifi02-zip.70966/?temp_hash=7042fdc7b23b7be3a7981eeb760df513 - that package includes:

    ASM port of the dswifi library from Stephen Stair - same as mentioned in the earlier post, but after adding some glue logic and fixing dozens of mistakes in my ASM code it's now actually tested & working quite well. Sometimes it's disconnecting (displaying "-DIS-") immediately after connecting to an accesspoint (and then requires to reboot and try again). I haven't yet figured out what is causing that issue, but apart from that, everything looks stable.
    Oh, and one nice feature is that my channel scanning is ways faster as in the original dswifi version, so it should find your access point almost instantly (if it's on a common channel, ie. 1,6,11).

    ASM clone of the dslink tool from wintermute - more or less same as the original dslink tool (allowing to wifi-upload bootcode from .nds/.dsi files to the console). The main difference is that my ASM version will initialize the stacks & hardware similar as how they are initialized by real NDS firmware (the original dslink didn't do so, causing the uploaded code to crash instantly after uploading), that's been the main reason why I've spend 9 weeks on that dswifi asm port (although, when I was almost done with that project, wintermute suddenly started to fix the bugs in the dslink HLL version, so I could have as well wasted my time on something else).
    For the PC side, I'll probably add an "upload" function in next no$gba update. For now, people could use my dslink.nds ASM version on console side with wintermute's dslink.exe on PC side.

    Dumping tool for several DSi chips - this is allowing to dump ROM, FLASH, Chip IDs, I/O ports from DSi wifi daughterboard, and DSi cameras... stuff that hasn't been done in the past years, apparently the HLL guys didn't knew how to, but with my wifi ASM port nobody is needing HLL programmers any longer ; ) and it should be now possible to figure out which chip(s) from which manufacturer(s) Nintendo has been using in their wifi/camera hardware on DSi (and 3DS). For using it:
    - Start "dsdump.dsi" on the console (in DSi mode) (and make source that you've configured wifi access point 1-3 in system settings, working should be open access points, with or without DHCP, and WEP should work too, but it's still untested).
    - Start "dsdump.exe" on a windows PC, that tool should then receive five files from the DSi/3DS console and save them as "dump*.bin", the dumping/transfer takes a few seconds for the first four files, the last file will take several minutes (it's intended to dump the wifi ROM, but for most wifi boards it's still unknown where the ROM is located in memory, so it dumping the whole 4Mbyte address space of the wifi chip, which is kinda slow unfortunately).
    After dumping all files, the PC tool should exit, and the console should display DUMPDONE. Ah, and if it finds unidentified hardware during dumping, then it should display UNKNOWN HARDWARE in red ink on the console screen. Which, I would be interested in getting the dumps or chip IDs for any such hardware (or even better, hopefully getting the actual hardware some day).
     

    Attached Files:

    Last edited by nocash123, Dec 3, 2016
    I pwned U!, dark_samus3 and windwakr like this.
  6. nocash123
    OP

    Newcomer nocash123 Advanced Member

    Joined:
    Aug 4, 2015
    Messages:
    63
    Country:
    Afghanistan
    Updated the wifi code and dsi memory dumping tool:

    New Wifi code contains a bugfix for WEP encryption, though WEP is still untested to my knowledge... or did anybody test it? And it's having a bugfix for handling wifi disassocation requests (which should be fixed in original dswifi library too, although the original lib doesn't ever seem to encounter disassociation, but if it would do so, then the bugfix would help; the original code did just ignore disassociation requests).

    DSi memory dumper does now contain an extra function for dumping the I2C bus wifi calibration EEPROM, including for the overwritten word at index [F0h] and including for the unused bytes at index [300h..3FFh], which seem to be just zerofilled. The main work there has been to write an Xtensa instruction set assembler for being able to run custom code on the Wifi CPU. The EEPROM dumping code is tested/working on AR6002 (old DSi). It's also intended to work on AR6013 (new DSi which uses different GPIO pins for I2C bus). The only thing that won't work is dumping the EEPROM on AR6014 (3DS and New3DS, which, I think, it isn't yet even known if that consoles do contain an I2C bus EEPROM at all, least how to dump it).

    To all hackers & crackers: It's all up to you: You can be the first person ever to discover new unknown hardware! Just run that dsdump.dsi tool on your DSi/3DS and dsdump.exe on your PC, and watch out for messages saying "UNKNOWN HARDWARE" in red ink. Hacking's never been simple! Or if it doesn't work for some reason, please let me know!

    http://gbatemp.net/attachments/dswifi03-zip.72277/?temp_hash=97d672ff546b4322536bb2b1cdbec149
     

    Attached Files:

    Coto and I pwned U! like this.
  7. Coto

    Member Coto GBAtemp Addict

    Joined:
    Jun 4, 2010
    Messages:
    2,298
    Country:
    Chile
    Fun-documented assembly.

    Now why dont you submit these bugfixed to DSWIFI then? For example NesDS NIFI uses a modified https://github.com/cotodevel/NesDS/commit/0582d5ba914ca5108978a72448e78aea3fca790b

    Not that I could not do that, but if you invested three weeks of your life on it, I guess the world could benefit from it. From the same author who invented those fixes.

    If I program something cool I'd use C and distribute that but I have the feeling you hate C (because of HLL programmers, like me sometimes). I can literally rewrite everything in assembly but if a bug appears it becomes very hard to track down (unless a dev unit, which I have never seen in my life). So I resort to -03 + inline stuff and strip debug symbols from GNU ARM (.s) assembly files and objdump the assembled stuff to see if they match the C logic code

    Also you use your own disassembler (which I think it's OK and cool to create our own stuff), but then you lose compatibility with GNU ARM syntax (divided syntax and unified syntax). Otherwise perhaps a parser to export to them would be handy to backport disassembled objects from GNU ARM files.

    just my 0.02 cents,but nonetheless pretty good work nocash
     
  8. nocash123
    OP

    Newcomer nocash123 Advanced Member

    Joined:
    Aug 4, 2015
    Messages:
    63
    Country:
    Afghanistan
    I've sent the asm file with bug-list to Stephen Stair (the dswifi author), and he has already fixed some of the bugs, there is no official update released yet, but I think there's already some branch or fork or what it is called on github, containing the changes that Stephen has made recently.

    For me it's versa, I feel better with ASM and quickly get scared in HLL and I can only guess what it wants say, especially if it's using those retro-kewl =--!^?|++ symbols instead of english keywords ; / but yeah, different people like different things, and some can probably understand HLL languages (or I would hope so).

    Apropos... the Red Ink. Some years ago I've read that many people can get scared by certain colors - if that's a problem to somebody then I could change the color of the "UNKNOWN HARDWARE" text message! I would be just glad if somebody would dare test the dumping tool someday. Or if somebody knows somebody who could test it on a DSi console - please tell them about it!

    For (dis-)assembler syntax, yup, I am usually brewing up my own syntax/dialect (and the dswifi port is using that syntax, which might prevent most people from using it). Aside from that all of the no$xxx programs contain options for selecting either nocash or native syntax, so everybody could use either one as desired.
    Except... I have never heard of that new "Unified" ARM syntax, so that isn't supported... just checked what it's about, and appending the "S suffix to THUMB opcode does really make a lot of sense (in the old syntax MOV and MOVS having kinda opposite meanings in ARM/THUMB was always preventing me from trying write anything in THUMB code).
     
    Last edited by nocash123, Dec 17, 2016
    DanTheManMS likes this.
  9. Normmatt

    Member Normmatt Former AKAIO Programmer

    Joined:
    Dec 14, 2004
    Messages:
    2,136
    Country:
    New Zealand
    This file doesn't seem to load from sudokuhax for me... just goes to a black screen and isn't connected to my wifi...
     
  10. Shicky256

    Member Shicky256 GBAtemp Regular

    Joined:
    Oct 13, 2013
    Messages:
    110
    Country:
    United States
    Does the dsdump tool work in dslink? When I tried it I got a black top screen and white bottom screen (might be the other way around but whatever) and it didn't connect to the wifi. This is a "launch day" dsi (it came with 1.2 when I got it off ebay), so it might be interesting to see the hardware I guess
     
  11. nocash123
    OP

    Newcomer nocash123 Advanced Member

    Joined:
    Aug 4, 2015
    Messages:
    63
    Country:
    Afghanistan
    Yes/no, it's working with wintermute's newest dslink version, but I am afraid that that version isn't officially released yet. And renaming it to boot.nds for directly starting it with sudokuhax... I didn't really try that (didn't have the sd-cart-slot attached to the dsi mainboard)... hmmm, tried now... and it really doesn't work. Attached is a new version that should work with sudokuhax (maybe also with the old dslink version). Ah, and WEP has been tested meanwhile too (and it's working fine).

    And, I've started investigating the TeakLite II coprocessor: Disassembled the "aac.a" from the DSi Sound utility, merged it with the included function names from the COFF symbol table, and made some more or less working assembler for programming own Teak code & running actual tests on the hardware. The new dsdump version includes a function for dumping the Teak's memory mapped I/O ports (showing the port address, it's value, and it's values after writing 0000h and FFFFh). Parts of the I/O specs can be also extracted from the disassembled code/symbols, especially the IRQ and CMD/REPLY/SEMAPHORE stuff looks quite straight, the Audio/DMA part looks a bit more difficult.

    EDIT: updated the dsdump.dsi tool (small bugfix on teak mapping, and changed arm7 org addr), the changed files are in dswifi05.zip. And for the other/unchanged files, see the old dswifi04.zip package.
     

    Attached Files:

    Last edited by nocash123, Jan 17, 2017 at 3:54 PM
    I pwned U! likes this.

Share This Page