BB Navi install on 10k....please kill me.

Ripping my hair out here literally. I have two dev drives which might be the problem. Set them on hdd 0 and you at least get to an install, set them to hdd 1 and everything goes wonkers. I have gotten both bb navi .30 and .20 to boot via ulaunchelf. .20 starts installing get to about 1/4 the way install on the mem card, polls the hdd and red screens, japanese and stops. .30 gets to approximately 28.5% install on the mem card, polls the hdd and stops, red screen, japanese and stops. My .30 copy is now not booting. Laser sees the disc and when you launch it just hangs in ulaunchelf. I think that disc may be too scratched,

 

I assume this is a SCPH-10000 retail? And are the "dev drives" the ones marked "for TOOL"?

I had a very similar experience, and eventually concluded that the "for TOOL" drive didn't support the security commands that the retail one did, despite looking identical and having Sony markings on it. In the end, I removed it from the case and swapped it with the standard 40GB "expansion bay" type drive - at which point the external drive started working normally and the expansion bay drive wasn't recognized by any Sony software, although it worked fine with HDD loader.

Having said this, some people (like sp193) have got drives in those cases which *do* support the security commands, and they all appear externally identical.

 

They are DTL-H20400 drives. Yeah that was the direction I was going in. I do have a retail and a dev pcmica card. I have not tried the dev card yet just to see if it changes anything.

 

I didn't get one. It was @l_oliveira who did.

That's because there has to be a ATA Master, so that switch must be always set to device 0.

 

Even when I was typing that I was thinking I should put a ? after it

 

I hope that someone would finally have access to such a disk, to confirm that such a thing does exist and the one that Trimesh got wasn't just a one-off defect.
Although I feel that it would be weird for such a disk to exist because it would have no use at all - at least not with the finalized standards for HDD support (no SONY ATAD module would work with it).

 

The .30 bb navi disc i have is about 10 years old. I was one of the first on ps2scene to have a non sony hdd in a us console with bb navi. The problem is there is a scratch on the disc.

 

Well, I've always thought that would explain why there seem to be so many of those HDDs that are still in their boxes unopened. They don't work.

 

Might have found it here, cracked one of the externals open, My retail internal in my 370000 OB is set to cable select ( think) My maxtor non-retail in my 30001-r running linux is cable select.....the external is not cable select but is labeled scph-20401. Next shot enable cable select.

NOPE not that either. Sad when one of the externals is identical to my internal. Really thought that was it.

 

The disk should be set to Master.

Did you try the format option?
It isn't impossible for the disk to be already bad (I.e. has bad sectors).

 

The one that is like my internal is formatted from ule. The second one won't format at all not even in ule. Navi .30 disc that will install to anything crashes at 12.5% with either hdd when you choose the 3rd option from the main menu to install. And I have then both back on Master. This is just nuts.

 

I meant formatted, with the HDD Utility Disc that installs the PSBBN.

I doubt that they were made to have no use though. Given that they were already put into nice enclosures, massed-produced and their model numbers don't even represent the original release (SCPH-10210) of the HDD unit (but the later SCPH-20400).

The disks have to be in working order (i.e. SMART works and there are no bad sectors in the APA layout), however. The HDD Utility Disc (not sure about the PSBBN ones though) lacks checks on the condition of the disk.

 

Indeed, I got a couple of those DTL-H20400 drives. Because the TOOL can't execute Magic Gate stuff and that means no PSBBN (normally) I suppose SONY allocated the drives that failed SMART to be put on DEV units.
(I had one of those drives which did not pass the MBR tests at boot time, making it impossible to boot PSBBN from it. I eventually fixed the issue with PC3000 by relocating a sector on the firmware area.)

Those drives do support the SONY custom commands but they might have no security data installed in them. In that case they will work with the HDD utility disc but not with PSBBN.

There are DTL drives with empty security sectors (no security data) and because PSBBN requires the security data for DRM purposes it will fail install if it can't find the security sector data. It will put out a red screen with a message about the HDD being faulty (same behavior as if you were using a non SONY HDD).

When I talked to him on messaging, I thought he were having problems with his memory card. He never mentioned the drives were those DTL-H20400 units. lol

Edit: Just to mention, the drive I have which has no security data is a SEAGATE.

 

I have one seagate and one maxtor which is the one i can atleast format in ule. So how do I work this pc3000?

 

Those are failed disks, so I doubt that SONY would have done such a thing.

I think that you wrote that it's an earlier model, hence the newer ones have support for the HDD-based DNAS?

 

That's what I thought at the time but after that I ran the tool which dumps the security sector and it came up to be all zeroes. So the HDD is just unfinished.

 

I did it on a ROMULUS drive (Maxtor) as I could understand what the menus were (they're all in russian) but I could not make out how the SEAGATE one works.

I have like five dev drives and only one of the maxtors had a physical problem. It only de the drive not boot to OSD from MBR. So, since MBR is never used on a TOOL they put the drive into a DTL kit.

@sp193: Why wouldn't them not? The drive is used only for testing stuff, it's not supposed to hold data for a user on long term. I see no harm on them doing that, honestly.

 

I believe that it would be unlikely because they would have needed to identify the bad disks. That would be a time-consuming process and I don't suppose they would be able to find that many bad disks so easily (they didn't make them). It would hence be easier to purchase working disks.
Not to mention that we didn't find the majority of them to have failed SMART.

A failed disk may not even necessarily have a failed SMART status. Depending on the type of damage, they may not even be able to guarantee that the disk (not counting the data) will last.
APA requires all sectors to be functional, so a bad disk cannot be used. I don't think that PFS can work with bad sectors either.

 

The fault was on the firmware area(negative lba), not on the user area.

 

But what are the odds of physical damage residing on only the firmware tracks?
Even if the damage resided on only the tracks containing the firmware, it wouldn't necessarily mean that the disk will have a failed SMART status.
My own SCPH-20400 had a failed firmware region and it was a CEX disk. SMART didn't fail on it anyway; it couldn't be enabled (obviously caused by the disk becoming partially brain-dead). This means that a failed region wouldn't always result in the same type of failures.