Hacking the DSO2X1X

[DavidAlfa]

The RTC script is finished, working great. Supports both DS1307 and DS3231.

DS1307 uses the RTC SRAM for timestamp.
DS3231 uses a flash file for timestamp.

Code: (/usr/bin/date_daemon) [Select]

# RTC selection
RTC="DS1307"
#RTC="DS3231"

# RTC common
DATE_FILE="/mnt/udisk/date"
I2C_ADDR="68"
RTC_REG="0x00"
RTC_BYTES="7"

# For DS1307
SRAM_REG="0x08"
SRAM_BYTES="7"

# For DS3231
STAMP_FILE="/etc/date_stamp"

I2C_GET="/usr/bin/i2cget -y 0 0x$I2C_ADDR"
I2C_SET="/usr/bin/i2cset -y 0 0x$I2C_ADDR"
I2C_DETECT="/usr/bin/i2cdetect -y 0 0x$I2C_ADDR 0x$I2C_ADDR"
DATE="/bin/date"
BOOT=1

# Read RTC and update date
read_rtc () {
  [ "$RTC" == "DS1307" ] && STAMP="$($I2C_GET $SRAM_REG i $SRAM_BYTES)"
  [ "$RTC" == "DS3231" ] && STAMP="$($DATE -r "$STAMP_FILE" +"0x%02S 0x%02M 0x%02H 0x%02u 0x%02d 0x%02m 0x%02y")"
  $DATE -us "$($I2C_GET $RTC_REG i $RTC_BYTES | awk '{printf "20%02X%02X%02X%02X%02X.%02X", $7, $6, $5, $3, $2, $1}')" >/dev/null
  [ $BOOT -eq 0 ] && (echo "Date daemon: RTC updated to $($DATE)" >/dev/kmsg)
  [ $BOOT -eq 1 ] && BOOT=0 && (echo "Date daemon: RTC date is $($DATE)" >/dev/kmsg)
}

# Update RTC and STAMP area
write_rtc () {
  $I2C_SET $RTC_REG $NEW i
  [ "$RTC" == "DS1307" ] &&  $I2C_SET $SRAM_REG $NEW i
  [ "$RTC" == "DS3231" ] &&  touch -r "$DATE_FILE" "$STAMP_FILE"
  read_rtc
}

# Detect RTC
[ -z "$($I2C_DETECT | grep " $I2C_ADDR ")" ] && (echo "Date daemon: RTC not detected!" >/dev/kmsg) && (exit 1)

read_rtc

# Monitor "date" file, update if timestamp changed
while true; do
  if [ -f "$DATE_FILE" ]; then
    NEW="$($DATE -r "$DATE_FILE" +"0x%02S 0x%02M 0x%02H 0x%02u 0x%02d 0x%02m 0x%02y")"
    [ "$NEW" != "$STAMP" ] && write_rtc
  fi
  sleep 5
done


Code: (/etc/init.d/S11_date_daemon.sh) [Select]

#!/bin/sh

case "$1" in
  start|restart|reload)
        pidof date_daemon | xargs kill -9 2>/dev/null
        /usr/bin/date_daemon &
        ;;
  stop)
        pidof date_daemon | xargs kill -9 2>/dev/null
        ;;
  *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac

Tested using the DS1307:

Code: [Select]

[ 5642.284836] Date daemon: RTC date is Thu Apr 28 01:55:42 UTC 2022
(Inserted USB drive)
[ 5677.630590] Date daemon: RTC updated to Thu Apr 28 01:56:20 UTC 2022

Booting:

Code: [Select]

System Normal start ...
Welcome to phoenix
[    4.839277] Date daemon: RTC date is Thu Apr 28 02:01:35 UTC 2022
phoenix login:


[Algoma]

Bit more expensive, but what about a USB RTC that wouldn't require an internal modification besides loading a script to read it, though suspect it's likely a bit too much to expect support from the allwinner's kernel..

https://shop.sb-components.co.uk/products/usb-rtc-for-raspberry-pi-1?

[DavidAlfa]

You're talking like there was a good support for this SoC, like rPI does.
There's no official linux support for this, all you have is few semi-patched repos.
I spent days just figuring out why PWM didn't work, then discovering the code was a mess mixing a lot of Allwinner socs, the PWM was completely wrong, writing to the I2S peripheral address.
Submitted a patch, loss half of my hair and flew away.
So, messing with the *kernel*? Suicide is a better solution
Nope, nope, nope, nope....

Also, carrying the usb RTC everywhere? Does that make any sense?


Edit:
The story repeats again.
Wasn't maintained for years, now buildroot it doesn't compile anymore because glibc was modified in 2021 breaking a lot of stuff... I've seen packages from 2014
It's impossible to work with this kind of crap.

What I don't understand is why Hantek used this SoC, while the V3s costs just a little more, running at 1.2GHz, 64MB DDR2, FPU, Linux support...

[morgan_flint]

Apart from the difficulties to implement it, I find it too expensive for this purpose (35€ vs 2€ approx) and not as convenient as a permanently installed RTC...

If you don't want to mess inside the scope, you can still set the time with Davids's method, just install the daemon and then you just need to plug in a USB drive with a freshly created or touched (open-save-close) "date" file when you need to set the clock. Or you can also use the corresponding SPCI command from the remote control program.

Edit: I don't know why that device is so expensive... just a DS3231 RTC (the same as the $2 module) and an MCP2221 USB to i2c bridge, also worth a few $. OTOH, if the RPi has its own i2c bus, why use this bridge, instead of the existing one?

[Algoma]

I've worked with a few modules from DFRobot. They often have slightly better quality modules than what is usually available from other sources in China. They've got a nice rechargeable RTC, Digikey often stocks DFRobot's Products.

https://www.dfrobot.com/product-1600.html

[morgan_flint]

...
Now uses the RTC SRAM to store the "date" file timestamp, instead the system flash.
...

Wow, interesting approach, and now everything in just one script

The problem is that DS3231 doesn't have RAM in that area, so it wouldn't be compatible with that chip... Could the unused space in the EEPROM be used for that purpose? I understand that this stamp is written only when the RTC is set with the "date" file trick (something that won't happen often with an RTC in the system), so no worries about writing the EEPROM too frequently. Is this true? Or maybe it's easier to keep it again in system flash?

[DavidAlfa]

Ouch, a DS3231? Saw DS1307 somewhere and spent quite a while working on the script
Luckly the date registers are the same, so the important part is the same.
Anyways, as you said, for the very few times it's going to be updated, the flash will do fine, or even better, as UBI filesystem provides wear leveling.

[morgan_flint]

Ouch, a DS3231? Saw DS1307 somewhere and spent quite a while working on the script
Luckly the date registers are the same, so the important part is the same.

Thank you, David. In fact, we were talking about both chips, I'd been experimenting with the DS3231 and you had ordered the DS1307, that I also have in my collection but, as you say and I had written in the document I uploaded to your disk, the first 7 registers are the same so it's easy to make that the script works for both, as with my "rudimentary" versions (although by now I've only tested DS3231).

I'll update that document, so it refers to your script instead of mine.

Also, I want to include in the document a reference to the mods that the modules need when used with a non-rechargeable battery; except for the compact version (which has a rechargeable cell and is designed for RPi at 3.3V), the other two modules I cited here can work with 5 V and include a circuit to charge the battery, supposing you install a rechargeable coin cell instead of a "normal" lithium one. See here and here. Really, in the latter one may be no mod is needed when feeding from 3.3V; the forward drop of the diode would prevent charging a 3V battery unless very discharged, while in the DS1307 module would be advisable at least to short R6 to make full use of the battery.

Apart from that, in the DS1317 the EEPROM removal or modding is mandatory, as its address is the same as the DSO's EEPROM. Yesterday, in order to be able to test it, I modded mine as in the photo, I lifted pin 1 and pulled it up to Vcc with 10k (in the limit of the recommended value, but I had it on hand).

[DavidAlfa]

Hold on, you're talking about the DS3121, DS1317(I guess it's a typo), while the picture is from a DS1307

I gave another try to the kernel...
Updated building steps here.

After a lot of work, I got something:
» Configure, compile and flash the kernel.
» Patch the existing uboot, because the bootcmd only reads 3MB, while there new kernel is larger. The kernel partition is 10MB so there's plenty of room available.
» Boot using the original flash rootfs.

However, there're still lots of issues:
» Screen needs fixing. I have no idea what configuration Hantek is using, but seems to be a simple framebuffer, not using the graphics engine at all, drawing everything by software.
    But it looks like the framebuffer is passed from u-boot, so no special config is needed?

» This kernel is 5.4.92, while original is 5.2.0. Hantek uses several custom kernel modules for scpi, keypad, fpga... which will refuse to load because the kernel version doesn't match.
    Additionally, I found a more recent kernel, 5.4.140, sadly we're tied to 5.2.0 for the same reasons.
    I might try using "modprobe -f" to force loading, will be great if it works instead exploding or something

Luckly for us, the original kernel is still available here, and there're great instructions here, so I'll keep working on it.
(Remove [ url] tags, it's a forum error)

Code: [Select]

git clone [url]https://github.com/Lichee-Pi/linux[/url] -b nano-5.2-flash
cd linux
touch .scmversion  # Required to prevent build from appending a "+" sign to the kernel LOCALVERSION, or it'll make "licheepi-nano+"
export ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
make  licheepi_nano_defconfig
make menuconfig
make -j8

» Current status: System dies after "Booting kernel...""

That 5.2.0 kernel has no DMA support, pretty crappy support overall, things that 5.4.92 fixed.
If at least I manage to boot it, I might try porting the patches from 5.4.92...

It's a shame that nobody with linux knowledge joins the business!

[morgan_flint]

Ouch, a DS3231? Saw DS1307 somewhere and spent quite a while working on the script
Luckly the date registers are the same, so the important part is the same.

Sure, using the eeprom is really easy to do, just use different addresses.
This example uses 0x50 (Internal EEPROM), but you could use any other, ex. from the RTC module EEPROM.

.....

Anyways, as you said, for the very few times it's going to be updated, the flash will do fine, or even better, as UBI filesystem provides wear leveling.

Hello again, sorry for reporting so late, but I've been doing some more experiments before doing so...

First of all, tested your EEPROM script, and worked OK. Then tried and tested two or three approaches to use flash instead, starting from the RAM version. The latest one, that seems to work OK is the following:

Code: [Select]

#!/bin/sh

# Variables
DBG=0
DATE_FILE="/mnt/udisk/date"
STAMP_FILE="/etc/date_stamp"
I2C_ADDR="68"
RTC_REG="0x00"
RTC_BYTES="7"
# SRAM_REG="0x08"
# SRAM_BYTES="6"
I2C_GET="/usr/bin/i2cget -y 0 0x$I2C_ADDR"
I2C_SET="/usr/bin/i2cset -y 0 0x$I2C_ADDR"
I2C_DETECT="/usr/bin/i2cdetect -y 0 0x$I2C_ADDR 0x$I2C_ADDR"
DATE="/bin/date"

# Detect RTC presence
detect_rtc () {
  DETECTED="$($I2C_DETECT | grep " $I2C_ADDR ")"
  if [ -z "$DETECTED" ]; then
    echo "Date daemon: RTC not detected!"  >/dev/kmsg
    exit 1
  else
    echo "Date daemon: Found RTC at address 0x$I2C_ADDR"  >/dev/kmsg
  fi
}

# Read RTC SRAM area used for stamp.
#read_stamp () {
#  STAMP="$($I2C_GET $SRAM_REG i $SRAM_BYTES)" #0xss 0xmm 0xhh 0xDD 0xMM 0xYY
#  [ $DBG -eq 1 ] && echo "Date daemon: Read RTC stamp: $STAMP"  >/dev/kmsg
#}

# Read file used for stamp.
read_stamp () {
  STAMP=$(date -r "$STAMP_FILE" +"%s") #epoch
  [ $DBG -eq 1 ] && echo "Date daemon: Read date_stamp date: $STAMP"  >/dev/kmsg
}


# Write RTC SRAM area used for stamp
#write_stamp () {
#  $I2C_SET $SRAM_REG $NEW_STAMP i
#  [ $DBG -eq 1 ] && echo "Date daemon: Write RTC stamp: $NEW_STAMP"  >/dev/kmsg
#}

# Write file used for stamp
write_stamp () {
  touch -d @$NEW_STAMP "$STAMP_FILE"
  [ $DBG -eq 1 ] && echo "Date daemon: Updated date_stamp with NEW_STAMP time"  >/dev/kmsg
}

# Read RTC and update date; calls read_stamp
read_rtc () {
  read_stamp
  NOW="$($I2C_GET $RTC_REG i $RTC_BYTES)"
  YYYY="$(printf "%04X" $(( 0x2000 + $(echo $NOW | awk '{print $7}') )))"
  MM="$(printf "%02X" $(echo $NOW | awk '{print $6}'))"
  DD="$(printf "%02X" $(echo $NOW | awk '{print $5}'))"
  hh="$(printf "%02X" $(echo $NOW | awk '{print $3}'))"
  mm="$(printf "%02X" $(echo $NOW | awk '{print $2}'))"
  ss="$(printf "%02X" $(echo $NOW | awk '{print $1}'))"
  $DATE -us "$YYYY$MM$DD$hh$mm.$ss"  >/dev/null
  echo "Date daemon: Date retrieved from RTC: $YYYY-$MM-$DD $hh:$mm:$ss"  >/dev/kmsg
 
}

# Extract date and write to RTC; calls read_rtc which, in turn, calls read_stamp
write_rtc () {
 
  #Extract fields
  YY="$(echo $NEW_DATE | awk '{print $1}')"
  MM="$(echo $NEW_DATE | awk '{print $2}')"
  DD="$(echo $NEW_DATE | awk '{print $3}')"
  #DAY="$(echo $NEW_DATE | awk '{print $4}')"
  AA="$(echo $NEW_DATE | awk '{print $4}')"
  hh="$(echo $NEW_DATE | awk '{print $5}')"
  mm="$(echo $NEW_DATE | awk '{print $6}')"
  ss="$(echo $NEW_DATE | awk '{print $7}')"
  # As AA is obtained with %u (day of week NUMBER), this is no longer needed
  #case "$DAY" in
  #  "Mon")
  #    AA="1"
  #    ;;
  #  "Tue")
  #    AA="2"     
  #    ;;
  #  "Wed")
  #    AA="3"     
  #    ;;
  #  "Thu")
  #    AA="4"     
  #    ;;
  #  "Fri")
  #    AA="5"     
  #    ;;
  #  "Sat")
  #    AA="6"     
  #    ;;
  #  "Sun")
  #    AA="7"     
  #    ;;
  #esac

  #Update RTC
  $I2C_SET $RTC_REG 0x$ss 0x$mm 0x$hh 0x$AA 0x$DD 0x$MM 0x$YY i
  write_stamp
  read_rtc
  echo "Date daemon: Updated RTC date: $DAY $YY-$MM-$DD $hh:$mm:$ss"  >/dev/kmsg
}

# Script execution start

# Create date_stamp if missing
if [ ! -f "$STAMP_FILE" ]; then
  touch "$STAMP_FILE"
fi

detect_rtc
read_rtc
# Monitor "date" file, update if timestamp changed
while true; do
  if [ -f "$DATE_FILE" ]; then
    # NEW_STAMP="$($DATE -r "$DATE_FILE" +"0x%S 0x%M 0x%H 0x%d 0x%m 0x%y")"
NEW_STAMP=$($DATE -r "$DATE_FILE" +"%s") #epoch
    [ $DBG -eq 1 ] && echo "Date daemon: OLD STAMP: $STAMP" >/dev/kmsg
    [ $DBG -eq 1 ] && echo "Date daemon: NEW STAMP: $NEW_STAMP" >/dev/kmsg
    if [ "$NEW_STAMP" != "$STAMP" ]; then     
      # NEW_DATE="$($DATE -r "$DATE_FILE" +"%y %m %d %a %H %M %S")"
  # Adding 20 secs to the date (time from PC to scope), Day of week with %u
  NEW_DATE="$($DATE -d "@$((20 + $NEW_STAMP))" +"%y %m %d %u %H %M %S")"
      write_rtc
    fi
  else
    [ $DBG -eq 1 ] && echo "Date daemon: Date file \"$DATE_FILE\" not found" >/dev/kmsg
  fi
  sleep 5
done
I've left the code for RAM, commented out, before my code for flash, so you can track easily the mods in case you want to revise it before uploading it to your drive. Another simplification I made is using "%u" instead of "%a" when extracting the day of week (I found on the internet that option gives the number of the day directly and happens to work also in or reduced Linux), so the "case" statement is no longer needed. I also included adding 20 seconds to the date of the "date" file before writing to the RTC, to compensate for the time you need to extract the pendrive from the PC (after "touching" it), plug it in the scope, and the time the scope needs to mount the unit and read it.

Apart from other advantages you commented on before, I think it's better to use the flash rather than the EEPROM as, although improbable, maybe in future versions HANTEK wants to use the now unused zone of the EEPROM, with unpredictable results...

The EEPROM and flash versions should work OK with DS3231 and DS1307 (with the appropriate EEPROM mod in case it exists in the RTC module and is mapped in 0x50, thus conflicting with the DSO's EEPROM).

EDIT: I still have to update the instructions document I uploaded to your disk after all these changes...

[morgan_flint]

Now, a different problem I've found while experimenting with the RTC daemons: When we unplug the pendrive from the scope we are not unmounting it properly, so when you plug it in a Windows PC it complains about problems with the pendrive and asks for repairing it. Not very important, in principle, but a tad annoying, and there's also a risk of data corruption. I think Hantek should have provided an option in the menus for properly unmounting the pendrive before extracting it, so I've opened a thread for that on the "official forum" (not very confident they take it into account, but nothing is lost for trying  ).

BTW, in fact, if you unplug and plug it in the scope with the serial console opened you can see Linux also complains:

Code: [Select]

#
# [ 2998.818192] usb 1-1: USB disconnect, device number 4
[ 2999.853749] FAT-fs (sda1): unable to read boot sector to mark fs as dirty
0:Got Signal with value umount
0:Got Signal with value umount

# [ 3011.622598] usb 1-1: new high-speed USB device number 5 using musb-hdrc
[ 3011.826582] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 3011.885068] scsi host0: usb-storage 1-1:1.0
[ 3012.964435] scsi 0:0:0:0: Direct-Access     Generic  USB Flash Disk   7.76 PQ: 0 ANSI: 4
[ 3012.977692] sd 0:0:0:0: [sda] 15974400 512-byte logical blocks: (8.18 GB/7.62 GiB)
[ 3013.094479] sd 0:0:0:0: [sda] Write Protect is off
[ 3013.102202] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 3013.139709] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 3013.199958] scsi 0:0:0:1: Direct-Access     Generic  USB Flash Disk   7.76 PQ: 0 ANSI: 4
[ 3013.216202] sd 0:0:0:1: [sdb] Attached SCSI removable disk
[ 3013.344367] sd 0:0:0:1: Attached scsi generic sg1 type 0
[ 3013.466786]  sda: sda1
[ 3013.535570] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 3014.402269] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
0:Got Signal with value mount

In the meantime, Do you think there could be a "hacker solution" for this? AFAIK, it's not possible to add new options to the menus (e.g., a menu option to launch custom scripts).

From the console, I've tried "umount /mnt/udisk", and it effectively avoids the error message in windows, but the USB icon in the scope's screen remains lit, so I'm not doing everything needed. I've also tried "eject /dev/sda1", which makes the USB icon disappear, but doesn't seem to unmount properly, as Windows still complains. Also tried one after the other, both possible sequences, without success.

Any suggestions?

EDIT: just for reference, if somebody lands here searching for the subject. As I said in the eediscuss thread linked before, another possibility is blkid /dev/sdb. This one removes the USB icon from the scope's screen and doesn't give errors when plugging it in a Windows PC

[DavidAlfa]

Just hope the system knows it's a removable drive and flush the cache often.
Whenever I write something there, I wait 10-20 seconds before removing or manually run "sync".
It'll still complain but didn't have any issues that way.
The menu is what it is, I'm not having the desire of a delightful experience of spending weeks looking at Guidra disassembly code

[crysti]

Please help-me with my DSO2D10 with freezing after booting.
The buttons no longer react, have only beep sound.

I connected to the serial console, and have this messages with error:

Code: [Select]

SPI-NAND: W25N01GV is found size: 128MB.
*** Warning - bad CRC, using default environment

Welcome to phoenix
phoenix login: anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.

I can restore full backup from memory("_FULL.upk" file) on the front USB with command from serial console?

Thanks in advance!

[DavidAlfa]

This indicates something weird with your data, shouldn't be there.

Code: [Select]

SPI-NAND: W25N01GV is found size: 128MB.
*** Warning - bad CRC, using default environment
Follow the platform-tools procedure described in the FAQ, then you can restore your backup.

[DavidAlfa]

I've opened a thread for that on the "official forum" (not very confident they take it into account, but nothing is lost for trying  ).

Huh, you could also ask them for the kernel sources, otherwise they're violating the GPL.

[morgan_flint]

....
I connected to the serial console, and have this messages with error:
...

I'm also having those messages from the first time I attached the serial port, but as everything seems to go well I didn't pay them much attention. I also made a backup before installing the serial console, I'm not sure if, in my case, restoring the backup would remove them, as maybe they were there from the very beginning (just I didn't have the console to see them). Here is what I get with a bit more context:

Code: [Select]

U-Boot SPL 2018.01 (May 25 2021 - 08:44:03)
DRAM: 64 MiB
Trying to boot from sunxi SPI


U-Boot 2018.01 (May 25 2021 - 08:44:03 +0800) Allwinner Technology

CPU:   Allwinner F Series (SUNIV)
Model: Lichee Pi Nano
DRAM:  64 MiB
show_dram_config:82ea5bc0, 82ea7ee8, 0, 82fc8000
SPI-NAND: W25N01GV is found size: 128MB.
*** Warning - bad CRC, using default environment

cfg_video_init:in:e59ff014
Setting up a 800x480 lcd console (overscan 0x0)
SPI-NAND: W25N01GV is found size: 128MB.
sunxi_lcdc_backlight_enable_user pwm 80
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
SPI-NAND: W25N01GV is found size: 128MB.
SPI-NAND: 3145728 bytes @ 0xf00000 Read: OK
SPI-NAND: 20480 bytes @ 0xd00000 Read: OK
## Booting kernel from Legacy Image at 80500000 ...
   Image Name:   Linux-5.2.0-licheepi-nano
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3071416 Bytes = 2.9 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80c00000
   Booting using the fdt blob at 0x80c00000
   Loading Kernel Image ... OK
   Loading Device Tree to 816fa000, end 816ffee3 ... OK
add fb mem rsv ok, 83f44000, bc000

Starting kernel ...


Code: [Select]

Welcome to phoenix
phoenix login:
[    3.966128] Date daemon: Found RTC at address 0x68
[    4.586737] Date daemon: Date retrieved from RTC: 2022-04-25 10:03:26
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
util_thread_start_with_sched_priority:thread 0xa15a18 is running
[    7.344970] spi_fpga_tn652: loading out-of-tree module taints kernel.
[    8.719567] input: afg3050_kbd as /devices/platform/soc/1c27000.i2c/i2c-0/0-0037/input/input0 CNxxxxxxxxxx
[    9.030971] Mass Storage Function, version: 2009/09/11
[    9.036275] LUN: removable file: (no medium)
[    9.093118] dual speed tmc: IN/ep1in, OUT/ep1out, INTep2in/
[    9.099344] phy phy-1c13400.phy.0: Changing dr_mode to 1

I'll take the opportunity to comment on another thing: When I switch on the scope with the serial to USB converter plugged into the scope but not to the USB port it stays frozen at the boot screen (the one with the QR). Of course, the first time it happened I thought I had bricked it, but later I realized that this happened because it stops at the bootloader menu, the one that you should get at the beginning when it shows "Hit any key to stop autoboot:  0", BTW, something I had tried before without success, seems like you have to be pressing keys continuously from the very beginning to get it. These are the commands it would accept in that menu, and the help for one of them (spi_nand) that might be interesting to explore:

Code: [Select]

=>
=>
=>
=> help
?       - alias for 'help'
bootm   - boot application image from memory
clrlogo - fill the boot logo area with black
env     - environment handling commands
exit    - exit script
false   - do nothing, unsuccessfully
fdt     - flattened device tree utility commands
gpio    - query and control gpio pins
help    - print command description/usage
printenv- print environment variables
reset   - Perform RESET of the CPU
setenv  - set environment variables
showvar - print local hushshell variables
spi_nand- SPI NAND flash sub-system
test    - minimal test like /bin/sh
true    - do nothing, successfully
version - print monitor, compiler and linker version
=>
=> spi_nand
spi_nand - SPI NAND flash sub-system

Usage:
spi_nand probe [[bus:]cs] [hz] [mode]   - init flash device on given SPI bus
                                  and chip select
spi_nand read addr offset len   - read `len' bytes starting at
                                  `offset' to memory at `addr', skipping bad blocks.
spi_nand write addr offset len  - write `len' bytes from memory
                                  at `addr' to flash at `offset', skipping bad blocks.
spi_nand erase[.spread] offset [+]len           - erase `len' bytes from `offset'
                                  `+len' round up `len' to block size
                                  With '.spread', erase enough for given file size, otherwise,
                                  'size' includes skipped bad blocks.
spi_nand update addr offset len - erase and write `len' bytes from memory
                                  at `addr' to flash at `offset'
spi_nand bad - show bad blocks
spi_nand markbad offset - mark block include `offset' as bad block
=>
=> version
U-Boot 2018.01 (May 25 2021 - 08:44:03 +0800) Allwinner Technology

arm-linux-gcc.br_real (Buildroot 2017.02.5) 5.4.0
GNU ld (GNU Binutils) 2.26.1
=>

Probably, all of this is obvious, but I hadn't seen it reported anywhere on this thread or the main one...

[tv84]

This indicates something weird with your data, shouldn't be there.

Code: [Select]

SPI-NAND: W25N01GV is found size: 128MB.
*** Warning - bad CRC, using default environment


I've seen this in many different devices/brands. Not a direct sign of problems BUT agree that, if things were done properly, it shouldn'd be there.

See here.

[morgan_flint]

Huh, you could also ask them for the kernel sources, otherwise they're violating the GPL.

Maybe we could open a thread for that at eediscuss.com and, if we get a lot of people from the threads at eevblog supporting it, maybe they would publish them. Not very confident in that, from what I read, Chinese manufacturers tend to be extremely reluctant to open source their products even though, in a good number of the few cases it has happened (or when the open-source community has created alternatives to the official FW), it has meant a boost in sales of the affected products...

OTOH, AndrewBCN said a long time ago he was considering doing so:

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

Don't know if he finally did it, but I think a public request in their forum with enough support from people posting there might get a better response than individual requests

[morgan_flint]

....
See here.

Thanks!

Could this mean Hantek is using a hacked u-boot  ?

Not very professional of them!!

[DavidAlfa]

Edit: I said nothing, didn't notice before, but it's also happening in mine.
That could be also caused because there's no environment (There's no saveenv cmd), and it always fallbacks to defaults. Not sure, but nothing to worry about.
It's just the u-boot, loads the kernel, end of story. You can modify the booting commands and kernel arguments but not much more.
I've done that, for example, when manually patching the original uboot to boot larger kernels, or stream the output to a different serial port before finding the actual UART0 location.
I gave another try, nope, not for me, I'm really tired of this device.

crysti, probably you had the same bug as me few days ago, where it suddenly freezed, and nothing fixed it until I reinstalled the system.

[morgan_flint]

It might be that, possibly, they're using a patched u-boot...

David, Do you also get the "anolis_picture_width:21 picture!=NULL failed." messages?

Also, Did you explore the u-boot environment commands?

[crysti]

Thanks for your help, now it's OK.

Frozen when I used the cursor for measurements.

[DavidAlfa]

Yes, these errors has always been there.

[crysti]

I find with google translate, a similar forum, with the same tools

https://4pda.to/forum/index.php?showtopic=1018961

[DavidAlfa]

Yes, I know that forum for a very long time.
Information is free, right? There's nothing wrong doing so, also english is not friendly for slavic countries.
All the available information over the net should be free to use, the only ethical aspect is to show some respect by giving credits to the author, wich they're doing, so everything is great.
I already said lots of times, most of my work was only possible thanks to Mark5, he's the one who already made a lot of hacking on other Hantek scopes, figuring out how upk files worked, and the decryption password.