Hitachi L47 memory dumps

[SuperMario]

Hi all,

Would anyone who has managed to get a Hitachi L47 drive working on their PC be able to help out a little?

I need someone who can do live memory dumps (via the debug command) from the following regions of memory, and preferably, two dumps from each memory region, and each set of dumps done once without a disc present, once with a DVD-Video movie and once again with a legitimate Xbox 360 disc mounted.

0x0000 through 0xffff - Low memory and HW regs.  If the drive crashes reading unbuffered HW regs, then as far along as you can (possibly 0x7fff ?)

0x8002ec00 - 0x8003a300 - The protected buffer regions (which can be easily got around by using the great explaination about the limit check failures as described on SeventhSon's site)

It would be good to also have an output of the information provided by something like DVD InfoPro or Nero on the discs you used for the dumps as well.

I really need to see (and confirm) the contents of these ranges as my drive is currently dismantled and having some probe wires attached to its microcontroller.

Gracias!

SuperMario

[SeventhSon]

I really need to see (and confirm) the contents of these ranges as my drive is currently dismantled and having some probe wires attached to its microcontroller.

My drive is in a similar state. Fortunately, due to the lack of test points and my shakey soldering hand,  I only have a couple of wires attached. If nobody has taken up the task before I get home (in about 8 hours), I'll restore my drive and get you the dumps you need.

I've been dumping lots of locations in the 0 - FFFF region lately, never had a single crash. So we should be able to get a sizable (if not total) dump of that range.

On a slightly related note. I see that DaveX half-documented a write to memory debug command.

E7 48 49 54 3B 06 ?? ?? ?? ?? ?? ?? : 0x90026005 : Write data to RAM?

I've seem to have had some limited success with this command (using  E7 48 49 54 3B 06 AA AA AA AA LL LL, A = address, L = length, just like the read memory command), but nothing consistant. Has anybody discovered anything more about writing to the MN103 address space (specifically 0 - FFFF) in software? Any info would be most useful to me, that way I won't have to wire up my ROM emulator (which is taking me forever to do). Cheers.

[SpenZerX]

With the command E748 49 543B 06 ...
you can only upload programm-code (or data) to 0x80000000

There is a checksum at the end of the file that is uploaded. (can easily calculated with winhex)

But the problem is that the drive only accepts this funktion when bit 10 at adress 0x5A5 is set.

ROM0:9002A5A1                 btst    0x10, (X_Status_2+1)
ROM0:9002A5A6                 beq     loc_9002A5CC                    ;<- problem
ROM0:9002A5A8                 mov     ATAPI_CDB1_6, A2


since two days iam trying to set this bit (my flash 90006000+ routine is ready to upload), but still no go.

I think before code can uploaded the drive needs a special Mode-Sense command (a code page). 

Is there a command that disables the drives caches? Because this should be done before upload.  Hmm


You cant download region 0xE08- 0xffff with HIT-Commands.


SpenZer

[SeventhSon]

@SuperMario
I just realised that you wanted dumps from a 0047 firmware. My drive is a 0046. Here they are anyway, I wouldn't think there'd be any significant differences.

Game: Project Gotham Racing 3 (UK version)
DVD movie: Joe Satriani Live in San Francisco disc 1 (UK, region 3 right? I forget)

http://www.kev.nu/360/misc/memdumps.tar.bz2 (30KB)
http://www.kev.nu/360/misc/memdumps.zip (60KB)

Enjoy.

It would be good to also have an output of the information provided by something like DVD InfoPro or Nero on the discs you used for the dumps as well.

Sorry. Can't help you with this at the moment. But if you really really need this info then let me know.

@ SpenZerX
Thanks for the info. Writing adn then jumping to code would be almost as good as writing to low memory directly. hopefully there's a way around the problematic (5A5) check.

You cant download region 0xE08- 0xffff with HIT-Commands.

What makes you say that?

[djhuevo]

Has anybody discovered anything more about writing to the MN103 address space (specifically 0 - FFFF) in software? Any info would be most useful to me, that way I won't have to wire up my ROM emulator (which is taking me forever to do).

the "e7 'H' 'I' 'T' cc BB xx xx AA AA AA AA" let you write arbitray value BB byte to any AAAAAAAA address.

edit: sadly the address is ORed by 0x80000000, but maybe you can upload in a byte by byte basis the code to 0x80000000, and execute ii with the "E7 'H' 'I' 'T' 3B 07" cmd

[SeventhSon]

On the issue of writing to the drive's complete address space in software:

I've been looking at the Mode Select(10) handler recently and I've finally discovered a way to write to the entire MN103 address space in software. It isn't pretty but it works.

Long story short:

1) Send SuperMario's command to set (598) bit 6 (i.e. initiate what i have been calling modeB)
E7 48 49 54 30 90 90 D0 01 00 00 00

