Loading image 1 from memory at 0xD0400000
O
BL_IMAGE_TYPE_BIN
X
XXXXXOOOOXXOOOOOOOOXOXOXOOOOOOOXOOXOXOOOOXXOOOOOOOOOXOOOOXOXOOXXXOOOXOXXXXOOXXOXOOOOOXOOXXXXOXXOOOXOOXXOXXOXOOOXOOXOOXXOOOXOOOOXOXOOOOOXOOOXOOXOXXOXOXOXOXXXXXXOXXXXXOOOOXOOXOOXOOOOXOOOOXXOXOOOOOOOXOOOXOOXOOOOXX
OOOOOXOOXOOXOXOOOOOOOOOXOOOOXOOOOOOXOXOOOOXXOOOOOOOXOOOOXOOXOOOXOOOXOOXXOOXOOXOXXOXOOXOXOXOXOOOXXXOOXOXXOOOXXXXOXOOXOXOOOOXOOOOXOOOXOOXOOXOOOXOOOOOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOXXXXXXXXXXXXXXXOXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOIncorrect Data 0 EccResult: 566556 EccError: ff3c3c EccRead: a9596a
EBOOT_ReadFlash failed offset 204eb88
EBOOT_ReadFlash failed location d2054000
ODeCompressFlash: CeCompressDecode() failed
CeDecompressFlashBlock failed
****** Data record 146 corrupted, ABORT!!! ******
File Name | Release Date | Instrument Software Version |
4000XSeries.7.30.2019051435.ksx | 29 May 2019 | 7.30.2019051435 |
4000XSeries.7.20.2017102615.ksx | 26 Oct 2017 | 7.20.20171026 |
4000XSeries.7.11.2017061227.ksx | 12 Jun 2017 | 7.11.20170612 |
4000XSeries.7.10.2017042903.ksx | 29 Apr 2017 | 7.10.20170429 |
4000XSeries.07.10.2017041132.ksx | 11 Apr 2017 | 7.10 |
4000XSeries.04.08.2016071801.agx | 27 Jul 2016 | 4.08 |
4000XSeries.04.07.2016040802.agx | 20 Apr 2016 | 4.07 |
4000XSeries04.05.2015051200.agx | 27 May 2015 | 4.06 |
4000XSeries04.05.2015021000.agx | 16 Feb 2015 | 4.05 |
4000XSeries.04.00.2014101303.agx | 01 Nov 2014 | 4.00 |
4000XSeries03.22.2014052101.agx | 21 May 2014 | 03.22.2014052101 |
4000XSeries.03.21.20140110001.agx | 21 Jan 2014 | 03.21.20140110001 |
4000XSeries.03.20.2013082300.agx | 03 Sep 2013 | 03.20.2013082300 |
4000XSeries.03.12.2013041700.agx | 23 Apr 2013 | 03.12.2013041700 |
4000XSeries.03.11.2013030100.agx | 01 Mar 2013 | 03.11.2013030100 |
4000XSeries.03.10.2013020700.agx | 12 Feb 2013 | 03.10.2013020700 |
4000XSeries.03.01.20121212001.agx | 12 Dec 2012 | 03.01.20121212001 |
4000XSeries.03.00.201209XXXX.agx | ?? Sep 2012 | 3.00 |
With a 2000/3000 the firmware you transfer over does need to be the same version on the scope or very close or it won't boot all the way(or at all). Is the scope Agilent or Keysight branded, you can use that to give you a hint of a version to try. I have no 4000x series firmware myself.
I still am wondering about the image you're using, I don't think it should be double the size.
Yeah the image size is about double that of the 2000/3000 series. But the instrument must have enough RAM to hold the transferred image, right? I'll see if I can split the image in two and do two transfers.
Yeah the image size is about double that of the 2000/3000 series. But the instrument must have enough RAM to hold the transferred image, right? I'll see if I can split the image in two and do two transfers.
This is a complex recovery. You need to have more assurances in order to succeed. The equipment has 128 MBytes RAM as you can see in your boot log.
Aren't you overwriting the prog that is running, when loading into RAM?
Is RAM all OK?
First step, I suggest you do a methodic mapping of your RAM space in order to understand if your loading space is valid. Take a 10 MB chunk and load it at offset 0, 10 MB, 20 MB, 30 MB, 40 MB, 50 MB, etc... and see where it hangs.
Can you stop the bootloader? That would be great. That could allow us to dump NAND.
Can you dump the bootloader (NOR Flash 512kB)?
I have all firmware version starting with Keysight branding, thus 4.00 ++
I checked the size of nk.bin of all firmware versions, unfortunately no match so you do not have to bother with 4.xx versions:
4.00: 80922891 byte
4.01-4.04: no such, regarding the release notes
4.05: 81539207 byte
4.06: 81413855 byte
4.07: 79718035 byte
4.08: 81031923 byte
7.10 and newer are all way larger
Unfortunately I do not have any version below 4.00 available. There once was a helpful HP/Agilent group on Yahoo where you could ask for such help. You might try it there if the group still exists. Possibly it moved away from Yahoo to somewhere else ... i have some vague memory about this.
I'm going to check in as well and see what the internal folks have to say.
The second is after the "PBOOT" primary boot loader image, which appears to be a Windows CE 6.0 standard bootloader. From there, I have four choices (again, see log). One very interesting one is an option to boot over ethernet. I tried this but the scope is waiting for some response from a host machine over the network that appears to be related to a "Windows CE 6.0 Platform Builder" tool that I need to see if I can get a copy of.
Yes, I can stop the bootloader.
Yes, I can stop the bootloader.
Those are good news. Go into NAND susbsytem and see what commands are available.
Attach them here.
The second is after the "PBOOT" primary boot loader image, which appears to be a Windows CE 6.0 standard bootloader. From there, I have four choices (again, see log). One very interesting one is an option to boot over ethernet. I tried this but the scope is waiting for some response from a host machine over the network that appears to be related to a "Windows CE 6.0 Platform Builder" tool that I need to see if I can get a copy of.
I compiled a tool that you can use on a windows machine many moons ago: https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg1022267/#msg1022267 (https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg1022267/#msg1022267)
The story behind it: https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg1022248/#msg1022248 (https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg1022248/#msg1022248)
All: Daniel has reached out to me and it's looking like the scope probably does have the known NAND corruption issue, and if so, it will be repaired by Keysight at no cost. I can't turn up an offer like that so I'm ending my repair attempt of it.Congratulation. It looks like everything's gonna turn out just fine for you.
All: Daniel has reached out to me and it's looking like the scope probably does have the known NAND corruption issue, and if so, it will be repaired by Keysight at no cost. I can't turn up an offer like that so I'm ending my repair attempt of it.Congratulation. It looks like everything's gonna turn out just fine for you.
However, I'm surprised the Keysight Repair Center turned down the free repair without even seeing the unit. At least they should have offered to check it. Did Daniel have anything to say about this?
All: Daniel has reached out to me and it's looking like the scope probably does have the known NAND corruption issue, and if so, it will be repaired by Keysight at no cost. I can't turn up an offer like that so I'm ending my repair attempt of it.
If the flash is fully erased you will lose factory data - cal data, serial #, licenses etc.
I know with other instruments I have seen they do not have the ability to encrypt the model/serial, only decrypt it. There is a tool which encrypts the data and sends it via SCPI.
The command format is often something like "SecureDataTool_<Client>.exe Initialize-ModelNumber" and "SecureDataTool_<Client>.exe Initialize-SerialNumber <SerialNumber>".
When the 2000/3000a series first came out there was a "leak" with the firmware update which included the tool to generate a model/serial #. You had to extract the binary and run it on the scope itself, but it was there. You could use the keys the binary contained to generate your own signed license files. After the leak Keysight changed the private key so it only worked with really old scopes. Being as you have have no keys at all it is certainly worth having a look at. The firmware update was version 1.10 - released before the 4000 series even existed I am sure.
For what it's worth, I had DSO-X3054A with the same problem. Mine has recurring NAND corruption issue even after I fixed it, I have corrupt NAND blocks being reloaded on almost every startup (visible in the serial console). Originally I was on 2.35 firmware which bricks when corrupt, it would become corrupt after being off for only a few minutes.hi,jake111
It was stuck at the infinitely looping lights on the front panel even after using bootp command to load nk.bin from my computer and then using the NAND WRITE to write it to the NAND (this could also be accomplished by using ymodem transfer thru serial but MUCH slower). I suddenly realized that this message about failing to program the FPGA was important... So after programming NAND (which I had to do every few boots because it would become corrupt again) I then transferred FPGA3000A.bin (for 3000 series) into memory and programmed the FPGA with it, then without rebooting, booted with the boot command. Viola! My machine then proceeded to boot from my 2.35 USB boot disk, and I then hastily upgraded it to 2.50.
Now it boots reliably but on almost every boot it notes corrupt NAND blocks and rewrites them. I think my NAND is not long for this world, but thought I would mention this trick in case someone else gets stuck at the infinitely looping lights and can't figure out why. It seems that the FPGA has to be programmed in order for the infiniivision launcher to proceed far enough to get the machine to boot from USB. I assume that the FPGA data must normally be stored in NAND and this is why mine lost it. NAND alzheimers is a terrible thing.
For what it's worth, I had DSO-X3054A with the same problem. Mine has recurring NAND corruption issue even after I fixed it, I have corrupt NAND blocks being reloaded on almost every startup (visible in the serial console). Originally I was on 2.35 firmware which bricks when corrupt, it would become corrupt after being off for only a few minutes.hi,jake111
It was stuck at the infinitely looping lights on the front panel even after using bootp command to load nk.bin from my computer and then using the NAND WRITE to write it to the NAND (this could also be accomplished by using ymodem transfer thru serial but MUCH slower). I suddenly realized that this message about failing to program the FPGA was important... So after programming NAND (which I had to do every few boots because it would become corrupt again) I then transferred FPGA3000A.bin (for 3000 series) into memory and programmed the FPGA with it, then without rebooting, booted with the boot command. Viola! My machine then proceeded to boot from my 2.35 USB boot disk, and I then hastily upgraded it to 2.50.
Now it boots reliably but on almost every boot it notes corrupt NAND blocks and rewrites them. I think my NAND is not long for this world, but thought I would mention this trick in case someone else gets stuck at the infinitely looping lights and can't figure out why. It seems that the FPGA has to be programmed in order for the infiniivision launcher to proceed far enough to get the machine to boot from USB. I assume that the FPGA data must normally be stored in NAND and this is why mine lost it. NAND alzheimers is a terrible thing.
how did you program the FPGA in P500?
Hello, I am a user of DSO 4104A.
I also encountered the Boot NAND error, and when I tried to download the bootloader, it stopped at around 65-70% during the upload.
Have you resolved this issue?
I have the same issue as you. I have obtained firmware version 4.08