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

0 Members and 7 Guests are viewing this topic.

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #275 on: December 23, 2018, 11:43:02 am »
I am between two chairs…

Buying the option bundle which costs about 700€ incl. tax don´t worry me.
The memory upgrade.... I´m not interested in - 100M standard is more than enough.
But the bandwith upgrades..
The price killing me as an owner of a 5074.
Buying the options but hacking the bandwith, this is in my mind, weird… ;)
I don't get it. You bought this for private use didn't you? If yes, then hack it and be done with it.

I also understand that you aren't very happy with the current state of the firmware. Don't make the mistake I made in trusting firmware issues will be fixed soon. If you are going to spend more cash then buy a scope which works out of the box right now. When I was in your situation I didn't listen to this advice and I wish I did. I ended up buying a different scope and the cheaper Chinese scope ended up to be a total waste of money.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #276 on: December 23, 2018, 01:49:22 pm »
Hey all,

I'm very curious about the inside of these (both the 5k and 7k) and am curious if some of you can post further details other then the bootlog dave has already posted earlier.

I'm particularly interested in the output of

Code: [Select]
dmesg
cat /proc/cpuinfo
lspci
lsusb
df
cat /proc/mtd

Are the first things I can think of. Further more, in one of the MSO7000 video's, dave mentioned that the TX uart wasn't working, but in a MSO5000 video he was sending commands to the shell (He typed things like help which printed the busbox help screen for example) I don't think at that point the root password was yet known, so I am thinking this was done over the serial TX line. So can someone confirm/deny that the TX works normally as expected on both MSO's?

Fear not, this is not a thread de-rail-ment :) I am curious as, while we have found how to start the application with all options enabled, the actual keys not changed, and thus a firmware upgrade can quite happily drop the option. We best be prepared for that right? So in my opinion the scope is not yet hacked and there's still some work left for us.

Finally, what's with the secrecy of the GEL files for the scopes? Before forking over, quite a substantial amount and then brick it, I'm thinking of getting a Zynq development board and see if I can 'install' the firmware onto it. As such, I'd need the actual GEL file (the more versions of the different scopes, the beter). So is anybody able to share me any GEL file they have gotten yet? Meanwhile I'll try to request a firmware file from Rigol the good old manual way.
Turns out, when going to https://www.rigol.eu/products/digital-oscilloscopes/7000/ the file is right there in the download section ...

Still, if anybody has other versions, beta or whatnot for the 5k and 7k it may still help with further analysis.

Thanks for listening :)
« Last Edit: December 23, 2018, 01:55:16 pm by oliv3r »
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #277 on: December 23, 2018, 01:58:52 pm »
No derailment. That's precisely the goal of this thread.

I can get you the 5000 GEL.

You can always look at this msg:

https://www.eevblog.com/forum/testgear/new-rigol-ds7000/msg1761803/#msg1761803
« Last Edit: December 23, 2018, 02:00:40 pm by tv84 »
 

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #278 on: December 23, 2018, 02:21:46 pm »

I'm particularly interested in the output of

Code: [Select]
dmesg
cat /proc/cpuinfo
lspci
lsusb
df
cat /proc/mtd




Code: [Select]
<root@rigol>dmesg
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
On node 0 totalpages: 114688
free_area_init_node: node 0, pgdat c0631c80, node_mem_map c0669000
  Normal zone: 896 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 114688 pages, LIFO batch:31
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
pcpu-alloc: s8384 r8192 d16192 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
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@linux.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.
PCI: CLS 0 bytes, default 64
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-12-23 22:14:55 UTC (1545603295)
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)
UBI: attaching mtd6 to ubi6
UBI: scanning is finished
UBI warning: print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, reserved 19, need 160
UBI: attached mtd6 (name "App1", size 100 MiB) to ubi6
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 800, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 137759694
UBI: available PEBs: 0, total reserved PEBs: 800, PEBs reserved for bad PEB handling: 19
UBI: background thread "ubi_bgt6d" started, PID 655
UBIFS: background thread "ubifs_bgt6_0" started, PID 658
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 6, volume 0, name "app"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 97263616 bytes (92 MiB, 766 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
UBIFS: reserved for root: 0 bytes (0 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 29D18BC9-40D5-47EB-8093-D75BB394A334, small LPT model
UBI: attaching mtd1 to ubi1
UBI: scanning is finished
UBI: attached mtd1 (name "DATA", size 64 MiB) to ubi1
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 1383059050
UBI: available PEBs: 0, total reserved PEBs: 512, PEBs reserved for bad PEB handling: 160
UBI: background thread "ubi_bgt1d" started, PID 687
UBIFS: background thread "ubifs_bgt1_0" started, PID 691
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 1, volume 0, name "DATA"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 42917888 bytes (40 MiB, 338 LEBs), journal size 2158592 bytes (2 MiB, 17 LEBs)
UBIFS: reserved for root: 2027117 bytes (1979 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 678F0810-83AE-49F3-AD8C-BB561AFDEDBD, small LPT model
UBI: attaching mtd12 to ubi12
UBI: scanning is finished
UBI: attached mtd12 (name "User", size 600 MiB) to ubi12
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 4796, bad PEBs: 4, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1737885595
UBI: available PEBs: 0, total reserved PEBs: 4796, PEBs reserved for bad PEB handling: 156
UBI: background thread "ubi_bgt12d" started, PID 728
UBIFS: background thread "ubifs_bgt12_0" started, PID 732
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 12, volume 0, name "USER"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 586502144 bytes (559 MiB, 4619 LEBs), journal size 29331456 bytes (27 MiB, 231 LEBs)
UBIFS: reserved for root: 4952683 bytes (4836 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 7C7DEB0E-5611-4D11-9900-4290138ACF6B, small LPT model
xemacps e000b000.ps7-ethernet: Set clk to 24999999 Hz
xemacps e000b000.ps7-ethernet: link up (100/FULL)
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc
<root@rigol>cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 0 (v7l)
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0

processor       : 1
model name      : ARMv7 Processor rev 0 (v7l)
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0

Hardware        : Xilinx Zynq Platform
Revision        : 0000
Serial          : 0000000000000000
<root@rigol>lspci
<root@rigol>lsusb
Bus 001 Device 001: ID 1d6b:0002
<root@rigol>df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                31729     22410      9319  71% /
devtmpfs                218708         0    218708   0% /dev
none                    102400       284    102116   0% /tmp
/dev/ubi6_0              87160     71224     15936  82% /rigol
/dev/ubi1_0              38072       256     35836   1% /rigol/data
/dev/ubi12_0            529048       408    523804   0% /user
<root@rigol>cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "Env"
mtd1: 04000000 00020000 "DATA"
mtd2: 00400000 00020000 "Bmp"
mtd3: 00400000 00020000 "Bmp1"
mtd4: 00800000 00020000 "Bit1"
mtd5: 02000000 00020000 "Sys1"
mtd6: 06400000 00020000 "App1"
mtd7: 00400000 00020000 "Bmp2"
mtd8: 00800000 00020000 "Bit2"
mtd9: 02000000 00020000 "Sys2"
mtd10: 06400000 00020000 "App2"
mtd11: 04300000 00020000 "Reserved"
mtd12: 25800000 00020000 "User"
<root@rigol>

 

Online Martin72

  • Super Contributor
  • ***
  • Posts: 5670
  • Country: de
  • Testfield Technician
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #279 on: December 23, 2018, 07:17:44 pm »

I don't get it. You bought this for private use didn't you? If yes, then hack it and be done with it.

I also understand that you aren't very happy with the current state of the firmware. Don't make the mistake I made in trusting firmware issues will be fixed soon. If you are going to spend more cash then buy a scope which works out of the box right now. When I was in your situation I didn't listen to this advice and I wish I did. I ended up buying a different scope and the cheaper Chinese scope ended up to be a total waste of money.


You´re right.
Two times…
It´s for private use only so why I´m afraid - Maybe because I´ve done this never before except hacking my 1054Z which was easy enough for me to do.

Quote
Don't make the mistake I made in trusting firmware issues will be fixed soon.


They´re two models I like to have, one is the R&S RTM 2/3000 series or a DSO 3000 from keysight.

Serial decoding will become more important for me so I had to buy the options also.
And then comes the MSO5000 along…
Not bad at all, "only" the firmware must be fixed on various points and this is my hope instead of spending an enormous amount of money for the above mentioned scopes.


Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #280 on: December 23, 2018, 07:36:43 pm »
Another option is to lower the requirements a little bit. In the end I bought a scope from GW Instek which just works. The highest bandwidth model of the MSO2000E version will still set you back around 2000 euro so it is not particulary cheap. OTOH it does have a few features the other oscilloscopes don't have: input filtering and you can change the decoding settings afterwards. There isn't such a thing as a perfect oscilloscope.

The hackability of the Rigol scopes may seem like a lot of fun and getting things 'for free' but in the end that doesn't help you if the features don't work the way you need them to work. Let alone if you are going to pay for the options.
« Last Edit: December 23, 2018, 08:06:34 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7547
  • Country: 00
  • +++ ATH1
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #281 on: December 23, 2018, 08:22:00 pm »
Another option is to lower the requirements a little bit. In the end I bought a scope from GW Instek which just works. The highest bandwidth model of the MSO2000E version will still set you back around 2000 euro so it is not particulary cheap. OTOH it does have a few features the other oscilloscopes don't have: input filtering and you can change the decoding settings afterwards. There isn't such a thing as a perfect oscilloscope.

The hackability of the Rigol scopes may seem like a lot of fun and getting things 'for free' but in the end that doesn't help you if the features don't work the way you need them to work. Let alone if you are going to pay for the options.

C'mon, this is a pure technical thread, not just a general discussion for this scope, yet you're still keep pushing & pushing GW Instek here, while constantly keep bashing Rigol, sound really desperate, aren't you ?

Hows your GW Instek sales achievement this 2018 ? Wish its beyond the committed target.  :P
 
The following users thanked this post: TopLoser, skench

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #282 on: December 23, 2018, 09:06:26 pm »
Another option is to lower the requirements a little bit. In the end I bought a scope from GW Instek which just works. The highest bandwidth model of the MSO2000E version will still set you back around 2000 euro so it is not particulary cheap. OTOH it does have a few features the other oscilloscopes don't have: input filtering and you can change the decoding settings afterwards. There isn't such a thing as a perfect oscilloscope.

The hackability of the Rigol scopes may seem like a lot of fun and getting things 'for free' but in the end that doesn't help you if the features don't work the way you need them to work. Let alone if you are going to pay for the options.

C'mon, this is a pure technical thread, not just a general discussion for this scope, yet you're still keep pushing & pushing GW Instek here, while constantly keep bashing Rigol, sound really desperate, aren't you ?
You've got it all wrong. Martin72 is on exactly the same path I was a couple of years ago. Looking for a good oscilloscope which does a lot except breaking the bank. As I wrote before: I wish I had listened to the advice I was given on this forum back then. And I also like to share what has been my solution in the end. I can't help it if that doesn't sit right with you but the facts are the facts.

BTW: I have nothing to gain by pushing any brand. I'm just a demanding test equipment user sharing what works for me and what doesn't.
« Last Edit: December 23, 2018, 09:11:45 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #283 on: December 23, 2018, 09:15:12 pm »
It’s a good answer nctnico but it’s the same one you post in every thread about every scope on sale!

Can we try and keep the clutter out of this thread please otherwise we end up with 500 pages of off-topic posts.

Can the 3 wise men stay away please  ;) You know who you are!!!
 
The following users thanked this post: Sparky, skench

Online Martin72

  • Super Contributor
  • ***
  • Posts: 5670
  • Country: de
  • Testfield Technician
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #284 on: December 23, 2018, 09:55:50 pm »
Back to Topic...

Unfortunately I left my rigol at work, nevertheless I want to try it out with the "hack" when I got it back.
Hacking the Rigol 1054Z was even for a noob as me easy.
This time it wouldn´t I guess.
I did just measurements all the years, don´t have experience with network things... :palm:  :-\
A little help is required to get the bee on the flower...

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #285 on: December 23, 2018, 10:13:14 pm »
A little talk about the the consequences of the "feature" is acceptable but we should do our best to keep this at the tech level.

BTW, if anyone could post true bandwidth sweeps, with/without fullopt, would be great.
 
The following users thanked this post: Sparky, TopLoser

Offline FireBird

  • Regular Contributor
  • *
  • Posts: 68
  • Country: at
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #286 on: December 23, 2018, 10:20:25 pm »
Is there somewhere a description how to modify the boot logo already? If not, I can provide one.

 
The following users thanked this post: TopLoser

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #287 on: December 23, 2018, 10:20:36 pm »
It’s stupidly easy... (even I did it)

Download and install PuTTY on your PC
On your scope find its IP address by UTILITY, IO, LAN
Run PuTTY and connect using that IP address and SSH with port 22
Login as ‘root’ password ‘root’
Enter ‘cd /rigol/shell’
Enter ‘vi start.sh’

Change line 82 to read:
‘/rigol/appEntry  $PowerOn -run -fullopt &’

Google vi commands to find out how to insert text into the file
Basically press ‘i’ to enter edit mode then move cursor, insert text and then ESC to exit edit mode.

Save the file and quit ‘:wq’

Reboot.
« Last Edit: December 24, 2018, 05:46:51 pm by TopLoser »
 
The following users thanked this post: thm_w, AndersAnd, Martin72

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #288 on: December 23, 2018, 10:26:09 pm »
You've got it all wrong. Martin72 is on exactly the same path I was a couple of years ago. Looking for a good oscilloscope which does a lot except breaking the bank. As I wrote before: I wish I had listened to the advice I was given on this forum back then. And I also like to share what has been my solution in the end. I can't help it if that doesn't sit right with you but the facts are the facts.

BTW: I have nothing to gain by pushing any brand. I'm just a demanding test equipment user sharing what works for me and what doesn't.

Problem: You never see anything positive in anything made by Rigol. Ever. You're not seeing that you get a four-channel, 250Mhz 'scope, with siggen. It's a damn useful tool for diagnosing circuits even if some niggling little feature (or even three!) isn't perfectly to your liking. For $999? It's a steal.
 
The following users thanked this post: nugglix

Online Martin72

  • Super Contributor
  • ***
  • Posts: 5670
  • Country: de
  • Testfield Technician
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #289 on: December 23, 2018, 11:03:33 pm »
In 2015, I brought a DS1054Z to work.
Now we got 4 DS1054Z for our developement team, nuff said about rigol.


Quote
It’s stupidly easy... (even I did it)


Thanks for your explanation in your post  :)


Quote
BTW, if anyone could post true bandwidth sweeps, with/without fullopt, would be great.


I´m working on it.
Full mem/function generator wouldn´t be a problem, power analysis too.
But Bandwith.....
« Last Edit: December 23, 2018, 11:09:03 pm by Martin72 »
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #290 on: December 23, 2018, 11:42:29 pm »
@nctnico, @Fungus

Just as this thread was getting itself back on track (thanks to TopLoser for nice x-ray images of the MSO pod!) it has again plunged into irrelevance -- speculation over the marketing tactics of some Chinese test equipment manufacturers!?!?  I even read something about Egyptians and pyramids some pages back!  WTH?  Seriously guys, it's as simple as this thread not the right place.  Stop it -- for the remainder of this thread.  Please, for all of us!
 
The following users thanked this post: AndersAnd, Simon_RL

Offline Frex

  • Regular Contributor
  • *
  • Posts: 116
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #291 on: December 24, 2018, 07:40:28 am »
Hello all,

I already have a MSO2072A hacked with full bandwidth and features, and very happy with.
Anyway, i look about the newest 5000 and 7000 series and they seems greats...
Even if a 7000 il a little out of budget with the MSO option  ;D
It's a great news too see there is a hack for the 5000.

I would like now is anybody have done some bandwidth measurement after the hack
to check it ? (using avalanche pulse generator).
Many tanks,

Frex
 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #292 on: December 24, 2018, 09:49:55 am »
MSO5000 FW v01.01.02.03

(link will expire after 24h)

Thanks for that! This is the original GEL, as in the version that comes shipped on the scopes yeah? Do you have this for the 7000 as well? For that I only have 00.01.01.07.01 so far ...

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #293 on: December 24, 2018, 09:55:37 am »

I'm particularly interested in the output of

Code: [Select]
dmesg
cat /proc/cpuinfo
lspci
lsusb
df
cat /proc/mtd




Code: [Select]
<root@rigol>dmesg
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
On node 0 totalpages: 114688
free_area_init_node: node 0, pgdat c0631c80, node_mem_map c0669000
  Normal zone: 896 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 114688 pages, LIFO batch:31
PERCPU: Embedded 8 pages/cpu @c09f1000 s8384 r8192 d16192 u32768
pcpu-alloc: s8384 r8192 d16192 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
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@linux.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.
PCI: CLS 0 bytes, default 64
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-12-23 22:14:55 UTC (1545603295)
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)
UBI: attaching mtd6 to ubi6
UBI: scanning is finished
UBI warning: print_rsvd_warning: cannot reserve enough PEBs for bad PEB handling, reserved 19, need 160
UBI: attached mtd6 (name "App1", size 100 MiB) to ubi6
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 800, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 137759694
UBI: available PEBs: 0, total reserved PEBs: 800, PEBs reserved for bad PEB handling: 19
UBI: background thread "ubi_bgt6d" started, PID 655
UBIFS: background thread "ubifs_bgt6_0" started, PID 658
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 6, volume 0, name "app"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 97263616 bytes (92 MiB, 766 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
UBIFS: reserved for root: 0 bytes (0 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 29D18BC9-40D5-47EB-8093-D75BB394A334, small LPT model
UBI: attaching mtd1 to ubi1
UBI: scanning is finished
UBI: attached mtd1 (name "DATA", size 64 MiB) to ubi1
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 1383059050
UBI: available PEBs: 0, total reserved PEBs: 512, PEBs reserved for bad PEB handling: 160
UBI: background thread "ubi_bgt1d" started, PID 687
UBIFS: background thread "ubifs_bgt1_0" started, PID 691
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 1, volume 0, name "DATA"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 42917888 bytes (40 MiB, 338 LEBs), journal size 2158592 bytes (2 MiB, 17 LEBs)
UBIFS: reserved for root: 2027117 bytes (1979 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 678F0810-83AE-49F3-AD8C-BB561AFDEDBD, small LPT model
UBI: attaching mtd12 to ubi12
UBI: scanning is finished
UBI: attached mtd12 (name "User", size 600 MiB) to ubi12
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 4796, bad PEBs: 4, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1737885595
UBI: available PEBs: 0, total reserved PEBs: 4796, PEBs reserved for bad PEB handling: 156
UBI: background thread "ubi_bgt12d" started, PID 728
UBIFS: background thread "ubifs_bgt12_0" started, PID 732
UBIFS: recovery needed
UBIFS: recovery completed
UBIFS: mounted UBI device 12, volume 0, name "USER"
UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS: FS size: 586502144 bytes (559 MiB, 4619 LEBs), journal size 29331456 bytes (27 MiB, 231 LEBs)
UBIFS: reserved for root: 4952683 bytes (4836 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 7C7DEB0E-5611-4D11-9900-4290138ACF6B, small LPT model
xemacps e000b000.ps7-ethernet: Set clk to 24999999 Hz
xemacps e000b000.ps7-ethernet: link up (100/FULL)
Rigol Device gadget: Rigol Device ready
usbcore: registered new interface driver usbtmc
<root@rigol>cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 0 (v7l)
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0

processor       : 1
model name      : ARMv7 Processor rev 0 (v7l)
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0

Hardware        : Xilinx Zynq Platform
Revision        : 0000
Serial          : 0000000000000000
<root@rigol>lspci
<root@rigol>lsusb
Bus 001 Device 001: ID 1d6b:0002
<root@rigol>df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                31729     22410      9319  71% /
devtmpfs                218708         0    218708   0% /dev
none                    102400       284    102116   0% /tmp
/dev/ubi6_0              87160     71224     15936  82% /rigol
/dev/ubi1_0              38072       256     35836   1% /rigol/data
/dev/ubi12_0            529048       408    523804   0% /user
<root@rigol>cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "Env"
mtd1: 04000000 00020000 "DATA"
mtd2: 00400000 00020000 "Bmp"
mtd3: 00400000 00020000 "Bmp1"
mtd4: 00800000 00020000 "Bit1"
mtd5: 02000000 00020000 "Sys1"
mtd6: 06400000 00020000 "App1"
mtd7: 00400000 00020000 "Bmp2"
mtd8: 00800000 00020000 "Bit2"
mtd9: 02000000 00020000 "Sys2"
mtd10: 06400000 00020000 "App2"
mtd11: 04300000 00020000 "Reserved"
mtd12: 25800000 00020000 "User"
<root@rigol>


Many thanks for that. Sadly, this _still_ does not show me which zynq they are using. I think someone mentioned somewhere that it's a 7020, at least we know it's a dual-core. So that leaves out a few of them and we know it runs about 800 MHz based on the bogomips.

Also newly learned is that the 'DATA' partition holds /rigol/data, which I think is where keys and calibration data is stored.

Someone also mentioned somewhere we have a 16Mb eeprom for configuration data. I think it's mostly u-boot (haven't found that in the NAND list yet) and _maybe_ some often changing data.

They also mirror their system data, to ensure safe upgrades.

Has anybody been able to 'interrupt' u-boot yet with the any-key press? Normally if you press it a few times (space works great) just before the message appears (keyboard buffer an all that) it should pick it up, IF the tx is not disabled ... But I guess very few have it opened and a debug header connected other then dave ...

Offline mrpackethead

  • Super Contributor
  • ***
  • Posts: 2845
  • Country: nz
  • D Size Cell
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #294 on: December 24, 2018, 10:05:35 am »
What do you do with this gel file.   I can untar it, and get four .img.gz files, plus the encrypted shell scripts.    Futher untarring and and i get some .img files.. 
What do you do with those?


MSO5000 FW v01.01.02.03

(link will expire after 24h)

Thanks for that! This is the original GEL, as in the version that comes shipped on the scopes yeah? Do you have this for the 7000 as well? For that I only have 00.01.01.07.01 so far ...
On a quest to find increasingly complicated ways to blink things
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #295 on: December 24, 2018, 10:10:58 am »
Many thanks for that. Sadly, this _still_ does not show me which zynq they are using. I think someone mentioned somewhere that it's a 7020, at least we know it's a dual-core. So that leaves out a few of them and we know it runs about 800 MHz based on the bogomips.

You can see the Zynq model in my DS7000 FPGAs parsing. (see the DS7000 thread)

I assume the Zynq is the same (7015). But I can parse the 5000 .bit file and verify that for you.

The 5000 .GEL version is the one that is currently being shipped.
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #296 on: December 24, 2018, 10:14:21 am »
What do you do with those?

Massage them a bit...

 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #297 on: December 24, 2018, 10:25:17 am »
Many thanks for that. Sadly, this _still_ does not show me which zynq they are using. I think someone mentioned somewhere that it's a 7020, at least we know it's a dual-core. So that leaves out a few of them and we know it runs about 800 MHz based on the bogomips.

You can see the Zynq model in my DS7000 FPGAs parsing. (see the DS7000 thread)

I assume the Zynq is the same (7015). But I can parse the 5000 .bit file and verify that for you.

Ah see that's where I saw it (lots of threads about the 5k and 7k. With the similarities between the two platform, the OP statement about this being only about the 5k should be redacted to be about 5k and 7k. Having the information in one thread is always easier :) I believe we have 3 threads now with information scattered...

But thanks. The 7010, 7015 and 7020 are similar enough that any dev board with these chips should be accurate enough. I think it's mostly CPU speed and maybe FPGA gate count that's different, so I guess they couldn't fit their bitstream into the 7010 and went one up ...

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #298 on: December 24, 2018, 10:33:08 am »
What do you do with this gel file.   I can untar it, and get four .img.gz files, plus the encrypted shell scripts.    Futher untarring and and i get some .img files.. 
What do you do with those?


MSO5000 FW v01.01.02.03

(link will expire after 24h)

Thanks for that! This is the original GEL, as in the version that comes shipped on the scopes yeah? Do you have this for the 7000 as well? For that I only have 00.01.01.07.01 so far ...

Well mostly compare between the different versions, as for the image files, they are regular linux filesystem images.

So the system.img file, is a FIT image that you can extract the kernel and initrd from. The kernel shouldn't be important, as we should be getting the sources from RIGOL on request (GPLv2). The initrd is interesting as that is the 'boot OS'. I'm not sure yet if this is their entire rootfs (likely) or just their first stage OS (which then in turn mounts the correct disks to continue booting). But since the other image is the 'app' image, my guess is that its the actual rootfs.

The final file in the system.img file is the ftd, flattened device tree, which contains the system configuration, such as all the various busses, gpios, LED's etc etc etc. Think ACPI tables for ARM if anything.

As for the app.img, well that contains the UI only as far as I can tell. It's based off of qt5, so replacing the shipped qt5 libraries with unstripped libraries may be an interesting thing to do (if they are stripped even), making gdb work a little easier if we'd want to gdb their main application.

The two script files are interesting, as it actually shows two potential upgrade paths. One is from within linux, the other from within u-boot. My guess is that if the upgrade fails via linux, if you have the usb stick with GEL inserted during boot, u-boot will parse the update file and perform the update. Why they did this I am not sure yet.

Further more, having the images, allows us to install them onto a zynq dev board (which can be had for about 100 USD) reducing the bricking risk of the scope immensely. As there is one way you can brick it, it seems. If one would wipe the 'env' partition, then we'd have an environment-less u-boot and without serial access, we don't know what the u-boot fallback would be.

Of course, the final goal is to blink a few LED's on the scope :D (and to RE the keys of course, where more information is always better)

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #299 on: December 24, 2018, 10:33:48 am »
Ah see that's where I saw it (lots of threads about the 5k and 7k. With the similarities between the two platform, the OP statement about this being only about the 5k should be redacted to be about 5k and 7k. Having the information in one thread is always easier :) I believe we have 3 threads now with information scattered...

Makes some sense since they are so similar (or "too much similar"...). I'll ask OP to change the thread name.

BTW, what is the 3rd thread?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf