problems with latest toolchain / psplibraries builds
problems with latest toolchain / psplibraries builds
I recently decided to upgrade the sdl and the libraries on 2 of my computers. The installation of the toolchain and the libraries went ok on both cygwin and ubuntu boxes. I have recompiled a couple of sdl game ports and that went ok too, but the resulting executables wont run on psp. I don't see any errors in psplinkusb's pspsh and it just shuts the psp down if ran from memory stick.
The tests were done on the slim, and the same code seems to work if compiled with 5month old sdk build.
Does anyone have any clues as to what changed or experience similar problems?
The tests were done on the slim, and the same code seems to work if compiled with 5month old sdk build.
Does anyone have any clues as to what changed or experience similar problems?
I think I am having the same problem as you. I am currently using revision 2392. All the executables that I compiled with it cannot be executed on my SLIM, 390m33-3 PSP resulting the PSP to be shutdown within a few seconds of running it. Someone with an older revision of the SDK compiled the exact same copy and it ran on my PSP without the shutdown problem.
I'm having a possibly related problem, where psplink shuts down my 3.90M33-3 fat when I start usbhostfs_pc, as detailed here:
http://forums.ps2dev.org/viewtopic.php?t=10377
psplink compiled with an earlier sdk runs fine.
http://forums.ps2dev.org/viewtopic.php?t=10377
psplink compiled with an earlier sdk runs fine.
-
- Posts: 376
- Joined: Wed May 10, 2006 11:31 pm
-
- Posts: 376
- Joined: Wed May 10, 2006 11:31 pm
Did you update the entire toolchain to revision 2392 or just the SDK (ie. via ./toolchain.sh 6)?whistler wrote:i'm using revison 2392 and i don't have any problems with either the psptoolchain or sdl and the support libraries. all my executables compile and run on my psp slim
I did a full install of revision 2391 and that worked perfectly.
Revision 2392 seems broken.
I've commited a fix in revision 2393, I'm just running the toolchain script now to ensure it works.
i was originally on 2390. to update to 2392 i ran ./toolchain.sh 6 and reran ./libraries.shInsert_witty_name wrote:Did you update the entire toolchain to revision 2392 or just the SDK (ie. via ./toolchain.sh 6)?whistler wrote:i'm using revison 2392 and i don't have any problems with either the psptoolchain or sdl and the support libraries. all my executables compile and run on my psp slim
I did a full install of revision 2391 and that worked perfectly.
Revision 2392 seems broken.
I've commited a fix in revision 2393, I'm just running the toolchain script now to ensure it works.
btw i've just started a completely fresh installation of revision 2393, if i have any problems i'll post back here
-
- Posts: 376
- Joined: Wed May 10, 2006 11:31 pm
-
- Posts: 376
- Joined: Wed May 10, 2006 11:31 pm
-
- Posts: 376
- Joined: Wed May 10, 2006 11:31 pm
It work here too, but something have changed in the sony osk usage.
The default keyboard is always set to chinsee (or jap dunno). When i change the "language" param, only the "confirm exit" box is concerned by the setting.
Also i can't retrieve the input texte anymore :x
Does someone have a solution ?
The default keyboard is always set to chinsee (or jap dunno). When i change the "language" param, only the "confirm exit" box is concerned by the setting.
Also i can't retrieve the input texte anymore :x
Does someone have a solution ?
-
- Posts: 376
- Joined: Wed May 10, 2006 11:31 pm
revision check
<<<<edit: solved now, thanks>>>>>
sorry for the newbie question, but how do I check what SVN revision I built pspsdk/toolchain from? I am having this exact problem with 3.90 M33
Thanks!
sorry for the newbie question, but how do I check what SVN revision I built pspsdk/toolchain from? I am having this exact problem with 3.90 M33
Thanks!
-
- Posts: 376
- Joined: Wed May 10, 2006 11:31 pm
I have no idea what actually broke, but it was broken by the changes introduced in revision 2392.ooPo wrote:Uh, so what was the problem and what was the fix? :)
I didn't fix it as such, but reverted the toolchain.sh and binutils patch back to what they were in revision 2391.
Just for clarification Oopo, all I have to do to get the toolchain to compile on OSX is to change the last line of 001-binutils-2.16.1.sh from:
Code: Select all
make clean && make -j 2 && make install && make clean || { exit 1; }
Code: Select all
make clean && make -r -j 2 && make install && make clean || { exit 1; }
So it compiles, but does it run? :)
If that doesn't break anything then we can add it to all builds, otherwise a check would be fine. Can someone test building it on a non-OSX machine?-r, --no-builtin-rules
Eliminate use of the built-in implicit rules. Also clear out the default list of suffixes for suffix rules.
-
- Posts: 376
- Joined: Wed May 10, 2006 11:31 pm
While you're doing that, how about submitting something we've been talking about for a while, but never got around to - being able to set the heap size to the max minus a variable amount. The code change is to _sbrk in libcglue.c in newlib.
You change
to
PSP_HEAP_SIZE_MAX() is still the same, but you can now set the heap to be the max - x using PSP_HEAP_SIZE_KB(negative kb). For example,
sets the heap size to MAX - 1024 KB. Positive values work the same way as before. I've tested the code above, and it really works. In pspuae on my Slim, I get 38.53 MB free for -1024, and 37.50 MB free for -2048. Setting it to 20000, gives a smidgen over 13 MB free.
This change is great for programs designed to give maximum memory on both the Phat and Slim without having two different binaries. Just set "PSP_LARGE_MEMORY = 1" in the makefile, then use a negative value for the heap size. Note that this is for cases where MAX cannot be used - for example, in SDL or LTE where threads are used. Setting MAX prevents threads from being created, which was what got us to talking about this negative value in the first place.
You change
Code: Select all
if (heap_size == (unsigned int) -1) {
heap_size = sceKernelMaxFreeMemSize();
} else {
heap_size *= 1024;
}
Code: Select all
heap_size *= 1024;
if ((int)heap_size < 0)
heap_size += sceKernelMaxFreeMemSize();
Code: Select all
PSP_HEAP_SIZE_KB(-1024);
This change is great for programs designed to give maximum memory on both the Phat and Slim without having two different binaries. Just set "PSP_LARGE_MEMORY = 1" in the makefile, then use a negative value for the heap size. Note that this is for cases where MAX cannot be used - for example, in SDL or LTE where threads are used. Setting MAX prevents threads from being created, which was what got us to talking about this negative value in the first place.
Yeah, I thought about making it more complex to check for -1 specifically, but come on! 1K? I can't envision it ever being an issue. :)ooPo wrote:Easy enough to add that change, the only problem I can see is if someone uses the old method (-1), it'll give them 1K less than before the change.
If that's acceptable, I have the patch made and can commit it anytime.
On the other hand, if your program is so close on memory that 1 KB less on the heap makes it fail, you probably need to do some more work on it in any case. :D