It seems getting WLAN support into PSPSDK continues to be a problem. I know there are issues with loading modules, however, the problems and solutions seem to be scattered through out the forums.
So, what are the issues, what are the possible solutions, and what do we do to get WLAN support finished and a new release of PSPSDK out the door?
These threads seem to have some details. Where is the other information?
wifi and user mode.
http://forums.ps2dev.org/viewtopic.php?t=3753
Wifi MultiTest .02 - updated WiFi sample code
http://forums.ps2dev.org/viewtopic.php?t=2543
Some sceNet / sceHttpInit usage questions
http://forums.ps2dev.org/viewtopic.php?t=2211
David. aka Oobles.
http://www.livemedia.com.au/Blog
WLAN Support in PSPSDK
I am back and I've started working a new source and binary release of PSPSDK. I'm working through a TODO list which includes a native Win32 installer (ala devkitpro), an updated toolchain (including VFPU support that was never finished), and misc. other fixes.
Network support would be nice, but getting it into PSPSDK in a portable manner is a bit complicated.
Network support would be nice, but getting it into PSPSDK in a portable manner is a bit complicated.
IMHO, there are four categories of work to be done:
#1: integration into the SDK, startup drivers and library entries
There is a technical problem in the way the drivers must be loaded. The current SDK lets you decide between a USER or KERNEL thread (do-it-yourself if you want both)
Assuming you want to load the sceNet drivers from flash0, there are tricks needed (kernel thread, kernel memory module flag)
Also there is some patch trickery for the way dynamically loaded libraries are loaded [all done in loadutil.c in my sample]
#2: UI code
WiFi apps aren't simple 'printf' like apps - they typically require a user interface - to let the user select the connection, and other options
My WiFi .02 sample lets you pick from a list and draw stuff on the screen, but since there are no universal standards in this area it does it it's own way [not the same as the PSP connection picker, or the same as other apps do their drawing]
#3: compatibility with more common Berekely sockets implementations
The sceNetInet are *like* other implementations - but not exactly.
Timeouts are perhaps the biggest compatibility problems.
Working around these can be a pain.
If someone want 99% compatibility with a standard socket implementation (eg: WinSock or common Unix implementations), there would be a lot of patching needed (and disassembling of the existing implementation to find the quirks)
#4: specific features like DHCP or WPA
These are mostly separate from the SDK integration issues.
[ie. if you can get them to work in your app based off the WiFi .02 sample, they should work everywhere]
FWIW: I've given up looking at the DHCP problem. There is something strange going on in the bowels of the system in the DHCP response thread.
---
NOTE: issues #1 and #2 are SDK philosophy and packaging issues. The existing WiFi sample *does* use the PSPSDK, so including it as a very big sample would satisfy these issues. However, it doesn't pass the test of being a small sample -- see the rules: http://forums.ps2dev.org/viewtopic.php?t=2395
The goal of small samples is a good one IMHO - albeit an artificial one. Issues #3 and #4 are true technical problems that need a new solution (or just live with it...)
Or put another way:
IMHO: it "would be nice" to see this integrated into the PSPSDK and made more compatible - but if you want a WiFi program now, it isn't that hard (ie. start with the WiFi .02 sample). SDK integration is an opportunity of cleaning things up. Waiting for SDK integration shouldn't be an excuse.
#1: integration into the SDK, startup drivers and library entries
There is a technical problem in the way the drivers must be loaded. The current SDK lets you decide between a USER or KERNEL thread (do-it-yourself if you want both)
Assuming you want to load the sceNet drivers from flash0, there are tricks needed (kernel thread, kernel memory module flag)
Also there is some patch trickery for the way dynamically loaded libraries are loaded [all done in loadutil.c in my sample]
#2: UI code
WiFi apps aren't simple 'printf' like apps - they typically require a user interface - to let the user select the connection, and other options
My WiFi .02 sample lets you pick from a list and draw stuff on the screen, but since there are no universal standards in this area it does it it's own way [not the same as the PSP connection picker, or the same as other apps do their drawing]
#3: compatibility with more common Berekely sockets implementations
The sceNetInet are *like* other implementations - but not exactly.
Timeouts are perhaps the biggest compatibility problems.
Working around these can be a pain.
If someone want 99% compatibility with a standard socket implementation (eg: WinSock or common Unix implementations), there would be a lot of patching needed (and disassembling of the existing implementation to find the quirks)
#4: specific features like DHCP or WPA
These are mostly separate from the SDK integration issues.
[ie. if you can get them to work in your app based off the WiFi .02 sample, they should work everywhere]
FWIW: I've given up looking at the DHCP problem. There is something strange going on in the bowels of the system in the DHCP response thread.
---
NOTE: issues #1 and #2 are SDK philosophy and packaging issues. The existing WiFi sample *does* use the PSPSDK, so including it as a very big sample would satisfy these issues. However, it doesn't pass the test of being a small sample -- see the rules: http://forums.ps2dev.org/viewtopic.php?t=2395
The goal of small samples is a good one IMHO - albeit an artificial one. Issues #3 and #4 are true technical problems that need a new solution (or just live with it...)
Or put another way:
IMHO: it "would be nice" to see this integrated into the PSPSDK and made more compatible - but if you want a WiFi program now, it isn't that hard (ie. start with the WiFi .02 sample). SDK integration is an opportunity of cleaning things up. Waiting for SDK integration shouldn't be an excuse.
-
florinsasu
- Posts: 47
- Joined: Wed Dec 15, 2004 4:23 am
the problem with loading network modules is that they are running in user mode. kernel application cannot link to user-mode modules afaik. if our app is running in user-mode it cannot load the modules from flash or ms.
so there are 2 solutions:
1. another kernel mode patch added to pspsdk to allow a kernel module to link with user libs
2. have a kernel-mode loader (that loads high!) that does all the kernel mode "dirty tricks", ie. apply the currently available patches
and then calls sceKernelLoadModule with the actual user-mode net application
Note: the load high can be eliminated if the "loader" is a prx and not a pfx
so there are 2 solutions:
1. another kernel mode patch added to pspsdk to allow a kernel module to link with user libs
2. have a kernel-mode loader (that loads high!) that does all the kernel mode "dirty tricks", ie. apply the currently available patches
and then calls sceKernelLoadModule with the actual user-mode net application
Note: the load high can be eliminated if the "loader" is a prx and not a pfx
DHCP working
UPDATE: thanks to 'benji' who discovered a combination that does work for DHCP !
The drivers must be loaded in kernel mode thread (with kernel memory access) and everything else, including nlhInit, sceNetApctlConnect and subsequent socket calls should be called from a user mode thread. Don't mix any calls between user and kernel mode and DHCP works great.
Will update my WiFi sample soon - but if anyone is working on a lower-level SDK implementation, the DHCP support should fall out. Be sure to force everything to happen in a User mode thread, except driver/library load/start which must be done in created Kernel mode thread (not the init()/static constructor startup code)
---
'florinsasu' wrote:
> so there are 2 solutions:
> 1. another kernel mode patch added to pspsdk...
> 2. have a kernel-mode loader (that loads high!) that does all the kernel mode "dirty tricks"...
Or 3. do the "dirty tricks" in a PSPSDK support function (like my loadutil.c).
Someone needs to decide how they want this done officially in the PSPSDK. I vote for #3 since that's how WiFi apps are done today. IMHO the PSPSDK should be an "SDK", not a system-patch, bag-of-loader-tricks - but that's just my opinion.
The drivers must be loaded in kernel mode thread (with kernel memory access) and everything else, including nlhInit, sceNetApctlConnect and subsequent socket calls should be called from a user mode thread. Don't mix any calls between user and kernel mode and DHCP works great.
Will update my WiFi sample soon - but if anyone is working on a lower-level SDK implementation, the DHCP support should fall out. Be sure to force everything to happen in a User mode thread, except driver/library load/start which must be done in created Kernel mode thread (not the init()/static constructor startup code)
---
'florinsasu' wrote:
> so there are 2 solutions:
> 1. another kernel mode patch added to pspsdk...
> 2. have a kernel-mode loader (that loads high!) that does all the kernel mode "dirty tricks"...
Or 3. do the "dirty tricks" in a PSPSDK support function (like my loadutil.c).
Someone needs to decide how they want this done officially in the PSPSDK. I vote for #3 since that's how WiFi apps are done today. IMHO the PSPSDK should be an "SDK", not a system-patch, bag-of-loader-tricks - but that's just my opinion.
Re: DHCP working
That's why we have libpspsdk.a :).PspPet wrote:'florinsasu' wrote:
> so there are 2 solutions:
> 1. another kernel mode patch added to pspsdk...
> 2. have a kernel-mode loader (that loads high!) that does all the kernel mode "dirty tricks"...
Or 3. do the "dirty tricks" in a PSPSDK support function (like my loadutil.c).
Someone needs to decide how they want this done officially in the PSPSDK. I vote for #3 since that's how WiFi apps are done today. IMHO the PSPSDK should be an "SDK", not a system-patch, bag-of-loader-tricks - but that's just my opinion.
I'll start working on adding networking support to PSPSDK soon...
Re: DHCP working
Wow!! It really does work!! I just got PSPRadio reworked following your note, and DHCP is working now!PspPet wrote:UPDATE: thanks to 'benji' who discovered a combination that does work for DHCP !
The drivers must be loaded in kernel mode thread (with kernel memory access) and everything else, including nlhInit, sceNetApctlConnect and subsequent socket calls should be called from a user mode thread. Don't mix any calls between user and kernel mode and DHCP works great.
Will update my WiFi sample soon - but if anyone is working on a lower-level SDK implementation, the DHCP support should fall out. Be sure to force everything to happen in a User mode thread, except driver/library load/start which must be done in created Kernel mode thread (not the init()/static constructor startup code)
Thanks!,
Raf.
Re: DHCP working
why not like pspaudio, a layer between user code and net code, like pspNetInit() that does kernel stuff?PspPet wrote:UPDATE: thanks to 'benji' who discovered a combination that does work for DHCP !
The drivers must be loaded in kernel mode thread (with kernel memory access) and everything else, including nlhInit, sceNetApctlConnect and subsequent socket calls should be called from a user mode thread. Don't mix any calls between user and kernel mode and DHCP works great.
Will update my WiFi sample soon - but if anyone is working on a lower-level SDK implementation, the DHCP support should fall out. Be sure to force everything to happen in a User mode thread, except driver/library load/start which must be done in created Kernel mode thread (not the init()/static constructor startup code)
---
'florinsasu' wrote:
> so there are 2 solutions:
> 1. another kernel mode patch added to pspsdk...
> 2. have a kernel-mode loader (that loads high!) that does all the kernel mode "dirty tricks"...
Or 3. do the "dirty tricks" in a PSPSDK support function (like my loadutil.c).
Someone needs to decide how they want this done officially in the PSPSDK. I vote for #3 since that's how WiFi apps are done today. IMHO the PSPSDK should be an "SDK", not a system-patch, bag-of-loader-tricks - but that's just my opinion.
I've been using the resolver for a while with great success in PSPRadio. Have a look the code if interested.danzel wrote:Doh, of course.
Has anyone figured out the DNS Resolving stuff yet?
I see the stubs in stubs.s but theres no headers to go with them, and my few hacky tests havent come up with anything.
Danzel.
Raf.