Hacking the DSO2X1X

[DavidAlfa]

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?

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


=> 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 ...

[Svyatoslavx]

Hello everybody.  who tried to open up to 200 MHz?

[AndrewBCN]

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.

[Svyatoslavx]

I want to connect a serial console via bluetooth.  will bluetooth interfere?

[AndrewBCN]

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. 

[DavidAlfa]

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.

[AndrewBCN]

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.

[DavidAlfa]

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!

[DavidAlfa]

Finally, the small ESP-01 modules arrived.
I was using the big nodeMCU board as serial bridge!

[AndrewBCN]

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.

[DavidAlfa]

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

[Svyatoslavx]

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

[AndrewBCN]

...
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).

[DavidAlfa]

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

[AndrewBCN]

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. 

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.

[DavidAlfa]

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"

[xuraax]

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?
 

[DavidAlfa]

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

[Andrew_Debbie]

The  2C10 and 2C15  are now the same price on the Hantek "Official" Store.     

[DavidAlfa]

I'm arguing with the seller. He offered me a partial refund. I'll see... 

[AndrewBCN]

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"

[DavidAlfa]

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

[AndrewBCN]

Thank you again, DavidAlfa.

OK, so I recompiled u-boot-sunxi-with-spl.bin and reuploaded it to your G-Drivein Writable/widora. I has the LCD parameters and backlight pin information corrected.

I have edited the uboot-defconfig file and I am attaching it. Also, I have completely changed the uboot.env file. It should load the kernel now. And the kernel should print something on the serial port... hopefully.

The sunxi-fel command must be changed because I have changed the addresses for the kernel, dtb and initramfs images (see uboot.env file):

Code: [Select]

sunxi-fel -p uboot u-boot-sunxi-with-spl.bin write 0x80500000 zImage write 0x81500000 devicetree.dtb write 0x81800000 rootfs.cpio.uboot
Before this u-boot attempts to start the Linux kernel it should print a message with "DSO2x1x" in it.

Also it should now be possible to display a splash screen loaded through sunxi-fel/USB on the DSO screen from u-boot, but I am leaving that for later.

As usual, DavidAlfa when you have the time, if you can try this... many thanks!

I am thinking about ordering a Lichee Pi Nano but that would take a month or so to arrive.   

[DavidAlfa]

I built uboot, and the usb download gadget works!
So now we can start talking... with proper uboot patches and hw support it's a different story! 

[AndrewBCN]

Well done! 

Did you try reading/writing to SPI NAND?