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?
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.
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?
<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)
<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
<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
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.
Re. logo screen: as there wasn’t any reply, I guess there isn’t such an information available yet. Or nobody is interested. Anyway…
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
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 ..."
Rigol is talking in their update script about app A and B. All app A blocks are empty.
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.
.....
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?
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?
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
Code: [Select]mtd1: 04000000 00020000 "DATA" ; UBI FS -> /rigol/data
Code: [Select]mtd2: 00400000 00020000 "Bmp" ; unused FF
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
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
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
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.
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 ...
[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>
Is all options != 350mhz? It almost seems like it’s 500mhz ?
I had seen rumors of making it run at 1ghz?
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.
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?
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 processCode: [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>