PS3 Fresh OFW install !!!!!
- Thread starter Rossco92
- Start date
-
- Tags
- ps3 help cfw
Coldheart2236
Moderator
Hello Rossco,
You would have to still install 4.89 as elements of the firmware are stored within the flash memory of the console, and it cannot be reversed. If it's a CFW compatible slim, in time it will be exploitable - all that's needed on this end is a bit of patience
You would have to still install 4.89 as elements of the firmware are stored within the flash memory of the console, and it cannot be reversed. If it's a CFW compatible slim, in time it will be exploitable - all that's needed on this end is a bit of patience
atreyu187
Loathsome Dung Eater
I have tried running a SSD and I would never do it again. Negligible increase in speed but it really starts to slow everything down if you add, switch or remove games from the drive. I have found SSHD to be the best without issues since the PS3OS can't properly handle SSD drives.
Hello Rossco,
You would have to still install 4.89 as elements of the firmware are stored within the flash memory of the console, and it cannot be reversed. If it's a CFW compatible slim, in time it will be exploitable - all that's needed on this end is a bit of patience
Thank you for your reply, HEN it is then
Berion
Developer
@atreyu187 Maybe Yours SSD was on QLC. Those are cheap but slow. Yet some users have issues with SSD like corrupting UFS2, while others not.
atreyu187
Loathsome Dung Eater
Definitely not the drive what it stemed from was removing and adding games to much fragmentation since the system can not properly handle SSD
Berion
Developer
Some can properly handle SSD. We don't know what causing the issues and what exactly are those issues.
Fragmentation is something which OS understand, not the SSD firmware. It completely doesn't matter. Also trim is not super needed if wear levelling control works as it should. So this must be something different I believe.
Fragmentation is something which OS understand, not the SSD firmware. It completely doesn't matter. Also trim is not super needed if wear levelling control works as it should. So this must be something different I believe.
I agree with that assessment.
It's very hard to work out a pattern, in my own experience with 4 or 5 SSDs, problems have been different with each of them, some problems were minor, others not so much. With some, issues would be obvious quickly in everyday use, with others only very specific features would be impacted and it could take a while before noticing but over the years, I basically gave up on using the SSDs I got for internal HDD, I just recycled them into external USB devices.
I think we have had this conversation before, those compatibility issues would need to be investigated properly, a number of them could probably be ironed out.
As to TRIM, it might be possible to implement it, maybe with a small patch at lv1/lv2 level to the ioctl function, so that the required parameters for TRIM don't error out, those 2 ioctls commands are needed.
Code:
#define DIOCGMEDIASIZE _IOR('d', 129, off_t) /* Get media size in bytes */
#define DIOCGDELETE _IOW('d', 136, off_t[2]) /* Delete data */The exact hex values can be calculated with this:
Code:
#define IOCPARM_SHIFT 13 /* number of bits for ioctl size */
#define IOCPARM_MASK ((1 << IOCPARM_SHIFT) - 1) /* parameter length mask */
#define IOCPARM_LEN(x) (((x) >> 16) & IOCPARM_MASK)
#define IOCBASECMD(x) ((x) & ~(IOCPARM_MASK << 16))
#define IOCGROUP(x) (((x) >> 8) & 0xff)
#define IOCPARM_MAX (1 << IOCPARM_SHIFT) /* max size of ioctl */
#define IOC_VOID 0x20000000UL /* no parameters */
#define IOC_OUT 0x40000000UL /* copy out parameters */
#define IOC_IN 0x80000000UL /* copy in parameters */
#define IOC_INOUT (IOC_IN|IOC_OUT)/* copy parameters in and out */
#define IOC_DIRMASK (IOC_VOID|IOC_OUT|IOC_IN)/* mask for IN/OUT/VOID */
#define _IOC(inout,group,num,len) ((unsigned long) \
((inout) | (((len) & IOCPARM_MASK) << 16) | ((group) << 8) | (num)))
#define _IOR(g,n,t) _IOC(IOC_OUT, (g), (n), sizeof(t))
#define _IOW(g,n,t) _IOC(IOC_IN, (g), (n), sizeof(t))Then, in theory, we might be able to use the existing ioctl syscall to call a TRIM or we could make it accessible through a dedicated syscall 8 sub code and maybe add a XMB item to launch the TRIM, we may need to do this on PS3 shutdown/reboot, we can always refer to the BSD implementation and documentation if need be.
This is all theoretical though, I dunno if it will work in practice with the lowest level driver. It's worth a quick try.
Here's a minimalistic trim/unmap function from FreeBSD trim c:
Code:
....
static off_t
getsize(const char *path)
{
struct stat sb;
off_t mediasize;
int fd;
fd = opendev(path, O_RDONLY | O_DIRECT);
if (fstat(fd, &sb) < 0)
err(EX_IOERR, "fstat failed: %s", path);
if (S_ISREG(sb.st_mode) || S_ISDIR(sb.st_mode)) {
close(fd);
return (sb.st_size);
}
if (!S_ISCHR(sb.st_mode) && !S_ISBLK(sb.st_mode))
errx(EX_DATAERR,
"invalid type of the file "
"(not regular, directory nor special device): %s",
path);
if (ioctl(fd, DIOCGMEDIASIZE, &mediasize) < 0)
err(EX_UNAVAILABLE,
"ioctl(DIOCGMEDIASIZE) failed, probably not a disk: "
"%s", path);
close(fd);
return (mediasize);
}
static int
trim(const char *path, off_t offset, off_t length, bool dryrun, bool verbose)
{
off_t arg[2];
int error, fd;
if (length == 0)
length = getsize(path);
if (verbose)
printf("trim %s offset %ju length %ju\n",
path, (uintmax_t)offset, (uintmax_t)length);
if (dryrun) {
printf("dry run: add -f to actually perform the operation\n");
return (0);
}
fd = opendev(path, O_RDWR | O_DIRECT);
arg[0] = offset;
arg[1] = length;
error = ioctl(fd, DIOCGDELETE, arg);
if (error < 0) {
if (errno == EOPNOTSUPP && verbose && !candelete(fd))
warnx("%s: TRIM/UNMAP not supported by driver", path);
else
warn("ioctl(DIOCGDELETE) failed: %s", path);
}
close(fd);
return (error);
}
...
Last edited:
