Rigolup Source Code?

[nbritton]

Where can I find the rigolup source code? I'd like to compile it for the Mac.

[bitwelder]

Check at the bottom of http://gotroot.ca/rigol/riglol/ page

[ebastler]

So "riglol" = "rigolup"? Or were you talking about something else?
I had wondered what the "rigolup" software is; doesn't ring a bell for me.

[awallin]

out of curiosity, does anyone have actual measurement data on e.g. the bandwidth of an oscilloscope before and after applying these codes?
for example DS2000 transformation from 70 MHz to 300 MHz would be interesting to see!

As mentioned somewhere previously Rigol must be letting this happen at least partly on purpose to boost sales - surely there are encryption-schemes out there that would be really hard to unlock if the manufacturer really wanted?

[krivx]

As mentioned somewhere previously Rigol must be letting this happen at least partly on purpose to boost sales - surely there are encryption-schemes out there that would be really hard to unlock if the manufacturer really wanted?

Sure, but it's a tradeoff between what is easy/fast/cheap to implement and the value of a more secure system.

[bson]

A secure on-chip NOR boot loader that deciphers an executable is super simple to implement, bordering on trivial.  The main problems are:

1. it's a lot easier to brick a device, resulting in more warranty returns
2. once the Windows or Linux kernel is booted *it* has no idea how to check signatures or decipher anything; if it needs to do this it will have to make calls to the on-chip firmware for these functions, which means lots of specialized kernel knowledge how to even make that firmware appear in the kernel address space.  The latter especially since the firmware will be non-read execute-only and may not run with caching enabled (since the cache may not honor execute-only).  In addition, the driver needs to be tied into the kernel's exec code path, which doesn't have a whole lot of hooks, which in practice means implementing your own signature-checking/deciphering file system.  I think WinCE has a secure boot feature, but undoubtedly MS charges an arm and a leg for it, and on top of that imposes certain system design limitations that makes it impractical (may not work on ARM/MIPS for instance).  For sector-level encryption you need twice the NAND flash since the risk of bricking means upgrades have to use partition flipping schemes.  (Which adds cost and/or board real estate.)

The basic, simple boot loader turns into a gnarly, messy, second-guessing problem that undoubtedly will have its share of bugs.  (Which may cause the device to brick or allow circumvention.)

[ebastler]

out of curiosity, does anyone have actual measurement data on e.g. the bandwidth of an oscilloscope before and after applying these codes?
for example DS2000 transformation from 70 MHz to 300 MHz would be interesting to see!

I don't know about the DS2000, but for the DS1000Z, measurement data are buried somewhere in the long monster thread. The bandwidth increase is real -- and why shouldn't it be? The pre-amp has an electronically switchable bandwidth; the mainboard is the same for all scope models, with all components for the different bandwidth configurations present. A suitable combination is selected by the firmware depending on the model code. For the DS1000Z, if I recall correctly there are two different caps which can be switched in or out in 2^2 combinations.

[Fohdeesha]

out of curiosity, does anyone have actual measurement data on e.g. the bandwidth of an oscilloscope before and after applying these codes?

For the ds1000z series, I remember at least 3 separate individuals making measurements after the unlock in the megathread. The lowest one I remember was the -3db point at 117mhz, another was over 120mhz

[MarkF]

out of curiosity, does anyone have actual measurement data on e.g. the bandwidth of an oscilloscope before and after applying these codes?
for example DS2000 transformation from 70 MHz to 300 MHz would be interesting to see!

I don't know about the DS2000, but for the DS1000Z, measurement data are buried somewhere in the long monster thread. The bandwidth increase is real -- and why shouldn't it be? The pre-amp has an electronically switchable bandwidth; the mainboard is the same for all scope models, with all components for the different bandwidth configurations present. A suitable combination is selected by the firmware depending on the model code. For the DS1000Z, if I recall correctly there are two different caps which can be switched in or out in 2^2 combinations.

Some DS1000Z bandwidth measurements from the "Sniffing the Rigol's internal I2C bus" thread:

Reply #3259
"I measured an upgraded 1074 ( with Marconi sig.gen. 2019a, level -20 dBm)
     10 Mhz  0 db
     70 Mhz -1.1
     80 Mhz -1.5
     90 Mhz -1.7
   100 Mhz -2.0
   110 Mhz -2.4
   120 Mhz -2.7 counter still working
   130 Mhz -3.0 counter not working
   160 Mhz -4.0
   200 Mhz -5.4
   300 Mhz -10 dB
   400 Mhz -16 dB"

Reply #3265
  "DS1074Z = 90 MHz
   DS1104Z = 125MHz"

Reply #3646
"MSO1104Z measured BW
   -3dB :   155 MHz
   -6dB :   280 MHz
   -9dB :   380 Mhz"