Author Topic: Hacking the DSO2X1X  (Read 19269 times)

0 Members and 3 Guests are viewing this topic.

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1045
  • Country: es
Re: Hacking the DSO2X1X
« Reply #125 on: June 10, 2021, 10:37:08 pm »
Yes, you can boot anything you want, of course compiled first (another fun party).
But meh, not having FPU cripples the performance by a factor of 20 or more... it's a bad base from the start.
I don't feel it worths the time anymore.
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #126 on: June 13, 2021, 12:09:32 pm »
As I posted in the main DSO2X1X thread, there is a software tool that allows access to the Allwinner F1C200s SOC in FEL mode through the USB connector on the back of the scope: sunxi-fel, which is part of sunxi-tools.

I am using Ubuntu 20.10 on my laptop, and it has available a packaged version of sunxi-tools (unfortunately not the latest version, but that can be compiled easily).

Just a quick test with booting the DSO in FEL mode and connecting it to my Linux laptop:

andrew@andrew-ThinkPad-T420:~$ sunxi-fel version
ERROR: You don't have permission to access Allwinner USB FEL device
andrew@andrew-ThinkPad-T420:~$ sudo sunxi-fel version
Warning: no 'soc_sram_info' data for your SoC (id=1663)
AWUSBFEX soc=00001663(unknown) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000


Two things:
1. You must run sunxi-tools as root or give permission to user.
2. The packaged sunxi-tools in Ubuntu 20.10 works but does not identify the F1C200s, but the latest version of sunxi-fel does.

Note that this FEL mode is before u-boot has started, so the actions available are very limited, but for example one should be able to tell the SOC to load the u-boot SPL binary from a file and run it, then starts u-boot proper (see the uboot <file-with-SPL> command below). (SPL = Secondary Program Loader which load the main u-boot binary into RAM)

So at this point I should be able to run any sunxi-fel command:

Usage: ./sunxi-fel [options] command arguments... [command...]
        -v, --verbose                   Verbose logging
        -p, --progress                  "write" transfers show a progress bar
        -l, --list                      Enumerate all (USB) FEL devices and exit
        -d, --dev bus:devnum            Use specific USB bus and device number
            --sid SID                   Select device by SID key (exact match)

        spl file                        Load and execute U-Boot SPL
                If file additionally contains a main U-Boot binary
                (u-boot-sunxi-with-spl.bin), this command also transfers that
                to memory (default address from image), but won't execute it.

        uboot file-with-spl             like "spl", but actually starts U-Boot
                U-Boot execution will take place when the fel utility exits.
                This allows combining "uboot" with further "write" commands
                (to transfer other files needed for the boot).

        hex[dump] address length        Dumps memory region in hex
        dump address length             Binary memory dump
        exe[cute] address               Call function address
        reset64 address                 RMR request for AArch64 warm boot
        readl address                   Read 32-bit value from device memory
        writel address value            Write 32-bit value to device memory
        read address length file        Write memory contents into file
        write address file              Store file contents into memory
        write-with-progress addr file   "write" with progress bar
        write-with-gauge addr file      Output progress for "dialog --gauge"
        write-with-xgauge addr file     Extended gauge output (updates prompt)
        multi[write] # addr file ...    "write-with-progress" multiple files,
                                        sharing a common progress status
        multi[write]-with-gauge ...     like their "write-with-*" counterpart,
        multi[write]-with-xgauge ...      but following the 'multi' syntax:
                                          <#> addr file [addr file [...]]
        echo-gauge "some text"          Update prompt/caption for gauge output
        ver[sion]                       Show BROM version
        sid                             Retrieve and output 128-bit SID key
        clear address length            Clear memory
        fill address length value       Fill memory


Note that when you boot in FEL mode the DSO buttons light up but the screen stays black (no backlight). This is as expected since the buttons LEDs are controlled by an FPGA but the screen and its backlight are controlled by the SOC.

 
The following users thanked this post: tttonyyy

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #127 on: June 13, 2021, 03:35:44 pm »
I have just built the version of sunxi-tools patched by Icenowy for the F1C100s (identical to the F1C200s, except different DRAM size). Now sunxi-fel correctly identifies the SOC:

$ sudo /usr/local/bin/sunxi-fel version
AWUSBFEX soc=00001663(F1C100s) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000


As DavidAlfa found out recently, the latest version of sunxi-fel can be used to read the SPI flash to a file, but the version of sunxi-tools patched by Icenowy doesn't.
So I tried the sunxi-fel which I compiled from source:

$ sudo sunxi-fel spiflash-info
Warning: no 'soc_sram_info' data for your SoC (id=1663)
SPI support not implemented yet for 0 ((null))!


But then I remembered that George Hilliard had merged Icenowy patches with the master sunxi-tools, his version of sunxi-tools can be found here: https://github.com/thirtythreeforty/sunxi-tools

Which I compiled (it takes 30 seconds) and tested: success!  8)

$ sudo /usr/local/bin/sunxi-fel spiflash-info
Manufacturer: Unknown (00h), model: EFh, size: 1024 bytes.

$ sudo /usr/local/bin/sunxi-fel spiflash-read 0 1024 flash.bin


The resulting flash.bin renamed to flash.txt is attached below and yes, it does seem to be u-boot and Linux kernel related code.

So in principle it should be possible to examine/read/write/backup the SPI flash (in other words, the DSO firmware) using sunxi-fel amd the USB OTG port on the back of the DSO. I still have to check how to make the Winbond SPI chip get properly recognized by sunxi-fel.
« Last Edit: June 13, 2021, 05:09:15 pm by AndrewBCN »
 

Offline tttonyyy

  • Regular Contributor
  • *
  • Posts: 54
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #128 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
 

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #129 on: June 13, 2021, 05:04:16 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.  :D

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

 

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #130 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.  :-BROKE
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1045
  • Country: es
Re: Hacking the DSO2X1X
« Reply #131 on: June 13, 2021, 11:39:27 pm »
Dude  :palm:.  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!
« Last Edit: July 13, 2021, 06:55:24 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: AndrewBCN

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #132 on: June 14, 2021, 06:44:25 am »
Dude  :palm:.  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).

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

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1045
  • Country: es
Re: Hacking the DSO2X1X
« Reply #133 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! :-DD
« Last Edit: July 13, 2021, 06:55:41 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #134 on: June 14, 2021, 07:33:19 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.

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! :-DD

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.
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1045
  • Country: es
Re: Hacking the DSO2X1X
« Reply #135 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...
« Last Edit: June 14, 2021, 09:25:16 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #136 on: June 14, 2021, 10:20:23 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...  :phew:
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1045
  • Country: es
Re: Hacking the DSO2X1X
« Reply #137 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
« Last Edit: June 14, 2021, 11:36:20 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Offline tttonyyy

  • Regular Contributor
  • *
  • Posts: 54
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #138 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.
 

Offline tttonyyy

  • Regular Contributor
  • *
  • Posts: 54
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #139 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
« Last Edit: June 14, 2021, 03:52:37 pm by tttonyyy »
 
The following users thanked this post: eevbstedt

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1045
  • Country: es
Re: Hacking the DSO2X1X
« Reply #140 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!
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Offline tttonyyy

  • Regular Contributor
  • *
  • Posts: 54
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #141 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.
« Last Edit: June 14, 2021, 10:07:43 pm by tttonyyy »
 
The following users thanked this post: eevbstedt

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1045
  • Country: es
Re: Hacking the DSO2X1X
« Reply #142 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!
« Last Edit: June 15, 2021, 03:34:40 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: tv84

Offline tttonyyy

  • Regular Contributor
  • *
  • Posts: 54
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #143 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.
« Last Edit: June 15, 2021, 07:51:22 am by tttonyyy »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1045
  • Country: es
Re: Hacking the DSO2X1X
« Reply #144 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 :-DD
« Last Edit: June 15, 2021, 08:18:36 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1045
  • Country: es
Re: Hacking the DSO2X1X
« Reply #145 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
« Last Edit: June 15, 2021, 11:20:06 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: eevbstedt, ph1lw21, tttonyyy

Offline tttonyyy

  • Regular Contributor
  • *
  • Posts: 54
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #146 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.
« Last Edit: June 15, 2021, 02:09:30 pm by tttonyyy »
 

Offline tttonyyy

  • Regular Contributor
  • *
  • Posts: 54
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #147 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!).
« Last Edit: June 15, 2021, 02:25:54 pm by tttonyyy »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1045
  • Country: es
Re: Hacking the DSO2X1X
« Reply #148 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.
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Offline tttonyyy

  • Regular Contributor
  • *
  • Posts: 54
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #149 on: June 15, 2021, 03:19:17 pm »
There is no update that applies phoenix 20210517 - that's why I created that custom one.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf