Hacking the Rigol MSO5000 series oscilloscopes

[oliv3r]

If someone could be so kind as to get me a mtd0 dump, I can poke there a little.
cat /dev/mtd0 > /tmp/mtd0.dump
Not sure if this is 'the way' to do nanddumps though I think if it's an mtd we can just do this.
(or directly to usb) would be great; while at it, compare it to /tmp/env.bin; rigol seems to be saving the env there every boot so if they are different, if you could get me both files; that'd be even better

(rigol dumps their nand like this: nanddump -s 0 -l 0x40000 -f /tmp/env.bin /dev/mtd0 )

I'm quite certain that the content of these files should be identical (except maybe some padding at the end).

[tv84]

If someone could be so kind as to get me a mtd0 dump, I can poke there a little.

By your command.

[oliv3r]

From what I can gather so far, the buildroot base is identical for both firmware images (5000 and 7000 I have so far).

I have not dug too deep yet into the filesystem, just some early poking around, but I'm quite sure that the major differences will be if device = 5000 ... if device = 7000 ... kind of logic.

heck, the keyword 'flamingo' (MSO7000) lights up like a christmas tree when grepping in the extracted image filesystem, where kerstrel (MSO5000) can't be found anywhere.

The update (which is newer of course) for the MSO7000 did have a few changes. startEntry is now called flamingo_console. There is a new script called 'bw.sh' that opens/closes 20 MHz bandwith to something over SPI.

So it could be that these are separately developed binaries, only name changes or .. just a bit messy development ...

We'll know more in a few updates when they synchronize their update files. Until then, every update is worth poking around in

Comparing kernels between the two, I found so far that they are build from the exact same source, but the touchscreen drivers seem to differ:

Code: [Select]

-TOUCHSCREEN_Goodix_TS y
 TOUCHSCREEN_SSD2543 n -> y
The MSO5000 has the SD2543 touchscreen, and I think the MSO7000 has a Goodix ts.

So because of that, for now, the firmwares are unique between the two and they can't be interchanged. But who knows, the app may very well run on either scope. E.g. what happens if we run flamingo_console on a MSO5000; (safer is to try the other way around of course). Will that yield us a MSO7000 in a MSO5000 box >: ) For those playing along at home, remember to add extra cooling when trying that :p

[oliv3r]

I do have a worry ...
I cannot seem to find anything GPL related to rigol. There is https://github.com/rigol but that seems all very much work in progress/abandoned/

So far, I see that:

They used buildroot to compile their OS -> GPLv2+
(and they have a -dirty tree, meaning uncommitted changes, so the hash may not point to anything public)
They use u-boot -> GPLv2+
They use Linux -> GPLv2+
They use busybox -> GPLv2

They've added some drivers from later kernels (app/drivers) which are NOT their own (strings shows they are GPL licensed)

CUPS is actually not viral licensed anymore, but I doubt they compiled it themselves ... it may not be part of build-root and so they just compiled it from source is my guess

some dbus stuff
some other libs and stuff

So clearly, currently they could be violating the GPL. While I don't think it's important yet to start bugging them about it (I doubt they have (m)any changes from upstream and the only code they wrote is in flamingo_console/appEntry) I am curious how they will deal with this ... I think this is their first-ish Linux offering ...

[asmi]

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

Not exactly. 7015 is fundamentally different from 10/20 in that its' fabric has 4 MGTs (GTPs) which support up to 6.6 Gbps per channel. I suspect they use these transceivers to talk to their ASICs.

[oliv3r]

If someone could be so kind as to get me a mtd0 dump, I can poke there a little.

By your command.

Super thanks! So the positive is that apparently their default data contains tftp boot/NFS mounts. So during dev they probably where booting over the network, and so can we

Sadly, their stored environment is a little light on the details, it's missing quite a few environment variables. I think they manually generated their initial 'stored' environment which supplements their built-in environment. So we probably need that as well.

So yet another request to get some more data. In the u-boot console, the output of 'printenv' would be great. While in the u-boot console, i'm curious about 'sf probe' as well, it should list the SPI flash that's used to boot the device from. If that returns something useful, we can read (and dump) the spi flash via u-boot!

Not sure if we can dump the spi flash content to file, but tftp is easy. We do need to know the details of the flash-chip (size) but then it's
sf read 0x4900000 0 <size of flash>
tftp 0x4900000 spiflash.dump <size of flash>

(that does assume a working tftp setup, e.g. proper ip's etc)

To return the fruits of your labor however, here's the decompiled env.bin into env.cmd

Code: [Select]

backpart=B
baudrate=115200
bootdelay=1
bootver=2018.06.27
ethact=Gem.e000b000
ethaddr=00:0a:35:00:01:2a
gatewayip=172.16.3.1
ipaddr=172.16.3.254
modeboot=qspiboot
nandboot=loadzynq;ledoff;run bootlogo; nand read 0x3000000 0x1100000 0x1000000;bootm 0x3000000
netmask=255.255.255.0
nfsboot=nfs 0x3000000 172.16.3.38:/home/rigolee/workspace/nfs/system.img && bootm 0x3000000
serverip=172.16.3.252
stderr=serial
stdin=serial
stdout=serial
update=if tar 0x4000000 0x2000000 fw4uboot.sh; then  aesTest 0x2000000 ${temp_file_size} 0x2100000if exec 0x2100000; then echo update success!; else echo update failed!; fi;else echo can not find update shell!;fi;
upnet=nfs 0x4000000 172.16.3.38:/home/rigolee/workspace/nfs/FlamingoUpdate.GEL && run update
usbboot=if usb start; then echo Copying Linux from USB to RAM... && fatload usb 0 0x3000000 uImage && fatload usb 0 0x2A00000 devicetree.dtb && fatload usb 0 0x2000000 uramdisk.gz && bootm 0x3000000 0x2000000 0x2A00000; fi;
usbupdate=upgradeFromUSB
vendor=RIGOL TECHNOLOGIES
nandbootA=checkGTP;loadzynq 0x4900000;ledoff;loadlogo 0x4500000;nand read 0x3000000 0x5100000 0xd8ebf0;bootm 0x3000000
nandbootB=checkGTP;loadzynq 0xd900000;ledoff;loadlogo 0xd500000;nand read 0x3000000 0xe100000 0xd8ebf0;bootm 0x3000000
bootlogo=loadlogo 0xd500000
builddate=2018-10-11 16:45:53
softver=00.01.01.02.03
bootpart=B
bootcmd=if run nandbootB; then echo 'ok'; else setenv bootpart A;save;run nandbootA; fi

Note that the ordering is not alphabetical. U-Boot itself always saves the environment alphabetically (or printenv does at least) so it's likely that the out-of-order entries are entries rigol 'adds' to the end of the file.

I wonder if that mac address is unique or identical for all devices. MAC's shouldn't be stored in envs (u-boot will export them to the env of course).
Further more, there are a few commands that are interesting (aesTest for example) which of course is a wrapper around the u-boot zynq-only aes command. But where is it stored? (Hopefully in the aforementioned printenv) otherwise, it's part of the GPL sources, and then, we have to start pressing Rigol to share them as per GPL.

Also I'm not sure yet if they have a distr_bootcmd as part of their printenv. Otherwise the env entry will be bootcmd, which will boot from either of the nand-flashes.

Why that matters is because that way we cannot 'break into' the boot sequence externally. E.g. the USB stick won't be accessed as it will boot from NAND first. And while changing the environment is trivial; it's invasive Booting noninvasive from USB is of course much cooler But for that we need to full printenv (and potentially their u-boot compiled version).

[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?

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

I was going to come back on that, it turns out, xilinx has a site which lists tons of boards.
https://www.xilinx.com/products/boards-and-kits/device-family/nav-zynq-7000.html

You have to sort prices from high-to low and start at about page 3; as there is a lot of 'contact vendor for price' that gits listed first otherwise.

The cheapest is 69 USD, but that's a single-core zynq-7007s. But for 75 USD we can start with a nice 7010 dual-core; https://www.xilinx.com/products/boards-and-kits/1-pcz4k3.html though as noted by asmi

Not exactly. 7015 is fundamentally different from 10/20 in that its' fabric has 4 MGTs (GTPs) which support up to 6.6 Gbps per channel. I suspect they use these transceivers to talk to their ASICs.

So I went digging into that a little; the low-budge (single and dual cores upto including the 7020) are the same, albeit GPIO and FPGA size difference, with indeed the 7012s and 7015 have the 4 MGT's, which I agree is probably how they are talking to their ASIC. So Ideally, we should find a 7015 based board, even if just to get the identical SoC.

The main reason to get a zynq based board is to avoid bricking the device; but if we can extract the SPI flash rom; worst case, we need to jtag back the SPI flash; the rest of the software is fully recoverable, though the /rigol/data (/dev/mtd1) partition will be critical to backup (calibration data, serial number etc are likely stored there).

[FireBird]

I wonder if that mac address is unique or identical for all devices.

I have the same MAC in my environment but 00:0a:35 is a Xilinx MAC and I haven't captured it during a normal boot. During normal operation, the packets have Rigol MACs (00:19:af).

[bitwelder]

So clearly, currently they could be violating the GPL. While I don't think it's important yet to start bugging them about it (I doubt they have (m)any changes from upstream and the only code they wrote is in flamingo_console/appEntry) I am curious how they will deal with this ... I think this is their first-ish Linux offering ...

Just for starters, do the 'scope comes with the usual leaflet (or pages at the end of the manual) about notes on GPL licensed components and how to request the source code?

[Karel]

They only have to provide the sourcecode (of the GPL'ed parts) if they modified it.
Maybe they use unmodified GPL'ed software.

[oliv3r]

They only have to provide the sourcecode (of the GPL'ed parts) if they modified it.
Maybe they use unmodified GPL'ed software.

They modified it trust me. Not sure yet about u-boot (as I wasn't able to dig into that, but they very likely changed the default environment (visible with printenv) which is a code change; so it starts there. Also they added the 'localversion=RIGOLEE' so that's a modification in itself. Granted. these are modifications that don't matter so I hope they left it at that.

Then they modified the linux kernel (they modified the xilinixfb driver, and at the least added a compatible devDPU). They added a devIRQ (probably because their ancient kernel didn't support /sys/class/gpio properly) They backported some other drivers, (/rigol/app/drivers) some, of which they are not the copyright holders.

I'm not familiar enough with buildroot to know what they changed their, but I doubt they left it unchanged (as they'd need to commit their own changes for the whole build-system that they need; so it's very likely it is modified.

Then of course we have some userspace tools; but I do agree they probably didn't touch these (busybox, cups, oprofile).

As for their own application; yes, that is their own and they can do with it as they wish of course

Now what I'd be interesting is, is the HDL that runs in the zynq. Not to RE or even to analyze, but to improve and replace. The video bit comes to mind. As they are using a QT stack, the video drivers are actually part of QT (linuxfb) so that are changes that are even in the realm of possibilities. But I think you need partial reconfiguration of the FPGA for that, and need to know _what_ to partially reconfigure, so you need at least some information of the bitstream blob I recon.

TL;DR
They could have the written offer for the code, but barring that, they would be in violation. Also, for both (us and them) it would be just so much easier to just push the repo's in question to somewhere public and be done with it.

Just for starters, do the 'scope comes with the usual leaflet (or pages at the end of the manual) about notes on GPL licensed components and how to request the source code?

Anybody who has the box and manuals already took a peak with regards to a software offer? I do know it must be somewhere on the scope, as there is /license/ on the device with the licenses of some of the parts in it.

[TopLoser]

Dump of MSO5074 NAND for anybody that's interested...

https://www.dropbox.com/s/zb9ay97a0df00cb/Rigol%20MSO5074%20NAND.zip?dl=0

[TopLoser]

Anybody who has the box and manuals already took a peak with regards to a software offer? I do know it must be somewhere on the scope, as there is /license/ on the device with the licenses of some of the parts in it.

No mention on the box or in any of the documents that came with it, nothing on the outside of the scope.

[oliv3r]

Dump of MSO5074 NAND for anybody that's interested...

https://www.dropbox.com/s/zb9ay97a0df00cb/Rigol%20MSO5074%20NAND.zip?dl=0

While this is super appreciated! I think you should at least remove mtd1 from there, as that contains scope specific parameters is my guess (If not, its okay, i think it is mapped to /rigol/data if you want to check), such as serial numbers and licenses.

EDIT Yes this does indeed contain your license keys, MAC address and other info, so do please remove mtd1 from the download. I am grateful for it as it allows me to poke more into the firmware's inner workings, so thanks for that

Now all we need is a way to dump the u-boot binary from the SPI flash and I have everything to replicate a scope :p
So if we can get the output of 'sf probe' we know u-boot can talk to it, and if so, we can use sf read to read it into memory. Getting it from memory into a file (without TFTP) I don't know yet ... So if anyone is willing to do this via serial console and u-boot, I can figure out if/how it's possible (TFTP, maybe xmodem?) worst case, we just do a md (memory dump) and capture the output of the serial line and write a simple script to convert the memory dump back into code.

Which then would be:

Code: [Select]

sf probe
sf read 0x4900000 0 <size of flash> (assuming its 16 Mbit, sf probe prints it) that will be 0x1000000)
md 0x4900000 0x1000000
becuase the serial console is quite slow, that will run for a few minutes, so logging of the serial output is required. (When using screen for example you can make it log everything into a file. Not sure if putty has that capability but https://www.viktorious.nl/2013/01/14/putty-log-all-session-output/ seems to suggest it is so.

While here, also do a printenv

I have ordered the MYIR z-turn lite 7010 so we'll see when it arrives here. Not to bad for 95 Euro's (I got the GPIO breakout board). Probably will take 6 weeks to get here though

[TopLoser]

While this is super appreciated! I think you should at least remove mtd1 from there, as that contains scope specific parameters is my guess (If not, its okay, i think it is mapped to /rigol/data if you want to check), such as serial numbers and licenses.

This scope is a sacrificial lamb off to slaughter, warranty is already void and I suspect it will suffer all sorts of abuse before it finally dies...

Bring it on!

[tv84]

I have ordered the MYIR z-turn lite 7010 so we'll see when it arrives here. Not to bad for 95 Euro's (I got the GPIO breakout board). Probably will take 6 weeks to get here though

I also bought the 7020...

Do you read PMs?

[TopLoser]

So if we can get the output of 'sf probe' we know u-boot can talk to it, and if so, we can use sf read to read it into memory.

While here, also do a printenv

Ok... breaking into u-boot is a right pain so far. There is the 'Hit any key' message but the countdown timer starts at zero so no time to hit a key. I tried holding SPACE down continuously during the boot process and never managed to break in.

But... if I spew a stream of data at the scope during boot I can break in...

rigol-uboot>sf probe
zynq_qspi_setup_slave: No QSPI device detected based on MIO settings
SF: Failed to set up slave
Failed to initialize SPI flash at 0:0

rigol-uboot>printenv
Invalid input(hxh)

Not very promising so far...

[oliv3r]

I have ordered the MYIR z-turn lite 7010 so we'll see when it arrives here. Not to bad for 95 Euro's (I got the GPIO breakout board). Probably will take 6 weeks to get here though

I also bought the 7020...

Do you read PMs?

I do now

what do you mean 'also' :p the z-turn lite? I don't think that exists in a 7020 flavor :p Which board did you order?

[oliv3r]

So if we can get the output of 'sf probe' we know u-boot can talk to it, and if so, we can use sf read to read it into memory.

While here, also do a printenv

Ok... breaking into u-boot is a right pain so far. There is the 'Hit any key' message but the countdown timer starts at zero so no time to hit a key. I tried holding SPACE down continuously during the boot process and never managed to break in.

But... if I spew a stream of data at the scope during boot I can break in...

rigol-uboot>sf probe
zynq_qspi_setup_slave: No QSPI device detected based on MIO settings
SF: Failed to set up slave
Failed to initialize SPI flash at 0:0

rigol-uboot>printenv
Invalid input(hxh)

Not very promising so far...

Huh? hxh is weird, it's almost as it doesn't like your command ... you can always do a 'help' to see if the command is different, I recall that in very old u-boots it may be env print for example. If you do not mind editing your environment, you can very easily increase the timeout

from the u-boot console, you can do

Code: [Select]

rigol-uboot> setenv bootdelay 2
for example, followed by either a `saveenv` or just `save`<enter>. These days it is saveenv, but i see rigol use in the scripts (to modify the bootpart parameter) use save instead.

Code: [Select]

rigol-uboot> save

Alternativly, you can do all this from linux (which we learned from the fw4linux.sh script
This requires /tmp/env.bin to be available (which it always is as several scripts extract it using "nanddump -s 0 -l 0x40000 -f /tmp/env.bin /dev/mtd0" via rc.S) So double check if the file exists:

Code: [Select]

ls -laF /tmp/env.bin
and then modify the env

Code: [Select]

/rigol/tools/cfger -s "bootdelay 2"
flash_eraseall /dev/mtd0
nandwrite -p /dev/mtd0 /tmp/env.bin

edit: clarified changing bootdelay from the u-boot shell

[TopLoser]

Help? Been there done that....

rigol-uboot>bollocks
Unknown command 'bollocks' - try 'help'
rigol-uboot>help
Invalid input(hxh)

[TopLoser]

Ok....
rigol-uboot>setenv bootdelay=3 save
## Error: illegal character '='in variable name "bootdelay=3"

Leave out the '=' and no error messages (or otherwise)
rigol-uboot>setenv bootdelay 3 save

Scared to have to reboot and see if it worked!

[oliv3r]

I'm sorry I wasn't clear, but they are two commands
so

Code: [Select]

setenv bootdelay 3
followed by

Code: [Select]

save
without the save, nothing happens. You basically just set the bootdelay variable to read '3 save' and after a reboot it's gone (reset, without the save)

[TopLoser]

I'm sorry I wasn't clear, but they are two commands
so

Code: [Select]

setenv bootdelay 3
followed by

Code: [Select]

save
without the save, nothing happens. You basically just set the bootdelay variable to read '3 save' and after a reboot it's gone (reset, without the save)

Ok cool... well it made no difference so I tried the Linux way:

Code: [Select]

/rigol/tools/cfger -s "bootdelay 5"
flash_eraseall /dev/mtd0
nandwrite -p /dev/mtd0 /tmp/env.bin

That made no difference either, countdown is still instantaneous.

[oliv3r]

Help? Been there done that....

rigol-uboot>bollocks
Unknown command 'bollocks' - try 'help'
rigol-uboot>help
Invalid input(hxh)

LOL they removed the 'help' command to make the binary smaller (or remove it to please the user lol)

ok, so then i'll just have to get the info from an older u-boot manual.
until now, i had to do all this from memory :p

[Fungus]

Would it be possible to hack it so it boots faster?

I mean, what's it doing for a whole minute? That's an eternity.