2) Use djhuevo's idea and RAM poke command to upload MN103 code one byte at a time. This code, when executed, can write to anywhere we want. Make sure your code has a return instruction at the end ;-)
E7 48 49 54 CC 1st_code_byte 00 00 80 00 00 00
E7 48 49 54 CC 2nd_code_byte 00 00 80 00 00 01
etc.

3) Send the following mode select(10) command to the drive to set (59E) bit 3 (needed to jump to RAM)
packet:
55 10 00 00 00 00 00 00 08 00 00 00
mode parameter list:
00 06 00 00 00 00 00 00

4) Send the following mode select(10) command to the drive. It will fail, but will execute our code along the way. Note the 'H' and 'L' bytes in the reserved fields at offsets 3 and 4 in the mode select(10) packet. It would be nicer to use the proper Hitachi jump to RAM command, but I had problems using that command.
packet:
55 10 48 4C 00 00 00 00 08 00 00 00
mode parameter list:
00 06 00 00 00 00 00 00

Here's some Linux code that uses the above process to peek/poke bytes in memory.
http://www.kev.nu/360/code/pp.c

And another Linux app that will upload and execute arbitrary code.
http://www.kev.nu/360/code/execcode.c

(Edit: The above two programs are criminally under-tested). Hopefully these will be useful to somebody besides me. Or at least interesting.


@ SpenZerX. You were right. There is a special mode select(10) command that will set your flag at (5A5) bit 4.
packet:
55 10 00 00 00 00 00 00 0A 00 00 00
mode parameter list:
00 08 00 00 00 00 00 00 09 00

Unfortunately that command also requires (598) bit 6 to be set (i.e. modeB) and, even worse, it requires that modeB was induced by holding tray_status low at drive power up. SuperMario's software command to set (598) bit 6 won't work

Suggestions:
* You could try using my peek/poke program to set (5A5) bit 4 directly, but there may well be other things you need to set up that this approach will omit.
* A better idea IMHO would be to use SuperMario's command to induce modeB, then use my program to clear (598) bit 4 (this bit is what causes the mode select command to fail for software induced modeB) and then finally send the above mode select command to set you (5A5) bit 4.

Long story long:
http://www.kev.nu/360/dvd.html#update_08_03_06

[djhuevo]

4) Send the following mode select(10) command to the drive. It will fail, but will execute our code along the way. Note the 'H' and 'L' bytes in the reserved fields at offsets 3 and 4 in the mode select(10) packet. It would be nicer to use the proper Hitachi jump to RAM command, but I had problems using that command.

the HITACHI cmd "jump to RAM" also execute the code, but never properly return. be carefull patching "jump to RAM" or mode select(10) coz this way the driver firmware is updated via software. I have to modify the firmware "flasher code" iniside a DLD to rescue a drive where the function that do the "calls a0" was patched.

[SeventhSon]

4) Send the following mode select(10) command to the drive. It will fail, but will execute our code along the way. Note the 'H' and 'L' bytes in the reserved fields at offsets 3 and 4 in the mode select(10) packet. It would be nicer to use the proper Hitachi jump to RAM command, but I had problems using that command.

the HITACHI cmd "jump to RAM" also execute the code, but never properly return.

Yeah, that's exactly what I found. My initial thought was that it was something to do with the 32bit value at packet[8] in the 0xE7 "jump to RAM" packet. To me this looks like a length field for some kind of data transfer If the drive expects to transfer data after executing the code in RAM, then this might explain why it appears to hang/not return. Do you know what the value at packet[8] is? I didn't bother looking into it because the Mode Select(10) method for jumping to RAM is working nicely for me. All I know is that is is restricted to 1 - 0x60000.

[SpenZerX]

Good work SeventhSon,

i did it with plscsi, but the HIT Upload is still not working.

There is a test for bit4 at Adress 0x599 in the HIT-Upload routine
ROM0:9002A66E                 btst    0x10, (0x598+1) ! ak40>bit 4 must be 1!
ROM0:9002A673                 bne     loc_9002A690

I hope that i can fix this tonight.

SpenZer



set PLSCSI=\\.\G:

rem *********** first set bit 6 and clear bit 4 at Adress 0x598 ************

rem set bit 4 and bit 6 in Adress 0x598 with HIT-Command
plscsi -p -v -x  "E7 48 49 54 30 90 90 D0 01 00 00 00" -i x1C 

rem upload code to 0x80000000 that clears bit 4 in Adress 0x598
rem plscsi -p -v -x  "E7 48 49 54 CC ?? 00 00 80 00 00 00" -i x1C 
rem CODE: CF 08 34 98 05 F8 E0 AF F8 E4 40 02 98 05 CE 08 F0 FC
rem Source:
rem RAM1:80000000                 movm    [D0,D1,A0,A1,MDR,LIR,LAR], (SP)
rem RAM1:80000002                 movbu   (0x598), D0
rem RAM1:80000005                 and     0xAF, D0
rem RAM1:80000008                 or      0x40, D0 !
rem RAM1:8000000B                 movbu   D0, (0x598)
rem RAM1:8000000E                 movm    (SP), [D0,D1,A0,A1,MDR,LIR,LAR]
rem RAM1:80000010                 rets
rem RAM1:80000012                 
plscsi -p -v -x  "E7 48 49 54 CC CF 00 00 80 00 00 00" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC 08 00 00 80 00 00 01" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC 34 00 00 80 00 00 02" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC 98 00 00 80 00 00 03" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC 05 00 00 80 00 00 04" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC F8 00 00 80 00 00 05" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC E0 00 00 80 00 00 06" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC AF 00 00 80 00 00 07" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC F8 00 00 80 00 00 08" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC E4 00 00 80 00 00 09" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC 40 00 00 80 00 00 0A" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC 02 00 00 80 00 00 0B" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC 98 00 00 80 00 00 0C" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC 05 00 00 80 00 00 0D" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC CE 00 00 80 00 00 0E" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC 08 00 00 80 00 00 0F" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC F0 00 00 80 00 00 10" -i x1C
plscsi -p -v -x  "E7 48 49 54 CC FC 00 00 80 00 00 11" -i x1C

rem Prepare Ramstart set (59E) bit 3 (Set59EBIT3.bin: 00 06 00 00 00 00 00 00)
plscsi -p -v -x  "55 10 00 00 00 00 00 00 08 00 00 00" -o x08 -f Set59EBIT3.bin

rem Ramstart at 0x80000000 (Set59EBIT3.bin: 00 06 00 00 00 00 00 00)
plscsi -p -v -x  "55 10 00 48 4c 00 00 00 08 00 00 00" -o x08 -f Set59EBIT3.bin

rem *****           code upload and firmware flashing          *****
rem *****  01= sec-erease 0x6000+ ; 00=chip-erase + full flash *****

rem set (5A5) bit 4 (send 00 08 00 00 00 00 00 00 09 00)
plscsi -p -v -x  "55 10 00 00 00 00 00 00 0A 00 00 00" -o x0A -f SET5A5BIT4.bin

rem Upload Flashcode
plscsi -p -v -x  "E7 48 49 54 3B 06 00 00 00 00 1B E8" -o x1BE8 -f CodeAt80000000.bin

rem Start Flashcode and Upload New Firmware in Save Mode
plscsi -p -v -x "E7 48 49 54 3B 07 01 00 00 04 00 00" -o x40000 -f firmware.bin

[SuperMario]

Guys,

There are a host of places that the drive performs CALLS to 0x80000000.

I haven't got time to dump them all here, but the lowest level one is here:

ROM:90001435                      loc_90001435:                           ! CODE XREF: CopyATAPI_CDB_to_RAM+5Ej
ROM:90001435                                                              ! CopyATAPI_CDB_to_RAM+65j ...
ROM:90001435 34 B8 05                             movbu   (0x5B8), D0     ! CDB[00]
ROM:90001438 A4                                   cmp     D1, D0          ! is CDB[00] == 0xe7
ROM:90001439 C9 17                                bne     loc_90001450
ROM:9000143B 34 BC 05                             movbu   (0x5BC), D0
ROM:9000143E A0 3B                                cmp     0x3B, D0        ! is CDB[04] == ";"
ROM:90001440 C9 10                                bne     loc_90001450
ROM:90001442 34 BD 05                             movbu   (0x5BD), D0     ! is CDB[05] == 0x07
ROM:90001445 A0 07                                cmp     7, D0
ROM:90001447 C9 09                                bne     loc_90001450
ROM:90001449 CD 1C 01 00 04                       call    CopyRAM_CDB_to_HiRAM_then_call_0x80000000, [], 4
ROM:9000144E CA 17                                bra     locret_90001465

It appears to me to be called via VendorCMD 0xe7, xx, xx, xx, 0x3b, 0x07

It is off the low-level ATAPI handler, so it should work even before all of the basic Inquiry parsing (ie:  before any bit contigencies are set).

BTW:  If you can write to RAM, recall that the stack is in RAM, too... 

SuperMario.

[SuperMario]

Further to my above post, for clarification:

The command above I refer to is not the same one as is used by the high level handler.  I haven't gone down any lower, but my guess is that the above code is called prior to the device being recognised by the initial Inquiry command. 

It is possible that this is the same difference between Mode A & Mode B that SeventhSon was talking about...  Failing that, it could also be called in the drives salvage mode.

Sorry I can not be more helpful, but I'm in Australia and we haven't even had the X360 released here yet, so I'm working blind with dead code disassembly here (atleast for another two weeks or so, until the release date here).

SuperMario.

[SpenZerX]

@SuperMario

the code at ROM:90001435  is not executed. (only if something with the flash is wrong)

I tried to upload a Jmp Instruction to 0x80000000 (jmp-destination 0x9001000) but crash after execution.

Spenzer

[SuperMario]

Spenzer:

Ok, thanks for the confirmation.  It is a salvage mode-only operation.

Here is a list of all the CALLS to 0x80000000

ROM:9002A7C3                      Calls_RAM_0x80000000    ;  Configs ATAPI RX flags then performs CALLS
ROM:900302CF                      Calls_RAM_0x80000000_2 ; Straight CALLS (NB:  No ATAPI configuration)

Here is a list of the CDB copies and then CALLS to 0x80000000:

ROM:90001565                      CopyRAM_CDB_to_HiRAM_then_call_0x80000000
ROM:9002A725                      CopyRAM_CDB_to_HiRAM_then_call_0x80000000_2

Here are the potential routines that utilise one of the above calls as a potential code execution vector:

ROM:90026517 CD AC 42 00 04                       call    Calls_RAM_0x80000000, [], 4
ROM:9002A7B1 CD 12 00 00 04                       call    Calls_RAM_0x80000000, [], 4

