Working on OPL ,is that still fun ?

User place app elf to harddisk .
Then they can launch them in OPL's APP page .
When one app is launched. I put my fake usbd/usbhdfs , fakeboot (to hook iop reboot)
to iop. I use the same code as OPL to block some irxes to be loaded.

In this way ,app can read/write ps2netbox 's hard disk.

 

So you are still using fakeboot? If the IOP cannot be reboot, then it is not very surprising if some software fail to work because LaunchELF loads its own modules (i.e. MCMAN) and not all software will use the same library versions as LaunchELF.

The IOP reset is meant to wipe the IOP of all kernel modules, so that the software can use the correct module versions.

 

I use udnl to reload module ,instead of reboot .

 

Then what does fakeboot do here?
If you use the fakeboot module's code to detect IOP reboot requests for changing the IOP reboot behaviour, then where do you store your IOP modules?

 

I store all irxes compressed into one irx

Code:

void handle_reboot(char *name ,int arglen,char*arg) 
{
  int i;
  int j;
  i=0;
  myp.arg[i]='i';i++;
  myp.arg[i]='m';i++;
  myp.arg[i]='g';i++;
  myp.arg[i]='0';i++;
  myp.arg[i]=':';i++;
  myp.arg[i]='\0';i++;

  for(j=0;j<arglen;j++,i++)
  {
    myp.arg[i] = arg[j]; 
  }
  myp.arg[i] ='\0';i++;
 
 
  printf("handle_reboot %s %d %s %d %s\n",name,arglen,arg,i,myp.arg);
  in_udnl_reset=1;
  load_start_compressed_module(ID_FAKEIMG,0,NULL);
  //load_start_compressed_module(ID_UDNL,5,"crap:");
  //int ret;
  load_start_compressed_module(ID_UDNL,i,myp.arg);
}

 

Okay, so what is inside this "fakeimg" image? In OPL, we generate an IOPRP image that contains only CDVDMAN, CDVDFSV and EESYNC. But you need to load other modules (i.e. modules for supporting the ps2netbox), instead of replacing those modules (CDVDMAN, CDVDFSV and EESYNC).

The IOPRP image should have a custom IOPBTCONF file (that lists the additional modules) and the additional modules. It should not replace CDVDMAN, CDVDFSV and EESYNC (unlike OPL).

If you replace CDVDFSV with something else that is not CDVDFSV, then any software that tries to bind with the CDVDFSV RPCs will hang. If you replace CDVDMAN with something else that is not CDVDMAN, then any software that attempts to check on the CD/DVD drive status will likely malfunction (some software, like SnesStation, originally used the CD/DVD drive).

 

fakeimg contain IOPRP IMG.
There are only one irx in it : EESYNC version number 0x9999.
I use EESYNC because I know EESYNC do nothing but set a flag to ee.
Before eesync set this flag,
It load irx for ps2netbox from it's data section ( irx storeed in compressed format) .

Code:

static int PostResetCallback(int *arg1, int arg2)
{
    printf("EESync PostResetCallback\n");
    load_start_module(ID_FUSBD,0,NULL);
    printf("start ID_FUSBD\n");

    load_start_compressed_module(ID_FUSBFSD,0,NULL);
    get_fusbfsd_exports();
    printf("start ID_FUSBFSD\n");
   
    // hook iop reboot 
    _start_fakeboot    ();
   
#ifdef FAKE_MC_USBD
    int _start_fake_mc() ;
    _start_fake_mc();
#endif   

    sceSifSetSMFlag(SIF_STAT_BOOTEND);
    printf("SIF_STAT_BOOTEND\n");
   
    return 0;
}

 

Okay, this part seems okay.
Honestly, I am impressed by how far you have gotten on your own, as this is quite a complicated topic. Congratulations!

Since replacing LaunchELF with a normal version can allow you to boot all software properly, after OPL boots this version of LaunchELF, so this probably means that your version of LaunchELF might be the cause. Have you tried compiling a clean copy (i.e. no modifications for ps2netbox) of LaunchELF, to test if you can build a working version of LaunchELF?

If you have tested and proven that you can build a version of LaunchELF that can be used, then it has to be related to the modifications that you made to LaunchELF. We can try to discuss the changes, to see if any of them could have caused boot problems in some apps.

Of course, the best way would be if you can debug the affected ELFs, since some of these old apps may be bugged or have some design problem (i.e. no IOP reset).

 

I do not test all these elfs.
I do not launch them use uLaunchELF . I launch them in OPL's app page.
I use OPL to launch uLaunchELF . Everything have worked , copy/delete virtual memory card.
I think IOP is not full reset in this method .

 

elf loader seems very simple:

Code:

    int start_addr ;
    int end_addr;
    ...
    // copy elf 
    // remember elf's  start_addr ,end_addr
    ...
    aend= (int)&_end;
    aend+=(int)&_stack_size;

    memset(aend,0,start_addr-aend)    ;
    memset((void*)end_addr,0,GetMemorySize()-end_addr)    ;
   
    SifExitRpc();
    SifInitRpc(0);
    while (!SifIopReset(NULL, 0)) {
        };

        FlushCache(0);
        FlushCache(2);

    while (!SifIopSync()) {
        };   
 
    SifInitRpc(0);
    SifExitRpc();
   
    argv[0] = filename;
    sio_putstr("\nLaunch:");
    sio_putstr(filename);
    sio_putstr(" ");
    sio_putint(entry);
    sio_putstr("\n...\n");
   
    ExecPS2((void *)entry, 0, 1, argv);

 

Oh, okay. Sorry, I thought you meant that you were booting software from LaunchELF.
Somehow I misread that part. No wonder...

So am I correct to say that the modified LaunchELF has no problem with booting any ELF, but booting the same ELFs from your modified OPL does not always work?

IOP rebooting is really just like that - it will discard the old modules and load new modules. The idea is hard to accept, I know. I once found it hard to believe, especially when I used to have a lot of problems with IOP resets.

Most issues that I had with IOP resets were caused by the SIF. The documentation does specify that SIFRPC should be initialized before the IOP reset (call SifInitRpc), but back then I did not have access to the documentation... and did not do that. So sometimes, the IOP would try to send some data over SIFCMD to the EE after (re-)boot, but the command receive buffer was not updated because I did not call SifInitRpc() (internally calls SifInitCmd)... so some undefined area in EE memory would get overwritten.

Oh wait, you wrote that you had a problem with getting SifLoadElf to work, didn't you? Can you describe how you are loading ELFs now?

Is this code that you put into OPL's EE core? Since _stack_size is defined as 0x2000, is &_stack_size the same as 0x2000?

There is also something you must know when working on the ELF Loader of OPL: when I made this, the linker file is defined like this:

Code:

/* Symbols needed by crt0.s. */
PROVIDE(_heap_size = -1);
PROVIDE(_stack = _end);
PROVIDE(_stack_size = 0x2000);

This means that the stack will exist at _end, for 0x2000 bytes.

However, please note the heap cannot be used because _stack exists at _end, while sbrk() is designed to assume that the heap begins after the end of the program.
Since _heap_size is < 0, the EE kernel sets up the end of heap to exist at _stack, so the heap size is 0 (since start of heap = end of heap).

So please do not use any code that uses the heap (i.e. malloc), within the ELF loader. This will probably result in a NULL-pointer getting allocated.
There is probably no need to use the heap though, so this is more of FYI.

How do you determine the ELF's start and end address? In the code for loading an ELF, we copy the program sections. However, a program may also have more than one section. So did you determine:

• The start address, based on the segment with the lowest address?
• The end address, based on end address of the highest segment?

Before you load the ELF (regardless of how), you should also wipe all memory before copying the ELF, to ensure that all regions of memory are wiped. Remember to flush the cache after that (unless you use the uncached segment, which will bypass the cache), before loading the ELF (especially if SIF DMA is used to transfer the program). If you do not do this, then it is possible that the EE will write back cache lines (which contain 0s) over the loaded ELF.

 

The modified LaunchELF work properly with files on fake mass. But I do not test launch app .
The unmodified LaunchELF work properly with files on fake mass when launched by OPL from APP page . But I do not test launch app also.
I will do some test today.

I load ELF by reading whole file into memory before execute loader.
The elf address is passed to loader as a parameter .

In elfloader . I print out ,aend,start_addr,end_addr and found they are ok . elfloader does not use any memory alloc function .

Code:

    int start_addr=GetMemorySize();
    int end_addr=0;
       
    for (i = 0; i < eh->phnum; i++) {
        if (eph[i].type != ELF_PT_LOAD)
            continue;

        pdata = (void *)(boot_elf + eph[i].offset);
        memcpy(eph[i].vaddr, pdata, eph[i].filesz);

        if (eph[i].memsz > eph[i].filesz){
            memset(eph[i].vaddr + eph[i].filesz, 0,
                   eph[i].memsz - eph[i].filesz);
        }
        if(start_addr>(int)(eph[i].vaddr)) 
            start_addr=(int)(eph[i].vaddr);
        if(end_addr<(int)(eph[i].vaddr)+eph[i].memsz)           
            end_addr=(int)(eph[i].vaddr)+eph[i].memsz;
    }

I wipe out all unused memory after loading elf , I think this is the same as yours method.

I will dump the memory to compare real data today.

Code:

int SifIopReset(const char *arg, int mode)
{
    struct _iop_reset_pkt reset_pkt;  /* Implicitly aligned. */
    struct t_SifDmaTransfer dmat;

    _iop_reboot_count++; // increment reboot counter to allow RPC clients to detect unbinding!

    SifStopDma();    //Stop DMA transfers across SIF0 (IOP -> EE).

    memset(&reset_pkt, 0, sizeof reset_pkt);

    reset_pkt.header.size = sizeof reset_pkt;
    reset_pkt.header.cid  = SIF_CMD_RESET_CMD;

    reset_pkt.mode = mode;
    if (arg != NULL) {
        strncpy(reset_pkt.arg, arg, RESET_ARG_MAX);
        reset_pkt.arg[RESET_ARG_MAX] = '\0';

        reset_pkt.arglen = strlen(reset_pkt.arg) + 1;
    }

    dmat.src  = &reset_pkt;
    dmat.dest = (void *)SifGetReg(SIF_SYSREG_SUBADDR);
    dmat.size = sizeof(reset_pkt);
    dmat.attr = SIF_DMA_ERT | SIF_DMA_INT_O;
    SifWriteBackDCache(&reset_pkt, sizeof(reset_pkt));

    SifSetReg(SIF_REG_SMFLAG, SIF_STAT_BOOTEND);

    if (!SifSetDma(&dmat, 1))
        return 0;

    SifSetReg(SIF_REG_SMFLAG, SIF_STAT_SIFINIT);
    SifSetReg(SIF_REG_SMFLAG, SIF_STAT_CMDINIT);
    SifSetReg(SIF_SYSREG_RPCINIT, 0);
    SifSetReg(SIF_SYSREG_SUBADDR, (int)NULL);

    return 1;
}

I think maybe there is bug around last four SifSetReg.
Things should be like , set one reg , waiting for response , and so on .

 

I see.

What happens if you use SifLoadElf? I know you got a workaround for this, but just in case it is a sign that there is something not right...

For example, if you can only use fileXioRead to read the file, then perhaps this is a sign that the driver cannot be accessed with the normal IOMAN.

Okay, that is good.

No, it is fine. SMFLAG is the Sub-CPU to Main-CPU flag register (implemented in hardware), which is used by the IOP to indicate its available services to the EE (IOP -> EE). The EE clears bits when it writes, while the IOP will set the bits of this register when it writes. Only the EE will read this register.

On the other hand, the EE uses MSFLAG (EE -> IOP) to indicate the same things to the IOP, but usually this does not change as much as SMFLAG because the EE does not reboot. Likewise, only the IOP will read this register.

SIF_SYSREG_RPCINIT and SIF_SYSREG_SUBADDR are not implemented in hardware, but are variables within the kernel. SIF_SYSREG_RPCINIT is used by the SIFRPC library to determine whether SIFRPC on the IOP was initialized by the EE side.
SIF_SYSREG_SUBADDR is used by SIFCMD to store the Sub-CPU's receive buffer (which SIFCMD will use to send SIFCMD packets into via DMA).

 

I get it . This a very good hardware design
Back to code :

Code:

1) if (!SifSetDma(&dmat, 1))       return 0;
2)     SifSetReg(SIF_REG_SMFLAG, SIF_STAT_SIFINIT);
3)     SifSetReg(SIF_REG_SMFLAG, SIF_STAT_CMDINIT);

line 1 , ee send reset packet to iop.
line2, ee clear SIFINIT bit , so (I think ) ee will check this bit , and reinit rpc
I think iop will set SIFINIT bit to signal ee init rpc .
line3, like line2.
If something happened between line1 and line2 . EE will miss SIFINIT flag from IOP .
I know nothing about ee/iop init procedure , this is based on how I design a system .


Our friend ,Algol , is waiting on me for new version .
I will debug today , and back this few days later .

 

SIFINIT is just to indicate that the SIFDMA transfers have been re-enabled by the IOP side. If I am not wrong, it is set by SIFINIT. There does not seem to be anything on the EE's libraries that checks for this bit, so only the part of the EE kernel that initializes SIF DMA will check for it (this is done when the kernel initializes).

The only part of the EE that will check for the CMDINIT part is in SIFCMD, when you reinitialize SIFCMD: https://github.com/ps2dev/ps2sdk/blob/master/ee/kernel/src/sifcmd.c#L280. These bits are used for synchronization (since it is not possible to initialize SIFCMD before the SIF is ready etc).
There is no way to remotely signal the other CPU to reinitialize the SIF/SIFCMD/SIFRPC.

Normally, nothing will access these registers, other than during initialization or IOP reboot.

 

Bonjour @sp193 et aussi @ps2netbox.

Vous êtres SUPER tous le deux et je vous apprécie énormément. Je souhaite très bientôt avoir un OPL spécial "PS2NetBox" parfait et tout autant un très bon uLE lui aussi "spécial" et débugué (debog). Vous me rappelez toute ma jeunesse quand vous parlez de programmation, je ne le faisais uniquement qu'en langage ASSEMBLEUR, très difficile mais très gratifiant, avec beaucoup de plaisir.

Bonne journée.

In Engrish via "Google Trad" :

Hello you.
You are both SUPER and I appreciate you a lot. I wish very soon to have a special OPL "PS2NetBox" perfect and just as much a very good uLE also "special" and debugged (debog). You remind me all my youth when you talk about programming, I did it only in ASSEMBLER language, very difficult but very rewarding, with a lot of fun.

Have a good day.

 

!!!

 

Hi ps2netbox,straight said as a player i very attentions if you become OPL developer,you may improve game compatibility in new versions?

 

well,seems ps2netbox only interested in his ps2netbox device...maybe his next OPL update will only for ps2netbox device become commercial not for normal users and named OPL ver ps2netbox...

 

I wound up getting hdl_dumb to work, nothing else would.