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

nctnico · « **Reply #275 on:** December 23, 2018, 11:43:02 am »

Quote from: Martin72 on December 22, 2018, 11:03:41 pm

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.

oliv3r · « **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

tv84 · « **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

TopLoser · « **Reply #278 on:** December 23, 2018, 02:21:46 pm »

Quote from: oliv3r on December 23, 2018, 01:49:22 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>

Martin72 · « **Reply #279 on:** December 23, 2018, 07:17:44 pm »

Quote from: nctnico on December 23, 2018, 11:43:02 am

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.

nctnico · « **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.

BravoV · « **Reply #281 on:** December 23, 2018, 08:22:00 pm »

Quote from: nctnico 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.

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.

nctnico · « **Reply #282 on:** December 23, 2018, 09:06:26 pm »

Quote from: BravoV on December 23, 2018, 08:22:00 pm

Quote from: nctnico 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.

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.

TopLoser · « **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!!!

Martin72 · « **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...

$:-\$
A little help is required to get the bee on the flower...

tv84 · « **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.

FireBird · « **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.

TopLoser · « **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.

Fungus · « **Reply #288 on:** December 23, 2018, 10:26:09 pm »

Quote from: nctnico on December 23, 2018, 09:06:26 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.

Martin72 · « **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.....

Sparky · « **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!

Frex · « **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

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

oliv3r · « **Reply #292 on:** December 24, 2018, 09:49:55 am »

Quote from: tv84 on December 23, 2018, 03:01:46 pm

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 ...

oliv3r · « **Reply #293 on:** December 24, 2018, 09:55:37 am »

Quote from: TopLoser on December 23, 2018, 02:21:46 pm

Quote from: oliv3r on December 23, 2018, 01:49:22 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>

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 ...

mrpackethead · « **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?

Quote from: oliv3r on December 24, 2018, 09:49:55 am

Quote from: tv84 on December 23, 2018, 03:01:46 pm
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 ...

tv84 · « **Reply #295 on:** December 24, 2018, 10:10:58 am »

Quote from: oliv3r on December 24, 2018, 09:55:37 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.

tv84 · « **Reply #296 on:** December 24, 2018, 10:14:21 am »

Quote from: mrpackethead on December 24, 2018, 10:05:35 am

What do you do with those?

Massage them a bit...

oliv3r · « **Reply #297 on:** December 24, 2018, 10:25:17 am »

Quote from: tv84 on December 24, 2018, 10:10:58 am

Quote from: oliv3r on December 24, 2018, 09:55:37 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 ...

oliv3r · « **Reply #298 on:** December 24, 2018, 10:33:08 am »

Quote from: mrpackethead 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?

Quote from: oliv3r on December 24, 2018, 09:49:55 am
Quote from: tv84 on December 23, 2018, 03:01:46 pm
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

(and to RE the keys of course, where more information is always better)

tv84 · « **Reply #299 on:** December 24, 2018, 10:33:48 am »

Quote from: oliv3r on December 24, 2018, 10:25:17 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?


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

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

Share me