Agilent 34461A corrupted flash

[dc101]

It may have been when I probably erased more of the NAND flash than I intended to? When I was first starting my attempt at reflashing nk.bin, I didn't specify a block_size, so I'm pretty sure that I erased everything after whatever the starting address was. Probably worth looking into a little more, since I still have to upload an nk.bin image to RAM after power-on/reboot to get it to fully boot.

That being said, I still don't really know what happened to my meter to cause it be in it's current state. For months it had trouble booting, but usually unplugging it for a few minutes plugging in back in and then turning it on would work. Unfortunately I didn't think the problem was serious, and I never thought to look at the serial console at the time. Eventually it got to the point where it didn't matter what I did, I'd just get the Keysight splashscreen and the serial console indicated all 3 images were invalid. Perhaps whatever caused this, also caused it to lose the model number as well?

-Tim

[TheSteve]

I have a Keysight 33622A that boots but won't enable any output as the FPGA authentication fails. All other self tests pass. There is a Dallas 1 wire secure IC with the FPGA that performs a secure handshake with the main processor, if it fails the meter won't work. It is tied to the model/serial # I am sure and is there to prevent someone else from ripping off the FPGA code(only reason I can think of). It seems my meter is a prototype and I'm wondering if the secure IC was never configured/programmed and worked fine with development firmware. Then someone updated to normal production firmware and it no longer operates. At that point they gave up and sold it, now I own it. The model # and serial # are correct. They are both also stored on the main board in an eeprom but if you blank that it will just silently reprogram it at boot from the front panel CPU processor. The ofinit command doesn't work because it is already programmed. I am wondering though if I was to erase the model/serial # like you did if it would also generate whatever is needed to work with the secure IC again when running the ofinit command. Obviously I don't want to erase anymore then needed.

The address location change in your 34461A is also interesting, it seems like it thought the dataspace was in use and shifted the address down and then wrote pboot in a new location. You may have slightly less NAND space then you had originally, not likely an issue though.

edit - if you perform a "factory list" Do you see your serial # listed? I tried it with my 33622A and have a valid MAC and GUID but there is no serial #.

[dc101]

When I first tried factory list it showed the same serial number as u-boot, MY99999999, but I can't be sure that's not because of current issues. I'll have to try that with my 53220A and see what it returns. Perhaps Frank can try on his scope as well? I'm not sure if that's legacy code or not.

After first reboot, it appeared the DIAG:OFINIT was not permanent as my model number was lost. But after additional tests, the model number seems to remain in memory even after unplugging the meter for several minutes. One interesting thing is that even after running the DIAG:OFINIT command, I was still unable perform a USB firmware update and received the same "Incorrect firmware loaded for this model number." unfortunately after trying the firmware update again I get a warning saying the firmware on the USB is the same or older and after pressing yes to continue, the unit simply freezes and the front panel stops responding. The web interface still seems to work though.

My current boot process is to abort the autoboot, load the NAND image2 into RAM, and issue the normal boot command.  By default this pboot boots from the RAM image. It's still a pain, but better than uploading nk.bin using ymodem after every reboot.

Out of curiosity, I ran the DIAG:OFINIT command with my serial number but changed the model number and got a "-310 System error" so there is definitely some logic checking happening in the meter.

Regarding the NAND address shifting, that seems to be related to using Frank's pboot since we have different meters. The problem is everytime I try a firmware update, the u-boot values seem to reset to their original settings. The FBGA codes on the NAND are different, although I haven't looked up the one for the 34465A, so I don't know the exact differences.

-Tim

[TheSteve]

I have a 34461A - maybe I should dump the pboot from it.

[dc101]

If you could, that would be super helpful. I'd be very curious to see what the default NAND locations are for your images. Also would be interesting to compare them with vbindiff  to see how different they are.

Have you looked at any of the interfaces coming off of the NXP chip mentioned by 6thimage in the new 34465A/34470A thread? It looks like the UART, I2C and SPI lines are all routed to traces. I checked the UART on boot with my scope and there's some 115200 baud traffic (3.3V logic) but I haven't gotten around to decoding it yet. It's on my to do list.

Since I've got a somewhat good feel for bringing up my meter from the dead, I may try to erase the entire NAND again and see what happens. Wonder if we'll lose the serial / model number again?

-Tim

[TheSteve]

Had a play with my 34461A. I dumped pboot.
I noticed at boot it showed the serial # as SerNum:MY99999999

I then thought I'd do the "factory list" but mis-remembered the command and typed "factory info". The command didn't give an error but has now changed the "MY99999999" to "x⚌⚌⚌⚌$
". It seems the change is permanent. So far the meter still boots and seems to work with no errors. I haven't tried a firmware update or anything. It's made me sweat a little, not going to lie. I really like my 34461A, bought it new. Normally commands don't do odd things, guess we need to be super careful.
You can see that same serial # with the printenv command.

[Monkeh]

Normally commands don't do odd things, guess we need to be super careful.

You're working at a very low level with code chucked together for test purposes, never really expected to be seen by anyone but the original firmware engineers. Here be dragons.

[dc101]

Not sure if this was reported in the other Agilent/Keysight multimeter threads, but you can enabled the FTP server on the 3446X by running the SCPI command DIAG:UPD:START?

Code: [Select]

[user.titan] ➤ telnet 192.168.30.96 5024
Trying 192.168.30.96...
Connected to 192.168.30.96.
Escape character is '^]'.
Welcome to Keysights's 34460A Digital Multimeter
34460A> DIAG:UPD:DIR?
\Agilent Flash\User\
34460A> DIAG:UPD:START?
+1
34460A>
Here's some more SCPI commands that you can use to try and brick you meter, get crazy:
DIAG:UPD:DIR?
DIAG:UPD:ENAB?
DIAG:UPD:REV?
DIAG:UPD:BLOCK:SIZE?
DIAG:UPD:START?
DIAG:UPD:STOP
DIAG:UPD:REBOOT
DIAG:UPD:END?
DIAG:UPD:ENAB?
DIAG:UPD:NKBIN "\Agilent Flash\User\Nk.bin"
DIAG:UPD:FIRM:ERR?
DIAG:UPD:FIRM:PROG?

[dc101]

The Steve - Ooooofff, unfortunately that makes sense with what I saw in the decompiler.  <--- Side note, what am I doing wrong, that I can't put pictures inline with my post?
It assumes any argument that isn't the string "list" is a pointer to a location containing the factory data. There's no checking to make sure it's a valid address. So if you typed in "info", then factory copied 0x2000 bytes starting at (RAM)0x696e666f into NAND flash.

Did you by chance run printenv prior to running factory info/list? If so, you should be able to restore your factory info back to default. It's not hard, it just involves finding a clean space of RAM, writing to it in the format that factory expects and then running the factory command with the correct address.

Cheers
-Tim

[TheSteve]

Oofff, yes that makes sense with what I saw in the decompiler. (Attachment Link)   <--- Side note, what am I doing wrong, that I can't put pictures inline with my post?
It assumes any input that isn't the string "list" is a pointer to a location containing the factory data. There's no checking on the input to make sure it's a valid address.

Did you by chance run printenv prior to running factory info/list? If so, you should be able to restore your factory info back to default. It's not hard, it just involves finding a clean space of RAM, writing to it in the format that factory expects and then running the factory command with the correct address.

It doesn't appear I did. I do have the original MAC saved elsewhere though, so maybe we can restore it still.

[dc101]

Thanks! Most surprisingly, it's exactly the same as the one from Frank. That's good news for the community, now we know.

It does however pose more questions, why now are the image locations different from the u-boot defaults? How do you change the pboot image locations? Why do the u-boot image settings change after a firmware update attempt? How do you change the u-boot defaults? What else needs to be programmed to perform a factory firmware update?

Cheers
-Tim

[dc101]

This is starting to get interesting.

[TheSteve]

Restored the proper mac and the dummy serial # MY99999999. Also added a new unique GUID. I think the only value that is used is the MAC address. So the 34461A is happy again. I am pondering options to nuke the serial/model on the 33622A still though.

[dc101]

Awesome, glad to hear things are back to normal.... errr pre-factory info

-Tim

[TheSteve]

So your 34461A works, but only if you tell it where to boot the image from manually?

[dc101]

