Making your own BSDL

[abyrvalg]

The shutdown could be due to some watchdog not being fed. You can try adding halt and mdb right to your .cfg script to run mdb ASAP after halt to see if it dumps anything at all. Or try reset halt instead of normal halt to stop the CPU right after reset. You’ll need the RESET line connected for that (and, perhaps, some additional configuration or the reset method).

[oh2ftu]

My guess is that halting the CPU shuts down some GPIO (might be from the AD6528 or the proprietary analog baseband cpu) that controls power circuitry.

Looking at the GX15 schematic the analog baseband cpu (AD6537B in the GX15) has input for powonkey AND it does the power conversion. Blimey.
This device has a proprietary thing so ... that's that.

The flash seems to have both 1.8V and 3V. so I guess I will have to inject both 1,8V and 3V, as 3V is done from battery.
It's quite hard to find the "power enable" spot without a schematic.

[abyrvalg]

No, halting freezes GPIO pins. Typical source of such problems is either an internal watchdog expecting periodic “feed”, an external watchdog expecting some pin toggling (and we freeze it) or other cores not expecting the halt.
Have you tried reset halt?

[oh2ftu]

No, halting freezes GPIO pins. Typical source of such problems is either an internal watchdog expecting periodic “feed”, an external watchdog expecting some pin toggling (and we freeze it) or other cores not expecting the halt.
Have you tried reset halt?

Hi,
I would venture a guess that the analog BB shuts down power when it loses connection to ad6528 (digital baseband cpu) - may it be a watchdog or what.

I decided to 3dprint a JIG that would allow easy access to the 1.8V line. Then I'd still need some hardware to get that 1.8V working.
Too bad there's no information whatsoever available on the analog BB cpu. It's proprietary.

Reset halt:

Code: [Select]

> reset halt
TAP UNKNOWN.unknown0 does not have valid IDCODE (idcode=0x4f44396)
JTAG tap: ad6528.cpu tap/device found: 0x027a21cb (mfg: 0x0e5 (Gadzoox Networks), part: 0x27a2, ver: 0x0)
ad6528.cpu: how to reset?


[abyrvalg]

You need to configure the reset method before issuing a reset command (either in the cfg file or manually). Use reset_config srst_only or if you have both the system reset signal and the jtag reset (nTRST) connected, use reset_config trst_and_srst to use both of them. With this command present OpenOCD should know how to reset the chip.

[oh2ftu]

Sorry, I've been busy with both work and life.
I managed to find where the cpu 1.8V testpoint is, so I designed a new adapter with provisions for a 1.8V regulator. Furthermore i ordered the parts needed. Still waiting for the boards though.
In the mean time I've been trying to get a grasp of the power delovery on the board.
I still don't know what turns on the smps's (5V and 3V).
I located the CGP-marked sot-23-5(?) That outputs 1.8V and the enable comes from ... drumroll... the 3V rail. Direct. And the debug-connection has a 3V input.
Haven't tested it, but will do shortly. Good to note is that the flash reset and write protect (RPf anf WPf) are both connected to the same output on a AND-gate, which in turn has both inputs connected to the debug conn AND analog baseband cpu.
Will be busy next week too so I decided to make an update.

[oh2ftu]

Finally.
I had some time to look at the board, and test.
Injecting 3V will keep the CPU going, no battery needed to be connected.

Code: [Select]

> halt
target halted in Thumb state due to debug-request, current mode: System
cpsr: 0x200000ff pc: 0x025321d6
> arm reg
System and User mode registers
      r0: 00000007       r1: 00040000       r2: 0000001e       r3: 0000000c
      r4: ffffb575       r5: 802000a0       r6: ffffffc0       r7: 082c4790
      r8: bbbbbbbb       r9: bbbbbbbb      r10: bbbbbbbb      r11: bbbbbbbb
     r12: 00000000   sp_usr: 0856c4e0   lr_usr: 025321cb       pc: 025321d6
    cpsr: 200000ff

FIQ mode shadow registers
  r8_fiq: fffffffe   r9_fiq: bfefffff  r10_fiq: ffbf6fdf  r11_fiq: dfff7f3b
 r12_fiq: ffbf3dbe   sp_fiq: 4005bd48   lr_fiq: 40046c7c spsr_fiq: 4000003f

Supervisor mode shadow registers
  sp_svc: 40046100   lr_svc: 024eab38 spsr_svc: 8000003f

Abort mode shadow registers
  sp_abt: bfdf7fff   lr_abt: ffffff7f spsr_abt: f00000ff

IRQ mode shadow registers
  sp_irq: ffdfffff   lr_irq: 3fff7fff spsr_irq: f00000ff

Undefined instruction mode shadow registers
  sp_und: ffbf3f7f   lr_und: ffbff77f spsr_und: f00000ff

> mdb 0 0x100
0x00000000: dc f0 9f e5 1e 00 00 ea 09 00 00 ea 1f 00 00 ea 21 00 00 ea 00 00 a0 e1 22 00 00 ea 35 00 00 ea
0x00000020: c0 f0 9f e5 00 00 a0 e1 00 00 9f e5 0e f0 b0 e1 1f 00 00 00 d3 f0 21 e3 10 00 0f e5 00 00 4f e1
0x00000040: 20 00 10 e3 b2 00 5e 11 b4 00 5e 01 ff 00 00 e2 ab 00 50 e3 56 00 50 13 f2 ff ff 0a 04 00 50 e3
0x00000060: 00 f1 9f 97 04 00 00 ea 3c bf 4e 02 b4 bf 4e 02 9c bf 4e 02 7c 00 00 00 4c bf 4e 02 08 c0 a0 e3
0x00000080: 0c 00 00 ea db f0 21 e3 04 c0 a0 e3 09 00 00 ea d7 f0 21 e3 0c c0 a0 e3 06 00 00 ea d7 f0 21 e3
0x000000a0: 10 c0 a0 e3 03 00 00 ea d2 f0 21 e3 14 c0 a0 e3 00 00 00 ea 18 c0 a0 e3 2c d0 9f e5 ff 7f 4d e9
0x000000c0: 00 00 a0 e1 0c 00 a0 e1 08 10 1d e5 3c d0 4d e2 0e 20 a0 e1 14 30 9f e5 24 30 93 e5 10 40 9f e5
0x000000e0: 14 ff 2f e1 00 00 18 02 84 c1 4e 02 00 04 00 00 e4 2d 05 40 c1 af 21 02 e4 00 5e e3 57 00 00 9a

And the other region

Code: [Select]

> mdb 0x02000000 0x100
0x02000000: 1c f0 9f e5 05 00 00 ea 04 00 00 ea 03 00 00 ea 02 00 00 ea 00 00 a0 e1 00 00 00 ea ff ff ff ea
0x02000020: fe ff ff ea 00 00 02 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x02000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x020000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x020000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x020000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Finally, some data!
The flash is 256Mbit, so 32MB. Size in hex 0x02000000?
Where would this area be?

[oh2ftu]

so.
Five years ago I dumped a bare flash with an arduino. I had varying results - ie not consistent. Bits were flipped etc.

Yesterday I dumped dump_image filename.bin 0x02000000 0x02000000 and got similar results. Granted from a different device, but a few looks here and there confirmed that the flash seem to start at 0x02000000.

Now, could I use openocd flash-tools with CFI?

Code: [Select]

flash bank name driver base size chip_width bus_width target

The example from the docs:

Code: [Select]

To configure two adjacent banks of 16 MBytes each, both sixteen bits (two bytes) wide on a sixteen bit bus:

flash bank $_FLASHNAME cfi 0x00000000 0x01000000 2 2 $_TARGETNAME
flash bank $_FLASHNAME cfi 0x01000000 0x01000000 2 2 $_TARGETNAME
To configure one bank of 32 MBytes built from two sixteen bit (two byte) wide parts wired in parallel to create a thirty-two bit (four byte) bus with doubled throughput:

flash bank $_FLASHNAME cfi 0x00000000 0x02000000 2 4 $_TARGETNAME

Now I don't know about the banks? the flash is a 16Mx16 piece (multiple bank, bultilevel burst).

Should this be configured as 16 banks?

[oh2ftu]

Long story short; I got CFI working. But it is VERY slow.
Dump_image was getting about 4KiB/s, while flash read_bank gives a tenth of that.
The flash is recognized;

Code: [Select]

> flash info 1
#1 : cfi at 0x02000000, size 0x02000000, buswidth 2, chipwidth 2
..... addresses ....
CFI flash: mfr: 0xf01c, id:0xe59f
qry: 'QRY', pri_id: 0x0001, pri_addr: 0x010a, alt_id: 0x0000, alt_addr: 0x0000
Vcc min: 1.7, Vcc max: 2.0, Vpp min: 8.5, Vpp max: 9.5
typ. word write timeout: 256 us, typ. buf write timeout: 512 us, typ. block erase timeout: 1024 ms, typ. chip erase timeout: 1 ms
max. word write timeout: 512 us, max. buf write timeout: 1024 us, max. block erase timeout: 4096 ms, max. chip erase timeout: 1 ms
size: 0x2000000, interface desc: 1, max buffer write size: 0x40

intel primary algorithm extend information:
pri: 'PRI', version: 1.3
feature_support: 0x3e6, suspend_cmd_support: 0x1, blk_status_reg_mask: 0x1
Vcc opt: 1.8, Vpp opt: 9.0
protection_fields: 2, prot_reg_addr: 0x80, factory pre-programmed: 8, user programmable: 8

Any idea how to speed things up a bit?

[abyrvalg]

Congratulations! That dump looks like valid ARM code.

Speeding the things up - you don’t need to use flash commands for reading, they read the same data dump_image does, just in some less efficient manner. The only thing requiring flash is writing. Try raising TCK frequency instead, i.e. adapter speed 10000 should set it to 10MHz.

Another totally different possible approach is to dump the BootROM (looks like it is right at 0, the size needs to be guessed by trying), reverse engineer the serial boot protocol (I can help with that) and use it instead of JTAG.

[oh2ftu]

Hi,
dump_image went to about 22KiB/s with 1MHz speed, going over that didn't speed things up.
I will take a few dumps and have a look-see.
The boot-rom is bottom type if that's of any concern - and isn't dumping the whole shebang enough? lot's of FF though.
About  8MB of real code, rest is empty.

[abyrvalg]

The memory at 0x0 is not a BootROM indeed. Looks like it is some RAM holding vector table and exception handlers and it’s content originates from flash (init code inside flash have copied this code from flash to RAM to catch exceptions/interrupts), so nothing valuable there. All those vectors lead to 0x02xxxxxxxx flash.