R&S RTB2004 Snooping - Page 1
Forum section: electronics / testgear

author: ElectronMan
author_rank: Regular Contributor
timestamp: September 20, 2020, 07:23:19 pm
content: The other day I was looking at my RTB2004 and wondering what makes it tick. Given the availability of fully-optioned scopes with the COM4 bundle when it was launched, it seems to not hold a lot of interest for people to scrutinize its innards.So, I took it apart and dug in to tease out its secrets. It is important to note that I am not focused on "hacking" licenses or anything like that. My interest is mostly in learning how it ticks.With that out of the way, there are 3 prominent debug connectors on the bottom of the mainboard. There is a 4-pin white connector, a 10-pin white connector, and a special 12-pin red connector.The 4-pin seems to have a 115.2kbps UART on it. It spits out unintelligible binary data immediately on boot.The 12-pin red connector (helpfully labeled) appears to be JTAG for 2 Altera Cyclone V FPGA device instances according to openOCD.The 10-pin white connector is the one I focused my efforts on. It is labeled HPS. This is for the Cyclone V's HPS (Dual core Arm Cortex A9 processor) that is built into their Cyclone V FPGA's, and is the primary processor that handles the UI.Using this minimal OpenOCD config, I can get access to read/write memory, set breakpoints and watchpoints etc:Code:source [find interface/jlink.cfg]reset_config trst_and_srstif { [info exists CHIPNAME] } {set _CHIPNAME $CHIPNAME} else {set _CHIPNAME fpgasoc}if { [info exists DAP_TAPID] } {set _DAP_TAPID $DAP_TAPID} else {set _DAP_TAPID 0x4ba00477}jtag newtap $_CHIPNAME dap -irlen 4 -ircapture 0x01 -irmask 0x0f -expected-id $_DAP_TAPIDadapter_khz 4000set _TARGETNAME1 $_CHIPNAME.cpu.0target create $_TARGETNAME1 cortex_a -chain-position $_CHIPNAME.dap -endian little -coreid 0 -dbgbase 0x80110000initcortex_a dbginitI started by examining memory dumps using OpenOCD's "dump_image" command. The memory configuration seems to put main SDRAM at memory address 0x10000000, and the CycloneV HPS memory mapping shows on-chip RAM @ 0xFFFF0000. The internal Altera Bootrom is @ 0xFFFD0000.Access to memory is all well and good, but the contents of NAND flash would be even better. Inte'ls docs on the CycloneV HPS (https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#topic/sfo1410068585834.html) give detailed information on the I/O memory mapping of the NAND controller (0xFFB80000 for control, FFB90000 for data), and with openOCD it is possible to read/write these registers directly (we don't have a driver).The NAND Flash is visible on the PCB, but just to verify functionality of the NAND controller while the CPU is halted, we can check appropriate registers with OpenOCD:Doing some binary math, we can build and write a command to disable DMA on the NAND controller (necessary for our commands), select the first block and page, and read the first 16 words to verify we are getting good data.With the particular command we are sending to the controller, it opens a page-size (2048 bytes) window @ 0xFFB90010 starting at the selected block/page. To get the full page we can just use openOCD's dump_image again, then select the next block/page and so forth. There are 4096 blocks with 64 pages per block with 2048 bytes per page.A little scripting and 24hrs later (JTAG is SLOW) and you have a 512M NAND image.binwalk returns a TON of images and files, some of the most interesting being the ELF binary executables, and the uBoot image:The uboot image (via strings) has some interesting references to "MesOS" and appears to be an emergency boot image with debug capabilities:Code: Writes a string.<adr> <n> Loads n-bytes (binary) at <adr> in memory.<src_adr> <n> <dst_adr> Copys n-bytes memory from <src_adr> to <dst_adr>.[<form> [<adr1> [<adr2>]]] Displays memory at <adr1> to <adr2> with <form> (1, 2, 4 Byte).<adr1> <adr2> [<pattern>] Testing memory from <adr1> to <adr2> with <pattern> and !<pattern> (def: 0x55555555).<adr> <value> <size> Change memory at <adr> at <size> (1, 2, 4 Byte) to <value>.<src_adr> <n> <dst_adr> Copys n-bytes memory from RAM to NAND-Flash (<dst_adr> blockaligned!)<src_adr> <n> <dst_adr> Copys n-bytes memory from NAND-Flash to RAM (<src_adr> blockaligned!)<dst_adr> <n> <value> Fills n-bytes in NAND-Flash with <value> (<dst_adr> blockaligned!)<log_adr> [<dst_adr>] [<n>] Load and exec programm from <log_ adr> SD-Card/Nand at dst_adr ) with n-Byte (def: 0x73f33000 0x00120000 0x20000).<adr> Start decrypted Update loaded at <adr>.[<adr>] Quits 'MonDeb' and starts execution at <adr> (def: restart).[<src_adr> [<n>]] Update Monitor from RAM with <src_adr> (def.: 0x0c000000) and <n> Bytes (def.: 0x10000) AND REBOOT!!!Quits 'MonDeb' and reboot at 0x0.Quits 'MonDeb' and reboot at 0x0 too.Displays the version of 'MonDeb'.Displays the detailed version of 'MonDeb'.Displays this short help.Displays this short help too.MonDeb>QuittingVersion:Monitor & Debugger for MesOSHardware: CycloneVSoCVersion:Date: Oct 6 2016 16:40:22The first ELF binary is ~2.2MB appears to be a firmware updater:Code:FWUPDATESERVICENVRAMPWFUSBOCFUSBFUSBTESTDIAGNOSTICPlease attach a USB flash drive containing a firmware update.Abort!Update failed!Checksum incorrect!Loading file info ... done.No file found!Loading file ...The checksum of the firmware update is correct.done.Running update ... ! DO NOT SWITCH OFF THE DEVICE !Reset internal memories ...Update file OK.Searching, please wait ...USB flash drive ready.File search starts in %i seconds.The second one is ~20MB and appears to be the main binary. These are all static, stripped binaries with no relocations. The RTB2004 runs binaries bare-metal without an actual Operating system. This explains why it boots so quickly. You can see references to various memory areas via readelf, including .fpga_ram, which jives with the CycloneV HPS docs (0xc0000000 is the shared FPGA-HPS memory region).I'm actually pretty impressed with what R&S has done here. Other vendors build on top of a pre-made OS. They seem to have developed their application for bare-metal and implemented it pretty efficiently. So far the most interesting stuff I have found reference a "textInit" file or folder on USB storage, but I haven't yet figured out if I can use this for something:

author: tv84
author_rank: Super Contributor
timestamp: September 20, 2020, 07:37:28 pm
content: Finally!

author: ElectronMan
author_rank: Regular Contributor
timestamp: September 20, 2020, 09:22:10 pm
content: In case anyone wants to dump their own NAND, I have attached my messy perl script.Pre-requisites:- Perl installed with Net::Telnet CPAN package.- OpenOCD must be configured and connected to the device via JTAG successfully.- OpenOCD must be listening on a user telnet port- The top of the script has settings that must be configured.The script will halt the CPU of the scope, disable NAND controller DMA, and start dumping. It will take many hours. You can continue a dump by specifying the 2 parameters (./rtb_nand_dump.pl <starting_block> <starting_page>) and it will append to the configured file. Launching without those starts at block 0, page 0.The script strips out the 16 byte block header that is on blocks 1 - 4095. This appears to be part of the NAND management and corrupts files if it is not removed before processing.[Edit to attachment: Fixed bug with restarting from a specified page/block offset]

author: Hydron
author_rank: Super Contributor
timestamp: September 20, 2020, 11:11:44 pm
content: ooh, very interesting, thanks!I have one of the launch promo units, so as mentioned there isn't such a burning reason other than curiosity to poke around, though I did have a look at the SPI bus in mine to see if the front-end VGA was doing the bandwidth limit (probably not was the answer - didn't see any change when enabling the 20MHz limit).Did you see the R&S Open Source Acknowledgement? Sounds like FreeRTOS might be in use:https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_osa/RTB_OpenSourceAcknowledgment_en_01.pdf

author: ElectronMan
author_rank: Regular Contributor
timestamp: September 20, 2020, 11:22:11 pm
content: Quote from: Hydron on September 20, 2020, 11:11:44 pmInteresting. I haven't really seen anything pointing to that, though it could be modified and renamed. As far as I can tell the main ELF is called directly from the boot loader.I have seen a number of libraries being referenced, such as "DietCrypto" used for option keys, and there are plenty of references to this custom library and others:"E:/jenkins/OK-Legacy-Distribution-10/workspace/ok_services_oklib/Src/COptionKeyServiceLib.cpp"I've noticed the main binary also accesses 3 different GPIO ports, and 2 i2c slave devices are present on the i2c bus. I haven't identified them as yet.

author: ElectronMan
author_rank: Regular Contributor
timestamp: September 21, 2020, 05:06:13 pm
content: Quote from: PeDre on September 21, 2020, 04:34:53 pmLooks like that is probably the case then. Following the boot routines, I see it go to the Altera Bootrom first, then jumps to the little 44KB uBoot image at the beginning of Flash (with MesOS references) then jumps into the main ELF executable.

author: ElectronMan
author_rank: Regular Contributor
timestamp: September 27, 2020, 12:03:06 am
content: It seems I did not look closely enough at the 4-pin connector. It is a typical 1.8V UART.From the top of the photo I posted the first pin is GND, and the third pin is UART TX (Device out TX 115.2kbps, 8N1, idle=low).I haven't yet been able to get a response when attempting to transmit on pins 2 or 4, so cannot identify the RX yet.This is the output immediately following poweron:Code:U-Boot SPL 2013.01.01 (Oct 06 2016 - 16:39:22)BOARD : Altera SOCFPGA Cyclone V BoardCLOCK: EOSC1 clock 50000 KHzCLOCK: EOSC2 clock 50000 KHzCLOCK: F2S_SDR_REF clock 0 KHzCLOCK: F2S_PER_REF clock 0 KHzCLOCK: MPU clock 925 MHzCLOCK: DDR clock 400 MHzCLOCK: UART clock 100000 KHzCLOCK: MMC clock 62500 KHzCLOCK: QSPI clock 3613 KHzRESET: WARMSDRAM: Initializing MMR registersSDRAM: Calibrating PHYSEQ.C: Preparing to start memory calibrationSEQ.C: CALIBRATION PASSEDSDRAM: 512 MiBNAND: Denali NAND controllerThe very first thing this U-boot image does is to check GPIO2, PIN 7 to see if it is low, and enters the "MonDeb" debug monitor if it is. So far I can't find a front-panel button that maps to that port/pin, so I am not sure what is supposed to trigger that. It could be that some device asserts that when it has a problem, or some front-panel combination I am missing so far.

author: darkstar49
author_rank: Frequent Contributor
timestamp: September 28, 2020, 03:55:12 pm
content: didn't see this before... well done !!! I'm rather a software guy, I had a (quick) look at the FW files (RTB, RTM, RTA), but these are all encrypted, so there was not much to chew without an image of the boot rom and/or the FW update code (to which I had no access...).

author: tv84
author_rank: Super Contributor
timestamp: September 29, 2020, 08:48:49 am
content: Quote from: ElectronMan on September 27, 2020, 12:03:06 amNo "Hit any key to stop autoboot: " ?

author: ElectronMan
author_rank: Regular Contributor
timestamp: September 29, 2020, 05:53:36 pm
content: Quote from: tv84 on September 29, 2020, 08:48:49 amNope. I only see 2 code checks that cause the "Mondeb" diagnostics to load.It checks a GPIO pin, and branches into it with no error if it is low. Otherwise it checks a memory location and branches into it with an error about being unable to start the bootloader.I managed to force it to take the first code path by changing a register value. So far I have not been able to get a response from UART to keypresses, and I believe it is an issue with my UART dongle.I got a new one and will be retesting soon.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: September 30, 2020, 06:32:05 am
content: Maybe that gpio is on one of those debug connectors? Would be more logical than having it accessible on the front panel (if the mode it triggers requires access to internal UART). Try grounding unknown pins (using some 500 Ohm resistor to stay safe) while observing that gpio reg bit via JTAG?

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 01, 2020, 12:42:37 am
content: Quote from: abyrvalg on September 30, 2020, 06:32:05 amCould be. I was a bit wary of connecting together things that were unknown, so I went the software route to get past it.I've finally made some progress on producing some IDA and Ghidra FunctionID signatures for these binaries too (figuring out the compiler options they used was a bear).

author: reyntjensm
author_rank: Regular Contributor
timestamp: October 05, 2020, 11:21:54 pm
content: I don't understand what you are trying to achieve? Just to see how R&S has build there software? I also have an RTB2004 and i'm very happy with it. I got a big discount on the scope with a lot of options( just send them an email and you can buy straight from the manufacturer, if you ask for a discount they can do some things). Sadly enough i don't have the full bandwith option. I only have 70 MHz.... If you know how to hack it to 300MHz please let me know. Do you know if the FFT functions depend on the bandwith option? I'm not sure about this since i can use the FFT above the 70MHz bandwith. It looks like you are doing very difficult stuff. I hope you don't blow up the logic with poking around, but i'm sure you know what you are doing with this

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 06, 2020, 03:07:03 am
content: Quote from: reyntjensm on October 05, 2020, 11:21:54 pmI just like to know what is inside the "black boxes" that I own. If I find something "useful" or provide a path for someone else to find something useful, all the better.I am pretty much done poking around the insides. I made a JTAG cable and ran it out the little door in the back so I can connect back up if I need to test something. I am using the firmware I recovered to learn more about software reverse-engineering in general. I have no plans to do anything potentially destructive, as this is my primary scope right now.

author: tv84
author_rank: Super Contributor
timestamp: October 07, 2020, 08:35:36 pm
content: Preloader: U-Boot SPL 2013.01.01 (Oct 06 2016 - 16:39:22)Loading address - 0xFFFF0000Bootloader:Code:00010000 Magic: 27051956 uImage File OK00010004 Header CRC-32: FB7A652B [00010000-0001003F] CRC OK00010008 Created: 06/10/2016 14:40:270001000C Data Size: 0000AFB000010010 Data Load Address: 0010000000010014 Entry Point Address: 0000000000010018 Data CRC-32: 8CF4BA9E [00010040-0001AFEF] CRC OK0001001C Operating System: U-Boot Firmware0001001D CPU Architecture: ARM0001001E Type: Firmware Image0001001F Compression: None00010020 Name: Monitor CycloneVSoC CB-2Ax00010040 - Image 0 [00010040-0001AFEF] 0000AFB0 bytesI included also a NAND visual map of its contents (512MB). The initial zone is the bootloader + 7 .ELF files.Code:Offset Size CRC32 ??? #00020001 00222DA0 667AD7B6 0177B8C9 00000000 [00020040-00242DDF] CRC OK0025FEE1 011C2270 99B593B8 017889C3 00000001 [0025FF20-0142218F] CRC OK0143F5F1 01249710 0F20C41A 017A8953 00000002 [0143F630-02688D3F] CRC OK0269ECC1 01255230 13A3E181 017C7C27 00000003 [0269ED00-038F3F2F] CRC OK038FE391 01364C10 55559A0E 0180559F 00000004 [038FE3D0-04C62FDF] CRC OK04C7D9D1 013C9110 35F2A042 0185479D 00000005 [04C7DA10-06046B1F] CRC OK0605CFE1 01482CF0 DE645734 0188065F 00000006 [0605D020-074DFD0F] CRC OK

author: YetAnotherTechie
author_rank: Regular Contributor
timestamp: October 07, 2020, 11:47:01 pm
content: Thank you ElectronMan for your investigation!Can you please post your version numbers?About the NAND, i suggest not stripping but saving the extra NAND bytes to a separate file, this could help in the future to repair a corrupted dump/chip.Do you know that those chips have unique data sectors, that can be programmed only once, have you considered reading them too?

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 09, 2020, 12:24:23 am
content: Quote from: YetAnotherTechie on October 07, 2020, 11:47:01 pmI haven't looked at any of the spare areas on the NAND chip. Everything appears to be out in the open. I can take an image easily enough with the NAND formatting in it, though I don't trust JTAG for writing back to my NAND unless I've got no other choice.Here are the versions (I have never installed most of these, so they must come on there from the factory):Code:25FF20: " [01.100 - HCL: 02.500 - MesOS: 03.760] with GCC 5.3.0"143F630: "Build 39 built on 2017-03-02 15:39:23 by SBC [01.203 - HCL: 02.500 - MesOS: 03.760] with GCC 5.3.0"269ED00: " [01.210 - HCL: 02.500 - MesOS: 03.760] with GCC 5.3.0"38FE3D0: " [02.000 - HCL: 03.100 - MesOS: 04.100] with GCC 5.3.0"4C7DA10: " [02.121 - HCL: 03.200 - MesOS: 04.200] with GCC 5.3.0"605D020: " [02.202 - HCL: 03.300 - MesOS: 04.300] with GCC 5.3.0"

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 09, 2020, 12:31:24 am
content: Found something interesting in memory. 32 bytes, padded with zeros on the end.... I wonder if they use the default AES256-CBC initialization vector for encrypting their firmware......

author: tv84
author_rank: Super Contributor
timestamp: October 09, 2020, 10:03:46 am
content: IV=0

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 09, 2020, 12:20:46 pm
content: Great! I was afraid they hid it in the FPGA part

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: October 09, 2020, 02:10:27 pm
content: Quote from: abyrvalg on September 30, 2020, 06:32:05 amA connector pin or test pad would be my guess as well.

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 09, 2020, 03:49:02 pm
content: Quote from: mikeselectricstuff on October 09, 2020, 02:10:27 pmIt is the second pin down on the UART 4-pin connector from my photo above. I grounded that through a 500Ohm as abyrvalg suggested and I see the GPIO pin register change to low for the pin were were interested in.Edit:I tested this. It looks like you need to un-ground it for the debug prompt to come up. So it seems it is supposed to be like holding a button during power-on then releasing it.Unfortunately, even with my new serial dongle, I am not getting any response from the device when trying to type commands. The bottom connector must be RX, as it is the only one left. Still investigating that.

author: KaneTW
author_rank: Frequent Contributor
timestamp: October 09, 2020, 04:01:18 pm
content: Very cool!

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 09, 2020, 07:59:38 pm
content: Great! If you know UART IO addresses you can try finding Rx the same way as that gpio - setup the PC to send something to the dongle port continuously, touch Rx candidate pins with your dongle’s Tx while observing the UART status/data regs via JTAG.

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 09, 2020, 09:19:40 pm
content: Quote from: abyrvalg on October 09, 2020, 07:59:38 pmI finally figured it out... The Mondeb interface actually uses that same GPIO pin to receive. It provides no echo (so you have to turn on local echo).You have to send BREAK (usually Alt-B on terminals) at the end of each command. You also need to hold BREAK while turning it on to trigger the debug terminal.So from the top of the photo in the original post, the pins on the 4-pin debug connector are:1 - GND2 - UART RX3 - UART TX4 - VCC?

author: tv84
author_rank: Super Contributor
timestamp: October 13, 2020, 07:28:14 pm
content: ElectroMan,Please explain how you did the NAND dump and why the first 0x0800 0000 seem all good and the rest seems to contain raw NAND bytes plus OOB.

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 14, 2020, 09:39:31 pm
content: Quote from: tv84 on October 13, 2020, 07:28:14 pmWhatever "filesystem" they are using seems to place 16 bytes of NAND management data at the beginning of each block after block 0 (possibly data for previous block?) I did not look too much at that and just discarded it, as it was corrupting the extracted firmware sections.Do you have other specific questions about the process? I explained the methodology in the first post and provided the script I used here:https://www.eevblog.com/forum/testgear/rs-rtb2004-snooping/msg3242084/#msg3242084I was basically emulating a crude NAND controller driver via memory reads/writes through OpenOCD to get the NAND contents.The image that was extracted seems to have all the software (and a bunch of different versions), but if there are errors in the latter memory regions it would be difficult to tell for certain what should be there. I double-checked my binary math a few times, and as all the important data seemed to be there I assumed some of the garbage later in the file was an artifact of however they were flashing these from the factory.Note that the apps seem to use about 25-30M of a 512M flash. A lot of the other stuff there are older firmware versions (the scope came with a version newer than most of them on the flash). This leads me to believe the image they use to flash these devices has a lot of stuff left over from earlier testing stages.It is, of course, also possible there's something wrong with my methodology and my binary math fell apart. A second set of eyes on that would be welcome.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 15, 2020, 09:58:21 am
content: Peter’s txt contains an answer: there is an FTL (and that is natural - this is NAND), so in general you can’t just strip and ignore OOB data. It’s a luck (and high quality components choice by R&S) that simple stripping worked on the first part of data without hitting a bad/remapped block. Btw, what about ECC? Is it done automatically by Cyclone’s NAND controller?

author: tv84
author_rank: Super Contributor
timestamp: October 15, 2020, 10:35:23 am
content: Quote from: abyrvalg on October 15, 2020, 09:58:21 amMaybe I used the wrong term. I don't think that those stripped 16 bytes are really OOB with sector recovery info, etc. Maybe more like checksum, framing, etc... it seems too few bytes to have a meaningful goal.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: October 15, 2020, 11:01:10 am
content: Quote from: tv84 on October 15, 2020, 10:35:23 amCould they be ECC data ?

author: tv84
author_rank: Super Contributor
timestamp: October 15, 2020, 11:12:08 am
content: Quote from: mikeselectricstuff on October 15, 2020, 11:01:10 amWell, as I was saying, they sure are OOB (out of band) but they don't seem ECC as they are only 16 bytes for each 16384 bytes block. I think that is very few bytes to do any recovery or error signaling. But, for sure, I'm no expert on this. And, most of all, i think 4 or more bytes are always the same... so it is even less useful data.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 15, 2020, 11:33:22 am
content: Checked the Cyclone docs and ElectronMan's script, the command used for reading (MAP01) handles the ECC internally, NAND spare area is not included in the readout at all. Those 16 bytes should be FTL metadata. PeDre's txt contains Sector Size: 16384 and User Sector Size: 16368 - exactly 16 bytes difference. FTL block map dump (the big part of txt) consists of small entries fitting to 16 bytes easily. I don't have a dump to see how those OOB bytes looks like, could someone post an example?That txt also explains why simple stripping works (for now): all "bad" counters (bad blocks, sectors, ECC errors, relocs etc) are 0.

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 15, 2020, 01:17:10 pm
content: Quote from: tv84 on October 15, 2020, 08:51:43 amI recall when working with a mostly-complete unaltered dump before that the 16-byte block headers may have ended later in the flash. I am taking a raw image now.My scope indicates it has ~380M of free internal flash memory, so I don't think there's anything major missing. I have noticed a few things like screenshot thumbnail BMP files in the last 3/4 of the flash, alignment logs, and possibly mask files.

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 15, 2020, 01:25:20 pm
content: Quote from: abyrvalg on October 15, 2020, 09:58:21 amThe NAND controller does do ECC transparently when reading in "Main area" mode, which is what I used. Main mode does not include the Spare area.From the CycloneV HPS technical reference manual:Code:Main Area Transfer ModeIn main area transfer mode, when ECC is enabled, the NAND flash controller inserts ECC check bits inthe data stream on writes and strips ECC check bits on reads. Software does not need to manage the ECCsectors when writing a page. ECC checking is performed by the flash controller, so software simplytransfers the data.If ECC is turned off, the NAND flash controller does not read or write ECC check bits

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 15, 2020, 03:51:07 pm
content: Looks like 08000000+ area uses some different data/metadata layout, so the reader script strips metadata incorrectly. The dump by tv84 looks like it has some data stripped at wrong positions (16 "metadata" bytes are at +0 in each 16K sector of the first 128K block, but the same looking data is moved by 16 bytes upper in the next block, then by 32 bytes upper, ...).It would be better to turn off that stripping at all, read everything as is, then decide what to strip for each area. Or even use MonDeb "cr" command to read NAND to RAM (so a builtin read function that knows the correct data format will be used), then dump it from there either via JTAG (this can be done in huge portions) or with MonDeb "du" command.

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 15, 2020, 04:31:58 pm
content: Quote from: abyrvalg on October 15, 2020, 03:51:07 pmYeah, I was considering using the Mondeb interface to do just that. I had tried doing DMA transfers via script from flash but could never get them to work.I have a full raw JTAG dump happening now at home via the flash controller. Problem is that long runs of 0xFF seem to cause JTAG timeouts and errors, so getting a good dump is a challenge. If it isn't complete when I get home I'll try using Mondeb to transfer it into RAM so I can read it in larger chunks.

author: tv84
author_rank: Super Contributor
timestamp: October 15, 2020, 04:52:04 pm
content: Agree with both. With a successful raw dump, we should be able to parse in no time.Electro, remember we don't need the 1st 128 MB again. You can restart at 0x08000000.By doing a bitmap with the whole 512MB it's very easy to see those 16-bytes "junk" zones and do a visual integrity check.

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 15, 2020, 05:01:36 pm
content: Quote from: tv84 on October 15, 2020, 04:52:04 pmI just started pulling the entire 512M so I'd have it for disaster recovery. It doesn't matter much anyway, as the first 128M transfers pretty quickly. It is the parts of flash that have a lot of 0xFF's (empty) that cause all kinds of JTAG errors and restarts. The first 128M takes about an hour or two, and the remainder ends up taking about 18hrs or so.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 15, 2020, 11:34:04 pm
content: The command to show those FTL stats should be DIAGNOSTIC:SERVICE:PFSTATUS

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 16, 2020, 12:56:08 am
content: (more or less) complete SCPI command list:

author: tv84
author_rank: Super Contributor
timestamp: October 16, 2020, 01:29:29 pm
content: .FWU parsing (after decryption):Code:00000000 Header Size: 0400 [00000000-000003FF] FileSize OK00000002 Section 1 Size: 0017792C [00000400-00177D2B]00000006 Section 2 Size: 014903A4 [00177D2C-016080CF]0000000A Section 1 CRC16: 2AE2 CRC OK0000000C Section 2 CRC16: 50A4 CRC OK0000000E ????: 0x103300000000001E Model: RTB20040000002E FW Version: 02.2020000003E Release Date: 2018-11-060000004E ????: 6731.193950000005E Compilation: Build 522 built on 2018-11-06 12:37:30 by MaG? [02.202 - HCL: 03.300 - MesOS: 04.300] with GCC 5.3.00000015E (???) Hash Type: 200000198 Build: 522000001AA Section 1 SHA256: 898ADDB2A111DBE0C45BC0EA363D4CD5 HASH OK000001CA Section 2 SHA256: 7208D30AF3FB85125AD5082BC46230FB HASH OK000003FE Header CRC16: 25E7 CRC OK

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 16, 2020, 02:15:07 pm
content: Quote from: tv84 on October 16, 2020, 01:29:29 pmGood info!The 0x10330000 is known as the "Material Number." The 6731.19395 Appears in some strings associated with a date and time, but not sure what it represents.19395 2018-11-06 12:37:306731(6730:6731;2018/11/06 12:28:21)19395(19399;2018/10/24 15:01:02)19383(19399;2018/10/18 10:30:34)19377(19399;2018/10/17 11:30:25)

author: KaneTW
author_rank: Frequent Contributor
timestamp: October 16, 2020, 04:38:32 pm
content: How did you decrypt the FWU? I tried with the AES key posted in this thread, but it failed.

author: tv84
author_rank: Super Contributor
timestamp: October 16, 2020, 04:42:28 pm
content: Quote from: KaneTW on October 16, 2020, 04:38:32 pmIt's AES-256, not AES-128. You have to consider the 32 bytes of the key.

author: KaneTW
author_rank: Frequent Contributor
timestamp: October 16, 2020, 04:50:30 pm
content: Oh. I didn't realize it was 0-padded 256-bit AES. It even worked the last time round, I just didn't notice that it succeeded. Oops.E: welp, didn't work. just didn't fail, but the data's still encrypted. hmm.

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 16, 2020, 05:08:24 pm
content: Make sure you're using AES-256CBC with an IV of 0. Openssl can be used.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 16, 2020, 05:22:27 pm
content: If all you want from decrypted FWU is to get the main part for study - just find the ELF header signature (7F "ELF") and rip from there till end of file, you'll get a correct ELF.

author: KaneTW
author_rank: Frequent Contributor
timestamp: October 16, 2020, 06:48:24 pm
content: Using this:Code:openssl aes-256-cbc -K 43C6B3E57510A3C5547AA4DF9528B783 -iv 0 -in RTB2004.FWU -out RTB2004.FWU.decResulting .dec file is either compressed or encrypted (bytes are uniformly distributed)

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 16, 2020, 07:24:14 pm
content: Quote from: KaneTW on October 16, 2020, 06:48:24 pmYou're missing some things... Not sure what the defaults are, but I'd specify them. It may be encrypting it rather than decrypting it, as I see no -d in your command.Code:openssl enc -aes-256-cbc -nopad -nosalt -d -in <infile> -out <outfile> -K '<key>' -iv '0'Don't forget to pad the key out to the proper length by appending the 0's.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: October 16, 2020, 10:06:05 pm
content: Great! So an update file consists of 3 main things: a loader code that writes update to flash, a splash screen to show during update and an all-in-one ELF to be flashed.

author: KaneTW
author_rank: Frequent Contributor
timestamp: October 16, 2020, 11:45:24 pm
content: Quote from: ElectronMan on October 16, 2020, 07:24:14 pmDuh. That's what I get for not double-checking. The args were what was missing.

author: uski
author_rank: Frequent Contributor
timestamp: October 29, 2020, 10:35:03 am
content: There are these SCPI commands :DIAGNOSTIC:PRODUCT:OPTION:STATUSDIAGNOSTIC:PRODUCT:OPTION:LISTDIAGNOSTIC:PRODUCT:OPTION:ENABLE OFF ONDIAGNOSTIC:PRODUCT:OPTION:FACTORY:CLEARDIAGNOSTIC:PRODUCT:MNUMBER:SETObviously I would not try CLEAR... but STATUS/LIST and ENABLE seem interesting...Regarding reverse engineering, if the ENABLE command asks for a key, it could be possible to statically decompile the code and look at what checks are performed. This could yield to the key algorithm.I don't have an RTB - I am waiting to see where this thread goes before maybe getting one. Someone wants to try these commands ?PS: Oh and MNUMBER can be promising... maybe it allows changing the model number to... a higher bandwidth version ?

author: Hydron
author_rank: Super Contributor
timestamp: October 29, 2020, 11:35:59 am
content: OK so I wouldn't get too worked up about the NUMBER thing, the bandwidth seems to be an option only thing, unlike the old Tek scope BW hack.When sending the LIST? command there isn't much of use in the output other than the actual keys used for activating each option (and the activation date) - could be useful if one lost the original info and cleared the list or something. These match the License keys on the document included in the original packaging (and the K36 bode plot key I was emailed).STATUS doesn't seem to give any output, and no way I'm trying the rest.

author: Harjit
author_rank: Regular Contributor
timestamp: October 31, 2020, 03:31:51 am
content: @uski - curious how you figured out these commands?

author: uski
author_rank: Frequent Contributor
timestamp: October 31, 2020, 03:55:13 am
content: Quote from: Harjit on October 31, 2020, 03:31:51 amSomeone posted a txt file with all the commands earlier.But otherwise... I am pretty sure you can run "strings" on the decrypted firmware image and get the same result (and possibly find other interesting stuff such as some error messages that can be interesting)I didn't have time to play around with the firmware (yet?). Another option is to load it in IDA or a similar disassembler, and then things get even more interesting.

author: uski
author_rank: Frequent Contributor
timestamp: October 31, 2020, 06:11:07 am
content: Some pretty cool content in the firmware...An error message :Code:1GHz Bandwidth extension is not supportedwith present hardware configuration.TXT_ID_LICENCE_OKL_1GHz_BW_UPGRADE_NOT_SUPPORTEDAnd a bunch of license numbers and descriptions, including these :Code:B1 - MSO 16 Logic ChannelsTXT_ID_LICENCE_OKL_DESIG_B1B200 - Bandwidth ext. 500MHzTXT_ID_LICENCE_OKL_DESIG_B200B201 - Bandwidth ext. 350MHzTXT_ID_LICENCE_OKL_DESIG_B201B202 - Bandwidth ext. 500MHzTXT_ID_LICENCE_OKL_DESIG_B202B203 - Bandwidth ext. 1GHzTXT_ID_LICENCE_OKL_DESIG_B203B204 - Bandwidth ext. 1GHzTXT_ID_LICENCE_OKL_DESIG_B204B205 - Bandwidth ext. 1GHzTXT_ID_LICENCE_OKL_DESIG_B205Not saying it will work or it is supported... but these strings are there in the firmware

author: maginnovision
author_rank: Super Contributor
timestamp: October 31, 2020, 02:55:12 pm
content: Probably just some common stuff between the 2000, 3000 and 4000 series scopes.

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 31, 2020, 03:45:58 pm
content: Quote from: uski on October 31, 2020, 06:11:07 amThat's just the LUT (look-up-table) for English names for those licenses. RTM and RTA licenses are included in that database.

author: ElectronMan
author_rank: Regular Contributor
timestamp: October 31, 2020, 10:16:37 pm
content: Quote from: uski on October 29, 2020, 10:35:03 amThis is an interesting SCPI command on the RTB2004:Code:JOSHUA?"Have Fun"I haven't been able to tell what it does, but if someone knows a SCPI command that fails due to permissions and can try it after that, it could be helpful.

author: uski
author_rank: Frequent Contributor
timestamp: November 01, 2020, 01:14:12 am
content: Quote from: ElectronMan on October 31, 2020, 03:45:58 pmStop breaking my dreams !1 GHz bandwidth on a 2.5GSPS scope would not be too helpful anyway.Have you found out how the strings from the LUT are referenced in the rest of the firmware ? Having some trouble with Xrefs.Quote from: ElectronMan on October 31, 2020, 10:16:37 pmIf you managed to get Xrefs between the strings and the rest of the code, you can see if any flag in memory is altered from the code handling this command.You can then see the Xrefs to these flags (if any) and see what else it affects

author: YetAnotherTechie
author_rank: Regular Contributor
timestamp: November 01, 2020, 11:10:05 am
content: There are plenty of commands that silently fail, like the ones mentioned earlier to check the file system, trough SCPI they don't work, the ones to check temperature or fan speed don't work either. It would be nice to discover how to enable them, and avoid jtaging in.

author: YetAnotherTechie
author_rank: Regular Contributor
timestamp: November 01, 2020, 07:37:32 pm
content: Quote from: tv84 on November 01, 2020, 11:19:54 amI haven't opened it yet, but i could, there's no warranty left. I'm not sure about what jtag hardware to get that supports 1.8v and doesn't take several months to arrive. After some research, i think a usb blaster would be ideal? I might have one packed in a box somewhere...

author: YetAnotherTechie
author_rank: Regular Contributor
timestamp: November 01, 2020, 07:40:59 pm
content: Quote from: PeDre on November 01, 2020, 11:50:17 amInteresting, for sure my RTM didn't reboot or answered to fan or time commands, i'll need to try with the service enable command.

author: YetAnotherTechie
author_rank: Regular Contributor
timestamp: November 02, 2020, 12:40:58 am
content: ElectronMan:Do you know how to issue SET FEATURE (EFh) commands to the nand via jtag?

author: ElectronMan
author_rank: Regular Contributor
timestamp: November 02, 2020, 03:04:23 am
content: Quote from: YetAnotherTechie on November 02, 2020, 12:40:58 amNormally you talk to the controller and not the NAND directly, but there are some pass-through commands. I'd have to look it up. Why?

author: YetAnotherTechie
author_rank: Regular Contributor
timestamp: November 02, 2020, 12:04:02 pm
content: Quote from: ElectronMan on November 02, 2020, 03:04:23 amFrom PeDre list we can see that OTP area is in use. Therefore any backup that doesn't have those thirty full pages (2112 bytes per page) of data is incomplete. Things like model/serial number, board type, permanent licenses or certificates could be stored there and couldn't be restored in case of nand failure.Is there a way to read it using the monitor?In a previous post you mentioned running a raw dump, does this mean talking directly to the nand and including ecc, or the entire chip through the HPS layer?

author: tv84
author_rank: Super Contributor
timestamp: November 02, 2020, 12:55:26 pm
content: Quote from: YetAnotherTechie on November 02, 2020, 12:04:02 pmWhen we mentioned "raw dump", we meant dumping without deleting any byte from the read instruction (look at Electroman original script where he cutted 16 bytes for each page).The goal is read all the NAND and post process after. The NAND controller provides a very clean output with all the ECC taken care of.

author: ElectronMan
author_rank: Regular Contributor
timestamp: November 02, 2020, 03:24:05 pm
content: Quote from: tv84 on November 02, 2020, 12:55:26 pmThe OTPData SCPI command appears to just write data to Block 0, Page 0. It does disable ECC before doing this, but I don't see it writing into the spare area.You can write to a register to tell it the read mode you want (just MAIN area, or MAIN and SPARE) so it would not be difficult to make the script grab that area in a dump as well.EDIT: It is writing 0x840 bytes, which is the full 2112 byte MAIN + SPARE. I'll see if I can get that data out of Block 0, page 0 on my device.

author: YetAnotherTechie
author_rank: Regular Contributor
timestamp: November 02, 2020, 04:53:09 pm
content: Quote from: ElectronMan on November 02, 2020, 03:24:05 pmFrom the datasheet:https://eu.mouser.com/datasheet/2/671/micron_technology_micts06228-1-1759217.pdf"The OTP area is only accessible while in OTP operation mode. To set the device to OTP operation mode, issue the SET FEATURE (EFh)command to feature address 90h and write 01h to P1, followed by three cycles of 00h to P2-P4. For parameters to enter OTP mode, see Features Operations.When the device is in OTP operation mode, all subsequent PAGE READ (00h-30h) and PROGRAM PAGE (80h-10h) commands are applied to the OTP area. The OTP area is assigned to page addresses 02h-1Fh. "So the code would look like reading block 0 page 0, but it's a diferent block than what you read before (bootblock) do you agree?It would also be interesting to get "read id" byte 4 to determine if they are using the internal on-chip ecc or not. it's also possible to use command "get features" to check ECC status and/or if you are reading from otp area or not.

author: tv84
author_rank: Super Contributor
timestamp: November 02, 2020, 04:53:53 pm
content: Quote from: ElectronMan on November 02, 2020, 03:24:05 pmMaybe you have to set the block/page with another command prior to read.

author: ElectronMan
author_rank: Regular Contributor
timestamp: November 02, 2020, 06:26:20 pm
content: Quote from: tv84 on November 02, 2020, 04:53:53 pmIt is using the altera hwlib command. It takes care of that, but the first parameter is the START page/block and is set to 0. Technically it could be writing any number of pages, but it certainly looks like it starts at address 0.

author: uski
author_rank: Frequent Contributor
timestamp: November 07, 2020, 04:57:02 am
content: FYI I tried decrypting the firmware for the RTM3000 series scopes with the same key and it didn't work. Meh.

author: ElectronMan
author_rank: Regular Contributor
timestamp: November 09, 2020, 09:39:32 pm
content: Quote from: uski on November 07, 2020, 04:57:02 amDid you try this one?https://www.eevblog.com/forum/testgear/rs-rtm2000-has-anybody-hacked-this-scope/msg3282494/#msg3282494

author: Harjit
author_rank: Regular Contributor
timestamp: November 25, 2020, 04:14:36 am
content: Wondering if anyone has updates? This was fascinating to follow along.

author: uski
author_rank: Frequent Contributor
timestamp: November 28, 2020, 09:44:42 pm
content: HiQuote from: ElectronMan on September 20, 2020, 07:23:19 pmI am trying to identify the part number for a matching connector for the JTAG connector. Any idea ?Pre-made cables would be even better but that's probably a stretchThanks

author: Kean
author_rank: Unknown
timestamp: November 28, 2020, 10:06:04 pm
content: Quote from: uski on November 28, 2020, 09:44:42 pmLooks like a Molex Picoblade 1.25mm pitch 10 way.https://www.molex.com/product/picoblade.htmlPCB connector is 53398-1071. Receptacle housing is 51021-1000. Contacts are 50079-8000 or -8100.I suggest buying pre-crimped leads as the proper crimp tool is very expensive!They can be bought from Mouser/Digikey/Aliexpress/etc - e.g Digikey 0500798000-12-R8-DOr you can buy a complete pre-made cable assembly and cut it in half to splice to your own JTAG interface - e.g. 150mm long Digikey WM17230-ND Molex PN 0151341002

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 28, 2020, 10:27:31 pm
content: Quote from: Kean on November 28, 2020, 10:06:04 pmAbsolutely - very hard to crimp the contacts without the proper tool.

author: ElectronMan
author_rank: Regular Contributor
timestamp: November 28, 2020, 10:51:52 pm
content: I ended up getting these:https://www.amazon.com/gp/product/B07PWZTC88/ref=ppx_yo_dt_b_asin_title_o07_s01?ie=UTF8&psc=1And then I took the 8 pin, and a 2-pin, and trimmed down the edges so they would fit together. I then pulled the 1-pin connectors off the other end and put them into a block to fit the JTAG pinout of my J-link.It's not ideal, but it worked for me.

author: Kean
author_rank: Unknown
timestamp: November 28, 2020, 11:39:33 pm
content: Quote from: ElectronMan on November 28, 2020, 10:51:52 pmYes, that is a good solution - although you can buy a pack of the 10 pin housings for a few bucks and transplant the crimped ends across to one.

author: Harjit
author_rank: Regular Contributor
timestamp: November 29, 2020, 12:10:33 am
content: Fantastic! You all are really good. I just spent a few minutes looking at JST connectors but didn't find a match.

author: uski
author_rank: Frequent Contributor
timestamp: November 29, 2020, 06:11:28 am
content: I got this :https://www.amazon.com/gp/product/B07XHW1959/Will report if they fit or not when I receive my scope

author: Harjit
author_rank: Regular Contributor
timestamp: January 16, 2021, 05:31:57 am
content: Any updates?

author: trimen
author_rank: Newbie
timestamp: April 13, 2021, 11:10:29 am
content: I was able to dump my scope via JTAG, it took only about 4-5 hours and I didn't encounter any JTAG related errors. (I used XDS100v3)In my unit, there wasn't placed Molex picoblade connector, so I populate it myself.For anyone interested I can provide dumped images for comparison.

author: AnJu
author_rank: Contributor
timestamp: October 16, 2021, 09:32:25 pm
content: Quote from: trimen on April 13, 2021, 11:10:29 amPlease to provide your NAND image.anjugm gmail com

author: sergeyklenov
author_rank: Contributor
timestamp: November 01, 2021, 07:51:48 pm
content: Quote from: ElectronMan on October 15, 2020, 01:17:10 pmYes, really content repeat each 0x2000 after 0x8000000i think mistake in setting page for nand reading.

