Author Topic: Sniffing the Rigol's internal I2C bus  (Read 1840503 times)

0 Members and 4 Guests are viewing this topic.

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3775 on: December 29, 2014, 08:04:34 pm »
Increasing the lower TG limit from -30dBm to -20dBm is a downgrade in my eyes.
 
The following users thanked this post: mklengel

Offline KD0RC

  • Regular Contributor
  • *
  • Posts: 114
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3776 on: December 29, 2014, 09:02:27 pm »
Chinglish at its best - 'Increase the sanitation function'...  Does this mean an upgrade to the flush handle?

KD0RC:

In a way you are correct, but it means that the next time you click on 'Clr Int Cal' you are going to loose the TG completely, NOT just its Calibration.  BTW did you ever get your TG Calibration back?
Well, I see the X Scale (Log Lin) function when I hit the Span button, and that seems to work.
If I hit the System button and go to page two, I see a new function, 'Sanitation'.  Press it, and you get two options, OK and Cancel.  Anyone have any idea what that does?  (Anyone brave enough to click OK?)
The tracking Generator output now goes from 0 to -20 dBm.  Not sure why they changed this from -30 dBm.

Wall-E - no, I do not have my TG cal back.  I am hoping someone figures out a way to do the cal.  Nothing that I have played with seems to have any effect.  Service mode looks like it works the same - I don't see any new functions that look like they let you do a TG cal manually.
 

Offline mhwlng

  • Contributor
  • Posts: 19
  • Country: nl
Re: Sniffing the Rigol's internal I2C bus
« Reply #3777 on: December 29, 2014, 09:11:22 pm »
Quote
'santitation function' Anyone have any idea what that does? 
According to this manual (july 2014) :
http://www.ame-hft.de/pdf/dsa800_userguide.pdf

Press Sanitation to clear all data set by user and restore them to factory settings.
The user data saved in the NVRAM and NorFlash are restored to factory settings.
HOST NAME, IP address and password in LXI are restored to factory settings.
« Last Edit: December 29, 2014, 09:14:17 pm by mhwlng »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3778 on: December 29, 2014, 09:52:22 pm »
Increasing the lower TG limit from -30dBm to -20dBm is a downgrade in my eyes.

This is kind of like RPN (Reverse Polish Notaion) because I believe they meant to say that the TG Output lower limit was changed from -20dBm to -30dBm.

...except that the default TG setting on the example I have here without the "upgrade" is already -30dBm, so I fear they're heading in the wrong direction. For some high gain low noise preamps, -20dBm will be a very strong signal indeed. Yet more external attenuation I guess!
 

Offline phersus

  • Newbie
  • Posts: 9
Re: Sniffing the Rigol's internal I2C bus
« Reply #3779 on: December 30, 2014, 01:12:27 pm »
Hello Guys,

First of all: Happy New Year ... a little in advance but as many, family will keep me away from the forum for a while so ...  ^-^

I've been trying the memory dump of my MSO1074Z, I'm using an OLIMEX JTAG header (the same model as referenced here by different members), I use MAC OS X and Windows 7 (Enterprise, 32 bits) without success (so far).

Some of you have helped me to do some progress (thank you for that!), however still stuck; I should be doing some stupid thing I think  |O

I wanted to confirm with you, I was wondering if I should turn the oscilloscope ON when trying the dump (?)

My problem seems to come from the USB driver for the OLIMEX header (in both MAC OS X and Windows)
I used the zadig (ver 2.1.1) tool (in the Windows environment, which is a real one not a virtual machine) to install the drivers (tried the three proposed by the tool) and I had the same error message: no device found.

In the MAC is not any better, I installed and locally compiled several tools without any success.

Any suggestion ? I really don't care which OS can make it, I'm using these two basically because is what I have at home, I could even use Linux virtual machines (I have Debian and Fedora already installed and running) but considered that if with the real hardware I'm not getting good results adding and extra layer of complexity wouldn't help at all.

Any advice will be appreciated!

Gus

 
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3780 on: December 30, 2014, 01:45:38 pm »
Yes, the scope should be on and booted. The dump process will freeze the scope though.

FWIW, the dump I had was on a Mac Mini 2012 Server running Windows 8.1 x64 which has its own problems, not least that as I remember I had to switch off enforced driver signing.
 

Offline phersus

  • Newbie
  • Posts: 9
Re: Sniffing the Rigol's internal I2C bus
« Reply #3781 on: December 30, 2014, 02:21:55 pm »
Thank you Howardlong,

I got the same result in Windows and MAC OS X (at least the error is coherent  :P )

This is the error message I'm getting:

phersus@MacBooKs-MBP:~$ openocd -d1 -f ./interface/olimex-arm-usb-ocd-h.cfg -f ./target/imx28.cfg
Open On-Chip Debugger 0.8.0 (2014-12-23-13:24)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html
debug_level: 1
adapter speed: 20000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
dcc downloads are enabled
Error: no device found
Error: unable to open ftdi device with vid 15ba, pid 002b, description 'Olimex OpenOCD JTAG ARM-USB-OCD-H' and serial '*'
in procedure 'init'

Any suggestion on what to try next ?

Gus
 

Offline Wall-E

  • Contributor
  • Posts: 36
  • Country: nl
  • Stijn
Re: Sniffing the Rigol's internal I2C bus
« Reply #3782 on: December 30, 2014, 06:37:59 pm »
Quote
@mhwlng, did the bootloader version change with this upgrade?  Mine is still at 01.03.
bootloader is still 01.03
mhwlng:
Re DSA815 with firmware 00.01.12.00.02:  Can you please show us, or describe what the Full Scan (on initial boot-up, or after pressing the Preset button) looks like with the Scan set to to X = Log (for the Log. Frequency display).  Thank you in advance.
 

Offline mhwlng

  • Contributor
  • Posts: 19
  • Country: nl
Re: Sniffing the Rigol's internal I2C bus
« Reply #3783 on: December 30, 2014, 07:13:17 pm »
mhwlng:
Re DSA815 with firmware 00.01.12.00.02:  Can you please show us, or describe what the Full Scan (on initial boot-up, or after pressing the Preset button) looks like with the Scan set to to X = Log (for the Log. Frequency display).  Thank you in advance.

As requested, see attached :
« Last Edit: December 30, 2014, 07:15:15 pm by mhwlng »
 

Offline Wall-E

  • Contributor
  • Posts: 36
  • Country: nl
  • Stijn
Re: Sniffing the Rigol's internal I2C bus
« Reply #3784 on: December 30, 2014, 07:54:22 pm »
mhwlng:
Re DSA815 with firmware 00.01.12.00.02:  Can you please show us, or describe what the Full Scan (on initial boot-up, or after pressing the Preset button) looks like with the Scan set to to X = Log (for the Log. Frequency display).  Thank you in advance.
As requested, see attached :
Thank you 'mhwlng', we are both seeing the same results.  I thought that this was Ok, and I feel better confirming it.  The Rigol DSA815 also works well down to 9kHz as long as you set the Freq. Span., RBW, etc. for the appropriate Log. Freq. measurements.   Thank you, Wall-E
« Last Edit: December 30, 2014, 11:14:05 pm by Wall-E »
 

Offline pa3bca

  • Regular Contributor
  • *
  • Posts: 135
  • Country: nl
Re: Sniffing the Rigol's internal I2C bus
« Reply #3785 on: December 30, 2014, 08:12:06 pm »
I know I can request the latest DSA815-TG firmware (00.01.12.00.02) from Rigol, but, but...
Is there anyplace I can download this version directly?
I really would like to have that Log x-axis.

« Last Edit: December 30, 2014, 10:29:05 pm by pa3bca »
 

Offline hpux735

  • Contributor
  • Posts: 39
