Zynq 700 based Rigol Software development (MSO5k, DS7k, MSO8k and probably more)

[oliv3r]

In this thread, I would like to start talking about software development on these platforms.

First things first, welcome and thanks for taking the time to read this I will try to keep this first post up to date. It follows into the footsteps that Hacking the rigol mso5000 series oscilloscopes started but got heavily derailed with mostly questions about 'please help me unlock my scope'. While all fair and game, this thread is about actually working on the scopes software. Reverse engineering it, figuring out how it works and ultimately improving it. I will not state 'lets make an open source implementation', which while possible, could take years and needs some dedication from more

This thread should be about discussion and discoveries, where they eventually will be put in a mere permanent form in the GitLab repos and its wiki's.

GitLab group The main entry point with all 'sub' repo's. The name is a wink to the DS1054z keygen.
rigolee contains several repositories and wiki's relating to the Rigol supplied items. The name is a homage to the 'user' that created all of this, though it is likely just a fake username rigol uses internally for their Linux compile VM.

Upstream firmware Contains analysis (including a copy) of all released firmwares (GEL files) up until now. The Readme contains firmware analysis documentation, and the wiki has a more general product information and some photo's. Both of these need to be re-arranged a bit, the README should reflect information that is unique to the branch it lives on, the wiki is all encompassing and generic.

Linux kernel Contains the released Linux kernel sources from rigol themselves. There are a few branches where things where cleaned up a bit. See the wiki for more details. (This is a big todo, as I still have to do/commit some of the work. The source import is there however).

U-Boot Contains the released U-Boot sources from rigol themselves. There are a few branches where things where cleaned up a bit. See the wiki for more details.

[oliv3r]

place holder for starting post follow up

[oliv3r]

place holder for follow up

[pascal_sweden]

There is already a thread for this topic:
https://www.eevblog.com/forum/testgear/other-dso-manufacturers-besides-gw-instek-that-use-xilinx-zynq-7000-series/

[tv84]

There is already a thread for this topic:
https://www.eevblog.com/forum/testgear/other-dso-manufacturers-besides-gw-instek-that-use-xilinx-zynq-7000-series/

Yours is a generic one. This thread is exclusive to Rigol's source code that Oliver got.

[tom66]

Actual source, or binaries?  ARM and/or FPGA?
There's a big difference and although the 7-series FPGA bitstream has some reverse engineering effort expended I'm not sure it's all that useful right now.

[oliv3r]

Actual source, or binaries?  ARM and/or FPGA?
There's a big difference and although the 7-series FPGA bitstream has some reverse engineering effort expended I'm not sure it's all that useful right now.

Actual source. Obviously not the front-end GUI, just the GPL required parts where delivered. If you are talking writing a new FPGA bitstream, in time, why not? The zynq's bitstream shouldn't be too hard, it's mostly the front-end stuff that lives there, display engine etc. The Kintex 7 is the hard one, as that takes in the info from the custom ADC and does all of the hardware processing. The spartan 6 is just a 'manager' to route and control everything on the board.

While we could start a lot of work with Vivado, I'd hold out for the OSS first; but people have itches to scratch right The interfaces are likely not to change anyway, e.g. an open source variant would remain compatible with the software interfaces for a long time. And the hardware interfaces, well those are not going to change really :p E.g. any future software would want to be able to talk to, and work with, either the old bitstream or the OSS bitstream.

[tom66]

Well, the GPL stuff is not that useful, but it is a start.

First thing to do is get the scope booting your custom user application and you could start with Kintex & Spartan using existing bitstream.  You might be able to learn a fair bit by seeing what addresses the application hits.  If the scope runs Linux, then it will be easier, because the kernel will not normally allow memory access to private addresses, I can't recall how it is done on Zynq but there may be some hypervisor or special user that has permissions. Or Rigol just run everything as root .

I suspect their choice of Zynq means the Zynq is doing some custom waveform plotting or management of acquisition control stuff.  It's a good fabric & SoC especially for the money but you wouldn't include it if you didn't really need it, and there are plenty of ways to get data into non-FPGA SoCs quickly, e.g. camera interface as I discovered.   

If they use standard Vivado configuration you might be able to get some interesting results by pinging at the common register addresses of 0x43c0 yyyy,  then 0x404x yyyy onwards.  (yyyy = 64k space, x = segment).  Most peripherals have an ID register available.  Chances are it's semi- or fully-custom Rigol IP though so there may not be too much to poke at without serious reverse engineering or completely redoing it.

[nctnico]

AFAIK reverse engineering an existing DSO has been done many times but never resulted in a product. I think the guys who reverse engineered the Welec W2000A oscilloscope got the furthest (and seem to be still at it) https://sourceforge.net/projects/welecw2000a/

[oliv3r]

We're not talking about writing a full scope from the ground up We could, but its more about development (The scope is still a cool hacking platform, when using it for non-scope task) it's 'plain old linux' making it much easier, we got the sources bootloader and kernel, so we 'know' how the interfaces work.

@tom666 read the links in the starting post and you'll get all your questions answered

[mabl]

Very cool initiative! So what is the near future plan? First run a more modern linux version? Getting network boot to work? Maybe find a good way to sniff what appEntry does?

[macaba]

As a proof of concept, earlier this year I got a custom UI to run on the MSO5k. Getting/setting the state of the front panel is easy enough, it’s the FPGA comms that are an unknown at this point and it’s beyond my current skills to rewrite a FPGA personality. (Would be good to get a proper n-bit mode with clearer indication of the resulting bandwidth reduction)

I will keep an eye on this with the hope that a FPGA expert will be inspired to get involved.

[oliv3r]

Very cool initiative! So what is the near future plan? First run a more modern linux version? Getting network boot to work? Maybe find a good way to sniff what appEntry does?

Near future? just documenting stuff, playing with things to learn how things work. E.g. sprite_tm's pr_boom. I'll work better on documentation (I have a collection of X-ray's of the PCB's for example that helps a lot here

The first few items on my todo (short-ish) term, is clean up the linux kernel (figure out what patches where added from upstream, what rigol wrote, as it's a bit messy, u-boot was much cleaner.

Then slightly longerish term, I want to get U-Boot mainline working. First without their hacks, then slowly adding the needed stuff. I have an arty z7 with the exact same SoC here, which helps a lot with that. In parallel, I want to RE the goldfinger pins and make a PCB for it. I still have to document it, but GoldFinger is a headre on the PCB, where 'something' is connected in the form of QSPI. I plan to put a simple SPI chip on there, and run a pair of remote programming wires, so i can reflash it outside of the board. Need to figure out how to drive and power it, but I'll ask those questions on the forum :p But how is the gold-finger useful? Well the spartan6 CPLD (fpga) functions as a CS mux. By switching the mux, you can (reboot) to the QSPI from the goldfinger, without having to worry about the onboard flash. So 'dual-boot' if you will. As the spartan6 looses all memory on power-off (it reprograms itself from the eeprom, but changing parameters/values which are not persisted, are lost after a power cycle).

One good reason to use our own (mainline feature rich and cleaned up) U-Boot is, it looses compatibility with the rigol updater (we can do something better of course following the same paradime). Two upsides, faster boot times (there are busy-wait 'sleep' loops during boot up that sit their changing the front-panel leds and wait a bit, to make sure you've seen them :p) and avoid that rigol can actually 'upgrade' U-boot (well make it really hard, they could still magically pull it of from linux, e.g. boot initramfs with SPI support, update u-boot, switch back to nand)

[mensi]

I've been casually playing around with my MSO5074 and have reached a point where I might have one or the other new thing I haven't seen here or in the hacking thread:

• Running the binaries from the extracted firmware under qemu
• A tiny bit of experimentation with NFS
• Implementing a frame buffer dumper in rust that can dump the different layers and take screenshots

I took notes while going along: https://mensi.ch/blog/tags/mso5000. Some of this stuff is also a bit of an excuse to play around with rust - I'm playing with the thought of maybe experimenting with what a good web UI could look like - Rigol's approach seems to be an ultra scrappy SCPI thing in Javascript via websocket bridge.

Has anyone done any reverse engineering on the whole "communicate with the FPGA" aspect? I presume it is some sort of AXI DMA thing?

[oliv3r]

Hey Mensi,

yeah it's all standard stuff, as we have access to the kernel sources now, there's not much special there.

I just read your blog, nice stuff there It was interesting seeing your adventure into decoding the GEL file. I wish I knew back then you where trying this, as you seem to have missed https://gitlab.com/riglol/rigolee/firmware/-/blob/MSO5000/bin/gel_unpack.sh  :p and the README in that repo