Page 1 of 2
I might be breaking things..
Posted: Wed Oct 14, 2009 5:14 am
by Herben
I'm in the process of adding a number of my changes to the ps2dev SVN. These are things that I've done over the last few years that I'm finally releasing. If I end up breaking something as a result, drop me a line and I'll fix it. ;)
Posted: Wed Oct 14, 2009 5:23 am
by Herben
So far I've added:
- Another EE debug library. Yes, we already have at least one of those in SVN.
- An IOP debug library.
- A SBUS library for both EE and IOP.
- An IOP SBUS debug library(uses IOP debug library and IOP sbus library to communicate with EE in order to debug IOP). This also contains a "TTY" file system and Kprintf which send output to EE via SBUS.
I have yet to add:
- An EE SBUS debug library. This is the EE side of the "IOP SBUS debug library".
- Changes I've made to ps2link which makes it use the new EE/IOP debug libraries.
- ??? I'll have to see what else I can dig out of my archives..
Posted: Wed Oct 14, 2009 7:14 am
by cosmito
A IOP debug library would be very handy, indeed. Thanks.
Posted: Thu Oct 15, 2009 1:22 am
by ragnarok2040
I'm not sure if you're done updating, but the iop_sbusdbg library isn't compiling.
kprintf_handler_func_t is undefined. It's on line 187 of sbus_tty.c.
The Makefile also uses PS2SDK instead of PS2SDKSRC and was missing some include directories when the variables were switched.
I changed it to this to fix the file not found errors.
Code: Select all
IRX_NAME = iop_sbusdbg
IRX_TARGET = $(IRX_NAME).irx
IOP_CPPFLAGS = -miop -O2 -G0 -I$(PS2SDKSRC)/iop/kernel/include -I$(PS2SDKSRC)/common/include -I$(PS2SDKSRC)/common/sbus/include -I$(PS2SDKSRC)/iop/debug/iopdebug/include -I./include -I./src -Wall -fno-builtin-printf -DIRX_NAME=$(IRX_NAME)
IRX_OBJS = main.o sbus_dbg_low.o sbus_tty.o sbus_dbg.o
IRX_OBJS := $(IRX_OBJS:%=obj/%)
all: $(IRX_TARGET)
obj/%.o: src/%.c
$(IOP_CC) $(IOP_CFLAGS) $(IOP_CPPFLAGS) -c $< -o $@
obj/%.o: src/%.cpp
$(IOP_CXX) $(IOP_CXXFLAGS) $(IOP_CPPFLAGS) -c $< -o $@
obj/%.o: src/%.S
$(IOP_CC) $(IOP_CPPFLAGS) -c $< -o $@
obj/%.o: src/%.s
$(IOP_AS) $(IOP_ASFLAGS) -c $< -o $@
$(IRX_TARGET): $(IRX_OBJS) src/imports.lst src/irx_imports.h
echo "#include \"irx_imports.h\"" > src/build-imports.c
cat src/imports.lst >> src/build-imports.c
$(IOP_CC) $(IOP_CFLAGS) $(IOP_CPPFLAGS) -c src/build-imports.c -o obj/imports.o
rm -f src/build-imports.c
$(IOP_CC) $(IOP_LDFLAGS) -miop -nostdlib -s -o bin/$(IRX_TARGET) $(IRX_OBJS) obj/imports.o
clean:
rm -f obj/*.o bin/$(IRX_TARGET)
rebuild: clean all
include $(PS2SDKSRC)/Defs.make
Thanks for the updates and hope this helps :D.
Posted: Thu Oct 15, 2009 9:07 am
by cosmito
ragnarok2040 wrote:The Makefile also uses PS2SDK instead of PS2SDKSRC and was missing some include directories when the variables were switched.
This issue is frequent at other projects... Maybe it would be good someone with admin rights to write some guidelines at the toolchain README.
Posted: Wed Oct 21, 2009 5:09 am
by misfire
Yes, you actually broke the SDK. :)
Here's what I get when compiling r1642:
Code: Select all
make[3]: Leaving directory `/tmp/ps2sdk/iop/debug/iopdebug'
make -C iop_sbusdbg
make[3]: Entering directory `/tmp/ps2sdk/iop/debug/iop_sbusdbg'
iop-gcc -miop -O2 -G0 -I/usr/local/ps2dev/ps2sdk/iop/include -I/usr/local/ps2dev/ps2sdk/common/include -I./include -I./src -Wall -fno-builtin-printf -DIRX_NAME=iop_sbusdbg -c src/main.c -o obj/main.o
src/main.c:6:22: ps2_sbus.h: No such file or directory
src/main.c: In function `_iop_ex_handler':
src/main.c:42: warning: implicit declaration of function `SBUS_check_intr'
make[3]: *** [obj/main.o] Error 1
make[3]: Leaving directory `/tmp/ps2sdk/iop/debug/iop_sbusdbg'
make[2]: *** [all-iop_sbusdbg] Error 2
make[2]: Leaving directory `/tmp/ps2sdk/iop/debug'
make[1]: *** [all-debug] Error 2
make[1]: Leaving directory `/tmp/ps2sdk/iop'
make: *** [all-iop] Error 2
Posted: Wed Oct 21, 2009 11:49 pm
by ragnarok2040
I fixed the definition of the kprintf_handler_func_t by typedefining it to a char pointer, but then ran into the problem of I_iop_dbg_get_reg_frames not being defined in iopdebug. There's also another undefined type named IOP_RegFrame. I decided to remove iop_sbusdbg from the SUBDIRS variable in the toplevel Makefile. After that, ps2sdk compiled fine until common/sbus, where PS2SDK was used again. I corrected the Makefile by replacing PS2SDK with PS2SDKSRC and adding the missing include directories. And, after that, it compiled fine.
Code: Select all
include $(PS2SDKSRC)/Defs.make
## IOP IRX
IRX_NAME = sbus
IOP_BIN = $(IRX_NAME).irx
IOP_CPPFLAGS = -miop -O2 -G0 -I$(PS2SDKSRC)/common/include -I$(PS2SDKSRC)/iop/kernel/include -I./include -I./src -Wall -fno-builtin-printf -DIRX_NAME=$(IRX_NAME)
IOP_OBJS = ps2_sbus.o iop_sbus.o ps2_sif.o iop_sif2.o sif2cmd.o imports.o exports.o
IOP_OBJS := $(IOP_OBJS:%=iop_obj/%)
## EE Library
EE_OBJS = ps2_sbus.o ee_sbus.o ps2_sif.o ee_sif2.o sif2cmd.o ee_low.o
EE_OBJS := $(EE_OBJS:%=obj/%)
EE_LIB = libs/libsbus.a
EE_CFLAGS = -D_EE -O2 -G0 -fno-builtin-printf
EE_INC = -I. -I./include -I $(PS2SDKSRC)/common/include -I $(PS2SDKSRC)/ee/kernel/include
all: $(IOP_BIN) $(EE_LIB)
iop_obj/%.o: src/%.c
$(IOP_CC) $(IOP_CFLAGS) $(IOP_CPPFLAGS) -c $< -o $@
iop_obj/%.o: src/%.cpp
$(IOP_CXX) $(IOP_CXXFLAGS) $(IOP_CPPFLAGS) -c $< -o $@
iop_obj/%.o: src/%.S
$(IOP_CC) $(IOP_CPPFLAGS) -c $< -o $@
iop_obj/%.o: src/%.s
$(IOP_AS) $(IOP_ASFLAGS) -c $< -o $@
$(IOP_BIN): $(IOP_OBJS) src/imports.lst src/irx_imports.h
$(IOP_CC) $(IOP_LDFLAGS) -miop -nostdlib -s -o bin/$(IOP_BIN) $(IOP_OBJS)
iop_obj/%.o: src/%.lst
echo "#include \"irx_imports.h\"" > src/build-imports.c
cat $< >> src/build-imports.c
$(IOP_CC) $(IOP_CFLAGS) $(IOP_CPPFLAGS) -c src/build-imports.c -o $@
rm -f src/build-imports.c
iop_obj/%.o: src/%.tab
$(ECHO) "#include \"irx.h\"" > src/build-exports.c
cat $< >> src/build-exports.c
$(IOP_CC) $(IOP_CFLAGS) $(IOP_CPPFLAGS) -Isrc -c src/build-exports.c -o $@
rm -f src/build-exports.c
$(EE_LIB): $(EE_OBJS)
$(EE_AR) rc $(EE_LIB) $(EE_OBJS)
clean:
rm -f obj/*.* iop_obj/*.* bin/*.* libs/*.*
obj/%.o: src/%.c
$(EE_CC) $(EE_CFLAGS) $(EE_INC) -c $< -o $@
obj/%.o: src/%.S
$(EE_CC) $(EE_CFLAGS) $(EE_INC) -c $< -o $@
release: all
mkdir -p $(PS2SDK)/ee/include
cp -f bin/$(IOP_BIN) $(PS2SDK)/iop/irx
cp -f $(EE_LIB) $(PS2SDK)/ee/lib
cp -f include/*.h $(PS2SDK)/common/include
Posted: Mon Oct 26, 2009 7:52 am
by protomank
Strangely I'm getting the iop_sbusdbg, even checking source from SVN.
Was the commit reverted?
Posted: Mon Oct 26, 2009 8:05 am
by ragnarok2040
No fixes have been committed yet. I'm waiting to see if Herben has the corrections needed for iop_sbusdbg to compile, :D. Besides, I don't have commit access :/.
Posted: Mon Oct 26, 2009 8:09 am
by protomank
ragnarok2040 wrote:No fixes have been committed yet. I'm waiting to see if Herben has the corrections needed for iop_sbusdbg to compile, :D. Besides, I don't have commit access :/.
Thanks, and too bad. Most of the code in the SDL, such the Makefiles, is very-very old, and with few people having commit permission, things will not improve :-P
I had a doc with all this problems (and solutions for those) but lost it on a format (it could be on some backup, but I'm lazy to seach it) :D
Anyway, it is sad, that ater a year and a half the same problems are still in subversion! Maybe we must at least create a simple way for people send patches?
Posted: Mon Oct 26, 2009 8:26 am
by ooPo
If you want access, send a message to Oobles asking for it. Point out which thread has the fixes you want to add so he'll know you know what you're doing. :)
Posted: Wed Oct 28, 2009 4:08 am
by protomank
Well, I do not need access, maybe ragnarok does :)
Anyway, I'll test those fixes from him tomorrow, and if it does work, is it ok for me to post them in the "Patch Submissions"?
Posted: Wed Oct 28, 2009 5:06 am
by misfire
I don't really understand why people commit patches to the SDK without actually testing if it breaks anything.
Posted: Wed Oct 28, 2009 7:29 am
by ragnarok2040
I've tried for a couple years now, to no avail. I've just given up by now.
I've got some more information on that error.
I've found the definition for IOP_RegFrame in ps2_debug.h in the 'common' folder.
It looks like the only thing that isn't implemented is:
iop_dbg_get_reg_frames(&_iop_ex_def_frame, &_iop_ex_dbg_frame);
in iopdebug.
Looking at the code, it looks like it's some sort of function to copy the register frame. The iopdebug module seems to have functions related to doing that, and it looks like it was starting to be implemented, but is incomplete.
misfire, they probably do test, but there's a lot of pitfalls that can occur.
E.g. 'svn diff' patches don't neccessarily work out of the box. Files that are moved/deleted need to be handled directly using svn commands, prior to patching.
Reverting changes to a local repository doesn't revert all local changes, related to the problem above this one, so you can create a diff that works locally on a reverted repository but doesn't work on a freshly checked out repository...
Posted: Wed Oct 28, 2009 2:45 pm
by jimparis
ragnarok2040 wrote:I've tried for a couple years now, to no avail. I've just given up by now.
E.g. 'svn diff' patches don't neccessarily work out of the box. Files that are moved/deleted need to be handled directly using svn commands, prior to patching.
Reverting changes to a local repository doesn't revert all local changes, related to the problem above this one, so you can create a diff that works locally on a reverted repository but doesn't work on a freshly checked out repository...
Maybe it would make sense for you and someone with commit access (like me) to use git-svn to track the repository. Use "git format-patch" to make the diff, then I can apply it with "git am" and commit with "git-svn dcommit" etc. It should avoid these issues even though it's a bit of a pain.
(Getting commit access would be best, but unfortunately only a couple people can grant that)
Posted: Thu Oct 29, 2009 3:34 am
by ragnarok2040
I'll do that, then, :D. That would simplify things for both of us, since I have quite a few changes to ps2sdk coming up... quite a few :D.
Posted: Thu Oct 29, 2009 6:56 am
by misfire
You could also use Mercurial to commit locally and create patches:
https://bitbucket.org/misfire/ps2sdk/
Posted: Wed Nov 04, 2009 4:36 am
by Herben
sorry guys, tried to avoid breaking things where possible.
To answer your question misfire, I've been working on stuff privately(along with the public stuff I've done) for many years now and promising to release various things for most of that time. Some of these things weren't released because they were incomplete or required changes to PS2SDK to make them work. And some things haven't been touched for years so I'm simply not sure what I had to do to get them to work. I *do* try to test things as well as possible before I commit. Unfortunately the time I have for ps2dev is rather limited these days so I've been taking the position of simply releasing what I can when I can in order to make good on some old promises, and hopefully these things will help keep ps2dev alive for a while.
rag: Thanks for the feedback. I forgot to commit my changes to iop/kernel/include/sysmem.h which defines that type. Fixed now. I've also changed the Makefile to the one supplied. I really need to redo the makefiles for many of my projects.. This one in particular wasn't intended to be part of PS2SDK originally which is why it referenced the "release" PS2SDK. Many thanks. :)
regarding "iopdebug", I don't know for sure what state it was in when commited. All these things are part of a much bigger project which I'm splitting up into individual modules and I'm still working out what belongs where. Anyway, I've committed some changes to "iopdebug" which compiles fine for me so if you have problems, let me know and I'll fix it.
That should be the end of me breaking things for the time being. Currently my PS2-time is focused on my pslink project. I'm just about to post a thread on this, check it out!
Let me now if you guys have any other problems with my commits. I know that the sbus stuff isn't that useful without the EE side or some kind of example, promise to get that out soonish.
Posted: Wed Nov 04, 2009 5:41 am
by ragnarok2040
Thanks :D. I have a couple more fixes, and it should all be set.
The iop_sbusdbg Makefile isn't formatted right. The forum replaces tab characters with spaces, three spaces from what I saw, so it probably got mangled from that.
The common/sbus Makefile also had that PS2SDK/PS2SDKSRC problem. I also fixed up the header paths.
After that, it all compiled fine :D.
I made a svn diff patch that fixes both issues:
http://pastebin.com/m40daf98f
Copying and pasting the copy below the formatted version works fine. The formatted version converted the tabs into spaces, heh.
A note for those reading this wanting to submit diffs to pastebin:
I had to double the first two @@'s in @@ 0,0 @@ lines to @@@@ 0,0 @@, since pastebin uses @@ for highlighting. After it's posted, the two extra @@'s get eaten and you're left with the original patch. Empty newlines at the bottom get eaten as well, but it didn't seem to matter for my patch.
Posted: Wed Nov 04, 2009 9:21 am
by Herben
Submitted. Thanks again. :D
Posted: Wed Nov 04, 2009 10:17 am
by Herben
Just a quick note: I've cleaned up the makefiles/directories for "sbus" and "iop_sbusdbg" to bring them more in line with the rest of PS2SDK.
Posted: Wed Nov 04, 2009 10:19 am
by Herben
I've also checked in "lwip 1.3.1" and a fork of "tcpip" which uses it. I haven't had a chance to actually test it out though so if anyone can, that'd be cool. :)
Posted: Wed Nov 04, 2009 10:26 am
by protomank
Nice. I'll try to compila the toolkit from zero to see if all problems were fixed, thanks.
Posted: Wed Nov 04, 2009 8:04 pm
by protomank
Works like a charm.
Just 10 minutes and ps2client is installed as all the SDK.
Thank you, now developing for PS2 will be MUCH easier for a lot of people, me inclued ;)
Posted: Thu Nov 05, 2009 5:38 am
by yoshi314
oh, i liked it broken - the thrill of hacking it into workable state ;-)
ok, it also works for me.
Posted: Thu Nov 05, 2009 9:12 pm
by dlanor
I can confirm that the fixes for rev 1660 again allow the current PS2SDK to be used for the USBLoader project, except that three references to the GetSyscall function had to be edited to use the new name GetSyscallHandler instead.
I agree with the logic behind that rename (considering the other 'Handler' functions added), but it is changes like this that mess up the backwards compatibility to both current and older projects...
Best regards: dlanor
Posted: Fri Nov 06, 2009 7:42 am
by Herben
Thanks for the confirmations guys.
dlanor: Perhaps an "inline" function with the old name that just calls the new GetSyscallHandler is in order. Personally I think it makes more sense to simply update the projects in question.
Posted: Fri Nov 06, 2009 9:55 pm
by dlanor
Herben wrote:Thanks for the confirmations guys.
dlanor: Perhaps an "inline" function with the old name that just calls the new GetSyscallHandler is in order. Personally I think it makes more sense to simply update the projects in question.
I agree, and for a project this recent it is no big chore.
But for an older project, say something that the original author abandoned and someone else is trying to revive, the many renamed and otherwise modified PS2SDK functions can be a real problem. Sometimes the only practical thing to do is to just revert to an older PS2SDK revision, just to get things working at all, and that in turn requires some way to easily switch between different setups of PS2SDK (and other libs).
With Cygwin and linux it can easily be done by symlink redefinition, but I don't think that works for MinGW users, so they may have to resort to manual renaming of the real folders each time.
Still, I guess that's the price of progress...;)
Best regards: dlanor
Posted: Fri Nov 06, 2009 9:59 pm
by protomank
My take: place the old functions on a lib that can be linked to (and sure, document it for newbies in ps2 development) to maintain compatibility with old programs. This lib functions can even call the new ones if they are compatible.
New project will not use this lib, people working with old code can convert it with no rush and much more easily, because you can point in the compatibiliiy lib what is the new funcion, and how it differs from the original..
Just my 2 cents :)
Posted: Fri Nov 06, 2009 11:06 pm
by misfire
Less complicated: do not touch syscall function names (or directly related functions), especially when they've been around for years.