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

0 Members and 3 Guests are viewing this topic.

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #325 on: December 24, 2018, 07:16:38 pm »
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).

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #326 on: December 24, 2018, 07:22:24 pm »
If someone could be so kind as to get me a mtd0 dump, I can poke there a little.

By your command.
 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #327 on: December 24, 2018, 07:31:41 pm »
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

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
GPL Violations?
« Reply #328 on: December 24, 2018, 07:37:08 pm »
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 ...

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #329 on: December 24, 2018, 08:41:40 pm »
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.

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #330 on: December 25, 2018, 11:47:01 am »
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).
« Last Edit: December 25, 2018, 11:49:44 am by oliv3r »
 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #331 on: December 25, 2018, 12:03:22 pm »
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).

Offline FireBird

  • Regular Contributor
  • *
  • Posts: 68
  • Country: at
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #332 on: December 25, 2018, 01:41:01 pm »
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).
 

Offline bitwelder

  • Frequent Contributor
  • **
  • Posts: 964
  • Country: fi
Re: GPL Violations?
« Reply #333 on: December 26, 2018, 08:30:03 am »
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?
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #334 on: December 26, 2018, 10:26:17 am »
They only have to provide the sourcecode (of the GPL'ed parts) if they modified it.
Maybe they use unmodified GPL'ed software.
 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #335 on: December 26, 2018, 11:12:51 am »
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.
« Last Edit: December 26, 2018, 11:14:57 am by oliv3r »
 

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #336 on: December 26, 2018, 11:49:52 am »
Dump of MSO5074 NAND for anybody that's interested...

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

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #337 on: December 26, 2018, 12:05:12 pm »
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.
 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #338 on: December 26, 2018, 12:26:53 pm »
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 :(
« Last Edit: December 26, 2018, 12:31:07 pm by oliv3r »
 

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #339 on: December 26, 2018, 12:30:13 pm »

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!
 
The following users thanked this post: thm_w, Kean, oliv3r

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #340 on: December 26, 2018, 12:37:25 pm »
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?

 

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #341 on: December 26, 2018, 01:40:29 pm »

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


 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #342 on: December 26, 2018, 01:50:39 pm »
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 :D

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? :)

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #343 on: December 26, 2018, 01:59:21 pm »

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
« Last Edit: December 26, 2018, 02:28:16 pm by oliv3r »
 

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #344 on: December 26, 2018, 02:02:31 pm »
Help? Been there done that....

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

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #345 on: December 26, 2018, 02:06:39 pm »
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!


 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #346 on: December 26, 2018, 02:18:52 pm »
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)

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #347 on: December 26, 2018, 02:24:14 pm »
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.
 

Offline oliv3r

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: nl
    • Rigol related stuff!
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #348 on: December 26, 2018, 02:29:06 pm »
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

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #349 on: December 26, 2018, 05:22:47 pm »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf