[HN Gopher] Using JTAG to dump parallel NOR flash
___________________________________________________________________
Using JTAG to dump parallel NOR flash
Author : GrokNet
Score : 51 points
Date : 2024-03-23 15:15 UTC (2 days ago)
(HTM) web link (zetier.com)
(TXT) w3m dump (zetier.com)
| catkitcourt wrote:
| Seems requiring IO of debugged device is directly connected to
| scan registers, like a FPGA.
| nneonneo wrote:
| Figure 33's hexdump and Figure 35's binwalk output look
| suspicious to me. The hexdump is too sparse - lots of zero bits
| but no long runs of 0x00, consistent 0x00, 0x01 or 0x10 in odd-
| numbered positions, etc. It might be valid, or it might point to
| some kind of clocking or pinout issue. The binwalk output is even
| more suspicious - the signatures are likely all spurious. One
| does not expect a Flash ROM to consist solely of MySQL databases,
| particularly not random versions; this is likely the result of
| random bytes happening to match the file signature. As such,
| there don't seem to be _any_ recoverable files in the dump per
| binwalk.
| chc4 wrote:
| Yeah, I'd suspect that binwalk output to be junk from the flash
| tripping heuristics: "MySQL database" is one of those
| heuristics that a lot of random binary files trip spuriously
| for who knows what reason.
|
| Practically every other read word is `10 00 10 00` which is
| definitely strange, but also it's hard to judge if that's wrong
| without looking at the dump more IMO.
| monocasa wrote:
| Yeah, there's no way it's running MySQl. I'd expect to see a
| CPIO archive, a UBoot copyright string, or something in that
| wheelhouse at the top of binwalk given that it's the NOR
| flash to a mediatek soc.
| Boardbricker34 wrote:
| The binwalk is more than likely not aligned for the endianess
| that is used. This dump was made to just be an example that
| magic existed and there was data that came from the flash chip
| using this method. Not necessarily the binary enumeration of
| the dump. The magic binwalk found is more than likely junk. If
| one was looking to flip endianess on a dump, use the -swap and
| it will flip around strings.
| dmitrygr wrote:
| This is a rather convoluted way to do this. Once you have the
| socket, just connect with wires to a pi pico and dump it over
| serial.
| monocasa wrote:
| Yeah, about the only way this would make sense is if they used
| the boundary scan of the original board's SoC so they didn't
| have to desolder anything.
| Boardbricker34 wrote:
| This also does work. Some devices do not have the ability to
| connect to a part though (no bsdl, no jtag header)
| monocasa wrote:
| Given that the top bit of every 16bit word looks to be set,
| I'm not sure that it does work.
| Boardbricker34 wrote:
| This would work. And I have done this. You need a jtag
| port and the flash needs to be directly connected to the
| SOC/MCU/FPGA. This is similar to how EJTAG works but
| without ejtag, you need to specify the pins themselves.
| As long as all 16 data and addr pins are connected, this
| is possible.
| monocasa wrote:
| I know it can be done. NOR boot flashes like this were
| typically written and verified via boundary scan at
| manufacturing time. That's probably how this flash was
| initially written.
|
| I question whether you successfully performed that
| operation.
| Boardbricker34 wrote:
| Oh yes it is convoluted. This is for parallel nor flash though,
| not serial. I suppose a pi could work I am just confused how
| you would dump it over serial. You need to connect:
|
| D0-D15
|
| A0-A15
|
| CE (STATIC)
|
| OE (STATIC)
|
| WE (STATIC)
|
| WP (STATIC)
|
| RST (STATIC)
|
| GND (STATIC)
|
| 3.3 (STATIC)
|
| The pi would have to request an address over the address bus to
| the flash chip using A0-A15 and then the data would come over
| on D0-D15 and you would have to collect it. A pi would work if
| external static pins were held or tied to their respective
| state in order to read. TSOP56/48/40 would not work for this as
| a pico only has 26 GPIO pins available.
|
| Here are images of the busses for both serial and parallel nor
| flashes. The bus sizes are different. Serial:
| https://www.embedded.com/wp-content/uploads/contenteetimes-i...
|
| Parallel: https://www.embedded.com/wp-
| content/uploads/contenteetimes-i...
| dmitrygr wrote:
| connect parallel pins to gpios, data out over usb-serial.
| i've done this a few times using the very same socket
| depicted in TFA
| Boardbricker34 wrote:
| Updated. Curious about how you wound up tying all 30+ pins
| on the pico (26 gpio)
| monocasa wrote:
| You can put that nor flash into byte mode, saving you 8
| data lines in exchange for an extra address line.
|
| You can also throw a shift register in to increase the
| number of GPIOs.
| Boardbricker34 wrote:
| Yes, I suppose this would be a functional way to do this.
| It would take much longer (double or quadruple depending
| on data bus size). But none the less, it could work.
| monocasa wrote:
| I think you'll find that even that is much quicker than
| twiddling lines via boundary scan. At best, JTAG boundary
| scan is basically one giant shift register generally
| hundreds to thousands of bits long. Every cycle you'd
| need to shift out the whole thing even if you change the
| state of one signal.
| RetroTechie wrote:
| Or hook up a counter (reset + clock signal, that's 2
| gpio's), and feed counter output to address lines.
|
| If you're really short on gpio's, you could do the same
| with the data outputs (use some parallel in, serial out
| shift register, or a multiplexer that selects which data
| bit(s) to read).
___________________________________________________________________
(page generated 2024-03-25 23:00 UTC)