PS3 Compiling open-source PS3 toolchain nowadays (in 2020)

Devildwarf said:
ok narrowed down the problem, it seems to be cgcomp on MINGW64, i built a old version of psl1ght and it worked great but you cannot use the old version with the new files (i tried and it just corrupts every elf/self made), The latest version of CGCOMP gives segmentation faultView attachment 28285
If i run it without any input it doesnt do that but what is the point in the program if it can't take input/output ?
Cygwin doesn't have this problem, at first i thought it was a GCC error so i tried compiling the EXE on GCC 9.3.0 and same problem, so i went back further to GCC 7.5.0 and still there, the only versions that work are the version pre JULY 2020 (versions from June compile and work fine but corrupt ELF/SELF when combined with newer PSL1GHT files.
Click to expand...

try opening an issue in the ps3dev/PSL1GHT repo on Github. Original author shagkur has been working lately making changes and updates to the cgcomp tool. Maybe one of these changes have broken the build on mingw. I think he can help you out with this bug.
 
First of all, thanks to all the psl1ght sdk contributors who help keep this great project updated!

I finally took the time to compile the latest sdk (toolchain & libs) on cygwin.
After 22h of compilation on an old i7 3rd gen laptop & a handful of minor tweaks, the sdk is ready, including @bucanero 's ported libs for good measure. Thanks brother. ;-)
I just compiled prepNTFS & Iris successfully, next task is testing when I get home..

Does anyone know how to generate a ps3dev2 folder from the latest source btw?
I don't even know where those files originally came from...

For those maybe less savvy reading this thread, the ps3dev2 folder is that folder with just a few binaries used to compile Cobra 8.x or Mamba 8.x kernel payload projects.
 
Last edited:
bguerville said:
First of all, thanks to all the psl1ght sdk contributors who help keep this great project updated!

I finally took the time to compile the latest sdk (toolchain & libs) on cygwin.
After 22h of compilation on an old i7 3rd gen laptop & a handful of minor tweaks, the sdk is ready, including @bucanero 's ported libs for good measure. Thanks brother. ;-)
I just compiled prepNTFS & Irisman successfully, next task is testing when I get home..
Click to expand...

thanks for sharing your feedback on building the latest toolchain :encouragement:

recently I was re-building it in macOS with the latest Catalina/Xcode and I had to do some patches to gdb-7.5.1 .
Files to modify:
  • readline/rltty.c
  • readline/terminal.c
Add this line:
Code: 
#include <sys/ioctl.h>
 
While I managed to compile an old Iris, I seem to have a problem linking the latest Irisman.

I had to edit the Makefile for the libspu_modulesound library files.
The default path & name of the library has changed compared to the PS3SDKv2 version.

Also the 3.xx payloads give the PIC error with clobbered r2. I just removed them temporarily.

The entire project compiled fine after that but linking errors out. Not sure why yet.
 
bguerville said:
While I managed to compile an old Iris, I seem to have a problem linking the latest Irisman.

I had to edit the Makefile for the libspu_modulesound library files.
The default path & name of the library has changed compared to the PS3SDKv2 version.

Also the 3.xx payloads give the PIC error with clobbered r2. I just removed them temporarily.

The entire project compiled fine after that but linking errors out. Not sure why yet.
Click to expand...

in @aldostools Irisman repository we fixed the gcc 7 compilation issue, here's the change:
https://github.com/aldostools/IRISMAN/commit/5807b33bd0004f4c47ac99c033b0b6270121a2fe

we added a macro check and skip the r2 register stuff when you're using gcc 7+
 
bucanero said:
in @aldostools Irisman repository we fixed the gcc 7 compilation issue, here's the change:
https://github.com/aldostools/IRISMAN/commit/5807b33bd0004f4c47ac99c033b0b6270121a2fe

we added a macro check and skip the r2 register stuff when you're using gcc 7+
Click to expand...
Oh that's good.
However I just checked the Makefile & it uses the PS3SDKv2 path & name for spu_modulesound library & include.
Can you compile that repo without changes?

For compatibility reason, would it not be simpler to roll back to the PS3SDKv2 folder structure for this ported lib?

Unless I messed up that library installation somehow?
The library path I have now is
portlibs/modules/lib/libspu_modulesound.a
(whereas before in PS3SDKv2, it was
portlibs/modules/spu_modulesound.bin.a).
Is it the same in your setup?
 
Last edited:
bguerville said:
Oh that's good.
However I just checked the Makefile & it uses the PS3SDKv2 path & name for spu_modulesound library & include.
Can you compile that repo without changes?

For compatibility reason, would it not be simpler to roll back to the PS3SDKv2 folder structure for this ported lib?

Unless I messed up that library installation somehow?
The library path I have now is
portlibs/modules/lib/libspu_modulesound.a
(whereas before in PS3SDKv2, it was
portlibs/modules/spu_modulesound.bin.a).
Is it the same in your setup?
Click to expand...

oh, yes you're right, I think that wargio updated some installation paths on his ps3soundlib repository.
I didn't pay attention, but yes I do have both files , probably left over from older installations.

so I have an old portlibs/ppu/modules/spu_modulesound.bin.a , and the new under modules/lib/libspu_soundmodule.a

not sure if Cygwin supports it, but I guess the easy fix would be to create a link (or symlink) from the old spu_modulesound.bin.a to the new libspu_soundmodule.a , so any old repo should compile properly even with the new paths and libs.
 
IDK if this should be posted here, but it started happening after re-compiling the toolchain a couple months back.
When running:
Code: 
 make npdrm
I expect the output to be NAME.elf, NAME.fake.self, NAME.self and EBOOT.BIN, but what I get is everything except EBOOT.BIN.
In the console I get a segmentation fault for make:
Code: 
linking ... SMW-PS3.elf
CEX self ... SMW-PS3.self
ELF header size @ 40
8 program headers @ 40
26 section headers @ 590e18
deflated...processing segment 0 with rlen 4b27a4 len 199b0d offset 0...encrypted...
deflated...processing segment 1 with rlen 54978 len 16663 offset 4c0000...encrypted...
deflated...processing segment 2 with rlen 562c8 len 1ab0b offset 520000...encrypted...
deflated...processing segment 3 with rlen 105b2 len 44b4 offset 580000...encrypted...
processing segment 4 with rlen 0 len 0 offset 5905b2...encrypted...
processing segment 5 with rlen 0 len 0 offset 514978...encrypted...
processing segment 6 with rlen 0 len 0 offset 0...encrypted...
deflated...processing segment 7 with rlen 28 len 22 offset 4b277c...encrypted...
segments enumerated
built crypt data
file built
self written in memory
make: *** [Makefile:127: npdrm] Segmentation fault

It seems that it has no permission to read the SELF file, copy it and then rename the copy to EBOOT.BIN.
What could be the cause of this? I don't discard the possibility of a problem on my end so if there's anything that I need to change in my system (Ubuntu running under WSL2) I'm more than willing to try.
Thanks in advance!

Edit: Maybe there's something I need to change in SMW-PS3's makefile, specially on line 127, where npdrm option is defined:
Code: 
npdrm: $(BUILD)
@$(SELF_NPDRM) $(SCETOOL_FLAGS) --np-content-id=$(CONTENTID) --encrypt $(BUILDDIR)/$(basename $(notdir $(OUTPUT))).elf $(BUILDDIR)/../EBOOT.BIN
 
Assuming you have the latest ps3 toolchain (github.com/ps3dev/ps3toolchain), you can convert the .elf to EBOOT.BIN with the following command:

Code: 
/usr/local/ps3dev/bin/make_self_npdrm input.elf EBOOT.BIN <content_id>

btw, from the parameters, it looks like your Makefile is trying to use the scetool to convert the .elf to EBOOT, but the ps3toolchain does not include scetool. Of course you could add it/build it too. But make_self_npdrm is enough for the PSL1GHT toolchain

edit: your Makefile could be probably be fixed for psl1ght with

Code: 
npdrm: $(BUILD)
@$(SELF_NPDRM) $(BUILDDIR)/$(basename $(notdir $(OUTPUT))).elf $(BUILDDIR)/../EBOOT.BIN $(CONTENTID)
 
bucanero said:
Assuming you have the latest ps3 toolchain (github.com/ps3dev/ps3toolchain), you can convert the .elf to EBOOT.BIN with the following command:

Code: 
/usr/local/ps3dev/bin/make_self_npdrm input.elf EBOOT.BIN <content_id>

btw, from the parameters, it looks like your Makefile is trying to use the scetool to convert the .elf to EBOOT, but the ps3toolchain does not include scetool. Of course you could add it/build it too. But make_self_npdrm is enough for the PSL1GHT toolchain

edit: your Makefile could be probably be fixed for psl1ght with

Code: 
npdrm: $(BUILD)
@$(SELF_NPDRM) $(BUILDDIR)/$(basename $(notdir $(OUTPUT))).elf $(BUILDDIR)/../EBOOT.BIN $(CONTENTID)
Click to expand...
Thanks! I'll try ASAP. That makefile was like that from the beginning, using the old psl1ght docker image it works, but with the latest toolchain it gives that error. The only changes I made to the makefile were the ones to build the all in one PKG and the fixed title. I guess I'll make a new branch to maintain the old makefile just in case as I'm still building with the docker image, as the executables still give black screen with the new toolchain.

Edit: It's working now, thanks :D
Edit 2: It also works on the old toolchain so there's no need to keep an older branch
 
Last edited:
blckbear_ said:
Edit: It's working now, thanks :D
Edit 2: It also works on the old toolchain so there's no need to keep an older branch
Click to expand...

good to know it worked fine! :encouragement:

if the build with the new toolchain fails to run on a PS3, I'd suggest to open an issue on Github on the ps3dev/PSL1GHT repository. I know they might not answer quickly, but you never know... perhaps they'll help to narrow the bug and fix the toolchain.

another test could be to run the binary on the ps3 emulator RPCS3 and see if it works there... I remember Crystal did those tests when trying to fix the tiny3d library build.
 
The binary works fine on RPCS3, but on console it gives two outcomes:
1. Black screen.
2. messed up main menu and the console crashes when any input is detected.

There have been a lot of updates to the toolchain since the last time that I compiled and ran the game on the console with the latest toolchain, do I'll give it a try again before opening an issue just to be sure
 
im trying to compile SDL2 using the repo at
https://github.com/bgK/sdl_psl1ght/tree/psl1ght-2.0.3
but i keep getting this error
Code: 
/root/Downloads/sdl_psl1ght-psl1ght-2.0.3/src/video/psl1ght/SDL_PSL1GHTvideo.c:151:31: error: too few arguments to function 'rsxInit'
     devdata->_CommandBuffer = rsxInit(0x10000, 1024*1024, host_addr);
                               ^~~~~~~
In file included from /root/Downloads/sdl_psl1ght-psl1ght-2.0.3/src/video/psl1ght/SDL_PSL1GHTvideo.h:29:0,
                 from /root/Downloads/sdl_psl1ght-psl1ght-2.0.3/src/video/psl1ght/SDL_PSL1GHTvideo.c:37:
/usr/local/ps3dev/ppu/include/rsx/rsx.h:106:5: note: declared here
 s32 rsxInit(gcmContextData **context,u32 cmdSize,u32 ioSize,const void *ioAddress);
     ^~~~~~~
make: *** [Makefile:513: build/SDL_PSL1GHTvideo.lo] Error 1
Any advice ? (i need this version for compiling scummvm/residualvm)
 
Devildwarf said:
im trying to compile SDL2 using the repo at
https://github.com/bgK/sdl_psl1ght/tree/psl1ght-2.0.3
but i keep getting this error
Code: 
/root/Downloads/sdl_psl1ght-psl1ght-2.0.3/src/video/psl1ght/SDL_PSL1GHTvideo.c:151:31: error: too few arguments to function 'rsxInit'
     devdata->_CommandBuffer = rsxInit(0x10000, 1024*1024, host_addr);
                               ^~~~~~~
In file included from /root/Downloads/sdl_psl1ght-psl1ght-2.0.3/src/video/psl1ght/SDL_PSL1GHTvideo.h:29:0,
                 from /root/Downloads/sdl_psl1ght-psl1ght-2.0.3/src/video/psl1ght/SDL_PSL1GHTvideo.c:37:
/usr/local/ps3dev/ppu/include/rsx/rsx.h:106:5: note: declared here
 s32 rsxInit(gcmContextData **context,u32 cmdSize,u32 ioSize,const void *ioAddress);
     ^~~~~~~
make: *** [Makefile:513: build/SDL_PSL1GHTvideo.lo] Error 1
Any advice ? (i need this version for compiling scummvm/residualvm)
Click to expand...
you need https://github.com/bgK/sdl_psl1ght/pull/2
explained in https://github.com/bgK/sdl_psl1ght/issues/1
 
Crystal said:
https://www.psx-place.com/threads/h...-in-asm-asm-volatile.29933/page-2#post-262480

Asked to @Omage a guide .......
Click to expand...

my step for msys64
1.
002-gcc-newlib-PPU.sh & 006-gcc-newlib-SPU.sh add --build=x86_64-pc-linux-gnu

2.
ps3toolchain\build\psl1ght\tools\geohot\Makefile add
ifneq (,$(findstring MSYS,$(UNAME)))
LDFLAGS += -s -lgmp -lcrypto -lz
POSTFIX := .exe
OS := win32
endif

ps3toolchain\build\psl1ght\tools\sprxlinker\Makefile add
ifneq (,$(findstring MSYS,$(UNAME)))
POSTFIX := .exe
LDFLAGS += -s -lelf
OS := win32
endif

3.
008-libvorbis-1.3.2.sh add
-lm
 
Omage said:
my step for msys64
1.
002-gcc-newlib-PPU.sh & 006-gcc-newlib-SPU.sh add --build=x86_64-pc-linux-gnu

2.
ps3toolchain\build\psl1ght\tools\geohot\Makefile add
ifneq (,$(findstring MSYS,$(UNAME)))
LDFLAGS += -s -lgmp -lcrypto -lz
POSTFIX := .exe
OS := win32
endif

ps3toolchain\build\psl1ght\tools\sprxlinker\Makefile add
ifneq (,$(findstring MSYS,$(UNAME)))
POSTFIX := .exe
LDFLAGS += -s -lelf
OS := win32
endif

3.
008-libvorbis-1.3.2.sh add
-lm
Click to expand...

I will test it as soon as possible....
 
JMGK said:
you can also try https://github.com/sergiou87/SDL2_PSL1GHT - with shagkur pull request

bgK port is 2.0.3, but sergious port is 2.0.13
Click to expand...
thanks for that, the 2.0.3 version kept breaking controllers in my builds of scummvm (meaning on ps3 i had no way of doing anything) but seems fixed with the 2.0.13 release, still black screens on the latest scummvm git builds but the official buildbot seems to do the same so i guess they broke something in the code.
 
I want to compile OpenBOR_PLUS with GCC7.2 ,but need libvpx.a
where can find libvpx src for ps3?
I find some scr build fail
thanks


build libvpx 1.7.0
CROSS=ppu- ../libvpx/configure --disable-multithread
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top