Re: Sniffing the Rigol's internal I2C bus
« Reply #3786 on: December 31, 2014, 02:37:04 am »
Increasing the lower TG limit from -30dBm to -20dBm is a downgrade in my eyes.

This is kind of like RPN (Reverse Polish Notaion) because I believe they meant to say that the TG Output lower limit was changed from -20dBm to -30dBm.

...except that the default TG setting on the example I have here without the "upgrade" is already -30dBm, so I fear they're heading in the wrong direction. For some high gain low noise preamps, -20dBm will be a very strong signal indeed. Yet more external attenuation I guess!

I just checked on mine.  I have 01.08 and my TG only goes down to -20dBm.  What firmware are you running?  The extra 10dB of attenuation would be more valuable to me than a logarithmic x axis (though, I wouldn't turn it down).  Is there any definitive word on TG amplitude in 01.12 and whether all the riglol hacks still work?

Thanks!
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3787 on: December 31, 2014, 02:55:53 am »
It's 1.09.
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: Sniffing the Rigol's internal I2C bus
« Reply #3788 on: December 31, 2014, 11:55:34 pm »
New Firmware for DS1000Z and MSO/DS2000 Here
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline KD0RC

  • Regular Contributor
  • *
  • Posts: 114
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3789 on: January 01, 2015, 08:26:21 pm »

I just checked on mine.  I have 01.08 and my TG only goes down to -20dBm.  What firmware are you running?  The extra 10dB of attenuation would be more valuable to me than a logarithmic x axis (though, I wouldn't turn it down).  Is there any definitive word on TG amplitude in 01.12 and whether all the riglol hacks still work?

Thanks!

TG output now definitely goes from 0 to -20 dBm with firmware version 01.12.00.02 and all hacks stay in place.

Len
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 450
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3790 on: January 01, 2015, 09:07:11 pm »
To those experiencing the "License is unavailable!" message that appears on some MSO/DS2000A series scopes when trying to install bandwidth options (200 or 300MHz), it turns out that a solution to this problem has been known since late June 2014!  Read on...

I encountered the above error a couple of months ago (read here) and searched the forums but didn't find any solution (must have been poor searching on my part...), and so started an investigation into the obvious possibilities of hardware differences, key generator differences, etc. Read here and here.

Yesterday I read this post regarding the same problem which mentions "NS8N" code for the key generation.  As far as I could find, NS8N was discovered way back on June 25 2014 by Purevector

I found a few other references to use of NS8N related to 300 MHz bandwidth unlocking:
June 27 2014 by KK (mentions "patched key generator" but not NS8N)
June 27 2014 by Purevector
July 8 2014 by AintBigAintClever
August 31 2014 by sm5uiu

I applied an NS8N generated key (for the MSO2072A which gave the "License is unavailable!" message for an NS8H generated key, as output by rigup by default), and it worked.  See below for details.

So, there's definitely some mystery surrounding option keys, and why some MSO/DS2072A units need to use different codes for bandwidth, but not other options (memory, decodes, etc).

Edit: Added following details:

You can use the precompiled rigup 0.4 to generate license codes for keys other than the default NS8H, etc. as follows.

Code: [Select]
C:\Users\Me\Desktop\rigup-0.4>rigup scan 32M_MemDump.scpi > keys.txt

C:\Users\Me\Desktop\rigup-0.4>rigup license keys.txt NSEH
rigup license - Version 0.4
ABCEEFG-ABCEEFG-ABCEEFG-ABCEEFG    (NSEH = 0x1C087)

C:\Users\Me\Desktop\rigup-0.4>rigup license keys.txt NS8N
rigup license - Version 0.4
ABCEEFG-ABCEEFG-ABCEEFG-ABCEEFG    (NS8N = 0x1C0C3)
« Last Edit: January 14, 2015, 05:59:11 am by Sparky »
 

Offline TitusPullo

  • Newbie
  • Posts: 6
Re: Sniffing the Rigol's internal I2C bus
« Reply #3791 on: January 02, 2015, 09:11:24 am »
Yes Sparky, I can confirm that. I tried the suggested codes from rigup, but only one (the 100MHz) worked.
By using NS8N instead of NS8H I could activate the 300MHz. From what I gather these codes were "guessed" by trial and error (didn't cybernet write a short routine for that?).
I believe some small detail may be still missing there.
 

Offline whotopia

  • Contributor
  • Posts: 12
  • Country: ch
Re: Sniffing the Rigol's internal I2C bus
« Reply #3792 on: January 04, 2015, 02:42:34 pm »
I have a DS2072A with the latest firmware (with the jitter patch).  I cleared out all the options but due to previous efforts have serial number of DS2A0000000001.   Is there guidance on how to restore this in the FRAM to the correct value? e.g. in case I want to sell the unit? 

DS2A0000000001> *IDN?
RIGOL TECHNOLOGIES,DS2072A,DS2A0000000001,00.03.03.SP1


More details on the scope:

Model: DS2072A
Serial: DS2A0000000001
Software Version: 00.03.03.01.00

FPGA Version:
  SPU: 04.01.04
  WPU: 01.01.03
  CCU: 12.29.00
  MCU: 02.13


I should add that I've tried older howtos on this board via the SNMODFIX program / firmware downgrade.  This works, until I flash to new firmware and then I loose the Serial Number again, the default value as above appears along with the correct model, DS2072A.   One other question I have is that I am choosing Model 16 - ds2072 when I patch the .GEL file.   However, I actually have a DS2072A.  Does anyone know what the model code 0-127 is for my model?    Oh, also, my actual serial number starts with DS2D.........  .

« Last Edit: January 04, 2015, 09:48:40 pm by whotopia »
 

Offline radiogeek97

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3793 on: January 06, 2015, 01:14:31 am »
As I promised in previous pages of this thread.  I finally purchased a dsa815tg  from t-equipment, that being said I am willing to experiment and post in the forum for those that want to work around the locked bootloader issue and some others.  I will post all the hardware information when i recieve the unit later.  if folks want to PM me or post in this thread on things they would like to try, i will do my best to help everybody
thanks again
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #3794 on: January 06, 2015, 11:41:57 am »
after some quiet xmas holidays ....

u-boot preliminary support is done.
linux 3.17 is also booting (tftpboot), but no framebuffer driver (yet) - working on it.

TODO:

fix USB support in kernel/uboot - to support keyboard on the host port
add framebuffer driver to linux
start playing with the hardware, reversing the FPGA interface would be nice to get some samples from the AD
play with DSA815, DG4XXX

DONE:

LCD interface (in part)
Keyboard
LED Front Panel

some IDEAS:
FRAM backup/restore via U-Boot Command
FLASH backup via U-Boot Command
use u-boot to start the rigol LDR instead of their crappy bootloader - then patch it on the fly (e.g. overwrite ECC keys/funcs or model strings etc ..)
reverse engineer the FPGAs and use the board as an open source oscilloscope platform

if somebody wants to test or join development let me know. i will update my wiki the next few days and put u-boot and a linux kernel online (+ patches).
for now i only work with the DS2000 because that allows booting a custom LDR without any hardware mods or even the need to open the device.

Code: [Select]
bfin> bootm
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   bf526-0.0-3.16.0-ADI-2014R1-prec
   Created:      2015-01-05   2:54:11 UTC
   Image Type:   Blackfin Linux Kernel Image (gzip compressed)
   Data Size:    4415220 Bytes = 4.2 MiB
   Load Address: 00001000
   Entry Point:  0028cdc0
   Verifying Checksum ... OK
Linux version 3.16.0-ADI-2014R1-precybernet-00397-g4d88578-dirty (cn@cynlaptop) (gcc version 4.3.5 (ADI-2013R1-RC1) ) #15 Mon Jan 5 03:54:08 CET 2015
register early platform devices
bootconsole [early_shadow0] enabled
Board Memory: 32MB
Kernel Managed Memory: 32MB
Memory map:
  fixedcode = 0x00000400-0x00000490
  text      = 0x00001000-0x001b6b68
  rodata    = 0x001b6b68-0x0024939c
  bss       = 0x0024a000-0x002604e8
  data      = 0x00260500-0x00284000
    stack   = 0x00282000-0x00284000
  init      = 0x00284000-0x00573000
  available = 0x00573000-0x01f00000
  DMA Zone  = 0x01f00000-0x02000000
Hardware Trace active and enabled
Boot Mode: 1
Blackfin support (C) 2004-2010 Analog Devices, Inc.
Compiled for ADSP-BF526 Rev 0.0
Warning: Compiled for Rev 0, but running on Rev 2
Blackfin Linux support by http://blackfin.uclinux.org/
Processor Speed: 400 MHz core clock and 100 MHz System Clock
 boot memmap: 0000000000573000 - 0000000001f00000 (usable)
On node 0 totalpages: 7936
free_area_init_node: node 0, pgdat 00281350, node_mem_map 00575000
  DMA zone: 62 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 7936 pages, LIFO batch:0
NOMPU: setting up cplb tables
Instruction Cache Enabled for CPU0
  External memory: cacheable in instruction cache
Data Cache Enabled for CPU0
  External memory: cacheable (write-back) in data cache
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 7874
Kernel command line: netconsole=6666@10.146.248.28/eth0,6666@10.146.248.20/0:30:48:db:6:6 mem=32M
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Kernel managed physical pages: 7936
Memory: 25836K/31744K available (1750K kernel code, 142K rwdata, 586K rodata, 3004K init, 89K bss, 5908K reserved, 1024K DMA)
NR_IRQS:159
Configuring Blackfin Priority Driven Interrupts
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [early_shadow0] disabled
Calibrating delay loop... 792.57 BogoMIPS (lpj=1585152)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
devtmpfs: initialized
Blackfin Scratchpad data SRAM: 4 KB
Blackfin L1 Data A SRAM: 16 KB (16 KB free)
Blackfin L1 Data B SRAM: 16 KB (16 KB free)
Blackfin L1 Instruction SRAM: 48 KB (42 KB free)
NET: Registered protocol family 16
Blackfin DMA Controller
ezbrd_init(): registering device resources
SCSI subsystem initialized
bfin-spi bfin-spi.0: master is unqueued, this is deprecated
bfin-spi bfin-spi.0: Blackfin on-chip SPI Controller Driver, Version 1.0, regs@ffc00500, dma channel@7
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c-bfin-twi i2c-bfin-twi.0: Blackfin on-chip I2C TWI Contoller, regs_base@ffc01400
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
debug-mmrs: setting up Blackfin MMR debugfs
msgmni has been set to 50
io scheduler noop registered (default)
bfin-uart: Blackfin serial driver
bfin-uart.1: ttyBF1 at MMIO 0xffc02000 (irq = 31, base_baud = 6250000) is a BFIN-UART
bfin-otp: initialized
brd: module loaded
physmap platform flash device: 00400000 at 20000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002101
NOR chip too large to fit in mapping. Attempting to cope...
Support for command set 0002 not present
gen_probe: No supported Vendor Command Set found
Creating 3 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000040000 : "bootloader(nor)"
0x000000040000-0x000000200000 : "linux kernel(nor)"
0x000000200000-0x000000400000 : "file system(nor)"
m25p80 spi0.1: unrecognized JEDEC id ffffff
libphy: bfin_mii_bus: probed
bfin_mac: attached PHY driver [Generic PHY] (mii_bus:phy_addr=bfin_mii_bus-0:00, irq=-1, mdc_clk=2500000Hz(mdc_div=19)@sclk=100MHz)
bfin_mac bfin_mac.0 eth0: Blackfin on-chip Ethernet MAC driver, Version 1.1
usbcore: registered new interface driver usb-storage
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
rtc (null): invalid alarm value: 1900-1-14 0:0:0
rtc-bfin rtc-bfin: rtc core: registered rtc-bfin as rtc0
bfin_wdt: initialized: timeout=20 sec (nowayout=0)
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
NET: Registered protocol family 17
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
rtc-bfin rtc-bfin: setting system clock to 1989-09-14 07:46:22 UTC (621762382)
Freeing unused kernel memory: 3004K (00284000 - 00573000)
dma_alloc_init: dma_page @ 0x008ea000 - 256 pages at 0x01f00000
bfin_mac bfin_mac.0 eth0: Link is Up - 100Mbps/Full - flow control off
random: nonblocking pool is initialized
buildroot login: root

                           _______________________________________
        a8888b.           / Welcome to the buildroot distribution \
       d888888b.         /       _     _                           \
       8P"YP"Y88        /       | |   |_|            __  __ (TM)   |
       8|o||o|88  _____/        | |    _ ____  _   _ \ \/ /        |
       8'    .88       \        | |   | |  _ \| | | | \  /         |
       8`._.' Y8.       \       | |__ | | | | | |_| | /  \         |
      d/      `8b.       \      \____||_|_| |_|\____|/_/\_\        |
     dP   .    Y8b.       \   For embedded processors including    |
    d8:'  "  `::88b        \    the Analog Devices Blackfin        /
   d8"         'Y88b        \_____________________________________/
  :8P    '      :888
   8a.   :     _a88P         For further information, check out:
 ._/"Yaa_:   .| 88P|            - http://blackfin.uclinux.org/
 \    YP"    `| 8P  `.          - http://docs.blackfin.uclinux.org/
 /     \.___.d|    .'           - http://www.uclinux.org/
 `--..__)8888P`._.'  jgs/a:f    - http://buildroot.org/

Have a lot of fun...


BusyBox v1.22.1 (2015-01-05 01:17:41 CET) hush - the humble shell

root:~> cat /proc/cpuinfo
processor       : 0
vendor_id       : Analog Devices
cpu family      : 0x27e4
model name      : ADSP-BF526 400(MHz CCLK) 100(MHz SCLK) (mpu off)
stepping        : 2 (Compiled for Rev 0)
cpu MHz         : 400.000000/100.000000
bogomips        : 792.57
Calibration     : 396288000 loops
cache size      : 16 KB(L1 icache) 32 KB(L1 dcache) 0 KB(L2 cache)
dbank-A/B       : cache/cache
external memory : cacheable in instruction cache
external memory : cacheable (write-back) in data cache
icache setup    : 4 Sub-banks/4 Ways, 32 Lines/Way
dcache setup    : 2 Super-banks/4 Sub-banks/2 Ways, 64 Lines/Way

board name      : ADI BF526-EZBRD
board memory    : 32768 kB (0x00000000 -> 0x02000000)
kernel memory   : 31740 kB (0x00001000 -> 0x01f00000)
root:~> free
             total         used         free       shared      buffers
Mem:         28840        18284        10556            0            0
-/+ buffers:              18284        10556
root:~> ps
  PID USER       VSZ STAT COMMAND
    1 root       592 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW<  [kworker/0:0H]
    6 root         0 SW   [kworker/u2:0]
    7 root         0 SW<  [khelper]
    8 root         0 SW   [kdevtmpfs]
   59 root         0 SW   [khungtaskd]
   60 root         0 SW<  [writeback]
   61 root         0 SW<  [bioset]
   62 root         0 SW<  [kblockd]
   64 root         0 SW<  [bfin-spi.0]
   66 root         0 SW   [kworker/u2:2]
   97 root         0 SW   [khubd]
  201 root         0 SW   [kworker/0:1]
  210 root         0 SW   [kswapd0]
  211 root         0 SW   [fsnotify_mark]
  325 root         0 SW<  [deferwq]
  359 root       596 R    {busybox} /sbin/telnetd -p 23
  365 root       592 S    /sbin/inetd -f
  366 root       588 S    /sbin/watchdog -F -T 20 -t 10 /dev/watchdog
  367 root       600 S    -/bin/sh
  368 root       592 S    /sbin/syslogd -n -m 0
  369 root       588 S    /sbin/klogd -n
  370 root       624 S    -sh
  377 root       592 R    ps


___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Sniffing the Rigol's internal I2C bus
« Reply #3795 on: January 06, 2015, 07:40:47 pm »
Hey, nicely done! :-+

Only have a DS1000Z, so can't test the blackfin goodness there. But regarding the DSA815, do you think Rigol uses a similar bootloader for DS2000 and DSA815? I'd be up for some linux experimentation on the DSA815. Any particular links + hints as a starting point?
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #3796 on: January 06, 2015, 10:33:21 pm »
currently im only focusing on the DS because i have fully reversed the bootloader there and it has support for loading a LDR and executing it out of the box (thanks rigol ;-)
for the DSA i never saw the bootloader afaicr - for the DG it was similar at least.
but its pretty simple to get your hands on it when u have JTAG access

just put the device in bootldr fw upgrade mode (HELP button) and let it sit there then attach with gdb and have
a look around:

 Sector Start Addresses:
  20000000   RO   20020000   RO   20040000   RO   20060000   RO   20080000   RO
  200A0000   RO   200C0000        200E0000        20100000        20120000     

0x20000000 is where external memory starts on the blackfin, and on the DS2000 thats where the flash is mapped too.
there is one caveat and that is rigol seems to switch some flash address lines with the fpga (or some other latching device) so its all shadowed.

the mapping on the DS is

0x20340000.w - set by ASYNC3_SelectBank (16bit write + SSYNC !!)
0x0000 - boot LDR
0x0100 - app LDR (oscilloscope software)
0x0200 - boot LDR images (ultravision and rigol logo)
0x0600 - fpga ?

there is probably more to it, but setting 0x20340000.w = 0x0 will let u read out the LDR stream of the Boot LDR.
id definitely be interested if somebody has the time to fetch a DG and DSA bootloader with this method.
the size of the DS LDR is exactly 0x40000 or 256kbytes - LDRs are easily spotted because they have a distinct header
check: http://www.analog.com/static/imported-files/application_notes/EE-240_Rev4.pdf
and: http://www.dolomitics.com/downloads/ldrviewer.html to test extracted data
i also have a custom tool that i will release shortly.






___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline benscammell

  • Newbie
  • Posts: 1
Re: Sniffing the Rigol's internal I2C bus
« Reply #3797 on: January 07, 2015, 03:32:34 pm »
I have just taken delivery of a MSO2102A-S.

Can I unlock all the options? If so, how?

THanks, Ben
 

Offline Jonson.poisk

  • Newbie
  • Posts: 6
Re: Sniffing the Rigol's internal I2C bus
« Reply #3798 on: January 10, 2015, 07:57:46 am »
Hello!
I purchased a new DSA815-TG, but he base the latest firmware, read thread, I understand that there is no solution to the licenses for these models?
Also a question about a 10Hz RBW, this option is not even officially on sale, and it is needed. These analyzers are doomed? Only sell and change to the old model? Are there any solutions?  |O :palm:
thanks in advance
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: Sniffing the Rigol's internal I2C bus
« Reply #3799 on: January 10, 2015, 12:04:14 pm »
Hello!
I purchased a new DSA815-TG, but he base the latest firmware, read thread, I understand that there is no solution to the licenses for these models?
Also a question about a 10Hz RBW, this option is not even officially on sale, and it is needed. These analyzers are doomed? Only sell and change to the old model? Are there any solutions?  |O :palm:
thanks in advance

See ->  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg583763/#msg583763
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf