HDG2002B AWG Firmware Reverse Engineering

[Cyber7]

I think the onboard ADC's were possibly used for the optional LCD touchscreen. From s3c2416_adc.c :

Code: [Select]

if (temp >= 4)
{
printk(" %d is already reserved for TouchScreen\n", _adc.adc_port);
}
else

[alex.forencich]

I have been looking at the FPGA-related drivers in the source archive, and I can't make any sense of them.  It looks like all of the cfg drivers use SPI, while the others are using the external memory controller?  Are these holdovers from the Hantek DSOs?  Or am I missing something here?

[alex.forencich]

RE: the onboard ADC... there is a driver for that in the sourceball that Hantek made available.. I wonder if the ADCs are accessed directly from the SoC and not through the FPGA?

Actually, there are multiple ADCs.  There is one inside the SoC and then there is a second discrete ADC on the other side of the isolation for the modulation input.  The ADC on the SoC seems to be designed for use with touch screens; see ch. 22 of the datasheet.

[Cyber7]

Looks to me like they are using the hi-speed serial port like the prior DSO sources and mapping the device to a SOC SDRAM buffer to facilitate DMA.

EDIT: That does look DSO related however. The pertinent code is in: /drivers/htg_drivers/fpga_cfg/

[Cyber7]

For a moment there I thought the keypad was on the FPGA..but that is DSO related. They keypad is indeed on the SOC i2C:

Code: [Select]

static int AFG3050_read(struct i2c_client *client, char *buf ,int count)
{
return i2c_master_recv(client,buf ,count);
}

static int AFG3050_write(struct i2c_client *client, char *buf ,int count)
{
return i2c_master_send(client,buf ,count);
}
And the ID tag for the uC is a TI MSP430:

Code: [Select]

static const struct i2c_device_id AFG3050_id[] = {
{ "msp430", 0 },
{ }
};

[alex.forencich]

Looks to me like they are using the hi-speed serial port like the prior DSO sources and mapping the device to a SOC SDRAM buffer to facilitate DMA.

No, I seriously doubt this.  The SMC seems to be a pretty standard external memory controller.  The idea is you can hang multiple memory devices on the system address/data bus and then the SMC will select and communicate with one of them at a time based on the memory mapping.  The only reason to use the SMC is if the FPGA itself is sitting on the memory bus and emulating an SRAM interface of some sort.  Which in this case it isn't; the only connection to the SoC is via SPI.  In the DSOs, they may be using the parallel memory bus connection to the FPGA for faster data transfer - simply performing a memcpy will go out over the bus to the FPGA.  I do not believe this is possible with SPI.

Also, in the htg_drivers folder, there is only the fpga_cfg driver that access the FPGA over SPI.  No drivers in that folder access the SMC.  Is it possible that the AWG app opens the SPI interface directly? 

[Cyber7]

The utility to load the firmware is here: /drivers/htg_drivers/fpga_cfg/cfg_fpga.c

It simply writes the bit file to the driver exposed at dev/fpga_cfg

[alex.forencich]

The utility to load the firmware is here: /drivers/htg_drivers/fpga_cfg/cfg_fpga.c

It simply writes the bit file to the driver exposed at dev/fpga_cfg

It actually doesn't even write the bit file, it writes the bit file NAME to /dev/fpga_cfg, which then passes it to request_firmware.  request_firmware then goes and reads in the file (not sure exactly how this works, will have to read up on it).  Then the file content is copied into kernel space, the FPGA is reset, and then the file is dumped over SPI to the FPGA.  Interesting that they can just dump the file verbatim, I thought they would have to at least strip off the header.  I suppose the configuration logic on the FPGA will just ignore the header, though. 

[Cyber7]

Well, after some tweaks, adding zlib and a patch or two + moving a number of hardcoded cross compiler settings to the top level config.mak, I can do a 'make all' successfully. Since we are missing certain libs, execs and base configs from the src, I merged the resultant rootfs with the differences (missing libs, configs, execs) in the official 1.00.2 firmware. I copied this to an ext3 partition on a sdcard, recompiled kernel with ext3 support and booted it via uboot with these options: bootargs=noinitrd console=ttySAC0 init=/linuxrc rootfstype=ext3 root=/dev/mmcblk0p1 rw rootwait

Moments later the system booted completely with the familiar click of the relays after the fpga firmware loads. Boot log attached. I need to attach the LCD/keypad to verify its operation.

@idpromnut: I can post a diff of my mods if you would like. There's certainly room for improvement, and I'm not certain some .config embedded settings are addressed properly to reflect the crosscompiler. I need to check up on this. I used the Sourcery CodeBench Lite 2014.05-29 compiler.

With a working toolchain, now I can focus on some SPI tests.

[idpromnut]

Well, after some tweaks, adding zlib and a patch or two + moving a number of hardcoded cross compiler settings to the top level config.mak, I can do a 'make all' successfully. Since we are missing certain libs, execs and base configs from the src, I merged the resultant rootfs with the differences (missing libs, configs, execs) in the official 1.00.2 firmware. I copied this to an ext3 partition on a sdcard, recompiled kernel with ext3 support and booted it via uboot with these options: bootargs=noinitrd console=ttySAC0 init=/linuxrc rootfstype=ext3 root=/dev/mmcblk0p1 rw rootwait

Moments later the system booted completely with the familiar click of the relays after the fpga firmware loads. Boot log attached. I need to attach the LCD/keypad to verify its operation.

@idpromnut: I can post a diff of my mods if you would like. There's certainly room for improvement, and I'm not certain some .config embedded settings are addressed properly to reflect the crosscompiler. I need to check up on this. I used the Sourcery CodeBench Lite 2014.05-29 compiler.

With a working toolchain, now I can focus on some SPI tests.

Very nice! Why don't you put your patch/diff into the GIT repo, and throw a pull request to Alex. I'll grab the changes from there.

So if I understand, you can compile the whole kernel+OS environment from Hantek's tarball, and you add in the original FW binaries and you have a fully working FW image that runs off SD?

[idpromnut]

Also, I was going to try getting the gcc-arm tool chain working, so we at least have a working path now, which is good!

[Cyber7]

...you can compile the whole kernel+OS environment from Hantek's tarball, and you add in the original FW binaries and you have a fully working FW image that runs off SD?

Yes. However, I am setting the bootparams each time with uboot, and loading the kernel via its USB test facility. The kernel has been modified to include EXT3 support. The bootparams inform the kernel to initialize from the 1st EXT3 partition on the sdcard.

Unfortunately, we cannot boot from sdcard, since the SOC is configured to copy the 1st 8K from NAND and start the 1st level bootloader. This bootstrap eventually initializes SOC SDRAM, loads u-boot and starts it up. The existing Uboot does not persist boot params, hence the tedious uboot process. My TQ2416 devkit won't arrive until next week, so, I guess I'm at the point of risking replacing the existing uboot, and placing the kernel on another EXT3 sdcard partition.

I finished some cleanup on the cross-compiler build flags, so you should only need to change 2 parameters prior to a build, not counting any changes to the kernel. I'll post my diff package to Alex's private repo for the project momentarily.

[Cyber7]

@idpromnut:

If you haven't already, PM your public key to Alex for access to the private repo. It only supports git via SSH. The src patch is now on the repo under /src/patches . Be sure to also pick up /src/tarballs/fs_base.tar.gz as it contains the missing configs/binaries for the rev 1.00.2 fw release. The makefile will integrate them into the resulting rootfs. See the README.

Still to do: fix the NAND image part of the build process.

I also consolidated some docs & related devkit schematics into the repo.

PS: If you havent seen 'Interstellar', go see it in 70mm IMAX, it is well worth the $12!

[idpromnut]

@Cyber7:

Awesome, I'll fire off my key tp Alex asap. My dev board should be arriving today.

[idpromnut]

Got my dev board; seems to contain a lot of stuff, too bad all of the documentation is in Chinese  :/   Although that was expected. There does seem to be a utility for building SDcard images however...

PS: Alex, can you update my ssh key with the updated one I PM'd you a little while ago?  Thanks!

[fremen67]

Got my dev board; seems to contain a lot of stuff, too bad all of the documentation is in Chinese  :/   Although that was expected. There does seem to be a utility for building SDcard images however...

I bought an EM2416 in May (http://www.armdesigner.com/EM2416.html) which is very similar to the TQ2416. The toolchain provided with the board is Cross-4.2.2-eabi. I made some u-boot building tests with the DSO5000P sources provided by Hantek. The sources had an already compile u-boot_nand.bin file included in the archive. I tested it on my dev board and everything seemed OK with this precompiled file. When I compiled the sources and transfered the new u-boot_nand.bin to my dev board, the lan was not working anymore. I spent some time with wireshark to find out that some data where corrupted in the ethernet frames (ping) and had to slow down the communication between the SOC and the DM9000 so that it worked. I just though that maybe some parameters where missing in the sources.

Now that Hantek released a new set of files including the HDG, I did the test again... with the same results 
I am not able to compile a u-boot with working lan.
I think now that the problem could be my toolchain. As Hantek used the TQ2416 as a base, I would find it logical to use the same Tools/versions they are using. They seem to use a toolchain based on GCC 4.3.3 (EABI-4.3.3_EmbedSky_20100610.tar.bz2 ??) but had not luck finding it on internet.

Could you check what is included on your TQ2416 support DVD?

[Cyber7]

They seem to use a toolchain based on GCC 4.3.3 (EABI-4.3.3_EmbedSky_20100610.tar.bz2 ??) but had not luck finding it on internet.

Here it is, albeit a slow connection: http://pan.baidu.com/wap/shareview?&shareid=4065305958&uk=707448433&dir=%2F&page=1&num=20&fsid=221503121476276&third=0

I haven't tried the GCC toolset, or u-boot LAN support yet on the AWG. 

@idpromnut: Did the support DVD include schematics?

[idpromnut]

@idpromnut: Did the support DVD include schematics?

Yes, however there are a few revisions of what seem to be the same set of schematics. I suspect I will need to check my actual board to see if there is a version number or something that match what the schematics are labelled.

@fremen67: I can shoot you the GCC (that is what they are using) package, as well as the u-boot source that came with my dev CD. I have not tried to compile them yet, as all the documentation on how to unpack and set up the environment is all in Chinese. I was going to give that a shot tonight.

[fremen67]

Here it is, albeit a slow connection: http://pan.baidu.com/wap/shareview?&shareid=4065305958&uk=707448433&dir=%2F&page=1&num=20&fsid=221503121476276&third=0

What a shame  4th result on Google but I was unable to read with internet explorer... no problem with Firefox. Thank's a lot!
And ... it works ! I tried with DSO5000P u-boot sources and with the new HDG u-boot sources. Both are working with a working lan on my dev board.
Now serious things are beginning. There are some bugs to correct (you can download u-boot via tftp but it won't write it, even on the HDG with the original firmware, ...). I will see tomorrow.

[fremen67]

@fremen67: I can shoot you the GCC (that is what they are using) package, as well as the u-boot source that came with my dev CD. I have not tried to compile them yet, as all the documentation on how to unpack and set up the environment is all in Chinese. I was going to give that a shot tonight.

Well... is the dev CD a big one?  . But yes, thank you, at least the dev Tools (with Qtopia).
The toolchain is easy to install (in fact no install at all). You just have to uncompress  in / and add the /opt/EmbedSky/4.3.3/bin path in your .bashrc (for ubuntu)

if you just want to compile u-boot, go to the "u-boot-2009.11_TQ2416" directory of the HDG sources and

make distclean
make TQ2416_config
make all

u-boot will be "u-boot_nand.bin"

[idpromnut]

@fremen67: I can shoot you the GCC (that is what they are using) package, as well as the u-boot source that came with my dev CD. I have not tried to compile them yet, as all the documentation on how to unpack and set up the environment is all in Chinese. I was going to give that a shot tonight.

Well... is the dev CD a big one?  . But yes, thank you, at least the dev Tools (with Qtopia).
The toolchain is easy to install (in fact no install at all). You just have to uncompress  in / and add the /opt/EmbedSky/4.3.3/bin path in your .bashrc (for ubuntu)

if you just want to compile u-boot, go to the "u-boot-2009.11_TQ2416" directory of the HDG sources and

make distclean
make TQ2416_config
make all

u-boot will be "u-boot_nand.bin"

Thanks!  I am wondering if I should bother getting this all working... you all have this solved!   I should probably start getting the actual UI etc started.

[Cyber7]

@fremen67: Have you tried uboot to mount the kernel & rootfs via NFS from your PC? I think this would be the best dev scenario.

The nfs client support on the default kernel works; I've mounted my Ubuntu Eclipse Cross Arm C/C++ workspace from the awg via:

Code: [Select]

mount -t nfs -o nolock,vers=2 {host pc ip}:/root/workspace/ /mnt/nfs
A quick test after setting the compiler flags:

Code: [Select]

[root@Hantek /mnt/nfs/hello/Debug]#./hello
Hello ARM World!

[fremen67]

@fremen67: Have you tried uboot to mount the kernel & rootfs via NFS from your PC? I think this would be the best dev scenario.

The nfs client support on the default kernel works; I've mounted my Ubuntu Eclipse Cross Arm C/C++ workspace from the awg via:

Code: [Select]

mount -t nfs -o nolock,vers=2 {host pc ip}:/root/workspace/ /mnt/nfs
A quick test after setting the compiler flags:

Code: [Select]

[root@Hantek /mnt/nfs/hello/Debug]#./hello
Hello ARM World!

No I did not. I just used NFS on my MSO5062D, which is based on the same SoC and linux version, but only after it was running. I mounted the NFS share to overwrite my USB drive  so that when I push the "Save to USB" button, the image is stored directly on the NFS server. But you will only have NFS support after having loaded the kernel, not before... I did not see NFS support in uboot. When uboot is loaded, you have access to usb, nand, tftp server and SD... and even if there was NFS support in Uboot, I think you would loose it as soon as the kernel would start loading, when the ethernet uboot driver is replaced with the linux one. So I doubt it is possible to mount the kernel using NFS via  uboot. But maybe I am wrong.
Mounting rootfs via NFS after the kernel has been loaded maybe?

As for tftp, it is now working on the HDG. It was a bug related to the new MTD layout where the name "bios" had been replaced with "uboot". I modified cmd_menu.c in /common so that it works now in any case.
tftp is very convenient for updating nand partition and should be enough for testing. Don't you think?
There are also hidden menus which allow updating from SD. I will investigate that point too. Plus I think it should be possible to boot from the SD if we don't want to burn the nand to often.

Code: [Select]

#####    Boot for SKY2416/TQ2416 Main Menu      #####
#####     EmbedSky TFTP download mode     #####

[1] Download u-boot.bin to Nand Flash
[2] Download LOGO (logo.bin) to Nand Flash
[3] Erase the MISC partion
[4] Download Kernel (kernel.bin) to Nand Flash
[5] Download UBIFS image (rootfs.ubi) to Nand Flash
[6] Download Kernel_bk (kernel_bk.bin) to Nand Flash
[7] Download UBIFS image (recover.ubi) to Nand Flash
[8] normal start!
[9] recover start!
[0] Set the boot parameters
[f] Format the Nand Flash
[a] Download User Program
[c] Download Config(config.ubi).
[n] Set TFTP parameters(PC IP,SKY2416/TQ2416 IP,Mask IP...)
[p] Test network (TQ2416 Ping PC's IP)
[r] Reboot u-boot
[s] Download STEPLDR.nb1 to Nand Flash
[t] Test Linux Image (zImage)
[q] Return main Menu
Enter your selection: 1
test_dm9000 i/o: 0x20000300, id: 0x90000a46
DM9000: running in 16 bit mode
MAC: 10:23:45:67:89:ab
operating at 100M half duplex mode
Using dm9000 device
TFTP from server 192.168.1.100; our IP address is 192.168.1.101
Filename 'u-boot.bin'.
Load address: 0xc0000000
Loading: #########################
done
Bytes transferred = 362388 (58794 hex)

NAND erase: device 0 offset 0x0, size 0x100000
Erasing at 0xe0000 -- 100% complete.
OK

NAND write: device 0 offset 0x0, size 0x58800
Writing data at 0x58800 -- 100% complete.
 362496 bytes written: OK

#####    Boot for SKY2416/TQ2416 Main Menu      #####
#####     EmbedSky TFTP download mode     #####

[1] Download u-boot.bin to Nand Flash
[2] Download LOGO (logo.bin) to Nand Flash
[3] Erase the MISC partion
[4] Download Kernel (kernel.bin) to Nand Flash
[5] Download UBIFS image (rootfs.ubi) to Nand Flash
[6] Download Kernel_bk (kernel_bk.bin) to Nand Flash
[7] Download UBIFS image (recover.ubi) to Nand Flash
[8] normal start!
[9] recover start!
[0] Set the boot parameters
[f] Format the Nand Flash
[a] Download User Program
[c] Download Config(config.ubi).
[n] Set TFTP parameters(PC IP,SKY2416/TQ2416 IP,Mask IP...)
[p] Test network (TQ2416 Ping PC's IP)
[r] Reboot u-boot
[s] Download STEPLDR.nb1 to Nand Flash
[t] Test Linux Image (zImage)
[q] Return main Menu
Enter your selection:


[Cyber7]

There are quite a few 'hidden' commands in Hantek uboot. The normal distro 'u-boot-2009.11.tar.bz2' isn't hobbled and will give you a nice long help prompt result. Among them:

nand   - NAND sub-system
nboot   - boot from NAND device
nfs   - boot image via network using NFS protocol
nm   - memory modify (constant address)
ping   - send ICMP ECHO_REQUEST to network host
printenv- print environment variables

There is a barebones src file based on tftp at net/nfs.c that adds nfs protocol support. With a little more digging we should be able to figure it out, but TFTP would do fine for the kernel. Then the kernel bootargs can boot the rootfs via NFS with something like this: "setenv bootargs noinitrd init=/linuxrc console=ttySAC0 root=/dev/nfs nfsroot=%s:%s ip=%s:%s:%s:%s:www.embedsky.com:eth0:off". This way we can recompile/debug files from the host system directly on the target's rootfs. Couple that with and IDE with GDB support for a S3C2416 JTAG, should hopefully make debugging an interactive experience. I've only done this with x86/x64 arch targets, and the directions for my cheapo ARM jtag for doing this with Eclipse are in Chinese...   

[alex.forencich]

Damn; I am having a bear of a time getting timing closure with some basic SPI-MCB interface code on the FPGA.  4 ns is very little to work with on a speed grade 2 Spartan 6.  With around 0.5 to 1 ns per net and 0.3 ns per LUT passthrough, it's not really feasible to go through more than two or three LUTs in each clock cycle at 250 MHz.  It certainly does not help that the MCB outputs have a rather large clock-to-output delay, so much so that it's basically unusable unless it's registered manually. 

I'm getting stuff like this, even after doing a lot of reorganizing and adding/removing/adjusting register locations:

Code: [Select]

Slack:                  -0.295ns (requirement - (data path - clock path skew + uncertainty))
  Source:               spi_slave_inst/input_axis_tready_reg (FF)
  Destination:          soc_interface_inst/port0_cmd_en_reg (FF)
  Requirement:          4.000ns
  Data Path Delay:      4.109ns (Levels of Logic = 3)
  Clock Path Skew:      -0.043ns (0.498 - 0.541)
  Source Clock:         clk_250mhz_int rising at 0.000ns
  Destination Clock:    clk_250mhz_int rising at 4.000ns
  Clock Uncertainty:    0.143ns

  Clock Uncertainty:          0.143ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
    Total System Jitter (TSJ):  0.070ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.216ns
    Phase Error (PE):           0.000ns

  Maximum Data Path at Slow Process Corner: spi_slave_inst/input_axis_tready_reg to soc_interface_inst/port0_cmd_en_reg
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    SLICE_X20Y30.DQ      Tcko                  0.476   spi_slave_inst/input_axis_tready_reg
                                                       spi_slave_inst/input_axis_tready_reg
    SLICE_X21Y30.A2      net (fanout=4)        1.064   spi_slave_inst/input_axis_tready_reg
    SLICE_X21Y30.A       Tilo                  0.259   soc_interface_inst/output_axis_tvalid_reg
                                                       soc_interface_inst/data_valid_reg_rd_empty_AND_65_o1
    SLICE_X18Y36.B5      net (fanout=5)        0.929   soc_interface_inst/data_valid_reg_rd_empty_AND_65_o
    SLICE_X18Y36.B       Tilo                  0.254   soc_interface_inst/port1_cmd_en_reg
                                                       soc_interface_inst/Mmux_port0_cmd_en_next12
    SLICE_X17Y37.C6      net (fanout=2)        0.754   soc_interface_inst/Mmux_port0_cmd_en_next12
    SLICE_X17Y37.CLK     Tas                   0.373   soc_interface_inst/port0_cmd_en_reg
                                                       soc_interface_inst/Mmux_port0_cmd_en_next21
                                                       soc_interface_inst/port0_cmd_en_reg
    -------------------------------------------------  ---------------------------
    Total                                      4.109ns (1.362ns logic, 2.747ns route)
                                                       (33.1% logic, 66.9% route)

That's a fail of 295 ps  while going through only 2 LUTs!