| Electronics > Repair |
| Agilent 34461A corrupted flash |
| << < (18/41) > >> |
| ElectronMan:
--- Quote from: analogRF on July 30, 2023, 08:35:27 pm ---here it is --- End quote --- 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... |
| analogRF:
--- Quote from: ElectronMan on July 30, 2023, 08:46:17 pm --- --- Quote from: analogRF on July 30, 2023, 08:35:27 pm ---here it is --- End quote --- 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... --- End quote --- 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 |
| analogRF:
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 |
| ElectronMan:
--- Quote from: analogRF on July 30, 2023, 08:49:25 pm --- --- Quote from: ElectronMan on July 30, 2023, 08:46:17 pm --- --- Quote from: analogRF on July 30, 2023, 08:35:27 pm ---here it is --- End quote --- 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... --- End quote --- 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 --- End quote --- 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. |
| analogRF:
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: |
| Navigation |
| Message Index |
| Next page |
| Previous page |