Hacking the DSO2X1X

[AndrewBCN]

Oh I didn't meant that.

Really? This is what you wrote: "The usb storage gadget can't directly access storage devices, you can only bind files to it." Perhaps you didn't read the documentation? It specifically says that the USB storage gadget can access files and block (storage) devices, and I have tested it and it works exactly as described in the documentation.

I'm no longer losing my time with this, so I'm waiting for you do do it!
Yeah I read all that, tried hundreds of examples... no way.
Just good luck!

It's not a matter of luck, just a matter of knowing what you are doing.

[AndrewBCN]

The next steps I'll be working on, in my spare time, when I have some:

1. Compiling an as good as possible Linux kernel, with better performance compared to the Hantek one.
2. Testing the LCD screen and writing a few example programs.
3. Loading the FPGA access module from the original firmware, to enable access to the FPGA RAM and the buttons, LEDs, etc.
4. Testing the various FPGA calls using MicroPython.
5. Long-term, start reverse-engineering the phoenix binary.

Eventually, I will ask Hantek to consider open-sourcing the phoenix binary, so that this becomes a (partially) Open Source community project for an Open Source DSO. Personally I see this as a win-win situation, as Hantek would be able to dedicate their firmware engineers to other projects and the community would gain access to the first Open Source DSO.

[DavidAlfa]

Sure, I tested attaching /dev/mtd0, also mtdblock0, both failed saying invalid device.

I think you're still getting it wrong.
I'm not saying you must do anything, or it's your obligation.
I just said I'm done with it, lost my pacience, and I'll wait to see how your work is going.

[DavidAlfa]

You woke my curiosity again and tried again...wtf?.
Same files I already had from the last time, changed nothing, and worked at first try  .


This is my msg init.d script:

Code: [Select]

#!/bin/sh

CONFIGFS="/sys/kernel/config"
GADGET="$CONFIGFS/usb_gadget"
VID="0x1f3a"
PID="0xefe0"
SERIAL="0123456789"
MANUF="Hantek"
PRODUCT="DSO2C10"

case "$1" in
    start)
        echo "Starting the USB gadget"

        if [ -d $GADGET/g1 ]; then
                echo "Gadget already running!"
                exit 1;
        fi

        if [ -z "$(mount | grep configfs)" ]; then
                echo "Mounting configfs..."
                mount -t configfs none $CONFIGFS
                fi

        mkdir -p $GADGET
        mkdir -p $GADGET/g1

        if [ ! -d $GADGET/g1 ]; then
            echo "Error creating gadget!"
            exit 1;
        fi

        cd $GADGET/g1
        mkdir functions/mass_storage.0
        mkdir functions/acm.0
        echo 1 > functions/mass_storage.0/stall
        echo "/dev/mtdblock0" > functions/mass_storage.0/lun.0/file
        echo 1 > functions/mass_storage.0/lun.0/removable
        echo 0 > functions/mass_storage.0/lun.0/cdrom

        mkdir configs/c.1
        mkdir configs/c.1/strings/0x409
        ln -s functions/mass_storage.0 configs/c.1
        ln -s functions/acm.0 configs/c.1

        echo $VID > idVendor
        echo $PID > idProduct
        mkdir -p strings/0x409
        echo $SERIAL > strings/0x409/serialnumber
        echo $MANUF > strings/0x409/manufacturer
        echo $PRODUCT > strings/0x409/product
        echo "$(ls /sys/class/udc)" > UDC
        echo "OK"
        ;;
    stop)
        echo "Stopping the USB gadget"

        if [ ! -d $GADGET/g1 ]; then
                echo "Gadget not running!"
                exit 1;
        fi

        cd $GADGET/g1

        echo "" > UDC
        rm -f configs/c.1/mass_storage.0
        rm -f configs/c.1/acm.0
        rmdir functions/mass_storage.0
        rmdir functions/acm.0
        rmdir strings/0x409
        rmdir configs/c.1/strings/0x409
        rmdir configs/c.1
        cd $GADGET
        rmdir g1
        cd /

        if [ -d $GADGET/g1 ]; then
                echo "Failed to delete gadget!"
                exit 1;
        fi

        echo "OK"
        ;;
    *)
        echo "Usage : $0 {start|stop}"
esac


[AndrewBCN]

...
Same files I already had from the last time, changed nothing, and worked at first try  .
...

Cool.   
Sometimes when more than one person works on the same problem, you get better results.
Btw I got a very nice email from a third hacker who wants to join in the fun, so I would suggest we share the results using the GitHub repository I already created (which I have to update urgently, and I am late in doing so, of course). 
So please feel free to add any pull requests for your excellent work. And I really hope you don't give up on hacking your Hantek. 

[DavidAlfa]

The storage device is having issues...

- Writing will throw lots of page errors unless I first do "mtd erase" in the console. Why? Shouldn't it manage sector erase by itself?
- After restoring my original image, the kernel will gave a lot of ubi errors, ending in kernel panic.
- Restored the scope with platform-tools, booted correctly. Dumped the flash, but restoring it back screws up the ubi partitions again.
- Wrote a 128MB file with random data, wrote to the nand, restarted the system just to be sure, then I read it again.
  The md5sum matches for both files, so the transfer is correct.

Speed is just  ~1MB/s reading, 1.3MB/s writing.
Doing dd if=/dev/zero of=/dev/sdb bs=128k achieves the fastest speed, 3.3MB/s.
All transfers are done in 128KB blocks to match the flash sectors.

[DavidAlfa]

I uploaded the Live Linux to the Writable folder (Hantek DSO2C10 Live Linux.zip).
It seems there's an old tradition in the forum of downloading and running things without reading... Be careful!

It has the mass storage and the acm serial port attached to the system console.

[DavidAlfa]

I made a very expensive FAT32 128MB drive, filled it with data, unplugged to bypass cache, read back... 100% correct.
But restoring the system image keeps failing.
Boot and kernel works, it's only related to Data/Root. I suspect the problem is related to the ECC.

You can't directly write or read the ECC data, everything is done by the hardware.
To check if the data is ok, after reading a block you have to check Status Register 3 ECC bits (ECC-0, ECC-1).
If (0,0) it means everythign was ok. If (0,1) it means there was a recoverable error. And so on.

So my thoughts is that original FW enables ECC, and also the SPI programmer? But not this Linux, thus the ECC is not updated when writing data.
So, althought the data is valid, the ECC isn't, and the UBI driver fails.

There're references to the internal ECC in drivers/mtd/nand/spi/winbond.c and drivers/mtd/nand/spi/core.c
I've been searching a way to enable or disable it, but this was all the documentations I found : Documentation/devicetree/bindings/mtd/spi-nand.txt

Code: [Select]

SPI NAND flash

Required properties:
- compatible: should be "spi-nand"
- reg: should encode the chip-select line used to access the NAND chip


The current DTS code related to the spi nand:

Code: [Select]

&spi0 {
status = "okay";
spi-nand@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "spi-nand";
reg = <0>;
spi-max-frequency = <100000000>;
status = "okay";

partition@0 {
              label = "spi-nand";
              reg = <0x000000 0x8000000>;
            };           
};
};

BTW a very nice Windows alternative to dd is usb image tool, been using it for years, for me it's the best for making disk images.
A truly lifesaver when I worked at fixing computers, the USB drives with utilities/proghrams/stuff failed very often (viruses, bad  removals...).
I could plug 8 drives  and restore all in a shot, take a 6-7 minutesa break and back to the work with new USBs!

[tv84]

Are you copying also ECC or not? Were you able to disable it?

[DavidAlfa]

Read my edited post. You don't read or write the ECC directly,  it's transparently done by the hardware.
You simply enable it, then any writes to the user data will update the ECC.
After reading the data, check the ECC flag bits to find out if the data is valid.

Edit: I edited drivers/mtd/nand/spi/core.c and forced ECC always off.
Wrote the system image, after rebooting uboot dropped hundreds of ECC errors.
So ECC seems to be enabled system-wide.
It's really weird, the dso is able to boot sometimes, even it's outputting a lot of errors, missing serial/model...
If it was the ECC, it wouldn't load anything, every single sector would report bad ECC.

[tv84]

Read my edited post. You don't read or write the ECC directly,  it's transparently done by the hardware.
You simply enable it, then any writes to the user data will update the ECC.
After reading the data, check the ECC flag bits to find out if the data is valid.

Edit: I edited drivers/mtd/nand/spi/core.c and forced ECC always off.
Wrote the system image, after rebooting uboot dropped hundreds of ECC errors.
So ECC seems to be enabled system-wide.
It's really weird, the dso is able to boot sometimes, even it's outputting a lot of errors, missing serial/model...
If it was the ECC, it wouldn't load anything, every single sector would report bad ECC.

Why don't you force the ECC on when you write your data? If it continue to throw errors than that is a problem/config with the ECC checking HW.

Another question: are you sure you don't have to previously "format" the flash in any special way in order for it to accept the new programming and calculate the new ECC info?

[DavidAlfa]

Obviously I tried that too. ECC is used by default.
Meh, same *** again, can't lose my time this way with this crappy product,  I'm flying away 

[lmantuano]

Hi Poogo,
can you give us some details of the added fan? Standard size mounted on the existing bracket? Powered by what, +8v ? Is there enough power for a 12v/140mA fan?
Thanx
Luigi

[AndrewBCN]

Hi Poogo,
can you give us some details of the added fan? Standard size mounted on the existing bracket? Powered by what, +8v ? Is there enough power for a 12v/140mA fan?
Thanx
Luigi

One of the advantages of these Hantek DSO2X1X is that they run cool and in total silence. Why would you want to add a fan that they absolutely don't need? That will take the PSU out of specs, add electrical noise to the DSO inputs, add the annoying fan buzz to your workplace, kill your warranty, and gain you strictly nothing. 

Would you also add a fan to your multimeter?

[lmantuano]

Hi Andrew,

fair point, but I'm thinking small room, no A/C, hot summers.. OTOH, I do have a small AC desk fan I could place next to the scope if/when needed.

lm

[Poogo]

Hi Luigi!
The biggest heating is at the electrolytic capacitors of the power supply and this can be felt from the outside of the housing in the area of the power supply. The fan in the regular place does not help much from this heating, so I used to install the fan under the power supply and power it from +8v. Now I have made my own linear power supply instead of the original one and it has a special voltage for the fan. I agree with AndrewBCN and if I had known this in advance, I would not have changed anything.

[lmantuano]

Cool... spossiba Poogo!
I will leave it alone and use my external fan if the room temp gets more than 26-28DegC, too easy!
ciao,
lm

[DavidAlfa]

Yesterday I opened it and added a ton of tantalum caps to everything, replaced almost 20 "0 ohm" chokes with real chokes, also modded the PSU, adding additional chokes for the +8/-8V rails, and replaced the electrolytic caps with better low esr ones.
Don't bother, made absolutely zero difference, I get exactly the same noise.
I think the noise comes from coupling of digital nearby digital signals, so it'll be really hard to remove.
Or it's the ADC converter itself, by design...

[Gerasim]

Hello! I have a question for David Alpha. I installed the latest firmware (.... 1108) and after that decided to apply the color theme. The theme was installed, but the firmware rolled back to ... 0714. For the sake of interest, I began to install other versions of updates, but after installing the color theme, the system information of the device always displays ... 0714 firmware. How can I fix this? Thanks)

[blackbile]

I see you did some improvements which unfortunatelly didn't help.
What noise you try to eliminate in this DSO?
The noise often come from the layout of the board which you could do nothing with...

So my question is that what do you think if we replace the OPAMP and the D/A converter could it help anything or they are only part of the signal generator function?

[enmane]

Hey All,
Been watching this as I was torn between the Siglent 1104 that I was going to upgrade and these DSO2000 series which seem pretty nice.  I think I'll go with the Siglent due to the 4 channels but some things that I found really cool were the fact that it was built on Linux - I used to hack on the kernel in grad school and the ability to upgrade.  I may try to get involved on the Siglent side ...

Enough about my interests - I thought you might be interested to know that it appears that on 12/30/2021 a new firmware was uploaded at Hantek -  http://www.hantek.com/download?key=zxgj&sid=3&pid=17182&word=

[masta_k74]

I have a question about the UART patch.
Is it normal that after applying the patch the same old firmware version is always displayed? Can I ignore this?
e.g.:
Update Firmware --> Displays new firmware in the system information.  --> Install Patch --> Displays the old version again.

[DavidAlfa]

Let me guess: You had the patch applied, updated the firmware, patch was gone, so you applied the patch again and found this problem.
The issue happens because the patch makes an internal backup of the binary to restore it at any time when uninstalling, but also when applying a new patch.
If it finds trhe backup it assumes the system is patched, because that's the only way the backup exists.

I don't use offsets for patching, that would be hard and very time consuming, every update would be different.
Instead, I search for patterns. You can't find the original pattern if the file is already patched, that's why it must restore the backup first, then apply your patch.
As the backup already existed, it overwrote the newer file with the older backup.

Nothing to worry about: Run the patch uninstaller, update the firmware, then apply the patch again.
Do this whenever your system is patched and want to update the firmware.

[Algoma]

Testing latest firmware update, at 2mv/Div  ..   Change the channel's DIV adjustment to FINE and you can zoom further, right into 1.02mv/div .. yay bugs (features?)

Heavy aliasing from the ADC, so no additional real resolution to be seen looking beyond the scope's usual 2mv/div limit.

[masta_k74]

@ DavidAlfa:
I have now uninstalled the patch, applied the update, re-patched, and lo and behold, it works!   
Thanks David!