I managed to flash it manually using mtd_debug. I've even tried using the other USB port, but with the way U-Boot enumerates USB devices it didn't matter.
U BOOT SPLASH UPDATE
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. Oh, and also the actual embedded Linux has no problem with any of them). (The drives were all FAT32, so it's not that either. The next day I went out and bought a 32GB USB2.0 drive, which also didn't work. I tried a USB2.0 to microSD adapter with an 8GB card and it also didn't work. My 16GB USB3.0 drive didn't work, another 16GB, this time USB2.0, also 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. On the next power on, U-Boot should check which of the files are available and flash the ones that are. 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. I've prepared my own logo.bmp using gimp, making sure "Do not write color space information" under "Compatibility Options" is checked. hex to make sure it uploads correctly) Max attachment size is 5000kB, so I've attached the truncated version instead.
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. 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. Luckily I found out I can access the NAND straight from Linux. 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. Since U-Boot is doing all the NAND flashing my first thought was to use it to read it too. I wanted to save the default splash screen before any further tests to have something to fallback on. I guess Siglent customized their U-Boot to search for sds1004x_e_udiskEnv.txt instead of the usual uEnv.txt. That would be getting too much into the details of hand-emulating a guest BIOS, and we'd prefer to provide that functionality by just running an actual guest BIOS blob.Code: upu=echo =uboot(BOOT.bin)= if fatload usb 0 0x100000 UBOOT.bin then nand erase 0x00 0x780000 nand write 0x100000 0x00 $ fi uenvcmd=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. QEMU doesn't have any way of saying "load the guest image from this block of the disk". (qemu-system-x86_64 works like the -bios option approach you just don't notice because the -bios option is enabled by default and loads the bios image from a system library directory.) Some board models don't support -bios. The first is a convenient shortcut the second is like how the hardware actually boots. The "bios" here could be u-boot or UEFI or something similar.
U BOOT SPLASH HOW TO
specify a guest BIOS using the -bios option (or some -pflash option) the bios then boots and knows how to read the kernel off the emulated disk.specify a guest kernel directly with -kernel, which then boots and knows how to talk to the emulated disk.
U BOOT SPLASH CODE
The below rules of thumb may or may not apply for a particular QEMU machine model.įor running QEMU guest code you can generally either: Your command line doesn't specify a particular machine model, which isn't valid for qemu-system-arm.
0 kommentar(er)
