Hacking the DSO2X1X

[DavidAlfa]

Not yet, trying to make dfu work...
The issue is that uboot doesn't support device reenumeration (or at least by default), so if you unplug the usb it won't work again unless you reset it.
So passing the usb device to the Ubuntu VM kills it....
If usb download gadget worked, nothing else would be needed!

[xuraax]

Suggestion: Read. Where did you see that Phoenix was used to connect to the scope?

I could not see any other help file besides the one provided with the zip. As I said item 4 is not clear to me. I could not read even one character in the screenshot provided. I opted to try out PhoenixSuit because it seemed logical after being requested to installation item 1.

Reading the exchange of messages between you and AndrewBCN it seems obvious that you know this subject in depth. What may be obvious to you when reading that help file may not be obvious to a newbie such as me. Sorry if I wasted your time.

[DavidAlfa]

I mean, read the forum! 
You don't download files and start doing random things.
Platform-tools usage have been explained a lot of times.
When you download that file there's a readme inside..
Check the FAQ down here, in my signature!

[DavidAlfa]

Arrrggh PWM in uboot was still broken for suniv! (F1cxxx family) After while I managed to fix it....
However, buildroot uses a patch to fix uboot source, and I don't know how to commit these changes.
Edit: AFter a lot of failures, errors, losing hair... I made a full patch for the new settings.
https://github.com/aodzip/buildroot-tiny200/pull/8/commits/4403b79eba010e330516523b0e2532a4394e3aa9

Not easy, probablybecause I'm not used to such in-depth details and git commands...
But now the PWM is working, because the screen is lit! Althought empty... for now!

[AndrewBCN]

DavidAlfa,
I noticed you also add two lines to dram.h, but you don't explain why. I would suggest you add a comment for that and resubmit the pull request,

[DavidAlfa]

Where? I think you read wrong... Those are the already existing patches.

This u-boot no longer uses sf / spi-nand method  for accessing the spi nand, instead it's directly attached to mtd, so mtd is used to read it.
SPI flash modules can be disabled in device drivers...
I could boot the flash correctly, added this line in the default bootcmd entry:

Code: [Select]

setenv bootargs 'earlyprintk console=ttyS0,115200 ubi.mtd=4 ubi.fm_autoconvert=1 root=ubi0:rootfs rw rootfstype=ubifs'; mtd read spi-nand0 0x80500000 0xf00000 0x300000; mtd read spi-nand0 0x80c00000 0xd00000 0x5000; bootm 0x80500000 - 0x80c00000


[AndrewBCN]

Ah, so perhaps the u-boot I sent you works also for booting the kernel and initramfs from sunxi-fel? Could you try that, please?

[DavidAlfa]

The best you could do is to a separate test branch in your GitHub and commit all these changes.
Will try later

[DavidAlfa]

And that's all it does. What are you doing to crew up u-boot so much? :

U-Boot SPL 2020.07 (Jun 26 2021 - 17:34:12 +0200)
DRAM: 64 MiB
Trying to boot from FEL

Try the attached file. Updates the uboot patch (Adding the said pwm fix) and has separate configs for hantek (make hantek_dso2000_defconfig).
Kernel is untouched for now. But uboot works right away.

You're using a zImage. So uboot bootm command doesn't work (Kernel image not found), instead use bootz.
I still see you are not providing root argument for the kernel? Is that correct??

I ran my own uboot and this bootcmd:

Code: [Select]

setenv bootargs 'earlyprintk console=ttyS0,115200n8 root=/dev/ram0';\
setenv kernel_addr_r '0x80500000'; setenv fdt_addr_r '0x81500000'; setenv ramdisk_addr_r '0x81800000';\
setenv ram_boot 'echo \"Booting DSO2x1x Linux from FEL...\"; bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}';\
run ram_boot'

But fails.  Hmm.... Load address 0? Entry point 0? Looks wrong.

U-Boot SPL 2020.07 (Jun 27 2021 - 17:06:20 +0200)
DRAM: 64 MiB
Trying to boot from FEL


U-Boot 2020.07 (Jun 27 2021 - 17:06:20 +0200) Allwinner Technology

CPU:   Allwinner F Series (SUNIV)
Model: Allwinner F1C100s Generic Device
DRAM:  64 MiB
MMC:   mmc@1c0f000: 0, mmc@1c10000: 1
Setting up a 800x480 lcd console (overscan 0x0)
In:    serial
Out:   serial
Err:   serial
Allwinner mUSB OTG (Peripheral)
Hit any key to stop autoboot:  0
Booting DSO2x1x Linux from FEL...
## Loading init Ramdisk from Legacy Image at 81800000 ...
   Image Name:
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    8910156 Bytes = 8.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 81500000
   Booting using the fdt blob at 0x81500000
   Loading Ramdisk to 80f80000, end 817ff54c ... OK
ERROR: image is not a fdt - must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###

[Gerasim]

DavidAlfa, excuse me, but I still could not figure out how to change the color of the rays. I saw that you did it! For you, apparently it's easy. But not everyone has this knowledge. Could you publish a ready-made patch with the UPK expansion in your GDrive? Sorry for the trouble I'm causing you)

[DavidAlfa]

No worries! But first I need to find a way to automatically find the offset in the file before patching it, because the app binary changes between updates...
I'll have a look...

[DavidAlfa]

I programmed a bluepill with Jean Thomas's DirtyJtag firmware:
https://github.com/jeanthom/DirtyJTAG

After that I compiled openFPGALoader:
https://github.com/trabucayre/openFPGALoader/releases/tag/v0.4.0

And urjtag:
https://sourceforge.net/projects/urjtag/files/

It seems that jtag I/O uses the same level as Vcore (1.1V). So I had to use a level converter.
I had few TXS108, and as I'm cheating (1.35V for the overclocking), the converter worked (Vmin 1.4V).

However none of them recogniced the device:

openFPGALoader:

Code: [Select]

./openFPGALoader -c dirtyJtag --detect -v
write to ram
Jtag frequency : requested 6000000Hz -> real 6000000Hz
JTAG init failed with: Unknown device with IDCODE: 0x081b


urjtag:

Code: [Select]

jtag> cable dirtyjtag
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000000000000000000100000011011 (0x0000081B)
  Unknown manufacturer! (10000001101) (/usr/local/share/urjtag/MANUFACTURERS)

Reading the programming specifications, Gowin ID is 0x81B (Manufacturer ID)
http://cdn.gowinsemi.com.cn/TN653E.pdf

0x0000081B ID seems to be a GW2A(R)-18.
The Lemontree 2090 might be just a relabeled version, or could be modified for Hantek's needs.
Here's the Gowin FPGA ID table:

[Svyatoslavx]

 Hi.
https://youtu.be/CKMDma6xilY
what parameters of ocmanager did you set?

[DavidAlfa]

Read the instructions. You have to find yourself.
Every chip will overclock different. Default is 648MHz.

From the script:

# DSO2x1x overclocking script by DavidAlfa
# Effective frequency is (BASE_FREQ*(N+1)*(K+1))/(M+1)
# Possible values:
# PLL_N: 1-31
# PLL_K: 0-3
# PLL_M: 0-3

# ------ USER ADJUSTABLE ------
# This example: (24*(17+1)*(2+1))/(1+1) = 648MHz
CPU_OC_PLL_N=17
CPU_OC_PLL_K=2
CPU_OC_PLL_M=1

MEM_OC_PLL_N=12
MEM_OC_PLL_K=0
MEM_OC_PLL_M=0
DEFAULT_DELAY=15

The default CPU K and M settings provide 36MHz steps.
So you CPU speed is (CPU_OC_PLL_N+1)*36
If you set K and M to 0, you'll have 24MHz steps (CPU_OC_PLL_N+1)*24

Memory overclock is usually unstable, you can try changing CPU_MEM_PLL_N, but 15-16 seems to be the limit.
Memory PLL K and M are 0, so the steps are 24MHz.(MEM_OC_PLL_N+1)*24

Remember to first run the test mode package.

[Svyatoslavx]

Thank you.

[pcprogrammer]

Every chip will overclock different. Default is 648MHz.

Hi David, what do you mean with the default is 648MHz? I read that the default startup frequency of the F1C100s is 408MHz. In the FNIRSI 1013-D they crank it up to 600MHz (24MHz * 25)

I did not try to go above that yet, but it would be interesting to see what is possible.

[DavidAlfa]

The default overclocking frequency

[pcprogrammer]

The default overclocking frequency

So it is an arbitrary value you choose to set in your script, and not some known save limit of the F1C100s?

I bought a Lichee nano and on their product page they state up to 900MHz

https://www.seeedstudio.com/Sipeed-Lichee-Nano-Linux-Development-Board-16M-Flash-WiFi-Version-p-2893.html

[DavidAlfa]

It's a value that I consider stable. I got 720MHz out of the box, so I think most will get 648MHz easily.
I currenly have it at 792MHz with a slight overvoltage of 60mV (1.16Vcore). Going over that the ram didn't like to overclock, so I prefer more ram speed and less CPU.
Also, to save costs, the Vcore is also used to power the fpga PLL, which is 1.05V max, Hantek is slighly overvolting it.
Some might get 720,other more, who knows. But they must find by themselves.
Overclocking depends on the chip fabrication quality. Dies coming from the center of the wafer are usually the best, maybe some could reach 900MHz, but those made in the sides won't.
That's why they are 408MHZ by default, by they sell them as "up to 900MHz".

I made the scripts, but I don't give any support. Always at your own risk!

[DavidAlfa]

More news. The i2cbus module works correctly and can be accessed by i2c-tools.
Check my statically compiled busybox binary, which includes it.

Scanninf reveals two devices, one used by the driver (For sure the fpga keyboard inteface)

Code: [Select]

# ./busybox i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --


The on-board eeprom can be dumped easily (address 0x50):

Code: [Select]

# ./busybox i2cdump 0 0x50
i2cdump: WARNING! This program can confuse your I2C bus
Continue? [y/N] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    0...............
10: ff ff ff ff ff ff ff ff ff 01 01 00 00 ff ff ff    .........??.....
20: ff ff ff ff ff ff ff ff b2 08 00 00 55 55 00 00    ........??..UU..
30: 99 59 00 00 dd 5d 00 00 ee 6e 00 00 77 77 00 00    ?Y..?]..?n..ww..
40: 77 77 00 00 aa 6a 00 00 aa 6a 00 00 44 84 00 00    ww..?j..?j..D?..
50: 00 80 00 00 92 08 00 00 99 59 00 00 55 55 00 00    .?..??..?Y..UU..
60: 99 59 00 00 aa 6a 00 00 33 73 00 00 ee 6e 00 00    ?Y..?j..3s..?n..
70: aa 6a 00 00 aa 6a 00 00 00 80 00 00 00 80 00 00    ?j..?j...?...?..
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................


[Poogo]

Successfully overclocked, CPU-900 MHz, RAM - 336 MHz, with an overvoltage of 1.2 V, radiators on the CPU, FPGA, ADC and an added fan in the area of the power supply. It works stably for 4 days for 4-5 hours a day.

[Svyatoslavx]

NOTE: This message has been deleted by the forum moderator Halcyon for being against the forum rules and/or at the discretion of the moderator as being in the best interests of the forum community and the nature of the thread.
If you believe this to be in error, please contact the moderator involved.
An optional additional explanation is: Please keep all posts in English. Most people here can't read Russian.

[DavidAlfa]

Remember that you're overvolting the FPGA too. You can buy a new F1C200s if you break it, but good luck finding the Hantek custom fpga.
Also, the ram overclocks worse with higher Vcore. That's why I stayed at 1.16V, I can run the ram at 408MHz.The system uses 16-bit ram bus, so it's pretty slow.
Moreover, the ram bus is shared with the CPU instruction fetching (Kernel runs from ram) and the LCD panel (800*480*2(16bit)*60Hz=43.9MB/s ).

Even at 408MHz RAM, it's pretty slow: 315MB/s. Stock is 224MB/s!

Code: [Select]

# time dd if=/dev/zero of=/dev/null bs=1M count=8192
8192+0 records in
8192+0 records out
real    0m 26.22s
user    0m 0.02s
sys     0m 26.18s


[Poogo]

Do you think Hantek uses Gowin GW2 series FPGA, not GW1?

[DavidAlfa]

I don't think it's any gowin device you can buy.

https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3598420/#msg3598420