Author Topic: Making your own BSDL  (Read 1895 times)

0 Members and 1 Guest are viewing this topic.

Offline oh2ftuTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: fi
Making your own BSDL
« on: April 19, 2020, 08:47:45 am »
So,
I've been trying to dump a M36L0T8060B3 flash lately with varying success.
I desoldered it, and slapped it onto a proto advantage breakout-board. Then connected to an Arduino Due.
Dumping it at 57600kbps takes a while, and I must take 2-3 passes to make sure I've got at least to identical.
This is very inconvenient. I would like to dump it in-place, without the need to solder/desolder after small changes to it. Also, I cannot write anything to it.

The CPU is AD6528DABCZ. The only thing I've found related to AD6528, are a one-sheet datasheet with no actual info, a pinout from a Sharp GX15 service manual and.. that's about it.
The datasheet is nowhere to be found (I would like to have a memory map and gpio registers, please), or even a BSDL.
With a BSDL, I could use JTAG to access the flash.

Now then, as the flash is removed, could I create my own bsdl?
I do know where it's connected, I've traced the board.

But JTAG is completely new to me, I don't have a programmer even yet! (I'm getting a segger Jlink).

Is it even possible to blindly set registers on the CPU and measure the BGA-pads? and thus creating a BSDL containing the bare minimum definitions for accessing a flash?
« Last Edit: April 19, 2020, 09:22:48 am by oh2ftu »
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 825
  • Country: es
Re: Making your own BSDL
« Reply #1 on: May 01, 2020, 01:02:00 am »
You don’t need BSDL and direct pin manipulations to access memory on this CPU. Use CPU debug features instead (halt the core and read memory via CPU bus). A more common chip from this family was AD6522 - should be more info available (although it was more than 15 years ago). These chips also had a service mode in BootROM allowing memory reading/programming. You send some "magic" bytes to AD652x UART at power on and ROM enters service loader instead of normal start.
Edit: one of the most popular devices based on AD6522 was Panasonic GD55. Search for "panasonic gd55 flasher" still finds some tool archives, i.e. this: https://service-gsm.net/Panasonic/GD55
« Last Edit: May 01, 2020, 01:16:57 am by abyrvalg »
 

Offline oh2ftuTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: fi
Re: Making your own BSDL
« Reply #2 on: May 01, 2020, 05:36:14 am »
I'm suspecting that the bootloader has been replaced, as I didn't have any luck with a Volcano box.
About the JTAG, I'm very new to it. JtagPROBE identified the cpu and the other, non-documented proprietary cpu.
Trying JtagFlasher, it requested a BSDL file.

What software should be used to access cpu debug features?

At the moment I'm trying out a GX15 flasher that I also found at the same site
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 825
  • Country: es
Re: Making your own BSDL
« Reply #3 on: May 01, 2020, 11:06:37 am »
Yes, this CPU has two cores - ARM7TDMI and ADSP21xx. Use some JTAG tool with ARM support (i.e. OpenOCD), connect to ARM7TDMI, halt it, then read memory space. You'll need to know memory address range, look at PC/LR registers after core halt to get an idea where is the code memory.

Boundary scan-based JTAG tools (like that tool asking for BSDL file) will NOT work in this (core debug) mode at all. There can be some CPU pin (something like "nBSCAN") to switch JTAG to boundary scan mode, but working in core debug mode is much easier (no need device-specific BSDL etc).

The bootloader of this chip can't be "replaced". It's in mask ROM, so it works even with an empty flash (and is used for empty board programming for example). Perhaps the protocol has changed a bit between AD6522 and AD6528. With JTAG you can even dump the mask ROM and study it to known the protocol.

Edit: noticed you are getting a J-Link. It will work for sure. I'm not familiar with it's newer GUI tools, but for the command line tool (jlink.exe) the command sequence will be something like this:
connect - connect to the core, select ARM7TDMI with default settings when it asks
h - halt the core
regs - show core registers
mem 0 100 - display memory at 0-0x100
savebin dump.bin 0 100 - save memory 0-0x100 to dump.bin
« Last Edit: May 01, 2020, 11:14:19 am by abyrvalg »
 