author: sergeyklenov
author_rank: Contributor
timestamp: November 02, 2021, 05:46:23 am
content: For info: i found in flash MSDOS5.0 FAT16 table. So i think this NAND formatted as usual PC disk.

author: ElectronMan
author_rank: Regular Contributor
timestamp: February 10, 2022, 05:40:24 pm
content: Quote from: sergeyklenov on November 02, 2021, 05:46:23 amThere are references to that in the firmware, but it is specifically for the USB disk emulation when you connect your RTB to your PC via USB. There are also components that allow mounting USB drives. The flash filesystem itself is not DOS compatible.

author: uski
author_rank: Frequent Contributor
timestamp: November 05, 2023, 07:14:19 pm
content: Hi,I have soldered the missing 10-pin connector on my oscilloscope.I had to extremely carefully remove the solder on the connector pads with a bit of flux and desoldering braid.There are 0201 resistors nearby and significant ground heatsinking, so this is not for beginners...Then, I soldered the connector, and made a custom cable with only the relevant pins (less pins = less force to remove = less chance to damage something = better)I used the following:- Pre-crimped cables: DigiKey 0500798000-12-L8-D-ND which I cut in half- SMD connector: DigiKey WM7614CT-ND- Housing: DigiKey WM1728-NDNow, on to JTAGing...

author: skander36
author_rank: Frequent Contributor
timestamp: November 05, 2023, 07:26:05 pm
content: Success!It took me about 5 hours using a JTAG interface (TMS320-XDS100-V3) which is considered high speed and OpenOCD.I'm curious how long it will took you.

author: uski
author_rank: Frequent Contributor
timestamp: November 05, 2023, 09:23:09 pm
content: So because I am so late into the party, I needed to update a few things to get the openocd script to work.First, I had an issue where the syntax of the "target create" command no longer accepts the chain-position parameter, I rather had to create a dap separately.I have followed the guide here:https://visualgdb.com/support/chainposition/The resulting script is:Code:source [find interface/jlink.cfg]reset_config trst_and_srstif { [info exists CHIPNAME] } {set _CHIPNAME $CHIPNAME} else {set _CHIPNAME fpgasoc}if { [info exists DAP_TAPID] } {set _DAP_TAPID $DAP_TAPID} else {set _DAP_TAPID 0x4ba00477}jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x01 -irmask 0x0f -expected-id $_DAP_TAPIDadapter_khz 4000dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpuset _TARGETNAME1 $_CHIPNAME.cpu.0target create $_TARGETNAME1 cortex_a -dap $_CHIPNAME.dap -endian little -coreid 0 -dbgbase 0x80110000initcortex_a dbginitIf anyone is more familiar with OpenOCD than I am, and can check that I did this right, feel free to take a look.I am now downloading the flash using the rtb_nand_dump.pl script (thanks ElectronMan for the fantastic background work in post #1, really couldn't have done it without you).I am using a clone JLink V9 (this is what I had in stock...). It had an internal VTref of 3.3V, and I didn't have an exposed 2.5V on the connector of the scope, so I switched the AMS1117 3.3V LDO that creates that reference inside the probe to a 2.5V one (the scope uses 2.5V signals). I don't seem to have issues reading the data, and I checked the signals with a voltmeter and all is at 2.5V.As to the speed, here is a quick measurement:Code:$ ls -l RTB_NAND_IMAGE.img && sleep 60 && ls -l RTB_NAND_IMAGE.img-rw-rw-r-- 1 x x 16191568 Nov 5 13:20 RTB_NAND_IMAGE.img-rw-rw-r-- 1 x x 17897344 Nov 5 13:21 RTB_NAND_IMAGE.img1705776 bytes per minute. Image is 512MB. 512*1024*1024/1705776=314 minutes, so around 5 hours if all goes well (no interruptions - hopefully my probe is stable)Stay tuned! Image file seems to contain valid data so far. I can see the bootloader that was discussed previously at the beginning of the image, with legible text etc.

author: skander36
author_rank: Frequent Contributor
timestamp: November 05, 2023, 10:12:35 pm
content: As I have different adapter i have used this script (thanks Trimen!) :#source [find interface/jlink.cfg]source [find interface/ftdi/xds100v3.cfg]#source [find target/altera_fpgasoc.cfg]adapter speed 5000transport select jtagreset_config trst_and_srst# Altera cyclone V SoC family, 5Cxxx#if { [info exists CHIPNAME] } {set _CHIPNAME $CHIPNAME} else {set _CHIPNAME fpgasoc}# CoreSight Debug Access Portif { [info exists DAP_TAPID] } {set _DAP_TAPID $DAP_TAPID} else {set _DAP_TAPID 0x4ba00477}jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x01 -irmask 0x0f \-expected-id $_DAP_TAPID# Subsidiary TAP: fpgaif { [info exists FPGA_TAPID] } {set _FPGA_TAPID $FPGA_TAPID} else {set _FPGA_TAPID 0x02d020dd}#jtag newtap $_CHIPNAME.fpga tap -irlen 10 -ircapture 0x01 -irmask 0x3 -expected-id $_FPGA_TAPIDset _TARGETNAME1 $_CHIPNAME.cpu.0#set _TARGETNAME2 $_CHIPNAME.cpu.1# A9 core 0dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cputarget create $_TARGETNAME1 cortex_a -dap $_CHIPNAME.dap \-coreid 0 -dbgbase 0x80110000$_TARGETNAME1 configure -event reset-start { adapter speed 1000 }$_TARGETNAME1 configure -event reset-assert-post "cycv_dbginit $_TARGETNAME1"# A9 core 1#target create $_TARGETNAME2 cortex_a -dap $_CHIPNAME.dap \# -coreid 1 -dbgbase 0x80112000#$_TARGETNAME2 configure -event reset-start { adapter speed 1000 }#$_TARGETNAME2 configure -event reset-assert-post "cycv_dbginit $_TARGETNAME2"proc cycv_dbginit {target} {# General Cortex-A8/A9 debug initialisationcortex_a dbginit}init; ftdi_set_signal PWR_RST 1; jtag arp_initinit#jlink targetpower on#targets#targets $_CHIPNAME.cpu.1#halt#targets $_CHIPNAME.cpu.0#halthalttargets

author: tech255
author_rank: Contributor
timestamp: April 13, 2025, 10:45:56 am
content: ElectronmanWhat jtag interface did you use for this.Nigel