-
I have a Agilent 34461a that's well out of warranty and no longer boots. Thanks to previous threads on this forum I was able to determine it's a result of corrupt/dead flash, although I can't 100% rule out a more serious issue. I suspect this may have resulted from leaving it unplugged for some amount of time. I emailed Keysight and asked them for a copy of the pboot.bin image and nk.bin, but I'm not very optimistic they will send me the files.
Does anyone here have a copy of pboot.bin and nk.bin? Or is anyone who has a 34461a willing to try and dump these files? My 34461a is running U-Boot 2010.03 (Oct 09 2012 - 12:48:30)Agilent P510. I was able to flash nk.bin that I grabbed off the USB thumbdrive for a front panel update, but without pboot.bin there is no kernel to boot nk.bin, and I'm not 100% the nk.bin I flashed is in the correct format.
Boot log:
U-Boot 2010.03 (Oct 09 2012 - 12:48:30)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: 2021-03-22 21:08:23.75
Net: No ethernet found.
splash RTC: 2021-03-22 21:08:24.78
Press space to stop autoboot: 0
NAND read: device 0 offset 0x320000, size 0x10000
65536 bytes read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!
p510>
Sure enough if I list the flash images, pboot is definitely gone:
********************* 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: 2012-10-09 18:59:15 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 237084 Bytes = 231.5 KiB
Load Address: 03f00000
Entry Point: 03f00000
Verifying Checksum ... OK
p510>
Cheers
-Tim
-
On a whim I grabbed pboot from my 53220a, but unfortunately the units are not as similar as I thought. I was hoping it would at least boot, but it stops shortly after loading.
Keysight has already informed me that I need to send the unit in for repair because there are "no user repair actions available."
U-Boot 2010.03 (Oct 09 2012 - 12:48:30)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: 2021-03-22 23:06:53.27
Net: No ethernet found.
splash RTC: 2021-03-22 23:06:54.31
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: 2009-10-22 11:56:02 UTC
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 37189 Bytes = 36.3 KiB
Load Address: 00000000
Entry Point: 00000000
Uncompressing Kernel Image ... OK
Starting kernel ...
Debug serial initialized ........OK
-
Unknown id: 0xffffff. Using ST_M23P40
imho tah means the memory chip is not responding at all
haven't yes seen chips with good memory space and not responding to ID interogation, but who knows, maybe others have seen this
corrupted or defective flash for me means remove memory/test in external programmer/replace or reprogram
i'd guess, the flash is not 'corrupted', is not responding at all
if you cand find the .hex, remove and replace with new programmed flash chip, or maybe your agilent have some sort of firmware update procedure if the flash is empty, i don't know that agilent model
-
I've been wondering this exact thing, is the flash corrupt, did the flash die, is the DDR bad?
I have a BGA63 socket in the mail that I ordered for a different project, so I could buy a new flash chip and reprogram it, but like you said I need to find the hex files to program it with. I believe I can use the nk.bin file from the firmware update, but pboot.bin is proving impossible to find. I may have to eat the cost of buying a new front panel, I believe it's around $US 250.00.
-
sometimes a good empty flash can do it, have you tried just replacing that flash? at least, you will see the message changing and maybe update proposed.
(I suspect from "Using ST_M23P40" you can try this type of flash or somethin,g with same size or bigger and same reading/writing algo, if you got one in your spare parts)
plus, it's a simple so8
case, so changing it it's really simple even with some soldering station
-
34465A/470A may be similar / identical, as all DMMs share same Firmware update files.
Where and how can one extract this Flash Boot Loader ?
Frank
-
Frank - That might actually work! I found some photos of the 34465a on the forum from radioFlash and the ARM processors are the same.
It's not a hard process, but there are a few steps to it. It does involve removing the instrument cover which may void the warranty? So understandable if you'd prefer not to. Once the cover is off you'll need to connect to the serial port on the back of the front panel that mikeselectricstuff identified in the original 34461a thread. On the 53220a and 34461a the serial port is real 12V levels, but probably worth double checking on the 34465a. After that there are a few u-boot commands you will need to run. There is no way to download the binary straight from flash that I know of, so here's what I did when I downloaded pboot from my 53220a: List the images loaded in flash, load pboot from the given flash address into ram, print the ram contents, copy and paste the ram output into a text editor to format the text properly (remove addresses, spaces, newlines etc...) then copy and paste the properly formatted ascii hex into HxD to save as binary.
One thing I would highly recommend is running the u-boot protect command to disable writing to flash, this will prevent you from accidentally overwriting/erasing sections of your flash. It was an errant copy and paste in putty that erased my pboot :( Previously it was just nk.bin that was corrupt in flash.
I would be very grateful if you would be willing to attempt to download pboot from your meter; I am willing to pay you for your troubles. I will connect to my 53220a and document the exact u-boot commands required and the TX/RX/GND pins of the serial port, so you have a better understanding of the exact process.
Thanks again
-Tim
-
Frank - That might actually work! I found some photos of the 34465a on the forum from radioFlash and the ARM processors are the same.
It's not a hard process, but there are a few steps to it. It does involve removing the instrument cover which may void the warranty? So understandable if you'd prefer not to. Once the cover is off you'll need to connect to the serial port on the back of the front panel that mikeselectricstuff identified in the original 34461a thread. On the 53220a and 34461a the serial port is real 12V levels, but probably worth double checking on the 34465a. After that there are a few u-boot commands you will need to run. There is no way to download the binary straight from flash that I know of, so here's what I did when I downloaded pboot from my 53220a: List the images loaded in flash, load pboot from the given flash address into ram, print the ram contents, copy and paste the ram output into a text editor to format the text properly (remove addresses, spaces, newlines etc...) then copy and paste the properly formatted ascii hex into HxD to save as binary.
One thing I would highly recommend is running the u-boot protect command to disable writing to flash, this will prevent you from accidentally overwriting/erasing sections of your flash. It was an errant copy and paste in putty that erased my pboot :( Previously it was just nk.bin that was corrupt in flash.
I would be very grateful if you would be willing to attempt to download pboot from your meter; I am willing to pay you for your troubles. I will connect to my 53220a and document the exact u-boot commands required and the TX/RX/GND pins of the serial port, so you have a better understanding of the exact process.
Thanks again
-Tim
Tim,
that sounds feasible.
The replacement of the current fuses requires to remove the cover.. so there is not "guarantee void"
I have done that many times already because I e.g. experimented with the LM399 vs LTZ1000 reference.
If you provide details about this internal interface, and the necessary serial port monitor programs, I'll try it.
Frank
-
Awesome, I have the steps written down, so hopefully it is fairly straightforward. If you're on Windows I would suggest using MobaXterm (https://mobaxterm.mobatek.net/download.html) and for Linux my goto is Minicom which can be installed with apt-get install minicom.
Step 1 - Make physical connection to serial port on back of display (see attached picture for pinout)
Step 2 - Open terminal program, and set the serial connection as follows: 115200 baud, no flow control, data bits 8, stop bits 1, parity bits none
For MobaXterm, you click on the session icon in the upper left and select Serial from the popup. The baud is set on the main screen and other settings are under Advanced Serial Settings.
Step 3 - Power on unit and press space bar in MobaXterm to abort autoboot process. You should see a prompt that says "p510>"
Step 4 - Type "protect on all" and press enter. This will enable flash write protection.
Step 5 - Type "imls" you will see several sections under NAND Flash Images (removed here for brevity). PBOOT should be the last entry and we need to know the image offset for the next step. Your PBOOT should look a little different from the one below, as this is the one from my 53220a.
********************* NOR Flash Images *********************
********************* NAND Flash Images *********************
.....
Image at offset 00320000:
Image Name: PBOOT
Created: 2009-10-22 11:56:02 UTC
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 37189 Bytes = 36.3 KiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
p510>
In my case PBOOT is at 0x320000 in flash. I'm not sure if it's the same across the product range.
Step 6 - Type "nand read 0x600000 0x320000 0x10000" and press enter. Change 0x320000 to the correct address of PBOOT if it is different. This command will load PBOOT from flash into RAM at address 0x600000. This is the same command the device uses when it normally boots except we're only going to print the ram contents and not boot from them.
Step 7 - Type "md.b 0x600000 0x10000" and press enter. This is the memory display command and will display 0x10000 bytes starting at address 0x600000.
Step 8 - The last step, simply right click on the MobaXterm screen and select Copy All. Paste the contents in your favorite text editor and that's in. I can take care of formatting the data and converting it into a binary.
Thanks again! Let me know if you run into any issues. Fingers crossed this works!
-Tim
-
My 34465A looks identical; serial interface identified; obviously the boot loader FW should be the same vintage from ~ 2010.
Concerning the command "protect on all", is this a permanent lock, which I have to reset after the operation?
I fear, otherwise, I would not be able to do a FW update any more.
Frank
-
I believe your correct. I was actually just reading over some u-boot web pages again this morning and had the same thought. http://www.denx.de/wiki/view/DULG/UBootCmdGroupInfo (http://www.denx.de/wiki/view/DULG/UBootCmdGroupInfo)
It might be a good idea to run protect off all after you finish, for exactly the reason you mentioned. Or alternatively you do not have to run the protect command in the beginning.
At the time I was using Putty as my terminal program and it has a rather annoying "feature" where anything that is highlighted by the mouse is automatically copied to the clipboard and just right clicking the mouse button will paste whatever is currently in the clipboard. This is what got me in trouble when I was trying to restore nk.bin. This is also why I recommended MobaXterm, at least there you have to explicitly select copy and paste.
-
OK, thanks, all went fine, appended dump to my recent post.
Have fun, and please report back if this could fix your 34461A!
Frank
-
Well that definitely did the trick, it's able to boot the windows ce kernel (pboot)! Now I need to see about reflashing nk.bin to correct places and see if it will boot up fully, or if there are in fact other issues with my meter. Thanks again!
-
Well the journey continues. PBOOT is working, however it seems that the version of nk.bin that comes with the official firmware update is not in the correct format be loaded directly from ram, or stored in flash and loaded into ram. The attached screenshot shows what the meter looks like after trying to put from nk.bin.
I've read some forum posts regarding Keysight scopes having success booting from the Windows CE platform builder, so I'm attempting to try that now. I'm in the process of updating my Windows XP CE development machine, and will report back with any news.
Cheers
-Tim
-
I was curious, so I took a quick look. The NK.bin file is stored in the compressed XPRS format, so you could try decompressing it first. See https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg1035605/#msg1035605 (https://www.eevblog.com/forum/testgear/dsox2000-and-3000-series-licence-have-anyone-tried-to-hack-that-scope/msg1035605/#msg1035605) for a direct link to bincompress.exe, or you can probably find it somewhere in the Windows CE SDK.
-
Thank you! I had looked at the bk.bin for the 53220a, and compared it to the nand flash on mine and noticed there was quite a difference, this certainly explains things. I'll definitely look into that. I just finished installing VS 2005 and CE 6.0 on an XP VM so I'll take a look in there. I messed around with WinCE 6.0 when the FLIR C3 was released a few years back, but haven't touched it since then, so I've forgetting almost everything.
-
This makes SSOOOO much more sense now. I've been scratching my head all day trying to figure out why it seemed so easy when I loaded the FLIR C3 nk.bin in platform builder, but it just wasn't working with the 34461a firmware until after I decompressed it with the file you mentioned. Sure enough, it was in one of the WinCE directories. Once I decompressed it, I just added it to a project in WinCE like any other file and it opened right up.
I'm uploading it to my meter now via ymodem, so I've got some time to kill before it finished uploading. For whatever reason I never got u-boot to recognize any USB storage devices.
-
Sooo.... I'm going to call this a win. A quick test of a dead 3V coin cell battery and shorting the probes.
(http://[attach=1])
It definitely works, but the serial number and model number are gone and I'm not exactly sure how to restore them.
Also the firmware update fails.
I'll have to read the DSO2000/3000 scope thread as I'm wondering if this issue has come up before. The service manual for the meter warns against swapping the front panel with another unit, so I'm assuming the serial/model number is stored some place in the ARM processor or in the NAND flash.
This correlates to some of the output on saw on the serial port while the unit was booting:
Inguard Bootup Complete -- OK
InguardBootup Buffered Test Signal detected
serialNumberW = 0000000000
rtnCode = 0
serialNumberW = 0000000000
rtnCode = 0
serialNumberW = 0000000000
rtnCode = 0
serialNumberW = 0000000000
rtnCode = 0
serialNumberW = 0000000000
rtnCode = 0
-
The master model/serial # is in the front panel. It is also stored on the mainboard. If you were to buy a new front panel it would be initialized such that when it was first connected it would read the model/serial from your mainboard. It would then be stored in the front panel and can no longer be changed.
There are also SCPI commands to set them, but it is unlikely they will work.
Still worth a shot:
diag:ofinit "SERIAL", "MODEL"
-
I did some more digging and found an interesting u-boot command factory.
p510> help factory
factory - factory - program factory data into NAND memory
Usage:
factory <address>
- the first 2K of RAM <address> will be written to NAND at the appropriate block
p510>
Interestingly, it only takes one argument, the ram address to read from. This means that the NAND address must be hard coded in the function. Sure enough, a few minutes of IDA and we find that the hardcoded NAND address is 0x80000. We also find something that's probably a little more interesting. An undocumented argument. Looking at the pseudo code in IDA, it first checks the number if arguments passed to factory. If that number is equal to 2, it checks to see if the word list is contained in the argument. Following the code, you'll see that passing list will print the factory data stored in NAND. If list is not found it assumes you passed an address and will write the first 2K of the specified address to the NAND address 0x80000
p510> factory list
Manufacturing Data
MAC: XX-XX-XX-XX-XX-XX
GUID: XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXXXXXX
SN: MY99999999
p510>
This should help us understand the exact format the data needs to be in, and allow anyone to reprogram their serial number. Still a little fuzzy on the model number though, unless it is somehow related to the GUID?
-
Hi Tim,
the model is also contained in the serial number, I assume.
MY547xxxxx is for 34470As, MY545xxxxx for the 34465A, please cheek the Serial Number of your 34461A.
Therefore there might be no distinct configuration (model #) parameter.
The hardware platform for all 4 instruments seems to be identical. the 460/461 have the same Mainboard, as well as the 465/470 PCBs are identical, apart from the reference.
The difference between the lower grade instruments vs. the higher grade ones seems to be a different / lesser assembly, to tailor the different features in hardware.
See 'New 34470A review' thread, where we analyzed all PCBs.
The differentiation in features and also the options like Digitizing and Memory is probably set up by firmware switches / keys only.
I assume that KS implemented a strong encryption of all these objects, to prohibit easy modification.
The serial number as well will be encrypted I assume, and as The Steve already claimed, stored in different places.
Anyhow I'm very interested, how to enable the 7 1/2 digit display on my 465A, as I already found out, how to upgrade the reference to the LTZ1000A .
Frank
-
Hey Frank,
Thanks, I'll check out that thread you mentioned. I'm thinking now that factory u-boot command might be some legacy code that is no longer used as the serial number showed in the help -> about menu, even before setting it with the factory command. My serial number starts with MY532, which matches the factory sticker and what is displayed on the screen.
I tried the SCPI command that The Steve mentioned, but as he guessed, it did not work. When I first uploaded new firmware and booted up the meter I saw something about detecting a new processor and taking a few minutes to update something. I wonder if the SCPI command would work when that screen is displayed?
The unfortunate part is I can't seem to be able to do a firmware update from USB or ethernet, due to the missing model number, which is preventing me from being able to get the firmware flashed to NAND. Even after uncompressing nk.bin, it still only loads from RAM. I wrote it to NAND, rebooted and read it back into to RAM and it loaded fine, so I don't think it's a NAND issue. Yet if I write nk.bin to NAND and verify the images with the CE bootloader, the NAND image comes back as invalid, while the RAM image is valid.
It's possible the issue might still be with pboot. I noticed after flashing the version from your meter, that the default NAND addresses are different from the 34461A. The RAM image was the same however at 0x84000000
34365A
Image addresses. (0xdxxxxxxx for NAND, 0x8xxxxxxx for RAM)
1 (0xd0400000)
2 (0xd1700000)
34461A
nimages=2
image1=0xd0620000
image2=0xd2120000
-
I made some errata to my former post, and here's the correct link to the discussion of the 461/465/470:
https://www.eevblog.com/forum/testgear/keysight_s-new-34465a-(6-5-digit)-and-34470a-(7-5-digit)-bench-multimeters/150/ (https://www.eevblog.com/forum/testgear/keysight_s-new-34465a-(6-5-digit)-and-34470a-(7-5-digit)-bench-multimeters/150/)
some pages earlier or later, we already discussed possible feature switches, afair.
If I remember correctly, during the normal boot process, the serial number is displayed on the serial monitor.. and I did not blank my serial number inside the pboot dump file.
Frank
-
So looks like the DIAG:OFINIT SCPI command worked after all. It didn't work immediately after getting the new cpu alert, but after repeatedly sending the command I noticed I stopped getting errors on the scoped. I thought maybe I just broke SCPI, after a reboot now I see it actually has a model number. For another test I ran *IDN? and this time it actually worked. The first time I tried this after flashing new firmware, my scope crashed and reset.
-
Very nice that it worked! I have a different device I'd like to reset the model and serial # on. Any thoughts on exactly what was erased to lose the model/serial #? If the model/serial # are set the command certainly doesn't work.
-
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
-
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 #.
-
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
-
I have a 34461A - maybe I should dump the pboot from it.
-
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
-
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.
-
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.
-
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?
[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?
-
The Steve - Ooooofff, unfortunately that makes sense with what I saw in the decompiler.[attachimg=1] <--- 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
-
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.
-
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
-
This is starting to get interesting. [attachimg=1]
-
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.
-
Awesome, glad to hear things are back to normal.... errr pre-factory info
-Tim
-
So your 34461A works, but only if you tell it where to boot the image from manually?
-
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.
-
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?
-
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.
-
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 (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.
-
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
-
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.
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
-
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 (https://www.micron.com/-/media/client/global/documents/products/data-sheet/nand-flash/60-series/m68a_1gb_nand.pdf)
-Tim
-
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.
#################### 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
-
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:
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:
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
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 |O |O |O |O :palm: :palm:
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
-
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?
-
I managed to get into the bootloader menu on my good meter (you must be very quick in pressing the space after bootcmd command) and as I expected, there the image addresses are d0620000 and d2120000 which matches the env variables. and also the "v" command (verify images) works but on my bad meter the image addresses are wrong and the verify command just hangs and i have to power down.
definitely the unit tries to read image from wrong address.
where are the bootloader parameters stored?
I checked my p-boot dump and it is exactly identical to the good meter
-
does anybody know where is the 64kB flash memory indicated in the u-boot:
CPU: SPEAr320
DRAM: 128 MiB
Unknown id: 0xffffff. Using ST_M23P40
Flash: 64 KiB
NAND: INTERNAL ECC 128 MiB
there is not flash memory on the board. Just the NAND and RAM.
-
even the difference between the wrong image addresses is about 19MB which is too small. I mean if one image would have been at d0400000 it would have overlapped with the second image.
where does pboot gets it boot parameters from?
I just noticed that when the bootloader stops it also reports a false MAC address 04:02:02:20:02:02 instead of the correct one 80:09:02:0e:7a:4f
nonetheless I am able to use "download from platform builder" option to get the nk.bin file over the ethernet and boot the meter. It gets IP using the wrong MAC address. But after booting, the meter shows the correct mac address!?
So it is reading whole bunch of wrong boot parameters from somewhere...
-
@ElectronMan or @TheSteve might give you a hand here.
-
mabe searching windows CE or embedded booting processes could give an hint ??
-
@ElectronMan or @TheSteve might give you a hand here.
I hope they come here and have a look
FWIW here is the .bin file of the P-Boot taken from my good 34461A and it is identical to the one from the bad meter
and also identical to those posted earlier in this thread by others
I am not able to figure out where it is getting its boot parameters from. Certainly not from the environment variables
because they are ok. Unless there is another hidden copy of them which is bad?
-
@ElectronMan or @TheSteve might give you a hand here.
I hope they come here and have a look
FWIW here is the .bin file of the P-Boot taken from my good 34461A and it is identical to the one from the bad meter
and also identical to those posted earlier in this thread by others
I am not able to figure out where it is getting its boot parameters from. Certainly not from the environment variables
because they are ok. Unless there is another hidden copy of them which is bad?
This looks like a problem with the CE bootloader (the stage after Uboot) or the flash. It could be that part of the NAND flash is completely unusable.
Do you happen to have the output when updating firmware? Are there any errors while writing the image?
-
@ElectronMan or @TheSteve might give you a hand here.
I hope they come here and have a look
FWIW here is the .bin file of the P-Boot taken from my good 34461A and it is identical to the one from the bad meter
and also identical to those posted earlier in this thread by others
I am not able to figure out where it is getting its boot parameters from. Certainly not from the environment variables
because they are ok. Unless there is another hidden copy of them which is bad?
This looks like a problem with the CE bootloader (the stage after Uboot) or the flash. It could be that part of the NAND flash is completely unusable.
Do you happen to have the output when updating firmware? Are there any errors while writing the image?
yes the bootloader is reading wrong parameters (image address, mac address, ...are all wrong)
when the unit was updating FW the UART was connected but there were no messages.
as far as I can tell the part of FW update that finished was just copying the Nk.bin (original from the FW pack) into d0620000 and I can see it is there and seems to be correct. But I guess the FW will also do some stuff after rebooting the unit however in this case it does not get there because on the reboot, it reads the wrong addresses and fails to boot.
-
@ElectronMan or @TheSteve might give you a hand here.
I hope they come here and have a look
FWIW here is the .bin file of the P-Boot taken from my good 34461A and it is identical to the one from the bad meter
and also identical to those posted earlier in this thread by others
I am not able to figure out where it is getting its boot parameters from. Certainly not from the environment variables
because they are ok. Unless there is another hidden copy of them which is bad?
This looks like a problem with the CE bootloader (the stage after Uboot) or the flash. It could be that part of the NAND flash is completely unusable.
Do you happen to have the output when updating firmware? Are there any errors while writing the image?
yes the bootloader is reading wrong parameters (image address, mac address, ...are all wrong)
when the unit was updating FW the UART was connected but there were no messages.
as far as I can tell the part of FW update that finished was just copying the Nk.bin (original from the FW pack) into d0620000 and I can see it is there and seems to be correct. But I guess the FW will also do some stuff after rebooting the unit however in this case it does not get there because on the reboot, it reads the wrong addresses and fails to boot.
Yeah, it looks like it loads those parameters from a location that it can't read right now, so loads those incorrect settings instead.:
CRC does not match for NAND AFFF475B F381A23
ERROR : Bootloader setting load failed
INFO : Loading default bootloader settings
I am trying to locate this config information
-
what is interesting is that earlier in the thread where @dc101 had very similar issue as mine, he also reported the pboot is thinking image addresses are d0400000 and d1700000 exactly like my unit! :-// :-//
I have also seen a similar issue in some broken 3000A scopes that also reported image address at d0400000 which again wrong for those scopes.
-
FWIW when I get the pboot prompt to choose how to boot and I choose option "d" (download from platform builder) here is the boot log until the unit is fully booted and the meter works perfectly after that for hours until I turn it off
......
FMD_DirectRead: Invalid block at sector 0xffc0 bumping by 0x40 sectors
CRC does not match for NAND AF7F475B 3665EF2
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 5 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
>System ready!
Preparing for download...
No RTC on 320
Downloading image from platform builder
Setting MAC address GMAC_MAC_ADDR_HI_LO[0] = 0x80000202, GMAC_MAC_ADDR_HI_LO[1] = 0x20020204
Auto Negotiation complete in 120192 iterations
Link up
AutoNegotiate Full Duplex
AutoNegotiate 100 Base T
Reading MAC address 0x402 0x220 0x202
Setting MAC address GMAC_MAC_ADDR_HI_LO[0] = 0x80000202, GMAC_MAC_ADDR_HI_LO[1] = 0x20020204
INFO: GMAC Ethernet controller initialized.
InitDHCP():: Calling ProcessDHCP()
ProcessDHCP()::DHCP_INIT
Got Response from DHCP server, IP address: 10.0.0.13
ProcessDHCP()::DHCP IP Address Resolved as 10.0.0.13, netmask: 255.255.255.0
Lease time: 172800 seconds
Got Response from DHCP server, IP address: 10.0.0.13
No ARP response in 2 seconds, assuming ownership of 10.0.0.13
+EbootSendBootmeAndWaitForTftp
Sent BOOTME to 255.255.255.255
Packet has the following data:
boot.bin[NULL]octet[NULL]
TFTP packet could have 1 name/value pairs
Locked Down Link 1
Src IP 10.0.0.13 Port 03D4 Dest IP 10.0.0.223 Port 0499
Default TFTP block size set to: 512 bytes
There were no options detected in the TFTP
EthDown::TFTPD_OPEN::boot.bin
-EbootSendBootmeAndWaitForTftp
BL_IMAGE_TYPE_BIN
X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXrom_offset=0x0.
XXImageStart = 0x80361000, ImageLength = 0x185E320, LaunchAddr = 0x80362000
Completed file(s):
-------------------------------------------------------------------------------
[0]: Address=0x80361000 Length=0x185E320 Name="" Target=RAM
Loading image 3 succeeded.
ROMHDR at Address 80361044h
Preparing launch...
No RTC on 320
Got EDBG_CMD_JUMPIMG
Got EDBG_CMD_CONFIG, flags:0x00000000
Launching windows CE image by jumping at address 0x 362000
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 Jul 2 2021)
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
ERROR: C:\WINCE600\PLATFORM\COMMON\SRC\SOC\STM\SPEARHEAD600\DRIVERS\NandFlash\.\sh600_NandFlash.c line 57: ConfigTimming - Unable to opey
ERROR: C:\WINCE600\PLATFORM\COMMON\SRC\SOC\STM\COMMON\DRIVERS\NandFlash\.\stm_NandFlash.c line 1043: LLD_GetInfo - Unable to open devicey
++SER_Init: context Drivers\Active\10
SER_Init, dwIndex:2
GPIO_Select0 Register 0xB300_0024: 0x80000000
Control Register 0xB300_0010 : 0x00000040
RAS Select Register 0xB300_000C: 0xffffacf4
CORE_CLK_CFG 0xB300_0024: 0x80000000
SER2 got sysintr:0x00000013
SER2 Serial Port, new baud rate:0x1c200 (UARTCLK:83250000 IBRD:0x2d FBRD:0xa)
++SER_Init: context Drivers\Active\11
SER_Init, dwIndex:3
GPIO_Select0 Register 0xB300_0024: 0x80000000
Control Register 0xB300_0010 : 0x00000040
RAS Select Register 0xB300_000C: 0xffffacf4
CORE_CLK_CFG 0xB300_0024: 0x80000000
+OALIntrRequestSysIntr IRQ (1) already used by SYSINTR (19)
SER3 got sysintr:0x00000014
SER3 Serial Port, new baud rate:0x1c200 (UARTCLK:83250000 IBRD:0x2d FBRD:0xa)
OHCI\system.c, GCFG_USBH1_SW_RST
OHCI\system.c, GCFG_USBH2_SW_RST
-EDeviceLoadEeprom 80:09:02:0E:7A:4F
Phy found addr 7 (ticks=5100)
WaitForLink Start (ticks=5101)
Link Detected (ticks=5104)
GMAC Init : 100 Mbit/s FULL DUPLEX (MII)
Flushed Transmit Buffer
phyCfg->dwSpeed 0x64
<--EDeviceInitialize
GMAC DMA status register = 0x600004
GMAC Device enable interrupt
DriverStart
GMAC Device enable interrupt
LIN: Data Valid
Resetting the USB-device silicon
sh600_pdd, IOCTL_BUS_POSTINIT
ERROR: C:\WINCE600\3RDPARTY\Agilent\HPP\Common\Drivers\stm320_UsbFnBusDriver\.\ufnbus.cpp line 1137: failed opening \Agilent Flash\SPD\ue
6
Autonegociation Start (ticks=7141)
+StartAutoNegotiation: pDeviceContext 0xd0506be0
Autonegociation End (ticks=9651)
WaitForLink Start (ticks=9652)
Link Detected (ticks=9655)
GMAC Init : 100 Mbit/s FULL DUPLEX (MII)
cable attached
SHIM DLL, LoadRealDll [PalSysManagement.dll] for [AgilentPalSysManagement.dll]
SHIM [AgilentPalSysManagement.dll] Get Process Addresses
SHIM DLL, LoadRealDll [PalIO.dll] for [AgilentPalIO.dll]
SHIM [AgilentPalIO.dll] Get Process Addresses
#################### dllEntry ###########################
FP:Platform identified as MSP430-type based on 1182 mV
FP:IdEprom File [\Windows\AgtFrontPanelIdEpromData.34460-66502.xml] does not exist
FP:Platform identified as MSP430-type based on 1184 mV
FP:IdEprom File [\Windows\AgtFrontPanelIdEpromData.34460-66502.xml] does not exist
SER3 Serial Port, new baud rate:0x2faf08 (UARTCLK:83250000 IBRD:0x1 FBRD:0x2a)
Inguard Bootup Complete -- OK
InguardBootup Buffered Test Signal detected
FP:INVALID CID read, 0x01
FP:INVALID CID read, 0xff
FP:INVALID CID read, 0xff
FP:INVALID CID read, 0x33
FP:INVALID CID read, 0x16
FP:INVALID CID read, 0x88
FP:INVALID CID read, 0x6b
FP:INVALID CID read, 0x40
FP:DoCommand [2] FAILED 0x[80040302]
FP:DoCommand [2] Retry [1] Error was 0x[80040302]
FP:DoCommand [2] Final call Error 0x[0]
SHIM DLL, LoadRealDll [PalCaps.dll] for [AgilentPalCaps.dll]
SHIM [AgilentPalCaps.dll] Get Process Addresses
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
SHIM DLL, LoadRealDll [PalWin32.dll] for [AgilentPalWin32.dll]
SHIM [AgilentPalWin32.dll] Get Process Addresses
SHIM DLL, LoadRealDll [PalSStorage.dll] for [AgilentPalSStorage.dll]
SHIM [AgilentPalSStorage.dll] Get Process Addresses
SHIM DLL, LoadRealDll [PalSysManagement.dll] for [AgilentPalSysManagement.dll]
SHIM [AgilentPalSysManagement.dll] Get Process Addresses
SHIM DLL, LoadRealDll [PalCaps.dll] for [AgilentPalCaps.dll]
SHIM [AgilentPalCaps.dll] Get Process Addresses
AgilentLxiWebStartUp successfully started LXI web service.]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 AF7F475B 3665EF2
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 5 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
>System ready!
Preparing for download...
No RTC on 320
Downloading image from platform builder
Setting MAC address GMAC_MAC_ADDR_HI_LO[0] = 0x80000202, GMAC_MAC_ADDR_HI_LO[1] = 0x20020204
Auto Negotiation complete in 120192 iterations
Link up
AutoNegotiate Full Duplex
AutoNegotiate 100 Base T
Reading MAC address 0x402 0x220 0x202
Setting MAC address GMAC_MAC_ADDR_HI_LO[0] = 0x80000202, GMAC_MAC_ADDR_HI_LO[1] = 0x20020204
INFO: GMAC Ethernet controller initialized.
InitDHCP():: Calling ProcessDHCP()
ProcessDHCP()::DHCP_INIT
Got Response from DHCP server, IP address: 10.0.0.13
ProcessDHCP()::DHCP IP Address Resolved as 10.0.0.13, netmask: 255.255.255.0
Lease time: 172800 seconds
Got Response from DHCP server, IP address: 10.0.0.13
No ARP response in 2 seconds, assuming ownership of 10.0.0.13
+EbootSendBootmeAndWaitForTftp
Sent BOOTME to 255.255.255.255
Packet has the following data:
boot.bin[NULL]octet[NULL]
TFTP packet could have 1 name/value pairs
Locked Down Link 1
Src IP 10.0.0.13 Port 03D4 Dest IP 10.0.0.223 Port 0499
Default TFTP block size set to: 512 bytes
There were no options detected in the TFTP
EthDown::TFTPD_OPEN::boot.bin
-EbootSendBootmeAndWaitForTftp
BL_IMAGE_TYPE_BIN
X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXrom_offset=0x0.
XXImageStart = 0x80361000, ImageLength = 0x185E320, LaunchAddr = 0x80362000
Completed file(s):
-------------------------------------------------------------------------------
[0]: Address=0x80361000 Length=0x185E320 Name="" Target=RAM
Loading image 3 succeeded.
ROMHDR at Address 80361044h
Preparing launch...
No RTC on 320
Got EDBG_CMD_JUMPIMG
Got EDBG_CMD_CONFIG, flags:0x00000000
Launching windows CE image by jumping at address 0x 362000
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 Jul 2 2021)
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
ERROR: C:\WINCE600\PLATFORM\COMMON\SRC\SOC\STM\SPEARHEAD600\DRIVERS\NandFlash\.\sh600_NandFlash.c line 57: ConfigTimming - Unable to opey
ERROR: C:\WINCE600\PLATFORM\COMMON\SRC\SOC\STM\COMMON\DRIVERS\NandFlash\.\stm_NandFlash.c line 1043: LLD_GetInfo - Unable to open devicey
++SER_Init: context Drivers\Active\10
SER_Init, dwIndex:2
GPIO_Select0 Register 0xB300_0024: 0x80000000
Control Register 0xB300_0010 : 0x00000040
RAS Select Register 0xB300_000C: 0xffffacf4
CORE_CLK_CFG 0xB300_0024: 0x80000000
SER2 got sysintr:0x00000013
SER2 Serial Port, new baud rate:0x1c200 (UARTCLK:83250000 IBRD:0x2d FBRD:0xa)
++SER_Init: context Drivers\Active\11
SER_Init, dwIndex:3
GPIO_Select0 Register 0xB300_0024: 0x80000000
Control Register 0xB300_0010 : 0x00000040
RAS Select Register 0xB300_000C: 0xffffacf4
CORE_CLK_CFG 0xB300_0024: 0x80000000
+OALIntrRequestSysIntr IRQ (1) already used by SYSINTR (19)
SER3 got sysintr:0x00000014
SER3 Serial Port, new baud rate:0x1c200 (UARTCLK:83250000 IBRD:0x2d FBRD:0xa)
OHCI\system.c, GCFG_USBH1_SW_RST
OHCI\system.c, GCFG_USBH2_SW_RST
-EDeviceLoadEeprom 80:09:02:0E:7A:4F
Phy found addr 7 (ticks=5100)
WaitForLink Start (ticks=5101)
Link Detected (ticks=5104)
GMAC Init : 100 Mbit/s FULL DUPLEX (MII)
Flushed Transmit Buffer
phyCfg->dwSpeed 0x64
<--EDeviceInitialize
GMAC DMA status register = 0x600004
GMAC Device enable interrupt
DriverStart
GMAC Device enable interrupt
LIN: Data Valid
Resetting the USB-device silicon
sh600_pdd, IOCTL_BUS_POSTINIT
ERROR: C:\WINCE600\3RDPARTY\Agilent\HPP\Common\Drivers\stm320_UsbFnBusDriver\.\ufnbus.cpp line 1137: failed opening \Agilent Flash\SPD\ue
6
Autonegociation Start (ticks=7141)
+StartAutoNegotiation: pDeviceContext 0xd0506be0
Autonegociation End (ticks=9651)
WaitForLink Start (ticks=9652)
Link Detected (ticks=9655)
GMAC Init : 100 Mbit/s FULL DUPLEX (MII)
cable attached
SHIM DLL, LoadRealDll [PalSysManagement.dll] for [AgilentPalSysManagement.dll]
SHIM [AgilentPalSysManagement.dll] Get Process Addresses
SHIM DLL, LoadRealDll [PalIO.dll] for [AgilentPalIO.dll]
SHIM [AgilentPalIO.dll] Get Process Addresses
#################### dllEntry ###########################
FP:Platform identified as MSP430-type based on 1182 mV
FP:IdEprom File [\Windows\AgtFrontPanelIdEpromData.34460-66502.xml] does not exist
FP:Platform identified as MSP430-type based on 1184 mV
FP:IdEprom File [\Windows\AgtFrontPanelIdEpromData.34460-66502.xml] does not exist
SER3 Serial Port, new baud rate:0x2faf08 (UARTCLK:83250000 IBRD:0x1 FBRD:0x2a)
Inguard Bootup Complete -- OK
InguardBootup Buffered Test Signal detected
FP:INVALID CID read, 0x01
FP:INVALID CID read, 0xff
FP:INVALID CID read, 0xff
FP:INVALID CID read, 0x33
FP:INVALID CID read, 0x16
FP:INVALID CID read, 0x88
FP:INVALID CID read, 0x6b
FP:INVALID CID read, 0x40
FP:DoCommand [2] FAILED 0x[80040302]
FP:DoCommand [2] Retry [1] Error was 0x[80040302]
FP:DoCommand [2] Final call Error 0x[0]
SHIM DLL, LoadRealDll [PalCaps.dll] for [AgilentPalCaps.dll]
SHIM [AgilentPalCaps.dll] Get Process Addresses
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
SHIM DLL, LoadRealDll [PalWin32.dll] for [AgilentPalWin32.dll]
SHIM [AgilentPalWin32.dll] Get Process Addresses
SHIM DLL, LoadRealDll [PalSStorage.dll] for [AgilentPalSStorage.dll]
SHIM [AgilentPalSStorage.dll] Get Process Addresses
SHIM DLL, LoadRealDll [PalSysManagement.dll] for [AgilentPalSysManagement.dll]
SHIM [AgilentPalSysManagement.dll] Get Process Addresses
SHIM DLL, LoadRealDll [PalCaps.dll] for [AgilentPalCaps.dll]
SHIM [AgilentPalCaps.dll] Get Process Addresses
AgilentLxiWebStartUp successfully started LXI web service.
the MAC address is wrong at this point but when the meter boots it has the correct MAC address and its IP becomes 10.0.0.7
instead of 10.0.0.13
-
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?
The PBOOT loader is trying to read the config from sector 0x180 in flash. It appears to be using flash page-sized sectors of 2048 bytes, so that puts it at the beginning of the 7th flash block at byte 0xC0000. In my flash, that contains this config, with a CRC32 in the first 4 bytes. It looks similar to the UBOOT config, but is null-separated (I've attached a copy). If you can read that flash location and see what is there, it may illuminate things.
With any luck, that block just needs rewritten.
-
The PBOOT loader is trying to read the config from sector 0x180 in flash. It appears to be using flash page-sized sectors of 2048 bytes, so that puts it at the beginning of the 7th flash block at byte 0xC0000. In my flash, that contains this config, with a CRC32 in the first 4 bytes. It looks similar to the UBOOT config, but is null-separated (I've attached a copy). If you can read that flash location and see what is there, it may illuminate things.
With any luck, that block just needs rewritten.
yes it seems a duplicate of the environment variables that I see in uboot and everything looks normal exactly like what I see in the uboot variables
the image addresses and MAC are correct.
note that I had changed my ipaddr variable to 10.0.0.242 (my tftp server) the default value is 000.000.000.000
but it is not related to the problem
is it possible that this is the place that uboot environment variables are stored? which we can see by printenv command. Because it is exactly those information
-
The PBOOT loader is trying to read the config from sector 0x180 in flash. It appears to be using flash page-sized sectors of 2048 bytes, so that puts it at the beginning of the 7th flash block at byte 0xC0000. In my flash, that contains this config, with a CRC32 in the first 4 bytes. It looks similar to the UBOOT config, but is null-separated (I've attached a copy). If you can read that flash location and see what is there, it may illuminate things.
With any luck, that block just needs rewritten.
yes it seems a duplicate of the environment variables that I see in uboot and everything looks normal exactly like what I see in the uboot variables
the image addresses and MAC are correct.
note that I had changed my ipaddr variable to 10.0.0.242 (my tftp server) the default value is 000.000.000.000
but it is not related to the problem
is it possible that this is the place that uboot environment variables are stored? which we can see by printenv command. Because it is exactly those information
It is likely, if they are sharing the config. If you change a variable in uboot, does it change at that flash location?
On a related note, have you tried changing the uboot config since the problem started? The reason I ask, is because page ECC data is re-written with the data. So if for some reason PBOOT is seeing bad ECC on that page, re-writing it by a config change may fix it.
-
but wait a second, I only changed "serverip" variable to 10.0.0.242 and never touched "ipaddr" variable. Also in my uboot variable I see that ipaddr variable still has its factory value like yours. However it shows different in this dump
Also I notice that at the end of the dump it looks weird.... like " ..} ..c}..." looks out of place, no?
-
The PBOOT loader is trying to read the config from sector 0x180 in flash. It appears to be using flash page-sized sectors of 2048 bytes, so that puts it at the beginning of the 7th flash block at byte 0xC0000. In my flash, that contains this config, with a CRC32 in the first 4 bytes. It looks similar to the UBOOT config, but is null-separated (I've attached a copy). If you can read that flash location and see what is there, it may illuminate things.
With any luck, that block just needs rewritten.
yes it seems a duplicate of the environment variables that I see in uboot and everything looks normal exactly like what I see in the uboot variables
the image addresses and MAC are correct.
note that I had changed my ipaddr variable to 10.0.0.242 (my tftp server) the default value is 000.000.000.000
but it is not related to the problem
is it possible that this is the place that uboot environment variables are stored? which we can see by printenv command. Because it is exactly those information
It is likely, if they are sharing the config. If you change a variable in uboot, does it change at that flash location?
On a related note, have you tried changing the uboot config since the problem started? The reason I ask, is because page ECC data is re-written with the data. So if for some reason PBOOT is seeing bad ECC on that page, re-writing it by a config change may fix it.
the only thing that I had done was just changed "serverip" variable to my tftp server address because at that point I though I could recover it through tftp which was stupid because there is no lan available but other than that no. I have not played with uboot variables anymore
-
The PBOOT loader is trying to read the config from sector 0x180 in flash. It appears to be using flash page-sized sectors of 2048 bytes, so that puts it at the beginning of the 7th flash block at byte 0xC0000. In my flash, that contains this config, with a CRC32 in the first 4 bytes. It looks similar to the UBOOT config, but is null-separated (I've attached a copy). If you can read that flash location and see what is there, it may illuminate things.
With any luck, that block just needs rewritten.
I cannot reproduce your CRC32 checksum so that I can check mine.
but the end of that dump looks out of place to me
-
The PBOOT loader is trying to read the config from sector 0x180 in flash. It appears to be using flash page-sized sectors of 2048 bytes, so that puts it at the beginning of the 7th flash block at byte 0xC0000. In my flash, that contains this config, with a CRC32 in the first 4 bytes. It looks similar to the UBOOT config, but is null-separated (I've attached a copy). If you can read that flash location and see what is there, it may illuminate things.
With any luck, that block just needs rewritten.
I cannot reproduce your CRC32 checksum so that I can check mine.
but the end of that dump looks out of place to me
Your checksum is good assuming you had 00's out to the end of that sector. I had to pad it out with zeros to the end of that page (like it should be in your flash). If the rest of that sector is not filled with 00's in your copy, then something is wrong.
-
I changed that serverip back to its original value and actually when you run "saveenv" in uboot it in fact erases one page of nand at that 0xC0000 address and writes the variables back into that place. Messages on screen are clearly saying this.
So 0xC0000 is in fact where the uboot variables are stored.
Now I am not sure pboot is getting its parameters from there
-
I changed that serverip back to its original value and actually when you run "saveenv" in uboot it in fact erases one page of nand at that 0xC0000 address and writes the variables back into that place. Messages on screen are clearly saying this.
So 0xC0000 is in fact where the uboot variables are stored.
Now I am not sure pboot is getting its parameters from there
So since they are sharing the config, there must be some other reason PBOOT doesn't like that block the data is stored in, that does not bother UBOOT.
Looking at the PBOOT code, I am trying to find where it checks the ECC/Error status flag and not finding it so far. I am starting to wonder if they are storing their own data in the spare area of that page that might be corrupted.
-
I changed "serverip" back to its original value and ran "saveenv" and dumped the nand at 0xC0000 again
here is the new dump. saveenv actually writes the variables in this place. so no surprises there
this time I dumped a whole page 2048 bytes but still I cannot get the CRC32 :-[
-
I changed "serverip" back to its original value and ran "saveenv" and dumped the nand at 0xC0000 again
here is the new dump. saveenv actually writes the variables in this place. so no surprises there
this time I dumped a whole page 2048 bytes but still I cannot get the CRC32 :-[
Sorry, my fault, that is more than a whole page that is CRC'd. It runs to the end of all the 0's in my flash. The total data length for the CRC32 should be 0x3FFC (0x4000 minus the CRC32 at the beginning).
Also, I mentioned ECC before, this flash chip does not seem to have ECC, so that increases my suspicions they are doing something else, possibly in the spare area, for data integrity.
I am seeing what appears to be checking of the SPARE area (64 bytes past the end of the page) on page reads.
-
Sorry, my fault, that is more than a whole page that is CRC'd. It runs to the end of all the 0's in my flash. The total data length for the CRC32 should be 0x3FFC (0x4000 minus the CRC32 at the beginning).
Also, I mentioned ECC before, this flash chip does not seem to have ECC, so that increases my suspicions they are doing something else, possibly in the spare area, for data integrity.
I am seeing what appears to be checking of the SPARE area (64 bytes past the end of the page) on page reads.
I remember back in 3000A scope thread there was talk of spare/duplicate copy of the env variables. I think @tv84 had posted its location address but I cannot remember where it was. With similarities between these two instruments at boot time I also suspected there is another copy of these somewhere else and pboot it using those when it does not match the one at 0xc0000
-
Sorry, my fault, that is more than a whole page that is CRC'd. It runs to the end of all the 0's in my flash. The total data length for the CRC32 should be 0x3FFC (0x4000 minus the CRC32 at the beginning).
Also, I mentioned ECC before, this flash chip does not seem to have ECC, so that increases my suspicions they are doing something else, possibly in the spare area, for data integrity.
I am seeing what appears to be checking of the SPARE area (64 bytes past the end of the page) on page reads.
I remember back in 3000A scope thread there was talk of spare/duplicate copy of the env variables. I think @tv84 had posted its location address but I cannot remember where it was. With similarities between these two instruments at boot time I also suspected there is another copy of these somewhere else and pboot it using those when it does not match the one at 0xc0000
It does support falling back to a backup config, but I don't see any other copies. That is probably optional (which would be why yours isn't attempting to load it). What does the spare area after that first page of the config look like?
-
It does support falling back to a backup config, but I don't see any other copies. That is probably optional (which would be why yours isn't attempting to load it). What does the spare area after that first page of the config look like?
all 00 all the way up to 0xC4000
still no luck in reproducing the crc32 though :-[ :-[
-
It does support falling back to a backup config, but I don't see any other copies. That is probably optional (which would be why yours isn't attempting to load it). What does the spare area after that first page of the config look like?
all 00 all the way up to 0xC4000
Are you certain you are reading the spare area? It is the extra 0x40 (64) bytes after the end of the 0x800 byte page. How were you reading the flash?
There is definitely some calculation it is doing with the spare area in the code before it decides it is a bad block... I am just not sure what algorithm it is using.
-
Are you certain you are reading the spare area? It is the extra 0x40 (64) bytes after the end of the 0x800 byte page. How were you reading the flash?
There is definitely some calculation it is doing with the spare area in the code before it decides it is a bad block... I am just not sure what algorithm it is using.
I could be quite wrong about this. So here is what I did for this last dump:
p510> nand read 0x800000 0xc0000 0x4000
.
.
p510> md.b 0x800000 0x4000
so 0x4000 in the nand read might not mean the same as 0x4000 in the memory read?
-
for the previous dump I used 0x800 instead of 0x4000 in nand read
but as you see the length of the file is 0x4000 and the first 4 bytes are crc32 and that leaves 0x3ffc of data as you suggested
-
ok for crc calculation I skip the first 4 bytes and select everything all the way up to 0x83F and do a crc32
i also tried selecting up to 0x7FF and also up to 0x3FFF and I never get those 4 bytes
I am using HxD hex editor to do that
-
for the previous dump I used 0x800 instead of 0x4000 in nand read
but as you see the length of the file is 0x4000 and the first 4 bytes are crc32 and that leaves 0x3ffc of data as you suggested
for the previous dump I used 0x800 instead of 0x4000 in nand read
but as you see the length of the file is 0x4000 and the first 4 bytes are crc32 and that leaves 0x3ffc of data as you suggested
I would guess that command is not including the spare area, as that is stored at a "lower level" on the flash and is usually not used by applications.
Every page is actually 0x840 bytes long. the last 0x40 bytes is typically used to store meta data (bad blocks, ECC information, etc) and is usually invisible for higher-level operations.
Looking at the code, I see what appears to be some software-implemented ECC check that is operating on the spare pages, just before the program decides to throw up that block read failure.
My guess is that data is not checking out, and causing the PBOOT to report a failure, despite the data actually being good.
UBOOT may not be implementing this check.
-
ok for crc calculation I skip the first 4 bytes and select everything all the way up to 0x83F and do a crc32
i also tried selecting up to 0x7FF and also up to 0x3FFF and I never get those 4 bytes
I am using HxD hex editor to do that
I am starting at 0xc0000 + 4 to skip the CRC, then running to 0xC3FF. The CRC32 is good on my area when I do that, and is also good on yours if I pad it out to that length with 00's (you didn't send me the whole thing to test).
So is there anything in there to the end of that area that isn't 00? I am using the CRC-32 in 010 Editor.
-
I can use the nand dump command which only dumps one page 0x800 at a time but it also dumps the out of band (.oob) data for that page
is that what you mean?
-
There is a slight chance, that rewriting all the pages in that block could cause the it to re-write the spare area ECC calculations. But that depends on whether the ting you are using to re-write those areas actually implements the ECC algorithm and updates it.
The idea would be that you write that block back exactly as it already exists, and see if the writing process takes care of whatever errors are present in the spare.
In my flash, that entire block is just the config padded by 0s followed by empty space.
-
I can use the nand dump command which only dumps one page 0x800 at a time but it also dumps the out of band (.oob) data for that page
is that what you mean?
Yes, oob is another name for the spare, so that should do the trick.
-
Yes, oob is another name for the spare, so that should do the trick.
I added those extra 0x40 bytes to the end of the 0x800 bytes page and made a bin file (attached)
still not getting those starting 4 bytes as CRC32 :-[ :-[
-
here it is
Thanks. That looks significantly different than mine.
I think what I am going to suggest is that you dump the entire block (64 * 2048 byte pages) starting at that 0xc0000 offset and then re-write exactly the same block back to flash if you can under the Uboot prompt.
Unless there is some actual physical flash damage, that should get the spare areas back in sync for the block.
Of course, this is taking a risk, so usual disclaimer here...
-
here it is
Thanks. That looks significantly different than mine.
I think what I am going to suggest is that you dump the entire block (64 * 2048 byte pages) starting at that 0xc0000 offset and then re-write exactly the same block back to flash if you can under the Uboot prompt.
Unless there is some actual physical flash damage, that should get the spare areas back in sync for the block.
Of course, this is taking a risk, so usual disclaimer here...
oh no you looked at the wrong file, I messed up there and deleted that message already :-[ :-[
please look at the bin file I just posted. change the extension to .bin
-
the file i posted earlier and you looked at was supposed to be this one here but I dont know what happened
it is just the plain text. Then I made a bin file from it and posted above
-
here it is
Thanks. That looks significantly different than mine.
I think what I am going to suggest is that you dump the entire block (64 * 2048 byte pages) starting at that 0xc0000 offset and then re-write exactly the same block back to flash if you can under the Uboot prompt.
Unless there is some actual physical flash damage, that should get the spare areas back in sync for the block.
Of course, this is taking a risk, so usual disclaimer here...
oh no you looked at the wrong file, I messed up there and deleted that message already :-[ :-[
please look at the bin file I just posted. change the extension to .bin
Looks the same. (I had taken the text and copied it into my hex editor to reproduce it).
The disturbing thing is that looking at your boot process, it basically told you that every block up to the end of flash from there has the same issue, which points to possible physical damage.
I would still try rewriting that block and see if the error clears for that one, but you may have other errors if that fixes the boot config block.
-
it does not look out of ordinary to me
by the way, if i want to dump the nand and write it back into the nand in uboot
I cannot write into those out of band areas. "nand dump" dumps one page at a time with those oob
but nand write has no way of writing in those oob area unless they are calculated automatically and updated by the nand controller
in that case I can just read the data by nand read and write it back instead of sumping one page at a time
I am only concerned about nand write command because still I am not sure what is the third parameter
is it a page size or is it # of bytes or some other block size? that scares me :scared: :scared:
-
can you point me to what errors/problems you see in that last bin file with .oob data?
-
can you point me to what errors/problems you see in that last bin file with .oob data?
Without knowing the exact structure they are using, I can't say what is wrong with it exactly, except that the structure appears to be different. There could be a lot of reasons for this. See my spare on the first page for the config below.
FF FF FF FF FF FF FF FF 95 A5 6A 69 59 FF FF FF
6A F3 3F CC FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Yours has more actual data in it, and is only filling the one side. Since these are structured in a very specific way, it is unusual to see such a large difference.
-
it does not look out of ordinary to me
by the way, if i want to dump the nand and write it back into the nand in uboot
I cannot write into those out of band areas. "nand dump" dumps one page at a time with those oob
but nand write has no way of writing in those oob area unless they are calculated automatically and updated by the nand controller
in that case I can just read the data by nand read and write it back instead of sumping one page at a time
I am only concerned about nand write command because still I am not sure what is the third parameter
is it a page size or is it # of bytes or some other block size? that scares me :scared: :scared:
DO NOT try to write the OOB data. Just rewrite the block normally. The functions that write the block SHOULD calculate the data that needs to go into the OOB and write it for you!
-
it does not look out of ordinary to me
by the way, if i want to dump the nand and write it back into the nand in uboot
I cannot write into those out of band areas. "nand dump" dumps one page at a time with those oob
but nand write has no way of writing in those oob area unless they are calculated automatically and updated by the nand controller
in that case I can just read the data by nand read and write it back instead of sumping one page at a time
I am only concerned about nand write command because still I am not sure what is the third parameter
is it a page size or is it # of bytes or some other block size? that scares me :scared: :scared:
DO NOT try to write the OOB data. Just rewrite the block normally. The functions that write the block SHOULD calculate the data that needs to go into the OOB and write it for you!
From what I can see in the uboot help, the commands should be similar to the read command.
Have you tried the "nand bad" command to see if any bad blocks are known?
You could also try writing this to the NEXT block assuming it is completely blank already. If you noticed during bootup, it does try the next block all the way to the end of flash.
-
DO NOT try to write the OOB data. Just rewrite the block normally. The functions that write the block SHOULD calculate the data that needs to go into the OOB and write it for you!
yeah but still I am not quite sure how the nand write command behaves. Is it taking # of bytes for the size parameter or number of 2kB pages or some other block size
For example, in the uboot variables I see some commands like this:
nand erase 0x00620000 ${blocksize};nand write 0x4000000 0x00620000 ${blocksize}
but i cannot find where the blocksize was defined.
Help on nand commands in uboot gives me this:
p510> help nand
nand - NAND sub-system
Usage:
nand info - show available NAND devices
nand device [dev] - show or set current device
nand read - addr off|partition size
nand write - addr off|partition size
read/write 'size' bytes starting at offset 'off'
to/from memory address 'addr', skipping bad blocks.
nand erase [clean] [off size] - erase 'size' bytes from
offset 'off' (entire device if not specified)
nand bad - show bad blocks
nand dump[.oob] off - dump page
nand scrub - really clean NAND erasing bad blocks (UNSAFE)
nand markbad off [...] - mark bad block(s) at offset (UNSAFE)
nand biterr off - make a bit error at offset (UNSAFE)
which seems to suggest the third parameter is just # of bytes but those in the uboot variables confuse me
-
"nand bad" shows no bad blocks
-
From what I can see in the uboot help, the commands should be similar to the read command.
Have you tried the "nand bad" command to see if any bad blocks are known?
You could also try writing this to the NEXT block assuming it is completely blank already. If you noticed during bootup, it does try the next block all the way to the end of flash.
the errors in the log start from
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
and it keeps bumping by 0x40 sectors whatever that means until the last error which is
FMD_DirectRead: Invalid block at sector 0xff80 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xffc0 bumping by 0x40 sectors
how is sector related to page? how long is it?
"nand info" commands says "sector size 128 KiB" but seems way too large to me
-
From what I can see in the uboot help, the commands should be similar to the read command.
Have you tried the "nand bad" command to see if any bad blocks are known?
You could also try writing this to the NEXT block assuming it is completely blank already. If you noticed during bootup, it does try the next block all the way to the end of flash.
the errors in the log start from
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
and it keeps bumping by 0x40 sectors whatever that means until the last error which is
FMD_DirectRead: Invalid block at sector 0xff80 bumping by 0x40 sectors
FMD_DirectRead: Invalid block at sector 0xffc0 bumping by 0x40 sectors
how is sector related to page? how long is it?
"nand info" commands says "sector size 128 KiB" but seems way too large to me
They are using sector size = 2048 bytes, so the same thing as a page. Multiply that # by 2048 to get offset.
It is effectively starting from c0000 and going to the end of flash.
-
So I just tested this from uboot, which reads out the page, and places it in the next block (the next block was empty in mine).
It seems to work without any issue for me. But YMMV.
The MD was just to check that memory area was mostly empty.
md 0x800000 0x20000
nand read 0x800000 0xc0000 0x20000
nand write 0x800000 0xe0000 0x20000
-
They are using sector size = 2048 bytes, so the same thing as a page. Multiply that # by 2048 to get offset.
It is effectively starting from c0000 and going to the end of flash.
yes I just figured that out but it is strange because when the unit boots
I am 100% it reads a lot from the flash and never complains for example about cal data being corrupted etc...
cannot be bad all the way to 128MB
I was just looking at the dumps of some random pages after 0xC0800 and they are all 00 (with identical oob data which has 4 rows of data and 4 rows of FF alternating) until 0xC4000 when all data become FF including all the oob and that continues for very long length....
-
So I just tested this from uboot, which reads out the page, and places it in the next block (the next block was empty in mine).
It seems to work without any issue for me. But YMMV.
The MD was just to check that memory area was mostly empty.
md 0x800000 0x20000
nand read 0x800000 0xc0000 0x20000
nand write 0x800000 0xe0000 0x20000
Just to clarify what this is doing, it is reading that boot config BLOCK (all 128kb of it) into a memory area at 0x80000000 and then writing the contents of that same memory out to the NEXT block at 0xe0000.
I did this because that block is empty on my flash (though the block after that one has redundant copy of uboot in it).
I checked the nand after that and it wrote it to the correct place.
If your next block at e0000 is also empty, you could try this first, with a lower risk of issues.... Again, YMMV so beware.
-
yes it is empty at 0xe0000
for those pages that are fully 0000 what do you see for oob?
and also for those pages that are all FFFF what is the oob? mine is all FF
-
dont you need to erase nand before writing to it?
or since it is empty that's fine, right?
but eventually if I want to re-write into the non empty areas i have to do erase first, right?
-
ok I duplicated the commands that you posted and then dumped one page from 0xE0000
as you see here the result is exactly a copy of the page at 0xC0000 including the oob data
p510> nand dump 0xc0000
nand_dump len: 2048, ooblen 64, off 0xc0000
Page 000c0000 dump:
ef 1e 8b 0c 72 61 6d 62 6f 6f 74 3d 64 68 63 70
20 30 78 34 30 30 30 30 30 30 20 6e 6b 2e 62 69
6e 3b 72 75 6e 20 62 6f 6f 74 63 6d 64 00 62 61
75 64 72 61 74 65 3d 31 31 35 32 30 30 00 67 61
74 65 77 61 79 69 70 3d 31 39 32 2e 31 36 38 2e
31 2e 31 30 00 6e 65 74 6d 61 73 6b 3d 32 35 35
2e 32 35 35 2e 32 35 35 2e 30 00 63 68 69 70 76
65 72 73 69 6f 6e 3d 41 41 00 62 6f 61 72 64 76
65 72 73 69 6f 6e 3d 34 00 66 74 70 3d 64 68 63
70 00 62 6f 6f 74 64 65 6c 61 79 3d 30 00 65 63
63 3d 34 00 63 6e 66 67 5f 76 6d 63 5f 69 6e 70
75 74 5f 70 69 6e 3d 6d 77 20 30 78 62 33 30 30
30 30 32 38 20 30 78 30 30 30 34 30 33 30 30 20
31 3b 6d 77 20 30 78 62 33 30 30 30 30 34 38 20
30 78 66 66 66 62 66 66 66 66 20 31 00 63 6e 66
67 5f 6c 61 6e 5f 69 6e 70 75 74 5f 70 69 6e 3d
6d 77 20 30 78 62 33 30 30 30 30 33 30 20 30 78
30 30 30 30 30 30 30 38 20 31 3b 6d 77 20 30 78
62 33 30 30 30 30 35 30 20 30 78 46 46 46 46 46
46 46 46 20 31 3b 6d 77 20 30 78 62 33 30 30 30
30 31 38 20 30 78 30 30 30 30 30 31 30 31 00 70
72 65 62 6f 6f 74 3d 6d 77 2e 6c 20 30 78 62 33
30 30 30 30 30 63 20 30 78 66 66 66 66 61 63 66
34 3b 20 72 75 6e 20 63 6e 66 67 5f 6c 61 6e 5f
69 6e 70 75 74 5f 70 69 6e 3b 20 72 75 6e 20 63
6e 66 67 5f 76 6d 63 5f 69 6e 70 75 74 5f 70 69
6e 3b 20 73 70 6c 61 73 68 20 6c 6f 61 64 00 64
69 73 70 50 61 72 6d 31 3d 31 31 30 20 31 65 30
20 39 38 39 36 38 30 20 30 20 32 38 00 64 69 73
70 50 61 72 6d 32 3d 31 20 31 20 31 20 31 20 33
00 6e 75 6d 69 6e 73 74 69 6d 61 67 65 73 3d 31
00 70 62 6f 6f 74 64 65 6c 61 79 3d 30 00 66 69
6d 61 67 65 3d 31 00 6e 69 6d 61 67 65 73 3d 32
00 69 6d 61 67 65 31 3d 30 78 64 30 36 32 30 30
30 30 00 69 6d 61 67 65 32 3d 30 78 64 32 31 32
30 30 30 30 00 66 73 73 74 61 72 74 3d 30 78 33
30 32 30 30 30 30 00 6e 75 6d 66 69 6c 65 73 79
73 74 65 6d 73 3d 32 00 6c 65 6e 67 74 68 66 69
6c 65 73 79 73 74 65 6d 31 3d 30 78 34 45 45 30
30 30 30 00 6c 65 6e 67 74 68 66 69 6c 65 73 79
73 74 65 6d 32 3d 30 78 31 30 30 30 30 30 00 62
6f 6f 74 63 6d 64 3d 6e 61 6e 64 20 72 65 61 64
20 30 78 36 30 30 30 30 30 20 30 78 33 32 30 30
30 30 20 30 78 31 30 30 30 30 3b 62 6f 6f 74 6d
20 30 78 36 30 30 30 30 30 00 75 61 72 74 32 3d
31 00 72 74 63 3d 31 00 70 73 3d 30 00 73 70 6c
61 73 68 64 61 74 61 3d 30 78 64 30 31 38 30 30
30 30 00 65 72 61 73 65 5f 65 6e 76 3d 6e 61 6e
64 20 65 72 61 73 65 20 30 78 43 30 30 30 30 20
30 78 34 30 30 30 30 00 73 74 6f 72 65 5f 78 6c
6f 61 64 65 72 3d 78 6c 6f 61 64 20 30 78 38 30
30 30 30 30 00 67 65 74 5f 78 6c 6f 61 64 5f 65
74 68 3d 64 68 63 70 20 30 78 38 30 30 30 30 30
20 78 6c 6f 61 64 65 72 2d 70 35 31 30 2e 62 69
6e 3b 20 72 75 6e 20 73 74 6f 72 65 5f 78 6c 6f
61 64 65 72 00 73 74 6f 72 65 5f 75 62 6f 6f 74
3d 6e 61 6e 64 20 65 72 61 73 65 20 30 78 31 30
30 30 30 30 20 24 7b 62 6c 6f 63 6b 73 69 7a 65
7d 3b 20 6e 61 6e 64 20 77 72 69 74 65 20 30 78
38 30 30 30 30 30 20 30 78 31 30 30 30 30 30 20
24 7b 62 6c 6f 63 6b 73 69 7a 65 7d 00 67 65 74
5f 75 62 6f 6f 74 5f 65 74 68 3d 64 68 63 70 20
30 78 38 30 30 30 30 30 20 75 2d 62 6f 6f 74 2d
70 35 31 30 2e 62 69 6e 3b 72 75 6e 20 73 74 6f
72 65 5f 75 62 6f 6f 74 00 73 74 6f 72 65 5f 70
62 6f 6f 74 3d 6e 61 6e 64 20 65 72 61 73 65 20
30 78 33 32 30 30 30 30 20 24 7b 62 6c 6f 63 6b
73 69 7a 65 7d 3b 20 6e 61 6e 64 20 77 72 69 74
65 20 30 78 38 30 30 30 30 30 20 30 78 33 32 30
30 30 30 20 24 7b 62 6c 6f 63 6b 73 69 7a 65 7d
00 67 65 74 5f 70 62 6f 6f 74 5f 65 74 68 3d 64
68 63 70 20 30 78 38 30 30 30 30 30 20 70 62 6f
6f 74 2e 62 69 6e 3b 72 75 6e 20 73 74 6f 72 65
5f 70 62 6f 6f 74 00 66 6c 61 73 68 5f 6e 6b 62
69 6e 3d 64 68 63 70 20 30 78 34 30 30 30 30 30
30 20 6e 6b 2e 62 69 6e 3b 6e 61 6e 64 20 65 72
61 73 65 20 30 78 30 30 36 32 30 30 30 30 20 24
7b 62 6c 6f 63 6b 73 69 7a 65 7d 3b 6e 61 6e 64
20 77 72 69 74 65 20 30 78 34 30 30 30 30 30 30
20 30 78 30 30 36 32 30 30 30 30 20 24 7b 62 6c
6f 63 6b 73 69 7a 65 7d 00 75 73 62 74 74 79 3d
63 64 63 5f 61 63 6d 00 65 74 68 61 64 64 72 3d
38 30 3a 30 39 3a 30 32 3a 30 65 3a 37 61 3a 34
66 00 73 65 72 69 61 6c 6e 75 6d 3d 4d 59 39 39
39 39 39 39 39 39 00 76 65 72 69 66 79 3d 6e 00
73 74 64 69 6e 3d 73 65 72 69 61 6c 00 73 74 64
6f 75 74 3d 73 65 72 69 61 6c 00 73 74 64 65 72
72 3d 73 65 72 69 61 6c 00 69 70 61 64 64 72 3d
31 39 32 2e 31 36 38 2e 31 2e 31 37 39 00 67 75
69 64 3d 7b 36 31 33 34 31 65 39 65 2d 61 66 33
36 2d 62 33 34 37 2d 61 65 30 35 2d 33 61 34 30
34 63 32 63 64 39 63 30 7d 00 73 65 72 76 65 72
69 70 3d 30 30 30 2e 30 30 30 2e 30 30 30 2e 30
30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
OOB:
ff ff ff ff ff ff ff ff
c7 c0 61 e7 00 4e 80 95
ff ff ff ff ff ff ff ff
ac 3e 59 ad 00 97 90 a1
ff ff ff ff ff ff ff ff
fe 04 f8 c7 00 d4 30 11
ff ff ff ff ff ff ff ff
ef 5d 4b a1 00 d7 80 8b
-
dont you need to erase nand before writing to it?
or since it is empty that's fine, right?
but eventually if I want to re-write into the non empty areas i have to do erase first, right?
Correct. Erasing can sometimes fix issues that you could otherwise still run into. But I'd hold off on that.
My pages also have all 0xff spares for both all 0x00 and 0xFF pages.
-
ok I duplicated the commands that you posted and then dumped one page from 0xE0000
as you see here the result is exactly a copy of the page at 0xC0000 including the oob data
p510> nand dump 0xc0000
nand_dump len: 2048, ooblen 64, off 0xc0000
Page 000c0000 dump:
ef 1e 8b 0c 72 61 6d 62 6f 6f 74 3d 64 68 63 70
20 30 78 34 30 30 30 30 30 30 20 6e 6b 2e 62 69
6e 3b 72 75 6e 20 62 6f 6f 74 63 6d 64 00 62 61
75 64 72 61 74 65 3d 31 31 35 32 30 30 00 67 61
74 65 77 61 79 69 70 3d 31 39 32 2e 31 36 38 2e
31 2e 31 30 00 6e 65 74 6d 61 73 6b 3d 32 35 35
2e 32 35 35 2e 32 35 35 2e 30 00 63 68 69 70 76
65 72 73 69 6f 6e 3d 41 41 00 62 6f 61 72 64 76
65 72 73 69 6f 6e 3d 34 00 66 74 70 3d 64 68 63
70 00 62 6f 6f 74 64 65 6c 61 79 3d 30 00 65 63
63 3d 34 00 63 6e 66 67 5f 76 6d 63 5f 69 6e 70
75 74 5f 70 69 6e 3d 6d 77 20 30 78 62 33 30 30
30 30 32 38 20 30 78 30 30 30 34 30 33 30 30 20
31 3b 6d 77 20 30 78 62 33 30 30 30 30 34 38 20
30 78 66 66 66 62 66 66 66 66 20 31 00 63 6e 66
67 5f 6c 61 6e 5f 69 6e 70 75 74 5f 70 69 6e 3d
6d 77 20 30 78 62 33 30 30 30 30 33 30 20 30 78
30 30 30 30 30 30 30 38 20 31 3b 6d 77 20 30 78
62 33 30 30 30 30 35 30 20 30 78 46 46 46 46 46
46 46 46 20 31 3b 6d 77 20 30 78 62 33 30 30 30
30 31 38 20 30 78 30 30 30 30 30 31 30 31 00 70
72 65 62 6f 6f 74 3d 6d 77 2e 6c 20 30 78 62 33
30 30 30 30 30 63 20 30 78 66 66 66 66 61 63 66
34 3b 20 72 75 6e 20 63 6e 66 67 5f 6c 61 6e 5f
69 6e 70 75 74 5f 70 69 6e 3b 20 72 75 6e 20 63
6e 66 67 5f 76 6d 63 5f 69 6e 70 75 74 5f 70 69
6e 3b 20 73 70 6c 61 73 68 20 6c 6f 61 64 00 64
69 73 70 50 61 72 6d 31 3d 31 31 30 20 31 65 30
20 39 38 39 36 38 30 20 30 20 32 38 00 64 69 73
70 50 61 72 6d 32 3d 31 20 31 20 31 20 31 20 33
00 6e 75 6d 69 6e 73 74 69 6d 61 67 65 73 3d 31
00 70 62 6f 6f 74 64 65 6c 61 79 3d 30 00 66 69
6d 61 67 65 3d 31 00 6e 69 6d 61 67 65 73 3d 32
00 69 6d 61 67 65 31 3d 30 78 64 30 36 32 30 30
30 30 00 69 6d 61 67 65 32 3d 30 78 64 32 31 32
30 30 30 30 00 66 73 73 74 61 72 74 3d 30 78 33
30 32 30 30 30 30 00 6e 75 6d 66 69 6c 65 73 79
73 74 65 6d 73 3d 32 00 6c 65 6e 67 74 68 66 69
6c 65 73 79 73 74 65 6d 31 3d 30 78 34 45 45 30
30 30 30 00 6c 65 6e 67 74 68 66 69 6c 65 73 79
73 74 65 6d 32 3d 30 78 31 30 30 30 30 30 00 62
6f 6f 74 63 6d 64 3d 6e 61 6e 64 20 72 65 61 64
20 30 78 36 30 30 30 30 30 20 30 78 33 32 30 30
30 30 20 30 78 31 30 30 30 30 3b 62 6f 6f 74 6d
20 30 78 36 30 30 30 30 30 00 75 61 72 74 32 3d
31 00 72 74 63 3d 31 00 70 73 3d 30 00 73 70 6c
61 73 68 64 61 74 61 3d 30 78 64 30 31 38 30 30
30 30 00 65 72 61 73 65 5f 65 6e 76 3d 6e 61 6e
64 20 65 72 61 73 65 20 30 78 43 30 30 30 30 20
30 78 34 30 30 30 30 00 73 74 6f 72 65 5f 78 6c
6f 61 64 65 72 3d 78 6c 6f 61 64 20 30 78 38 30
30 30 30 30 00 67 65 74 5f 78 6c 6f 61 64 5f 65
74 68 3d 64 68 63 70 20 30 78 38 30 30 30 30 30
20 78 6c 6f 61 64 65 72 2d 70 35 31 30 2e 62 69
6e 3b 20 72 75 6e 20 73 74 6f 72 65 5f 78 6c 6f
61 64 65 72 00 73 74 6f 72 65 5f 75 62 6f 6f 74
3d 6e 61 6e 64 20 65 72 61 73 65 20 30 78 31 30
30 30 30 30 20 24 7b 62 6c 6f 63 6b 73 69 7a 65
7d 3b 20 6e 61 6e 64 20 77 72 69 74 65 20 30 78
38 30 30 30 30 30 20 30 78 31 30 30 30 30 30 20
24 7b 62 6c 6f 63 6b 73 69 7a 65 7d 00 67 65 74
5f 75 62 6f 6f 74 5f 65 74 68 3d 64 68 63 70 20
30 78 38 30 30 30 30 30 20 75 2d 62 6f 6f 74 2d
70 35 31 30 2e 62 69 6e 3b 72 75 6e 20 73 74 6f
72 65 5f 75 62 6f 6f 74 00 73 74 6f 72 65 5f 70
62 6f 6f 74 3d 6e 61 6e 64 20 65 72 61 73 65 20
30 78 33 32 30 30 30 30 20 24 7b 62 6c 6f 63 6b
73 69 7a 65 7d 3b 20 6e 61 6e 64 20 77 72 69 74
65 20 30 78 38 30 30 30 30 30 20 30 78 33 32 30
30 30 30 20 24 7b 62 6c 6f 63 6b 73 69 7a 65 7d
00 67 65 74 5f 70 62 6f 6f 74 5f 65 74 68 3d 64
68 63 70 20 30 78 38 30 30 30 30 30 20 70 62 6f
6f 74 2e 62 69 6e 3b 72 75 6e 20 73 74 6f 72 65
5f 70 62 6f 6f 74 00 66 6c 61 73 68 5f 6e 6b 62
69 6e 3d 64 68 63 70 20 30 78 34 30 30 30 30 30
30 20 6e 6b 2e 62 69 6e 3b 6e 61 6e 64 20 65 72
61 73 65 20 30 78 30 30 36 32 30 30 30 30 20 24
7b 62 6c 6f 63 6b 73 69 7a 65 7d 3b 6e 61 6e 64
20 77 72 69 74 65 20 30 78 34 30 30 30 30 30 30
20 30 78 30 30 36 32 30 30 30 30 20 24 7b 62 6c
6f 63 6b 73 69 7a 65 7d 00 75 73 62 74 74 79 3d
63 64 63 5f 61 63 6d 00 65 74 68 61 64 64 72 3d
38 30 3a 30 39 3a 30 32 3a 30 65 3a 37 61 3a 34
66 00 73 65 72 69 61 6c 6e 75 6d 3d 4d 59 39 39
39 39 39 39 39 39 00 76 65 72 69 66 79 3d 6e 00
73 74 64 69 6e 3d 73 65 72 69 61 6c 00 73 74 64
6f 75 74 3d 73 65 72 69 61 6c 00 73 74 64 65 72
72 3d 73 65 72 69 61 6c 00 69 70 61 64 64 72 3d
31 39 32 2e 31 36 38 2e 31 2e 31 37 39 00 67 75
69 64 3d 7b 36 31 33 34 31 65 39 65 2d 61 66 33
36 2d 62 33 34 37 2d 61 65 30 35 2d 33 61 34 30
34 63 32 63 64 39 63 30 7d 00 73 65 72 76 65 72
69 70 3d 30 30 30 2e 30 30 30 2e 30 30 30 2e 30
30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
OOB:
ff ff ff ff ff ff ff ff
c7 c0 61 e7 00 4e 80 95
ff ff ff ff ff ff ff ff
ac 3e 59 ad 00 97 90 a1
ff ff ff ff ff ff ff ff
fe 04 f8 c7 00 d4 30 11
ff ff ff ff ff ff ff ff
ef 5d 4b a1 00 d7 80 8b
Still same error during boot-up too?
Just FYI, the function that verifies the data in PBOOT appears to look at the spare areas on at least the first 8 pages before deciding the block is bad. So the issue is not necessarily the first page.
-
dont you need to erase nand before writing to it?
or since it is empty that's fine, right?
but eventually if I want to re-write into the non empty areas i have to do erase first, right?
Correct. Erasing can sometimes fix issues that you could otherwise still run into. But I'd hold off on that.
My pages also have all 0xff spares for both all 0x00 and 0xFF pages.
hmmmm....for all 000 pages I dont get all FF for OOB...there are numbers in it...but for all FF pages I get all FF oob
i just rebooted the unit and the sector at 0x1c0 (=0xE0000) still shows invalid
-
for instance this is the dump of a page which is all 0x00
all others 0x00 filled pages look identical
p510> nand dump 0xc0800
nand_dump len: 2048, ooblen 64, off 0xc0800
Page 000c0800 dump:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
OOB:
ff ff ff ff ff ff ff ff
ef 5d 4b a1 00 d7 80 8b
ff ff ff ff ff ff ff ff
ef 5d 4b a1 00 d7 80 8b
ff ff ff ff ff ff ff ff
ef 5d 4b a1 00 d7 80 8b
ff ff ff ff ff ff ff ff
ef 5d 4b a1 00 d7 80 8b
-
still I am pretty sure the whole 128MB of NAND is not bad and I am not even sure the 0xC0000 area is bad either.
perhaps there is still a problem with the pboot itself or it is reading its parameters from somewhere else , not from 0xc0000
-
these front panels (used is many Keysight instruments) are very well known to have bad CPU (SPear320)
I have personally replaced 4 of them in multimeters and 33600 function generators
so maybe mine has a slightly defective nand controller in it....but the meter was manufactured in Nov 2019 and its warranty ended in Dec 1. 2022 |O |O
it has been sitting off on the bench for 4-5 month and now suddenly this? :palm: :palm:
is there any service note or extended warranty for this nand corruption issue similar to what was available for 3000A scopes?
-
by the way the areas that I wrote in the NAND (starting from 0xE0000) look exactly identical to the areas I copied from
including the oob data
so I dont think writing back into the nand is gonna help, is it?
-
still I am pretty sure the whole 128MB of NAND is not bad and I am not even sure the 0xC0000 area is bad either.
perhaps there is still a problem with the pboot itself or it is reading its parameters from somewhere else , not from 0xc0000
I've considered a possible issue with PBOOT, but the problem is that it has a couple of different levels of checksums protecting it. There is a table inside it that it seems to use for the check. If that got corrupted, it could cause the appearance of a failure that is not there.
But that is extremely unlikely given that the checksum that UBOOT sees when you list images shows Ok, and the gzipped nb0 for PBOOT has its own CRC.
It is more likely something in the spare area isn't matching up. A hardware issue could cause a bit to appear stuck, for example.
The hope is that by rewriting you can force a re-write of the spare by the same mechanism that does the checking (FMD_Write). If that doesn't correct the issue, then it is looking more like a flash hardware problem.
-
by the way the areas that I wrote in the NAND (starting from 0xE0000) look exactly identical to the areas I copied from
including the oob data
so I dont think writing back into the nand is gonna help, is it?
Did you try rebooting since? You can test the theory, as it should check the block you wrote (it was checking it previously) when the first one fails.
If it still shows an error on that block (assuming you wrote the entire block) then it is not looking like an error that is correctable by re-writing it.
And erase cycle on that block might help, but now we're getting into more dangerous stuff.
-
by the way the areas that I wrote in the NAND (starting from 0xE0000) look exactly identical to the areas I copied from
including the oob data
so I dont think writing back into the nand is gonna help, is it?
Did you try rebooting since? You can test the theory, as it should check the block you wrote (it was checking it previously) when the first one fails.
If it still shows an error on that block (assuming you wrote the entire block) then it is not looking like an error that is correctable by re-writing it.
And erase cycle on that block might help, but now we're getting into more dangerous stuff.
yes I mentioned that I rebooted and I still get the same bad block error at sector 0x1c0 which is where I copied into. no change
also the oob data in those areas that I wrote into now are exact copy of the ones I copied from.
I just opened up my good 34461A and dumped the same area of the nand. The oob data looks exactly identical to what i see on my bad meter
so I am 100% sure it is not about those OOB data
-
by the way the areas that I wrote in the NAND (starting from 0xE0000) look exactly identical to the areas I copied from
including the oob data
so I dont think writing back into the nand is gonna help, is it?
Did you try rebooting since? You can test the theory, as it should check the block you wrote (it was checking it previously) when the first one fails.
If it still shows an error on that block (assuming you wrote the entire block) then it is not looking like an error that is correctable by re-writing it.
And erase cycle on that block might help, but now we're getting into more dangerous stuff.
yes I mentioned that I rebooted and I still get the same bad block error at sector 0x1c0 which is where I copied into. no change
also the oob data in those areas that I wrote into now are exact copy of the ones I copied from.
I just opened up my good 34461A and dumped the same area of the nand. The oob data looks exactly identical to what i see on my bad meter
so I am 100% sure it is not about those OOB data
I am still looking at the code to see exactly what it is verifying in the spare area. If I figure out what it is looking for, maybe we will have some idea of why it is rejecting it.
-
Having fun without me??
I'm almost sure I know how to calc that CRC/checksum.
-
Having fun without me??
I'm almost sure I know how to calc that CRC/checksum.
What I am looking at actually appears to be a bad-block check.
As an example:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
XX XX XX XX XX XX XX XX
87FFB708 = FF FF FF FF FF FF FF FF 95 A5 6A 69 59 FF FF FF
If any of the bytes marked with X's from the first 16 bytes of Spare are not FF, it bails with an error.
-
Having fun without me??
I'm almost sure I know how to calc that CRC/checksum.
so finally dragged you into this >:D >:D
-
Okay. So I just noticed something. This is likely why our spares are not matching up... It appears you have a different flash chip with internal ECC, while I do not.
Maybe a cost-cutting change Keysight made before I bought mine. Did you see what flash chip you have in there?
Mine:
CPU: SPEAr320
DRAM: 128 MiB
Unknown id: 0xffffff. Using ST_M23P40
Flash: 64 KiB
NAND: fsmc-ecc1 128 MiB
In: serial
Out: serial
Err: serial
SerNum:MY99999999
Chip: AA Board Rev: 4
init RTC: 2023-07-30 18:12:44.22
Net: No ethernet found.
splash RTC: 2023-07-30 18:12:45.25
Yours:
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
-
NAND chips on both of my meters are Micron MT29F1G08ABADAH4-ITX:D marked NQ432
both are identified in uboot as INTERNAL ECC 128 MiB
-
from the datasheet of the NAND flash chip:
Internal ECC and Spare Area Mapping for ECC
Internal ECC enables 5-bit detection and 4-bit error correction in 512 bytes (x8) or 256
words (x16) of the main area and 4 bytes (x8) or 2 words (x16) of metadata I in the spare
area. The metadata II area, which consists of two bytes (x8) and one word (x16), is not
ECC protected. During the busy time for PROGRAM operations, internal ECC generates
parity bits when error detection is complete.
During READ operations the device executes the internal ECC engine (5-bit detection
and 4-bit error correction). When the READ operaton is complete, read status bit 0 must
be checked to determine whether errors larger than four bits have occurred.
Following the READ STATUS command, the device must be returned to read mode by
issuing the 00h command.
Limitations of internal ECC include the spare area, defined in the figures below, and
ECC parity areas that cannot be written to. Each ECC user area (referred to as main and
spare) must be written within one partial-page program so that the NAND device can
calculate the proper ECC parity. The number of partial-page programs within a page
cannot exceed four
-
NAND chips on both of my meters are Micron MT29F1G08ABADAH4-ITX:D marked NQ432
both are identified in uboot as INTERNAL ECC 128 MiB
Okay, that is similar to what they put in their scopes. Mine is a WINBOND W29N01HV. It doesn't have internal ECC. So while I've figured out the code path and what causes that error on mine, it will likely be somewhat different for yours.
What I can see, however, is that this appears to be when it is checking the "BAD BLOCK" area that it is finding something it doesn't like.
Did you say that the OOB for page 0xc0000 was the same on both of your meters? Is there anything on one that is 0xFF that isn't on the broken one?
-
NAND chips on both of my meters are Micron MT29F1G08ABADAH4-ITX:D marked NQ432
both are identified in uboot as INTERNAL ECC 128 MiB
Okay, that is similar to what they put in their scopes. Mine is a WINBOND W29N01HV. It doesn't have internal ECC. So while I've figured out the code path and what causes that error on mine, it will likely be somewhat different for yours.
What I can see, however, is that this appears to be when it is checking the "BAD BLOCK" area that it is finding something it doesn't like.
Did you say that the OOB for page 0xc0000 was the same on both of your meters? Is there anything on one that is 0xFF that isn't on the broken one?
right at the first page at 0xc0000 although the actual numbers are different because I had changed the serverip on the bad meter and then changed it back and when you do make a change the whole set of env variables are re-written so the pattern becomes different and the OOB are not identical however the pattern of numbers is identical
but after that first page (on pages that are all 0x00) the OOB are exactly identical
-
I am pretty sure it is not the nand having a physical problem.
the pboot is doing a wrong calculation for some reason
maybe it is not identifying the correct chip ID
-
where do you think pboot is getting those "default" boot parameters from. Look at the error here:
ERROR : Bootloader setting load failed
[b][b]INFO : Loading default bootloader settings[/b][/b]
Press [ENTER] to launch image stored in flash or [SPACE] to cancel.
Initiating image launch in 4 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)
if we can somehow change those stupid default values to 0xD0620000 and 0xD2120000
then we should be good to go :-X :-X
-
there is variable in uboot
erase_env=nand erase 0xC0000 0x40000
i dont know where it is used but shows the env partition must be 256KiB
-
I am pretty sure it is not the nand having a physical problem.
the pboot is doing a wrong calculation for some reason
maybe it is not identifying the correct chip ID
That's a distinct possibility. I read through the datasheet, and it indicates that bad block information is stored on the first page OOB in bytes 0x800-0x801, 0x810-0x811, 0x820-0x821, and 0x830-0x831.
Those all appear to be good (they should be 0xFF).
Was the PBOOT reflashed at some point, possibly with the wrong one for your flash chip?
-
I am pretty sure it is not the nand having a physical problem.
the pboot is doing a wrong calculation for some reason
maybe it is not identifying the correct chip ID
That's a distinct possibility. I read through the datasheet, and it indicates that bad block information is stored on the first page OOB in bytes 0x800-0x801, 0x810-0x811, 0x820-0x821, and 0x830-0x831.
Those all appear to be good (they should be 0xFF).
Was the PBOOT reflashed at some point, possibly with the wrong one for your flash chip?
no this meter had not been opened until few days ago
also I dumped the pboot from nand and compared the bin file with my good meter and they are identical.
-
I am pretty sure it is not the nand having a physical problem.
the pboot is doing a wrong calculation for some reason
maybe it is not identifying the correct chip ID
That's a distinct possibility. I read through the datasheet, and it indicates that bad block information is stored on the first page OOB in bytes 0x800-0x801, 0x810-0x811, 0x820-0x821, and 0x830-0x831.
Those all appear to be good (they should be 0xFF).
Was the PBOOT reflashed at some point, possibly with the wrong one for your flash chip?
no this meter had not been opened until few days ago
also I dumped the pboot from nand and compared the bin file with my good meter and they are identical.
It is starting to get weird now. The flash pages in question look fine. The PBOOT image looks correct. It could be that the chip is not responding properly to parameters and giving the correct ID, but I would expect that to cause problems with UBOOT as well.
You could verify that via JTAG by querying the flash chip for parameters. A memory dump might help too.
It might still be worth doing an erase on that once-empty block at e0000 and reprogram it to see if anything changes. But other than that, I am out of ideas at the moment.
-
It is starting to get weird now. The flash pages in question look fine. The PBOOT image looks correct. It could be that the chip is not responding properly to parameters and giving the correct ID, but I would expect that to cause problems with UBOOT as well.
You could verify that via JTAG by querying the flash chip for parameters. A memory dump might help too.
It might still be worth doing an erase on that once-empty block at e0000 and reprogram it to see if anything changes. But other than that, I am out of ideas at the moment.
i dont know the JTAG pins on the board. Do you?
I will do the erase and re-write but I am pretty sure it will work. maybe the issue is not pboot but it is the uboot
I mean if I understand correctly, uboot reads pboot from 0x320000 into memory but it is a packed (gzipped) binary
so when the bootm command runs, I suppose it must unpack pboot in order for it to execute and maybe that's where the problem starts
-
It is starting to get weird now. The flash pages in question look fine. The PBOOT image looks correct. It could be that the chip is not responding properly to parameters and giving the correct ID, but I would expect that to cause problems with UBOOT as well.
You could verify that via JTAG by querying the flash chip for parameters. A memory dump might help too.
It might still be worth doing an erase on that once-empty block at e0000 and reprogram it to see if anything changes. But other than that, I am out of ideas at the moment.
i dont know the JTAG pins on the board. Do you?
I will do the erase and re-write but I am pretty sure it will work. maybe the issue is not pboot but it is the uboot
I mean if I understand correctly, uboot reads pboot from 0x320000 into memory but it is a packed (gzipped) binary
so when the bootm command runs, I suppose it must unpack pboot in order for it to execute and maybe that's where the problem starts
Here is the pinout on the connector labeled J102.
0 0 GND
3.3V 0 0 GND
TMS 0 0 GND
TCK 0 0 GND
TDO 0 0 3.3V
TDI 0 0 TRST
3.3V 0 0 GND
-
Here is the pinout on the connector labeled J102.
0 0 GND
3.3V 0 0 GND
TMS 0 0 GND
TCK 0 0 GND
TDO 0 0 3.3V
TDI 0 0 TRST
3.3V 0 0 GND
Great! Thanks. I only have a Segger J-Link. Not sure if it is compatible with Spear320. I doubt that but I will certainly check
How could a memory dump help?
-
Here is the pinout on the connector labeled J102.
0 0 GND
3.3V 0 0 GND
TMS 0 0 GND
TCK 0 0 GND
TDO 0 0 3.3V
TDI 0 0 TRST
3.3V 0 0 GND
Great! Thanks. I only have a Segger J-Link. Not sure if it is compatible with Spear320. I doubt that but I will certainly check
How could a memory dump help?
I've been using a J-LINK pro with J-Link commander for some things (debugging and breakpointing) and OpenOCD via the j-link on a Linux box for things like dumping full NAND images.
Really the memory dump around the time of failure may just reveal some things about what the software was "thinking" at the time. Parameters it has loaded for the flash device, etc. I could compare it to my memory state. It's a long shot without me being able to actually breakpoint it and follow it myself.
-
I need to read the entire thread in detail, but I'd certainly say it's JTAG time.
-
I need to read the entire thread in detail, but I'd certainly say it's JTAG time.
please do. your input is always highly appreciated.
-
I did the erase and re-write at the empty block at 0xe0000 as was suggested everything is exactly the same including the oob data
looks identical to what i have at 0xc0000 which is what i saw also on my good meter
i really dont think it's the NAND chip physical problem. it is still a software issue
can it have something to do with those "preboot" commands/variables in the uboot?
-
I also have a crazy idea which may not completely solve the problem but at least might let the meter boot on its own
what if I write the extracted nk.nb0 file in the nand (need to decide in what location) and then using those preboot commands
I load it into memory and change the bootcmd to just start the WInce and therefore bypass the damn pboot altogether
the same way that I boot it now using CEloader or YMODEM.
obviously FW update will not be possible but other than that it seems it should be a solution? no?
-
I also have a crazy idea which may not completely solve the problem but at least might let the meter boot on its own
what if I write the extracted nk.nb0 file in the nand (need to decide in what location) and then using those preboot commands
I load it into memory and change the bootcmd to just start the WInce and therefore bypass the damn pboot altogether
the same way that I boot it now using CEloader or YMODEM.
obviously FW update will not be possible but other than that it seems it should be a solution? no?
Could work in theory. Might also be worth a try to modify the default settings in that PBOOT to the correct ones, so it proceeds anyway.
You could write it to a different location in flash, and load it from there via uboot, so you don't have to overwrite the current one.
It is a lot smaller, and probably safer to try than decompressing the entire image.
-
I also have a crazy idea which may not completely solve the problem but at least might let the meter boot on its own
what if I write the extracted nk.nb0 file in the nand (need to decide in what location) and then using those preboot commands
I load it into memory and change the bootcmd to just start the WInce and therefore bypass the damn pboot altogether
the same way that I boot it now using CEloader or YMODEM.
obviously FW update will not be possible but other than that it seems it should be a solution? no?
Could work in theory. Might also be worth a try to modify the default settings in that PBOOT to the correct ones, so it proceeds anyway.
You could write it to a different location in flash, and load it from there via uboot, so you don't have to overwrite the current one.
It is a lot smaller, and probably safer to try than decompressing the entire image.
I thought about that first but the problem is I dont know where it gets those default values from to change them
and also the first option that it follows automatically if user does not interfere is loading from 0x84000000 which leads to boot fail.
I dont know where it gets that address from and what is supposed to be loaded in there (nk.bin??) and when was it supposed to be loaded there
that;s when I thought I can just write the uncompressed nk.bin in NAND and load it to memory before the pboot...
-
I also have a crazy idea which may not completely solve the problem but at least might let the meter boot on its own
what if I write the extracted nk.nb0 file in the nand (need to decide in what location) and then using those preboot commands
I load it into memory and change the bootcmd to just start the WInce and therefore bypass the damn pboot altogether
the same way that I boot it now using CEloader or YMODEM.
obviously FW update will not be possible but other than that it seems it should be a solution? no?
Could work in theory. Might also be worth a try to modify the default settings in that PBOOT to the correct ones, so it proceeds anyway.
You could write it to a different location in flash, and load it from there via uboot, so you don't have to overwrite the current one.
It is a lot smaller, and probably safer to try than decompressing the entire image.
I thought about that first but the problem is I dont know where it gets those default values from to change them
and also the first option that it follows automatically if user does not interfere is loading from 0x84000000 which leads to boot fail.
I dont know where it gets that address from and what is supposed to be loaded in there (nk.bin??) and when was it supposed to be loaded there
that;s when I thought I can just write the uncompressed nk.bin in NAND and load it to memory before the pboot...
It gets the 0xd0400000 and 0xd1700000 and 0x84000000 addresses from defaults it loads in the binary.
I PMed you a copy of the xloader you can try, where I changed the defaults to the correct ones.
This is normally in flash @0x320000 but I would recommend writing it somewhere empty and then:
nand read 0x600000 <New Address> 0x10000;bootm 0x600000
to boot and test it.
-
It gets the 0xd0400000 and 0xd1700000 and 0x84000000 addresses from defaults it loads in the binary.
I PMed you a copy of the xloader you can try, where I changed the defaults to the correct ones.
This is normally in flash @0x320000 but I would recommend writing it somewhere empty and then:
nand read 0x600000 <New Address> 0x10000;bootm 0x600000
to boot and test it.
Thanks :-+
looks very promising. I'll try that. I will write it somewhere maybe after the current one in the nand
or I can write it at that 0xe0000 no? it's empty
-
It gets the 0xd0400000 and 0xd1700000 and 0x84000000 addresses from defaults it loads in the binary.
I PMed you a copy of the xloader you can try, where I changed the defaults to the correct ones.
This is normally in flash @0x320000 but I would recommend writing it somewhere empty and then:
nand read 0x600000 <New Address> 0x10000;bootm 0x600000
to boot and test it.
Thanks :-+
looks very promising. I'll try that. I will write it somewhere maybe after the current one in the nand
or I can write it at that 0xe0000 no? it's empty
Yes, that should work.
-
I uploaded the modified pboot into NAND at 0xe0000 (after erasing and made sure it is all 0xFF before writing)
and then loaded from there into memory at 0x600000 and issued bootm 0x600000
pboot ran exactly the same way it used to and stopped after all those error messages
when I press space bar to enter the bootloader menu, Now I get the correct addresses 0xd0620000 and 0xd2120000
for image locations however when I choose any of them, the unit simply says "loading image 1 from memory at 0xd0620000" and stops there and hangs
I know there is a Nk.bin (compressed exactly as it is in the firmware package) at d0620000 and d2120000
and it is the same on my good meter.
it seems pboot cannot read the nand or it cannot decompress the XPRS Nk.bin so it hangs in there
-
it seems the only way is to bypass the pboot by writing the extracted nk.nb0 directly and using the "go" command
but I will give that JTAG a try and see if you guys can decipher anything from memory content
-
I uploaded the modified pboot into NAND at 0xe0000 (after erasing and made sure it is all 0xFF before writing)
and then loaded from there into memory at 0x600000 and issued bootm 0x600000
pboot ran exactly the same way it used to and stopped after all those error messages
when I press space bar to enter the bootloader menu, Now I get the correct addresses 0xd0620000 and 0xd2120000
for image locations however when I choose any of them, the unit simply says "loading image 1 from memory at 0xd0620000" and stops there and hangs
I know there is a Nk.bin (compressed exactly as it is in the firmware package) at d0620000 and d2120000
and it is the same on my good meter.
So, this uses the same exact function to verify block status when loading the nkbin as it uses when trying to read the uboot configuration.
It may be failing that part too. It is also possible I missed something.
Either way, we can rule out a bad copy of the xloader as the cause, if you are still seeing the same block defects showing up. Theoretically I could nix the part of that binary that does the bad block check, but that's not a good idea long-term.
If you manage to get connected via JTAG, we can query the flash chip to make sure it is outputting the correct parameters. The flash chips in these devices are not natively supported by the PBOOT, they are supported by OFNI-standard parameters read from the chip. If something is bad there, it could cause what we're seeing.
-
If you get JTAG going, here is what you'll need uisng JTAG Commander (the segger tools, if using openocd, replace w1 with mwb and replace mem with mdb in the commands).
First "halt" the CPU while in the uboot prompt.
The first command should output 5 bytes identifying the chip manufacturer and a few parameters (the PBOOT checks this to see if it is natively supported).
Read ID:
w1 0xBAB10000 0x90
w1 0xBAB20000 0x0
mem 0xBAB00000 5
Next, PBOOT checks for the ONFI "magic" like this:
Read ONFI:
w1 0xBAB10000 0x90
w1 0xBAB20000 0x20
mem 0xBAB00000 4
This should return the letters "ONFI"
Finally, this next is the most likely place there could be an issue. It is the page PBOOT uses to configure itself. It tells it what kind of ECC is in use, as well as lots of other things that could break the boot process if it is wrong. For this reason, the manufacturer includes a checksum in this info, AND alternate copies of parameters later. PBOOT appears to ignore these things.
Read Parameter Page:
w1 0xBAB10000 0xEC
w1 0xBAB20000 0x0
mem 0xBAB00000 512
This will grab the complete parameters, with CRC and at least 1 redundant copy.
Make sure you don't resume the CPU after this. Just power cycle it, as you are putting the NAND into a mode UBOOT won't be aware of...
-
I connected the JTag and tried those commands but the "mem" command always says "Could not read memory." :-// :-// :scared:
-
if I use mem8 instead of mem, it takes the command with no error but then it does not show anything.
-
if I use mem8 instead of mem, it takes the command with no error but then it does not show anything.
What was the memory error? Can you try this while in the PBOOT loader? That memory range is sometimes not available in earlier and later boot stages. Just drop into that menu and halt it there to try.
Even with the patched loader booting okay, it would be interesting to see what's wrong with your flash parameters page exactly.
-
if I use mem8 instead of mem, it takes the command with no error but then it does not show anything.
What was the memory error? Can you try this while in the PBOOT loader? That memory range is sometimes not available in earlier and later boot stages. Just drop into that menu and halt it there to try.
Even with the patched loader booting okay, it would be interesting to see what's wrong with your flash parameters page exactly.
just says "Could not read memory." that's it
i'll try it in pboot
-
well I halted in pboot prompt and now the jtag commands work and I think this probably shows where the problem is :-// :-//
J-Link>w1 0xbab10000 0x90
Writing 90 -> BAB10000
J-Link>w1 0xbab20000 0x00
Writing 00 -> BAB20000
J-Link>mem 0xbab00000 5
BAB00000 = 2C F1 80 95 82 ,....
--------------------------------------------------------------------------
J-Link>w1 0xbab10000 0x90
Writing 90 -> BAB10000
J-Link>w1 0xbab20000 0x20
Writing 20 -> BAB20000
J-Link>mem 0xbab00000 4
BAB00000 = 4F 4E 46 49 ONFI
---------------------------------------------------------------------------
J-Link>w1 0xbab10000 0xec
Writing EC -> BAB10000
J-Link>w1 0xbab20000 0x00
Writing 00 -> BAB20000
J-Link>mem 0xbab00000 512
****** Error: Read memory error @ address 0xBAB00000, word access: Memory access timeout.
Could not read memory.
-
still i think the reason it gives that error is something else I am doing wrong, still I cannot tell it is because the nand has an error
i tried again but same error
I thought it should at least read something
-
still i think the reason it gives that error is something else I am doing wrong, still I cannot tell it is because the nand has an error
i tried again but same error
Maybe. I started having problems reading my parameters page with the jlink tool, and switched to OpenOCD instead of troubleshooting it. I figured that was a problem specific to my setup.
If you want to try in openOCD I can give you a config that works.
-
still i think the reason it gives that error is something else I am doing wrong, still I cannot tell it is because the nand has an error
i tried again but same error
Maybe. I started having problems reading my parameters page with the jlink tool, and switched to OpenOCD instead of troubleshooting it. I figured that was a problem specific to my setup.
If you want to try in openOCD I can give you a config that works.
i dont have openocd right now and with your unbelievable expertise the meter is fixed and working now as normal :-+ :-+ ;D ;D ;D
I wrote the patched pboot binary provided by @ElectronMan at 0x340000 in the NAND and changed my bootcmd variable to
read pboot from the new address (instead of the original one still at 0x320000) and boot from there
The unit now boots normally and works flawlessly.
Thank you so much @ElectronMan. It was a lot of fun working with you :-DMM :-DMM
-
still i think the reason it gives that error is something else I am doing wrong, still I cannot tell it is because the nand has an error
i tried again but same error
Maybe. I started having problems reading my parameters page with the jlink tool, and switched to OpenOCD instead of troubleshooting it. I figured that was a problem specific to my setup.
If you want to try in openOCD I can give you a config that works.
i dont have openocd right now and with your unbelievable expertise the meter is fixed and working now as normal :-+ :-+ ;D ;D ;D
I wrote the patched pboot binary provided by @ElectronMan at 0x340000 in the NAND and changed my bootcmd variable to
read pboot from the new address (instead of the original one still at 0x320000) and boot from there
The unit now boots normally and works flawlessly.
Thank you so much @ElectronMan. It was a lot of fun working with you :-DMM :-DMM
No problem, I am glad that worked! :clap: It was out of other ideas. Keysight really should update that pboot to handle that situation properly.
-
Well done guys!
So what is the overall summary of the failure itself - a bad block where the original pboot sits?
-
Well done guys!
So what is the overall summary of the failure itself - a bad block where the original pboot sits?
The flash chip's parameter page was apparently corrupted.
UBOOT doesn't use it. It just applies defaults based on whether the flash is Micron or not Micron, so it was unaffected.
But PBOOT just grabs the first parameter page and configures itself to talk to the flash.
I patched PBOOT to jump +256 bytes forward during the parameter load to grab the first redundant copy of the parameters page instead, and apparently that copy is good.
Really, PBOOT should be checking the checksum on the page, and automatically checking the 3 or so other copies instead of just trusting that the first copy is good.
-
Hi!Today my device did not work. When you turn it on, there is such a picture on the screen, it does not respond to the buttons. I am attaching the download log. I ask for help in repairing, maybe someone has had such an error. Thank you.
-
Sorry there was the wrong log file
U-Boot 2010.03 (Oct 09 2012 - 12:48:30)Agilent P510
CPU: SPEAr320
DRAM: 128 MiB
Unknown id: 0xffffff. Using ST_M23P40
Flash: 64 KiB
NAND: INTERNAL ECC 128 MiB
failed: 5 0
nand_bbt: Can't scan flash and build the RAM-based BBT
In: serial
Out: serial
Err: serial
SerNum:MY99999999
Chip: AA Board Rev: 4
init RTC: 2001-02-15 15:44:10.15
Net: No ethernet found.
splash RTC: 2001-02-15 15:44:11.18
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
System ready!
Preparing for download...
No RTC on 320
Loading image 1 from memory at 0xD0620000
O
BL_IMAGE_TYPE_BIN
X
XXXXOOOOXOXOOOOOOOXXOXXOOOOOOOXOOXOOXOOOXXXOOOOOOOOOXOOOOXOXXOXXXOXOOOXOXXXXOOXXOOOOOOXOOOOXXOOXXOOXXOXOOXOOOXOOXXOOOXOOOOXOXOOOOXOOOXOOOXXOXOXOXOXXXOXXXXOOOXOOOXOXOOOOXOOOOXOXOXOOOOOOXOOOXOOXOOOOXOXOOOOOXOXOOOOOOOOOOOXOXOOOOOOOXXOOOOOOOOXOOOOX
OXOOOXOXXOXXOOXOOXXXOXXXXOXOOXOOXOOXOOXOOXOXXOXOOXOXOOOOOOXXXXXOXOOOXOXOOOOXOOOOXOOOXOOXOOXOOOXOXXXXXXXXXXXXXXXXXXXXXXXXXrom_offset=0x0.
XXImageStart = 0x80361000, ImageLength = 0x169BC08, LaunchAddr = 0x80362000
Completed file(s):
-------------------------------------------------------------------------------
[0]: Address=0x80361000 Length=0x169BC08 Name="" Target=RAM
Loading image 1 succeeded.
ROMHDR at Address 80361044h
Preparing launch...
No RTC on 320
Launching windows CE image by jumping at address 0x 362000
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 Mar 18 2016)
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
ERROR: C:\WINCE600\PLATFORM\COMMON\SRC\SOC\STM\SPEARHEAD600\DRIVERS\NandFlash\.\sh600_NandFlash.c line 57: ConfigTimming - Unable to open device registry entry
ERROR: C:\WINCE600\PLATFORM\COMMON\SRC\SOC\STM\COMMON\DRIVERS\NandFlash\.\stm_NandFlash.c line 1043: LLD_GetInfo - Unable to open device registry entry
++SER_Init: context Drivers\Active\10
SER_Init, dwIndex:2
GPIO_Select0 Register 0xB300_0024: 0x80000000
Control Register 0xB300_0010 : 0x00000040
RAS Select Register 0xB300_000C: 0xffffacf4
CORE_CLK_CFG 0xB300_0024: 0x80000000
SER2 got sysintr:0x00000013
SER2 Serial Port, new baud rate:0x1c200 (UARTCLK:83250000 IBRD:0x2d FBRD:0xa)
++SER_Init: context Drivers\Active\11
SER_Init, dwIndex:3
GPIO_Select0 Register 0xB300_0024: 0x80000000
Control Register 0xB300_0010 : 0x00000040
RAS Select Register 0xB300_000C: 0xffffacf4
CORE_CLK_CFG 0xB300_0024: 0x80000000
+OALIntrRequestSysIntr IRQ (1) already used by SYSINTR (19)
SER3 got sysintr:0x00000014
SER3 Serial Port, new baud rate:0x1c200 (UARTCLK:83250000 IBRD:0x2d FBRD:0xa)
Incorrect Data, interal ECC failed at 0x62db
Incorrect Data, interal ECC failed at 0x62db
OHCI\system.c, GCFG_USBH1_SW_RST
OHCI\system.c, GCFG_USBH2_SW_RST
-EDeviceLoadEeprom 80:09:02:05:E6:FA
Phy found addr 7 (ticks=3917)
WaitForLink Start (ticks=3919)
No Link (ticks=4921)
<--EDeviceInitialize
GMAC DMA status register = 0x0
FAILED to obtain valid Flash Handle in PlatformInitializeResetting the USB-device silicon
sh600_pdd, IOCTL_BUS_POSTINIT
ERROR: C:\WINCE600\3RDPARTY\Agilent\HPP\Common\Drivers\stm320_UsbFnBusDriver\.\ufnbus.cpp line 1137: failed opening \Agilent Flash\SPD\usbOverride
stm320_UsbFnBusDriver, set IST priority 96
#################### dllEntry ###########################
Exception 'Raised Exception' (-1): Thread-Id=04a90002(pth=831ff000), Proc-Id=04a80002(pprc=8327bc3c) 'Torreys.exe', VM-active=04a80002(pprc=8327bc3c) 'Torreys.exe'
PC=400256e8(coredll.dll+0x000156e8) RA=803782c8(kernel.dll+0x000062c8) SP=0002f274, BVA=ffffffff
Exception 'Raised Exception' (-1): Thread-Id=04a90002(pth=831ff000), Proc-Id=04a80002(pprc=8327bc3c) 'Torreys.exe', VM-active=04a80002(pprc=8327bc3c) 'Torreys.exe'
PC=400256e8(coredll.dll+0x000156e8) RA=803782c8(kernel.dll+0x000062c8) SP=0002efe4, BVA=ffffffff
Exception 'Raised Exception' (-1): Thread-Id=04a90002(pth=831ff000), Proc-Id=04a80002(pprc=8327bc3c) 'Torreys.exe', VM-active=04a80002(pprc=8327bc3c) 'Torreys.exe'
PC=400256e8(coredll.dll+0x000156e8) RA=803782c8(kernel.dll+0x000062c8) SP=0002efdc, BVA=ffffffff
FAILED to obtain valid Flash Handle in PlatformInitialize
SSInitialize: Error 3
FAILED to obtain valid Flash Handle in PlatformInitialize
SSInitialize: Error 3
FAILED to obtain valid Flash Handle in PlatformInitialize
SSInitialize: Error 3
-
There is an error in my LOG, "Incorrect Data, interal ECC failed at 0x62db" what could it be?
-
Sorry for being stupid, but how to get uncompressed nk.bin file ?
-
I have a keysight 34461A that also has I believe corrupted flash. The spear CPU is not overheating and all supply voltages in the meter are spot on. The meter does not boot up and only displays a white screen, none of the button's work, and neither does the USB connection to the meter. I haven't gone much farther then measuring supply voltages. I have purchased a used supposely working front panel for a 34460a with the front circuit board but didn't receive it yet. I know keysight says do not swap out front panels from other units but I figured I would try when I receive it. Obviously, it probably won't work due to mismatch in model/serial numbers. I didn't pay much for it. Anyways, from reading these posts it seems this problem can somewhat remedied by reflashing the NAND. Does anyone have the actual process in steps to perform this fix, including firmware images to use? Thanks, any help is appreciated. I am pretty familar with firmware programming as I do this as part of my job at work.
-
I have a keysight 34461A that also has I believe corrupted flash. The spear CPU is not overheating and all supply voltages in the meter are spot on. The meter does not boot up and only displays a white screen, none of the button's work, and neither does the USB connection to the meter. I haven't gone much farther then measuring supply voltages. I have purchased a used supposely working front panel for a 34460a with the front circuit board but didn't receive it yet. I know keysight says do not swap out front panels from other units but I figured I would try when I receive it. Obviously, it probably won't work due to mismatch in model/serial numbers. I didn't pay much for it. Anyways, from reading these posts it seems this problem can somewhat remedied by reflashing the NAND. Does anyone have the actual process in steps to perform this fix, including firmware images to use? Thanks, any help is appreciated. I am pretty familar with firmware programming as I do this as part of my job at work.
i dont think anybody "reflashed" the NAND here. Certainly I didnt.
the first thing to do was to hook up the UART debug port on the front panel and see if there are any messages.
still the CPU could be dead even if it's not getting hot
-
Haven't gotten around to hooking up serial just yet, but that is next. I'll report back on my findings when I do. I hate to toss this meter it was barely used by my company but is out of warranty and they were going to trash it. It was given to me to take home. Yes, the CPU could be bad as the one test point on the front panel was supposed to have a 24 khz signal on it but didn't have anything except 3.3 volts on it I think. Other voltages on the front pcb were good.
-
is there antyhing in that upd file to help recover ??
https://www.keysight.com/us/en/lib/software-detail/instrument-firmware-software/34460a34461a34465a34470a-firmware-2367633.html (https://www.keysight.com/us/en/lib/software-detail/instrument-firmware-software/34460a34461a34465a34470a-firmware-2367633.html)