Hacking the Rigol MSO5000 series oscilloscopes

[oliv3r]

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?

You are right, it is only 2; i thought there was the 7000 'hacking-ish' thread and the original thread from dave about the new scope. I stand corrected

[tv84]

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.

The scope accepts the usual ultra-special Rigol vendor USB flashdrive (with the special boot sector).

Don't know yet what that allows but... 

Tell me what zynq dev board do you have in mind for 100USD?

[A Hellene]

I am sorry for the following request, regarding DS1000Z in a thread about MSO5000... I am also sorry if that has already been answered and I have missed it.

The problem I face is that I have updated DS1000Z firmware to the buggy (and revoked) 04.04.03.05, which mangles long memory data while navigating through it; so I would like to downgrade to the last good known firmware version (04.04.03.02) or even to an older one I may have.

I remember having read in the past that DS1000Z firmware downgrade is a matter of writing a special signature on the flash drive that carries the downgrade firmware. Is there any chance I can have that special signature or any other help to downgrade the DS1000Z firmware, please?

-George

[tv84]

I remember having read in the past that DS1000Z firmware downgrade is a matter of writing a special signature on the flash drive that carries the downgrade firmware. Is there any chance I can have that special signature or any other help to downgrade the DS1000Z firmware, please?

George,

Don't hijack with such a OT. It's better to send a PM. Contact janekivi as he may be able to help. I think you have 2 ways: using the special Rigol USB vendor disk and patching the version number in the previous FW. I think Janekivi can help with both. I would have to do some development to replicate it.

[FireBird]

Re. logo screen: as there wasn’t any reply, I guess there isn’t such an information available yet. Or nobody is interested. Anyway…

First of all, you need to create a picture with your preferred image editing program with a maximum size of 1024 x 600 (full screen) and save it as a bitmap. I’ve programmed and uploaded a little Windows conversion tool that converts pictures (.bmp, .png or .jpg) to .hex logo format and also the other way around. If you don’t trust my exe or want to create a conversion tool for a different system, here’s the format of logo file:

LE dword  imageWidth;
LE dword  imageHeight;
LE word pixel[imageWidth * imageHeight];

The pixel format is rrrr rggg gggb bbbb;

After the .hex file has been created, copy it to a thumb drive and connect the drive to the scope. Open putty or any other ssh terminal and log in to the MSO (port 22, root/root, you know ). First verify that the thumb drive has been mounted to /media/sda1:

Code: [Select]

<root@rigol> mount

rootfs on / type rootfs (rw)
/dev/root on / type ext2 (rw,relatime,errors=continue)
devtmpfs on /dev type devtmpfs (rw,relatime,size=218708k,nr_inodes=54677,mode=755)
none on /proc type proc (rw,relatime)
none on /sys type sysfs (rw,relatime)
none on /tmp type tmpfs (rw,relatime,size=102400k)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/ubi6_0 on /rigol type ubifs (rw,relatime)
/dev/ubi1_0 on /rigol/data type ubifs (rw,sync,relatime)
/dev/ubi12_0 on /user type ubifs (rw,sync,relatime)
>>> /dev/sda1 on /media/sda1 type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=936,iocharset=utf8,shortname=mixed,errors=remount-ro)
If this is the first time you’re doing this, backup the original Rigol logo:

Code: [Select]

<root@rigol> dd if=/dev/mtd7 of=/media/sda1/logo_orig.hex

8192+0 records in
8192+0 records out
4194304 bytes (4.0MB) copied, 1.070000 seconds, 3.7MB/s
Now install your logo. Of course you need to enter the file name of your logo and this must be case sensitive:

Code: [Select]

<root@rigol> flash_eraseall /dev/mtd7

Erasing 128 Kibyte @ 400000 - 100% complete.

<root@rigol> nandwrite -p /dev/mtd7 /media/sda1/Logo_FireBird.hex

Writing at 0x00000000
Writing at 0x00020000
Writing at 0x00040000
Writing at 0x00060000
Writing at 0x00080000
Writing at 0x000a0000
Writing at 0x000c0000
Writing at 0x000e0000
Writing at 0x00100000
Writing at 0x00120000
Reboot and have fun.

[A Hellene]

George,

Don't hijack with such a OT. It's better to send a PM. Contact janekivi as he may be able to help. I think you have 2 ways: using the special Rigol USB vendor disk and patching the version number in the previous FW. I think Janekivi can help with both. I would have to do some development to replicate it.

Thank you for the reply.
Once more, I am sorry for the off-topic; yet, reading about MSO5000 hacking reminded me of my DS1000Z issue...


-George

[tv84]

Re. logo screen: as there wasn’t any reply, I guess there isn’t such an information available yet. Or nobody is interested. Anyway…

People are shy...   Keep those contributions! If everyone does a bit, it costs less.

What about MTD3? What is the BMP there?

BTW, dump both original BMP from the NAND and attach them here (as .PNGs). People like to look at some images.

[FireBird]

Rigol is talking in their update script about app A and B. All app A blocks are empty.

Code: [Select]

dev:    size   erasesize  name
mtd0:  00040000 00020000 "Env"          ; Environment as a NULL terminated list and a dword at the beginning
mtd1:  04000000 00020000 "DATA"         ; UBI FS -> /rigol/data
mtd2:  00400000 00020000 "Bmp"          ; unused FF
mtd3:  00400000 00020000 "Bmp1"         ; App A unused FF
mtd4:  00800000 00020000 "Bit1"         ; App A unused FF
mtd5:  02000000 00020000 "Sys1"         ; App A unused FF
mtd6:  06400000 00020000 "App1"         ; App A unused FF
mtd7:  00400000 00020000 "Bmp2"         ; App B Boot Logo        <- logo.hex
mtd8:  00800000 00020000 "Bit2"         ; App B Zynq Bitstream   <- zynq.bit
mtd9:  02000000 00020000 "Sys2"         ; App B Linux Kernel     <- system.img
mtd10: 06400000 00020000 "App2"         ; App B UBI FS -> /rigol <- app.img
mtd11: 04300000 00020000 "Reserved"     ; unused FF
mtd12: 25800000 00020000 "User"         ; UBI FS -> /user

[BravoV]

BTW, dump both original BMP from the NAND and attach them here (as .PNGs). People like to look at some images.

Yep, might be handy someday, when someone yells ... "I want the original logo back, where can I find one ..." 

[tv84]

Yep, might be handy someday, when someone yells ... "I want the original logo back, where can I find one ..." 

Better yet: "I would love to have my brick with the original logo, please help!!"

[tv84]

Rigol is talking in their update script about app A and B. All app A blocks are empty.

Interesting... We can have 2 different environments loaded in the machine...

Anyone with 7000 can check if it's the same scheme?

[mrpackethead]

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

Thanks for the background infomation. Its really helpful.  I have a very generic debian vm on my laptop. Am i am able to mount these images somehow, so i can start to have a poke around?

[oliv3r]

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.

The scope accepts the usual ultra-special Rigol vendor USB flashdrive (with the special boot sector).

Don't know yet what that allows but... 

Tell me what zynq dev board do you have in mind for 100USD?

I'm curious about this special 'vendor' usb stick. Is it something we can obtain/download/create?
I guess dumping the environment from /dev/mtd0 (and attaching it here) yields us all the scripts etc, if anybody could be so kind

As for the zynq dev board, there's the mini Zed for 89 USD, but is a 7007s (single core) so I feel too far from the scope. The Pynq however looks promising with a 7020, there seems to be a few flavors however, like https://nl.farnell.com/tul-corporation/1m4-m000127000/dev-kit-32bit-arm-cortex-a9-mpu/dp/2913031?st=pynq for example is only 101 Euro. But then i can't buy privately at farnell. So will have to do some more digging, but even so; it still sounds very reasonable

I find pricing for these boards can very, not sure why. (Same board, different sites, double the price). If I find a nice vendor where i can buy stuff; i'll post a link

[oliv3r]

Re. logo screen: as there wasn’t any reply, I guess there isn’t such an information available yet. Or nobody is interested. Anyway…

People are shy...   Keep those contributions! If everyone does a bit, it costs less.

What about MTD3? What is the BMP there?

That's probably u-boot's splash screen. I'd be suprised if it is initially different from the other two to keep a 'smooth' logo experience.

[oliv3r]

Rigol is talking in their update script about app A and B. All app A blocks are empty.

Code: [Select]

dev:    size   erasesize  name
mtd0:  00040000 00020000 "Env"          ; Environment as a NULL terminated list and a dword at the beginning


Standard u-boot environment created from a text file and 'compiled' with mkimage. The dword in front is the header.

Code: [Select]

mtd1:  04000000 00020000 "DATA"         ; UBI FS -> /rigol/data


As I mentioned earlier, probably configuration data and the like

Code: [Select]

mtd2:  00400000 00020000 "Bmp"          ; unused FF


Hmm strange that it is unused, I would have expected the logo for u-boot to use.

Code: [Select]

mtd3:  00400000 00020000 "Bmp1"         ; App A unused FF
mtd4:  00800000 00020000 "Bit1"         ; App A unused FF
mtd5:  02000000 00020000 "Sys1"         ; App A unused FF
mtd6:  06400000 00020000 "App1"         ; App A unused FF


This will be populated the first time an update is performed, the update script updates the 'backup', and boots from that next time.

Code: [Select]

mtd7:  00400000 00020000 "Bmp2"         ; App B Boot Logo        <- logo.hex
mtd8:  00800000 00020000 "Bit2"         ; App B Zynq Bitstream   <- zynq.bit
mtd9:  02000000 00020000 "Sys2"         ; App B Linux Kernel     <- system.img
mtd10: 06400000 00020000 "App2"         ; App B UBI FS -> /rigol <- app.img
mtd11: 04300000 00020000 "Reserved"     ; unused FF
mtd12: 25800000 00020000 "User"         ; UBI FS -> /user

[tv84]

I'm curious about this special 'vendor' usb stick. Is it something we can obtain/download/create?
I guess dumping the environment from /dev/mtd0 (and attaching it here) yields us all the scripts etc, if anybody could be so kind

It can be created, sure. I'll rewind a liitle my efforts with the DS1054Z and then I'll tell you how to create a vendor disk.

[TillMundy]

I have tested out the bandwidth with the MSO5000 "hack". I have attached some photos below. The amplitude of my signal generator is not linear so be wary of the changes in amplitude between images.

• The device will measure frequencies up to 1Ghz
• It seems that at 600Mhz the performance degrades significantly
• There may be a trigger glitch with low amplitude signals
• Not having a 50 Ohm load option for the inputs is a real downer
• Managed to crash the software during FFT, had to reboot

On the topic of screen brightness; At first when I opened the scope I thought it seemed dim. After using it for a day I didn't notice or care. Then I had to do some other measurements using two scopes. I put my Siglent SDS1104 next to it and boy is there a difference. The Siglent's small display is incredibly bright and clear. On the MSO5000 it is not only a dim screen but also bad diffusion of the back lights. All the edges of the MSO5000 are brighter than the rest of the display. I think they may have reduced the back-light brightness to reduce this effect. Comparing the display to a DSA815 the MSO5000 is still much dimmer and lower resolution.

[oliv3r]

and boy is there a difference. The Siglent's small display is incredibly bright and clear. On the MSO5000 it is not only a dim screen but also bad diffusion of the back lights. All the edges of the MSO5000 are brighter than the rest of the display. I think they may have reduced the back-light brightness to reduce this effect. Comparing the display to a DSA815 the MSO5000 is still much dimmer and lower resolution.

Once we know how the backlight is connected to linux, we can see if they purposely lowered the brightness. Since this is a device that is intended to be in use for years to come (10 years is not super unreasonable, considering I had my DS1052 for about 10 years now and would still had it if I didn't sell it cause I wanted the MSO5000 )

Given that, it could very well that Rigol actually did a lifetime analysis (I know we did at our work) taking LED degradation into account when in use 24/7 and have set the brightness to 50% or something. Or, it's just shit we don't know yet.

You can always check /sys/class/led to see if there's a backlight there, or do a `find /sys -iname '*backlight*'`to see if the backlight is controllable. I'll dig into the decompiled device tree soon and see if I can find something.

[mrpackethead]

Is all options != 350mhz?  It almost seems like it’s 500mhz ?

I had seen rumors of making it run at 1ghz?

[TopLoser]

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

Yes you can halt the boot process

Code: [Select]

[12/24 17:12:56.0]
[12/24 17:12:56.0]U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
[12/24 17:12:56.0]
[12/24 17:12:56.0]I2C:   ready
[12/24 17:12:56.0]Memory: ECC disabled
[12/24 17:12:56.0]DRAM:  448 MiB
[12/24 17:12:56.1]DPU:   20170604
[12/24 17:12:56.1]NAND:  OnDie ECC supported, 1024 MiB
[12/24 17:12:57.1]zynq-In:    serial
[12/24 17:12:57.1]zynq-Out:   serial
[12/24 17:12:57.1]zynq-Err:   serial
[12/24 17:12:57.1]Net:   Gem.e000b000
[12/24 17:12:57.1]BootParam=0x0
[12/24 17:12:57.1]Hit any key to stop autoboot:  0
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
[12/24 17:12:57.1]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.3](
[12/24 17:12:57.3]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.3]rigol-uboot>
[12/24 17:12:57.3]  aesTest base bdinfo beeper boot bootd bootm bootp bootz checkGTP checkVer
[12/24 17:12:57.3]  clk cmp coninfo cp cpldver crc32 dcache ...
[12/24 17:12:57.3]rigol-uboot>


[TillMundy]

Is all options != 350mhz?  It almost seems like it’s 500mhz ?

I had seen rumors of making it run at 1ghz?

Some features stop working after 350Mhz. For example the counter option does not work after 350Mhz. Also the frequency measurement gets iffy after 500Mhz. It will show the correct frequency 50% of the time.

It will measure and show waveforms at 1Ghz but the quality is poor and I would not consider this "hack" to unlock a 1Ghz scope.

Sent from my LM-Q910 using Tapatalk

[tinhead]

It will measure and show waveforms at 1Ghz but the quality is poor and I would not consider this "hack" to unlock a 1Ghz scope.

ehm, on your picture, you do sample with 2GSa/s, i though it can get up to 8GSa/s?

[BravoV]

It will measure and show waveforms at 1Ghz but the quality is poor and I would not consider this "hack" to unlock a 1Ghz scope.

ehm, on your picture, you do sample with 2GSa/s, i though it can get up to 8GSa/s?

Only at the 500MHz.

[TillMundy]

Sorry I was just on the wrong time scale.

[oliv3r]

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

Yes you can halt the boot process

Code: [Select]

[12/24 17:12:56.0]
[12/24 17:12:56.0]U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
[12/24 17:12:56.0]
[12/24 17:12:56.0]I2C:   ready
[12/24 17:12:56.0]Memory: ECC disabled
[12/24 17:12:56.0]DRAM:  448 MiB
[12/24 17:12:56.1]DPU:   20170604
[12/24 17:12:56.1]NAND:  OnDie ECC supported, 1024 MiB
[12/24 17:12:57.1]zynq-In:    serial
[12/24 17:12:57.1]zynq-Out:   serial
[12/24 17:12:57.1]zynq-Err:   serial
[12/24 17:12:57.1]Net:   Gem.e000b000
[12/24 17:12:57.1]BootParam=0x0
[12/24 17:12:57.1]Hit any key to stop autoboot:  0
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]rigol-uboot>U-Boot 2014.01.Rigolee.dirty (2018.06.12 - 12:12:01)
[12/24 17:12:57.1]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.1]rigol-uboot>
[12/24 17:12:57.1]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.3](
[12/24 17:12:57.3]Unknown command 'U-Boot' - try 'help'
[12/24 17:12:57.3]rigol-uboot>
[12/24 17:12:57.3]  aesTest base bdinfo beeper boot bootd bootm bootp bootz checkGTP checkVer
[12/24 17:12:57.3]  clk cmp coninfo cp cpldver crc32 dcache ...
[12/24 17:12:57.3]rigol-uboot>


That, is awesome While they can still fix this trivially (by editing the environment and disabling it) I was afraid that TX would not work. I guess Dave just made a booboo somewhere where it did not work (in the video). Probably tried to late. (one of those things that need an edit in the video with a text overlay saying it does work.

But if the u-boot allows tftp or USB access (which I think it does) we can boot from tftp or via USB images.