How liteon eeprom and firmware work?

how do liteon eeprom and firmware work

there is an eeprom, that contains drive identification (drive model), rpc counts, region, and a flashrom that contains the software that the drive need to know how to write.

1- what happens when upgrading to a different non-OP model firmware? drive will boot, eeprom will tell firmware that it’s a wrong model firmware, and flash orange? or the firmware will make a check in the eeprom to see if it’s the same model?

2- when the omnipatcher enables crossflash, what will it do? makes firmware not check for the eeprom or check for another eeprom that make it think it’s the correct drive?

4- when the firmware is corrupted for a bad flash, if the bootcode is there, then windows can detect the drive (but will not work), to allow another flashing, if not, the only solution is mtk flash in dos which will rewrite complete firmware (bootcode+firmware)?

5- when the eeprom is corrupted, what will happen? will bios/windows detect the drive? can it be reovered in some way?

6- when changing rpc to region free or resetting count, it modifies the eeprom in what way? change hex values, checksums?

i made this post because from reading in this forum i learned how firmware and crossflashing work, but still nothing about the eeprom…

It looks like it’s warning time again :slight_smile:

:cop:Keep your hands off any eeprom modifications. Alot of liteon owners have flashed the wrong drive (e.g. a liteon cd burner instead of the dvd burner) or have lost their original eeprom backup and were left with a corrupted drive during the 411@811 hype. :cop:

The firmware calculates a checksum made of bytes stored in the (software) write protected eeprom area and compares the result with the checksum result stored in the writable area of the eeprom. If this compare fails, the drive led flashes orange and the drive will not detect any disks. Different firmware families use sightly modified checksum algorithms, so e.g. a 812 checksum differs from a 832 checksum.

2- when the omnipatcher enables crossflash, what will it do? makes firmware not check for the eeprom or check for another eeprom that make it think it’s the correct drive?
The check is disabled.

4- when the firmware is corrupted for a bad flash, if the bootcode is there, then windows can detect the drive (but will not work), to allow another flashing, if not, the only solution is mtk flash in dos which will rewrite complete firmware (bootcode+firmware)?
Exactly.

5- when the eeprom is corrupted, what will happen? will bios/windows detect the drive? can it be reovered in some way?

Windows will detect the drive, the eeprom can be restored if a backup is available. Without a backup you can lose the calibration settings, which will make your drive worthless.

6- when changing rpc to region free or resetting count, it modifies the eeprom in what way? change hex values, checksums?

It changes some values. The checksum is not touched. It is not a checksum over all eeprom values, so there is no need to update the checksum.

Only those with the know how should attempt the eeprom mod. Others should not. When doing any kind of flashing especialy with your eeprom you should always have a backup. If you do not know to backup then you should stop and continue to mod your drives or anything else no more. Never attempt anything untill you have fully researched the process and the risks that come with it. Remeber that any kind of mod has its risks because you will not be running the equipment according to the specs that it was intended for. Take caution because flashing a different drive are mistakes that are made by not researching and double checking what you are doing.

i didn’t understand well this: are there 2 types of eeprom (or 1 eeprom and 1 rom), the firmware on boot calculate the checksum for both and compare?

also the checksum is only one algorithm the value produced by running it on some data varry, not the algorithm itself.

from the first day i got the drive i backed up everything (eeprom and original flash) in multiple copies…

so from what i read here and all over the forum, a liteon drive can be revived in worst cases, that is with firmware corruption and eeprom corruption (if backups exist), is this true?

to be on the safe side, i made another backup copy of the eeprom today, and compared to the one i made 3 days ago, THEY ARE DIFFERENT, and not 1 or 2 byte, but 60 bytes are different.
the only thing i made was update to the latest US0Q firmware using the stock updater from liteon website…
and maybe, a change in the rpc region (by windvd or windows, not LtnRPC)

do firmware updates change eeprom contents.

Please make use of the search function. This has been discussed many times before. The EEPROM contains a lot of information. Calibration data (should never change), RPC information (should change), a 16-byte randomly-generated security key with a checksum of this key (should not change), a rotating burn counter, a rotating disc disc recognition counter (3S only), and a debug log of the previous 4 burns (this is the 60+ bytes you’re talking about), and other things that not much is known about (may or may not change). Firmware flashes do NOT change anything.

Once again, the end-user should never have to even touch the EEPROM! Just pretend that it doesn’t exist and let it do its thing. Don’t mess with it, and it won’t mess with you.