EEVblog #978 - Keysight 1000X Hacking

[Anthocyanina]

Thx,I have tried,but still get UnSet Model and UnSet SN

hmm! no idea then, i would say contact keysight about it, but they will completely ignore you if you're not a business. As long as that isn't affecting functionality, i would just ignore that.

[regged]

Please, upload latest hack firmware for 1102g?

[ttelectronic]

This is a few pages back, the latest I am aware of. https://mega.nz/file/GkVSVaiY#3PVl1AI0F0FEWE_RMl5mqP7kXpECmojEtstUbp-zX6I

[TT-392]

My DSOX1102A seems to have a flash corruption issue. As far as I understand this is a common issue with these scopes, which is theoretically fixable if you can actually access and write to the corrupted memory.

At first I tried looking into the U701 chip because this thread suggested that it might be possible to access the rest of the flash through doing something to that chip: https://www.eevblog.com/forum/repair/keysight-1000x-(edux1002a)-fails-to-boot-uart-logged-at-boot/. But there doesn't seem to be any information on how to actually pull that off, and I got no responses to me asking there.

I am currently trying to connect to the J-LINK interface with my j-link edu mini, because to me, that seemed like the most obvious way to actually get access to the flash of the scope. But I am running into an:  "Error: CPU-TAP not found in JTAG chain" when trying to connect to it. The SPEAR600 cpu in the scope seems to be supported by my j-link, and I double checked all of the wiring. Also, I tried connecting to it after pulling off U701, in an attempt to get the CPU into a state where it might be more likely to accept me trying to access its J-link interface.
Also, someone seems to have already had some success in connecting to the CPU through the J-Link interface: https://www.eevblog.com/forum/blog/eevblog-978-keysight-1000x-hacking/msg2019472/#msg2019472 so I am not sure why it isn't working for me. At this point I am kinda stuck on this one and not sure how I would continue troubleshooting this particular method.

There was also the suggestion in the afformentioned thread that building that stupidbear LAN card, and using that to write to flash. I am open to going that route, but before spending all that extra time, money, and effort, I would like to know how big a chance there is of that actually leading to success. And if there is any documentation on how to actually do it, so far I have seen a bunch of suggestions on how to go about repairing scopes with this issue, but nothing in terms of recorded cases of successful fixes.

[Bud]

To enable JTAG you have to pull high a couple lines as shown in a picture in Reply #530. You can also check with Spear600 manual how to enable JTAG. I've done that and it worked, though i did not use it to upload the firmware.

[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]

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.

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: [Select]

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

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: [Select]

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!

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: [Select]

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    ................
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]

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 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.

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:

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.

[TT-392]

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.

Alright, I have been tinkering for a bit longer now. The nand block size was indeed off, and I was able to upload stuff to the nand flash using the tool from ST, and confirm the data was there using the: "nand dump" command. I tried using this to flash both the kernel, and the fpga image. But trying to load them, into for example the FPGA, or to read from nand (using the "nand read "command) in general gave me errors, often with error code "-71" my suspicion is that something goes wrong with the oob bytes (which I am interpreting as parity data?) when flashing with that ST tool.

What I tried next was using loady to load the fpga image over uart, and then using the "nand write" command to copy that data to nand (offset 0x60000). This indeed worked, the "fpga" command doesn't complain anymore, and I can actually use the "nand read" command on the data now.

I then used the same method to load nk.bin.comp (which I interpreted as the compressed OS image), into nand offset 0x600000. This went well, and I was able to, after restarting the scope to clear the RAM, write the data from NAND, back into RAM to check the checksum which matched the one I got out of the file on my pc. I then proceeded to solder the original NOR flash onto my scope, and attempted a boot. I got the following result:

Code: [Select]

U-Boot 2010.03 (Oct 18 2011 - 14:28:06)Agilent P500

CPU:   SPEAr600
DRAM:  128 MiB
Flash: 512 KiB
NAND:  internal ecc 128 MiB

Debug serial initialized ........OK
RTC: 2024-23-11   7:99:35.56 UTC

Microsoft Windows CE Bootloader Common Library Version 1.4 Built May  7 2015 01:38:03
Microsoft Windows CE 6.0 Ethernet Bootloader for the Agilent P500 board
Adaptation performed by Agilent Technologies (c) 2008

PHY not found.

System ready!
Preparing for download...
RTC: 2024-23-11   7:99:35.56 UTC
 Loading image 1 from memory at 0xD0600000
O
BL_IMAGE_TYPE_BIN

X
XXXXOOOOXXIncorrect Data 2 EccResult: cf330 EccError: 3cfcc3 EccRead: 300ff3
 EBOOT_ReadFlash failed offset 62d7ce
 EBOOT_ReadFlash failed location d0632000
ODeCompressFlash: CeCompressDecode() failed
 CeDecompressFlashBlock failed
****** Data record 7 corrupted, ABORT!!! ******

Completed file(s):
-------------------------------------------------------------------------------
[0]: Address=0x80361000  Length=0x1A857C0  Name="" Target=RAM
 Loading image 1 failed, trying next one
 Loading image 2 from memory at 0xD1E00000

BL_IMAGE_TYPE_UNKNOWN

 Loading image 2 failed, trying next one
 All images failed

Press r to reset

It seems to try something with the data at 0xD0600000, but gives up quite quickly.

My guess is that I am either using the wrong file (though I'd have no idea what other file inside of infiniiVisionSetup.cab could be it), or that it might need some preprocessing to decompress it beforehand, but as far as I understand, the boot process does expect a compressed file. I did try decompressing it a while ago. Back then, I think I used the instructions from https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg2136181/#msg2136181 back then. But the resulting file was too big to even fit in the region of flash in which it is supposed to go, so I am guessing that isn't it.

[Bud]

Try without writing nk.bin.comp into NAND. Just prepair nk.nb0 file as desribed in titiris's post you referenced and use the output from viewbin.exe, the color coded offsets in that post. Load that nk.nb0 using ymodem into RAM to the proper offset and execute the image from RAM using go <your start address> command (do not reboot)  If the scope starts, immediately run firmware upgrade and let the scope worry about writing firmware to NAND.
But to do this you again need access to Uboot.

[Bud]

By the way, what NOR image did you flash into U701 using ST flasher? Did you use the original image with bootdelay changed and checksums updated or was it any other image, which may be dangerous? I say only use the changed one from your scope because it initializes cruicial environment variables.

[TT-392]

Try without writing nk.bin.comp into NAND. Just prepair nk.nb0 file as desribed in titiris's post you referenced and use the output from viewbin.exe, the color coded offsets in that post. Load that nk.nb0 using ymodem into RAM to the proper offset and execute the image from RAM using go <your start address> command (do not reboot)  If the scope starts, immediately run firmware upgrade and let the scope worry about writing firmware to NAND.
But to do this you again need access to Uboot.

I tried this back when I tried following the instructions from that post, however, when I ran: "go 0x00362000", it just hang, and did nothing. I might have messed something up back then though, I also didn't have the FPGA image flashed to NAND yet (I did load it from ram). I am open to trying again, but have been a bit hesitant so far because it takes like 45 minutes to upload that uncompressed image through UART.

By the way, what NOR image did you flash into U701 using ST flasher? Did you use the original image with bootdelay changed and checksums updated or was it any other image, which may be dangerous? I say only use the changed one from your scope because it initializes cruicial environment variables.

The image I flashed was one I extracted from the firmware upgrade package from keysights website. I didn't change anything about it, but when I boot with that image flashed, it does give me 3 seconds to press space and then goes into the <p500> shell. For the last boot test I described in my previous post, I used the original NOR chip, which I left unchanged as a backup.

[TT-392]

Or are you suggesting I extract the data from the original NOR flash, and modify those?

[TT-392]

Just did that, am in the <p500> console with a practically identical image to the original NOR chip now. Guess the next step is loading that decompressed OS image in ram.

[Bud]

Did what? Updated the original NOR? Make sure you updated UBoot checksums as well, otherwise Uboot will assume its data is corrupted and will not load the environment variables and that will cause further NAND corruption.
From UBoot prompt type printenv and post the output here. Let us review it before you attempt to boot an image.

[TT-392]

Did what? Updated the original NOR?

Uh, ye, the ROM thing, I forgot to quote myself in that post.

Make sure you updated UBoot checksums as well, otherwise Uboot will assume its data is corrupted and will not load the environment variables and that will cause further NAND corruption.
From UBoot prompt type printenv and post the output here. Let us review it before you attempt to boot an image.

I am not entirely sure what checksums you are talking about, there is this thing: https://reverseengineering.stackexchange.com/questions/26108/how-do-i-calculate-crc32-of-a-u-boot-header-in-a-modified-firmware-image. But that is just a checksum of the first 64 bytes, which I haven't changed, so I don't see why the checksum would need updating?
Also, as far as I can tell, the environment variables are there:

Code: [Select]

p500> printenv
bootcmd=tftp 0x4000000 nk.bin;bootm 0xf8050000
ramboot=dhcp 0x4000000 nk.bin;bootm 0xf8050000
bootdelay=3
baudrate=115200
serverip=192.168.1.10
preboot=splash load;fpga;expi
gatewayip=192.168.1.10
netmask=255.255.255.0
usbtty=cdc_acm
fpgadata=0xd0060000
fpgasize=0x75394
splashdata=0xd0000000
dispParm1=0x300 0x400 0x2625A00 0x1 0x3
dispParm2=0x20 0x4c 0x1 0x2 0x3
boardversion=4
ps=0
rtc=0
erase_env=protect off 1:4;erase 1:4
store_uboot=protect off 1:1-3;erase 1:1-3;cp.b 0x800000 0xF8010000 ${filesize};protect on 1:1-3;imi 0xF8010000
get_uboot_eth=dhcp 0x800000 u-boot_image.bin;run store_uboot
get_uboot_uart=loadb 0x800000 115200;run store_uboot
verify=n
ethaddr=00:03:d3:04:10:00
ipaddr=192.168.1.100
serialnum=serial number not programmed
chipversion=BD
ethact=unknown

Environment size: 777/16380 bytes
I am just missing a serial number, but I am just going by that not being needed to get a boot.

Also.... I don't think there is much more NAND to be corrupted.... I accidentally did a full NAND erase at some point.

I am planning to retry the method described in: https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg2136181/#msg2136181 today. I have already seen some steps I missed last time.

[Bud]

Oh, that is unfortunate....Your device calibration is gone then and Infiniivision application is gone. Downloading nk.bin will only restore WinCE image but I think boot process will fail when it comes to starting the scope application. So you won't be able to run firmware upgrade from the scope menu.

[TT-392]

Oh, that is unfortunate....Your device calibration is gone then and Infiniivision application is gone. Downloading nk.bin will only restore WinCE image but I think boot process will fail when it comes to starting the scope application. So you won't be able to run firmware upgrade from the scope menu.

Well... calibration data is unfortunate, but I just followed the instructions from that other post, for creating the USB with stuff the scope needs to boot, and loaded the nk.nb0 file to ram, and it actually booted.... (though with a message on the display saying: "OS version incorrect, please reload system firmware"). So I don't think I am going to give up just yet.

I was also able to start the firmware upgrade. Though it was complaining about environment data during the upgrade, and it did fail to boot afterwards.

Code: [Select]

U-Boot 2010.03 (Oct 18 2011 - 14:28:06)Agilent P500

CPU:   SPEAr600
DRAM:  128 MiB
Unknown id: 0x13409d. Using ST_M23P40
Flash: 64 KiB
NAND:  fsmc-ecc1 128 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
SerNum:serial number not programmed
Chip:  BD Board Rev: 4
Error: start address not on sector boundary
Net:   unknown
BMP data is not valid. Use splash bmp
Press space to stop autoboot: 2 
p500> loady 0x0361000 115200
## Ready for binary (ymodem) download to 0x00361000 at 115200 bps...
CSending: nk.nb0
Ymodem sectors/kbytes sent:   0/ 0kRetry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Retry 0: NAK on sector
Bytes Sent:27809792   BPS:7995                           
Sending:
Ymodem sectors/kbytes sent:   0/ 0k
Transfer complete
) packets, 10 retries
## Total Size      = 0x01a857c0 = 27809728 Bytes
p500> crc 0x0361000 0x01a857c0
CRC32 for 00361000 ... 01de67bf ==> f3fb57d9
p500> go 0x00362000
## Starting application at 0x00362000 ...
Windows CE Kernel for ARM (Thumb Enabled) Built on Mar  8 2013 at 17:05:33
Setting up for a Cold Reboot
Done Setting up for a Cold Reboot
Windows CE Firmware Init
BSP 1.0.0 for the SPEARHEAD600AB board (built Jun 10 2019)
Adaptation performed by ADENEO (c) 2005
+OALIntrInit
-OALIntrInit(rc = 1)
Initialize driver globals Zeros area...
pDrvGlobalArea 0xa0060000  size 0x800 (0xa0060800 -0xa0060000)
Initialize driver globals Zeros area...done
 OALKitlStart
Firmware Init Done.
OALIoctlHalEnterI2cCriticalSection init i2c cs
UBOO: CRC does not match for primary a431ee82 7f16dd10
ERROR: c:\WINCE600\3RDPARTY\Agilent\HPP\P500\Drivers\p500_uboo\.\p500_uboo_hw.cpp line 143: UBOO:   CRC does not match for backupffffffff a05a35aa
ERROR: c:\WINCE600\3RDPARTY\Agilent\HPP\P500\Drivers\p500_uboo\.\p500_uboo_drv.cpp line 116: UBOO_Init - Failed to initialize UBOO Controller
++SER_Init: context Drivers\Active\14
SER_Init, dwIndex:2
SER2 got sysintr:0x00000017
SER2 Serial Port, new baud rate:0x1c200  (UARTCLK:48000000 IBRD:0x1a FBRD:0x2)
FMD: Start of the FileSystem not set, reverting to default values
OHCI\system.c, GCFG_USBH1_SW_RST
OHCI\system.c, GCFG_USBH2_SW_RST
LAN PHY NOT detected.
DeleteP500EnetRegistry:
   \Comm\GMAC 0x0
   \Comm\GMAC1 0x0
   \Comm\Tcpip\Linkage 0x0
   \Drivers\Virtual 0x0
   \Drivers\BuiltIn\LIN 0x5
FMD: Start of the FileSystem not set, reverting to default values
LIN: Data Valid
BALDWIN_DDI: cBaldwinHwIf::Init: Initializing...
BALDWIN_DDI: cBaldwinHwIf::Init: Scope successfully identified.
BALDWIN_DDI: cBaldwinHwIf::Init: Success!
Device load time:
   NANDFLASH: 380 ms
   USB Hard Disk Drive: 380 ms
ERROR: OALIoCtlHalGetDeviceInfo: Device doesn't support IOCTL_HAL_GET_DEVICE_INFO::SPI_GETBOOTMENAME
SHIM DLL, LoadRealDll [PalIO.dll] for [AgilentPalIO.dll]
SHIM [AgilentPalIO.dll] Get Process Addresses
LaunchInfiniiVision:
SHIM DLL, LoadRealDll [PalSStorage.dll] for [AgilentPalSStorage.dll]
SHIM [AgilentPalSStorage.dll] Get Process Addresses
SHIM DLL, LoadRealDll [PalWin32.dll] for [AgilentPalWin32.dll]
SHIM [AgilentPalWin32.dll] Get Process Addresses
FWUpdate: Bad news, can't get environment data
                                              Create: \Agilent Flash\selftest\
Create: \Secure\cal\
Create: \Secure\help\
Create: \Secure\bin\
Create: \Agilent Flash\wfmMem\
Create: \Agilent Flash\LxiMdns\
Released build, Jun 10 2019, 21:13:39
Initializing FPGA...
************************************
Ver: 1.067 Released
************************************
Calibration mode User
Serial Number file isn't loaded, defaulting to 0
open FAILED
open FAILED
open FAILED
Cal Date Thu Jan 01 00:00:00 1970
Could not load valid cal factors
Startup sequence is complete.
Saved configuration invalid
FWUpdate: Bad news, can't get environment data
                                              System has been running 134.088058 seconds
Start Up Sequence 5.067179
Memory Load 47%
   System Physical Memory 33.957 / 73.465 MB
   Process Virtual Memory 42.375 / 1024.000 MB
-----> InfiniiVision is running <-----
failed open \Secure\InfiniiVision\LudicrousSpeed.usb
                                                    no workaround for USB phy

** BEGIN ** ExtractFileFromCabFile: INSTALL.XML
** END   ** ExtractFileFromCabFile: INSTALL.XML: 140 ms
** BEGIN ** ExtractFileFromCabFile: infiniiVisionSetup.cab
** END   ** ExtractFileFromCabFile: infiniiVisionSetup.cab: 13425 ms
** BEGIN ** ExtractFileFromCabFile: _setup.xml
** END   ** ExtractFileFromCabFile: _setup.xml: 14 ms
** BEGIN ** ExtractFileFromCabFile: INFINI~1.025
** END   ** ExtractFileFromCabFile: INFINI~1.025: 15 ms

** BEGIN ** ExtractFileFromCabFile: INSTALL.XML
** END   ** ExtractFileFromCabFile: INSTALL.XML: 24 ms

** BEGIN ** ExtractFileFromCabFile: INSTALL.XML
** END   ** ExtractFileFromCabFile: INSTALL.XML: 16 ms
** BEGIN ** ExtractFileFromCabFile: updateSplashImage.wvga.bin
** END   ** ExtractFileFromCabFile: updateSplashImage.wvga.bin: 8 ms
GetNextUsbEvent, bOpenContextClosing
EventThread, ERROR ABORTED or INVALID HANDLE, exiting
GetSetupPacket, tmcDriverClosing 2
** BEGIN ** ExtractFileFromCabFile: nk.bin.comp
** END   ** ExtractFileFromCabFile: nk.bin.comp: 6893 ms
** BEGIN ** ProcessRecipeStep: \windows\loadP500Flash -u ceImage2 \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\nk.bin.comp
SHIM DLL, LoadRealDll [PalSysManagement.dll] for [AgilentPalSysManagement.dll]
SHIM [AgilentPalSysManagement.dll] Get Process Addresses
FWUpdate: Bad news, can't get environment data
                                              FWUpdate: Bad news, can't get environment data
                                                                                            fwUpdateOffset error: Too Big Error
** END   ** ProcessRecipeStep: \windows\loadP500Flash -u ceImage2 \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\nk.bin.comp: 432 ms
** BEGIN ** ExtractFileFromCabFile: updateBootLoaders2.exe
** END   ** ExtractFileFromCabFile: updateBootLoaders2.exe: 184 ms
** BEGIN ** ExtractFileFromCabFile: pboot_rel.bin
** END   ** ExtractFileFromCabFile: pboot_rel.bin: 244 ms
** BEGIN ** ProcessRecipeStep: \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\updatebootloaders2.exe
Update XLOADER at address f8000000.
XLOADER is up to date. Skipping
Update UBOOT at address f8010000.
UBOOT is up to date. Skipping
Update PBOOT at address f8050000.
PBOOT is up to date. Skipping
** END   ** ProcessRecipeStep: \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\updatebootloaders2.exe: 95 ms
** BEGIN ** ExtractFileFromCabFile: nk.bin.comp
** END   ** ExtractFileFromCabFile: nk.bin.comp: 6873 ms
** BEGIN ** ProcessRecipeStep: \windows\loadP500Flash -u ceImage1 \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\nk.bin.comp
SHIM DLL, LoadRealDll [PalSysManagement.dll] for [AgilentPalSysManagement.dll]
SHIM [AgilentPalSysManagement.dll] Get Process Addresses
FWUpdate: Bad news, can't get environment data
                                              FWUpdate: Bad news, can't get environment data
                                                                                            fwUpdateOffset error: Too Big Error
** END   ** ProcessRecipeStep: \windows\loadP500Flash -u ceImage1 \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\nk.bin.comp: 433 ms
** BEGIN ** ExtractFileFromCabFile: fpga1000a.bin
** END   ** ExtractFileFromCabFile: fpga1000a.bin: 102 ms
** BEGIN ** ProcessRecipeStep: \windows\loadP500Flash -u fpga --target marsupial \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\fpga1000a.bin
SHIM DLL, LoadRealDll [PalSysManagement.dll] for [AgilentPalSysManagement.dll]
SHIM [AgilentPalSysManagement.dll] Get Process Addresses
** END   ** ProcessRecipeStep: \windows\loadP500Flash -u fpga --target marsupial \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\fpga1000a.bin: 615 ms
** BEGIN ** ExtractFileFromCabFile: cleanupFileSystem.exe
** END   ** ExtractFileFromCabFile: cleanupFileSystem.exe: 164 ms
** BEGIN ** ProcessRecipeStep: \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\cleanupFileSystem.exe
** END   ** ProcessRecipeStep: \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\cleanupFileSystem.exe: 15 ms
** BEGIN ** ExtractFileFromCabFile: infiniivisionSetup.cab
** END   ** ExtractFileFromCabFile: infiniivisionSetup.cab: 8084 ms
** BEGIN ** ProcessRecipeStep: \windows\wceldcmd.exe /delete 0 \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\infiniivisionSetup.cab
** END   ** ProcessRecipeStep: \windows\wceldcmd.exe /delete 0 \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\infiniivisionSetup.cab: 833 ms
** BEGIN ** ExtractFileFromCabFile: splashImage.png
** END   ** ExtractFileFromCabFile: splashImage.png: 285 ms
** BEGIN ** ProcessRecipeStep: \windows\compileImageForSplashScreen.exe \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\SplashImage.png \Secure\InfiniiVision\splashImage.bin
** END   ** ProcessRecipeStep: \windows\compileImageForSplashScreen.exe \TEMP\{FB49C34B-AF8F-785E-20BD-0D9FCFF926FB}\SplashImage.png \Secure\InfiniiVision\splashImage.bin: 2438 ms
** BEGIN ** ProcessRecipeStep: \windows\rebootInfiniivision.exe


U-Boot 2010.03 (Oct 18 2011 - 14:28:06)Agilent P500

CPU:   SPEAr600
DRAM:  128 MiB
Unknown id: 0x13409d. Using ST_M23P40
Flash: 64 KiB
NAND:  fsmc-ecc1 128 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
SerNum:serial number not programmed
Chip:  BD Board Rev: 4
Error: start address not on sector boundary
Net:   unknown
BMP data is not valid. Use splash bmp
Press space to stop autoboot:  0
 no link
Using unknown device
TFTP from server 192.168.1.10; our IP address is 192.168.1.100
Filename 'nk.bin'.
Load address: 0x4000000


I am currently uploading again for another attempt. Though not sure what I am going to try differently this time.

[Bud]

*** Warning - bad CRC, using default environment

That is exactly what I told you about updating Uboot CRC in NOR. Uboot found incorrect CRC and did not load the environment variables and that has caused bunch of errors. You have to properly update the CRC in your modified NOR. I do not think you can use the original NOR  because there will be no access to ymodem.

[Bud]

I'll search my archives if I have Uboot CRC  update information somewhere in my records.

[Bud]

/==========================================
Updating u-boot in SPI Flash (ST M2540P IC) for EDUX1002A

Location of Uboot image in SPI firmware : 0x00010000 - 0x0003F90B
Location of Uboot environment variables:  0x00040000 - 0x00043FFF

The first 4 bytes in envvars area is a CRC32 of the envvars area in Little Endian (LSB first) format over the block 0x00040004 - 0x00043FFF (including zero bytes fill after the env variables end.)
For example if a calculated CRC32 is 98C7C680, then the first 4 bytes (0x40000-0x40003) become 80C6C798.

It is IMPORTANT to update this envvars CRC32 if envvars area is patched.
Failure to update the env variables data checksum after a change (typically by unsoldering and re-programming the U701 IC located on the bottom side of the BLT Module) will cause u-boot to load default environment variables which will lead to failed boot and NAND corruption.

To calculate CRC32 over a block of data use any existing tool which can do this, like a Hex editor.

User envvars area is located in SPI chip outside of the U-boot binary image, so if user envvars are patched, the U-boot's own header CRC32 and Data CRC32 do not need to be updated.
/==========================================

[Bud]

... it takes like 45 minutes to upload that uncompressed image through UART.

This is where the StupidBear LAN board shines. Uploading an image through network only takes a few min.

[TT-392]

/==========================================
Updating u-boot in SPI Flash (ST M2540P IC) for EDUX1002A

Location of Uboot image in SPI firmware : 0x00010000 - 0x0003F90B
Location of Uboot environment variables:  0x00040000 - 0x00043FFF

The first 4 bytes in envvars area is a CRC32 of the envvars area in Little Endian (LSB first) format over the block 0x00040004 - 0x00043FFF (including zero bytes fill after the env variables end.)
For example if a calculated CRC32 is 98C7C680, then the first 4 bytes (0x40000-0x40003) become 80C6C798.

It is IMPORTANT to update this envvars CRC32 if envvars area is patched.
Failure to update the env variables data checksum after a change (typically by unsoldering and re-programming the U701 IC located on the bottom side of the BLT Module) will cause u-boot to load default environment variables which will lead to failed boot and NAND corruption.

To calculate CRC32 over a block of data use any existing tool which can do this, like a Hex editor.

User envvars area is located in SPI chip outside of the U-boot binary image, so if user envvars are patched, the U-boot's own header CRC32 and Data CRC32 do not need to be updated.
/==========================================

So, I succeeded in creating the new image, with correct checksum, and it doesn't complain anymore, but I am not getting into <p500> anymore, the bootdelay is still 3, And I can press space on startup, and then I get into this (somewhat familiar from the original flash) screen. I am getting the feeling that the only reason I was getting into the <p500>, was because the checksum was wrong...

Here is my current output (including me pressing space on startup).

Code: [Select]

U-Boot 2010.03 (Oct 18 2011 - 14:28:06)Agilent P500

CPU:   SPEAr600
DRAM:  128 MiB
Unknown id: 0x13409d. Using ST_M23P40
Flash: 64 KiB
NAND:  internal ecc 128 MiB

Debug serial initialized ........OK
RTC: 2024-19-6   2:85:47.54 UTC

Microsoft Windows CE Bootloader Common Library Version 1.4 Built May  7 2015 01:38:03
Microsoft Windows CE 6.0 Ethernet Bootloader for the Agilent P500 board
Adaptation performed by Agilent Technologies (c) 2008

PHY not found.


P500 Boot Loader Configuration :

Mac address .......... (00:03:D3:04:10:00)
Ip address ........... (192.168.1.100)
Subnet Mask address .. (255.255.255.0)
DHCP ................. (Enabled)
Boot delay (seconds).. (0)
Load image 1 at startup

Image addresses. (0xdxxxxxxx for NAND, 0x8xxxxxxx for RAM)
        1 (0xd0600000)
        2 (0xd1e00000)

l) Load memory resident image Load image 1 now
1) Load memory resident image 1 now
2) Load memory resident image 2 now
3) Load memory resident image 3 now
d) Download from platform builder now
u) Start u-boot by resetting
v) Verify Images
>

Did I miss a a var I needed to modify? when originally modifying the flash, I set the "bootdelay" to 3 in 2 places I could find it in flash:

(here is the strings containing bootdelay in the monolithic image which I flashed to the chip)

Code: [Select]

> strings dump5.bin | grep bootdela
bootdelay
bootdelay=3
bootdelay=3
pbootdelay=0