Author Topic: Hacking the DSO2X1X  (Read 19088 times)

0 Members and 2 Guests are viewing this topic.

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #175 on: June 21, 2021, 10:03:53 am »
Sadly, it seems the layout is hardcoded in Phoenix.
Changing this part in utility_menu.xml
Quote
   <item id="@+id/utility_system_update" text="@string/update" type="menu_button"/>
   <item id="@+id/utility_pass_fail" text="@string/pass_fail" type="menu_button"/>
   <item id="@+id/utility_system_info" text="@string/sys_info" type="dialog_swi"/>
   <item id="@+id/utility_calibrate" text="@string/calibrate" type="menu_button"/>
   <item id="@+id/utility_fpst" text="@string/front_panel_self_test" type="button"/>
   <item id="@+id/utility_law" text="@string/legal_info" type="dialog_swi"/>

To:
Quote
   <item id="@+id/utility_system_update" text="@string/update" type="menu_button"/>
   <item id="@+id/utility_system_info" text="@string/sys_info" type="dialog_swi"/>
   <item id="@+id/utility_pass_fail" text="@string/pass_fail" type="menu_button"/>   
   <item id="@+id/utility_calibrate" text="@string/calibrate" type="menu_button"/>
   <item id="@+id/utility_fpst" text="@string/front_panel_self_test" type="button"/>
   <item id="@+id/utility_law" text="@string/legal_info" type="dialog_swi"/>

Yes,it changes the menu labels. But clicking on "sys info" opens "pass/fail", and "pass/fail" opens sys info.

In fact this still works, in only shows "fail" in all menu entries.
Quote
        <item id="@+id/it" text="@string/fail" type="seems"/>
        <item id="@+id/that" text="@string/fail" type="people"/>
        <item id="@+id/at" text="@string/fail" type="hantek"/>
        <item id="@+id/did" text="@string/fail" type="some"/>
        <item id="@+id/crappy" text="@string/fail" type="job"/>
        <item id="@+id/here" text="@string/fail" type="lol"/>

Definitely, Phoenix only reads the string entry. Doesn't give a **** at the ID or type.
« Last Edit: June 21, 2021, 10:21:44 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: Svyatoslavx

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #176 on: June 21, 2021, 03:33:43 pm »
I found the colors to use a lookup table. Yes, they're hardcoded!
I think I found the wave drawing function. It seems to be able to draw 9 waves?
The passing variable to "anolis_wave_plot_set_chn_wave_color" came from a previous function (I called it  get_wave_color?) based on a value that I assumed to be the wave index number.
That function uses pointers+offset to return a value. Knowing the start of the table, it was just matter of time patching these values and trying.
However the color processing is weird. White or black are drawn as grey. If R=G=B, the colour will be always be the same shade of grey.

Patching can be done easily. Phoenix offsets change between versions, but searching "wave_plot_helper" will quickly reveal the table position.
Code: [Select]

# Patch CH1
printf "\x80\xf0\80'" | dd bs=1 count=3 seek=765256 conv=notrunc of=/dso/app/phoenix

# Patch CH2
printf "\x80\xf0\80'" | dd bs=1 count=3 seek=765224 conv=notrunc of=/dso/app/phoenix

# Patch MATH
printf "\x80\xf0\80'" | dd bs=1 count=3 seek=765246 conv=notrunc of=/dso/app/phoenix


« Last Edit: June 21, 2021, 04:00:41 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: AndrewBCN, Victor1964

Online AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #177 on: June 23, 2021, 08:22:46 am »
Hello,
I have just uploaded to DavidAlfa's GDrive a second set of files to test booting Linux through sunxi-fel/USB. I would be grateful if you guys could test them (it takes a few seconds for each test) and post the output on the serial terminal.

1. Test 1: In Writable/AndrewBCN_DSO_Buildroot/sunxi-fel test uboot env, there are two files to test whether sunxi-fel can set environment variables in u-boot. The test is very simple:
- copy the two files to your PC with sunxi-tools installed.
- Boot the DSO or Lichee Pi Nano in FEL mode.
- send the following sunxi-fel command: ./sunxi-fel uboot u-boot-sunxi-with-spl.bin write 0x43100000 my.env
- If all goes well, the DSO / Lichee Pi Nano should print out a "Hello World" message on the serial port (UART1)

The test above is straight from this page: https://linux-sunxi.org/FEL/USBBoot#Example

2. Test 2: In Writable/AndrewBCN_DSO_Buildroot there are three files to test whether u-boot finds the kernel image that we load in RAM using sunxi-fel. Again, the test is quite simple:
- copy the three files (u-boot, dtb, uImage which has kernel and compressed filesystem) to your PC with sunxi-tools installed.
- Boot the DSO or Lichee Pi Nano in FEL mode.
- send the following sunxi-fel command: sunxi-fel -p -v bootm u-boot-sunxi-with-spl.bin write 0x42000000 uImage write 0x42700000 businesscard.dtb
- If all goes well, the DSO / Lichee Pi Nano should load the kernel and print the kernel messages on the serial port (UART1)

Thanks a bunch!
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #178 on: June 23, 2021, 09:22:34 am »
Write 0x4xxxxx? RAM in these starts at 0x80000000
Also you're missing RAM not initialized in fel mode.
"unxi-fel -p -v bootm " there's no such bootm command in sunxi-fel.

This will init the ram. You don't really care what or where it writes, because after this you can write anything to the whole ram.
Code: [Select]
sunxi-fel spl u-boot-sunxi-with-spl.bin
Fixed addresses for the sunxi memory map. You must adjust that offset, the default 0x200000 is wasting the first 32MB of ram!
Code: [Select]
sunxi-fel write 0x80500000 uImage write 0x80c00000 businesscard.dtb

Boot u-boot:
Code: [Select]
sunxi-fel uboot u-boot-sunxi-with-spl.bin

Also the env variables are wrong:



Code: [Select]
bootcmd=setenv bootargs console=ttyS0,115200 bootm 0x42000000 0x43300000 0x43000000This is wrong. It does nothing but this:
Code: [Select]
bootargs=console=ttyS0,115200 bootm 0x42000000 0x43300000 0x43000000Also, why 3 memory addresses after bootm?
Code: [Select]
kernel_addr_r=0x80500000I guess this does nothing.

Where's the root? Ramdisk? Initrd? Since you're booting from ram, shouldn't it be something like this?
Code: [Select]
bootargs root=/dev/ram0 rw console=ttyS0,115200n8 initrd=0x80600000,8M ramdisk_size=8192

Oh, you're discovering the reality vs theory to be much harder? :-DD

Even fixing the address, it doesn't work because it seems the kernel is expecting 0x42000000...?:
Code: [Select]
sunxi-fel spl u-boot-sunxi-with-spl.bin
sunxi-fel write 0x80500000 uImage write 0x80c00000 businesscard.dtb
sunxi-fel uboot u-boot-sunxi-with-spl.bin
Code: [Select]
=> setenv bootargs 'console=ttyS0,115200'
=> setenv bootcmd 'bootm 0x80500000'
=> run bootcmd

Quote
=> setenv bootargs 'console=ttyS0,115200'
=> setenv bootcmd 'bootm 0x80500000'
=> run bootcmd
## Booting kernel from Legacy Image at 80500000 ...
   Image Name:   Linux-5.2.4
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    6613592 Bytes = 6.3 MiB
   Load Address: 42000000
   Entry Point:  42000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

undefined instruction
pc : [<80000140>]          lr : [<83fb9b8f>]
reloc pc : [<7d747140>]    lr : [<81700b8f>]
sp : 83ead4c0  ip : 83fb9e33     fp : 81700020
r10: deadbeef  r9 : 83eb0eb0     r8 : 83fb92a0
r7 : 00000000  r6 : 42000000     r5 : 83fe8bf4  r4 : 00000000
r3 : 83fe8bf4  r2 : 80000100     r1 : fffffff0  r0 : 00000000
Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
Code: 3d656c6f 53797474 31312c30 30303235 (7e2b6200)
Resetting CPU ...

resetting ...
« Last Edit: June 23, 2021, 10:32:44 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: AndrewBCN

Offline Svyatoslavx

  • Contributor
  • Posts: 5
  • Country: ru
Re: Hacking the DSO2X1X
« Reply #179 on: June 23, 2021, 10:40:11 am »
Hello everybody.  who tried to open up to 200 MHz?
 

Online AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #180 on: June 23, 2021, 11:23:40 am »
Write 0x4xxxxx? RAM in these starts at 0x80000000


Thank you DavidAlfa!  :-+

I am recompiling the kernel / uImage so that it starts at address 0x80500000 as you suggested. And will upload it as soon as recompiled.

Done:
  OBJCOPY arch/arm/boot/Image
  Kernel: arch/arm/boot/Image is ready
  GZIP    arch/arm/boot/compressed/piggy_data
  AS      arch/arm/boot/compressed/piggy.o
  LD      arch/arm/boot/compressed/vmlinux
  OBJCOPY arch/arm/boot/zImage
  Kernel: arch/arm/boot/zImage is ready
  UIMAGE  arch/arm/boot/uImage
Image Name:   Linux-5.2.4
Created:      Wed Jun 23 15:09:03 2021
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    6613360 Bytes = 6458.36 KiB = 6.31 MiB
Load Address: 80500000
Entry Point:  80500000
  Kernel: arch/arm/boot/uImage is ready


The (large) uImage includes the initramfs filesystem CPIO appended to the kernel, it should be automatically decompressed by the kernel.

Did you try the small sunxi-fel test to see if it can set u-boot env variables? Did it work? (it should print "Hello World" and return you to u-boot prompt.
« Last Edit: June 23, 2021, 01:13:03 pm by AndrewBCN »
 

Offline Svyatoslavx

  • Contributor
  • Posts: 5
  • Country: ru
Re: Hacking the DSO2X1X
« Reply #181 on: June 23, 2021, 01:05:48 pm »
I want to connect a serial console via bluetooth.  will bluetooth interfere?
 

Online AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #182 on: June 23, 2021, 01:25:37 pm »
So I reuploaded uImage to DavidAlfa's GDrive Writable folder.
This uImage is configured with load address 0x80500000 and same entry point. It includes (?) the compressed initramfs image.

So the sunxi-fel commands to load it into memory should be:

Code: [Select]
sunxi-fel spl u-boot-sunxi-with-spl.bin
sunxi-fel write 0x80500000 uImage write 0x80c00000 businesscard.dtb
sunxi-fel uboot u-boot-sunxi-with-spl.bin

Followed by the u-boot commands:
Code: [Select]
setenv bootargs 'console=ttyS0,115200'
setenv bootcmd 'bootm 0x80500000'
run bootcmd

This should definitely boot the Linux 5.2.4 kernel, and we'll see if the kernel finds the root filesystem in the initramfs image, and jumps to the init program.  :phew:
« Last Edit: June 23, 2021, 05:29:35 pm by AndrewBCN »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #183 on: June 23, 2021, 05:18:56 pm »
uboot envs are still wrong:
Code: [Select]
bootcmd=setenv bootargs console=ttyS0,115200 bootm 0x42000000 0x43300000 0x43000000
Anyways, doing:
Code: [Select]
setenv bootargs 'console=ttyS0,115200'
setenv bootcmd 'bootm 0x80500000'
run bootcmd

Code: [Select]
## Booting kernel from Legacy Image at 80500000 ...
   Image Name:   Linux-5.2.4
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    6613360 Bytes = 6.3 MiB
   Load Address: 80500000
   Entry Point:  80500000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

And nothing else comes out!


About the "hello world" test, I didn't try, loading the envs to  0x43100000 won't work.
« Last Edit: June 23, 2021, 05:28:40 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: AndrewBCN

Online AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #184 on: June 24, 2021, 12:49:08 pm »
First, many many thanks!  :-+  :-+  :-+

uboot envs are still wrong:
Code: [Select]
bootcmd=setenv bootargs console=ttyS0,115200 bootm 0x42000000 0x43300000 0x43000000

Yes, I didn't recompile u-boot, only the kernel (uImage). My bad!

Anyways, doing:
Code: [Select]
setenv bootargs 'console=ttyS0,115200'
setenv bootcmd 'bootm 0x80500000'
run bootcmd

Code: [Select]
## Booting kernel from Legacy Image at 80500000 ...
   Image Name:   Linux-5.2.4
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    6613360 Bytes = 6.3 MiB
   Load Address: 80500000
   Entry Point:  80500000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

And nothing else comes out!

There seems to be a kernel panic before the UART is initialized. I am going to try the kernel config earlyprintk setting, hopefully that will tell us where things go wrong.

About the "hello world" test, I didn't try, loading the envs to  0x43100000 won't work.

Could you please try:
Code: [Select]
sunxi-fel uboot u-boot-sunxi-with-spl.bin write 0x080500000 my.env
That should display the "Hello World" message and confirm that we can set u-boot env variables from sunxi-fel. That will make it much easier for later tests.

From the above it seems that something is wrong with the kernel uImage that I compiled. It does get started by u-boot but then (probably) there occurs a segfault, as I wrote probably before the UART is initialized, since nothing is sent on the serial port.

I am compiling a new set of files (u-boot, kernel, root fs image) with the default Lichee Pi Nano configuration, with earlyprintk enabled and will upload them ASAP.
« Last Edit: June 24, 2021, 12:56:01 pm by AndrewBCN »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #185 on: June 24, 2021, 10:49:13 pm »
Nah, In that report I had already set the earlyprintk in the bootargs...
Why are you writing the envs with a 5MB offset? U-boot usually have them few 100s KB away.
Check CONFIG_ENV_OFFSET and CONFIG_ENV_SIZE:
https://www.digi.com/resources/documentation/digidocs/90001546/reference/u-boot/r_environment_variables.htm

Dropping the envs to a random memory address will do nothing!
« Last Edit: June 24, 2021, 10:55:29 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 DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #186 on: June 25, 2021, 02:53:08 pm »
Finally, the small ESP-01 modules arrived.
I was using the big nodeMCU board as serial bridge!
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Online AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #187 on: June 25, 2021, 03:59:40 pm »
Hello,
I compiled the Widora mangopi-r3 buildroot Linux from their github repository here: https://github.com/aodzip/buildroot-tiny200

This uses a much more recent kernel (5.4.99), u-boot and buildroot and builds almost the same files as George Hilliard's businesscard project.

The sunxi-fel command to load the files  and start the kernel is:

Code: [Select]
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
The rootfs.cpio.uboot file was created using mkimage (in uboot-tools):
mkimage -A arm -T ramdisk -C gzip -d ./rootfs.cpio.gz rootfs.cpio.uboot

DavidAlfa, could you try these? Btw this u-boot apparently supports NAND flash, so you can possibly read/write the onboard-flash chip.


 
The following users thanked this post: H2Nut

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #188 on: June 25, 2021, 06:06:35 pm »
Yeah, but don't mix NAND and SPI-nand. Very different things!

You last u-boot does absolutely nothing. Only uploading the uboot, nothing.
And the're no environment variables inside it...
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: AndrewBCN

Offline Svyatoslavx

  • Contributor
  • Posts: 5
  • Country: ru
Re: Hacking the DSO2X1X
« Reply #189 on: June 25, 2021, 06:29:42 pm »
I also screwed it yesterday, well, it doesn't work here to place a photo.
firmware esp-link
https://4pda.to/forum/index.php?showtopic=1018961&st=200#entry107605161
« Last Edit: June 25, 2021, 06:37:44 pm by Svyatoslavx »
 

Online AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #190 on: June 25, 2021, 07:37:14 pm »
...
You last u-boot does absolutely nothing. Only uploading the uboot, nothing.

When you say u-boot does nothing, do you mean you never get any u-boot messages on the serial port? What are the messages that show up on the serial port before u-boot get started (from BROM)?

And the're no environment variables inside it...

In fact if you examine the u-boot-sunxi-with-spl.bin file, you'll find the entire uboot.env file in there, starting at address 0x004951D.

In the u-boot config file, I have this:
Code: [Select]
...
CONFIG_USE_DEFAULT_ENV_FILE=y
CONFIG_DEFAULT_ENV_FILE="../../../board/allwinner/generic/uboot.env"
...

The uboot.env file is quite long, it's attached (with a txt extension added).
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #191 on: June 26, 2021, 12:07:58 am »
When I mean nothing, I mean absolutely nothing, dead. Not a single char out of the serial port.
Yes, I had checked the uboot file. My mistake, I searched BOOT but I had selected case sensitive option from a previous search, so nothing was found :palm:
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: AndrewBCN

Online AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #192 on: June 26, 2021, 07:01:17 am »
When I mean nothing, I mean absolutely nothing, dead. Not a single char out of the serial port.
...

OK, I found the problem. The uboot-defconfig file for the Widora MangoPi r3 defines CONFIG_CONS_INDEX=2, meaning it selects UART1 as the serial console, and we need UART0.

So I need to recompile u-boot and select UART0 by changing CONFIG_CONS_INDEX=1.  :-/O

OK done, and re-uploaded the corrected u-boot-sunxi-with-spl.bin. This one should display messages on UART0 as intended.

DavidAlfa, sorry to ask you again, but can you give it a try when you have some time? Thank you very much as always.
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #193 on: June 26, 2021, 11:18:19 am »
Haha do you really withstand the waiting?
I would have opened mine long time ago!

Code: [Select]
U-Boot SPL 2020.07 (Jun 26 2021 - 08:49:36 +0200)
DRAM: 64 MiB
Trying to boot from FEL
And nothing else comes out. Tried loading only uboot, same results.

Code: [Select]
sunxi-fel -p uboot u-boot-sunxi-with-spl.bin write 0x80000000 zImage write 0x80700000 devicetree.dtb write 0x80708000 rootfs.cpio.uboot

I looked at that buildroot. Seems they did a great job patching and adding support for the F1C100s!
I'm trying it. I'm using the default allwinner cfg, which seems to be closer to hantek's cfg than the others.
The screen cfg is almost the same, but hantek uses 16bit, this is the correct LCD config:
Code: [Select]
CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:16,pclk_khz:33333,le:35,ri:201,up:25,lo:10,hs:20,vs:10,sync:3,vmode:0"
« Last Edit: June 26, 2021, 12:25:17 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 xuraax

  • Contributor
  • Posts: 30
  • Country: mt
Re: Hacking the DSO2X1X
« Reply #194 on: June 26, 2021, 11:43:45 am »
Hi,

Am I the only one facing issues with getting PhoenixSuit to connect to the DSO in Windows 10?

I believe I have followed the instructions in the help file diligently, i.e. instructions 1,2 and 3. Unfortunately item 4 of the help file is not readable to me so I don't know what it is intended to do.

Zadig installs the driver correctly and returns the display in Item 2 exactly. Windows Device Manager also reports correct driver installation.

However PhoenixSuit still is not able to see the DSO.

Any suggestions?
 
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #195 on: June 26, 2021, 11:48:30 am »
Suggestion: Read. Where did you see that Phoenix was used to connect to the scope?
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Offline Andrew_Debbie

  • Regular Contributor
  • *
  • Posts: 115
  • Country: gb
Re: Hacking the DSO2X1X
« Reply #196 on: June 26, 2021, 11:53:11 am »
The  2C10 and 2C15  are now the same price on the Hantek "Official" Store.      :-DD

 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #197 on: June 26, 2021, 12:26:03 pm »
I'm arguing with the seller. He offered me a partial refund. I'll see...  :-DD
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 

Online AndrewBCN

  • Regular Contributor
  • *
  • Posts: 124
  • Country: fr
Re: Hacking the DSO2X1X
« Reply #198 on: June 26, 2021, 01:05:53 pm »
Haha do you really withstand the waiting?
I would have opened mine long time ago!

Code: [Select]
U-Boot SPL 2020.07 (Jun 26 2021 - 08:49:36 +0200)
DRAM: 64 MiB
Trying to boot from FEL
And nothing else comes out. Tried loading only uboot, same results.

This is expected: the long .env file which I posted earlier is incorrect and the default command is wrong too. I am going to fix them and also add the correct LCD parameters which you kindly posted below and we'll see if that works.
 Do you know what the backlight pwm control pin is for the DSO?

I looked at that buildroot. Seems they did a great job patching and adding support for the F1C100s!
I'm trying it. I'm using the default allwinner cfg, which seems to be closer to hantek's cfg than the others.
The screen cfg is almost the same, but hantek uses 16bit, this is the correct LCD config:
Code: [Select]
CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:16,pclk_khz:33333,le:35,ri:201,up:25,lo:10,hs:20,vs:10,sync:3,vmode:0"
« Last Edit: June 26, 2021, 01:09:45 pm by AndrewBCN »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 1021
  • Country: es
Re: Hacking the DSO2X1X
« Reply #199 on: June 26, 2021, 01:28:45 pm »
Yes, already said before, PE12.
But needs to be pwm, can't be set low or high, the backlight driver is ac-coupled with a series capacitor.
The default allwinner f1c100s config has the PWM pin correctly configured.
Read boards/allwinner/f1c100s.../uboot defconfig
« Last Edit: June 26, 2021, 01:30:20 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ
Stm32 Soldering FW      Forum      Github      Donate      I need calibration reports!
 
The following users thanked this post: AndrewBCN


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf