Author Topic: Hacking the Rigol MSO5000 series oscilloscopes  (Read 310524 times)

bmx and 4 Guests are viewing this topic.

Offline oliv3r

  • Regular Contributor
  • *
  • Posts: 116
  • Country: nl
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #525 on: January 02, 2019, 06:33:41 pm »
We should start a new thread for those numerous bugs.

So we did.  Here you go.  Bugs away!

https://www.eevblog.com/forum/testgear/rigol-5000-bugs/
awesome great idea; we can talk about hacking here then :)
 

Offline Martin72

  • Super Contributor
  • ***
  • Posts: 1461
  • Country: de
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #526 on: January 02, 2019, 06:48:48 pm »
"Offtopic", last time...we should use the existing threads for it indeed...

And now, average(64) + fine + aliasing does something : a very fine trace (1px). To All: Do run a self cal.

Instead of using averaging, you could decrease the memory depth to make the trace thinner.
See also Daves video

Quote
That is no difference between x10 and x1. No matter how you adjust the probe, the little overshoot won't disappear.

Although I don´t have the issue with my 5074, it sounds like a mismatch problem - we bought a couple of probes cause the originals were mostly "vanished"...
On some scopes there was no problem to adjust them.
Other scopes showed exactly your problem - we couldn´t compensate the overshoots completely, it´s a matter oft the Input capacity.
Only with their original probes everything was fine.
Either the input capacity on your rigol was different (tolerance) or the probes are defective.


Offline Commodore8888

  • Contributor
  • Posts: 30
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #527 on: January 02, 2019, 09:32:18 pm »

Quote
That is no difference between x10 and x1. No matter how you adjust the probe, the little overshoot won't disappear.

Although I don´t have the issue with my 5074, it sounds like a mismatch problem - we bought a couple of probes cause the originals were mostly "vanished"...
On some scopes there was no problem to adjust them.
Other scopes showed exactly your problem - we couldn´t compensate the overshoots completely, it´s a matter oft the Input capacity.
Only with their original probes everything was fine.
Either the input capacity on your rigol was different (tolerance) or the probes are defective.

A little to my dismay, I found the same result on the MSO7k we have at work. Tried different probes with slightly different loading, square waves from a few different sources. Same exact overshoot in every case at 1kHz, which seemed a bit odd :/
I'll try the other 7k in the office that came in from the same batch tomorrow as well.
Mike D
 

Offline Martin72

  • Super Contributor
  • ***
  • Posts: 1461
  • Country: de
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #528 on: January 02, 2019, 09:36:15 pm »
Quote
Same exact overshoot in every case at 1kHz

Oh.... :(

Only at 1Khz ?

Online Fungus

  • Super Contributor
  • ***
  • Posts: 11203
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #529 on: January 03, 2019, 05:47:38 am »
We should start a new thread for those numerous bugs.

So we did.  Here you go.  Bugs away!

https://www.eevblog.com/forum/testgear/rigol-5000-bugs/

Is there really any point at this stage? It will be 100% noise until there's been a firmware update or two,
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19924
  • Country: nl
    • NCT Developments
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #530 on: January 03, 2019, 07:50:00 am »

Quote
That is no difference between x10 and x1. No matter how you adjust the probe, the little overshoot won't disappear.

Although I don´t have the issue with my 5074, it sounds like a mismatch problem - we bought a couple of probes cause the originals were mostly "vanished"...
On some scopes there was no problem to adjust them.
Other scopes showed exactly your problem - we couldn´t compensate the overshoots completely, it´s a matter oft the Input capacity.
Only with their original probes everything was fine.
Either the input capacity on your rigol was different (tolerance) or the probes are defective.
A little to my dismay, I found the same result on the MSO7k we have at work. Tried different probes with slightly different loading, square waves from a few different sources. Same exact overshoot in every case at 1kHz, which seemed a bit odd :/
I'll try the other 7k in the office that came in from the same batch tomorrow as well.
The overshoot is likely due to a factory adjustment of the input circuit. Is there some way to run a self-calibration or adjustment procedure? I don't recall whether there is a trim capacitor in the input circuit or not.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline knotapun

  • Newbie
  • Posts: 1
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #531 on: January 03, 2019, 02:56:23 pm »
I'm curious, it's been mentioned that the serial number and keys are stored in a location that is not overwritten when the firmware is updated, doesn't that mean that you can just copy a real licence over as long as you copy the serial number along with it?

After reading the whole thread of comments, I'm under the impression that it's entirely possible to do so.
 

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2831
  • Country: nz
  • D Size Cell
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #532 on: January 03, 2019, 09:17:04 pm »
From what i understand the license file is encrypted.    It is highly probable that it requires the key that is hardware coded into the Zync.  Copying another licence file, wont' help you in this case.
On a quest to find increasingly complicated ways to blink things
 

Offline Commodore8888

  • Contributor
  • Posts: 30
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #533 on: January 03, 2019, 11:18:04 pm »

The overshoot is likely due to a factory adjustment of the input circuit. Is there some way to run a self-calibration or adjustment procedure? I don't recall whether there is a trim capacitor in the input circuit or not.

Tried it at a few other Hz today, ran the self cal as well. Still present. Solid 500mV over/undershoot on a 10v square. Looked about a 25uS RC constant around 63% of the way down from the spike. First time I saw it I thought it was the sig gen, but realized this was at 200uS/div....

No go on checking the other 7k. Was being used to debug some SPI to TFT screen stuff (which it does rather well).
Mike D
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 1814
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #534 on: January 04, 2019, 10:11:31 am »
Gentlemen,

Is it so difficult to take all this OT to another thread?   >:(
 
The following users thanked this post: nctnico, dren.dk, Sparky, TopLoser, mrpackethead, 2N3055

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2831
  • Country: nz
  • D Size Cell
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #535 on: January 04, 2019, 02:57:16 pm »
Gentlemen,

Is it so difficult to take all this OT to another thread?   >:(

Like

https://www.eevblog.com/forum/testgear/rigol-5000-bugs
On a quest to find increasingly complicated ways to blink things
 
The following users thanked this post: dren.dk

Offline sparkv

  • Newbie
  • Posts: 4
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #536 on: January 04, 2019, 11:42:11 pm »
So the image can boot on Xilinx QEMU it seems, and gets pretty far. I expected it to kernel panic early on, but it doesn't. I haven't gotten it to a point where it starts the appEntry, but it gets to a point where it's trying to mount UBIFS partitions and fails because I haven't provided the emulator with NAND image/options. Won't have my scope for another 2-3 weeks probably according to TE, but if it's possible to get some of it running on QEMU to "debug" and test, I'll take it  :-DD

Another problem is probably lack of certain devices (it just complains but proceeds with boot). I'm using BSP provided by Xilinx and not creating custom hardware definition. I might do that tonight/over the weekend just to speed up the boot.

If it can boot on QEMU and run appEntry that will make RE a whole lot easier, at least until I get the real hardware. But even then, having no fear or bricking/destroying instrument while testing stuff will make some things easier. I'll share steps once I have things working in a stable manner.

Code: [Select]
qemu-system-aarch64: -serial mon:pty: char device redirected to /dev/pts/19 (label serial0-base)
qemu-system-aarch64: -serial mon:pty: char device redirected to /dev/pts/20 (label serial2-base)
qemu-system-aarch64: warning: nic ethernet@e000c000 has no peer
rom: requested regions overlap (rom bootloader. free=0x000000000000ed70, addr=0x0000000000000000)


U-Boot 2018.01 (Jan 04 2019 - 11:47:57 -0800) Xilinx Zynq ZC702

Model: Zynq ZC702 Development Board
Board: Xilinx Zynq
Silicon: v0.0
I2C:   ready
DRAM:  ECC disabled 1 GiB
MMC:   Card did not respond to voltage select!
mmc_init: -95, time 12
sdhci@e0100000 - probe failed: -95
Card did not respond to voltage select!
mmc_init: -95, time 11

SF: Detected n25q512 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
*** Warning - bad CRC, using default environment

In:    serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Model: Zynq ZC702 Development Board
Board: Xilinx Zynq
Silicon: v0.0
Net:   ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id
eth0: ethernet@e000b000
U-BOOT for xilinx-zc702-2018_2

BOOTP broadcast 1
DHCP client bound to address 192.168.76.9 (2 ms)
Hit any key to stop autoboot:  0
Zynq> tftpboot 0x03000000 image.ub
Using ethernet@e000b000 device
TFTP from server 10.5.3.218; our IP address is 192.168.76.9; sending through gateway 192.168.76.2
Filename 'image.ub'.
Load address: 0x3000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
###########
15 MiB/s
done
Bytes transferred = 33554432 (2000000 hex)
Zynq> printenv baudrate
baudrate=115200
Zynq> bootm
## Loading kernel from FIT Image at 03000000 ...
   Using 'rootfs@1' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel@1' kernel subimage
     Description:  Kerstrel Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x030000f8
     Data Size:    3302448 Bytes = 3.1 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00100000
     Entry Point:  0x00100000
     Hash algo:    sha1
     Hash value:   bece162e8cad943c68714d8eb8020d68e1db896b
   Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 03000000 ...
   Using 'rootfs@1' configuration
   Trying 'ramdisk@1' ramdisk subimage
     Description:  kerstrel-Update-Ramdisk
     Type:         RAMDisk Image
     Compression:  gzip compressed
     Data Start:   0x03328c5c
     Data Size:    10901113 Bytes = 10.4 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha1
     Hash value:   55bdcbebccba845da403130143793ee0135e53a1
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 03000000 ...
   Using 'rootfs@1' configuration
   Trying 'fdt@1' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x0332661c
     Data Size:    9597 Bytes = 9.4 KiB
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   da2d17ba0d5a71b5897deec4cb026014f3132185
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x332661c
   Loading Kernel Image ... OK
   Loading Ramdisk to 0759a000, end 07fff679 ... OK
   Loading Device Tree to 07594000, end 0759957c ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.12.0-xilinx (rigolee@Jim) (gcc version 4.8.1 (Sourcery CodeBench                                                       Lite 2013.11-53) ) #43 SMP PREEMPT Sat Jul 28 12:14:01 CST 2018
CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @c0e74000 s8384 r8192 d16192 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260624
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1022228K/1048576K available (4197K kernel code, 255K rwdata, 1716K rodat                                                      a, 176K init, 179K bss, 26348K reserved, 270336K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc05ce880   (5915 kB)
      .init : 0xc05cf000 - 0xc05fb0c0   ( 177 kB)
      .data : 0xc05fc000 - 0xc063bd78   ( 256 kB)
       .bss : 0xc063bd84 - 0xc06689a4   ( 180 kB)
Preemptible hierarchical RCU implementation.
        Dump stacks of tasks blocking RCU-preempt GP.
        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
NR_IRQS:16 nr_irqs:16 16
ps7-slcr mapped to f0004000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1454.89 BogoMIPS (lpj=7274496)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0xc03fa6b8 - 0xc03fa710
L2x0 series cache controller enabled
l2x0: 8 ways, CACHE_ID 0x00000000, AUX_CTRL 0x00000000, Cache size: 512 kB
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xf0050000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xf0050000
hw-breakpoint: debug architecture 0x4 unsupported.
zynq_ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xf0080000
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@l                                                      inux.it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 10644K (c759a000 - c7fff000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 1 counters available
Boot process: fb dev not inited, boot process not start!
bounce pool size: 64 pages
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 1489
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
bg request_mem_region failed!
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:301 __arm_ioremap_pfn_caller+0xf                                                      c/0x17c()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-xilinx #43
[<c0015074>] (unwind_backtrace+0x0/0x11c) from [<c0011568>] (show_stack+0x10/0x1                                                      4)
[<c0011568>] (show_stack+0x10/0x14) from [<c03f5c08>] (dump_stack+0x8c/0xd4)
[<c03f5c08>] (dump_stack+0x8c/0xd4) from [<c00218a4>] (warn_slowpath_common+0x60                                                      /0x84)
[<c00218a4>] (warn_slowpath_common+0x60/0x84) from [<c0021958>] (warn_slowpath_n                                                      ull+0x18/0x20)
[<c0021958>] (warn_slowpath_null+0x18/0x20) from [<c001a484>] (__arm_ioremap_pfn                                                      _caller+0xfc/0x17c)
[<c001a484>] (__arm_ioremap_pfn_caller+0xfc/0x17c) from [<c001a550>] (__arm_iore                                                      map_caller+0x4c/0x54)
[<c001a550>] (__arm_ioremap_caller+0x4c/0x54) from [<c001a25c>] (__arm_ioremap+0                                                      x14/0x1c)
[<c001a25c>] (__arm_ioremap+0x14/0x1c) from [<c02321b0>] (xilinxfb_of_probe+0x74                                                      /0x3d8)
[<c02321b0>] (xilinxfb_of_probe+0x74/0x3d8) from [<c02684a0>] (platform_drv_prob                                                      e+0x14/0x18)
[<c02684a0>] (platform_drv_probe+0x14/0x18) from [<c0267208>] (driver_probe_devi                                                      ce+0x11c/0x324)
[<c0267208>] (driver_probe_device+0x11c/0x324) from [<c02674bc>] (__driver_attac                                                      h+0x68/0x8c)
[<c02674bc>] (__driver_attach+0x68/0x8c) from [<c02656a8>] (bus_for_each_dev+0x7                                                      0/0x84)
[<c02656a8>] (bus_for_each_dev+0x70/0x84) from [<c02667f0>] (bus_add_driver+0xfc                                                      /0x268)
[<c02667f0>] (bus_add_driver+0xfc/0x268) from [<c0267ab8>] (driver_register+0x9c                                                      /0xe0)
[<c0267ab8>] (driver_register+0x9c/0xe0) from [<c00087ac>] (do_one_initcall+0xb8                                                      /0x15c)
[<c00087ac>] (do_one_initcall+0xb8/0x15c) from [<c05cfb9c>] (kernel_init_freeabl                                                      e+0x108/0x1cc)
[<c05cfb9c>] (kernel_init_freeable+0x108/0x1cc) from [<c03f1e50>] (kernel_init+0                                                      x8/0xe4)
[<c03f1e50>] (kernel_init+0x8/0xe4) from [<c000e5b8>] (ret_from_fork+0x14/0x3c)
---[ end trace ca10809752213256 ]---
DPU:Map vRam to 0x0
DPU:Map iReg to 0xf0200000
DPU:Ver=0x0
Could not allocate frame buffer memory
devDPU: probe of 40000000.ps7-fb failed with error -12
dma-pl330 f8003000.ps7-dma: unable to set the seg size
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 f8003000.ps7-dma:     DBUFF-256x8bytes Num_Chans-8 Num_Peri-4 Num_Even                                                      ts-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 992063) is a x                                                      uartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 992063) is a x                                                      uartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xF005A000, irq=58
libphy: XEMACPS mii bus: probed
xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0000/0x0000
ULPI integrity check: failed!
xusbps-dr e0002000.ps7-usb: Unable to init USB phy, missing?
ULPI transceiver vendor/product ID 0x0000/0x0000
ULPI integrity check: failed!
xusbps-dr e0003000.ps7-usb: Unable to init USB phy, missing?
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Unable to write register #23
i2c i2c-0: probing for rx8010 failed
rtc-rx8010sj: probe of 0-0032 failed with error -110
Retry another address of GTP
input: Goodix-TS as /devices/virtual/input/input0
xi2cps e0004000.ps7-i2c: 90 kHz mmio e0004000 irq 57
zynq-edac f8006000.ps7-ddrc: ecc not enabled
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
NAND device: Manufacturer ID: 0x20, Chip ID: 0xaa (ST Micro NAND 256MiB 1,8V 8-bit), 256MiB, page size: 2048, OOB size: 64
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
Bad block table not found for chip 0
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
pl353_nand_calculate_hwecc status failed
Bad block table not found for chip 0
Scanning device for bad blocks
pl353_nand_calculate_hwecc status failed
Bad block table written to 0x00000ffe0000, version 0x01
pl353_nand_calculate_hwecc status failed
Bad block table written to 0x00000ffc0000, version 0x01
13 ofpart partitions found on MTD device pl353-nand
Creating 13 MTD partitions on "pl353-nand":
0x000000000000-0x000000040000 : "Env"
0x000000100000-0x000004100000 : "DATA"
0x000004100000-0x000004500000 : "Bmp"
0x000004500000-0x000004900000 : "Bmp1"
0x000004900000-0x000005100000 : "Bit1"
0x000005100000-0x000007100000 : "Sys1"
0x000007100000-0x00000d500000 : "App1"
0x00000d500000-0x00000d900000 : "Bmp2"
0x00000d900000-0x00000e100000 : "Bit2"
0x00000e100000-0x000010100000 : "Sys2"
mtd: partition "Sys2" extends beyond the end of device "pl353-nand" -- size truncated to 0x1f00000
0x000010100000-0x000016500000 : "App2"
mtd: partition "App2" is out of reach -- disabled
0x000016500000-0x00001a800000 : "Reserved"
mtd: partition "Reserved" is out of reach -- disabled
0x00001a800000-0x000040000000 : "User"
mtd: partition "User" is out of reach -- disabled
TCP: cubic registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 176K (c05cf000 - c05fb000)
Starting rcS...
++ Mounting filesystem
++ Setting up mdev
++ Starting ftp daemon
rcS Complete
pl353_nand_calculate_hwecc status failed

<snip>

Segmentation fault
mount: mounting /dev/ubi6_0 on /rigol failed: Invalid argument
**********Mount App partition failed.Check Nandflash********



 
The following users thanked this post: mrpackethead, luma

Offline wulfman

  • Contributor
  • Posts: 22
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #537 on: January 05, 2019, 03:08:19 pm »
Scope arrived yesterday.  :)  old version of firmware installed but calibrated at the end of December. Seems that everything works as expected.
 

Offline Swap_File

  • Contributor
  • Posts: 6
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #538 on: January 05, 2019, 05:28:16 pm »
Scope arrived yesterday.  :)  old version of firmware installed but calibrated at the end of December. Seems that everything works as expected.

Same here, arrived from tequipment yesterday, currently on 1.1.2.3.  For now I'm keeping the scope on an isolated network, I let it warm up, ran a self cal, looked at some signals, and now am starting to poke around in it. 
 

Offline dren.dk

  • Regular Contributor
  • *
  • Posts: 53
  • Country: dk
  • Software developer, dabbling in electronics
    • Dren.dk
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #539 on: January 05, 2019, 07:03:40 pm »
Does anybody know where the scope stores configuration settings?

I've tried altering stuff like the email configuration and then looked for modified files using: find / -type f -mmin -1 but I did not find any files with interesting content, so it seems there's no simple config file that stores the settings.
 

Offline skip

  • Contributor
  • Posts: 5
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #540 on: January 06, 2019, 12:44:26 am »
Scope arrived yesterday.  :)  old version of firmware installed but calibrated at the end of December. Seems that everything works as expected.

Likewise here. 

Neither the probe calibration signal nor a 1 Khz signal from the function generator (after "hacking" it of course) result in a stable waveform, there's lots of jitter!  This is a bit worrisome, is that expected?

I've been sniffing my scope on an isolated network for 3 hours now and so far the only network traffic was the initial DHCP address assignment.  If it's phoning home it's not doing it very aggressively.

Skip

 

Offline Swap_File

  • Contributor
  • Posts: 6
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #541 on: January 06, 2019, 01:28:42 am »
Seems to be working OK for me, but maybe I haven't tried anything advanced enough yet?  Right now I'm mostly waiting a day for the trial clock to run down.
« Last Edit: January 06, 2019, 01:39:31 am by Swap_File »
 

Offline FireBird

  • Regular Contributor
  • *
  • Posts: 58
  • Country: at
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #542 on: January 06, 2019, 07:32:30 pm »
When I tried to get http://www.rigol.com/Support/ProductUpgradePackage?sn=MS5xxxxxxxxxx from my browser I got a "Something went wrong."
I've tried it with 3 different serial numbers and it always starts to download the firmware GEL.
 

Offline skip

  • Contributor
  • Posts: 5
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #543 on: January 06, 2019, 07:50:02 pm »
When I tried to get http://www.rigol.com/Support/ProductUpgradePackage?sn=MS5xxxxxxxxxx from my browser I got a "Something went wrong."
I've tried it with 3 different serial numbers and it always starts to download the firmware GEL.

That's interesting.  I guess I spoofed myself!  I cleared my DNS cache and then I was able to download it once.  Trying again with a bogus SN failed and then I went back to my real SN and it failed again.  I tried clearing my DNS cached again and it didn't help.  Weird.

Did you try a bogus serial number?

Skip
 

Offline skip

  • Contributor
  • Posts: 5
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #544 on: January 06, 2019, 07:54:06 pm »
On topic first:

I've set up a DNS spoofer and captured what happens when I try to do an "online upgrade".  After an DNS lookup of www.rigol.com the scope does a regular http (not https) get of "/Support/ProductUpgradeFile?sn=MS5xxxxxxxxxx&hardware=1.0&behaviour=soft&software=00.01.01.02.03 HTTP/1.1". 

This returns an xml file that looks like this:
<?xml version="1.0" encoding="utf-8"?>
<meta>
  <firmware>
    <series>MSO5000</series>
    <version>00.01.01.02.03</version>
    <url>http://www.rigol.com/Support/ProductUpgradePackage?sn=MS5xxxxxxxxxx</url>
    <comment_cn>2.3????</comment_cn>
    <comment_en>2.3formalverison</comment_en>
    <filesize>66.78MB</filesize>
  </firmware>
</meta>

When I tried to get http://www.rigol.com/Support/ProductUpgradePackage?sn=MS5xxxxxxxxxx from my browser I got a "Something went wrong.
The page you requested does not exist, or the page has an error" error in Chinese.

Now offtopic:

The jitter is most apparent when you set the memory depth to 1k, you can just see it at 10k and it goes away at longer memory settings.  A screen shot is attached... (or inline??  How do you insert inline if this doesn't work??)

Skip
 

Offline FireBird

  • Regular Contributor
  • *
  • Posts: 58
  • Country: at
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #545 on: January 06, 2019, 08:01:21 pm »
Did you try a bogus serial number?
I've tried some and they didn't work and lead to the error page. But I've captured an upload from the scope to the server.

http://www.rigol.com/up.aspx?act=up&filename=MS5A204700xxx.dat

The "file" contained the scope's type and the current firmware, nothing else. Maybe it needs to register itself before it can download a firmware? I didn't have the time to repeat the tests to see if these uploads happen regularly.

 

Online FriedMule

  • Frequent Contributor
  • **
  • Posts: 603
  • Country: dk
  • Can make even the simplest task look imposible.
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #546 on: January 07, 2019, 12:30:14 am »
So if I bought a rigol mso5000 in next week, can it then be hacked?
Sorry I am asking, it's because I am a noob and all those 22 pages of informations and comments confuse me.
 

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1901
  • Country: gb
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #547 on: January 07, 2019, 12:32:48 am »
So if I bought a rigol mso5000 in next week, can it then be hacked?
Sorry I am asking, it's because I am a noob and all those 22 pages of informations and comments confuse me.

Right now yes it can have all the options and 350MHz bandwidth enabled.

After the next software upgrade... who knows.

Watch this space.
 

Online FriedMule

  • Frequent Contributor
  • **
  • Posts: 603
  • Country: dk
  • Can make even the simplest task look imposible.
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #548 on: January 07, 2019, 12:37:46 am »
Thanks for you wary fast answer!! :-)
Is there anything that I shall think about, except for the guaranty being void?
I mean before jumping out and buy.
 
The following users thanked this post: Noy

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1901
  • Country: gb
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #549 on: January 07, 2019, 12:51:23 am »
Thanks for you wary fast answer!! :-)
Is there anything that I shall think about, except for the guaranty being void?
I mean before jumping out and buy.

You won't void the warranty unless you do something crazy stupid.

There is the very real risk that in future software updates all the 'bonus' features will disappear. Only you can decide if you want to take that risk.

A better place to discuss this is:
https://www.eevblog.com/forum/blog/new-rigol-scope/
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf