| Products > Test Equipment |
| Possible GW Instek GDS-1000B hack |
| << < (42/52) > >> |
| nctnico:
--- Quote from: Fungus on January 12, 2021, 09:13:10 am --- --- Quote from: danymogh on January 12, 2021, 06:37:56 am ---based on the boot.bin file from the upgrade files and a dump from another scope I'd say the bootloader used raw Nand flash. --- End quote --- You don't really need wear-levelling for firmware and it's a whole layer of extra complexity for a low-level bootloader. --- End quote --- You do because nand flash is that bad. Wear levelling is also about checking the contents and in case a sector is very bad it needs to be mapped out. See the problems Keysight has with their oscilloscopes. And nowadays bootloaders are very advanced pieces of software. Not just a few lines of code but close to being an OS in themselves. |
| tv84:
You said you had a NAND dump? If so, share it with us to have a look. |
| danymogh:
--- Quote from: tv84 on January 12, 2021, 09:54:11 am ---You said you had a NAND dump? If so, share it with us to have a look. --- End quote --- Yes, I have a full dump including the OOB data but after the firmware is corrupted. so the bootloader section OOB is useless. Also, the other dumps I got from the other working scope don't include OOB data and unfortunately, I bricked that scope as well |O because I had no Idea the "nandtest" command messes up the block content. here is the full dump including OOB after bootloader being messed up https://mega.nz/file/EwhBHK5Z#iWaQYef7AYeb_-1wFezzOjsCgKbDqYcK72qOQfp7sz4 as you can see on page 65472 and 65408 there is the BBT according to Zynq documents (in the last 4 blocks) also, I have a boot log that points to them as well --- Code: ---Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 --- End code --- according to Micron ECC the OOB area is 64 bytes and the table explains each part. however, that table (should?) be valid only when the internal ECC is used. It seems the Zynq uses address 0x804 - 0x807 to store the BBT signature (spare 0) and address 0x808 - 0x80F are the calculated ECC parity bits based on the content of main0 and spare 0 the subsequent addresses are similar. to sum it up, the last 8 bytes in each row are the parity bits, the first 8 bytes of each row are the Bad block information (2 bytes) + 6 byte user data (from that 6 bytes 2 bytes are not ECC protected (User metadata II) and 4 bytes are ECC protected (user metadata I)) |
| nctnico:
Perhaps a better way is to let the bootloader boot a Linux image (from Xilinx) over the network and use that to create the MTD partitions which are missing and then populate them with data from an extracted firmware image. |
| danymogh:
--- Quote from: nctnico on January 12, 2021, 12:56:15 pm ---Perhaps a better way is to let the bootloader boot a Linux image (from Xilinx) over the network and use that to create the MTD partitions which are missing and then populate them with data from an extracted firmware image. --- End quote --- unfortunately, that's not possible since it is the bootloader that loads the device tree which has the definition of all connected peripherals. if only one of the people who has the GDS-1054b could provide a dump from their bootloader using the command I specified, that's a great help to me. |
| Navigation |
| Message Index |
| Next page |
| Previous page |