Using HL3120 drive with linux and plscsi

[Nayr]

The HL3120 drive requires a nonstandard INQUIRY command.  This is why it is not reconized by most operating systems.  I believe most BIOS can recognize it because they don't use the packet interface.  Drivers that do work avoid the packet inquiry command.

To use plscsi in linux, you have to use the ide-scsi driver and load the sg module. Refer to cd burning tutorials on how to use ide-scsi.

The following was done with an older kernel 2.4.22 and a pata to sata adapter:

The linux scsi module first sends a packet "12 00 00 00 ff 00". This fails and causes the drive to be ignored.  Patch scsi_scan.c to send "12 00 00 00 24 c0". The inquiry command will no longer fail and the drive functions as normal.  This patch may cause other scsi drives to fail to be recognzied.

To use "plscsi -w", change "#define SCL_CDB" in scl.cpp to the above cdb.

Plscsi has another bug that breaks the E7"HIT" commands.  Add to toLengthFromCdb0 in scl.cpp:

Code:

        case 0xE0: /* xE0 .. xFF */ /* SCSI2 vendor-specific */
            return 12;

Now the sg module prevents seemingly random CDBs for being sent. Patch sg_allow_access() in sg.c to always return 1.

Refer to DaveX's excellent post on E7"HIT" commands. 
http://www.xboxhacker.net/index.php?option=com_smf&Itemid=33&action=profile;u=500;sa=showPosts

Things like this now work:

Code:

[root@dp plscsi]# ./plscsi -v -x  "e7 48 49 54 30 90 90 a2 00 4f 85 00" -i x1
x 00000000 E7 48 49:54:30:90 90 A2:00:4F:85 00 .. .. .. .. "gHIT0PP"@OE@"
x 00000000 0A .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. "J"
// 0 = plscsi.main exit int

Next I would like somebody to come up with a way to dump the drive key without soldering.

[stonersmurf]

100% confirmed working method to dump your 3120L flash (yes, including key)

plscsi -p -v -x "E7 48 49 54 01 00 91 00 00 00 D0 00" -i xD000 -t d0.bin
plscsi -p -v -x "E7 48 49 54 01 00 91 00 D0 00 D0 00" -i xD000 -t d1.bin
plscsi -p -v -x "E7 48 49 54 01 00 91 01 A0 00 D0 00" -i xD000 -t d2.bin
plscsi -p -v -x "E7 48 49 54 01 00 91 02 70 00 D0 00" -i xD000 -t d3.bin
plscsi -p -v -x "E7 48 49 54 01 00 91 03 40 00 C0 00" -i xC000 -t d4.bin

copy /b d0.bin+d1.bin+d2.bin+d3.bin+d4.bin 3120L_descrambled.bin

No, I didn't try this myself, all credits go to the little birdie .. 

Try that, it should dump the firmware.

[Nayr]

Sorry didn't follow that thread...  Wish we just had one thread again...
If it ain't broke, don't fix it.
Much simpler.


(anita999)
This should be interesting...

Code:

[root@dp plscsi]# ./plscsi -v -x "e7 48 49 54 01 00 91 00 4f 00 00 ff" -i xff
x 00000000 E7 48 49:54:01:00 91 00:4F:00:00 FF .. .. .. .. "gHITA@Q@O@@?"
x 00000000 A0:AA:96:C0 22:31:23:3D 85:45:EA:C9 B3:2B:C6:5B " *V@"1#=EEjI3+F["
x 00000010 74:74:74:74 74:74:74:74 74:74:74:74 74:74:74:74 "tttttttttttttttt"
...
x 00000070 74:74:74:74 74:74:74:74 74:74:74:74 74:74:74:74 "tttttttttttttttt"
x 00000080 00:01:05:08 17:0A:0C:29 03:00:4F:00 A2:00:4F:00 "@AEHWJL)C@O@"@O@"
x 00000090 A3:00:4F:00 FF:FF:FF:FF FF:FF:FF:FF FF:FF:FF:FF "#@O@????????????"
x 000000A0 FF:FF:FF:FF FF:FF:FF:FF FF:FF:FF:FF FF:FF:FF:FF "????????????????"
...
x 000000E0 FF:FF:FF:FF FF:FF:FF:FF FF:FF:FF:FF FF:FF:FF:FF "????????????????"
x 000000F0 FF:FF:FF:FF FF:FF:FF:FF FF:FF:FF:FF FF:FF:FF .. "???????????????"
// 0 = plscsi.main exit int
[root@dp plscsi]#

100% confirmed working method to dump your 3120L flash (yes, including key)

