LiteON DH20AH4 - QP5B PC drive DVDRW All Write Lightscribe

[Meat Plow]

Well the All Write was not alright. Would not load factory CDDA or
DVD-RAM. Latest QP5B firmware. Would write and play DVD -R +R R/W
and lightscribe just fine. Since this drive is only a couple months
old it left me scratching my head. I had an epiphany, reload the
firmware even though the utility complained I'm loading the same
version. Make backup first, reload QP5B. Reboot and VOILA!
the All Write is alright!

No explanation other than corrupted firmware but I have done nothing
to corrupt it. I'm not a firmware hacker nor do I bother with third
party utilities other than to backup existing firmware.

Just an FYI

 

[Franc Zabkar]

On Fri, 13 Nov 2009 12:58:17 -0500, Meat Plow <meat@petitmorte.net>
put finger to keyboard and composed:

Well the All Write was not alright. Would not load factory CDDA or
DVD-RAM. Latest QP5B firmware. Would write and play DVD -R +R R/W
and lightscribe just fine. Since this drive is only a couple months
old it left me scratching my head. I had an epiphany, reload the
firmware even though the utility complained I'm loading the same
version. Make backup first, reload QP5B. Reboot and VOILA!
the All Write is alright!

No explanation other than corrupted firmware but I have done nothing
to corrupt it. I'm not a firmware hacker nor do I bother with third
party utilities other than to backup existing firmware.

Just an FYI

I would have thought that corrupted firmware (bad checksum) would not
allow the drive to pass its self test.

Can you compare the backup with the downloaded version?

In a Windows DOS box you would type ...

fc /b backup_fw.bin QP5B.bin

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Meat Plow]

On Sat, 14 Nov 2009 08:28:33 +1100, Franc Zabkar
<fzabkar@iinternode.on.net>wrote:

On Fri, 13 Nov 2009 12:58:17 -0500, Meat Plow <meat@petitmorte.net
put finger to keyboard and composed:

Well the All Write was not alright. Would not load factory CDDA or
DVD-RAM. Latest QP5B firmware. Would write and play DVD -R +R R/W
and lightscribe just fine. Since this drive is only a couple months
old it left me scratching my head. I had an epiphany, reload the
firmware even though the utility complained I'm loading the same
version. Make backup first, reload QP5B. Reboot and VOILA!
the All Write is alright!

No explanation other than corrupted firmware but I have done nothing
to corrupt it. I'm not a firmware hacker nor do I bother with third
party utilities other than to backup existing firmware.

Just an FYI

I would have thought that corrupted firmware (bad checksum) would not
allow the drive to pass its self test.

The firmware can be hacked to provide functions it would not normally
support so the fault may lie in that area and not necessarily cause a
self test failure.

Can you compare the backup with the downloaded version?

In a Windows DOS box you would type ...

fc /b backup_fw.bin QP5B.bin

- Franc Zabkar

The firmware is loaded by its own imbedded loader in (QP5B.exe) so I
have no new bin to compare. Best I can do is backup the current
firmware and compare it to the one in question.

 

[Franc Zabkar]

On Sat, 14 Nov 2009 11:01:28 -0500, Meat Plow <meat@petitmorte.net>
put finger to keyboard and composed:

On Sat, 14 Nov 2009 08:28:33 +1100, Franc Zabkar
fzabkar@iinternode.on.net>wrote:

I would have thought that corrupted firmware (bad checksum) would not
allow the drive to pass its self test.

The firmware can be hacked to provide functions it would not normally
support so the fault may lie in that area and not necessarily cause a
self test failure.

I have hacked the firmware in my old Ricoh 2x CD burner, and in an old
Award 386 motherboard. Both devices required that the checksum be
recomputed. On my first attempt with the Award BIOS hack, the POST
complained of a BIOS (not CMOS) checksum failure. Therefore it appears
that one of the first tests that a uP does after it powers up is to
verify the integrity of its firmware. This was always the case with
the minicomputers and periperals that I used to service. I suspect
that it still applies to most, if not all, uP based gear.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Meat Plow]

On Sun, 15 Nov 2009 20:27:56 +1100, Franc Zabkar
<fzabkar@iinternode.on.net>wrote:

On Sat, 14 Nov 2009 11:01:28 -0500, Meat Plow <meat@petitmorte.net
put finger to keyboard and composed:

On Sat, 14 Nov 2009 08:28:33 +1100, Franc Zabkar
fzabkar@iinternode.on.net>wrote:

I would have thought that corrupted firmware (bad checksum) would not
allow the drive to pass its self test.

The firmware can be hacked to provide functions it would not normally
support so the fault may lie in that area and not necessarily cause a
self test failure.

I have hacked the firmware in my old Ricoh 2x CD burner, and in an old
Award 386 motherboard. Both devices required that the checksum be
recomputed. On my first attempt with the Award BIOS hack, the POST
complained of a BIOS (not CMOS) checksum failure. Therefore it appears
that one of the first tests that a uP does after it powers up is to
verify the integrity of its firmware. This was always the case with
the minicomputers and periperals that I used to service. I suspect
that it still applies to most, if not all, uP based gear.

- Franc Zabkar

I understand that a unique checksum is generated each time bits in the
firmware code are changed and they must match but in this case that
was overlooked in some unexplainable manner. All I did was reload the
same bin I did several months ago and the device now functioned in
every mode it advertises not just DVD and Lightscribe like I had been
using it for.

I have another device, a Pioneer DVD-RW 108 (circa 2005) 16X16 that I
use for CDDA and out of curiosity put a CD in the LiteOn finding out
it could not even initialize the read and just ejected the disc. I've
used the LiteOn for CDDA prior to and after adding the Pioneer with
the same bin aboard. I'll just chalk this up to one of life's little
unsolved mysteries.