SDS1104X-E custom splash screen - Page 1
Forum section: electronics / testgear

author: Piorski
author_rank: Newbie
timestamp: September 16, 2020, 07:55:08 pm
content: I've wanted to find a way to change the boot screen on my Siglent SDS1104X-E for a while now and yesterday I decided to finally sit down and try my best to do it.I did get it to work, but I'm fairly certain there is an easier way that I can't get to work properly, so if anyone could tell me if there's some obvious thing I'm doing wrong I'd greatly appreciate it.Ok, so the logo is an 800x480 24bpp bitmap stored in the NAND chip at addres 0xC00000, it takes up a little over a meg, but 5 megabytes are allocated for it. I got the address and size info from the sds1004x_e_usidkEnv.txt file included in the OS v1 update archive:Code:upu=echo ===================uboot(BOOT.bin)====================;if fatload usb 0 0x100000 UBOOT.bin; then nand erase 0x00 0x780000;nand write 0x100000 0x00 ${filesize};mw.b 0x100000 0x0 ${filesize}; fiupk=echo ===================kernel(uImage)=====================;if fatload usb 0 0x100000 uImage; then nand erase 0x780000 0x400000;nand write 0x100000 0x780000 ${filesize};mw.b 0x100000 0x0 ${filesize}; fiupd=echo ===================devicetree(devicetree.dtb)=========;if fatload usb 0 0x100000 devicetree.dtb; then nand erase 0xB80000 0x80000;nand write 0x100000 0xB80000 ${filesize};mw.b 0x100000 0x0 ${filesize}; fiupl=echo ====================logo(logo.bmp)====================;if fatload usb 0 0x100000 logo.bmp; then nand erase 0xC00000 0x500000;nand write 0x100000 0xC00000 ${filesize};mw.b 0x100000 0x0 ${filesize}; fiupr=echo =============rootfs(rootfs.cramfs)====================;if fatload usb 0 0x100000 rootfs.cramfs; then nand erase 0x1600000 0x2800000;nand write 0x100000 0x1600000 ${filesize};mw.b 0x100000 0x0 ${filesize}; fiupf0=echo =============firmdata0(firmdata0.img)==============;if fatload usb 0 0x100000 firmdata0.img; then nand erase 0x3E00000 0xA00000;nand write 0x100000 0x3E00000 ${filesize};mw.b 0x100000 0x0 ${filesize}; fiups=echo =============siglent(siglent.img)===================;if fatload usb 0 0x100000 siglent.img; then nand erase 0x4800000 0x2800000;nand write 0x100000 0x4800000 ${filesize};mw.b 0x100000 0x0 ${filesize}; fiupdf=echo =============datafs(datafs.img)=====================;if fatload usb 0 0x100000 datafs.img; then nand erase 0x7000000 0x6400000;nand write 0x100000 0x7000000 ${filesize};mw.b 0x100000 0x0 ${filesize}; fiuenvcmd=run upk; run upd; run upl; run upr; run ups; run updf;Using the syntax of this file I found out it's a config file for U-Boot, a kernel bootloader. I guess Siglent customized their U-Boot to search for sds1004x_e_udiskEnv.txt instead of the usual uEnv.txt.I wanted to save the default splash screen before any further tests to have something to fallback on. Since U-Boot is doing all the NAND flashing my first thought was to use it to read it too. From what I understand, U-Boot will stop booting the kernel and start its own shell when it detects a character sent over UART during boot, but my oscilloscope is still sealed (and technically I still have some warranty left, although I guess I've already voided it anyway) so I didn't want to open it up and search for a header on the motherboard. Luckily I found out I can access the NAND straight from Linux.Because I'm still running the .26 firmware I can run SHELLCMD from the web SCPI interface, so withCode:SHELLCMD telnetd -l/bin/sh -p9999I could telnet into the 'scope. I found 'nanddump', 'nandtest' and 'nandwrite' in /usr/sbin, but before running them I did a little bit of research and found a discussion about a whole different Siglent product where someone claimed to have analyzed those tools: "this is the stuff that formats and overwrites flash - even nandtest (I dumped the binary and started to disassemble) doesn't look safe", so I kept on looking.Then I found out that this type of straight up NAND without a controller is handled by the mtd subsystem, which exposes it as character devices in /dev/mtd*. The configuration is stored in /proc/mtd:Code:/ # cat /proc/mtddev: size erasesize namemtd0: 00780000 00020000 "fsbl"mtd1: 00400000 00020000 "kerneldata"mtd2: 00080000 00020000 "device-tree"mtd3: 00500000 00020000 "Manufacturedata"mtd4: 00500000 00020000 "reserved1"mtd5: 02800000 00020000 "rootfs"mtd6: 00a00000 00020000 "firmdata0"mtd7: 02800000 00020000 "siglent"mtd8: 06400000 00020000 "datafs"mtd9: 02800000 00020000 "upgrade_cramdisk"mtd10: 00400000 00020000 "reserved2"So /dev/mtd3 is mapped to the memory range I'm interested in. Using mtd_debug I captured an image of /dev/mtd3ro (I thought using the read-only device would be safer, but I guess it doesn't matter) and transferred it to a USB drive. It was indeed the splash screen, an 800x480 24bpp bmp,attached here as mtd3ro.hex (with all the trailing ones that don't really matter, also the forum doesn't list bmp as a supported file extension so I changed it to .hex to make sure it uploads correctly)Max attachment size is 5000kB, so I've attached the truncated version instead.I've prepared my own logo.bmp using gimp, making sure "Do not write color space information" under "Compatibility Options" is checked. From what I've seen all it takes to update the OS is to copy the sds1004x_e_udiskEnv.txt and the OS files we want to flash to a usb drive, insert it into the USB port and restart the oscilloscope. On the next power on, U-Boot should check which of the files are available and flash the ones that are.Unfortunately this didn't work.I've tried different thumb drives, as the OS update instructions make it very clear you should only use 8GB or 32GB drives (they state it two times, both in red), so I guess it's some U-Boot quirk. My 16GB USB3.0 drive didn't work, another 16GB, this time USB2.0, also didn't work. I tried a USB2.0 to microSD adapter with an 8GB card and it also didn't work. The next day I went out and bought a 32GB USB2.0 drive, which also didn't work. (The drives were all FAT32, so it's not that either. Oh, and also the actual embedded Linux has no problem with any of them). The OS update instructions also state that you should plug in the drive when the oscilloscope is turned off, but I've tried it every which way and it didn't work. I've even tried using the other USB port, but with the way U-Boot enumerates USB devices it didn't matter.I managed to flash it manually using mtd_debug.After cd-ing to /usr/bin/siglent/usr/mass_storage/U-disk0/ I tried to mtd_debug erase mtd3 and then write to it, but trying to erase 1152056 (0x119438) bytes didn't work. Erase can only work with multiples of erasesize, it seems, which, according to /proc/mtd, is 00020000 (that's a hex number), so to erase I ranCode:mtd_debug erase /dev/mtd3 0x0 0x200000which erased more than enough of the NAND to fit the new bitmap. Trying to mtd_debug write the 0x119438 bytes also failed, so I padded the file to a multiple of 8192 bytes. I'm a bit hazy on where exactly I got this value from, as it was 5 in the morning when I did, and chrome browsing history apparently really sucks, but I remember getting something along the lines ofCode:file_to_flash()write(): Invalid argumentand reading the mdt_debug source. So anyway, after padding the bmp to 141*8192 bytes it worked:Code:mtd_debug write /dev/mtd3 0x0 0x11A000 logo.bmpI rebooted and saw my custom boot screen, which was nice, but I wanted to get the simpler usb method working. Obviously I tried doing the same thing as before but with the padded logo.bmp (and just now I even tried padding it to 9*0x20000 bytes, no dice). I looked around and someone in another thread here complained that he can't upgrade the OS to the patched version with a known password despite doing everything right and it turned out that somehow copying the files to the USB drive using Ubuntu 18.10 made them invisible for U-Boot, but doing the same from a Raspberry Pi solved the problem. I tried formatting the usb drive and uploading the files all on my Raspberry Pi and it still didn't work, so then I tried doing the same from a Windows 10 installation and it didn't work either. At this point I've even tried copying over the other OS update files, editing the sds1004x_e_udiskEnv.txt to only flash logo.bmp and probably other things I can't remember right now but I don't even know if the OS update is going through (I updated the OS when I got the 'scope in May '19, so I don't even remember how long an update is supposed to take and re-uploading OSv1 doesn't change anything in the info screen).I suppose I can try patching my own OSv1 upgrade or using the one that someone else made to see if the default telnet password changes to make sure the OS update mechanism is working for me, which would mean there's something else I'm doing wrong, but if anyone has any other suggestions please post them.Oh, if anyone found this thread because they are actually trying to to change the splash screen,here's the shortened version of the current way to do itwithout my rambling:-Either upload a patched OS with a known telnet password or just firmware .26 to enable SHELLCMD and run a second telnet server and login over telnet-Create an 800x480 24bpp bmp (without additional color information, if you're using GIMP) and then pad it so that it is a multiple of 8192 bytes (it should be a little less than 141*8192 bytes before padding, in my case it took 3016 bytes to align it properly)Code:dd if=/dev/zero bs=1 count=3016 >> logo_trunc.bmp-Either use the tftp available on the 'scope (there's >100MB of free space in /tmp) or simply a USB stick to transfer the new logo to your oscilloscope-flash it to the NANDCode:mtd_debug erase /dev/mtd3 0x0 0x200000mtd_debug write /dev/mtd3 0x0 0x11A000 /usr/bin/siglent/usr/mass_storage/U-disk0/logo.bmp-Reboot the scope and marvel at your new boot screen :-)

author: xottal
author_rank: Newbie
timestamp: October 14, 2022, 07:22:02 pm
content: Hi!I've successfully updated splash screen on SSA3021X+ (actually crossflashed to SVA1032X). Your instructions were okay, but i would like to mention some points:1. It's much easier to create image using bmp export in Gimp with R8 G8 B8 color scheme and with not saving data about color. We will get a image with size 0x1C2036.2. To cut it to 0x1C2000 I used this tool:https://hexed.it/. Just by removing last 36 bytes. So we will get the file size exactly 1 843 200 bytes.3. So, flashing:First of all erase:Code:mtd_debug erase /dev/mtd3 0x0 0x200000Screen image is 1024*600 pixels. Therefore we need now 0x1C2000 writing length in mtd3. So to flash:Code:mtd_debug write /dev/mtd3 0x0 0x1C2000 /usr/bin/siglent/usr/mass_storage/U-disk0/Test.bmpThat's it.P.S. I didn't managed to upload image with size 0x1C4000. Screen is blank on startup.

author: meowster
author_rank: Newbie
timestamp: November 30, 2023, 07:59:27 pm
content: Hi all!The much simpler approach works on my SDS1104x-e.1. Download the SDS1xx4X-E Operating System -V3 (Only For 4-Channel models) (Release Date 01.04.23 ) from siglent's site2. Unzip contents and remove everything but sds1004x_e_udiskEnv.txt3. Add your logo.bmp in this directory. As noted above, it must be 800x480 and 24bpp.4. Format a usb drive as FAT32, and add these two files (logo.bmp and sds1004x_e_udiskEnv.txt) to the empty drive.5. Plug into siglent front IO while off, and boot. The boot process should be extra long.6. Once fully booted, remove usb. And reboot.7. You should see your custom splash screen