plscsi -p -v -x "E7 48 49 54 01 00 91 00 00 00 D0 00" -i xD000 -t d0.bin
plscsi -p -v -x "E7 48 49 54 01 00 91 00 D0 00 D0 00" -i xD000 -t d1.bin
plscsi -p -v -x "E7 48 49 54 01 00 91 01 A0 00 D0 00" -i xD000 -t d2.bin
plscsi -p -v -x "E7 48 49 54 01 00 91 02 70 00 D0 00" -i xD000 -t d3.bin
plscsi -p -v -x "E7 48 49 54 01 00 91 03 40 00 C0 00" -i xC000 -t d4.bin

copy /b d0.bin+d1.bin+d2.bin+d3.bin+d4.bin 3120L_descrambled.bin

No, I didn't try this myself, all credits go to the little birdie .. 

Try that, it should dump the firmware.

[anita999]

hoo, you know me, man. really appreciate, Nayr.

btw, the firmware only checks whether the control byte is C0 or not. I modify the firmware instead of the PLSCSI and it works great. Now windows recognize the drive as "standard SCSI DVDROM"

sorry, the drive was recognizes as "3120L". and you can brose the video content of the xbox original disks. by using the plscsi, you can download all data in the RAM and Flash area. But somwhow the drive gets freezed when I try to download the internal memory. I couldn't figure out what's going wrong.

[uberfry]

hoo, you know me, man. really appreciate, Nayr.

btw, the firmware only checks whether the control byte is C0 or not. I modify the firmware instead of the PLSCSI and it works great. Now windows recognize the drive as "standard SCSI DVDROM"

Great, does it still work on the xbox360? And can you read games without hotswapping?

[Arakon]

reading games can't work until the 360 "unlocks" the drive, sort of like Specialist's unlocker for the xbox 1 drives. being detected just means it will work as a standard dvdrom without any capability to read 360 disks (yet).

[DonJ]

btw, the firmware only checks whether the control byte is C0 or not. I modify the firmware instead of the PLSCSI and it works great. Now windows recognize the drive as "standard SCSI DVDROM"

So you are saying after changing the controll byte of the HL3120 drive to C0, the dvd drive works in windows? What do you use to flash the firmware?

Thx

[probutus]

there is a function included in the recent 2.6.15 kernel which sounds very promising:

/**
 * scsi_unlock_floptical - unlock device via a special MODE SENSE command
 * @sdev:       scsi device to send command to
 * @result:     area to store the result of the MODE SENSE
 *
 * Description:
 *     Send a vendor specific MODE SENSE (not a MODE SELECT) command.
 *     Called for BLIST_KEY devices.
 **/
This function might give us the opportunity to get the HL-3120L device being recognized without having the support for other drives broken;
since my sata->pata converter has not arrived yet I will start my investigations without having the real drive attached.

This is my first post in this forum I want to thank you very much for this great forum and I hope I can share my knowledge so that we all have a working generic linux driver in the end 

[probutus]

I did some further investigations and found out the following (referring to the kernel 2.6.15):

if we change: (in scsi_scan.c/function scsi_unlock_floptical() )

the sequence:
scsi_cmd[0] = MODE_SENSE;
        scsi_cmd[1] = 0;
        scsi_cmd[2] = 0x2e;
        scsi_cmd[3] = 0;
        scsi_cmd[4] = 0x2a;     /* size */
        scsi_cmd[5] = 0;

with this one:
        scsi_cmd[0] = MODE_SENSE;
        scsi_cmd[1] = 0;
        scsi_cmd[2] = 0;
        scsi_cmd[3] = 0;
        scsi_cmd[4] = 0x24;     /* size */
        scsi_cmd[5] = 0xC0;

we have the right unlock command sent to the drive; now we only have to convince the kernel that it has to send that data to our *beloved*    xbox-drive:

therefore we have to add a new entry into scsi_devinfo.c:
we append a line directly after:       
{"IOMEGA", "Io20S         *F", NULL, BLIST_KEY},
which contains the identification data of our 3120  (it also has to include the value BLIST_KEY in the end).

if this succeeds the kernel should send the right inquiry command to our drive and all other connected cd/dvd media will work undisturbed

except three devices:
        {"IOMEGA", "Io20S         *F", NULL, BLIST_KEY},
        {"INSITE", "Floptical   F*8I", NULL, BLIST_KEY},
        {"INSITE", "I325VM", NULL, BLIST_KEY},
which will now be sent the "wrong" xbox-key.

and this is where I am currently stuck because I do not have my sata/pata converter yet

is there someone who can do the following (depending on where you connected your drive) on the console and post the output:

cat /proc/ide/ide0/hda/model #if you connected the dvd as primary master
cat /proc/ide/ide0/hda/identify #if you connected the dvd as primary master

cat /proc/ide/ide0/hdb/model #if you connected the drive as primary slave
cat /proc/ide/ide0/hdb/identify #if you connected the drive as primary slave

cat /proc/ide/ide1/hdc/model #if you connected the drive as secondary master
cat /proc/ide/ide1/hdc/identify #if you connected the drive as secondary master

cat /proc/ide/ide1/hdd/model #if you connected the drive as secondary slave
cat /proc/ide/ide1/hdd/identify #if you connected the drive as secondary slave

I will try to compile a test module as soon the data is available

[Nayr]

probutus:  you need a special case for the INQUIRY command not MODE_SENSE.

Personally I don't think its worth the effort. It might not even break anything.

Also of note...

My patches don't work after a boot. They only work after a "rmmod"ing sg, ide-scsi and scsi_mod and reloading them. I don't know why.

[probutus]

Nayr: you are right, I somehow mixed the commands... SORRY.. it was three o'clock in the morning over here..

but as I can see in the in the linux driver there is also  a similar opportunity for the INQUIRY command...

The driver sends the inquiry command up to three times (first starting with 0x12, 0x00 0x00 0x00  0x00
where  is the expected response lenght. which seems to be 0xff in this case.

I will add a fourth (or a changed first) try containing the special xbox inquiry data;

@Nayr: Do you know if the drive is still responding if we first send it the standard INQ data like 0x12 0x00 ... 0xff ... and later the correct one or does it first need to be resetted after the failed attempt before sending the 'right' inquiry?

concerning the strange behaviour of the module: can you please switch on the logging facility (kernel options in drivers -> scsi device support -> scsi logging facility).

Then it is possible to monitor various activity via system messages (stored in /var/log/messages)

logging in this case for the drive recogniton process can be activated via:

echo "scsi log scan 3" > /proc/scsi/scsi #this logs all information about the ongoings in the driver in /var/log/messages

hopefully  we can gather some information why your modules do not work on startup but when inserting them later on...

BTW: Via this interface it is possible to log even more about the scsi communication between the drive and the linux host maybe this will also help later on...

[Pandor]

....

To use plscsi in linux, you have to use the ide-scsi driver and load the sg module. Refer to cd burning tutorials on how to use ide-scsi.

....

Would this still be required for newer (2.6.xx) kernels?
hasn't ide-scsi emulation been deprected (unmaintained) in favor of the new ATAPI interface?
As i understand, scsi-emulation was only a workaround for the old drivers wich did not support scsi commands to be passed on to ATAPI drives.

on a sidenote: I realy should get the dvd drive out, but i'm afraid that i'll lose my warranty...
My first 360 died after 2 weeks with a hardware error, so i'm thinking twice before opening this box just yet.

[probutus]

plscsi requires a scsi-device node to operate (the ide nodes /dev/hda? are not supported)

I'm still waiting for my sata-ide adapter... ;-(

[Pandor]

Are you sure, because when i run ./plscsi /dev/hdc -v -x "12 0 0 0 24 0" -v -i x24 it just works (or so it seems to me..).

Code:

./plscsi /dev/hdc -v -x "12 0 0 0 24 0" -v -i x24
x 00000000 12 00:00:00 24 00 .. .. .. .. .. .. .. .. .. .. "R@@@$@"
x 00000000 05:80:00:32 5B:00:00:00 4D:41:54:53 48:49:54:41 "E@@2[@@@MAT$#!tA"
x 00000010 44:56:44:2D 52:41:4D:20 55:4A:2D:38 32:35:53:20 "DVD-RAM UJ-825S "
x 00000020 44:31:30:30 .. .. .. .. .. .. .. .. .. .. .. .. "D100"
// 0 = plscsi.main exit int

The above is just a litle vendor string test on my laptop's dvd-writer.

afaik. since kernel 2.6, SG_IO has been implemented for ATAPI drives which uses MMC.
Only 2.4 kernels needed the SCSI subsystem (ide-scsi).

I could be way off here.. i've only been using linux for a few months now.. still learning.

After some more google-ing i came up with this:
http://sg.torque.net/sg/#mozTocId551081

In the lk 2.6 series the SG_IO ioctl has been replicated (with a slightly reduced feature set) in the block subsystem.

Also a good read:
http://sg.torque.net/sg/sg_io.html

[probutus]

you are right, but using the ide-scsi driver has the advantage that (as previously mentioned) it is not needed anymore.

If we manipulate the inquiry command in the scsi-cdrom driver the system will only detect the connected xbox drive; other drives (also ones connected via usb) might not get recognized anymore.

When using ide-scsi we can tell explicitly in the kernel config on which drive we want to use the ide-scsi driver so that it only gets loaded for the xbox drive (hdc=ide-scsi) for example. All other drives will continue working.

I found out that ide-scsi sends three inquiry commands to a connected drive:

de-scsi: TRANSFORM cmd: INQUIRY 12  0  0  0 24  0
ide-scsi: TRANSFORM cmd: INQUIRY 12  0  0  0 60  0
de-scsi: TRANSFORM cmd: INQUIRY 12  0  0  0 FF  0

before it is attached

In the meantime I prepared a patch for ide-scsi.c (located in drivers/scsi) which changes the inquiry command sent to the drive:


in the function: static inline void idescsi_transform_pc1(..)
{
        u8 *c = pc->c, *scsi_buf = pc->buffer, *sc = pc->scsi_cmd->cmnd;
        char *atapi_buf;

        if (!test_bit(PC_TRANSFORM, &pc->flags))
        {
                return;
        }
        else
        {
                if (c[0] == INQUIRY)
                {
                c[5]=0xc0;
                printk("ide-scsi: TRANSFORM cmd: INQUIRY %2x %2x %2x %2x %2x %2x\n"
                                ,(char)c[0]
                                ,(char)c[1]
                                ,(char)c[2]
                                ,(char)c[3]
                                ,(char)c[4]
                                ,(char)c[5]);
                }
        }
        if (drive->media == ide_cdrom || drive->media == ide_optical) {
                if (c[0] == READ_6 || c[0] == WRITE_6) {

...
This patch is done against the 2.6.15 kernel (should also work with older 2.6 please compare)
This should set the changed 5th character from 00 to c0 which is exactly what we want. Can someone please test?
As already mentioned, we should now have the drive recognized with all other drives still working properly..

*EDIT* fixed a typo in the code (copy/paste from VI sometimes has strange effects ;-) )

*2nd EDIT* as I could read out of the original fw-hacking thread there is a special mode sense command required to unlock the data session of xbox dvds. Since we use ide-scsi exclusively for our dvd-drive one could do the following:

1) fix the first inquiry command sent that it includes c0 in the last byte (this is already done with the above patch)
2) check if c[4] contains 0x60  or 0xff (this would be the second or third inqiry command and send the unlock command instead)

As posted by others earlier this worked if the host sends this command immediately the unlock command after the inquiry

-> theoretically we should have access to the data partition then available
-> practically i do not know what happens to the kernel since it expects the result from his inquiry

A second idea would  be to patch the MODE_SENSE packet (as described in one of my misinterpretation of the MODE_SENSE command in conjunction with the BLIST_KEY flag)...

Any suggestions?

[SpenZerX]

Hi,

i have ripped the flashroutine (that ist uploaded to 0x8000000) from the GDR-8163b-flasher.

Has anybody tested if it works on GDR-3120??? (somebody here with flash chip in a socket and flashreader/writer if flashing went wrong?)

If it works we can flash only parts of the firmware (0x2000-0x3ffff). This is a 100% secure way to test our firmware changes without desoldering, because the failsave part stays intact.

SpenZer

[probutus]

@SpenZerXcan you pm me the fragmet of code? I will try to have a look at it...

@Pandor: I had a closer look at the ide-probe and ide-cd modules; it seems that the linux ide driver tries to identify the attached drives via the ata command 0xEC (= identify device) and if this fails 0xA1(identify packet device). I tapped the packet send routine of the ide-cd driver and see that there is no inquiry command sent at all to the cdrom drive (in contrast to the ide-scsi driver). Which makes the inclusion of a fix for the ide driver more difficult than simply patching ide-scsi.

And this is what's currently confusing me:

1)  The BIOS seems also to use 0xEC or 0xA1 to retrieve device information while querying the IDE-Bus.  Then is possible to boot from the device. I'm pretty sure that there is no specific inquiry sent.
2) The drive does not get recognized when trying to mount it from linux with the standard ide-cd driver since it seems to require a special INQUIRY command. If this is the case, why can the bios boot from it (since eltorito uses also packet commands)?

It was stated earlier that application which do not use the packet interface seem to work.
does this mean that the standard ide commands work but to use the atapi extensions there must be this inquiry command sent first? If this is the case the drive should first be detected by linux but later there is no driver installed.

*ADDON* I got my pata-sata converter! I had to carve it a little because there was the wrong connector on it  FIXED

The above mentioned patch to ide-scsi works! The drive is recognized as scd0 and woks like a charm (on the first look)

My assumption concerning the IDENTIFY_PACKET device was right: When the IDE controller is initialized:

Probing IDE interface ide1...
probing for hdc: present=0, media=32, probetype=ATA cmd=ec
ide-probe.c: try_to_identify: hdc cmd: ec
ide-probe.c: try_to_identify: hdc cmd: ec
probing for hdc: present=0, media=32, probetype=ATAPI cmd=a1
ide-probe.c: try_to_identify: hdc cmd: a1
hdc: HL-DT-STDVD-ROM GDR3120L, ATAPI CD/DVD-ROM drive
probing for hdd: present=0, media=32, probetype=ATA cmd=ec
probing for hdd: present=0, media=32, probetype=ATAPI cmd=a1

The problem that the drive isnt attached is somewhere else:
ide-cdrom-get-capabilites: HL-DT-STDVD-ROM GDR3120L
hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown


Will look into this.... My assumption is that if we can convince the ide driver to talk to the drive (instead of ide-scsi) it should be possible to connect the drive directly via sata (no more adapters needed...)

[probutus]

UPDATE: The following command is sent to the drive:

ide_cdrom_get_capabilities:cdrom_mode_sense:GPMODE_CAPABILITIES_PAGE
ide_cdrom_device_packet:0x5a 0x00 0x2a 0x00 0x00 0x00 0x00 0x00 0x18 0x00 0x00 0x00

it seems that this is the 10 byte Version of the MODE SENSE COMMAND for retrieving device capabilities (not to confuse with the INQUIRY command)

If this command succeeds the drive should be recognized.... These values are all static ones so it should be possible to fill them already in the driver.

In the ata specification this command is marked as MANDATORY. Will try to enter a fake the answer tomorrow..

Maybe someone from the Firmware-thread may help and tell what happens inside the drive when this command is sent....  (and if it is possible to implement that command; its just sending constant data back (except the current drive speed; could be faked maybe).

Help is GREATLY appreciated...

[probutus]

SUCCESS!!

I got the GDR-3120L drive running in linux without using ide-scsi but only patching the ide-cd driver!!! (And I could browse the VIDEO_TS and AUDIO_TS part of an 360 disc-> someone will have to add some unlock code into the "faking capabilities section"...)

I could mount and access several standard discs just like in every other cdrom (still used my sata->pata converter)

The only thing I had to do was to prevent the ide-cd module to send the GPMODE_CAPABILITIES_PAGE sense-package to the cdrom but fake the capabilities instead.

See the code to change in linux/drivers/ide/ide-cd.c below. (All other attached cd/dvd drives will continue working unaffected)

exchange the function ide_cdrom_get_capabilities() with this one:

static int ide_cdrom_get_capabilities(ide_drive_t *drive, struct atapi_capabilities_page *cap)
{
        struct cdrom_info *info = drive->driver_data;
        struct cdrom_device_info *cdi = &info->devinfo;
        struct packet_command cgc;
        int stat=0, attempts = 3, size = sizeof(*cap);
        /*
         * ACER50 (and others?) require the full spec length mode sense
         * page capabilities size, but older drives break.
         */
        if (!(!strcmp(drive->id->model, "ATAPI CD ROM DRIVE 50X MAX") ||
            !strcmp(drive->id->model, "WPI CDS-32X")))
                size -= sizeof(cap->pad);

        if (strcmp(drive->id->model, "HL-DT-STDVD-ROM GDR3120L"))
        {
                init_cdrom_command(&cgc, cap, size, CGC_DATA_UNKNOWN);
                do { /* we seem to get stat=0x01,err=0x00 the first time (??) */
                        stat = cdrom_mode_sense(cdi, &cgc, GPMODE_CAPABILITIES_PAGE, 0);
                        if (!stat)
                                break;
                } while (--attempts);
        }
        else
        {

                /* the GDR3120L does not support the GPMODE_CAPABILITIES_PAGE command so we have to fake it */
                printk("GDR3120L detected!->faking capabilities\n");
                memset(cap,0,sizeof(struct atapi_capabilities_page));
                cap->dvd_r_read=1;
                cap->dvd_rom=1;
                cap->method2=1;
                cap->cd_rw_read=1;
                cap->cd_r_read=1;
                cap->multisession=1;
                cap->mode2_form2=1;
                cap->mode2_form1=1;
                cap->audio_play=1;
                cap->composite=1;
                cap->isrc=1;
                cap->cdda=1;
                cap->upc=1;
                cap->maxspeed=35344;
                cap->buffer_size=8;
                cap->curspeed=35844;
        }
        return stat;
}

[TheSpecialist]

Congrats, probutus, VERY nice work !