Yeah the Win CE bootloader boots from RAM by default, so I have to load the RAM image from flash every boot. I can't make the nk.bin images recognized as valid images when written to flash. And I can't get the firmware update to work from USB or ethernet. I've tried converting nk.bin into an nk.nb0 image and writing that to flash but that didn't work either. Maybe using u-boot to write to flash is bypassing the built-in ECC? Kind of at a loss right now.

While I'm pretty happy my meter still seems to pretty much work, it's also pretty frustrating to not get any support from HP/Agilent/Keysight. Sadly, it's a stark contrast to the experience I had with Rohde & Schwarz when the FFT filters on my FSP3 stopped working. I bought it used years after it was EOL, and still got an email from the R&S support staff with a copy of the firmware and instructions on reloading the firmware.

[TheSteve]

What happens if you enter the Boot Loader Config menu, then load an image via the platform builder(network) option. That should get you booted, then perform a firmware update via the front panel USB?

[dc101]

I haven't been able to figure out how to present the nk.bin image from platform builder to my meter. I have a virtual machine with Windows CE 6.0 and platform builder SP 1 installed, but I have very little experience with Windows CE/Windows Embedded. I've been able to look at the nk.bin in platform builder, but that's as far as I've gone. It's the reason why I setup the virtual machine, but I just haven't figured out how to load an nk.bin for another device to boot from.

[TheSteve]

Forget the true platform builder program. You want to use celoader. You can grab it from here:
https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg1022267/#msg1022267

Then on a windows machine run it from a command prompt window with an uncompressed nk.bin file. It will open a port on the machine with the custom tftp port needed for platform builder. When you select boot from platform builder on the 34461A it should find the machine serving the file, download and boot it.

[Dr. Frank]

Well folks,
you both do a great job ..

Just an idea concerning the 460/461 versus the 465/470:

If I remember correctly, the 460/461 came out earlier, brand still being agilent.
The main board already contained the full schematic for the later 465/470 functionality, but these additional components were not yet assembled.

The 465/470 were published under the new brand Keysight, they got a slightly updated PCB version, and the Memory option probably requires more DRAM or Flash space (I don't know where they store these data, in Flash, or in a battery backed up SRAM).

Therefore, the front panel PCB might also have more memory space and a slightly different memory map than the 460/461.. probably the PCB itself is  identical.

I could check / compare this if you tell me exactly where / what to look for, also via the monitor program.

Frank   

[dc101]

So your 34461A works, but only if you tell it where to boot the image from manually?

I tried the celoader and that takes care of loading fairly quick, but the firmware update still didn't go through.

For now, as a quick hack to just be able to use my meter again I went ahead and flashed the uncompressed nk.bin to NAND and modified the uboot preboot variable to load the image from NAND into RAM before loading the Win CE bootloader. It works for now and keeps me from having to manually abort the startup process every time I power on my meter. Eventually I need to figure out how to re-program the kernel bootloader parameters, as those seemed messed up as well.

Code: [Select]

Starting kernel ...


Debug serial initialized ........OK
No RTC on 320

Microsoft Windows CE Bootloader Common Library Version 1.4 Built May 22 2012 09:09:57
Microsoft Windows CE 6.0 Ethernet Bootloader for the Agilent P500 board
Adaptation performed by Agilent Technologies (c) 2008

Reading NAND configuration
FMD_DirectRead : Offset must be sector aligned !!
CRC does not match for NAND 6042A00 F69E122E
ERROR : Bootloader setting load failed
INFO : Loading default bootloader settings

Press [ENTER] to launch image stored in flash or [SPACE] to cancel.
Initiating image launch in   0 seconds
System ready!
Preparing for download...
No RTC on 320
 Loading image 3 from memory at 0x84000000

BL_IMAGE_TYPE_BIN

X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Xrom_offset=0x0.
XXImageStart = 0x80361000, ImageLength = 0x1856D34, LaunchAddr = 0x80362000

[dc101]

Well folks,
you both do a great job ..

Just an idea concerning the 460/461 versus the 465/470:

If I remember correctly, the 460/461 came out earlier, brand still being agilent.
The main board already contained the full schematic for the later 465/470 functionality, but these additional components were not yet assembled.

The 465/470 were published under the new brand Keysight, they got a slightly updated PCB version, and the Memory option probably requires more DRAM or Flash space (I don't know where they store these data, in Flash, or in a battery backed up SRAM).

Therefore, the front panel PCB might also have more memory space and a slightly different memory map than the 460/461.. probably the PCB itself is  identical.

I could check / compare this if you tell me exactly where / what to look for, also via the monitor program.

Frank   

The NAND flash appear to be the same between units. I checked the Micron FBGA codes and they both resolve to the same part number, with the exception of the 34470A NAND being a "premium lifecycle product" but as far as the rest of the part number and FLASH layout, exactly the same.

34461A Micron PN: MT29F1G08ABADAH4-IT:D
34470A Micron PN: MT29F1G08ABADAH4-ITX:D
Datasheet: https://www.micron.com/-/media/client/global/documents/products/data-sheet/nand-flash/60-series/m68a_1gb_nand.pdf

-Tim

[dc101]

I believe 6thimage suggested that the model and serial number might possibly be stored in the NXP, and I think I found a hint today that he might be correct.

Occasionally after loading nk.bin, sometimes I get several decrypt errors. Looking closer, I noticed a rather interesting line FP:Platform identified as NXP 8051-type based on 0 mV Looks like I'll have to look into that NXP serial port after all.

Code: [Select]

#################### dllEntry ###########################

Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
modelNumberW = 000000
rtnCode = 0

Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
modelNumberW = 000000
rtnCode = 0

Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
modelNumberW = 000000
rtnCode = 0

Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
modelNumberW = 000000
rtnCode = 0

Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
modelNumberW = 000000
rtnCode = 0

FP:Platform identified as NXP 8051-type based on 0 mV
FP:Platform identified as NXP 8051-type based on 0 mV
SER2 Serial Port, new baud rate:0x12c0  (UARTCLK:83250000 IBRD:0x43b FBRD:0x3e)
Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
serialNumberW = 0000000000
rtnCode = 0

Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
serialNumberW = 0000000000
rtnCode = 0

Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
serialNumberW = 0000000000
rtnCode = 0

Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
serialNumberW = 0000000000
rtnCode = 0

SER2 Read timeout
FP:FAILED IOCTL_SER2_READ_WITH_TIMEOUT [1460][ERROR_TIMEOUT]
Decrypt(1): CryptDecrypt failed -  NTE_BAD_DATA : -2146893819
Decrypt(2c): Decryption failed - NTE_BAD_DATA : -2146893819
serialNumberW = 0000000000
rtnCode = 0

SER2 Read timeout

[analogRF]

sorry I have to revive this old thread. One of my two 34461A which has not been used for about 4 or 5 month is not booting up anymore. The Keysight logo screen appears and then stays. Here is the boot log:

Code: [Select]

U-Boot 2010.03 (Dec 04 2017 - 01:41:53)Agilent P510

CPU:   SPEAr320
DRAM:  128 MiB
Unknown id: 0xffffff. Using ST_M23P40
Flash: 64 KiB
NAND:  INTERNAL ECC 128 MiB
In:    serial
Out:   serial
Err:   serial
SerNum:MY99999999
Chip:  AA Board Rev: 4
init  RTC: 2023-07-28 15:47:59.57
Net:   No ethernet found.
splash RTC: 2023-07-28 15:48:00.60
Press space to stop autoboot:  0

NAND read: device 0 offset 0x320000, size 0x10000
 65536 bytes read: OK
## Booting kernel from Legacy Image at 00600000 ...
   Image Name:   PBOOT
   Created:      2012-05-22  16:06:43 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    38780 Bytes = 37.9 KiB
   Load Address: 00000000
   Entry Point:  00000000
   Uncompressing Kernel Image ... OK

Starting kernel ...


Debug serial initialized ........OK
No RTC on 320

Microsoft Windows CE Bootloader Common Library Version 1.4 Built May 22 2012 09:09:57
Microsoft Windows CE 6.0 Ethernet Bootloader for the Agilent P500 board
Adaptation performed by Agilent Technologies (c) 2008

Reading NAND configuration
FMD_DirectRead: Invalid block at sector 0x180 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x1c0 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x200 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x240 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x280 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x2c0 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x300 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x340 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x380 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x3c0 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x400 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x440 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x480 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x4c0 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x500 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x540 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x580 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x5c0 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x600 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x640 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x680 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x6c0 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x700 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0x740 bumping by 0x40 sectors

.
.
.
.

FMD_DirectRead: Invalid block at sector 0xfc80 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xfcc0 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xfd00 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xfd40 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xfd80 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xfdc0 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xfe00 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xfe40 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xfe80 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xfec0 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xff00 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xff40 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xff80 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xffc0 bumping by 0x40 sectors
CRC does not match for NAND AFFF475B F381A23
ERROR : Bootloader setting load failed
INFO : Loading default bootloader settings

Press [ENTER] to launch image stored in flash or [SPACE] to cancel.
Initiating image launch in   3 seconds

P500 Boot Loader Configuration :

Mac address .......... (04:02:02:20:02:02)
Ip address ........... (192.168.114.201)
Subnet Mask address .. (255.255.255.0)
DHCP ................. (Enabled)
Boot delay (seconds).. (5)
Load image 3 at startup

Image addresses. (0xdxxxxxxx for NAND, 0x8xxxxxxx for RAM)
        1 (0xd0400000)
        2 (0xd1700000)
        3 (0x84000000)

l) Load memory resident image Load image 3 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
[color=red](I press 1 here but it is the same with other choices. "v" just does not do anything and hangs)
[/color]>System ready!
Preparing for download...
No RTC on 320
 Loading image 1 from memory at 0xD0400000
[color=red](hangs here)[/color]
here are "printenv" and "imls" outputs:

Code: [Select]

p510>   imls

*********************   NOR Flash Images   *********************


*********************   NAND Flash Images   *********************
Image at  offset 00000000:
   Image Name:   XLOADER
   Created:      2012-05-16  23:33:58 UTC
   Image Type:   ARM Linux Firmware (uncompressed)
   Data Size:    5370 Bytes = 5.2 KiB
   Load Address: d2800b00
   Entry Point:  d2800b00
   Verifying Checksum ... OK
Image at  offset 00020000:
   Image Name:   XLOADER
   Created:      2012-05-16  23:33:58 UTC
   Image Type:   ARM Linux Firmware (uncompressed)
   Data Size:    5370 Bytes = 5.2 KiB
   Load Address: d2800b00
   Entry Point:  d2800b00
   Verifying Checksum ... OK
Image at  offset 00040000:
   Image Name:   XLOADER
   Created:      2012-05-16  23:33:58 UTC
   Image Type:   ARM Linux Firmware (uncompressed)
   Data Size:    5370 Bytes = 5.2 KiB
   Load Address: d2800b00
   Entry Point:  d2800b00
   Verifying Checksum ... OK
Image at  offset 00060000:
   Image Name:   XLOADER
   Created:      2012-05-16  23:33:58 UTC
   Image Type:   ARM Linux Firmware (uncompressed)
   Data Size:    5370 Bytes = 5.2 KiB
   Load Address: d2800b00
   Entry Point:  d2800b00
   Verifying Checksum ... OK
Image at  offset 00100000:
   Image Name:   UBOOT
   Created:      2017-12-04   8:50:24 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    237800 Bytes = 232.2 KiB
   Load Address: 03f00000
   Entry Point:  03f00000
   Verifying Checksum ... OK
Image at  offset 00320000:
   Image Name:   PBOOT
   Created:      2012-05-22  16:06:43 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)                                                   
   Data Size:    38780 Bytes = 37.9 KiB                                                                     
   Load Address: 00000000                                                                                   
   Entry Point:  00000000                                                                                   
   Verifying Checksum ... OK

Code: [Select]

p510> printenv           
ramboot=dhcp 0x4000000 nk.bin;run bootcmd
baudrate=115200
gatewayip=192.168.1.10
netmask=255.255.255.0
chipversion=AA
boardversion=4
ftp=dhcp
bootdelay=0
ecc=4
cnfg_vmc_input_pin=mw 0xb3000028 0x00040300 1;mw 0xb3000048 0xfffbffff 1
cnfg_lan_input_pin=mw 0xb3000030 0x00000008 1;mw 0xb3000050 0xFFFFFFFF 1;mw 0xb3000018 0x00000101
preboot=mw.l 0xb300000c 0xffffacf4; run cnfg_lan_input_pin; run cnfg_vmc_input_pin; splash load
dispParm1=110 1e0 989680 0 28
dispParm2=1 1 1 1 3
numinstimages=1
pbootdelay=0
fimage=1
nimages=2
image1=0xd0620000
image2=0xd2120000
fsstart=0x3020000
numfilesystems=2
lengthfilesystem1=0x4EE0000
lengthfilesystem2=0x100000
bootcmd=nand read 0x600000 0x320000 0x10000;bootm 0x600000
uart2=1
rtc=1
ps=0
splashdata=0xd0180000
erase_env=nand erase 0xC0000 0x40000
store_xloader=xload 0x800000
get_xload_eth=dhcp 0x800000 xloader-p510.bin; run store_xloader
store_uboot=nand erase 0x100000 ${blocksize}; nand write 0x800000 0x100000 ${blocksize}
get_uboot_eth=dhcp 0x800000 u-boot-p510.bin;run store_uboot
store_pboot=nand erase 0x320000 ${blocksize}; nand write 0x800000 0x320000 ${blocksize}
get_pboot_eth=dhcp 0x800000 pboot.bin;run store_pboot
flash_nkbin=dhcp 0x4000000 nk.bin;nand erase 0x00620000 ${blocksize};nand write 0x4000000 0x00620000 ${blocksize}
usbtty=cdc_acm
ethaddr=80:09:02:0e:7a:4f
serialnum=MY99999999
serverip=10.0.0.242
verify=n
stdin=serial
stdout=serial
stderr=serial
ipaddr=192.168.1.179
guid={61341e9e-af36-b347-ae05-3a404c2cd9c0}

Environment size: 1482/16380 bytes
I downloaded the P-Boot from NAND and compared to one I downloaded from my good meter and also the ones posted here in this thread by TheSteve and Dr.Frank and they are all exactly identical.

I extracted "nk.nb0" from the firmware Nk.bin file (using bincompress and then cvrtbin tools that I had used when I was recovering my DSOX3034A from nand corruption) and then I used YMODEM to upload the nk.nb0 into memory and boot it from 0x362000 .

The meter boots normally and everything is hunky dory. S/N and FW revision all fine, the  meter works great and passes selftests etc...
So I upgraded (I should say re flashed) same FW 3.03 into the unit using the Keysight FW update Utility (LAN connection) and you can see in the attached photo
all goes well and when the unit is rebooted I am back exactly at where I was in the beginning 
Everytime it take 40 minutes to upload the nk.nb0 back into the unit using YMODEM to boot it and after FW update (also did using USB stick) it reboots to the same original state.

I am totally at loss here....it seems the flash is bad but rewriting the FW should have fixed it...I noticed that the image addresses in u-boot (see the last lines of the boot log) are d0400000 and d1700000 but in the printenv you can see the images must be at d0620000 and d2120000.
I downloaded few kilobytes of the NAND at d0620000 and it contains EXACTLY the Nk.bin file in the firmware (compressed). Also at d2120000 there is compressed Nk.bin file but I think it must be an earlier version

However at d0400000 there is absolutely nothing in NAND (FFFFFF for a while) and at d1700000 I can see it is the last mega byte of the Nk.bin file which started at d0620000.

So if the unit actually tries to read image from d0400000 or d1700000 then obviously it must fail.
I dont know how to check these addresses on my good meter.

I am at total loss here now...it's been 3 days of trying YMODEM 40 minutes each time and then no joy....

any help is highly appreciated

[analogRF]

so far at least I managed to get rid of the stupid YMODEM and used CEloader.exe to upload the uncompressed nk.bin file
to the meter after it fails to boot and I have the option to boot from platform builder. thats 1000 times faster than YMODEM
but still the problem remains. after successfully booting the meter and re -flashing firmware, it reboots into the exact same condition

I am now fairly convinced that the unit tries to load image #1 at d0400000 which is the wrong address. It must be d0620000
and I know for fact that there lies a good FW image at d0620000. I have checked it.

I just do not know where the unit is getting those wrong addresses from. Even the RAM address 84000000 (image #3) is wrong and it must be 80361000

any idea?