ROM:90030218 CD B7 00 00 04                       call    Calls_RAM_0x80000000_2, [], 4

ROM:90001449 CD 1C 01 00 04                       call    CopyRAM_CDB_to_HiRAM_then_call_0x80000000, [], 4

ROM:9002600C CD 19 47 00 04                       call    CopyRAM_CDB_to_HiRAM_then_call_0x80000000_2, [], 4

Hope that helps!

SuperMario.

[SuperMario]

Further to my last post:

You definately want to look into:

ROM:90030218 CD B7 00 00 04                       call    Calls_RAM_0x80000000_2, [], 4

It appears to be part of an existing RPC compliance config.  Check out vendor command bytes "RPCJD4" as this CALLS 0x80000000 does not setup the ATAPI flags and hence shouldn't crash post execution...

SuperMario.

[SpenZerX]

SuperMario,

i think you misunderstand me.

Look at my last post.

Upload a small pice of code an run it is not the problem.

Here is the problem - this is not working:
plscsi -p -v -x  "E7 48 49 54 3B 06 00 00 00 00 1B E8" -o x1BE8 -f CodeAt80000000.bin

There is a test for bit4 at Adress 0x599 in the HIT-Upload routine
ROM0:9002A66E                 btst    0x10, (0x598+1) ! ak40>bit 4 must be 1!
ROM0:9002A673                 bne     loc_9002A690

I dont want to send 0x1BE8 byte by byte Hit commands to upload some code...

Has somebody found the patch function in ida-windows-version??? In dos-ida its at edit menu...

Spenzer

[SuperMario]

Spenzer:

The bit your refer to is only ever set once in the drive, and that is in the low-level ATAPI communication error handler routines at 0x9001c360. 

That routine is to do with ATAPI CRC transmission errors, and the specific region to set it is dependant upon the callback error handler by parsing bit #7 being clear at 0x59e.

So what exactly are you trying to achieve?  Just a mass upload of code into the buffer for execution?

If so, is there any reason that you can you not use WriteBuffer (MMC 0x3b) and write a small relocator stub to rebase your code prior to its execution?

SuperMario.

[SpenZerX]

I uploaded and started the following code to enter the Flash-Fail routine at 0x90001000
(to use the command E7 48 49 54 3B in this part ...)
, but still no success. The drive crashes.

I want to upload the Hitachi flash routine.

Spenzer


RAM1:80000000                 and     0, PSW
RAM1:80000004                 nop
RAM1:80000005                 nop
RAM1:80000006                 mov     0xDFC, A0
RAM1:80000009                 mov     A0, SP
RAM1:8000000B                 mov     0x14, D0       
RAM1:8000000D                 mov     D0, (0xD9A0)
RAM1:80000010                 add     0xFC, SP
RAM1:80000013                 calls   0x900000C5         
RAM1:80000019                 calls   0x900000EE       
RAM1:8000001F                 add     4, SP
RAM1:80000022                 or      0xF00, PSW
RAM1:80000026                 nop
RAM1:80000027                 nop
RAM1:80000028                 jmp     0x90001000
CODE: FA FC 00 00 CB CB 24 FC-0D F2 F0 80 14 01 A0 D9
CODE: F8 FE FC FC FF B2 00 00-10 FC FF D5 00 00 10 F8
CODE: FE 04 FA FD 00 0F CB CB-DC D8 0F 00 10

[SeventhSon]

FYI:

I had a request to port a couple of my tools over to win32. They're available on my site if anybody wants them.

pp - A program that peeks and pokes bytes in MN103 address space
execcode - A program that force the drive to execute arbitrary code
memdump - A program that dumps chunks of the MN103 address space

These ports are not tested at all properly. Using windows for any significant length of time is not good for my blood pressure.

http://www.kev.nu/360/dvd.html#update_15_03_06

Hope they're useful.