Offline oh2ftuTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: fi
Re: Making your own BSDL
« Reply #4 on: May 08, 2020, 12:00:59 pm »
I tried this.
the jlink commander does only give ARM7 as an option.
Using that, it will not connect, here's the printout:
Code: [Select]
Connecting to target via JTAG
TotalIRLen = 8, IRPrint = 0x0015
JTAG chain detection found 2 devices:
 #0 Id: 0x10A62005, IRLen: ?, Unknown device
 #1 Id: 0x027A21CB, IRLen: ?, Unknown device
TotalIRLen = 8, IRPrint = 0x0015
JTAG chain detection found 2 devices:
 #0 Id: 0x10A62005, IRLen: ?, Unknown device
 #1 Id: 0x027A21CB, IRLen: ?, Unknown device

****** Error: CPU-TAP not found in JTAG chain

TotalIRLen = 8, IRPrint = 0x0015
JTAG chain detection found 2 devices:
 #0 Id: 0x10A62005, IRLen: ?, Unknown device
 #1 Id: 0x027A21CB, IRLen: ?, Unknown device
TotalIRLen = 8, IRPrint = 0x0015
JTAG chain detection found 2 devices:
 #0 Id: 0x10A62005, IRLen: ?, Unknown device
 #1 Id: 0x027A21CB, IRLen: ?, Unknown device

****** Error: CPU-TAP not found in JTAG chain

Cannot connect to target.

this does not have the AD analog baseband, but a proprietary chip in place of it.
#0 is the proprietary
#1 is the AD6528DABCZ
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 825
  • Country: es
Re: Making your own BSDL
« Reply #5 on: May 10, 2020, 09:47:35 am »
I’m sure I had JTAG ARM7 debug working on GD55. Try targeting JLink to the second device by specifying IRPre=4/DRPre=1 values (either with cmd “config 4,1” or a param to jlink.exe “-jtagconf 4,1”.
Unfortunately I’m away from my old archives due to COVID lockdown :(
 

Offline oh2ftuTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: fi
Re: Making your own BSDL
« Reply #6 on: May 10, 2020, 11:02:58 am »
That didn't work either. Seems like I'm missing something very easy.
JTAGEN is high, and unless it's high nothing is found on the bus.
This is not a gsm-phone, so that might affect it. Also, a Volcano Box (nor any phone software) was not able to identify this on the serial line.

Interesting indeed.
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 825
  • Country: es
Re: Making your own BSDL
« Reply #7 on: May 10, 2020, 04:09:06 pm »
Regarding the serial boot: there are two boot mode control pins (look for "Boot Control 0/1" in GX15 schematic), maybe you need to set them to the correct state (GX15 PDF says BC0=1, BC1=0 is UART boot). An older AD6522 I'm talking about had no USB at all, so there were just two boot modes, but your AD6528 has 4.
Trying to activate the USB boot mode could be interesting too if you manage to find an appropriate software for it. I see an original SPST here: http://evil-hackers.com/Sharp/, but it is protected with WIBU dongle (but at least there is an USB driver for device with PID=6528 - nice). Looking at that SPST suggests that all models from GX15 to GX30 were based on the same CPU, so some other tool (i.e. this http://evil-hackers.com/Sharp/Flasher/PLATIJET_flashers.rar) could work.
 

Offline oh2ftuTopic starter

  • Regular Contributor
  • *
  • Posts: 52
  • Country: fi
Re: Making your own BSDL
« Reply #8 on: May 10, 2020, 04:28:46 pm »
Both GPIO_55 and GPIO_56 are connected directly to ground.
USB seems very un-utilized on this device
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 825
  • Country: es
Re: Making your own BSDL
« Reply #9 on: May 10, 2020, 05:19:32 pm »
So that can be the reason why UART tools don't work. Is it possible to disconnect GPIO56 from GND?

JTAG: I've seen some SoCs showing up in "system top level" mode by default, then switching to core debug mode with some dedicated command written to IR. You could try brute forcing IR commands with jlink's "wjc" cmd (followed by "i" identify cmd to observe possible changes in IDCODEs). Like this:
wjc 0
i
wjc 1
i
...
These things can be more complicated (like specific IR cmd selects some "mode control" register, then writing a correct value into DR selects debug mode), would be much harder to try all combinations in that case.

Another possible direction is to study your existing dump (you've dumped some part of flash with Arduino, right?) to find some bootloader there and try talking it's protocol.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf