flasher can't read or write to drive

[CCF100]

Attempting to backup drive firmware returns this:

[root@caleb-gaming-rig-archlinux flasher_Linux32_11072010_1004AM]# ./flasher -d /dev/sr0 -m -l firmware_backup.bin Devilsclaw's LG Renesas Drive Utility cmd_drive: Opening Drive: /dev/sr0. cmd_dumpmain: Starting dumping process get_firminfo_drive: failed to find pattern cmd_dumpmain: failed to get firmware info

Attempting to flash firmware returns this:

`[root@caleb-gaming-rig-archlinux flasher_Linux32_11072010_1004AM]# ./flasher -d /dev/sr0 -f HL-DT-ST-BD-RE_WH16NS60-1.01-NM00100-211711202000.bin Devilsclaw's LG Renesas Drive Utility cmd_drive: Opening Drive: /dev/sr0. cmd_flashfirm: Flashing process started

firm_flasher: Drive should be flashing its light. firm_flasher: This indicates its flashing its self. firm_flasher: This can take a while, Please be patiant. firm_flasher: Failed to write at 0x00000000 firm_flasher: your drive should still be fine. cmd_flashfirm: Flashing process failed`

[RyanDawkins]

+1 I get the same issue.

[fenugrec]

It looks like some drives (including my GSA-H62N) have a slightly different "firmware header" that isn't recognized by flasher. Without seeing the original firmware that was used to develop this, I'm not sure what pattern to suggest. Some info :

/************* lg_renesas.c ****************
* these are the search patterns. Note, a 0xFF here means "match all" */
char core_pat[] =
  { 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00,
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 'C', 'O', 'R', 'E', 0x20,
  0x20, 0x20, 0x20,
  'R', 'E', 'V', 0x20, 'L', 'V', 'L', 0x20, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00,
  'R', 'O', 'M', 0x20, 'R', 'E', 'V', 0x20, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00,
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
};

char main_pat[] =
  { 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00,
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 'M', 'A', 'I', 'N', 0x20,
  0x20, 0x20, 0x20,
  'R', 'E', 'V', 0x20, 'L', 'V', 'L', 0x20, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
  0x00, 0x00, 0x00,
  'R', 'O', 'M', 0x20, 'R', 'E', 'V', 0x20, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00,
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
};

You can dump raw memory from the disk with something like

$> flasher -d /dev/sr0 -l test.bin 5 0x0000  0x408000
$> flasher -d /dev/sr0 -l upper.bin 5 0x410000 0x1b0000

where the arguments are <filename> <location> <start_addr> <size> , with <location>=5 to read from memory.

For some reason, my disk can't be read between 0x408000-0x410000. This was a bit of a problem since it causes the program to abort at the first failure, yet the "main" ROM is after that mem hole.

So, I got a "broken" header @ 0x403A20

03 24 01 20 6D 76 01 30 6D 73 56 70 47 53 41 2D ............GSA-
48 36 30 4C 00 4D 41 49 4E 20 20 20 20 00 43 4F H60L.MAIN     CO
52 45 20 20 20 20 00 52 45 56 20 4C 56 4C 20 00 RE    .REV LVL .
52 4F 4D 20 52 45 56 20 00 00 00 00 00 00 00 00 ROM REV ........
40 00 00 00 60 00 00 00                         ........

The fields are slightly off, and the last 32-bit values (4000 0000 and 60 00 00 00) should
relate to firmware_start and _size, but don't make sense.

Instead, later @ 0x42ba1c
FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
47 53 41 2D 48 36 30 4C 43 4F 52 45 20 20 20 20 GSA-H60LCORE    
52 45 56 20 4C 56 4C 20 00 00 00 00 00 00 00 00 REV LVL ........
52 4F 4D 20 52 45 56 20 00 00 00 00 00 00 00 00 ROM REV ........
00 40 00 00 FF FF FF FF FF FF FF FF 00 00 00 00
00 00 00 00 00 00 00 00 47 53 41 2D 48 36 30 4C ........GSA-H60L
4D 41 49 4E 20 20 20 20 52 45 56 20 4C 56 4C 20 MAIN    REV LVL 
FF FF FF FF 00 00 00 00 52 4F 4D 20 52 45 56 20 ........ROM REV 
00 00 00 00 00 00 00 00 00 41 00 00 FF FF FF FF

Here, it fits much better with the headers on lg_renesas.c, and the firmware_start field
makes more sense (0x410000).
Not sure why in both those CORE and MAIN headers the firmware_size field is 0xFFFF FFFF ?

****************
Now I compare to a firmware update I haven't flashed yet but "unpacked" with this software :
;;;;;; CORE.bin : firm_start @ 0x400000, size = 0x6000
0000  40 3B 00 00 00 00 00 00  00 00 00 00 00 00 00 00  @;..............
0010  47 53 41 2D 48 36 30 4C  43 4F 52 45 20 20 20 20  GSA-H60LCORE    
0020  52 45 56 20 4C 56 4C 20  00 00 00 00 00 00 00 00  REV LVL ........
0030  52 4F 4D 20 52 45 56 20  00 00 00 00 00 00 00 00  ROM REV ........
0040  00 40 00 00 00 00 60 00                           .@....
;;;;;; MAIN.bin : firm_start @ 0x410000, size = 0x1b0000
00000000  2B A7 00 00 00 00 00 00  00 00 00 00 00 00 00 00  +...............
00000010  47 53 41 2D 48 36 30 4C  4D 41 49 4E 20 20 20 20  GSA-H60LMAIN    
00000020  52 45 56 20 4C 56 4C 20  43 4C 30 31 00 00 00 00  REV LVL CL01....
00000030  52 4F 4D 20 52 45 56 20  00 00 00 00 00 00 00 00  ROM REV ........
00000040  00 41 00 00 00 1B 00 00                           .A......

There, everything makes a lot more sense and fits perfectly with the program's notion of headers.

@christopherkobayashi , I can't post issues on your fork, any thoughts on this ?

btw, the code is extremely fragile regarding int sizes, and endian conversions. doing a memcpy() into a "long int" is just evil.

[devilsclaw]

Yeah, I wrote this back when I was still on only a 32bit system and did not know how to make platform compatible code. It might need to be re-written from the ground up to make it work better on my systems