PS2 mini-OPL v1.0

Replacing OPNPS2LD by standard OPL (beta 1697) makes the same effect. Returning to browser. Launching this file alone from the same location is ok, and I also tried to launch Ico from game list and it works.

However, returning to browser is a standard behaviour if:
  • HDD OSD cannot find XLF,
  • XLF was found but wrongly signed (broken sign or sign for MC or DESR)
  • or XLF have wrong load memory address.

Maybe I should send You a small disk image, so You could blindly replacing XLF by hex editor and test it? But of course I can test new revisions, no problem. ^^ I'm also interesting in this feature. I don't know if this can be test on PCSX2 but last time I was reading about, emulator doesn't support any crypto stuff related to HDD and MC.
 
Maybe I can help, however need to solve the following:
  1. Is it mandatory for miniOPL to be a KELF (boot.kelf)?
  2. If above is true, does KELF have to be created from a headerless ELF?.
  3. What is the load address for aforementioned ELF and its maximum size?
 
1. Yes
2. No. This rule is for MBR (and PSX xfrom) binaries. The HDD OSD wants a valid ELF header.
3. Load address and entrypoint don't need to be fixed, that's a MBR / PSX nand thing.
No size restriction when running the KELF from PFS.
But in this specific case, when injecting a KELF into the PATINFO region of a HDL partition, it has to not overlap the HDL disc information area... So it depends on the icon sizes and stuff, and where the HDL stuff starts (cannot remember where). @akuhak 's hdl_dump installs a 3 076 096 bytes max KELF.

For compatibility with DEX units that support MG decryption, do not flag a DVD Player APP_TYPE. You can, for example, set it to 0.
For compatibility with the PSX, use a HDD DNAS loader header signature (you can get one from my XLFs), and flag the SYS_TYPE to PS2 (0).
 
@alexparrado Depend what we called "miniOPL". Executable written to APA (OPL-Launcher) must be XLF (or KELF if You prefer this naming convention, personally I follow by Sony naming where *.xlf is signed ELF and *.xin is __mbr signed ELF). Launched app (OPNPS2LD.ELF) of course not on standard retail units.
 
Thanks. @Krah, OPL loader should be linked to start from 0x90000 or you should embed an ELF loader, this last one is the safest way. I use first approach in OpenTuna and it works, but I think it could be dangerous if ELF goes beyond 0x100000 (ELF larger than 458752 bytes).
 
Last edited:
@Berion This one will work, I tested each element individually and had success.. only thing left to test is HDDOSD.. and of course I still haven't bothered to learn how to properly sign the elf/xlf/kelf so make sure to do that :) Thanks mate
 

Attachments

Still doesn't work. ^^"
When I launched game from HDD OSD, I see some debug colours (?) but to fast for me. Green and/or sea green.

Launcher itself looks fine as partition executable:
Code: 
  Magic:  7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:  ELF32
  Data:  2's complement, little endian
  Version:  1 (current)
  OS/ABI:  UNIX - System V
  ABI Version:  0
  Type:  EXEC (Executable file)
  Machine:  MIPS R3000
  Version:  0x1
  Entry point address:  0x100000
  Start of program headers:  52 (bytes into file)
  Start of section headers:  343448 (bytes into file)
  Flags:  0x20920021, noreorder, abi2, 5900, mips3
  Size of this header:  52 (bytes)
  Size of program headers:  32 (bytes)
  Number of program headers:  2
  Size of section headers:  40 (bytes)
  Number of section headers:  26
  Section header string table index: 25

Program Headers:
  Type  Offset  VirtAddr  PhysAddr  FileSiz MemSiz  Flg Align
  ABIFLAGS  0x01c968 0x0011c8e8 0x0011c8e8 0x00018 0x00018 R  0x8
  LOAD  0x000080 0x00100000 0x00100000 0x3e3a4 0x49904 RWE 0x80
 

Attachments

  • Like
Reactions: TnA
Those quick debug colours are the elf loader booting into OPL, if you have debug colours enabled in OPL cfg you would then see the normal OPL colours.. I wonder if I attached the correct OPL.. all my tests were with wLE and giving the launcher hard coded partition names to check for and then read.. all worked well.. So what happened after the colours? Kick back/ hang on black or OPL GUI?
 
After colours long black screen (~30s) then back to Browser with devices (HDD, MC's).

I don't remember to enable debug colours in my config. ;)
 

Attachments

Last edited:
Thanks. I'll try later in my environment.

Have You used "fmcb" or "mbr" switch?

I made my XLF by SCEDoormat R3 (because I know it works ;p). That's strange. Or maybe it doesn't from "hdd0:/__common/OPL/" but "hdd0:/+OPL/"?
 
I have checked Your file already and the same results. Green "flashbacks", black screen and returning to browser... I didn't have config for Ico, so I created (I thinking that maybe this could be an issue here but no :/). Second test, I moved common OPL content to +OPL and rename "hdd0:/__common/OPL/" to "OPL_new" (to be sure that OPL didn't find config on __common). In both cases, it returns to browser.

And of course I also have "OPNPS2LD.ELF" from latest R3 release in root of "hdd0:/+OPL/", as well as in earlier test in "hdd0:/__common/OPL/".

Could You check ICO (SCUS-97113)?
 
Tested with SCUS-97113 and it worked as well. After debug colors, game was properly launched. In your case, I'm not sure if launcher fails at finding OPNPS2LD.ELF or configuration file from older OPL is interfering.
 
Last edited:
Cannot interfere because I don't have two configs reachable at the same time. I have only "hdd0:/+OPL/" or only "hdd0:/__common/OPL/". Besides that, both are exactly the same with exception of conf_hdd of course.

I made myself "hdd0:/__common/OPL/conf_hdd.cfg" and it works (because OPL writing and seeking resources in there as I point in this file), so I don't see how this file could be not proper as You suggesting.

So... If setup is correct and launcher is ok, then something wrong could be with file access. HDL Dump put it in wrong address (not where Sony in docs tells, in my case it is 0x0090111000, while it should be 90110000 if I'm correct (2MiB later counting from partition start; and again if I'm not mistaken)) but in readme I read that this is intensional for larger files (putting it later? it doesn't make sense to me), and also jump address in APA looks ok to me.

This is f*g frustrating. :D

@alexparrado Could You add to libata (?) also kelf injection? Is this would be time consuming? So @El_isra could add to his uLE fork also "mass:/__Headers/<partition name>/boot.kelf" support. I would rather want to avoid jump address and size calculating by hand in hex editor as I'm not very good in math. ;p It would be another way to update APA.
 
Last edited:
Berion said:
I made myself "hdd0:/__common/OPL/conf_hdd.cfg" and it works (because OPL writing and seeking resources in there as I point in this file), so I don't see how this file could be not proper as You suggesting.
Click to expand...
The reason is more so related to the launcher, OPL can read it without issues because it uses the config system within OPL but the launcher just does a quick check for = to determine the value/partition then because I was being sloppy I didn't check
https://github.com/ps2homebrew/Open-PS2-Loader/blob/master/src/config.c#L550
To see what OPL appends to the string and instead checks for a bunch of different possibilities to change to a null terminator.

Anyway can you try allowing OPL create the file? It could be a Linux/windows line endings thing perhaps
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top