Page 1 of 2
Unofficial LaunchELF related ps2sdk changes
Posted: Tue Jan 16, 2007 10:26 am
by EP
Here are most of the diffs from what's currently in the ps2sdk vs. what we've made changes to:
Dlanor is better at explaining some of this stuff but if you have any questions just ask.
If you don't like this format, let me know and I'll gladly change it.
ps2sdksrc\ee\rpc\memorycard\include\libmc.h
Code: Select all
60a61,64
> // Additional valid bits for MC attributes, deduced by 'dlanor'
> #define MC_ATTR_FILE 0x0010 //Set for any file on MC
> #define MC_ATTR_OBJECT 0x0030 //Mask to find either folder or file
>
147a152,156
> #define MC_TYPE_RESET 0xDEAD
> //RA NB: mcInit(MC_TYPE_RESET) after IOP Reset, to forget old modules
> //RA NB: This will not reinitialize anything for use of MC. To do that
> //RA NB: you will need to mcInit(MC_TYPEMC) or mcInit(MC_TYPEXMC),
> //RA NB: after having loaded modules to the IOP again.
281,282c290,291
< // data to be changed
< // flags to show which data is valid
---
> // data to be changed //RA NB: This is an mcTable struct
> // flags to show which data is valid //0xFFFF works with valid mcTable structs
285c294
< int mcSetFileInfo(int port, int slot, const char* name, const char* info, unsigned flags);
---
> int mcSetFileInfo(int port, int slot, const char* name, const mcTable* info, unsigned flags);
Code: Select all
228a229,234
> if (type == MC_TYPE_RESET)
> { mclibInited = 0;
> cdata.server = NULL;
> return 0;
> }
>
673c679
< int mcSetFileInfo(int port, int slot, const char* name, const char* info, unsigned flags)
---
> int mcSetFileInfo(int port, int slot, const char* name, const mcTable* info, unsigned flags)
Code: Select all
129a130,135
> /* Since padEnd() further below doesn't work right, a pseudo function is needed
> * to allow recovery after IOP reset. This function has nothing to do with the
> * functions of the IOP modules. It merely resets variables for the EE routines.
> */
> int padReset();
>
Code: Select all
257a258,270
> /* Since padEnd() further below doesn't work right, a pseudo function is needed
> * to allow recovery after IOP reset. This function has nothing to do with the
> * functions of the IOP modules. It merely resets variables for the EE routines.
> */
> int
> padReset()
> {
> padInitialised = 0;
> padsif[0].server = NULL;
> padsif[1].server = NULL;
> return 0;
> }
>
568c581
< else if (pdata->nrOfModes < index) {
---
> else if (index < pdata->nrOfModes) {
Code: Select all
129a130,135
> /* Since padEnd() further below doesn't work right, a pseudo function is needed
> * to allow recovery after IOP reset. This function has nothing to do with the
> * functions of the IOP modules. It merely resets variables for the EE routines.
> */
> int padReset();
>
Code: Select all
256a257,270
> /* Since padEnd() further below doesn't work right, a pseudo function is needed
> * to allow recovery after IOP reset. This function has nothing to do with the
> * functions of the IOP modules. It merely resets variables for the EE routines.
> */
> int
> padReset()
> {
> padInitialised = 0;
> padsif[0].server = NULL;
> padsif[1].server = NULL;
> return 0;
> }
>
>
566c580
< else if (pdata->nrOfModes < index) {
---
> else if (index < pdata->nrOfModes) {
Change that fixes an issue when compiling with the older 2.8.1 IOP compiler.
The change from 1024 to 512 was do to an inaccuracy in partition sizes. Size is in bytes.
Code: Select all
362a363
> u64 size;
367,368c368,369
< u64 size = clink->header->length;
< size *= 1024;
---
> size = clink->header->length;
> size *= 512;
The first change forces the hour timestamp to Tokyo time to matchup with the mc driver.
Note: this change now resides in the usbhdfsd driver.
The second change with the IlinkID allows for those using hard drives in their slim model PS2's.
Code: Select all
46c46
< timeBuf.hour = (timeBuf.hour + 4) % 24; // TEMP FIX (need to deal with timezones?)
---
> //timeBuf.hour = (timeBuf.hour + 4) % 24; // TEMP FIX (need to deal with timezones?)
69,73c69,70
< if(CdReadIlinkID(idbuf, &err))
< if(err==0)
< return 0;
< dprintf1("ps2hdd: Error: cannot get ilink id\n");
< return -EIO;
---
> CdReadIlinkID(idbuf, &err);
> return 0;
Changes hour timestamp to Tokyo time to matchup with the mc driver
Note: this change now resides in the usbhdfsd driver.
Code: Select all
47c47
< timeBuf.hour = (timeBuf.hour + 4) % 24; // TEMP FIX (need to deal with timezones?)
---
> //timeBuf.hour = (timeBuf.hour + 4) % 24; // TEMP FIX (need to deal with timezones?)
Posted: Tue Jan 16, 2007 8:19 pm
by jbit
Thanks for the reports... I have a few comments/questions before committing (although most of it does look committable)
I don't like having mcInit(MC_TYPE_RESET) and padReset().
A) I'd prefer mcReset() and padReset() (since they seem to do similar, and keeping similar APIs is nice)
B) Shouldn't this happen in the End() functions anyway?
I guess it's useful to have these reset functions as well as End() functions. (In case it's not possible to call End before the reset, for example)
Is there any known reason why the hdd size was multiplied by 1024 and not 512?
I have no idea about the timezone stuff, I'll have to have a think about it when it's not 10:30am at night.
Is there anything else? I believe you mentioned something about iomanX and the cdvd library.
Can you make sure to compare difference with the latest svn version (since that's what i'll be working against)
And i do prefer "unified" diff format (diff -u")
Thanks again :)
Posted: Tue Jan 16, 2007 10:15 pm
by Henk
Are those the exact same changes as found in uLaunchELF v4.08\Source\Changed source for external projects\ps2sdk?
I tried to apply them to my yesterday's fresh checkout of ps2sdk and when I complile them I get this:
make[4]: Entering directory `/root/ps2dev/toolchain/ps2sdk/iop/tcpip/tcpip'
iop-gcc -fno-builtin -O2 -G0 -c -I/root/ps2dev/toolchain/ps2sdk/iop/tcpip/lwip/src/include -I/root/ps2dev/toolchain/ps2sdk/iop/tcpip/lwip/src/include/ipv4 -Isrc/include -I/root/ps2dev/toolchain/ps2sdk/iop/kernel/include -I/root/ps2dev/toolchain/ps2sdk/common/include -Iinclude -Wall -fno-builtin-printf -DLWIP_NOASSERT src/ps2ip.c -o obj/ps2ip.o
src/ps2ip.c: In function `ps2ip_input':
src/ps2ip.c:344: `arch_message' undeclared (first use in this function)
src/ps2ip.c:344: (Each undeclared identifier is reported only once
src/ps2ip.c:344: for each function it appears in.)
src/ps2ip.c:344: `msg' undeclared (first use in this function)
src/ps2ip.c:348: warning: implicit declaration of function `alloc_msg'
src/ps2ip.c:377: warning: implicit declaration of function `free_msg'
make[4]: *** [obj/ps2ip.o] Error 1
make[4]: Leaving directory `/root/ps2dev/toolchain/ps2sdk/iop/tcpip/tcpip'
make[3]: *** [all-tcpip] Error 2
make[3]: Leaving directory `/root/ps2dev/toolchain/ps2sdk/iop/tcpip'
make[2]: *** [all-tcpip] Error 2
make[2]: Leaving directory `/root/ps2dev/toolchain/ps2sdk/iop'
make[1]: *** [all-iop] Error 2
make[1]: Leaving directory `/root/ps2dev/toolchain/ps2sdk'
make: *** [/usr/local/ps2dev/ps2sdk/ee/lib/libkernel.a] Error 2
Any idea?
P.S. If I should have rather opened a new topic for this help request please feel free to delete this.
Posted: Wed Jan 17, 2007 7:45 am
by EP
jbit wrote:I don't like having mcInit(MC_TYPE_RESET) and padReset().
A) I'd prefer mcReset() and padReset() (since they seem to do similar, and keeping similar APIs is nice)
Sure, I doubt dlanor would mind.
jbit wrote:B) Shouldn't this happen in the End() functions anyway?
I guess it's useful to have these reset functions as well as End() functions. (In case it's not possible to call End before the reset, for example)
Yes, we experienced issues before with lockups. From what I remember, this was the only real way to allow a reset choice without breaking the functionality of the program. It has to be allowed to be cleared early.
jbit wrote:Is there any known reason why the hdd size was multiplied by 1024 and not 512?
I don't know. You'll have to ask radad about that one. I mentioned it to radad before and he said he thought it was right. However, I disagreed after doing some partition listings with ps2ftpd.
jbit wrote:I have no idea about the timezone stuff, I'll have to have a think about it when it's not 10:30am at night.
The timezone stuff was never fully implemented thus I commented out those lines in the mass, pfs, and hdd drivers since they were all giving different timestamps. It's rather strange to see the same file that was copied to 3 different sources have a different hour stamp. I prefer consistency over anything so I settled with PS2 Standard Tokyo time.:)
jbit wrote:Is there anything else? I believe you mentioned something about iomanX and the cdvd library.
Sure the iomanX, ps2ip, and tcpip lwip issues. It's kind of hard to explain. Currently we are using slightly older versions of some of the source files to get around our problems. The older lwip is still in the sdk so it was just a matter of linking. I'll try to get some things in order so I can better point out our issues with some of herbens sdk svn commits.
The issues we have experienced are not just with uLE. I think the ps2ip and lwip issues was what eventually sent EEUG on a tear to work on the his own network solution for SMS.;)
jbit wrote:Can you make sure to compare difference with the latest svn version (since that's what i'll be working against)
And i do prefer "unified" diff format (diff -u")
Sure, that's not a problem. At the moment, I keep all the current svn files that we've made changes to as renamed files like name(org). It makes it easier to do individual diffs between changes made to the ps2sdk sources.
Henk wrote:Are those the exact same changes as found in uLaunchELF v4.08\Source\Changed source for external projects\ps2sdk?
No it's not all of the changes. These are just ready to be submitted the other ps2sdk source changes have not been fully inspected.
Henk wrote:Any idea?
P.S. If I should have rather opened a new topic for this help request please feel free to delete this.
Not really. Yes, you may have been better off posting this in another thread.
Posted: Wed Jan 17, 2007 12:02 pm
by EP
Ok, here is the earlier stuff from before made with diff -ru between the current ps2sdk from svn and the ule one. Note: This does not include the changes to iomanX and tcpip. I left them out as they mostly just revert back to slightly older versions of the ps2sdk. I'm currently putting that other stuff together and will post about it later.:)
Code: Select all
diff -ru ps2sdksrc/ee/rpc/memorycard/include/libmc.h ps2sdksrcule/ee/rpc/memorycard/include/libmc.h
--- ps2sdksrc/ee/rpc/memorycard/include/libmc.h 2007-01-08 23:12:50.000000000 -0600
+++ ps2sdksrcule/ee/rpc/memorycard/include/libmc.h 2007-01-08 23:36:32.000000000 -0600
@@ -58,6 +58,10 @@
#define MC_ATTR_PDAEXEC 0x0800
#define MC_ATTR_PSX 0x1000
+// Additional valid bits for MC attributes, deduced by 'dlanor'
+#define MC_ATTR_FILE 0x0010 //Set for any file on MC
+#define MC_ATTR_OBJECT 0x0030 //Mask to find either folder or file
+
// function numbers returned by mcSync in the 'cmd' pointer
#define MC_FUNC_GET_INFO 0x01
#define MC_FUNC_OPEN 0x02
@@ -145,6 +149,11 @@
// values to send to mcInit() to use either mcserv or xmcserv
#define MC_TYPE_MC 0
#define MC_TYPE_XMC 1
+#define MC_TYPE_RESET 0xDEAD
+//RA NB: mcInit(MC_TYPE_RESET) after IOP Reset, to forget old modules
+//RA NB: This will not reinitialize anything for use of MC. To do that
+//RA NB: you will need to mcInit(MC_TYPEMC) or mcInit(MC_TYPEXMC),
+//RA NB: after having loaded modules to the IOP again.
// init memcard lib
@@ -278,11 +287,11 @@
// args: port number
// slot number
// filename to access
-// data to be changed
-// flags to show which data is valid
+// data to be changed //RA NB: This is an mcTable struct
+// flags to show which data is valid //0xFFFF works with valid mcTable structs
// returns: 0 = successful
// < 0 = error
-int mcSetFileInfo(int port, int slot, const char* name, const char* info, unsigned flags);
+int mcSetFileInfo(int port, int slot, const char* name, const mcTable* info, unsigned flags);
// delete file
// mcSync returns: 0 if deleted successfully
diff -ru ps2sdksrc/ee/rpc/memorycard/src/libmc.c ps2sdksrcule/ee/rpc/memorycard/src/libmc.c
--- ps2sdksrc/ee/rpc/memorycard/src/libmc.c 2005-11-14 14:31:04.000000000 -0600
+++ ps2sdksrcule/ee/rpc/memorycard/src/libmc.c 2006-02-09 17:42:22.000000000 -0600
@@ -226,6 +226,12 @@
{
int ret=0;
+ if (type == MC_TYPE_RESET)
+ { mclibInited = 0;
+ cdata.server = NULL;
+ return 0;
+ }
+
if(mclibInited)
return -1;
@@ -670,7 +676,7 @@
// flags to show which data is valid
// returns: 0 = successful
// < 0 = error
-int mcSetFileInfo(int port, int slot, const char* name, const char* info, unsigned flags)
+int mcSetFileInfo(int port, int slot, const char* name, const mcTable* info, unsigned flags)
{
int ret;
diff -ru ps2sdksrc/ee/rpc/pad/include/libpad.h ps2sdksrcule/ee/rpc/pad/include/libpad.h
--- ps2sdksrc/ee/rpc/pad/include/libpad.h 2005-11-14 14:31:04.000000000 -0600
+++ ps2sdksrcule/ee/rpc/pad/include/libpad.h 2005-11-14 15:03:08.000000000 -0600
@@ -127,6 +127,12 @@
*/
int padInit(int a);
+/* Since padEnd() further below doesn't work right, a pseudo function is needed
+ * to allow recovery after IOP reset. This function has nothing to do with the
+ * functions of the IOP modules. It merely resets variables for the EE routines.
+ */
+int padReset();
+
/*
* End all pad communication (not tested)
*/
diff -ru ps2sdksrc/ee/rpc/pad/src/libpad.c ps2sdksrcule/ee/rpc/pad/src/libpad.c
--- ps2sdksrc/ee/rpc/pad/src/libpad.c 2006-06-12 21:04:34.000000000 -0500
+++ ps2sdksrcule/ee/rpc/pad/src/libpad.c 2006-06-12 20:29:48.000000000 -0500
@@ -255,6 +255,19 @@
}
+/* Since padEnd() further below doesn't work right, a pseudo function is needed
+ * to allow recovery after IOP reset. This function has nothing to do with the
+ * functions of the IOP modules. It merely resets variables for the EE routines.
+ */
+int
+padReset()
+{
+ padInitialised = 0;
+ padsif[0].server = NULL;
+ padsif[1].server = NULL;
+ return 0;
+}
+
/*
* End all pad communication (not tested)
@@ -565,7 +578,7 @@
if(index == -1) {
return pdata->nrOfModes;
}
- else if (pdata->nrOfModes < index) {
+ else if (index < pdata->nrOfModes) {
return pdata->modeTable[index];
}
else {
diff -ru ps2sdksrc/ee/rpc/padx/include/libpad.h ps2sdksrcule/ee/rpc/padx/include/libpad.h
--- ps2sdksrc/ee/rpc/padx/include/libpad.h 2005-11-14 14:31:02.000000000 -0600
+++ ps2sdksrcule/ee/rpc/padx/include/libpad.h 2005-11-14 15:03:08.000000000 -0600
@@ -127,6 +127,12 @@
*/
int padInit(int a);
+/* Since padEnd() further below doesn't work right, a pseudo function is needed
+ * to allow recovery after IOP reset. This function has nothing to do with the
+ * functions of the IOP modules. It merely resets variables for the EE routines.
+ */
+int padReset();
+
/*
* End all pad communication (not tested)
*/
diff -ru ps2sdksrc/ee/rpc/padx/src/libpadx.c ps2sdksrcule/ee/rpc/padx/src/libpadx.c
--- ps2sdksrc/ee/rpc/padx/src/libpadx.c 2006-06-12 21:06:36.000000000 -0500
+++ ps2sdksrcule/ee/rpc/padx/src/libpadx.c 2006-06-12 20:29:48.000000000 -0500
@@ -254,6 +254,20 @@
}
+/* Since padEnd() further below doesn't work right, a pseudo function is needed
+ * to allow recovery after IOP reset. This function has nothing to do with the
+ * functions of the IOP modules. It merely resets variables for the EE routines.
+ */
+int
+padReset()
+{
+ padInitialised = 0;
+ padsif[0].server = NULL;
+ padsif[1].server = NULL;
+ return 0;
+}
+
+
/*
* End all pad communication (not tested)
*/
@@ -563,7 +577,7 @@
if(index == -1) {
return pdata->nrOfModes;
}
- else if (pdata->nrOfModes < index) {
+ else if (index < pdata->nrOfModes) {
return pdata->modeTable[index];
}
else {
diff -ru ps2sdksrc/iop/hdd/apa/src/hdd_fio.c ps2sdksrcule/iop/hdd/apa/src/hdd_fio.c
--- ps2sdksrc/iop/hdd/apa/src/hdd_fio.c 2006-07-10 14:07:24.000000000 -0500
+++ ps2sdksrcule/iop/hdd/apa/src/hdd_fio.c 2006-07-10 14:14:36.000000000 -0500
@@ -360,12 +360,13 @@
void fioGetStatFiller(apa_cache *clink, iox_stat_t *stat)
{
apa_header *header;
+ u64 size;
stat->mode=clink->header->type;
stat->attr=clink->header->flags;
stat->hisize=0;
- u64 size = clink->header->length;
- size *= 1024;
+ size = clink->header->length;
+ size *= 512;
stat->size=size & 0xFFFFFFFF;
size >>= 32;
stat->hisize=size & 0xFFFFFFFF;
diff -ru ps2sdksrc/iop/hdd/apa/src/misc.c ps2sdksrcule/iop/hdd/apa/src/misc.c
--- ps2sdksrc/iop/hdd/apa/src/misc.c 2005-11-14 14:29:18.000000000 -0600
+++ ps2sdksrcule/iop/hdd/apa/src/misc.c 2006-03-26 21:51:40.000000000 -0600
@@ -43,7 +43,7 @@
timeBuf.min=(((tmp<<2)+tmp)<<1)+(cdtime.minute&0x0F);
tmp=cdtime.hour>>4;
timeBuf.hour=(((tmp<<2)+tmp)<<1)+(cdtime.hour&0x0F);
- timeBuf.hour = (timeBuf.hour + 4) % 24; // TEMP FIX (need to deal with timezones?)
+ //timeBuf.hour = (timeBuf.hour + 4) % 24; // TEMP FIX (need to deal with timezones?)
tmp=cdtime.day>>4;
timeBuf.day=(((tmp<<2)+tmp)<<1)+(cdtime.day&0x0F);
tmp=cdtime.month>>4;
@@ -66,9 +66,6 @@
int err=0;
memset(idbuf, 0, 32);
- if(CdReadIlinkID(idbuf, &err))
- if(err==0)
- return 0;
- dprintf1("ps2hdd: Error: cannot get ilink id\n");
- return -EIO;
+ CdReadIlinkID(idbuf, &err);
+ return 0;
}
diff -ru ps2sdksrc/iop/hdd/pfs/src/misc.c ps2sdksrcule/iop/hdd/pfs/src/misc.c
--- ps2sdksrc/iop/hdd/pfs/src/misc.c 2005-11-14 14:29:40.000000000 -0600
+++ ps2sdksrcule/iop/hdd/pfs/src/misc.c 2005-10-21 15:26:22.000000000 -0500
@@ -44,7 +44,7 @@
timeBuf.min=(((tmp<<2)+tmp)<<1)+(cdtime.minute&0x0F);
tmp=cdtime.hour>>4;
timeBuf.hour=(((tmp<<2)+tmp)<<1)+(cdtime.hour&0x0F);
- timeBuf.hour = (timeBuf.hour + 4) % 24; // TEMP FIX (need to deal with timezones?)
+ //timeBuf.hour = (timeBuf.hour + 4) % 24; // TEMP FIX (need to deal with timezones?)
tmp=cdtime.day>>4;
timeBuf.day=(((tmp<<2)+tmp)<<1)+(cdtime.day&0x0F);
tmp=cdtime.month>>4;
Posted: Wed Jan 17, 2007 12:42 pm
by jbit
Okay, most of the fixes are in SVN.
I didn't do a couple for following reasons:
Code: Select all
- if(CdReadIlinkID(idbuf, &err))
- if(err==0)
- return 0;
- dprintf1("ps2hdd: Error: cannot get ilink id\n");
- return -EIO;
+ CdReadIlinkID(idbuf, &err);
+ return 0;
I would like a reason why This should return success when ReadILinkID has failed...
Code: Select all
- u64 size = clink->header->length;
- size *= 1024;
+ size = clink->header->length;
+ size *= 512;
Going to write some test code to see just WTF is going on (the fix looks sane, but I'm curious why it was 1024, and if it's 1024 anywhere else)
The mcInit(MC_RESET) thing isn't committed since i think mcReset() is a nicer solution.
Can you check the commit to make sure I haven't misread one of the patches or something. Thanks again for the fixes.
(Rant to EVERYBODY, not really to dlanor/EP)
In future can people please report these bugs! It's much nicer to have one working version of ps2sdk rather than 100 different versions with different fixes and different reverts.
If a new version of something breaks your code you should first check to see if you're relying on broken behavior, if so then change your code to work with the new stuff. If you're positive it's the new versions fault, post something on the forums or come to IRC and bitch at somebody with SVN write access!
ps2sdk is a community effort, any fix/features/etc will be considered (well, there are SOME restrictions of course, no points for guessing what). Nobody is going to kill you if you dispute a modification. Discussion about fixes and possible solutions is healthy.
Posted: Wed Jan 17, 2007 2:52 pm
by EP
jbit wrote:Okay, most of the fixes are in SVN.
No problem. We've held onto those changes for quite some time. We also have a whole lot more.:)
jbit wrote:I would like a reason why This should return success when ReadILinkID has failed...
Me too but someone gave us the code changes quite sometime ago. It fixed the hdd modded slim PS2 issues with hdd based applications. I don't even have a slim PS2 but many say that it works with that particular change. Few PS2's even have an ILink port and we still haven't noticed any issues so we kept on using that change.
jbit wrote:The mcInit(MC_RESET) thing isn't committed since i think mcReset() is a nicer solution.
Ok, I'll try it out.
jbit wrote:Can you check the commit to make sure I haven't misread one of the patches or something. Thanks again for the fixes.
Everything is there except you forgot the changes to ps2sdksrc\ee\rpc\padx\include\libpad.h
jbit wrote:In future can people please report these bugs! It's much nicer to have one working version of ps2sdk rather than 100 different versions with different fixes and different reverts.
Part of the problem is many don't update regularly to use the current stuff. I still find it easier to work off the current stuff and mention errors here from time to time.
I'll be sure to post the issues we're having with the other stuff once I get my stuff in order.
Posted: Wed Jan 17, 2007 3:35 pm
by jbit
EP wrote:Everything is there except you forgot the changes to ps2sdksrc\ee\rpc\padx\include\libpad.h
Oops, I actually edited this file and just forgot to commit, it's there now, good catch :)
EP wrote:Part of the problem is many don't update regularly to use the current stuff. I still find it easier to work off the current stuff and mention errors here from time to time.
Well I totally understand the need to include a "working" or "custom" version of ps2sdk in some things (I personally just tell people to use the latest SVN, this isn't always the best solution).
But the problems people may be having with ps2sdk should defiantly be be brought up here, and the fixes should defiantly make their way back into the main SVN tree.
(Which they're doing now :)
Hrm, the iLink thing kind of makes sense, since it'd presumably fail on certain variants of PS2 hardware. I'd like to do a it a bit nicer though.
It seems that it's only used for sce security protected drives. so maybe we can just change hdd.c[unlockDrive()] to something like:
Code: Select all
int unlockDrive(u32 device)
{
u8 id[32];
if(getIlinkID(id)!=0)
printf("ps2hdd: Warning: Using zeros for drive unlock password!\n");
return atadSceUnlock(device, id);
}
Although really, the results of both fixes are the same, it's nice to output what's happening. I'll have a think about it in case anything rings alarm bells with me.
Posted: Thu Jan 18, 2007 12:46 am
by dlanor
@jbit & EP:
I see that you two have been quite busy here lately, and I agree with most of what you've said, but here are some things I'd still like to comment on.
jbit wrote:I don't like having mcInit(MC_TYPE_RESET) and padReset().
A) I'd prefer mcReset() and padReset() (since they seem to do similar, and keeping similar APIs is nice)
Either way suits me fine. Since these calls will not be passed on to the IOP module, a pure EE function for each makes more sense. The only reason I did it the other way for the memory card init is because I didn't want to add any new lib functions at that time. (This was much earlier than the pad patches.)
B) Shouldn't this happen in the End() functions anyway?
I'm not absolutely sure what 'End()' functions you mean. For the gamepad I guess it would be 'padEnd()', but for the memory card I can find no similar function.
Anyway, the padEnd() function is not equivalent to padReset() for two important reasons. One is that it leaves the old server pointers intact, though the content there will be garbage after an IOP reset, and the other (the biggie) is that its main work of zeroing the 'padInitialised' flag is conditional.
We need a function that will zero it properly at all times, regardless of any test conditions. However, as I stated earlier, we still have some problem with reinitializing the pad drivers after reloading modules, so this fix requires more research in any case.
Since the purpose of the padEnd() function may be considered the same as that of padReset(), an improved padEnd() could replace both those current functions, but its end result must at all times, regardless of any test conditions, be that the EE end of the pad driver goes back to pre-initialized state. Otherwise it may still remain impossible to reinitialize it after reloading new IOP modules after an IOP reset.
I guess it's useful to have these reset functions as well as End() functions. (In case it's not possible to call End before the reset, for example)
Another possible reason is if any existing software is using the current padEnd() function in some way incompatible with the changes we need.
For MC the need of a new function is not even debatable, as the current libs contain no code whatever to bring its EE libs back to a preinitialized state, and our method of doing that has proven to work perfectly in long-term testing. But I do agree with you that a new function to do the same work would be a better idea, as our present method gives a false impression of passing the call on to an IOP function, as the mcInit function would do that when used with other arguments.
So a new EE function like this could instead be added to "ee/rpc/memorycard/src/libmc.c" (with a prototype to libmc.h):
Code: Select all
void mcReset()
{
mclibInited = 0;
cdata.server = NULL;
}
It may not look like much, but it makes a world of difference to uLE and any other program that needs to use MC both before and after an IOP reset.
Best regards: dlanor
Posted: Thu Jan 18, 2007 3:50 am
by cdevine
Hey jbit :-)
I'm not sure you remember me, I used to hand around on #lfs a loong time ago (2003 I think?). Started recently doing some PSP development and saw you administer this forum, I guess it's a small world ^^
(btw I don't use LFS anymore, got lazy and reinstalled Debian ;-)
Posted: Thu Jan 18, 2007 6:34 am
by EP
Ok here are our other two ps2sdk issues:
1. Issues with lwip 1.1.1 that breaks ps2host and ps2ftpd. Dlanor and I had issues where ps2host would only show '/' entries instead of actual file/directories.
ps2ftpd broken example..
Code: Select all
Configuration Loaded successfully.
Setting Durent Directory to E:\cygwin\usr\local\ps2dev\ps2ftpd\bin\.
Executing Irx host:E:\cygwin\usr\local\ps2dev\ps2ftpd\bin\ps2ftpd.irx...
IOP cmd: 1 args
ps2ftpd: starting
ps2ftpd: Could not change socket options.
ps2ftpd: could not create server
loadmodule: id 32, ret 1
whereabouts ps2ip prior behavior broke:
1347 /trunk/ps2sdk/iop/tcpip/
1346 /trunk/ps2sdk/iop/tcpip/
If I'm missing something that needs changing in ps2ftpd or ps2host, please let me know. Anyway here is my workaround, which merely reverts functionality back the old tried and true lwip. The older lwip is currently still in the ps2sdk so after a few slight changes and you get the previous functionality back.
changed files include:
ps2sdksrc\iop\tcpip\tcpip\makefile
ps2sdksrc\iop\tcpip\tcpip\src\ps2ip.c
ps2sdksrc\iop\tcpip\tcpip\src\include\lwipopts.h
full diff:
Code: Select all
diff -ru ps2sdksrc/iop/tcpip/tcpip/Makefile ps2sdksrcule/iop/tcpip/tcpip/Makefile
--- ps2sdksrc/iop/tcpip/tcpip/Makefile 2006-08-15 01:34:42.000000000 -0500
+++ ps2sdksrcule/iop/tcpip/tcpip/Makefile 2006-09-05 23:25:14.000000000 -0500
@@ -6,7 +6,7 @@
# Licenced under Academic Free License version 2.0
# Review ps2sdk README & LICENSE files for further details.
#
-# $Id: Makefile 1347 2006-08-10 20:10:10Z Herben $
+# $Id: Makefile 1053 2005-04-27 01:13:00Z pixel $
IOP_OBJS_DIR = obj/
@@ -14,15 +14,13 @@
IOP_SRC_DIR = src/
IOP_INC_DIR = include/
-#PS2IP_DHCP=1
-
ifeq ($(DEBUG),1)
DEBUG_FLAGS = -DDEBUG -DLWIP_DEBUG
endif
-LWIP=$(PS2SDKSRC)/iop/tcpip/lwip-1.1.1
+LWIP=$(PS2SDKSRC)/iop/tcpip/lwip
-ps2ip_OBJECTS = ps2ip.o sys.o sys_arch.o exports.o imports.o inet.o mem.o netif.o pbuf.o stats.o tcp_in.o tcp_out.o udp.o memp.o tcp.o etharp.o raw.o
+ps2ip_OBJECTS = ps2ip.o sys.o sys_arch.o exports.o imports.o inet.o mem.o netif.o pbuf.o stats.o tcp_in.o tcp_out.o udp.o memp.o tcp.o etharp.o
ifdef PS2IP_DHCP
ps2ip_OBJECTS+= dhcp.o
@@ -119,9 +117,6 @@
obj/sys.o: $(LWIP)/src/core/sys.c
$(IOP_CC) $(IOP_CFLAGS) $< -o $@
-obj/raw.o: $(LWIP)/src/core/raw.c
- $(IOP_CC) $(IOP_CFLAGS) $< -o $@
-
obj/etharp.o: $(LWIP)/src/netif/etharp.c
$(IOP_CC) $(IOP_CFLAGS) $< -o $@
diff -ru ps2sdksrc/iop/tcpip/tcpip/src/include/lwipopts.h ps2sdksrcule/iop/tcpip/tcpip/src/include/lwipopts.h
--- ps2sdksrc/iop/tcpip/tcpip/src/include/lwipopts.h 2006-08-15 01:34:42.000000000 -0500
+++ ps2sdksrcule/iop/tcpip/tcpip/src/include/lwipopts.h 2006-09-05 23:25:14.000000000 -0500
@@ -163,6 +163,8 @@
#define RAW_STATS 1
#endif /*LWIP_STATS*/
+#define LWIP_PROVIDE_ERRNO
+
//Boman666: This define will force the TX-data to be splitted in an even number of TCP-segments. This will significantly increase
//the upload speed, atleast on my configuration (PC - WinXP).
#define PS2IP_EVEN_TCP_SEG
diff -ru ps2sdksrc/iop/tcpip/tcpip/src/ps2ip.c ps2sdksrcule/iop/tcpip/tcpip/src/ps2ip.c
--- ps2sdksrc/iop/tcpip/tcpip/src/ps2ip.c 2006-08-15 01:34:42.000000000 -0500
+++ ps2sdksrcule/iop/tcpip/tcpip/src/ps2ip.c 2006-09-18 22:32:50.000000000 -0500
@@ -289,7 +289,7 @@
//IP-packet. Update ARP table, obtain first queued packet.
- etharp_ip_input(pNetIF,pInput);
+ pARP=etharp_ip_input(pNetIF,pInput);
//Skip Ethernet header.
@@ -307,7 +307,7 @@
//ARP-packet. Pass pInput to ARP module, get ARP reply or ARP queued packet.
- etharp_arp_input(pNetIF,(struct eth_addr*)&pNetIF->hwaddr,pInput);
+ pARP=etharp_arp_input(pNetIF,(struct eth_addr*)&pNetIF->hwaddr,pInput);
//Send out the ARP reply or ARP queued packet.
Posted: Thu Jan 18, 2007 6:40 am
by EP
2. IomanX changes: Causes ps2ftpd to steal devices away from uLE when started with PS2Net. I have seen this with the USB mass. After launching PS2Net, uLE can no longer access the currently connected USB device. The device is stolen away and the next thing that needs to use the device is prevented from accessing it.
Something similar also occurs with ps2netfs where devices are locked out because another part of a program has stolen access to an IOMAN device. There once was shared access.
Anyway, I ended up reverting back to revison 1332 /trunk/ps2sdk/iop/system/iomanx/ to get around this issue with uLaunchELF.
changed files include:
ps2sdk\iop\system\iomanx\makefile
ps2sdk\iop\system\iomanx\src\exports.tab
ps2sdk\iop\system\iomanx\src\imports.lst
ps2sdk\iop\system\iomanx\src\iomanX.c
ps2sdk\iop\system\iomanx\src\irx_imports.h
Sorry, but I've never been able to get my head around this change. Maybe I'm still missing something about these changes to iomanX?
Posted: Thu Jan 18, 2007 9:33 am
by evilo
EP wrote:2. IomanX changes: Causes ps2ftpd to steal devices away from uLE when started with PS2Net. I have seen this with the USB mass. After launching PS2Net, uLE can no longer access the currently connected USB device. The device is stolen away and the next thing that needs to use the device is prevented from accessing it.
Something similar also occurs with ps2netfs where devices are locked out because another part of a program has stolen access to an IOMAN device. There once was shared access.
Anyway, I ended up reverting back to revison 1332 /trunk/ps2sdk/iop/system/iomanx/ to get around this issue with uLaunchELF.
changed files include:
ps2sdk\iop\system\iomanx\makefile
ps2sdk\iop\system\iomanx\src\exports.tab
ps2sdk\iop\system\iomanx\src\imports.lst
ps2sdk\iop\system\iomanx\src\iomanX.c
ps2sdk\iop\system\iomanx\src\irx_imports.h
Sorry, but I've never been able to get my head around this change. Maybe I'm still missing something about these changes to iomanX?
Maybe I'm wrong, but I'm quite sure Herben made something about this in a recent change...
revision 1353 :
http://svn.ps2dev.org/listing.php?repna ... =1353&sc=1
Fixed a bug in ioman_sbv.c which cased the first device entry to be missed when stealing the device list from ioman. The calculation didn't take into account the .sbss section for some reason which is 4 bytes long... Other projects such as ps2ftpd and iopmgr also need to have this fixed. Added stealing of ioman's file descriptors so that files which are open at the time that iomanX is loaded will still be accessable when stealing all ioman exports.
Added CpuSuspendIntr around the file and device entry allocation code to prevent race conditions.
Posted: Sat Jan 27, 2007 1:40 pm
by EP
evilo wrote:Maybe I'm wrong, but I'm quite sure Herben made something about this in a recent change...
Yes, it's herben's changes that we have issues with. I have worked around them by reverting back to prior behavior. From what I remember, it wasn't just a ps2ftpd thing either as I think ps2netfs suffers similar symptoms.
Posted: Mon Jan 29, 2007 12:46 pm
by Herben
ps2ftp and a couple other things(devfs.irx?) do some crappy hacks to get the device list. I imagine these probably got broken when I made changes iomanX, but I don't think reverting back to fix compatability with hacky code is a good idea. Personally, I would suggest that you change ps2ftpd to use the iomanx export GetDeviceList() rather than the hack that is used now.
Posted: Tue Jan 30, 2007 10:32 am
by EP
Herben wrote:ps2ftp and a couple other things(devfs.irx?) do some crappy hacks to get the device list. I imagine these probably got broken when I made changes iomanX, but I don't think reverting back to fix compatability with hacky code is a good idea. Personally, I would suggest that you change ps2ftpd to use the iomanx export GetDeviceList() rather than the hack that is used now.
Hum, never mind that. I just did a check and we apparently only have a problem with just usbhdfsd. It's not ps2netfs or ps2ftpd related as I disabled the loading of those two network modules and I still experience mass: in uLE as inaccessible after starting MISC/PS2Net. Still reverting back to prior iomanX behavior solves it. Looks like dlanor and I need to further investigate this issue with uLaunchELF.
Posted: Tue Jan 30, 2007 3:15 pm
by Herben
what exactly does "starting MISC/PS2Net" do? what modules get loaded/inited/etc? I'll try to help, if I can.
Posted: Tue Jan 30, 2007 3:31 pm
by Herben
tcpip-1.1.1(what you're refering to as "tcpip" in your uLE project...) uses lwip-1.1.1, not the old lwip. I made very few changes to tcpip to make "tcpip-1.1.1" other than linking it with lwip-1.1.1 instead of the old lwip. A "diff" isn't going to help in this situation as lwip-1.1.1 is quite different than the old one and iirc I didn't really make any changes to the official lwip-1.1.1 source.
If there're problems, it's likely due to my quick "port" of lwip-1.1.1 and lwip-1.1.1 needing more changes to work properly on PS2. I wouldn't suggest using it. It was more of an attempt to get things moving forward since the whole ps2ip thing seemed to be stagnating.
Posted: Tue Jan 30, 2007 4:47 pm
by EP
Herben wrote:what exactly does "starting MISC/PS2Net" do? what modules get loaded/inited/etc? I'll try to help, if I can.
It loads the following IOP modules: HDD modules, USB modules, ps2netfs, and ps2ftpd. Anyway, what I eventually found out was that by loading the HDD modules it would lock out the mass driver. All I did was use the uLaunchELF fileBrowser. After opening mass: and seeing the folders and the files, I then opened hdd0:. Then after going back to mass: I saw nothing there.
We have experienced strange things with the later changes to iomanX. Earlier we had thought it was network module related but that's just not the only case. The current version of uLaunchELF v4.09 uses the older iomanX so you won't see this issue there if you wanted to experience it firsthand.
Herben wrote:tcpip-1.1.1(what you're refering to as "tcpip" in your uLE project...) uses lwip-1.1.1, not the old lwip. I made very few changes to tcpip to make "tcpip-1.1.1" other than linking it with lwip-1.1.1 instead of the old lwip. A "diff" isn't going to help in this situation as lwip-1.1.1 is quite different than the old one and iirc I didn't really make any changes to the official lwip-1.1.1 source.
Yes, it was the linking I only changed. The diff is well useless since it doesn't really add anything. We don't even use that stuff anymore since we're currently using EEUG's network solution.;)
Herben wrote:If there're problems, it's likely due to my quick "port" of lwip-1.1.1 and lwip-1.1.1 needing more changes to work properly on PS2. I wouldn't suggest using it. It was more of an attempt to get things moving forward since the whole ps2ip thing seemed to be stagnating.
Ah, all right that's good to know. I saw that ps2link and ps2client were working fine but I wondered what broke for host:, ps2ftpd, and ps2netfs. Thanks for the clarification.:)
Posted: Fri Feb 02, 2007 10:58 am
by dlanor
Herben wrote:what exactly does "starting MISC/PS2Net" do? what modules get loaded/inited/etc? I'll try to help, if I can.
Like EP already said, it's not really the PS2Net driver as such that messed things up, and later experiments have shown that it was the loading of device drivers which caused "mass:" to go 'awol'. For the case of PS2Net it was the loading of the HDD drivers, but we also got the same result simply by browsing to "host:" or "hdd0:" in uLE, which also loads the corresponding driver (the first time that is). In either of those cases, we lost touch with "mass:", which from then on only showed an empty dir. And we also got the same effect if either of those drivers was started before "mass:". which then never became browsable for uLE at all.
The funniest thing about this is that even in this state, with "mass:" access completely lost for uLE, it was still possible to start PS2Net and use FlashFXP to browse "mass:" through the FTP server of uLE... This proved that the "mass:" driver itself was in fact alive and well, even when uLE was unable to browse it.
After checking out your new sources for iomanx, I decided that it had to be the more extensive patching of function pointers that caused this mess, so I recompiled with the line "#define FULL_IOMAN" commented out, and then recompiled uLE again, which appears to have cured our symptoms. With that uLE version I've not been able to trigger this "missing mass:" bug by any means whatever, so I think this is solved now.
Btw:
I'm not sure if we said so earlier, but in all these test cases the "mass:" driver was your "usbhdfsd", which is the default driver embedded into uLE.
Best regards: dlanor
Posted: Sat Feb 03, 2007 12:13 am
by Herben
yeah, I added the FULL_IOMAN define for this exact reason. However I don't consider the issue resolved yet, myself. ;)
I'll try to come up with some possible causes and solutions, if I think of anything I'll post again in this thread to let you know.
Posted: Sat Feb 03, 2007 12:21 am
by Herben
do you use fileXio_rpc or the fioXXX functions?
Posted: Sat Feb 03, 2007 2:32 am
by dlanor
Herben wrote:do you use fileXio_rpc or the fioXXX functions?
We use both, depending on the device to be accessed. So for HDD and PFS we use 'fileXioXxxx' and for most everything else we use 'fioXxxx'. The main launchelf header file likewise refers both to "<fileio.h>" and "<fileXio_rpc.h>".
Best regards: dlanor
Posted: Sat Feb 03, 2007 8:08 am
by Herben
ok, I think I see where this is going now. I'm not exactly sure of the cause but I have some ideas to try out, will see what I can dig up this weekend.
is there any reason you use both? There should be no reason to use the fioXXX functions at all, regardless of the device. iomanX is designed to be an extender for ioman and fileXio is a working replacement for fioXXX RPC and uses iomanX. If you're running iomanX and fileXio anyway you might as well use it for everything since the fioXXX functions are crap.
Regardless, it should still work with both so I'll see what I can see and let you know what I find.
Posted: Sat Feb 03, 2007 9:36 am
by evilo
about crappy fioxxxx functions, what about replacing them by their filXio equivalent in the SDK ?
Posted: Sat Feb 03, 2007 9:54 am
by Herben
well, I don't think that would be appropriate. the fioXXX functions are RPC client functions for the rom0:FILEIO RPC server. It makes sense that people may want to not include iomanx.irx, filexio.irx, link with fileXio_rpc.a, etc in their program and just use the crappy fioXXX RPC stuff.
I do think it would make sense to add more helper functions though, like those macros I sent you. That would make it easier for people to transition from fioXXX to fileXio.
Posted: Sat Feb 03, 2007 12:16 pm
by dlanor
Herben wrote:ok, I think I see where this is going now. I'm not exactly sure of the cause but I have some ideas to try out, will see what I can dig up this weekend.
Good. I hope it works out. While our current modification works for us, we always prefer PS2SDK to be improved so we can use those libs without any patches for uLE.
is there any reason you use both?
No specific reason, except that many of the underlying device drivers were developed for one module or the other. It makes little sense for me to use fileXio functions with an underlying driver that doesn't support much of the fileXio function repertoire, and which ignores several of the extended arguments of that function set.
There should be no reason to use the fioXXX functions at all, regardless of the device.
Perhaps not in our program, but what about other programs launched by uLE, and running without IOP reset ? Those will inherit the module environment of the launcher, so it is crucial that both fioXxx and fileXioXxx calls work normally, since we have no control over what functions those programs will use.
iomanX is designed to be an extender for ioman and fileXio is a working replacement for fioXXX RPC and uses iomanX. If you're running iomanX and fileXio anyway you might as well use it for everything since the fioXXX functions are crap.
We might do so for sure, but we can't say the same for launched programs.
As for the fioXxx functions being crap, I agree on some points, like the classic fioRemove/fioMkdir fallthrough bug. But apart from that they still reflect some real limitations inherent in several of the underlying drivers. Accessing those drivers through fileXioXxx functions is not going to add any missing features. (Like fileXioRename for memory cards etc...)
Regardless, it should still work with both so I'll see what I can see and let you know what I find.
Good. I look forward to your results.
Best regards: dlanor
Posted: Sat Feb 03, 2007 7:30 pm
by Herben
dlanor: please check your email, I sent you a new iomanX.irx to try.
Posted: Sat Feb 03, 2007 10:31 pm
by dlanor
Herben wrote:dlanor: please check your email, I sent you a new iomanX.irx to try.
Thanks. I've got that RAR now, and will proceed with my testing directly. So I'll be back here with a report ASAP.
Best regards: dlanor
Posted: Sat Feb 03, 2007 11:36 pm
by dlanor
@Herben:
I've now tested the new module you sent, but it still causes the same errors for mass: as we had before, and I also noticed some weird errors for host: as well.
Like I said, the mass: errors are exactly as before, including the ability of the FTP server to access mass: properly as seen through FlashFXP, even though uLE loses the ability to see anything in mass: whenever the HDD or HOST drivers have been loaded, regardless of whether that happens before or after loading the USB drivers.
The new error is that HOST now doesn't work right at all, regardless of other drivers loaded, although part of the error symptom is affected by those. There is normal network contact with the PC, and the use of elflist.txt does work, so in uLE I can see the top-level links to the folders indicated by that file (on the PC). But when I browse to any of those folders I get a really weird symptom that varies with other modules/drivers loaded (I'm still a bit vague as to causes here).
In the resulting folder listing I see that some size values are correct, matching what that PC folder contains, but all the names are completely wrong, though differently depending on whether or not the mass: driver has been loaded yet. If it has, then all the names in the listing are such that really belong in the root directory of the USB drive, but if the mass: driver is not loaded yet, then all names in the listing are shown as "/".
It's seems as if the filename part of the directory listing is coming from a different (older?) driver in the list, than the correctly listed filesize info from host:.
With mass: loaded immediately before host:, we get mass: filenames in the host: listing, and without it we get none, which might indicate that the preceding driver in the list was not directory based ?!?
I'm not sure if that symptom is worth any more 'digging' though, so I'll conclude my report here.
Best regards: dlanor