EEVblog > EEVblog Specific

EEVblog #978 - Keysight 1000X Hacking

<< < (197/206) > >>

Bud:
To use the StupidBear LAN board for firmware upload purpose you need to first update the U701. But updating U701  will give you access to Ymodem and uploading via the serial port, so LAN access becomes a moot point, why bother.

To update U701 you have to change bootdelay (or uboot_delay, or boot_delay, cant remember the exact name) variable in Uboot section from 0 to 1...3 seconds. This will allow to interrupt boot process by pressing spacebar and access firmware uploading options. But you also MUST recalculate and update the checksums in the Uboot header and entire Uboot block after changing the delay. Unless you already know where to find the checksum bytes you have to study Uboot structure. Failure to update the checksums will brick your scope so this is a vital thing to do. Do not modify U701 if you do not understand what you are doing.

Bud:
The safiest and easy option would be to replace U701 with a new blank chip from Digikey and use STM Flash Utility to upload the firmware via USB. What happens is when you turn on the scope it will try use Uboot in NOR U701 and if it can't find it (which will be the case if U701 is empty), the scope will switch to boot from USB (the USB connector at the back). This is where STM Flash utility comes into play. You run the utility and it gives you access to the address space. You then configure it to upload the firmware as either in chunks (say only U701 part) or as a single block for everything.

This method was described either in this thread or in 2000/3000 thread, i cant remember where- you will have to comb the threads to search for it either page by page or using kewords like STM Flash (or flashing) utility within those threads. The utility itself used to be available from STM web site, not sure if it still is.

candrian:
Any one found a hack for the DSOX1202 ?

TT-392:

--- Quote from: Bud on November 19, 2023, 06:02:39 pm ---The safiest and easy option would be to replace U701 with a new blank chip from Digikey and use STM Flash Utility to upload the firmware via USB. What happens is when you turn on the scope it will try use Uboot in NOR U701 and if it can't find it (which will be the case if U701 is empty), the scope will switch to boot from USB (the USB connector at the back). This is where STM Flash utility comes into play. You run the utility and it gives you access to the address space. You then configure it to upload the firmware as either in chunks (say only U701 part) or as a single block for everything.

This method was described either in this thread or in 2000/3000 thread, i cant remember where- you will have to comb the threads to search for it either page by page or using kewords like STM Flash (or flashing) utility within those threads. The utility itself used to be available from STM web site, not sure if it still is.

--- End quote ---

So I did this, and managed to use the STM flash utility to flash uboot, pboot, and xloader. These work, and I am able to get into the p500 commandline. I then, as a first experiment, tried if I could load something to the FPGA using the method described here: https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg3802571/#msg3802571. The commandline seemed to accept this just fine, so I am assuming this worked. I then proceeded to try and copy that data, from ram, to the right place in nand (0xd0060000) using the "cp" command, but that command just hang forever, so I had to restart the device. I then tried uploading everything to the right addresses in NAND using  that STM flash utility:


I set up the partitions like this, and then I uploaded the files, and rebooted the scope, and I got something like this:


--- Code: ---System ready!
Preparing for download...
RTC: 2024-23-11   3:100:32.29 UTC
 Loading image 1 from memory at 0xD0600000
Incorrect Data 0 EccResult: 3303c3 EccError: ccfc3c EccRead: ffffff
 IsCompressed: ReadFlash failed
Incorrect Data 0 EccResult: 3303c3 EccError: ccfc3c EccRead: ffffff
 EBOOT_ReadFlash failed

ERROR: Unable to read image signature.

BL_IMAGE_TYPE_UNKNOWN

 Loading image 1 failed, trying next one
 Loading image 2 from memory at 0xD1E00000
Incorrect Data 0 EccResult: 3303c3 EccError: ccfc3c EccRead: ffffff
 IsCompressed: ReadFlash failed
Incorrect Data 0 EccResult: 3303c3 EccError: ccfc3c EccRead: ffffff
 EBOOT_ReadFlash failed

ERROR: Unable to read image signature.

BL_IMAGE_TYPE_UNKNOWN

 Loading image 2 failed, trying next one
 All images failed

Press r to reset

--- End code ---

So clearly not everything is nicely in place to boot from yet, So to check if it I tried loading the FPGA image from the NAND flash:

--- Code: ---p500> fpga 0xd0060000 45480
failed: 979 731
Could not copy from NAND offset 0x60000. Error -74 With ECC
failed: 1225 979
Could not copy from NAND offset 0x60000. Error -74 NO ECC
FPGA programming FAILED!

