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

@Crystal @bucanero
Did you try to use cell sdk linker to build all the psl1ght libraries .a ?
cell/host-win32/ppu/bin/ppu-lv2-ld.exe instead of /ps3dev/ppu/bin/ppu-ld.exe

According to @zecoxao and @xerpi psl1ght homebrews are slow (expecially I/O from external) because of psl1ght linker
 
Zar said:
@Crystal @bucanero
Did you try to use cell sdk linker to build all the psl1ght libraries .a ?
cell/host-win32/ppu/bin/ppu-lv2-ld.exe instead of /ps3dev/ppu/bin/ppu-ld.exe

According to @zecoxao and @xerpi psl1ght homebrews are slow (expecially I/O from external) because of psl1ght linker
Click to expand...
I'm not using windows so I can only use the linker from the open source tool chain

but I think crystal uses windows so he might be able to check
 
I don't understand what's broken crt0.S need to be fixed/optimised to get a proper crt0.o ?

the file we install and use is lv2-crt0.o, it's made of crt0 and crt1 with a linker : @$(LD) -r crt0.o crt1.o -o lv2-crt0.o
maybe we need to swap the linker at this step ?
 
Crystal said:
@bucanero
Do you ever got a Z_DATA_ERROR tiring to start a SELF compiled with new PSL1GHT (gcc 7.2.0) ?
Click to expand...
Z_DATA_ERROR is a zlib error. It's caused by the compressed data format not being what zlib expects, or by corrupt data blocks.
Zlib checks the data integrity with adler32, sort of like crc32.

Assuming this is for an elf which has been converted to a self for running as an app on the ps3, the simplest way to check is to not compress the elf sections when you make the self. Also, appldr uses version 1.2.3 of zlib. I've not heard of any version difference causing errors, but you might want to use that version to compress the self. Finally, a few self tools use a higher compression ratio than the default for official game selfs. Theoretically, this could be checked by the ps3, but I doubt that such a check has been added.
 
Zar said:
I don't understand what's broken crt0.S need to be fixed/optimised to get a proper crt0.o ?

the file we install and use is lv2-crt0.o, it's made of crt0 and crt1 with a linker : @$(LD) -r crt0.o crt1.o -o lv2-crt0.o
maybe we need to swap the linker at this step ?
Click to expand...
I remember looking quickly at this last year, I saw nothing at all to optimise in the crt0/crt1 code itself to get faster storage reads either, the ppc and the c code didn't look to me like an obvious culprit, as far as I could make out anyway.
I wondered at the time if the perf issue could be caused by the librt functions that crt links to rather than the crt code itself.
But I don't remember seeing much there to be optimised either, the file functions are only wrappers to syscalls iirc without much added code around the syscall..
 
Last edited:
I tried few stuff today, long story short : still nothing.


I rebuilt the psl1ght libs (.a files) with the official linkers (I remplaced the linkers from cell to ps3dev directory) and then I built a simple lv2 dumper : it didn't improve the speed.

I tried to link .o to .elf with official linker I added this in makefile with "LD = /c/cell/host-win32/sn/bin/ps3ppuld64.exe" = got errors, L0039: reference to undefined symbol

I tried like it's said in psdevwiki : https://www.psdevwiki.com/ps3/Talk:PSL1GHT by using the gcc with "LD = /c/cell/host-win32/ppu/bin/ppu-lv2-gcc.exe" it seems to redirect the task to ps3ppuld64 = got errors, L0039: reference to undefined symbol


report over :)
 
Last edited:
60fpshacksrock said:
Perhaps this explains why ScummVM loading games from USB is so slow.
Click to expand...
yeah probably, I'm not sure because it use use psl1ght v1.

I just noticed something weird. I was doing small app to dumpLV2 (to have small app to test the speed with stdio function in usb), the app wasn't working, it returned to xmb... I investigated and found out lv2peek -syscall #6- function was causing it. When I used the same EBOOT.BIN but as a self (the one generated by psl1ght) and then I launch it, it worked... The capabilities/controls flags are set on both.

I tried another syscall (buzzer) -syscall #392- and it worked on both...


Do you think psl1ght is building a broken EBOOT.BIN ?
 
Zar said:
yeah probably, I'm not sure because it use use psl1ght v1.

I just noticed something weird. I was doing small app to dumpLV2 (to have small app to test the speed with stdio function in usb), the app wasn't working, it returned to xmb... I investigated and found out lv2peek -syscall #6- function was causing it. When I used the same EBOOT.BIN but as a self (the one generated by psl1ght) and then I launch it, it worked... The capabilities/controls flags are set on both.

I tried another syscall (buzzer) -syscall #392- and it worked on both...


Do you think psl1ght is building a broken EBOOT.BIN ?
Click to expand...

I couldn't tell you. Though I recently installed a Linux VM to maybe start playing around with compiling game-related stuff.
 
I did they are the same ELF.

About your issue, i read it in your thread, try to add in the makefile :
SCETOOL_FLAGS += --self-ctrl-flags 4000000000000000000000000000000000000000000000000000000000000002
SCETOOL_FLAGS += --self-cap-flags 00000000000000000000000000000000000000000000007B0000000100000000

it gives you kind of "admin privilege"
 
I found the issue but I can't explain it :

"Broken code": it doesn't work on EBOOT.BIN but works as .self
Code: 
#define DUMPER_BUFFSIZE 0x10000   
    FILE* f=NULL;
    u64 i, j;

    f=fopen("/dev_hdd0/LV2_DUMP.BIN", "wb");
    if(f==NULL) return 0;
   
    u64 data[DUMPER_BUFFSIZE];
  
    for(i=0 ; i < 0x800000ULL; i+= 0x8 *  DUMPER_BUFFSIZE ) {
        //memset(data, 0, DUMPER_BUFFSIZE*8);
      
        for( j = 0; j < DUMPER_BUFFSIZE; j++) {
            data[j]=lv2peek(0x8000000000000000ULL + i+j*0x8);
        }
        fwrite(&data, sizeof(u64), DUMPER_BUFFSIZE, f);
    }
    fclose(f);

Working code : it works as EBOOT and .self
Code: 
    FILE* f=NULL;
    u64 i, j;
   
    f=fopen("/dev_hdd0/LV2_DUMP.BIN", "wb");
    if(f==NULL) return 0;
   
    u64 data;
   
    for(i=0 ; i < 0x800000ULL; i++ ) {
   
        data=lv2peek(0x8000000000000000ULL + i);
       
        fwrite(&data, sizeof(u64), 1, f);
    }
    fclose(f);
 
Last edited:
ok, I found out why, I didn't set the stacksize, the EBOOT.BIN didn't have any (maybe 1KB by default), so when I used "u64 data[DUMPER_BUFFSIZE]" I probably overloaded the memory. I added this
SYS_PROCESS_PARAM(1001, 0x100000) to make it work as EBOOT.BIN

And when I launched the self with exitspawn, the stack size was set at 1MB, so it worked.

sry, about the offtopic, it wasn't related to psl1ght at all :p
 
@Zar, are you sure io is causing the speed problem for your test code? lv2peek is a relatively slow way to dump lv2. copy_to_user is much faster.

Maybe also try using setvbuf() to use your own buffer to which you've already copied lv2, as the io buffer. While that only saves one copy step between memory locations, if by chance buffering is a factor in the problem with the io speed, it might help.

Here is the source code for dumping lv2 using copy_to_user. On my friend's 4.84 hen console it takes about 20 seconds to save lv2 to usb stick; on my 4.21 cfw console it takes about 15 or so seconds. It uses unused syscall 20 for copy_to_user. There are 3 addresses specific to firmware version: address for the syscall 20 entry in the syscall table which points the address of syscall 20 in the TOC, which I have placed just after the syscall table, and the address of copy_to_user which is entered in the "fake" TOC entry. setvbuf is commented out since I didn't need it.
 

Attachments

I think you don't have the slow speed issue because your app use fopen fwrite fclose only once, I didn't test my dump lv2 app yet but on my others homebrews (idpset, managunz), when I was using standart io (fopen fread fwrite fclose) it was very slow like few KB/s...

So, I avoided the std i/o func and instead i'm using lv2syscalls, when I copy a big file from internal to external now, I have around 8MB/s to 12MB/s and with multiman (which is using cellSDK) I have around 20MB/s

But your app gave me an idea, maybe I can use lv2 internal function with cobra syscall 15, it may be faster...
 
You must log in or register to reply here.

Similar threads

Back
Top