^^^ which kernel are you using? the hermes v3 .ko file only works for the omap kernel. if you are using the omap kernel, the .ko file should be in the root folder (correct me if i'm wrong)
Thank you. I was using the power kernel and tried to uninstall it through the app manager and to my horror the phone went into a reboot loop. I had to reflash the phone.
Thank you. I was using the power kernel and tried to uninstall it through the app manager and to my horror the phone went into a reboot loop. I had to reflash the phone.
Does anybody knows where to get a .ko file that has PL3 and that the backup manager is enabled?
I want it thanks to this KaKaRoTo post :
Originally Posted by
Hi all,
I see a lot of people asking me some questions and I notice a lot of ignorance in the net about the different payload and the latest PL3 payload.
So I want to make things clear..
First of all, people should stop talking/requesting/using the hermes v3 payload, I don’t like his work, and the payload is not good, it might crash the system in some cases, it’s not written properly, and hermes doesn’t even seem to understand how git works.
Also, PL3 already includes (for some time now) all the good stuff from hermes, it already supports installing game updates, or running games without a disc, anything else that Hermes added is useless and dangerous.
Some might have seen my tweets about my new payload being released, and many are asking me what is the difference between my payload and what is already available.
PL3 doesn’t support syscall 36 anymore, for multiple reasons, first, it was bad code, it was mapping a path to a single hardcoded value (/dev_bdvd or /app_home or /dev_flash or whatever is hardcoded in the payload) which means that, since we (the PSGroove and PSFreedom developers) don’t want to support running backups, all the official payloads weren’t working with the backup manager without being patched first.
The syscall_35 I added in my payload is more generic though, it is the proper way of doing things.
You can map any path to another other new path, the prototype looks like this :
Code:
syscall_35 (char *old_path, char *new_path);
This means that the payload doesn’t need to have a hardcoded /dev_bdvd path in it, or have extra code for mapping /app_home to something else.. or having syscall 36 change both /dev_bdvd and /app_home breaking homebrew when using a discless mode with a backup manager.
You also don’t need a special payload to run the ‘firmware usb loader’.. It all just works because the choice of the path mapping is given to the homebrew applications themselves.
This means that the backup managers will just map /dev_bdvd to what they want and they will work by default on my payload, there will be no need for a patched version of the payload to make them work.
This however means that the backup managers that depend on syscall 36 will stop working.
For now Gaia Manager is the only backup manager available that is compatible with my payload. But I’m sure more will be ported to use syscall_35.
People need to understand that this new syscall_35 has to become the new standard, this is what all the payloads should use, nothing else, and this is what everyone should start using, not the old, crappy, backup-manager specific, PSJailbreak written, syscall_36.
We need to have some form of standardization for all these payloads, I’m tired of seeing about 100 different payloads floating on the internet, it doesn’t make sense.
I always believed in a single payload that works for everyone, and that’s why I created
...
so you can play games that are require above 3.41, with current pl3 file from kakarote , which only work with Gaia Manager latest RC9, which does not have that option and even tho using OMB 2.1 still didnt work with patch and that option because hermes v4 requires
