gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > DS to DS communication

#175895 - sverx - Fri Feb 25, 2011 12:10 pm

I just didn't want to reply to this 2009 topic, so I'm starting a new one...
What's going on about DS to DS communication?
So far I've read that liblobby isn't working, and that maybe there's a way to build up sort of a channel using raw wi-fi packets.
Has anyone gone ahead? Any POC or sources that I can see?
Thanks :)

#175897 - wintermute - Fri Feb 25, 2011 12:47 pm

Nothing public exists yet.

There are unfortunately rather a lot of issues to deal with in attempting to provide this kind of functionality. All of the code people keep pointing to is broken in various "interesting" ways which vary from being completely unreliable to having the potential to render your whole wifi network completely unusable (quite possibly your neighbours too)

I have some code in test which provides some of the basics but I'm reluctant to share thanks to people jumping on hacky code and providing "tutorials" on how to use it to make the tools not work as expected. DSwifi is already creaking a bit with some hacks we put in to work around problems that were related to not fully understanding the hardware at the time the library was created. We're also now faced with supporting yet another wifi chipset in the DSi and that needs some thought to redesign the default arm7 code so it allows for the use of DSi features without losing the ability to run on a DS. devkitARM release 33 is also under test and should be available at some point in the not very distant future.

Obviously the ideal situation is for sgstair to finish off some current projects needed to properly RE the wifi hardware and put together the new dswifi that's been promised for so long.

I do understand that lots of people want this but getting it right is an enormous challenge and provoking ill informed discussion tends to slow things down. We don't need or want several implementations coming from people who can't or won't make sure that their code can be integrated into the libraries provided by devkitPro. When that happens everybody loses.

What would probably help most is finding some people with a complete understanding of 802.11 standards and low level knowledge of wifi chipsets in general. Bear in mind that linux drivers still don't provide all the functionality of some chipsets due to the difficulty in obtaining the knowledge required to write the drivers.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#175899 - TwentySeven - Fri Feb 25, 2011 1:02 pm

Excellent post Wintermute, thankyou for the heads up.

#175900 - sverx - Fri Feb 25, 2011 2:01 pm

wintermute wrote:
[...] to having the potential to render your whole wifi network completely unusable (quite possibly your neighbours too)


We could write jamming tools :D ;)

Thanks for the post, I hope we will have something to test soon.

#175946 - sverx - Mon Mar 07, 2011 2:17 pm

I was reading an article about Nintendo 3DS and I read it has an Atheros chip in it, for wi-fi. Is it possible that there's a similar chip in the DS and/or DSi too?

#175949 - yellowstar - Mon Mar 07, 2011 8:40 pm

sverx wrote:
I was reading an article about Nintendo 3DS and I read it has an Atheros chip in it, for wi-fi. Is it possible that there's a similar chip in the DS and/or DSi too?

3DS uses a similar(if not identical) AR6001X wifi chipset to DSi.(don't remember the exact model for DSi wifi chipset) DS uses some unrelated proprietary chipset iirc.

#175953 - wintermute - Tue Mar 08, 2011 4:22 pm

DS has a Mitsumi MM3155, DS Lite has Mitsumi MM3128.

The DSi has both Mitsumi MM3128 and an Atheros AR6002.

Much work needs to be done before the Atheros chip can be supported, notably deciding on how best to arrange the arm7 code. I think we've probably gone as far as we can with DSi support in the current default arm7 binary and it's unlikely that camera and new wifi support can be squeezed in there without a serious detrimental effect on the utility of the code.

Right now I'm not entirely sure how Nintendo handle hybrid arm7 code - it looks like both binaries are loaded at startup but it's not clear whether the DSi arm7 is a simple extension of the DS arm7 code or if it's effectively a replacement. I suspect the best approach may be to build the default core with two segments with DSi specific code separated into a segment which ndstool extracts from the elf into the arm7i section of the nds container format.

Another big, big issue is that official DSi code contains traces of a commercial wpa supplicant, obviously used for WPA authentication and probably modified with protocols for Nintendo Zones.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#175955 - sverx - Wed Mar 09, 2011 10:43 am

Googling around I've seen there are no datasheets for those Mitsumi, I believe now I understand why there are still problems with it. (BTW I wonder if Mitsumi has ever made a similar chip with public datasheets, might be worth checking...).

Hopefully anyway Atheros specs are easier to find... again I've read around there are open implementations of drivers so it could be a good place to start...

Quote:
I suspect the best approach may be to build the default core with two segments with DSi specific code separated into a segment which ndstool extracts from the elf into the arm7i section of the nds container format.


You mean we would probably have ndstool packing 2 distinct arm7 parts together with arm9 part?

#175956 - elhobbs - Wed Mar 09, 2011 3:21 pm

sverx wrote:
Googling around I've seen there are no datasheets for those Mitsumi, I believe now I understand why there are still problems with it. (BTW I wonder if Mitsumi has ever made a similar chip with public datasheets, might be worth checking...).
I think the problems are also from the fact that dswifi was a work in progress - with lots of things being figured out while it was being written. sgstair has always said that it was a little bit of a mess that he intended to rewrite completely.

#175957 - wintermute - Wed Mar 09, 2011 11:20 pm

sverx wrote:

Hopefully anyway Atheros specs are easier to find... again I've read around there are open implementations of drivers so it could be a good place to start...


Only Atheros docs I can find have big "DO NOT COPY" written across them :/

Also open implementations tend to be linux which tend to require all kinds of crap that isn't found on a bare metal system.

Quote:

Quote:
I suspect the best approach may be to build the default core with two segments with DSi specific code separated into a segment which ndstool extracts from the elf into the arm7i section of the nds container format.


You mean we would probably have ndstool packing 2 distinct arm7 parts together with arm9 part?


No, I mean a single arm7 binary which has a second part held in a different memory region that only gets loaded in DSi mode.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#175958 - sverx - Thu Mar 10, 2011 4:45 pm

wintermute wrote:
I mean a single arm7 binary which has a second part held in a different memory region that only gets loaded in DSi mode.

Wow! Seems a very good solution :) And this second part will contain Atheros chip specific code and other code that isn't needed on a (phat/lite) DS if I understand correctly. Unfortunately this doesn't help dswifi...

#175966 - yellowstar - Fri Mar 11, 2011 7:07 pm

wintermute wrote:

Right now I'm not entirely sure how Nintendo handle hybrid arm7 code - it looks like both binaries are loaded at startup but it's not clear whether the DSi arm7 is a simple extension of the DS arm7 code or if it's effectively a replacement.


Launcher/sysmenu loads the arm7/arm9 bins when it launches titles, and loads the arm9i/arm7i bins into memory when they exist. The arm7/arm9 crt0 then relocates the twl bins to the final VMA sections when the twl bins exist and when running in DSi-mode. The arm7i is not an replacement, it's an extension: code is executed in both the arm7 and arm7i.
The SD card loader Sudokuhax uses loads the arm7i/arm9i binaries from boot.nds when those exist.

wintermute wrote:

I suspect the best approach may be to build the default core with two segments with DSi specific code separated into a segment which ndstool extracts from the elf into the arm7i section of the nds container format.

Sounds good. :)

wintermute wrote:

Another big, big issue is that official DSi code contains traces of a commercial wpa supplicant, obviously used for WPA authentication and probably modified with protocols for Nintendo Zones.

NZone is just standard 802.11b wifi they only use cleartext/WEP with those, they send an encrypted beacon which the client uses to determine which SSID+key to connect to.