Author Topic: Hacking the DSO2X1X  (Read 18989 times)

Piton and 1 Guest are viewing this topic.

Offline tttonyyy

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

Offline tttonyyy

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

Offline tttonyyy

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

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: es
Re: Hacking the DSO2X1X
« Reply #153 on: June 15, 2021, 04:15:19 pm »
I don't remember deleting your file?. In fact, it's dated as yesterday. Checked the recycle bin, wasn't there either  :-//
I also noticed that. After modifying the update so it applied all of its contents, the system did't like it and the dso interface broke completely.
Didn't investigate any further.

uboot-with-spl-spinand is what it is- Uboot compiled with spi nand support. But that image is build to be compatible with the AllWinner BROM loader (eGon), with a specific header and such.
uboot_fb is build to be loaded at ram, also with spi nand support but adding usb and fastboot. Don't ask me how, I guess Hantek did some crazy hacks there.

nand, spi and spi nand are all different things in u-boot and sunxi.fel. Nand is usually a parallel interface, while generic spi is NOR.
Hovewer this board uses spi nand. Sunxi-fel code lacks support for that. I started working on it but I got tired of the lack of documentation and other stupid time-wasting issues.
And, in the best case, it made 44KB/s, took 1 hour to read or flash. No thanks! The best way would be to compile a program that runs in the ram, avoiding all the u-boot and linux thing.

This SOC BROM doesn't init the DRAM by default, so a dirty hack is to let  sunxi-fel to do it by loading u-boot into ram, but not executing it:
Code: [Select]
sunxi-fel spl uboot.binNow the DRAM is ready. I wrote a 8MB file to the memory, took 26 seconds:
Code: [Select]
sunxi-fel write 0x80000000 8M.binThen read it back, took 21 seconds:
Code: [Select]
sunxi-fel read 0x80000000 8388608 8M.bin
Made m5sums before and after, and they were the same.

So now, the loader. Shouldn't be that hard. SPI is easy to interface in low level programming.
The computer-side interface can be easily done by scripting sunxi-fel commands, reading/writing from/to known memory addresses.
Ex.:
0x80001000: Status (Ready, Execute, ,done, error)
0x80001004: Cmd read/write/erase/protect...
0x80001008: Start address
0x8000100C: Read / write length.
0x80002000: Scratchpad start address (buffer to store the data)

For example, you write the first chunk into the buffer. Write the address and length. Write "erase"comand. Execute. Write "program" command. Execute.
And repeat with the next chunks. That's what actually sunxi-fel does, but in a such way that I cannot understand completely, I don't know how why some work and others not. So it'll be better to do it myself!
Yet to know how to execute a program and return the control to the BROM loader.
« Last Edit: June 15, 2021, 05:02:36 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: eevbstedt

Online Piton

  • Contributor
  • Posts: 44
  • Country: ua
Re: Hacking the DSO2X1X
« Reply #154 on: June 15, 2021, 05:57:53 pm »
Holding the "Default parameters" button for about 3 seconds brings up additional options in my oscilloscope.
[IMG_4193]
 
The following users thanked this post: eevbstedt

Online Piton

  • Contributor
  • Posts: 44
  • Country: ua
Re: Hacking the DSO2X1X
« Reply #155 on: June 15, 2021, 06:02:01 pm »
For some reason, it was not possible to insert an image in the next branch
 

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #156 on: June 15, 2021, 06:15:24 pm »
DavidAlfa,
I cloned George Hilliard's F1C100s Buildroot project and compiled it with four trivial patches. I just uploaded to your Writable a folder which is the Buildroot/output/images folder, it includes u-boot, DTB, Linux kernel and small root filesystem, all compiled for the F1C100s.

The small root filesystem is configured to open a terminal on the Gadget Serial serial interface ttyGS0, so in principle connecting the back USB port to a Linux PC should have the PC detecting the DSO as a serial device /dev/ttyACM0. It also opens a terminal on ttyS0 where you have your serial to USB converter soldered, so you can investigate the included u-boot and kernel.

The Linux kernel in GH's image is 5.2.4, compiled with gcc 8.3.0. The Hantek kernel is 5.2.0, compiled with gcc 5.4.0, a very old version of gcc !
« Last Edit: June 15, 2021, 06:33:56 pm by AndrewBCN »
 
The following users thanked this post: eevbstedt, tttonyyy

Offline tttonyyy

  • Regular Contributor
  • *
  • Posts: 54
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #157 on: June 15, 2021, 07:02:46 pm »
I don't remember deleting your file?. In fact, it's dated as yesterday. Checked the recycle bin, wasn't there either  :-//

I've probably unfairly blamed you, looks like anyone can delete files from your Writable area. Someone else then!
Might be dated yesterday (file creation) but the history only shows today. Meh, anyway. Sounds like you have put a lot of effort into fighting unknowns on this scope, whatever way we look at it we know more about its inner workings than we did before!
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: es
Re: Hacking the DSO2X1X
« Reply #158 on: June 16, 2021, 01:31:35 am »
Fixed. I removed permissions for files already uploaded there, so only me and owner can change them.
(The folder itself stays writable)
Just let me know when you uploaded something, to update the new files.
It's a shame that Google disabled advanced permissions on non business accounts.
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: es
Re: Hacking the DSO2X1X
« Reply #159 on: June 16, 2021, 08:26:02 am »
I found the F1C100s low-level usb driver: https://github.com/RT-Thread/rt-thread/issues/3648
They even say it's the same as the stm32, so it seem to follow a known standard for the register structure? (EHCI, OHCI, UHCI and such?)
That migh explain why there's nothing about it in the datasheet.

Then I found this bit hack to enable USB High speed mode: https://github.com/linux-sunxi/sunxi-tools/issues/146
However the F1c100s addresses are different. After some diging in the header files I got the correct address.
Effectively, the speed increased. In this case, it doubled.
I wrote 64M (Filling the entire DRAM) in 1m50s.  Read in 1m38s. Md5 matches, so it's working.

Now I'm figuring out how to modify sunxi to use it.
The spi program is a low-level arm binary code, inside the file "fel-remotefunc-spi-data-transfer.h"
My idea is to make a new program specifically for the hantek HW, keeping it simple, mostly hardcoded.
Ex. "spinand read [file]", "spinand write [file]". Perhaps adding a hash for error detection.
« Last Edit: June 16, 2021, 10:08:23 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
Properly hacking the DSO2X1X
« Reply #160 on: June 17, 2021, 06:31:41 am »
Properly hacking the DSO2X1X

As I wrote in a previous post, I have used Buildroot to compile uboot, a Linux kernel and a root filesystem for the SOC inside the Hantek DSO2X1X scopes. The Linux kernel and the root filesystem are setup so that the back USB port when connected to a PC makes the DSO appear as a Linux machine accessible through a serial terminal, and a USB mass storage device with the contents of the root filesystem. Many thanks to George Hilliard who developed this small Linux distribution for his F1C100s-based business card. I am going to properly fork his project, rename it and reupload it to GitHub with the small modifications I have made.

The next step is to boot this newly compiled Linux kernel and root filesystem from a USB key plugged into the front USB port. This can be achieved by pressing the FEL button underneath the DSO while turning it on, in principle. I hope to have this going this weekend.

The first and main advantage of hacking the Hantek DSO in this way is that the contents of the SPI nand chip remain untouched, in fact there is no need to even open the back of the scope. So there is zero risk of "bricking" the DSO, and/or damaging any internal component, and/or voiding the warranty.

The second advantage is that this is a much more efficient way to debug / decompile / reverse engineer or just understand the original Hantek firmware and the inner workings of this little DSO.

The third advantage is that this "gentle hacking" method can provide more useful and detailed feedback to Hantek about the issues with their firmware, compared to "your DSO doesn't work" style comments. If you have ever been in support for just about any software or hardware project, you know exactly what I mean.  :-BROKE
 
The following users thanked this post: tv84

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: es
Re: Hacking the DSO2X1X
« Reply #161 on: June 17, 2021, 09:18:05 am »
Good luck! You'll need it! The Business Card project doesn't boot from USB so you'll need...black magic!
The usb module is very broken and/or incomplete.

Some hints (Or how Hantek should have done it in first place):
- PE11(input):
    If 1 it means the back usb port is connected. Disable power from OTG port and set usb phy in device mode.
    If 0 it means the back usb port is disconnected. Enable power on the OTG port and set usb phy in host mode. 
    Hantek powers it all the time, no matter what. So when both usb are connected, nothing works. Very clever!

- PA0(output): Set to 1 to enable power for the OTG, 0 to disable.

- Also, the usb module seems to need to be set either in device or host manually
Code: [Select]
# Set Host mode
echo host > /sys/devices/platform/soc/1c13000.usb/musb-hdrc.1.auto/mode
# Set Device mode
echo peripheral > /sys/devices/platform/soc/1c13000.usb/musb-hdrc.1.auto/mode
Phoenix does it in the background. Killing it leaves the usb phy in the last mode.


From pinctrl-sunxi.h, the kernel GPIO name is calculated as: (GPIO group * 32) + pin number.
GPIO groups: PA(0), PB(1), PC(2) ... PF(5).
Ex.:
PA0 = (32*0)+0 = GPIO0
PC5 = (32*2)+5 = GPIO69
PE11 = (32*4)+11 = GPIO139


To set everything from the shell:
Code: [Select]
# Export GPIO0
echo 0 > /sys/class/gpio/export

# Set GPIO0 as input
echo in > /sys/class/gpio/gpio0/direction

# Set GPIO0 as ouput
echo out > /sys/class/gpio/gpio0/direction

# Set GPIO0 to 1
echo 1 >  /sys/class/gpio/gpio0/value
« Last Edit: June 17, 2021, 10:12:31 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: Nominal Animal

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: fi
    • My home page and email address
Re: Hacking the DSO2X1X
« Reply #162 on: June 17, 2021, 10:02:26 am »
- PE11(input):
    If 1 it means the back usb port is connected
    If 0 it means the back usb port is [disconnected]
So that was the reason the phoenix log showed the GPIO139 (=PE11) being polled, heh!
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: es
Re: Hacking the DSO2X1X
« Reply #163 on: June 17, 2021, 10:10:42 am »
It seems you didn't read the pin assignment list in the page 5? ;D
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 #164 on: June 17, 2021, 11:38:22 am »
Good luck! You'll need it! The Business Card project doesn't boot from USB so you'll need...black magic!
The usb module is very broken and/or incomplete.
...
DavidAlfa,

Yes, I know George Hilliard's F1C100s project boots from SPI NOR. But then he uses the USB port in OTG mode and the USB OTG Linux kernel driver works 100% fine as both a serial-over-USB port and as emulating a USB mass storage device.

So which USB "module" are you talking about? The long proven sunxi USB driver in the Linux kernel works fine in both USB and normal mode, as evidenced by the fact that right now you can connect the Hantek DSO to a PC using the back USB port in OTG mode, or in USB master mode, connect a USB key to the front USB port to run the updates. Obviously you can't and shouldn't use both ports / both modes simultaneously.

So, what makes you say it is "very broken and/or incomplete"?
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: es
Re: Hacking the DSO2X1X
« Reply #165 on: June 17, 2021, 12:37:12 pm »
Just read what I put there. At least in the Hantek fw the usb module can't work on it's own, it needs a daemon to set the correct mode. If you think that's a normal behavior...
What's next? Using switches to enable GPIOs like in a 50s computer? Potentiometers to adjust the LCD backight? :-DD

I organized my GDrive folder. Enhanced some scripts. Added my build/extract scripts for the updates, using a single-step command.

I accidentally discovered something. The update packages don't need the file "upend" or "special". Only "do_update.sh" and "Manifest.xml".
After deleting these files, the updates are much faster! They only take 2-3 seconds.
I guess if they triggered some extra step, like computing checksums or anything cpu-hungry like that.
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: fi
    • My home page and email address
Re: Hacking the DSO2X1X
« Reply #166 on: June 17, 2021, 01:27:42 pm »
It seems you didn't read the pin assignment list in the page 5? ;D
Of course I did, I just didn't realize PE11 == gpio139.  Reason being, I'm not used to pin labels actually matching the hardware numbering!
 

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #167 on: June 17, 2021, 02:09:55 pm »
Just read what I put there. At least in the Hantek fw the usb module can't work on it's own, it needs a daemon to set the correct mode. If you think that's a normal behavior...
...

Yes, that is the correct behavior. The Linux kernel is not supposed to decide what a user-space program should do, in this case switching the USB OTG interface from Master to Slave/Gadget mode.

Also, you have not answered my question. Which "USB module" are you saying is "very broken and/or incomplete" and why?
 

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #168 on: June 18, 2021, 11:55:12 am »
I have found another repository with a Buildroot configuration for the F1C100s / F1C200s:
https://github.com/aodzip/buildroot-tiny200

There is a very interesting script in the buildroot-tiny200/flashutils/linux/ directory: fel-linux.sh

It contains the FEL command to boot the Linux kernel and a root filesystem entirely through FEL:

#!/bin/bash
sunxi-fel -p uboot output/images/u-boot-sunxi-with-spl.bin write 0x80000000 output/images/zImage write 0x80700000 output/images/devicetree.dtb write 0x80708000 output/images/rootfs.cpio.uboot


In other words, no need the use a USB key plugged into the front panel USB port.

I think this is the best and simplest option for hacking these Hantek DSO2000 series: build u-boot, the kernel, DTB and root filesystem on a development PC, connect this PC to the DSO using the USB cable, poweron the DSO with the FEL button pressed, and run this script, then open a terminal on the PC and if everything is setup correctly, you should have a root shell.



 

Offline AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Please help with a quick test
« Reply #169 on: June 18, 2021, 05:04:35 pm »
David is actually waiting for the ram linux method! :popcorn:
DavidAlfa, since you are the only one with a serial connection to the DSO UART0, could you please post the serial terminal output of running the following FEL command:

sunxi-fel -p -v uboot u-boot-sunxi-with-spl.bin write 0x80000000 zImage write 0x80700000 businesscard.dtb

where the three files are from the folder I uploaded to your GDrive Writable?

It's possible u-boot will complain about not finding the kernel image, but at this stage I just want to know if the u-boot binary that I compiled loads through sunxi-fel and runs correctly.

So it would be a big step forward if you could test this. Actually that's the first stage to getting this "load Linux from sunxi-fel" method going.

The second stage will be to configure u-boot to find and load the Linux kernel zImage from RAM, which shouldn't be too difficult. That should give us the Linux kernel messages on the serial terminal.

The third stage is to get the Linux kernel to find the root filesystem compressed file in RAM, decompress it and mount it.That means creating a cpio file from the root filesystem which is a bit tricky but doable.

And the final stage is to configure that root filesystem, once mounted, to open a session on the ttyGS0 (USB gadget serial port) making the UART0 soldered connection redundant. That final stage is actually trivial because it just involves a small edit of the /etc/inittab file, as far as I know.
« Last Edit: June 18, 2021, 05:24:39 pm by AndrewBCN »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: es
Re: Hacking the DSO2X1X
« Reply #170 on: June 18, 2021, 05:37:13 pm »
Quote
sunxi-fel -p -v uboot u-boot-sunxi-with-spl.bin write 0x80000000 zImage write 0x80700000 businesscard.dtb
Stack pointers: sp_irq=0x00002000, sp=0x00005E08
MMU is not enabled by BROM
=> Executing the SPL... done.
Writing image "U-Boot 2019.04 for sunxi board", 224366 bytes @ 0x81700000.
100% [================================================]  1598 kB,  318.6 kB/s
100% [================================================]     8 kB,  305.1 kB/s
Starting U-Boot (0x81700000).


Quote
U-Boot SPL 2019.04 (Jun 15 2021 - 13:20:07 +0200)
DRAM: 64 MiB
Trying to boot from FEL


U-Boot 2019.04 (Jun 15 2021 - 13:20:07 +0200) Allwinner Technology

CPU:   Allwinner F Series (SUNIV)
Model: George Hilliard's business card
DRAM:  64 MiB
In:    serial@1c25000
Out:   serial@1c25000
Err:   serial@1c25000
Hit any key to stop autoboot:  0
unrecognized JEDEC id bytes: 00, ef, aa
Failed to initialize SPI flash at 0:0 (error -2)
Could not find a valid device for spi-flash
Partition rootubi not found!
Error, no UBI device selected!
Error, no UBI device selected!
=>
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: AndrewBCN

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: es
Re: Hacking the DSO2X1X
« Reply #171 on: June 18, 2021, 07:18:14 pm »
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 #172 on: June 18, 2021, 07:44:54 pm »
Wow, many thanks! That was fast!

As expected, GH's u-boot is configured to load the kernel from SPI NOR flash, which it can't find. That's why it displays an error.
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1010
  • Country: es
Re: Hacking the DSO2X1X
« Reply #173 on: June 18, 2021, 08:12:36 pm »
Anyways, you can't just boot the kernel, it needs a a filesystem! And you're not uploadign anything else.
You need to setup a ramdisk and then launch the kernel with the proper args.

That buildroot looks great. Apparently USB works.
Uboot also support USB gadgets, like mass storage devices.
« Last Edit: June 18, 2021, 08:51:31 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
GitHub repository created
« Reply #174 on: June 19, 2021, 05:38:49 pm »
I created a GitHub repository for this. And the README file references this thread.

https://github.com/AndrewBCN/Hantek_DSO2x1x_Linux

It's pretty much empty right now, but I think I'll just populate it with the Buildroot configuration files for building a Linux distribution for this DSO, and document how to build the distribution and load and run it using sunxi-fel.

Now I have to choose which u-boot, kernel and dts I am going to be using, there are three choices (see README). The root filesystem is going to be similar to what George Hilliard decided, minus the games, and plus a few tools to help reverse engineering phoenix.

Note there is a wiki and anybody is more than welcome to contribute.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf