I just can't format the HDD using libhdd... Why???

sparrow · Post by **sparrow** » Thu Apr 13, 2006 5:52 am

Hi folks!

I am writing a simple application to format the PS2 HDD. Everything goes fine: it's detected, it's formatted (i can see the internal HDD orange led flashing while it's being formatted).

At the end of the proccess, I just poweroff the PS2. But if I run the application again, it recognizes my HDD like UNFORMATTED, i. e., the program was just "pretending" it was formatting my HDD. At this point, the second time the application is run, it should display "Nothing to do! HDD is already formatted", because that was done already in the first execution, but no: I just get the formatting routine again! :(

Here goes my code:

Code: Select all

#include <kernel.h>
#include <sifrpc.h>
#include <libhdd.h>
#include <debug.h>
#include <string.h>
#include <libmc.h>
#include <loadfile.h>

#include <sys/fcntl.h>
#include <sys/stat.h>
#include <sys/ioctl.h>

extern u8 *iomanx_irx;
extern int size_iomanx_irx;
extern u8 *filexio_irx;
extern int size_filexio_irx;
extern u8 *ps2dev9_irx;
extern int size_ps2dev9_irx;
extern u8 *ps2atad_irx;
extern int size_ps2atad_irx;
extern u8 *ps2hdd_irx;
extern int size_ps2hdd_irx;
extern u8 *ps2fs_irx;
extern int size_ps2fs_irx;
extern u8 *poweroff_irx;
extern int size_poweroff_irx;
extern u8 *cdvd_irx;
extern int size_cdvd_irx;

void loadModules&#40;void&#41;;

int main&#40;&#41;
&#123;   
   SifInitRpc&#40;0&#41;; 

   init_scr&#40;&#41;;

   loadModules&#40;&#41;;
   
   if&#40;hddCheckPresent&#40;&#41; == 0&#41; &#123;

      if&#40;hddCheckFormatted&#40;&#41; != 0&#41; &#123;

         if&#40;hddFormat&#40;&#41; == 0&#41;
            scr_printf&#40;"HDD formated successfuly\n\n"&#41;;
         else

            scr_printf&#40;"Error! Could not format HDD\n\n"&#41;;
      &#125; else 

         scr_printf&#40;"Nothing to do! HDD is already formatted\n\n"&#41;;

   &#125; else

      scr_printf&#40;"Error! HDD not found!\n\n"&#41;;
   
   while&#40;1&#41;;
   
   return 0;
&#125;

void loadModules&#40;void&#41; &#123;
   static char hddarg&#91;&#93; = "-o" "\0" "4" "\0" "-n" "\0" "20";
   static char pfsarg&#91;&#93; = "-m" "\0" "4" "\0" "-o" "\0" "10" "\0" "-n" "\0" "40";
   int ret;
   
   hddPreparePoweroff&#40;&#41;;

   SifLoadModule&#40;"rom0&#58;SIO2MAN", 0, NULL&#41;;
   SifExecModuleBuffer&#40;&poweroff_irx, size_poweroff_irx, 0, NULL, &ret&#41;;
   SifExecModuleBuffer&#40;&iomanx_irx, size_iomanx_irx, 0, NULL, &ret&#41;;
   SifExecModuleBuffer&#40;&filexio_irx, size_filexio_irx, 0, NULL, &ret&#41;;
   SifExecModuleBuffer&#40;&ps2dev9_irx, size_ps2dev9_irx, 0, NULL, &ret&#41;;
   SifExecModuleBuffer&#40;&ps2atad_irx, size_ps2atad_irx, 0, NULL, &ret&#41;;
   SifExecModuleBuffer&#40;&ps2hdd_irx, size_ps2hdd_irx, sizeof&#40;hddarg&#41;, hddarg, &ret&#41;;
   SifExecModuleBuffer&#40;&ps2fs_irx, size_ps2fs_irx, sizeof&#40;pfsarg&#41;, pfsarg, &ret&#41;;
&#125;

What I am doing wrong? What am I missing? Hope to get some help from you guys!

Thanks in advance!

sparrow

sparrow · Post by **sparrow** » Thu Apr 13, 2006 10:15 pm

Nobody?

Well, I am using the exploit method to run my format elf. This can be why it's not working?

Hope to get some help!

Regards!

Saotome · Post by **Saotome** » Fri Apr 14, 2006 12:20 am

Well I'm not 100% sure but I had a similar problem in my first HDD project: I created some directories but after restart they were gone. Just before I was about to give up and throw away my HDD I ran a last test doing a hdd cache flush (don't know the exact function name since I'm not home right now) after creating the directories. Maybe that's what you're missing, just a guess though ;)

dlanor · Post by **dlanor** » Fri Apr 14, 2006 3:39 am

This thread made me interested in finding out more on how those two 'hddCheck*' functions really work, so I started looking/searching in the sources. Apparently they are both remapped/wrapped to fileXioDevctl calls in nearly identical manner, as shown by this small excerpt from "$PS2SDKSRC/ee/rpc/hdd/src/libhdd.c"

Code: Select all

int hddCheckPresent&#40;&#41;
&#123;
	int rv;

	if&#40;!hddStatusCurrent&#41;
		hddUpdateInfo&#40;&#41;;

	rv = fileXioDevctl&#40;"hdd0&#58;", HDDCTL_STATUS, NULL, 0, NULL, 0&#41;;

	if&#40;&#40;rv >= 3&#41; || &#40;rv < 0&#41;&#41;
		return -1;
	else
		return 0;
&#125;

int hddCheckFormatted&#40;&#41;
&#123;
	int rv;

	if&#40;!hddStatusCurrent&#41;
		hddUpdateInfo&#40;&#41;;

	rv = fileXioDevctl&#40;"hdd0&#58;", HDDCTL_STATUS, NULL, 0, NULL, 0&#41;;
	if&#40;&#40;rv >= 1&#41; || &#40;rv < 0&#41;&#41;
		return -1;
	else
		return 0;	
&#125;

Both those cases use an identical call, with identical arguments, to ask the IRX driver for the relevant status. The only difference is in how the two functions 'filter' the return value. So the crucial call here is clearly: "rv = fileXioDevctl("hdd0:", HDDCTL_STATUS, NULL, 0, NULL, 0)"

Analyzing this deeper was a bit tricky due to inconsistent use of constants, but apparently HDDCTL_STATUS, defined in "$PS2SDKSRC/common/include/hdd-ioctl.h" is identical in both value and purpose to APA_DEVCTL_STATUS, defined both in "$PS2SDKSRC/iop/hdd/pfs/src/misc.h" and "$PS2SDKSRC/hdd/apa/src/hdd_fio.h", and finally referenced by "$PS2SDKSRC/iop/hdd/apa/src/hdd_fio.c" for the "hddDevctl" function.

The relevant part of that function simply looks like this:

Code: Select all

	case APA_DEVCTL_STATUS&#58;
		rv=hddDeviceBuf&#91;f->unit&#93;.status;
		break;

Clearly then, that structure member 'status' is supposed to keep track of HDD status, both as it relates to presence/absence of the unit, and as it relates to its formatted/unformatted state. The big question then becomes how and when that 'status' value is set inside the IRX.

Judging by the EE code sections quoted further above, it is clear that the function call "hddUpdateInfo()" should handle this, though it doesn't do so directly (only makes various fileXio calls that may affect it). But "hddUpdateInfo()" will only be used if the flag variable "hddStatusCurrent" is false.

That variable is only set in two places, both inside "libhdd.c". The first place is where this static variable is declared, with initialization to 0. The other place is inside "hddUpdateInfo()", where it is set to 1 at the end of the function. So if such a call has already been made earlier, then neither of the two 'hddCheck*' functions will bother to make such an update but will proceed to refetch an old "hddDeviceBuf[f->unit].status" value from the IRX. Any invalid result in that status value, resulting from (or otherwise occurring after) an earlier call to "hddUpdateInfo()", will therefore persist forever as far as these two 'hddCheck*' functions are concerned, as they then do nothing to update the information.

That's as far as I've gotten for now. The main thing to proceed with next is to check how the fileXio calls of "hddUpdateInfo()" affect the IRX internals (mainly hddDeviceBuf[f->unit].status), and try to see if anything suspicious is going on there.

Best regards: dlanor

sparrow · Post by **sparrow** » Sun Apr 16, 2006 9:02 am

Guys, I really don't know what is happening. It just doesn't work. DMS HDD Format Tool works. But my code doesn't. I don't want to use DMS HDD Format Tool. I want to format the HDD by myself. Does anybody here has a working example about how to properly format the PS2 HDD?

Thanks in advance!

sparrow

sparrow · Post by **sparrow** » Mon Apr 17, 2006 12:31 am

Guys,

How can I call the hddFormat function (int hddFormat(iop_file_t *f, ...)) which is inside the /ps2sdk/iop/hdd/apa/src/hdd_fio.c file? I know this file will be merged inside the ps2hdd.irx library, so how can I call it?

I think the problem is with the hddFormat function (int hddFormat()) which is inside the /ps2sdk/ee/rpc/hdd/src/libhdd.c file, because it doesn't create the __mbr partition.

The hddFormat function inside the hdd_fio.c file will create the __mbr partition, so how can I call it instead of the default (libhdd.c) hddFormat() function?

I hope I get a reply soon, so I will make some tests, then I will post here!

Thenks in advance!

Regards,

sparrow

Post by **Drakonite** » Mon Apr 17, 2006 1:26 am

__mbr isn't a pfs formatted partition

The ee side libhdd's hddFormat calls the iop side apa hddFormat (that you pointed at in your post), followed by a pfs format for each of the required partitions that are supposed to contain the pfs file system.

The ee side libhdd DOES create everything the IOP side function of the same name creates (it actually calls it), in fact it does a bit more as it formats the partitions that should be pfs, which the IOP side function requires you to do on your own.

If the drive is formatted using the dms hdd tool (which itself just uses an old version of the libhdd code), does your code then see the drive as formatted? If not it is pretty clear your code simply is not detecting right.

sparrow · Post by **sparrow** » Mon Apr 17, 2006 4:28 am

Thanks for the info, Drakonite!

Yeah, my code detects my HDD as FORMATTED if I use the DMS HDD Format Tool to format it: "Nothing to do! HDD is already formatted" is displayed, what is the correct thing!

So what do you think I could do? Where can I download the old libs used by DMS HDD Format Tool and how can I use them to compile my application?

I hope to get my application working soon, thanks to you guys!

Best regards,

sparrow

Drakonite wrote:__mbr isn't a pfs formatted partition

The ee side libhdd's hddFormat calls the iop side apa hddFormat (that you pointed at in your post), followed by a pfs format for each of the required partitions that are supposed to contain the pfs file system.

The ee side libhdd DOES create everything the IOP side function of the same name creates (it actually calls it), in fact it does a bit more as it formats the partitions that should be pfs, which the IOP side function requires you to do on your own.

If the drive is formatted using the dms hdd tool (which itself just uses an old version of the libhdd code), does your code then see the drive as formatted? If not it is pretty clear your code simply is not detecting right.

Post by **Drakonite** » Mon Apr 17, 2006 9:48 am

Shouldn't hddPreparePoweroff(); be run AFTER the modules are loaded, not before?

sparrow · Post by **sparrow** » Mon Apr 17, 2006 11:30 am

According to libhdd's documentation:

void hddPreparePoweroff();
Installs the default power-off handler. The default poweroff hander will close all PFS files then
power off the PS2 when the reset button is pressed. For this operation it is required that
poweroff.irx (included with libHdd) is loaded on IOP. This can actually be loaded before or after
the call is made to this function.

Anyway, I will put that function call after modules loading, then I will put the results here!

Regards,

sparrow

Drakonite wrote:Shouldn't hddPreparePoweroff(); be run AFTER the modules are loaded, not before?

sparrow · Post by **sparrow** » Mon Apr 17, 2006 8:19 pm

I just made the test... No success! :-(

sparrow wrote:According to libhdd's documentation:

void hddPreparePoweroff();
Installs the default power-off handler. The default poweroff hander will close all PFS files then
power off the PS2 when the reset button is pressed. For this operation it is required that
poweroff.irx (included with libHdd) is loaded on IOP. This can actually be loaded before or after
the call is made to this function.
Anyway, I will put that function call after modules loading, then I will put the results here!

Regards,

sparrow
Drakonite wrote:Shouldn't hddPreparePoweroff(); be run AFTER the modules are loaded, not before?

sparrow · Post by **sparrow** » Tue Apr 18, 2006 10:08 am

Problem solved guys!

I just used old libhdd IRX's that I got from PGEN! I am now wondering why the new lib is not formatting the HDD properly... *sigh*

dlanor · Post by **dlanor** » Tue Apr 18, 2006 5:57 pm

sparrow wrote:Problem solved guys!

I just used old libhdd IRX's that I got from PGEN! I am now wondering why the new lib is not formatting the HDD properly... *sigh*

This may mean "problem solved" for your current project, but it means the opposite for the homebrew community as a whole. It is the new driver, not any old version, which MUST be made to work properly one way or another. Otherwise we've lost control. :(

This also raises the question if any other software successfully uses the new lib for formatting or not !?! If so, then it may just be a matter of using it differently than you tried to do, but if not then it could mean that the current version has completely lost the capability for correct formatting. :(

I'm not yet sufficiently familiar with the libhdd code to debug it myself, though I do plan to rectify that. In the meantime I hope that other developers with a better grip on it will investigate the problem.

Best regards: dlanor

sparrow · Post by **sparrow** » Tue Apr 18, 2006 7:26 pm

I agree with you, dlanor. The problem is only solved to my current project. I really wanted to use the new libs with it. I hope the ps2dev guys really fix this issue someday! Now I am taking off the "solved" from the thread's title, so we don't get a false feeling of "job done".

Regards,

sparrow

Polo35 · Post by **Polo35** » Tue May 30, 2006 6:56 am

So, as requested at ps2scene, i post what i found here.

I'm working on a hdd manager for ULE ( uLaunchELF ), and i'd got some problem with libhdd format fontion from ps2sdk.

I've try with libhdd1.2 from ps2dev.org web site, and format work fine, but size report was wrong.

I decided to search difference between two libs and found in iop/apa/src/hdd_fio.c a little difference in format fonction, setup mbr section:

In ps2sdk libhdd:

Code: Select all

strncpy&#40;header->mbr.magic, mbrMagic, 31&#41;;
header->mbr.magic&#91;31&#93; = '\0';

In libhdd1.2 from ps2dev:

Code: Select all

strncpy&#40;header->mbr.magic, mbrMagic, 0x20&#41;;

I've copied the line from ps2dev libhdd1.2 to ps2sdk libhdd and recomplied it completly, and now format fonction work fine.

Hdd is well reconize formated by $ony tool, DM$ tool, and "my tool". ;)

So if somebody want to confirm that thing, and make a fix to ps2sdk in svn, i would be very grateful.

Best regards

Polo

sparrow · Post by **sparrow** » Mon Jul 10, 2006 7:31 am

OMG! How could I forget to return about this?

Polo, your solution just WORKED GREAT, thank you!

Is this problem already fixed in the SDK svn? Please, someone do that! :-D

Regards

sparrow

Post by **jbit** » Mon Jul 10, 2006 9:47 am

Fixed in SVN revision 1330

Polo35 · Post by **Polo35** » Tue Jul 11, 2006 7:13 am

jbit wrote:Fixed in SVN revision 1330

Great.

Thanks jbit. ;)

Best regards

Polo