ATAPI CMDS supported in panic mode:
E7h VENDOR SPECIFIC
E7 XX XX XX 3B 06 XX XX XX XX LL LL (copy code to the 0x80000000 region)
LL LL = PAYLOAD LENGTH
the payload must come with his checksum (sum16 LE) in the last 2 bytes.
E7 XX XX XX 3B 07 P0 P1 P2 P3 P4 P5 (exec code @0x80000000 region)
P0...P5 = customs parameters
12 XX XX XX LL
LL length of data expected (upto 96 bytes)
I want make test about this function, upload and exec can help to flash the drive.
>the questions are:
>does the birdy mod to libata-core works can perform flawlessly a "ATAPI INQUIRY" CMD?
>does that mod disable the automatic "REQUEST SENSE" after ATAPI CMDs?
This mod is very easy : If is a drive physicaly present than linux make a scsi entry in /dev/ (sda .. sdb or another)
But than the kernel make nothing else, no inquiry, nothing
In this way the kernel give us only a way to send command to the drive.
>If the response to that 2 question is positive, I don't see any problem in repair/upgrade/downgrade a firm (I've done it succefully in a "panic mode" 8164B).
>about put the drive in panic mode using a simple JUMP to 90001000 wont work because the MCU state is really unknown when you jump to that location, to figure how >to "softreset" into panic mode, a deep look at 0x40000000 can give us some clues (but seems a very hard task).
I have try at first to copy the boot sequence from $90000000 to $9000011A because it reset all registry and the PSW. Without sucess.
But it's possible to make a soft reset by put bit 1 from register D900.
Than the idee is for 'no bricked drive' to reflash the boot sequence at $90000000 with the tray tweak (closed=recovery) than reset the drive.
>a way to force the drive to get in panic mode can be putting ground to the higher address line to make the checksum test to fail without corrupting the flash, but I really don't know how to do this electrically safe.
We must make that for bricked drive, because all flasher set the checksum to 0. That a problem, because the firmware jmp in 'normal mode' and than freeze.
But the checksum is a high memory value > $30000 and the chesum test and recovery mode at low value <$2000.
30000 = 110000000000000000 than if we put only one adress bit low (connect to gnd) the checksum is read an another memory adress and fail.
I have read in this thread that bricked drive fail in bios, the reason is that the drive is not in 'recovery mode' (because the checksum is set to 0).
The bios wait for only for inquiry, this function work in real recovery mode.
>the other way can be patching the code when it calculate the checksum and check for tray status to select "panic mode", reading birdy's documentation on his hack seems to be 0xD930 bit 1, and that guide me to another question, has anybody figured the MN103 internal registers??
I have 'virtually bricked' my drive with this tweak ;-)
code at $90000090
$90: movbu (D930),D0 // 34 30 D9
$93: btst 1,D0 // F8 EC 01
$96: bne $9000009C // C9 07
$98: jmp $90001000 // DC 68 0F 00 00
$9C: jmp $90006040 // DC 14 5F 00 00
>I only know at the moment:
0xD930: port XX input data register
bit 1: tray status
0xD990: port YY output data register
bit 8: LED (on 8163/4B)
0xDC00-0xDCFF: timers related registers