@TeddyRaspin:
It might be (perhaps) that the EEPROM Data Mover is not always doing the proper thing in all cases (only an assumption). On one firmware dump import checksum from EEPROM Data Mover matches to the other method via "dd".
On the other firmware, it doesn't.
See more further below especially screenshots and the Code:
I have two BH16NS55.
The 1st BH16NS55 (Retail) came with FW 1.02
The 2nd BH16NS55 (Bulk) came preinstalled with FW 1.03.
At first I made a dump of both drives (Bulk and Retail) each with Dosflashed 1.7 you provided.
1st BH16NS55 (Retail): LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin
2nd BH16NS55 (Bulk): LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin
Then I imported the data from the dump to to the correspondending SAME firmware version of the clean firmware.
I had some strange beavior that the EEPROM data mover is not always doing the same thing in all cases compared using "dd".
The idea was a try to find out if the EEPROM data mover and/or "dd" hexediting can reproduce original firmware dump from clean firmware and importing parts from the Original dump.
,by using same corresponding firmware version of clean firmware to the same matching SAME fw-number of the Original dumps.
I made the importing data-hex-editing through "dd" (find it easier) on clean firmware
I also used the EEPROM data mover for second attempt on a clean firmware
It might be (perhaps) that the EEPROM Data Mover is not always doing the same thing in all cases.
See screenshots:
But I'm pretty sure I made all correct, and "dd" starts counting up from 0 like the hex-editor.
0x1E8000 = 1998848 dez
0x1E84FF = 2000127 dez
0x1E9000 => 2002944dez
=> 0x1E84FF - 0x1E8000 = 0x4FF (Delta) =1279dez
=> 2000127dez - 1998848dez=1279dez
=>Because including/counting in 0x1E8000 =>1279+1 =>1280 Bytes
So the first import range from 0x1E8000 (including) to 0x1E84FF (including) that should be 1280 Bytes:
----
LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.02 (Retail):
LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin:
For testing purposes I have used 1.02 BH16NS55 clean firmware, and importing 1.02 firmware dosflash dump into BH16NS55 1.02 clean firmware
Code:
cp -a ../forum.cdrinfo.pl_dosflash-v2-0-patched-support-bh16ns40-bh16ns55-drives-96930/Clean_NS50_compatible_firmwares/flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin ./dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin
sync
dd if=LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin bs=1 skip=1998848 count=1280 of=dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin seek=1998848 conv=notrunc
dd if=LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin bs=1 skip=2002944 of=dd_hexediting_flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin seek=2002944 conv=notrunc
sha256sum dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin Data_Mover_1.02_Original-dump-Dsflsh_1.7_to_Clean-Firmware_BH16NS55_1.02.bin LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin
3e54efd7c8138366a1cc583d86fc524cd94675f651f7eebf24ced752c1e2ce40 dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin
4a94bc1e3f87daf217af849d214e901927481f131daa212b168f4e26817083d4 Data_Mover_1.02_Original-dump-Dsflsh_1.7_to_Clean-Firmware_BH16NS55_1.02.bin
9cfac42ebaac32cb0e575a014d9d21c7e3a1d560a430598e30b56628531949ce LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin
Result: different checksums all to each other (from "dd" and Data Mover different, and also different to Original Dosflash dump)
----
LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03 (Bulk):
LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin:
(For testing purposes I have used 1.03 BH16NS55 clean firmware, and importing 1.03 firmware Dosflash dump into BH16NS55 1.03 clean firmware
Result: Same checksums all to each other ("dd" and Data Mover , and even to the Original Dosflash dump)
Code:
cp -a ../forum.cdrinfo.pl_dosflash-v2-0-patched-support-bh16ns40-bh16ns55-drives-96930/Clean_NS50_compatible_firmwares/flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin ./dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin
sync
dd if=LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin bs=1 skip=1998848 count=1280 of=dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin seek=1998848 conv=notrunc
dd if=LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin bs=1 skip=2002944 of=dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin seek=2002944 conv=notrunc
sha256sum dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin Data_Mover_1.03_Original-dump-Dsflsh_1.7_to_Clean-Firmware_BH16NS55_1.03.bin LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin
82e60c0d0bd6010b13364a86097041b1b57a21dc8b152ff73ee1abd38e228f22 dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin
82e60c0d0bd6010b13364a86097041b1b57a21dc8b152ff73ee1abd38e228f22 Data_Mover_1.03_Original-dump-Dsflsh_1.7_to_Clean-Firmware_BH16NS55_1.03.bin
82e60c0d0bd6010b13364a86097041b1b57a21dc8b152ff73ee1abd38e228f22 LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin
Result: All the same checksums , (from "dd" and Data Mover same, and even the same to Original Dosflash dump)
I can't explain it 100% why on one matches, on the other not. I used same "dd" parameters (except different clean firmware number using, but same model)
Maybe I misenterpreted the hex-range range you provided slightly, so that the last number of the range maybe should not be included. I was not entirely sure, but using 0x1E8000 from start to including end of 0x1E84FF =4FF+1 =1280 Bytes appears rather plasible as instruction as 0x1E8000 from start to end of 0x1E84F
E (=the end before right on the beginning of 0x1E84F
F =1279 Bytes)
So maybe on first firmware one byte too much on the first range didn't take any effect, because the Byte of clean firmware 1.03 in 1st range anyway has same value.
Or maybe the clean firmware differs a bit (maybe from a Bulk drive). The checksum where it doesn't match was using Retail drive.
@TeddyRapsin. Maybe you have an idea?
I Hope all this pictures of exact documentation about what was done, do help and not confuse people.
I was busy 30-40 hours in that unskilled testing through night and preparing all the documentation.
Can't attach any dump in this post (too many pictures)
This issue wonders and makes too busy, and I can't sleep so well without finding out the reason.
I'll post the dumps in the next reply, in case you should be interested if you want to try to reproduce this issue.