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

zzzox and 3 Guests are viewing this topic.

Offline Shodge

  • Contributor
  • Posts: 21
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1000 on: March 22, 2019, 03:12:47 pm »
I do not have my scope open, but is it possible that there is a termination resistor missing in the design?  If they were using a open drain output without a pull up, the leakage current from the receiving gate might make it appear to sort of work....

Just a thought...

-Stan
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16627
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1001 on: March 22, 2019, 05:22:29 pm »
I do not have my scope open, but is it possible that there is a termination resistor missing in the design?  If they were using a open drain output without a pull up, the leakage current from the receiving gate might make it appear to sort of work....

Just a thought...

Seems much more likely than a change in timing in the low bits.

Maybe somebody at Rigol has been Muntzing, try adding a 2k pullup to the line and see what happens (or maybe a pulldown...)
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3217
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1002 on: March 22, 2019, 05:34:11 pm »
Seems much more likely than a change in timing in the low bits.

Maybe somebody at Rigol has been Muntzing, try adding a 2k pullup to the line and see what happens (or maybe a pulldown...)

Indeed it makes sense but just because Rigol must have wanted to make it unaccessible...

Olliver, what can you see in TopLoser's PCB images?

Edit: Oopsss! The photo is from TopLoser and he has the RES...  Must disassemble yours.
« Last Edit: March 22, 2019, 05:44:18 pm by tv84 »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16627
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1003 on: March 22, 2019, 05:48:49 pm »
Indeed it makes sense but just because Rigol must have wanted to make it unaccessible...

Why assume it's a deliberate anti-hacking thing?

Their diagnostic/repair tools might have a pullup resistor in them so they figured they could save a couple of cents by Muntzing that.

 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3217
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1004 on: March 22, 2019, 05:50:03 pm »
Serial is disabled immediately after the 'Hit any key' prompt, so you can still enter uboot at that point. Not available when the scope is up and running though.

TopLoser, can you confirm that while on uboot you have serial output and it just disappears when the app is called?
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3217
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1005 on: March 22, 2019, 05:53:45 pm »
Their diagnostic/repair tools might have a pullup resistor in them so they figured they could save a couple of cents by Muntzing that.

Take that specific 0R to reduce a couple cents????   :wtf:

I think it was to reduced the booting time...
 

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1006 on: March 22, 2019, 05:59:54 pm »
Serial is disabled immediately after the 'Hit any key' prompt, so you can still enter uboot at that point. Not available when the scope is up and running though.

TopLoser, can you confirm that while on uboot you have serial output and it just disappears when the app is called?

This where it stops:

Code: [Select]
U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)

I2C:   ready
Memory: ECC disabled
DRAM:  448 MiB
DPU:   20170604
NAND:  OnDie ECC supported, 1024 MiB
zynq-In:    serial
zynq-Out:   serial
zynq-Err:   serial
Net:   Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0xd900000, size 0x3591fd
Ÿ


Disabled before the kernel is loaded - compared to previous versions:

Code: [Select]
U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)

I2C:   ready
Memory: ECC disabled
DRAM:  448 MiB
DPU:   20170604
NAND:  OnDie ECC supported, 1024 MiB
zynq-In:    serial
zynq-Out:   serial
zynq-Err:   serial
Net:   Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x4900000, size 0x3591fd
þ
NAND read: device 0 offset 0x4900000, size 0x8
 8 bytes read: OK

NAND read: device 0 offset 0x4500000, size 0x12c008
 1228808 bytes read: OK
Loading logo, x=310,y=247,width=404,height=89

NAND read: device 0 offset 0x5100000, size 0xd8ebf0
 14216176 bytes read: OK
## Loading kernel from FIT Image at 03000000 ...
   Using 'rootfs@1' configuration
   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 1b099000, end 1bafe679 ... OK
   Loading Device Tree to 1b093000, end 1b09857c ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.12.0-xilinx (rigolee[member=167213]Jim[/member]) (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 [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 437416K/458752K available (4197K kernel code, 255K rwdata, 1716K rodata, 176K init, 179K bss, 21336K reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xdc800000 - 0xff000000   ( 552 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 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 dc802000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)
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
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, 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 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xdc84e000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
zynq_ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xdc880000
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[member=183778]linux[/member].it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 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 (db099000 - dbafe000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 875
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
DPU:Map vRam to 0xdca00000
DPU:Map iReg to 0xdcc00000
DPU:Ver=0x20170711
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-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, 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 0x0424/0x0009
ULPI integrity check: passed.
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000
xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Update timer was detected
rtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0
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
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, 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"
0x000010100000-0x000016500000 : "App2"
0x000016500000-0x00001a800000 : "Reserved"
0x00001a800000-0x000040000000 : "User"
TCP: cubic registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
rtc-rx8010sj 0-0032: setting system clock to 2018-11-10 12:15:08 UTC (1541852108)
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
<root@rigol>rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
2018-11-10 12:15:21: (log.c.166) server started
7 2048 16 2 "/dev/fb0"
Mount user space to:/user
default setting by user set
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc
« Last Edit: March 22, 2019, 06:02:35 pm by TopLoser »
 

Offline DeKu

  • Newbie
  • Posts: 5
  • Country: de
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1007 on: March 22, 2019, 11:19:23 pm »
Hi,

just wanted to thank every1 who has contributed. Got my Scope a day ago and its already fully upgraded thx to all of you work. So TY ppl.

I'm sorry, i got no Idea of this Stuff but:

NAND read: device 0 offset 0x4900000, size 0x3591fd
þ


NAND read: device 0 offset 0xd900000, size 0x3591fd
Ÿ


That's normal right?

Regards AND BigTHX from Hamburg

DeKu
 

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1008 on: March 22, 2019, 11:35:10 pm »
Yes quite normal. The scope has two areas A and B where it stores the previous version of firmware and alternates between them each time you upgrade.
 

Offline DeKu

  • Newbie
  • Posts: 5
  • Country: de
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1009 on: March 22, 2019, 11:42:24 pm »
Ah OK,

can't upgrade a system which is running!

THX again

P.S. But there is a "Hardware" Serial Terminal?
 

Offline rgwan

  • Contributor
  • Posts: 24
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1010 on: March 23, 2019, 03:06:47 am »
 |O
Serial is disabled immediately after the 'Hit any key' prompt, so you can still enter uboot at that point. Not available when the scope is up and running though.

TopLoser, can you confirm that while on uboot you have serial output and it just disappears when the app is called?

This where it stops:

Code: [Select]
U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)

I2C:   ready
Memory: ECC disabled
DRAM:  448 MiB
DPU:   20170604
NAND:  OnDie ECC supported, 1024 MiB
zynq-In:    serial
zynq-Out:   serial
zynq-Err:   serial
Net:   Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0xd900000, size 0x3591fd
Ÿ


Disabled before the kernel is loaded - compared to previous versions:

Code: [Select]
U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)

I2C:   ready
Memory: ECC disabled
DRAM:  448 MiB
DPU:   20170604
NAND:  OnDie ECC supported, 1024 MiB
zynq-In:    serial
zynq-Out:   serial
zynq-Err:   serial
Net:   Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x4900000, size 0x3591fd
þ
NAND read: device 0 offset 0x4900000, size 0x8
 8 bytes read: OK

NAND read: device 0 offset 0x4500000, size 0x12c008
 1228808 bytes read: OK
Loading logo, x=310,y=247,width=404,height=89

NAND read: device 0 offset 0x5100000, size 0xd8ebf0
 14216176 bytes read: OK
## Loading kernel from FIT Image at 03000000 ...
   Using 'rootfs@1' configuration
   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 1b099000, end 1bafe679 ... OK
   Loading Device Tree to 1b093000, end 1b09857c ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.12.0-xilinx (rigolee[member=167213]Jim[/member]) (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 [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 437416K/458752K available (4197K kernel code, 255K rwdata, 1716K rodata, 176K init, 179K bss, 21336K reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xdc800000 - 0xff000000   ( 552 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 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 dc802000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)
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
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, 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 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xdc84e000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
zynq_ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xdc880000
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[member=183778]linux[/member].it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 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 (db099000 - dbafe000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 875
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
DPU:Map vRam to 0xdca00000
DPU:Map iReg to 0xdcc00000
DPU:Ver=0x20170711
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-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, 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 0x0424/0x0009
ULPI integrity check: passed.
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000
xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Update timer was detected
rtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0
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
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, 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"
0x000010100000-0x000016500000 : "App2"
0x000016500000-0x00001a800000 : "Reserved"
0x00001a800000-0x000040000000 : "User"
TCP: cubic registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
rtc-rx8010sj 0-0032: setting system clock to 2018-11-10 12:15:08 UTC (1541852108)
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
<root@rigol>rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
2018-11-10 12:15:21: (log.c.166) server started
7 2048 16 2 "/dev/fb0"
Mount user space to:/user
default setting by user set
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc


They already set the PS0's pinmux configuration to PL and assign it to zero by Zynq bitstream in the new firmware. It is easy to work around, just an ordinary anti-hack trick.

Btw, there's still lots of bugs exist in the new firmware, like trigger level is not inverted when channel invert switch is on...
« Last Edit: March 23, 2019, 03:10:24 am by rgwan »
 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1011 on: March 24, 2019, 02:50:51 pm »
Meanwhile, I can read 'just about enough' to debug stuff. I do have to take appart the scope to see if I'm missing the 0? oHm resistor.

Or, as I've hinted in the past, maybe the serial passes through the FPGA and something went bad in the latest programming.

If it was unintented, a bad recovery serial port is not something very pleasant to have...

You may not be completly wrong.

Looking atleast at one of the traces on the PCB, we see it going near/under the spartan6. But I'd be supprised (rigol shouldn't suprise us anymore) that they take the serial output, route it through the FPGA, andt hen to a pinheader.

Also, it's the spartan6, which I don't think they are actually upgarding (boot from SPI flash).

Seems much more likely than a change in timing in the low bits.

Maybe somebody at Rigol has been Muntzing, try adding a 2k pullup to the line and see what happens (or maybe a pulldown...)

Indeed it makes sense but just because Rigol must have wanted to make it unaccessible...

Olliver, what can you see in TopLoser's PCB images?

Edit: Oopsss! The photo is from TopLoser and he has the RES...  Must disassemble yours.
So ... yes, I spend an hour taking it apart (I didn't realize it was such a painfull job TopLoser. Thank you for all your dissasemblies!!

And indeed, the resistor for RX on the scope side is indeed missing, as pointed out in the earlier post. Bastards. If you have your scope open again, could you measure the resistor value? My guess is, it's something super low, like 0 or 33 oHms. Maybe a protection diode-ish?

The length seems to be 1 mm; So 1005, i'll check my parts bin to get one of these ...

Serial is disabled immediately after the 'Hit any key' prompt, so you can still enter uboot at that point. Not available when the scope is up and running though.

TopLoser, can you confirm that while on uboot you have serial output and it just disappears when the app is called?

This where it stops:

Code: [Select]
U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)

I2C:   ready
Memory: ECC disabled
DRAM:  448 MiB
DPU:   20170604
NAND:  OnDie ECC supported, 1024 MiB
zynq-In:    serial
zynq-Out:   serial
zynq-Err:   serial
Net:   Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0xd900000, size 0x3591fd
Ÿ


Disabled before the kernel is loaded - compared to previous versions:

Code: [Select]
U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)

I2C:   ready
Memory: ECC disabled
DRAM:  448 MiB
DPU:   20170604
NAND:  OnDie ECC supported, 1024 MiB
zynq-In:    serial
zynq-Out:   serial
zynq-Err:   serial
Net:   Gem.e000b000
BootParam=0x0
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x4900000, size 0x3591fd
þ
NAND read: device 0 offset 0x4900000, size 0x8
 8 bytes read: OK

NAND read: device 0 offset 0x4500000, size 0x12c008
 1228808 bytes read: OK
Loading logo, x=310,y=247,width=404,height=89

NAND read: device 0 offset 0x5100000, size 0xd8ebf0
 14216176 bytes read: OK
## Loading kernel from FIT Image at 03000000 ...
   Using 'rootfs@1' configuration
   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 1b099000, end 1bafe679 ... OK
   Loading Device Tree to 1b093000, end 1b09857c ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.12.0-xilinx (rigolee[member=167213]Jim[/member]) (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 [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
Memory policy: Data cache writealloc
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
Kernel command line: console=ttyPS0,115200 no_console_suspend, root=/dev/ram rw
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 437416K/458752K available (4197K kernel code, 255K rwdata, 1716K rodata, 176K init, 179K bss, 21336K reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xdc800000 - 0xff000000   ( 552 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 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 dc802000
Zynq clock init
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop... 1725.23 BogoMIPS (lpj=8626176)
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
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, 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 4
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
gpio->base_addr is:0xdc84e000
The gpio irq num is:52
zynq_gpio e000a000.ps7-gpio: gpio at 0xe000a000 mapped to 0xdc84e000
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
zynq_ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xdc880000
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[member=183778]linux[/member].it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
NET: Registered protocol family 2
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 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 (db099000 - dbafe000)
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
NTFS driver 2.1.30 [Flags: R/W].
msgmni has been set to 875
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
DPU:Map vRam to 0xdca00000
DPU:Map iReg to 0xdcc00000
DPU:Ver=0x20170711
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-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 59, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xuartps e0001000.serial: failed to get alias id, errno -19
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 82, base_baud = 6249999) is a xuartps
brd: module loaded
loop: module loaded
xspips e0006000.ps7-spi: master is unqueued, this is deprecated
xspips e0006000.ps7-spi: at 0xE0006000 mapped to 0xDC858000, 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 0x0424/0x0009
ULPI integrity check: passed.
ULPI transceiver vendor/product ID 0x0424/0x0009
ULPI integrity check: passed.
xusbps-ehci xusbps-ehci.1: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.1: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.1: irq 76, io mem 0x00000000
xusbps-ehci xusbps-ehci.1: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
rtc-rx8010sj 0-0032: Update timer was detected
rtc-rx8010sj 0-0032: rtc core: registered rtc-rx8010sj as rtc0
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
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron MT29F8G08ADADAH4), 1024MiB, page size: 2048, OOB size: 64
Bad block table found at page 524224, version 0x01
Bad block table found at page 524160, 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"
0x000010100000-0x000016500000 : "App2"
0x000016500000-0x00001a800000 : "Reserved"
0x00001a800000-0x000040000000 : "User"
TCP: cubic registered
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
rtc-rx8010sj 0-0032: setting system clock to 2018-11-10 12:15:08 UTC (1541852108)
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
<root@rigol>rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
2018-11-10 12:15:21: (log.c.166) server started
7 2048 16 2 "/dev/fb0"
Mount user space to:/user
default setting by user set
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc

Ok this is way way way before the kernel is even informed, and we already checked the environment. BUT

They already set the PS0's pinmux configuration to PL and assign it to zero by Zynq bitstream in the new firmware. It is easy to work around, just an ordinary anti-hack trick.

They probably did not want, or where not able to use the actually PS pins, so they are probably indeed are rerouting the pins though the zynq's FPGA. And in turn, most likely are not forwarding the pins in the bit stream anymore. And this does coinside with the NAND read bit, d900000 and 4900000 are the locations of the FPGA bitstream, so it reads that, executes that, and after that it dies.

btw, how is it easy to work around? When making a new bitstream, sure it's easy, but we can't easily modify the existing bitstream can we? If we could, the solution is of course easy, just pass the bits 1-on-1 forward.

What is curious btw, is that the serial port does work before the bitstream is being loaded. Maybe that's why they have such a big flash for the u-boot. Maybe they have a very small FPGA bitstream in it, which initializes the FPGA's serial ports and the display unit?

Also that explains why the serial console is so messed up, the FPGA's timing may not be competently in sync with the 115200 baudrate. That still doesn't explain to me why it's working 'fine' on toplosers scope, so maybe it is just some resistor magic going better?

What would the suggested pull-up on the TX do? I doubt it would 'stretch' the bit by that much? Or is TopLosers USB Uart convert just so much better?

I went over the math, and they have a 0.0006% error rate on the 115200 baud rate. So the linux driver is calculating the baudrate near perfectly.
« Last Edit: March 24, 2019, 02:56:41 pm by oliv3r »
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3217
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1012 on: March 24, 2019, 03:19:30 pm »
Solder the RES and that part will be solved.
 

Online seronday

  • Regular Contributor
  • *
  • Posts: 93
  • Country: au
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1013 on: March 24, 2019, 10:41:44 pm »
oliv3r.
    I put a solder bridge across the PCB traces where the resistor is missing and then used an external 560 ohm resistor in series with the data line as a precaution.

This value of resistor had no effect on the amplitude or shape of the data bits going into the MSO5000.

Regards.
 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1014 on: March 25, 2019, 01:26:13 pm »
Solder the RES and that part will be solved.
For the data going into the scope; but getting data out of the scope still requires some magic :(

oliv3r.
    I put a solder bridge across the PCB traces where the resistor is missing and then used an external 560 ohm resistor in series with the data line as a precaution.

This value of resistor had no effect on the amplitude or shape of the data bits going into the MSO5000.

Regards.

Yeah but I want to make the 'repair' look as genuine as possible, so that no repair tech will say 'this doesn't belong' :)

So 560 oHm sounds good, but using a resistor that matches what was in the early scopes would be even more transparrant :)

Online seronday

  • Regular Contributor
  • *
  • Posts: 93
  • Country: au
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1015 on: March 25, 2019, 11:03:54 pm »
Solder the RES and that part will be solved.
For the data going into the scope; but getting data out of the scope still requires some magic :(


To fix the corrupted data coming out of the MSO500, you can always use something similar to my solution for correcting the low going data bit width, until you work out how to solve the issue in firmware.

As an alternative, you could try to find a UART interface adaptor that clocks the data bits in near the start of the data bit instead of what should be the center of the bit.
 

Offline ChRobin

  • Newbie
  • Posts: 2
  • Country: ru
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1016 on: March 27, 2019, 05:13:26 pm »
Hello! I do not understand - any Rigol mso 5xxx is unlocked. Or is it necessary to buy a four channel? (5074/72)
 

Offline mindy

  • Contributor
  • Posts: 20
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1017 on: March 27, 2019, 05:19:07 pm »
Hello! I do not understand - any Rigol mso 5xxx is unlocked. Or is it necessary to buy a four channel? (5074/72)

All MSO5k models are unlocked, including 2ch models.
If you'll buy 5072 you'll benefit of nice channel covers with a title "Optional". :)
Other than that is just a matter of if you need a warranty for all 4 channels and 4 probes.
 
The following users thanked this post: ChRobin

Offline ChRobin

  • Newbie
  • Posts: 2
  • Country: ru
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1018 on: March 27, 2019, 05:27:59 pm »
Thanks for the quick response. Now it is clear. 4 probes - there is something to think about.
 

Offline joesmith

  • Newbie
  • Posts: 3
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1019 on: March 29, 2019, 06:24:38 am »
Current best practice:

First: You will perform a series of upgrades. These have to be done using the help menu and the DS5000Update.GEL filename. The files you download here have a .txt extension. Remove it and rename it to the proper name. Attention, Windows might just hide the .txt extension! Make sure to properly unmount your USB drive, and that there is free space left on it (<50MB).

Now:
  • Note your current software version down. If it is older than 01.01.04.04 you will need to upgrade.
  • Backup your scope specific data such as calibration values. Get the DS5000Update_backup.GEL.txt from here. Rename to DS5000Update.GEL and put it on a USB drive. Execute an upgrade using the help menu in your scope, NOT the secret menu. You will see the scope doing a backup. Unplug the stick and make sure you have a backup in the data_backup folder on the stick.
  • If you have an older version of the firmware, download 01.01.04.04 from here. Also rename it to DS5000Update.GEL, put it on your usb drive, and upgrade.
  • Make sure you are on the 01.01.04.04 firmware in the about dialog.
  • Patch the scope to have all licenses. For that download the patch from here. Again rename and copy to usb drive. This time the upgrade might take a bit longer, it should ask you to reboot, if not something failed, but it is probably not fatal for your scope, no worries. Reboot.
  • Check that all licences are activated.
  • If you want, do an auto calibration and check that everything is still okay.

You can get temporary SSH access by executing this upgrade. The upgrade will "fail", but you will have ssh until reboot. You can use this to fix your calibration data, if truly required.

I ran this one on 3/27/19 and it worked flawlessly.  Mine shipped with the 01.01.04.04FW.    :-+
 
The following users thanked this post: MegaVolt, joeyjoejoe, BitBug

Offline angelo

  • Contributor
  • Posts: 32
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1020 on: April 17, 2019, 05:16:21 pm »
Just received mine from Teq on Tuesday 01.01.04.04 and the backup/upgrade worked perfectly. All options appear as licensed forever.

Thanks to those who have contributed.
 

Offline jack_d

  • Newbie
  • Posts: 1
  • Country: de
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1021 on: April 18, 2019, 11:22:50 am »
Hi to all !

My MSO5074 comes with FW 00.01.01.04.04 - followed backup/upgrade instructions and it works like a charm - all options activated forever  :-+

Is there a simple way to deactivate this hack ?

Best regards and thanks a lot for your effort,

jack_d
 

Offline Menen

  • Newbie
  • Posts: 6
  • Country: ru
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1022 on: April 18, 2019, 06:54:30 pm »
This is what I watch over the LAN.
 
The following users thanked this post: kwinz

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3217
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1023 on: April 18, 2019, 07:15:15 pm »
Is there a simple way to deactivate this hack ?

Reflashing stock FW.
 
The following users thanked this post: jack_d

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16627
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #1024 on: April 18, 2019, 07:23:52 pm »
Is there a USB stick to automatically switch between the two firmwares in the machine?

That would be cool for testing things.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf