I might be breaking things..

Discuss the development of software, tools, libraries and anything else that helps make ps2dev happen.

Moderators: cheriff, Herben

Herben
Posts: 107
Joined: Sun Jan 25, 2004 10:25 am

I might be breaking things..

Post 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. ;)
Herben
Posts: 107
Joined: Sun Jan 25, 2004 10:25 am

Post 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..
cosmito
Posts: 307
Joined: Sun Mar 04, 2007 4:26 am
Location: Portugal
Contact:

Post by cosmito »

A IOP debug library would be very handy, indeed. Thanks.
ragnarok2040
Posts: 202
Joined: Wed Aug 09, 2006 1:00 am

Post 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
	$&#40;IOP_CC&#41; $&#40;IOP_CFLAGS&#41; $&#40;IOP_CPPFLAGS&#41; -c $< -o $@

obj/%.o&#58; src/%.cpp
	$&#40;IOP_CXX&#41; $&#40;IOP_CXXFLAGS&#41; $&#40;IOP_CPPFLAGS&#41; -c $< -o $@

obj/%.o&#58; src/%.S
	$&#40;IOP_CC&#41; $&#40;IOP_CPPFLAGS&#41; -c $< -o $@

obj/%.o&#58; src/%.s
	$&#40;IOP_AS&#41; $&#40;IOP_ASFLAGS&#41; -c $< -o $@

$&#40;IRX_TARGET&#41;&#58; $&#40;IRX_OBJS&#41; src/imports.lst src/irx_imports.h
	echo "#include \"irx_imports.h\"" > src/build-imports.c
	cat src/imports.lst >> src/build-imports.c
	$&#40;IOP_CC&#41; $&#40;IOP_CFLAGS&#41; $&#40;IOP_CPPFLAGS&#41; -c src/build-imports.c -o obj/imports.o
	rm -f src/build-imports.c
	$&#40;IOP_CC&#41; $&#40;IOP_LDFLAGS&#41; -miop -nostdlib -s -o bin/$&#40;IRX_TARGET&#41; $&#40;IRX_OBJS&#41; obj/imports.o

clean&#58;
	rm -f obj/*.o bin/$&#40;IRX_TARGET&#41;

rebuild&#58; clean all

include $&#40;PS2SDKSRC&#41;/Defs.make
Thanks for the updates and hope this helps :D.
cosmito
Posts: 307
Joined: Sun Mar 04, 2007 4:26 am
Location: Portugal
Contact:

Post 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.
misfire
Posts: 110
Joined: Mon Sep 06, 2004 7:53 am
Location: Germany

Post by misfire »

Yes, you actually broke the SDK. :)

Here's what I get when compiling r1642:

Code: Select all

make&#91;3&#93;&#58; Leaving directory `/tmp/ps2sdk/iop/debug/iopdebug'
make -C iop_sbusdbg
make&#91;3&#93;&#58; 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&#58;6&#58;22&#58; ps2_sbus.h&#58; No such file or directory
src/main.c&#58; In function `_iop_ex_handler'&#58;
src/main.c&#58;42&#58; warning&#58; implicit declaration of function `SBUS_check_intr'
make&#91;3&#93;&#58; *** &#91;obj/main.o&#93; Error 1
make&#91;3&#93;&#58; Leaving directory `/tmp/ps2sdk/iop/debug/iop_sbusdbg'
make&#91;2&#93;&#58; *** &#91;all-iop_sbusdbg&#93; Error 2
make&#91;2&#93;&#58; Leaving directory `/tmp/ps2sdk/iop/debug'
make&#91;1&#93;&#58; *** &#91;all-debug&#93; Error 2
make&#91;1&#93;&#58; Leaving directory `/tmp/ps2sdk/iop'
make&#58; *** &#91;all-iop&#93; Error 2
ragnarok2040
Posts: 202
Joined: Wed Aug 09, 2006 1:00 am

Post 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 $&#40;PS2SDKSRC&#41;/Defs.make

## IOP IRX
IRX_NAME = sbus
IOP_BIN = $&#40;IRX_NAME&#41;.irx
IOP_CPPFLAGS = -miop -O2 -G0 -I$&#40;PS2SDKSRC&#41;/common/include -I$&#40;PS2SDKSRC&#41;/iop/kernel/include -I./include -I./src -Wall -fno-builtin-printf -DIRX_NAME=$&#40;IRX_NAME&#41;
IOP_OBJS = ps2_sbus.o iop_sbus.o ps2_sif.o iop_sif2.o sif2cmd.o imports.o exports.o
IOP_OBJS &#58;= $&#40;IOP_OBJS&#58;%=iop_obj/%&#41;

## EE Library
EE_OBJS = ps2_sbus.o ee_sbus.o ps2_sif.o ee_sif2.o sif2cmd.o ee_low.o
EE_OBJS &#58;= $&#40;EE_OBJS&#58;%=obj/%&#41;
EE_LIB = libs/libsbus.a
EE_CFLAGS = -D_EE -O2 -G0 -fno-builtin-printf
EE_INC = -I. -I./include -I $&#40;PS2SDKSRC&#41;/common/include -I $&#40;PS2SDKSRC&#41;/ee/kernel/include

all&#58; $&#40;IOP_BIN&#41; $&#40;EE_LIB&#41;

iop_obj/%.o&#58; src/%.c
	$&#40;IOP_CC&#41; $&#40;IOP_CFLAGS&#41; $&#40;IOP_CPPFLAGS&#41; -c $< -o $@

iop_obj/%.o&#58; src/%.cpp
	$&#40;IOP_CXX&#41; $&#40;IOP_CXXFLAGS&#41; $&#40;IOP_CPPFLAGS&#41; -c $< -o $@

iop_obj/%.o&#58; src/%.S
	$&#40;IOP_CC&#41; $&#40;IOP_CPPFLAGS&#41; -c $< -o $@

iop_obj/%.o&#58; src/%.s
	$&#40;IOP_AS&#41; $&#40;IOP_ASFLAGS&#41; -c $< -o $@

$&#40;IOP_BIN&#41;&#58; $&#40;IOP_OBJS&#41; src/imports.lst src/irx_imports.h
	$&#40;IOP_CC&#41; $&#40;IOP_LDFLAGS&#41; -miop -nostdlib -s -o bin/$&#40;IOP_BIN&#41; $&#40;IOP_OBJS&#41;

iop_obj/%.o&#58; src/%.lst
	echo "#include \"irx_imports.h\"" > src/build-imports.c
	cat $< >> src/build-imports.c
	$&#40;IOP_CC&#41; $&#40;IOP_CFLAGS&#41; $&#40;IOP_CPPFLAGS&#41; -c src/build-imports.c -o $@
	rm -f src/build-imports.c

iop_obj/%.o&#58; src/%.tab
	$&#40;ECHO&#41; "#include \"irx.h\"" > src/build-exports.c
	cat $< >> src/build-exports.c
	$&#40;IOP_CC&#41; $&#40;IOP_CFLAGS&#41; $&#40;IOP_CPPFLAGS&#41; -Isrc -c src/build-exports.c -o $@
	rm -f src/build-exports.c

$&#40;EE_LIB&#41;&#58; $&#40;EE_OBJS&#41;
	$&#40;EE_AR&#41; rc $&#40;EE_LIB&#41; $&#40;EE_OBJS&#41;

clean&#58;
	rm -f obj/*.* iop_obj/*.* bin/*.* libs/*.*

obj/%.o&#58; src/%.c
	$&#40;EE_CC&#41; $&#40;EE_CFLAGS&#41; $&#40;EE_INC&#41; -c $< -o $@

obj/%.o&#58; src/%.S
	$&#40;EE_CC&#41; $&#40;EE_CFLAGS&#41; $&#40;EE_INC&#41; -c $< -o $@

release&#58; all
	mkdir -p $&#40;PS2SDK&#41;/ee/include
	cp -f bin/$&#40;IOP_BIN&#41; $&#40;PS2SDK&#41;/iop/irx
	cp -f $&#40;EE_LIB&#41; $&#40;PS2SDK&#41;/ee/lib
	cp -f include/*.h $&#40;PS2SDK&#41;/common/include
protomank
Posts: 59
Joined: Thu Dec 18, 2008 1:41 am
Location: Porto Alegre, RS, Brazil
Contact:

Post by protomank »

Strangely I'm getting the iop_sbusdbg, even checking source from SVN.
Was the commit reverted?
ragnarok2040
Posts: 202
Joined: Wed Aug 09, 2006 1:00 am

Post 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 :/.
protomank
Posts: 59
Joined: Thu Dec 18, 2008 1:41 am
Location: Porto Alegre, RS, Brazil
Contact:

Post 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?
ooPo
Site Admin
Posts: 2023
Joined: Sat Jan 17, 2004 9:56 am
Location: Canada
Contact:

Post 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. :)
protomank
Posts: 59
Joined: Thu Dec 18, 2008 1:41 am
Location: Porto Alegre, RS, Brazil
Contact:

Post 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"?
misfire
Posts: 110
Joined: Mon Sep 06, 2004 7:53 am
Location: Germany

Post by misfire »

I don't really understand why people commit patches to the SDK without actually testing if it breaks anything.
ragnarok2040
Posts: 202
Joined: Wed Aug 09, 2006 1:00 am

Post 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...
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post 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)
ragnarok2040
Posts: 202
Joined: Wed Aug 09, 2006 1:00 am

Post 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.
misfire
Posts: 110
Joined: Mon Sep 06, 2004 7:53 am
Location: Germany

Post by misfire »

You could also use Mercurial to commit locally and create patches: https://bitbucket.org/misfire/ps2sdk/
Herben
Posts: 107
Joined: Sun Jan 25, 2004 10:25 am

Post 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.
ragnarok2040
Posts: 202
Joined: Wed Aug 09, 2006 1:00 am

Post 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.
Herben
Posts: 107
Joined: Sun Jan 25, 2004 10:25 am

Post by Herben »

Submitted. Thanks again. :D
Herben
Posts: 107
Joined: Sun Jan 25, 2004 10:25 am

Post 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.
Herben
Posts: 107
Joined: Sun Jan 25, 2004 10:25 am

Post 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. :)
protomank
Posts: 59
Joined: Thu Dec 18, 2008 1:41 am
Location: Porto Alegre, RS, Brazil
Contact:

Post by protomank »

Nice. I'll try to compila the toolkit from zero to see if all problems were fixed, thanks.
protomank
Posts: 59
Joined: Thu Dec 18, 2008 1:41 am
Location: Porto Alegre, RS, Brazil
Contact:

Post 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 ;)
yoshi314
Posts: 36
Joined: Sat Jul 26, 2008 11:19 pm

Post by yoshi314 »

oh, i liked it broken - the thrill of hacking it into workable state ;-)

ok, it also works for me.
dlanor
Posts: 258
Joined: Thu Oct 28, 2004 6:28 pm
Location: Stockholm, Sweden

Post 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
Herben
Posts: 107
Joined: Sun Jan 25, 2004 10:25 am

Post 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.
dlanor
Posts: 258
Joined: Thu Oct 28, 2004 6:28 pm
Location: Stockholm, Sweden

Post 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
protomank
Posts: 59
Joined: Thu Dec 18, 2008 1:41 am
Location: Porto Alegre, RS, Brazil
Contact:

Post 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 :)
misfire
Posts: 110
Joined: Mon Sep 06, 2004 7:53 am
Location: Germany

Post by misfire »

Less complicated: do not touch syscall function names (or directly related functions), especially when they've been around for years.
Post Reply