Author Topic: Hacking the DSO2X1X (Read 140069 times)

tttonyyy · « **Reply #125 on:** June 13, 2021, 04:52:33 pm »

This is all fascinating progress, which leaves me itching to fiddle with the innards of mine. But mine is working OK for me (aside from the awful triggering on slopes) so I'm reluctant to mess it up since I'm actually using it for work.

The comments about lack of a FPU, as an ex-Ti DSP algorithm optimiser I'm like, "these kids and their floating point... back in my day we used fixed point and were forced to love it!" lol

AndrewBCN · « **Reply #126 on:** June 13, 2021, 05:04:16 pm »

Quote from: tttonyyy on June 13, 2021, 04:52:33 pm

This is all fascinating progress, which leaves me itching to fiddle with the innards of mine. But mine is working OK for me (aside from the awful triggering on slopes) so I'm reluctant to mess it up since I'm actually using it for work.

The comments about lack of a FPU, as an ex-Ti DSP algorithm optimiser I'm like, "these kids and their floating point... back in my day we used fixed point and were forced to love it!" lol

I would suggest waiting until there is a 100% fool-proof, simple way to backup the firmware and restore it, and to test communicate with the Linux kernel using the USB OTG interface (the USB port on the back).

Yeah, no FPU, but there are DSP instructions.

I think people who are complaining about the lack of FPU or overclocking are missing the point: does this $1.40 (!) SOC perform adequately for the intended purpose at the default settings? It seems yes, and the programmers at Hantek should focus first on fixing the remaining bugs in future firmware updates.

Make it work, make it right, make it fast.
-- Kent Beck

AndrewBCN · « **Reply #127 on:** June 13, 2021, 06:32:12 pm »

I have recompiled again sunxi-tools, this time by editing fel-spiflash.c which is the program that read and writes to SPI flash; I have added the parameters for the Winbond W25N01GV which is found inside the Hantek DSO. Unfortunately I have ascertained that the original code is buggy and does not read or write correctly to flash, and I am not sure it ever did with the F1C200s SOC, no matter the SPI flash chip used. To debug that code would require many hours of investigation and programming, a 200MHz logic analyzer with an SPI protocol decoder and some surgery on the DSO mainboard, and I am just not going to do that, also I don't have the logic analyzer.

So that path to backup the DSO firmware is closed for the moment. Imo the best option is still to boot a functional u-boot + DTB + Linux kernel + root filesystem over USB OTG and use that to examine/read/write/backup the SPI flash.

I'll be quite busy this week so perhaps next weekend I'll dive into George Hilliard's Buildroot GitHub repository and try to make something out of it for the Hantek DSO.

DavidAlfa · « **Reply #128 on:** June 13, 2021, 11:39:27 pm »

Dude

. Don't take it too bad, but adding the chip ID is simply useless. The read/write algorithm is pretty different for spi nand.
Not a bug problem. For the SPI nor, you simply throw the read command and the address, and get the data.
For nand, you must fetch the nand page to the output buffer, wait for it to complete, then read the buffer.

Same for writing, for NOR you erase the block and write the data.
For NAND you have to erase the block, send data to the buffer, and send the programming command. And again wait.

That's what I've been doing. Almost working but there are strange bugs with the internal handler, sometimes it doesn't like sending comands.
I guess if it's a timing issue. I don't know but it's driving be mad!

Also, the spi nand as an OTP area. 10pages x 2048Bytes. I didn't check it the contents, but who knows.
As its name says, it's only one-time programmable. Who knows if hantek wrote some unique data there, like calibrations and such.

Other thing I've been trying is to buiild u-boot with usb support. But no way. The documentation is null, so guess what the *** is going on.
Why the hell they added options for sunxi/suniv, if when you enable them you get all kinf of "not defined" or "not implemented" errors

Edit: And now it seems the spi flash os gone. No matter what flash, the dso is dead. Will put the original memory back and bye!
I'm out of here. Burn all that chinese crap down!

AndrewBCN · « **Reply #129 on:** June 14, 2021, 06:44:25 am »

Quote from: DavidAlfa on June 13, 2021, 11:39:27 pm

Dude . Don't take it too bad, but adding the chip ID is simply useless. The read/wrire algorithm is pretty different for spi nand.
Not a bug problem. For the SPI nor, you simply throw the read command and the address, and get the data.
For nand, you must fetch the nand page to the output buffer, wait for it to complete, then read the buffer.

Same for writing, for NOR you erase the block and write the data.
For NAND you have to erase the block, send data to the buffer, and send the programming command. And again wait.

That's what I've been doing. Almost working but there are strange bugs with the internal handler, sometimes it doesn't like sending comands.
I guess if it's a timing issue. I don't know but it's driving be mad!

Yes, SPI NOR and NAND use different algorithms, but the JEDEC ID command is the same.
I was trying to get the chip ID recognized as a start. but not even that works, so at this stage sunxi-fel definitely cannot be used to read/write the SPI chip in this DSO.
And as I wrote, debugging the sunxi-fel code would require more work than I have the time for, and a good logic analyzer (that I don't have).

Quote from: DavidAlfa on June 13, 2021, 11:39:27 pm

Also, the spi nand as an OTP area. 10pages x 2048Bytes. I didn't check it the contents, but who knows.
As its name says, it's only one-time programmable. Who knows if hantek wrote some unique data there, like calibrations and such.

Other thing I've been trying is to buiild u-boot with usb support. But no way. The documentation is null, so guess what the *** is going on.
Why the hell they added options for sunxi/suniv, if when you enable them you get all kinf of "not defined" or "not implemented" errors

Edit: And now it seems the spi flash os gone. No matter what flash, the dso is dead. Will put the original memory back and bye!
I'm out of here. Burn all that chinese crap down!

You don't need u-boot with USB support. What you really want is a kernel with USB-OTG support, and George Hilliard's GitHub repository already has that.

Well, I guess now you have two choices, either solder another SPI chip to replace the dead one, or solder back the original chip and be done with it, and it seems to have chosen the latter option.

I understand your frustration, but unfortunately this is what hacking is all about: lots of failures and few victories, but many bloggers only report their successes. At least you have been very honest about everything you have achieved and I am very grateful to you for that.

DavidAlfa · « **Reply #130 on:** June 14, 2021, 06:58:52 am »

Nope, the jedec response is different.
While the nor answers from the 1st bit, in the nand the first bit is dummy. The original sunxi-fel code doesn't handle this.
What I do is to read 1 extra byte, check the 1st, if not valid check the 2nd, and start parsing. It works perfect.
Well, "what I need" is relative.
If uboot USB worked, I could set the env to automatically backup the spi. Simple.
Building Linux for a obscure, badly documented soc is a lot of work.

Don't get me wrong, I like hacking.
But also I hate losing my time.
And when the Linux building storm starts, I prefer to spend my time elsewhere.
I'm not used yo compiling kernels, every little crappy code drops errores and I have to ask Google , the fu*** dependencies, or strange build flags, exports...
I'll take the sleep-forever pill thanks!

AndrewBCN · « **Reply #131 on:** June 14, 2021, 07:33:19 am »

Quote from: DavidAlfa on June 14, 2021, 06:58:52 am

Nope, the jedec response is different.
While the nor answers from the 1st bit, the nand the first bit is dummy. The original sunxi-fel code doesn't handle this.
What I do is to read 1 extra byte, check the 1st, if not valid check the 2nd, and start parsing. It works perfect.

Actually if you check the datasheet what it says is that the JEDEC ID command is followed by 8 "dummy" clock cycles for the NAND. But you are right that the original sunxi-fel code does not handle this. In fact, it is missing most of the code to make reading/writing to SPI NAND possible, which is the reason I concluded that trying to use sunxi-fel and the BROM environment to read/write/backup the DSO firmware is NOT the right way.

Quote from: DavidAlfa on June 14, 2021, 06:58:52 am

Well, "what I need" is relative.
If uboot USB worked, I could set the env to automatically backup the spi. Simple.
Building Linux for a obscure, badly documented soc is a lot of work.

Don't get me wrong, I like hacking.
But also I hate losing my time.
And when the Linux building storm starts, I prefer to spend my time elsewhere.
I'm not used yo compiling kernels, every little crappy code drops errores and I have to ask Google , the fu*** dependencies, or strange build flags, exports...
I'll take the sleep-forever pill thanks!

Actually for embedded systems most people use BuildRoot to build u-boot, the DTB and Linux kernel and a root filesystem. which is why I suggested you take a look at George Hilliard's GitHub repository. I have since found two more GitHub repositories with BuildRoot configurations for the F1C100s.

BuildRoot actually even builds gcc and the needed libraries if configured to do so, it really simplifies the build process.

DavidAlfa · « **Reply #132 on:** June 14, 2021, 09:21:44 am »

Following the datasheets:

W25Q64 (NOR)
[0x9F] [vendor] [model] [size]

W25N01GV (NAND)
[0x9F] [dummy] [vendor] [model] [size]

Sunxi-fel is simply old and poorly maintained, didn't implement the SPI NAND(These are relatively new memories, I didn't knew they existed).
At least in my version, it didn't gave a f*** aboot was actually connected, hardcoding the memory type in "default_spi_flash_info".
That was the first changes I made. Detecting the memory before any operation.
For now I stopped that path. It's very slow and messy to work with. At very best 150KB/s with NOR, but 1/3 of that with NAND since it needs for commands.

Now I'm looking into this: http://linux-sunxi.org/Miniroot

That would be great. A simple miniroot environment, Build with the enought to support SPI and USB.

I don't know what happened with the SPI. It programmed ok with the CH341A. I guess I fucked something up while sending commands to the SPI.
I guess that the Hantek fastboot doesn't check write protection at all. WIl lsolder it back and try.

Does anyone have a nice camera? Would be great to have high resolution scans of the board. My phone camera freaks out with black pcbs...

AndrewBCN · « **Reply #133 on:** June 14, 2021, 10:20:23 am »

Quote from: DavidAlfa on June 14, 2021, 09:21:44 am

...

Now I'm looking into this: http://linux-sunxi.org/Miniroot

...

From the page you linked to:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- KERNEL_MODULES=/path/to/kernel/INSTALL_MOD_PATH

That won't work: wrong compiler. We have an ARM926EJ-S CPU, it doesn't have (as far as I know) hardware floating point.

I suggest you look into buildroot and base yourself on the previous work in three different github repositories that got buildroot working on the F1C100s / Lichee Pi Nano months ago.

You may find that this will save you hours of work and lots of headaches...

DavidAlfa · « **Reply #134 on:** June 14, 2021, 10:38:57 am »

What's the problem? Use arm-linux-gnueabi.
arm-linux-gnueabihf is for lichee pi zero (Which has FP).

The memory programmed correctly and the dso is alive again.
I disassemble everything, I'm trying to find all gpio input/outputs.

I found the kernel modules in lib/modules/3.10.65/modules.builtin

Quote

kernel/fs/binfmt_script.ko
kernel/fs/mbcache.ko
kernel/fs/configfs/configfs.ko
kernel/fs/ext4/ext4.ko
kernel/fs/fat/fat.ko
kernel/fs/fat/vfat.ko
kernel/fs/jbd2/jbd2.ko
kernel/fs/nls/nls_base.ko
kernel/fs/nls/nls_cp437.ko
kernel/fs/nls/nls_iso8859-1.ko
kernel/fs/overlayfs/overlayfs.ko
kernel/crypto/crypto.ko
kernel/crypto/crypto_wq.ko
kernel/crypto/crypto_algapi.ko
kernel/crypto/crypto_blkcipher.ko
kernel/crypto/chainiv.ko
kernel/crypto/eseqiv.ko
kernel/crypto/crypto_hash.ko
kernel/crypto/aes_generic.ko
kernel/crypto/arc4.ko
kernel/crypto/crc32c.ko
kernel/crypto/rng.ko
kernel/crypto/krng.ko
kernel/block/cfq-iosched.ko
kernel/drivers/base/firmware_class.ko
kernel/drivers/base/regmap/regmap-i2c.ko
kernel/drivers/base/regmap/regmap-spi.ko
kernel/drivers/char/dump_reg/dump_reg.ko
kernel/drivers/char/sunxi-sysinfo/sysinfo.ko
kernel/drivers/dma/virt-dma.ko
kernel/drivers/dma/sun3i-dma.ko
kernel/drivers/gpio/gpio-pcf857x.ko
kernel/drivers/hid/hid.ko
kernel/drivers/hid/usbhid/usbhid.ko
kernel/drivers/i2c/i2c-core.ko
kernel/drivers/i2c/busses/i2c-sunxi.ko
kernel/drivers/input/input-core.ko
kernel/drivers/input/input-polldev.ko
kernel/drivers/input/evdev.ko
kernel/drivers/input/keyboard/sunxi-keyboard.ko
kernel/drivers/input/serio/serio.ko
kernel/drivers/input/serio/serport.ko
kernel/drivers/input/serio/libps2.ko
kernel/drivers/media/cedar-ve/cedar_ve.ko
kernel/drivers/media/v4l2-core/videodev.ko
kernel/drivers/media/v4l2-core/v4l2-common.ko
kernel/drivers/mmc/core/mmc_core.ko
kernel/drivers/mmc/host/sunxi-mmc.ko
kernel/drivers/mmc/host/sunxi-mmc-debug.ko
kernel/drivers/mmc/host/sunxi-mmc-export.ko
kernel/drivers/mmc/host/sunxi-mmc-v4p1x.ko
kernel/drivers/mmc/host/sunxi-mmc-v4p00x.ko
kernel/drivers/mmc/host/sunxi-mmc-v4p10x.ko
kernel/drivers/mmc/host/sunxi-mmc-v4p5x.ko
kernel/drivers/mtd/mtd.ko
kernel/drivers/mtd/sunxipart.ko
kernel/drivers/mtd/mtd_blkdevs.ko
kernel/drivers/mtd/mtdblock.ko
kernel/drivers/mtd/chips/chipreg.ko
kernel/drivers/mtd/devices/m25p80.ko
kernel/drivers/net/mii.ko
kernel/drivers/of/of_i2c.ko
kernel/drivers/pwm/pwm-sunxi.ko
kernel/drivers/rtc/rtc-cmos.ko
kernel/drivers/rtc/rtc-pcf8563.ko
kernel/drivers/scsi/scsi_mod.ko
kernel/drivers/scsi/sd_mod.ko
kernel/drivers/spi/spidev.ko
kernel/drivers/spi/spi-sunxi.ko
kernel/drivers/tty/serial/serial_core.ko
kernel/drivers/tty/serial/sunxi-uart.ko
kernel/drivers/usb/usb-common.ko
kernel/drivers/usb/core/usbcore.ko
kernel/drivers/usb/gadget/udc-core.ko
kernel/drivers/usb/host/ehci-hcd.ko
kernel/drivers/usb/host/sunxi_hci.ko
kernel/drivers/usb/storage/usb-storage.ko
kernel/drivers/usb/sunxi_usb/sunxi_usb_hcd0.ko
kernel/drivers/usb/sunxi_usb/sunxi_usbc.ko
kernel/drivers/video/fb.ko
kernel/drivers/video/cfbfillrect.ko
kernel/drivers/video/cfbcopyarea.ko
kernel/drivers/video/cfbimgblt.ko
kernel/drivers/video/sunxi/disp/disp/disp.ko
kernel/drivers/video/sunxi/disp/lcd/lcd.ko
kernel/sound/soundcore.ko
kernel/sound/core/snd.ko
kernel/sound/core/snd-timer.ko
kernel/sound/core/snd-pcm.ko
kernel/sound/core/snd-page-alloc.ko
kernel/sound/core/snd-compress.ko
kernel/sound/soc/snd-soc-core.ko
kernel/sound/soc/sunxi/sun3iw1_codec.ko
kernel/sound/soc/sunxi/sunxi_cpudai.ko
kernel/sound/soc/sunxi/sun3iw1_sndcodec.ko
kernel/net/ipv4/ip_tunnel.ko
kernel/net/ipv4/ipip.ko
kernel/net/ipv4/gre.ko
kernel/net/ipv4/ip_gre.ko
kernel/net/ipv4/tunnel4.ko
kernel/net/ipv4/tcp_cubic.ko
kernel/net/ipv4/netfilter/ip_tables.ko
kernel/net/ipv4/netfilter/iptable_filter.ko
kernel/net/key/af_key.ko
kernel/net/netfilter/x_tables.ko
kernel/net/netfilter/xt_tcpudp.ko
kernel/net/packet/af_packet.ko
kernel/net/unix/unix.ko
kernel/net/wireless/cfg80211.ko
kernel/net/xfrm/xfrm_algo.ko
kernel/net/xfrm/xfrm_user.ko
kernel/lib/bitrev.ko
kernel/lib/crc16.ko
kernel/lib/crc32.ko
kernel/lib/lzo/lzo_compress.ko
kernel/lib/lzo/lzo_decompress.ko
kernel/lib/xz/xz_dec.ko

tttonyyy · « **Reply #135 on:** June 14, 2021, 12:52:24 pm »

Uni-T do meters with NCV? Dammit now I need to upgrade my old UT136B.

Oh and good progress, shame about the SPI flash failure. And a bit alarming that there is a OTP area.

tttonyyy · « **Reply #136 on:** June 14, 2021, 03:33:25 pm »

OK revisiting my upgrade situation I realise I've been a bit thick/blind all along on the other thread about versions not installing...

The 20210601 update is a weird one. I don't know how I missed this, but the app update lines are commented out of the do_update.sh so that it ONLY replaces the FW with 3102 and nothing else. I've hacked it about such that it contains latest (to us) FW 3202 and re-enabled the app update.

Now, my system looks like this: software 20210517 firmware: 3202

No comment on stability/improvements yet - don't forget we're probably not supposed to have this version of phoenix at all, so it might be entirely untested - and they didn't bundle it with 3202 - I have.

I've put it (filename dso3kb_20210601_3202.upk) in DavidAlfa's writeable GDrive area if anyone wants to play at their own risk

DavidAlfa · « **Reply #137 on:** June 14, 2021, 08:26:12 pm »

The SPI issue was because I was trying to send low-levl commands to it modifying sunxi-fel.
People running normal operations shouldn't get any problem. So don't worry about that,
The OTP is likely unused.
So the FW is definitely linked to that file. Easy to make a script that backups and restores it!

tttonyyy · « **Reply #138 on:** June 14, 2021, 09:52:34 pm »

Definitely seeing some stability improvements with the hacked together upk. Not crashed once all evening - when I used to fiddle with memory depth at the fastest capture rate it crashed quite often, but so far it has been really stable.

AWG still generates 1.8Vpp even though it's configured for 1.5Vpp (but then it did that out of the factory with 20210416 and FW 3200 so nothing new).

Calibration works OK, no errors.

Still has DC offsets when channels set to GND mode. No improvement to triggering.

DavidAlfa · « **Reply #139 on:** June 15, 2021, 12:11:02 am »

The DC offset in GND coupling happened only when changing the FW version. Keeping the factory (3000) works.

I'm definitely out of the linux hacking. Everything around the f1C100s is broken. It's by far the AllWinner SOC with worst linux support.
You end downloading chinese u-boot forks that fix something, but only that "something". Still a lot of bugs or lacking features.
Anything you enable in uboot... bang! "Not defined" or "conflicts with....". I won't spend any more time!

tttonyyy · « **Reply #140 on:** June 15, 2021, 07:48:43 am »

They're also looking at booting Linux on the FNIRSI-1013D "100MHz" tablet oscilloscope thread which is also based on the Allwinner F1C100 SoC family, so they may have more luck.

Maybe rather than cross compile it is possible to build on the Orange Pi with the same processor directly. Though my experience of building OpenOCD for ESP32 on the Orange Pi was very slow going.

DavidAlfa · « **Reply #141 on:** June 15, 2021, 08:14:39 am »

Cross compiling works perfectly. It's not the typical dependencies/libs problem, but the f1c100s code, lacking a lot.
The fnirsi has a 16Mbit flash, it probably runs some rtos, not Linux. What the matter on booting Linux on that?
Anyways, since It uses spi nor Flash, it'll be easy as flash something existing like the business card. Good luck with the display

DavidAlfa · « **Reply #142 on:** June 15, 2021, 10:57:40 am »

I've tested every psram_board_test.fs.bin from the available update packages. Those were the results:

Quote

20201118 = FW2013
20201121 = FW2013
20201207 = FW2015
20201221 = FW3000
20210105 = FW3000
20210223 = FW3101
20210311 = FW3101
20210416 = FW3200
20210510 = FW3202
20210601 = FW3102

I made custom update packages that change the FW version, they're inside "FW changer".
Now you can change the FW version in a breeze!

As I suspected, not every updates applies psram_board_test.fs.bin. Neither other contents present in the update itself.

20201118

Code: [Select]

cp $WORKPATH/package/help/help.db /dso/app/
cp $WORKPATH/package/font /dso/app/ -rf
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc

20201121

Code: [Select]

cp $WORKPATH/package/help/help.db /dso/app/
cp $WORKPATH/package/font /dso/app/ -rf
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc

20201207

Code: [Select]

cp $WORKPATH/package/help/help.db /dso/app/
cp $WORKPATH/package/font /dso/app/ -rf
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc

20201221

Code: [Select]

cp  $WORKPATH/package/fpga/* /lib/firmware/psram_board_test.fs.bin -rf
cp $WORKPATH/package/help/help.db /dso/app/
cp $WORKPATH/package/font /dso/app/ -rf
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc

20210105

Code: [Select]

cp $WORKPATH/package/help/help.db /dso/app/
cp $WORKPATH/package/font /dso/app/ -rf
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc

20210223

Code: [Select]

cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc 
cp $WORKPATH/package/spi-fpga-tn652.ko /dso/etc 
cp $WORKPATH/package/load_fpga_kb.sh /dso/etc

20210304

Code: [Select]

cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc 
cp $WORKPATH/package/spi-fpga-tn652.ko /dso/etc 
cp $WORKPATH/package/load_fpga_kb.sh /dso/etc

20210311

Code: [Select]

cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc 
cp $WORKPATH/package/spi-fpga-tn652.ko /dso/etc 
cp $WORKPATH/package/load_fpga_kb.sh /dso/etc

20210416

Code: [Select]

cp $WORKPATH/package/root/* -rf /

20210510

Code: [Select]

cp  $WORKPATH/package/fpga/* /lib/firmware/psram_board_test.fs.bin -rf

20210601

Code: [Select]

cp  $WORKPATH/package/fpga/* /lib/firmware/psram_board_test.fs.bin -rf

tttonyyy · « **Reply #143 on:** June 15, 2021, 01:51:01 pm »

That's very useful. Are you going to put that in a note on your GDrive (maybe alongside the .upk files) so it doesn't get lost on this thread (and can be updated with each Hantek release).

The other thing we could do with picking apart is the layout of /dso/etc/data/cali.dat (aka /cache/cali.dat). It would be useful to be able to adjust calibrate against known external sources and to fix offset problems that the auto calibration (app /dso/app/dso3000c_calibration) gets wrong. I was debating modifying the contents a byte at a time to see which ones affect which area but given the size of the file and all the copying, that would be beyond tedious.

BTW David you can get the Phoenix version from the app binary by looking for a string contained "2021" (or 2020 for earlier ones) which appears like this: ^@res/drawable/hantek.ico^@%d.%d.%s^@^@^@^@1.1.0(20210416.00)^@^@ or just use strings:

strings phoenix | grep 2021
1.1.0(20210416.00)

That'd be good in your list too.

tttonyyy · « **Reply #144 on:** June 15, 2021, 02:23:21 pm »

I see you've removed my .upk from the Writeable dir, has that gone somewhere else as currently there is no other way to get phoenix at version 20210517 with firmware 3202, even using your list of firmware update upks. (The phoenix version was in 20210601, which as you observe does not copy the app to the scope - we're not supposed to have it yet!).

DavidAlfa · « **Reply #145 on:** June 15, 2021, 02:44:06 pm »

I did what I said 2 post ago. Run any update you want. Then run the desired FW changer.
I keep it simple, avoiding the trouble of combining SW + FW together.

tttonyyy · « **Reply #146 on:** June 15, 2021, 03:19:17 pm »

There is no update that applies phoenix 20210517 - that's why I created that custom one.

tttonyyy · « **Reply #147 on:** June 15, 2021, 03:29:40 pm »

I've put it back in your Writable, if you want to see why it's different to standard dso3kb_20210601.upk - it doesn't just apply the 3202 firmware but enables the installation of the bundled (but otherwise not deployed) 20210517 phoenix. As I said before, we're not supposed to have it yet, none of the .upks deploy it. It's working well on my scope in combination with the 3202 firmware.

tttonyyy · « **Reply #148 on:** June 15, 2021, 04:08:31 pm »

Actually not strictly true that we're not supposed to have it, it's also in the platform-tools-20210517.zip file in images/rootfs.ubifs

$ python3 ubidump.py -l rootfs.ubifs | grep phoenix
-rwxr-xr-x 1 0 0 868144 2021-05-27 02:24:52 dso/app/phoenix
$ python3 ubidump.py rootfs.ubifs -c dso/app/phoenix > phoenix
$ strings phoenix | grep 2021
1.1.0(20210517.00)

( ubidump.py from https://github.com/nlitsme/ubidump )

tttonyyy · « **Reply #149 on:** June 15, 2021, 04:11:56 pm »

Speaking of which, platform tools bundles uboot-with-spl-spinand.bin, Pre-made SPI NAND read/write, at a guess.

And in sunxi-tools, nand*.c/h implementation.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Hacking the DSO2X1X (Read 140069 times)

Share me