--- End code ---

That seemed kinda odd to me, so I checked the memory using the "md" (memory display) command in <p500>, and I got a bunch of 0's and a few bytes of data that didn't look like the start of the FPGA file when I run it through xxd on my PC.  (I don't think I kept a log of me printing this data).

Later, because like I mentioned at the start, copying data to NAND from <p500> seemed to hang, and the data I was reading from NAND didn't make sense, I figured that writing to NAND just wasn't working, and while troubleshooting this, I happened to try to read a block of data from the start of the NAND memory twice:

--- Code: ---p500> md 0xd0000000
d0000000: 00000036 00000000 00000000 00000000    6...............
d0000010: 00000000 00000000 0000013f 00000000    ........?.......
d0000020: 00000000 0000001a 00000003 00000070    ............p...
d0000030: 00000301 00000012 00000000 00000000    ................
d0000040: 00000000 00000000 00000000 00000000    ................
d0000050: 00000000 00000000 00000000 00000000    ................
d0000060: 00000000 00000000 00000000 00000000    ................
d0000070: 00000000 00000000 00000000 00000000    ................
d0000080: 00000000 00000001 00000000 00000000    ................
d0000090: 00000000 00000000 00000000 00000000    ................
d00000a0: 00000000 00000000 00000000 00000000    ................
d00000b0: 00000000 00000000 00000000 00000000    ................
d00000c0: 00000000 00000000 00000000 00000000    ................
d00000d0: 00000000 00000000 00000000 00000000    ................
d00000e0: 00000000 00000000 00000000 00000000    ................
d00000f0: 00000000 00000000 00000000 00000000    ................
p500> md 0xd0000000
d0000000: 0000007f 00000000 00000000 00000000    ................
d0000010: 00000000 00000000 0000013f 00000000    ........?.......
d0000020: 00000000 0000001a 00000003 00000070    ............p...
d0000030: 00000301 00000012 00000000 00000000    ................
d0000040: 00000000 00000000 00000000 00000000    ................
d0000050: 00000000 00000000 00000000 00000000    ................
d0000060: 00000000 00000000 00000000 00000000    ................
d0000070: 00000000 00000000 00000000 00000000    ................
d0000080: 00000000 00000001 00000000 00000000    ................
d0000090: 00000000 00000000 00000000 00000000    ................
d00000a0: 00000000 00000000 00000000 00000000    ................
d00000b0: 00000000 00000000 00000000 00000000    ................
d00000c0: 00000000 00000000 00000000 00000000    ................
d00000d0: 00000000 00000000 00000000 00000000    ................
d00000e0: 00000000 00000000 00000000 00000000    ................
d00000f0: 00000000 00000000 00000000 00000000    ................
--- End code ---

The thing that worries me is that the data isn't identical between two reads, suggesting that something is wrong with either the NAND chip / connection, or I guess something in the memory setup?

(I also tried uploading the boot image through ymodem to ram (after loading the fpga image using the same method), but that took 45 minutes, and it didn't boot. I guess I might have done something wrong in preparing the image or something. I didn't keep a log, and I haven't had time yet to try that again)

Bud:

--- Quote from: TT-392 on November 21, 2023, 09:07:23 pm --- I could load something to the FPGA using the method described here: https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg3802571/#msg3802571. The commandline seemed to accept this just fine, so I am assuming this worked. I then proceeded to try and copy that data, from ram, to the right place in nand (0xd0060000) using the "cp" command, but that command just hang forever, so I had to restart the device.
--- End quote ---

I think you used wrong address, should have used 0x60000. When use NAND command to read/write, use physical addresses.
Also you may need to Erase the NAND address block first, before writing to it. I am unsure if NAND write does it for you.


--- Quote --- I then tried uploading everything to the right addresses in NAND using  that STM flash utility:


I set up the partitions like this, and then I uploaded the files, and rebooted the scope, and I got something like this:
--- End quote ---

Are you sure the NAND block size is 0x10000? You should be able to check it from p500 prompt using one of NAND commands- type "NAND help" to see list of commands. I can't remember which one. You have to use that block size then in the Flasher utility in NAND section, and when manipulating NAND from p500 prompt.

Edit: Just noticed you used cp command to write to NAND, i think you cant do that, you have to use NAND commands to work with NAND. Type nand help from p500 to see list of commands for nand. The cp command is for RAM.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod