search

csersoft / hi_sd5115_openocd_config

Hisilicon SD5115 OpenOCD Config file
GNU General Public License v3.0
12 stars 2 forks source link

JTAG pinout and use or not nTRST #2

Open crazygsm opened 5 years ago

crazygsm commented 5 years ago

Hello,

Was checking your project but I still not able to communicate with SD5115 with JTAG

Can you share pinout in this model and if is necessary to have any special sequence to communicate?

thanks in advance.

csersoft commented 5 years ago

Hello, Pull-up DBGSEL pin on power-up, You can refer to these two links: https://blog.csersoft.net/archives/121 https://blog.csersoft.net/archives/196

crazygsm commented 5 years ago

thank you.

Will try it and revert. In fact model where I am working is 47H instead of 45H but also uses the SD5115 and jtag have same pinout.

But I am a bit concerned regarding this part "After a period of debugging analysis, it is concluded that JTAG should be enabled by default after the CPU is powered on. StartCode will also not close JTAG. Closing JTAG is done by UBoot. Disabling JTAG is accomplished by writing a 1 to a memory address."

In my case UBoot works fine so I suspect will disable JTAG at that moment.

csersoft commented 5 years ago

May be related to the uboot version, Disabling JTAG seems to be before booting the kernel, Here is my cracked uboot file (for HG8245H): http://www.chinadsl.net/thread-128798-1-1.html Download: 8245H_R16_UB_PAT_FULL.zip

crazygsm commented 5 years ago

Mainly my issue is the fact my router have a customized firmware without root user, due this I cannot configure it accordingly.

UART don't have shell implemented, we can see only the boot sequence and then after around 10sec no more output and don't accept input.

Firmware: Due customization and no root user cannot be uploaded new firmware.

Idea is to use jtag to download firmware, add root user and flash it back.

PS: great work you did.

csersoft commented 5 years ago

My previous situation is similar to yours. To restore the router, JTAG and UART and Ethernet ports must be used together. The original UBOOT generally disable the command line interface. Need to manually crack and patch the uboot file, reference link: https://blog.csersoft.net/archives/174 After cracking, you can enter the Hisilicon command line interface. At this time, you can interact with the device in the UART. Write the firmware partition (mtd*) to the memory by JTAG or TFTP command, and then write back to the flash device.

crazygsm commented 5 years ago

Finally I managed to "talk" with it over jtag

CPU Chip ID: 01001011101000000000010001110111 (4BA00477)

Tomorrow if have time will continue investigations. For now and to simplify was just using tjtag (not openOCD) to obtain CPU ID.

crazygsm commented 5 years ago

Hello,

Got stucked at this point, after several search no way to figure out where is the issue.

Is returning " UNEXPECTED: 0xffffffff" and due no match don't go further.,

Any ideia?

Regards

root@raspberrypi:/home/pi/openocd-git# openocd -f raspberrypi-due.tcl -f hi_sd5115_jtag.cfg Open On-Chip Debugger 0.10.0+dev-00746-g8f518d35 (2019-03-19-11:45) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html SysfsGPIO nums: tck = 11, tms = 25, tdi = 10, tdo = 9 SysfsGPIO nums: swclk = 11, swdio = 25 Info : auto-selecting first available session transport "jtag". To override use 'transport select '. adapter speed: 500 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m reset_config sysresetreq sd5115_help Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : SysfsGPIO JTAG/SWD bitbang driver Info : JTAG and SWD modes enabled Warn : gpio 11 is already exported Warn : gpio 25 is already exported Info : This adapter doesn't support configurable speed Info : JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Info : JTAG tap: sd5115.cpu tap/device found: 0xffffffff (mfg: 0x7ff (), part: 0xffff, ver: 0xf) Warn : JTAG tap: sd5115.cpu UNEXPECTED: 0xffffffff (mfg: 0x7ff (), part: 0xffff, ver: 0xf) Error: JTAG tap: sd5115.cpu expected 1 of 1: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4) Error: Trying to use configured scan chain anyway... Error: sd5115.cpu: IR capture error; saw 0x0f not 0x01 Warn : Bypassing JTAG setup events due to errors Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response Error: Invalid ACK (6) in DAP response

csersoft commented 5 years ago

Are you using a Raspberry Pi for JTAG connection? I only tried the FT2232H to connect, I don't know how to solve your problem.

crazygsm commented 5 years ago

Yes, raspberry pi for jtag connection, I don't have the interface for FT2232H

and for reference in case someone else face same issue, I had to do a small change in the code adding 2 lines to create the target and comment the original one, openocd was giving error for "chain-position" and requesting to user "dap".

set _TARGETNAME $_CHIPNAME.cpu dap create $_CHIPNAME.dap -chain-position $_TARGETNAME target create $_TARGETNAME cortex_a -endian $_ENDIAN -dap $_CHIPNAME.dap

target create $_TARGETNAME cortex_a -endian $_ENDIAN -chain-position $_TARGETNAME

crazygsm commented 5 years ago

Finally I managed to init_hw

sd5115_hwinit background polling: on TAP: sd5115.cpu (enabled) target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x000001d3 pc: 0xfffffffc MMU: disabled, D-Cache: disabled, I-Cache: disabled cpsr (/32): 0x000001D3 Info: (arm mrc 15 0 0 0 5) & 0xf == 0 . Info: call offset 0x6EC . Info: call offset 0x700 . Info: call offset 0x710 . Info: call offset 0xFAD4 . Info: call offset 0xFCD4 . Info: call offset 0xFAF4 . Info: call offset 0xFBD8 . Info: call offset 0xFED4 (init dram). Info: init dram... Hardware initialization is complete!

Before try upload your start_code I will dump the current SC,Uboot, etc..

Seems it's different in this model

0x000000000000-0x000000100000 : "startcode" 0x000000100000-0x000008000000 : "ubifs" 0x000008000000-0x000008000000 : "reserved"

How you have identified the bit in startcode to be changed?

csersoft commented 5 years ago

0x000000000000-0x000000100000 : "startcode" 0x000000100000-0x000008000000 : "ubifs" 0x000008000000-0x000008000000 : "reserved"

Congratulate! These addresses are in the flash device and are not in memory. You can't read directly to flash. In addition to startcode, all other parts can be extracted in the full firmware. This script simply writes the attached startcode to memory and runs it without breaking the startcode in the flash.

crazygsm commented 5 years ago

thanks again for all the support, guess I am almost there.

Managed to get the startcode from this model, will try to upload it for reference. Also I managed to upload your StarCode using the steps and worked also.

Now I am just struggling in the correct way to do the same for the Uboot to could access console.

Should also be directly to memory? What should be the correct way to load your Cracked_Uboot?

csersoft commented 5 years ago

For the same CPU product, startCode should be the same. After startCode is executed, it will try to load the uboot in the flash into memory and run it. If the uboot in the flash is invalid, it will block (maybe). At this time, the cracked uboot needs to be loaded into the memory through JTAG and run (the address seems to be 0x81F00000).

OpenOCD Command: halt ; load_image 8245H_R16_UB_PAT_FULL.BIN 0x81F00000 ; resume 0x81F00000

Reference: http://www.chinadsl.net/thread-128798-1-1.html

crazygsm commented 5 years ago

Your Uboot worked fine and I got the hisilicon console but when think I am there I face a new issue :/

I could not manage at all to launch the kernel/linux from there or dump flash. What I really need is to start linux with serial console enabled or dump the NAND content.

Any idea?

csersoft commented 5 years ago

Boot the kernel: Run printenv first, then execute the command corresponding to bootcmd. Dump nand flash content: Use the command to read the nand partition to the blank memory address (try 0x84000000) and then read it out via JTAG.

crazygsm commented 5 years ago

After write I figured out the reason, I had to disable NAND to force JTAG. Finally I found a way to just made fail the uboot loading but only after startcode had initialized NAND and then I could access it.

Trying now to dump NAND to memory to collect using JTAG.

What still unclear to me is why even using the cracked Uboot after boot firmware still no UARTserial console to interact with the OS, tried do some changes in "BootArgs" but still not activating.

Bellow in the log can be seen the NAND load is correct and fails in uboot part (forced by me).

HuaWei StartCode 2012.02 (R15C10 Apr 03 2015 - 01:24:45)

NAND: Nand(Hardware): 128 MiB
startcode select the uboot to load
the high RAM is :8080103c
startcode uboot boot count:-1005561840
Slave struct initializtion success!!
Use the UbootA to load first
Start from UbootA ERROR, Change to UbootB Both UbootA and UbootB are wrong, load it by JTAG!

U-Boot 2010.03 (R16C10 Jul 14 2016 - 14:19:37)

DRAM: 128 MB
Boot From NAND flash
Chip Type is SD5115T
NAND: Special Nand id table Version 1.23
Nand ID: 0x01 0xF1 0x00 0x1D 0x01 0xF1 0x00 0x1D
ECC Match pagesize:2K, oobzie:64, ecctype:4bit
Nand(Hardware): Block:128KB Page:2KB Chip:128MB*1 OOB:64B ECC:4bit
128 MiB
Using default environment

In: serial
Out: serial
Err: serial
MEM_MODE = MEM!
[main.c__6080]::CRC:0x51a2092, Magic1:0x5a5a5a5a, Magic2:0xa5a5a5a5, count:0, C0 0x000000100000-0x000008000000 : "mtd=1"
UBI: attaching mtd1 to ubi0
slave_paramA in flash, CRC:0x6a8fe445, Magic1:0x5a5a5a5a, Magic2:0xa5a5a5a5, co0 use slave_paramA which is from flash, the RAM data is not OK!!!
Start from main system(0x1)!
CRC:0x6a8fe445, Magic1:0x5a5a5a5a, Magic2:0xa5a5a5a5, count:1, CommitedArea:0x10 Main area (B) is OK!
CRC:0xc4e775d4, Magic1:0x5a5a5a5a, Magic2:0xa5a5a5a5, count:1, CommitedArea:0x10 Loading file 'doublecore' to addr 0x85a00000 with size 2 (0x00000002)...
Done
Unmounting UBIFS volume file_system!
Unmount ubifs success!
Bootcmd:ubi read 0x85c00000 kernelB 0x1b500a; bootm 0x85c00054
BootArgs:noalign mem=118M console=ttyAMA1,115200 ubi.mtd=1 root=/dev/mtdblock12n U-boot Start from NORMAL Mode!
hisilicon #
hisilicon # printenv bootdelay=1 baudrate=115200 ethaddr=00:0a:0b:0c:0d:0e ipaddr=192.168.0.10 serverip=192.168.0.1 netmask=255.255.255.0 bootfile="uImage" mtdids=nand0=nand0 flashsize=128M mtdparts=mtdparts=nand0:0x100000(startcode),0x7F00000(ubifs) stdin=serial stdout=serial stderr=serial verify=n ver=U-Boot 2010.03 (R16C10 Jul 14 2016 - 14:19:37) partition=nand0,0 mtddevnum=0 mtddevname=startcode bootcmd=ubi read 0x85c00000 kernelB 0x1b500a; bootm 0x85c00054 bootargs=noalign mem=118M console=ttyAMA1,115200 ubi.mtd=1 root=/dev/mtdblock12n

Environment size: 713/262140 bytes hisilicon #

crazygsm commented 5 years ago

It took almost 24h but I managed to download the full flash content (128Mb)

Will check now the better option to sort it into the blocks and then try to decrypt.

Now the main issue will be know the address and lenght for each partition ubootA ubootB flash_configA flash_configB slave_paramA slave_paramB kernelA kernelB rootfsA rootfsB wifi_paramA wifi_paramB system_param file_system

Is already known for the HG8245H?

csersoft commented 5 years ago

You need to run on a device that can boot normally: cat /proc/mtd Generally the entire flash is divided into 2 parts: The first 1MB is startCode, and the first 127MB is ubifs.

megaraider commented 5 years ago

And the serial console log also gives some hints at what address they're located, e.g.: ubootA, ubootB, slave_paramA, slave_paramB, ... The device address map has to be converted to the Flash physical address.

crazygsm commented 5 years ago

Not that simple apparently.

Already sorted into a unique file the UBIFS

laptop@laptop ~/$ python ubidump-master/ubidump.py -d /home/laptop/ubifs.bin ==> /home/laptop/ubifs.bin <== 14 named volumes found, 13 physical volumes, blocksize=0x20000 == volume ubootA == E: magic num mismatch == volume ubootB == E: magic num mismatch == volume flash_configA == E: magic num mismatch == volume flash_configB == E: magic num mismatch == volume slave_paramA == E: magic num mismatch == volume slave_paramB == E: magic num mismatch == volume kernelA == E: magic num mismatch == volume kernelB == E: magic num mismatch == volume rootfsA == E: magic num mismatch == volume rootfsB == E: magic num mismatch == volume wifi_paramA == E: volume does not contain lnum == volume wifi_paramB == E: volume does not contain lnum == volume system_param == E: magic num mismatch == volume file_system == E: volume does not contain lnum

Tried to mount it using the nandsim but is giving me this error.

laptop@laptop ~ $ sudo modprobe nandsim first_id_byte=0x01 second_id_byte=0xF1 third_id_byte=0x00 fourth_id_byte=0x1D laptop@laptop ~ $ sudo modprobe ubi laptop@laptop ~ $ sudo modprobe ubifs

laptop@laptop ~ $ sudo dd if=ubifs.bin of=/dev/mtd0 262144+0 registos dentro 262144+0 registos fora 134217728 bytes (134 MB) copiados, 1,16179 s, 116 MB/s

laptop@laptopL ~ $ sudo ubiattach --mtdn=0 UBI device number 0, total 1024 LEBs (132120576 bytes, 126.0 MiB), available 998 LEBs (128765952 bytes, 122.8 MiB), LEB size 129024 bytes (126.0 KiB) laptop@laptop ~ $

laptop@laptop ~ $ cat /proc/mtd dev: size erasesize name mtd0: 08000000 00020000 "NAND simulator partition 0"

laptop@laptop ~ $ ls -ls /dev/ubi* 0 crw------- 1 root root 243, 0 Mar 27 21:53 /dev/ubi0 0 crw------- 1 root root 10, 54 Mar 27 21:51 /dev/ubi_ctrl

laptop@laptop ~$ sudo mount -t ubifs -o ro /dev/ubi0 /mnt/ubifs/ mount: wrong fs type, bad option, bad superblock on /dev/ubi0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so

laptop@laptop ~$ dmesg | tail [ 257.406948] ubi0: scanning is finished [ 257.407873] ubi0: attached mtd0 (name "NAND simulator partition 0", size 128 MiB) [ 257.407879] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes [ 257.407882] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512 [ 257.407885] ubi0: VID header offset: 512 (aligned 512), data offset: 2048 [ 257.407888] ubi0: good PEBs: 1024, bad PEBs: 0, corrupted PEBs: 0 [ 257.407891] ubi0: user volume: 0, internal volumes: 1, max. volumes count: 128 [ 257.407894] ubi0: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 360987593 [ 257.407897] ubi0: available PEBs: 998, total reserved PEBs: 26, PEBs reserved for bad PEB handling: 20 [ 257.407907] ubi0: background thread "ubi_bgt0d" started, PID 3144

megaraider commented 5 years ago

I strongly advise you to make several Flash dumps and check for integrity, as you've got no confirmation your dump is correct. Furthermore, when doing Flash dumps it's far more productive to extract page by page or multiple page chunks, at least twice, to make sure error free dumps are made.

Also, keep connecting wires, between the JTAG port and the FT2232H module, to the bare minimum length possible.

megaraider commented 5 years ago

After having a full verified flash dump, imo you should tackle it using ‘binwalk’ not ‘nandsim’. Keep in mind that most often the volumes are compressed (major exception for the bootcode).

Thus not only ‘binwalk’ will display the address map (might fail here being 100% correct) but as well extract, decompressing if needed, each volume.

Even then, when mounted, some (crucial) files are bound to be AES encrypted. Therefore, these have to be decrypted before reading / changing contents, and encrypted back again when modified. But it doesn’t end here… Because length and CRC have changed these have to be calculated and replaced.

yt1dl commented 5 years ago

I also use RPI for JTAG SD5115 and got same error like you (Invalid ACK (6) in DAP response). Haw did you manage to JTAG SD5115 with your RPI? Thank you...