Wednesday, February 7, 2024

RISC-v on ZC706 Evaluation Board - Part VI: Building fesvr-zynq with Petalinux

 As of RISC-v on ZC706 Evaluation Board - Part V: Running Petalinux, I'm back to square one, need to figure out how to build fesvr-zynq with Petalinux. First, set all environment as I can:

source <path-to-installed-PetaLinux>/settings.sh
source <path-to-installed-PetaLinux>/components/yocto/buildtools/environment-setup-x86_64-petalinux-linux
source <path-to-installed-Xilinx>/Vitis/2022.1/settings64.sh
export PATH=$PATH:<path-to-installed-Xilinx>/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/x86_64-petalinux-linux/usr/bin/arm-xilinx-linux-gnueabi
cd <path-to-fpga-zynq>/zc706 && make fesvr-zynq

Now, it complain:
arm-xilinx-linux-gnueabi-g++ -O2 -std=c++11 -Wall -L fpga-zynq/common/build -lfesvr -Wl,-rpath,/usr/local/lib -I fpga-zynq/common/csrc -I fpga-zynq/testchipip/csrc -I fpga-zynq/rocket-chip/riscv-tools/riscv-fesvr/ -Wl,-rpath,/usr/local/lib  -o fpga-zynq/common/build/fesvr-zynq /mnt/ext4/fpga-zynq/common/csrc/fesvr_zynq.cc fpga-zynq/common/csrc/zynq_driver.cc fpga-zynq/testchipip/csrc/blkdev.cc

Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/x86_64-petalinux-linux/usr/lib/arm-xilinx-linux-gnueabi/gcc/arm-xilinx-linux-gnueabi/11.2.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory

   9 | # include_next <stdint.h>
     |                ^~~~~~~~~~

Still sounds like some configuration is missing for the build. With export CFLAGS/CPPFLAGS/CXXFLAGS or set them in make cmdline to "-I<path-to-Xilinx>/Vitis/2022.1/gnu/aarch32/lin/gcc-arm-linux-gnueabi/x86_64-petalinux-linux/usr/include" doesn't help either.

Search shows me a link from lowRISC as Building the front-end server:

# set up the RISCV environment variables
# set up the Xilinx environment variables
cd $TOP/riscv-tools/riscv-fesvr
mkdir build_fpga
cd build_fpga
../configure --host=arm-xilinx-linux-gnueabi
make -j$(nproc)

Once compilation has completed, you should find the following files:

ls -l fesvr-zedboard
ls -l libfesvr.so

To copy your new front-end server to the FPGA image:

cd $TOP/fpga-zynq/zedboard
make ramdisk-open
sudo cp $TOP/riscv-tools/riscv-fesvr/build_fpga/fesvr-zedboard \
  ramdisk/home/root/fesvr-zynq
sudo cp $TOP/riscv-tools/riscv-fesvr/build_fpga/libfesvr.so \
  ramdisk/usr/local/lib/libfesvr.so
make ramdisk-close
sudo rm -fr ramdisk

The proxy kernel (pk) used by the FPGA is the same one used in simulation. While not normally necessary, the proxy kernel can be recompiled using the following commands:

cd $TOP/fpga-zynq/zedboard
make ramdisk-open
sudo cp $TOP/riscv-tools/riscv-pk/build/pk ramdisk/home/root/pk
make ramdisk-close
sudo rm -fr ramdisk

lowRISC also has its risc-fesvr build instruction at fpga-zynq/README.md, slightly different from https://github.com/ucb-bar/fpga-zynq. And actually the two would behave same, if I use Xilinx 2016, which create a 'SDK' folder, and after run 'source SDK/2016.2/settings64.sh', 'make fesvr-zynq':

mkdir -p fpga-zynq/common/build
cd fpga-zynq/common/build && \
fpga-zynq/rocket-chip/riscv-tools/riscv-fesvr/configure \
        --host=arm-xilinx-linux-gnueabi
&& \
make libfesvr.so
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm-xilinx-linux-gnueabi
checking for arm-xilinx-linux-gnueabi-gcc... arm-xilinx-linux-gnueabi-gcc
checking whether the C compiler works... no
configure: error: in `fpga-zynq/common/build':
configure: error: C compiler cannot create executables
See `config.log' for more details

same error as following the lowRISC instructions. Now need to figure out the problem from the config.log file. The log file indicates several warnings for same thing:

fpga-zynq/rocket-chip/riscv-tools/riscv-fesvr/configure: line 2365: ~/SDK/2016.2/gnu/arm/lin/bin/arm-xilinx-linux-gnueabi-gcc: No such file or directory

The gcc compiler does exist, but file ./arm-xilinx-linux-gnueabi-gcc shows:
./arm-xilinx-linux-gnueabi-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.16, stripped

which means I need to enable 32bit support in WSL as I mentioned in Run Linux on Windows - WSL, by doing:

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt install gcc:i386 gcc-multilib g++-multilib libc6:i386

With that, finally I'm able to do make fesvr-zynq, fesvr-zynq and libfesvr.so would be generated under fpga-zynq/common/build folder. When copying fesvr-zynq, also need to copy common/build/libfesvr.so to /usr/local/lib on the board. As mentioned in above lowRISC instructions and fpga-zynq, it is possible to recreate the ram disk, however, I'm getting this when trying the commands under WSL: cpio: dev/console: Cannot mknod: Operation not supported. Not sure whether this is WSL limitation or something I have missed. Give up on this for now. So I tried to copy the new executable. For that, might need to get IP from dhcp server if the board is connected to a network. Modifying /etc/network/interfaces with line 'iface eth0 inet dhcp', then do 'ifdown eth0' and 'ifup eth0' will temporarily work as the change of the interfaces file won't survive of a reboot. After successfully get IP from dhcp server, ssh may still not work with error: Unable to negotiate with a.b.c.d port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1. Can try tftp as:

cd ~
tftp -g -r fesvr-zynq tftp_server
cd  /usr/local/lib
tftp -g -r libfesvr.so tftp_server

Now, run fesvr-zynq without argument would get usage print out (with the original fesvr-zynq executable, used to get "ERROR: No cores found" error, same error as running 'fesvr-zynq pk hello'), but still not able to load the bbl or run the hello code.

PS: README.md in fpga-zynq/rocket-chip/riscv-tools/fpga-fesvr shows:

This repository is deprecated; it has been absorbed into the Spike repository (https://github.com/riscv/riscv-isa-sim).


Sunday, February 4, 2024

Use Blink Mini camera without Amazon subscription

Blink Mini is a cheap camera. Auto detection is a bit awkward to me as it always detected change out of the region I set for motion detecting. And after one year, recording video stop working without subscription.

Luckily, there are Open Source solution, using Python, likely are all based off the documentation at: https://github.com/MattTW/BlinkMonitorProtocol

1) https://pypi.org/project/blink-cameras/ I didn't try it as likely the development was paused since May 2019

2) https://pypi.org/project/blinkpy, github: https://github.com/fronzbot/blinkpy.  This library was built with the intention of allowing easy communication with Blink camera systems, specifically to support the Blink component in homeassistant.

Following is note for using blinkpy.

The blinkpy github site has a brief introduction for how to use it. Information at the pypi.org page likely is out-of date, as module 'blinkpy' has no attribute 'Blink'.

When I try the example code from the Readme, I got this: 

Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x00000201A7EE2310>
Unclosed connector
connections: ['[(<aiohttp.client_proto.ResponseHandler object at 0x00000201A7EE6040>, 57822.015)]', '[(<aiohttp.client_proto.ResponseHandler object at 0x00000201A7F22460>, 57822.593)]']
connector: <aiohttp.connector.TCPConnector object at 0x00000201A7EE2370>
Fatal error on SSL transport
protocol: <asyncio.sslproto.SSLProtocol object at 0x00000201A7EE2970>
transport: <_ProactorSocketTransport fd=844 read=<_OverlappedFuture cancelled>>
Traceback (most recent call last):
  File "C:\miniconda3\lib\asyncio\sslproto.py", line 684, in _process_write_backlog
    self._transport.write(chunk)
  File "C:\miniconda3\lib\asyncio\proactor_events.py", line 359, in write
    self._loop_writing(data=bytes(data))
  File "C:\miniconda3\lib\asyncio\proactor_events.py", line 395, in _loop_writing
    self._write_fut = self._loop._proactor.send(self._sock, data)
AttributeError: 'NoneType' object has no attribute 'send'

Sounds like the connection isn't successfully established? Actually it isn't. I added more code to read the camera name and attribute, and all these information can be read back correctly before above error showing up. Likely, above error raised at the closing or exiting. As a comment for aiohttp issues 5941, loop._proactor is None means loop.close() was called before session.close() call.
This is incorrect; and not aiohttp problem.

Monday, January 29, 2024

RISC-v on ZC706 Evaluation Board - Part V: Running Petalinux

Follow up on RISC-v on ZC706 Evaluation Board - Part IV: petalinux. As mentioned in the previous post, I didn't have tftp setup on my host PC. With 'BOOT.BIN' copied to SD card, when booting up the board, U-Boot will look for tftp server, and trying to download Linux image from there. I guess it is possible to copy the Linux image to the SD card and boot from there. But let's setup the tftp server, then it be more convenience to update the Linux image without the need to transfer image to the SD card, why not? It's also possible to run SCP on the ZC706 EV board to copy image to SD card.

It's very easy to setup tftp (Trivial File Transfer Protocol). Searching Internet may recommend tftp-hpa, which is an enhanced version of the BSD TFTP client and server. It possesses a number of bugfixes and enhancements over the original. May follow this to setup tftp backed by xinetd. If cannot update /etc/xinetd.d/tftp file, and 'sudo kill -HUP pid_of_inetd' doesn't help, then try 'sudo kill -9 pid_of_inetd'. Then restart xinetd with: sudo /etc/init.d/xinetd restart

There might be multiple tftp servers on the same subnet, so may need to specify the server on the ZC706 board. This can be done with cmd:

setenv serverip 192.168.1.117

Somehow, it still try to download from the other tftp server. So I tried to boot the image with QEMU:

 source petalinux/settings.sh
 petalinux-boot --qemu --prebuilt 2

It can boot to Linux, and will ask for login credential, and 'root/root' doesn't work. Per https://docs.xilinx.com/r/en-US/ug1144-petalinux-tools-reference-guide/Login-Changes, the root account is disabled, The default user is petalinux and the password should be set on first boot. For me, using both 2 and 3 for prebuilt option will boot to Linux, but with 2, it will show more information for uboot boot.

Refer to QEMU User Documentation for how to use QEMU, such as:

To quit the emulation, press CTRL+A followed by X. To switch
between the serial port and the monitor, use CTRL+A followed by C.

Now, back to the UBoot with tftp, do a power cycle and press 'space' key within 3 seconds to pause UBoot. printenv shows:

arch=arm
baudrate=115200
board=zynq
board_name=zynq
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; i
boot_efi_bootmgr=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
boot_targets=mmc0 jtag mmc0 mmc1 qspi nand nor usb0 usb1 pxe dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=devtype=dhcp; run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;set;
bootcmd_jtag=echo JTAG: Trying to boot script at ${scriptaddr} && source ${scriptaddr}; echo JTAG: SCRIPT FAILED: continuing...;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_nand=nand info && nand read ${scriptaddr} ${script_offset_f} ${script_size_f} && echo NAND: Trying to boot script at ${;
bootcmd_nor=cp.b ${script_offset_nor} ${scriptaddr} ${script_size_f} && echo NOR: Trying to boot script at ${scriptaddr} && sou;
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_qspi=sf probe 0 0 0 && sf read ${scriptaddr} ${script_offset_f} ${script_size_f} && echo QSPI: Trying to boot script at;
bootcmd_usb0=devnum=0; run usb_boot
bootcmd_usb1=devnum=1; run usb_boot
bootcmd_usb_dfu0=setenv dfu_alt_info boot.scr ram $scriptaddr $script_size_f && dfu 0 ram 0 60 && echo DFU0: Trying to boot scr;
bootcmd_usb_dfu1=setenv dfu_alt_info boot.scr ram $scriptaddr $script_size_f && dfu 1 ram 1 60 && echo DFU1: Trying to boot scr;
bootcmd_usb_thor0=setenv dfu_alt_info boot.scr ram $scriptaddr $script_size_f && thordown 0 ram 0 && echo THOR0: Trying to boot;
bootcmd_usb_thor1=setenv dfu_alt_info boot.scr ram $scriptaddr $script_size_f && thordown 1 ram 1 && echo THOR1: Trying to boot;
bootdelay=2
bootfile=pxelinux.0
bootfstype=fat
bootm_low=0
bootm_size=30000000
cpu=armv7
dfu_alt_info=mmc 0:1=boot.bin fat 0 1;u-boot.img fat 0 1
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
ethact=ethernet@e000b000
ethaddr=??:??:??:??:??:??
fdt_addr_r=0x1f00000
fdtcontroladdr=3eadf220
ipaddr=x.x.x.x
kernel_addr_r=0x2000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadaddr=0x0
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
modeboot=sdboot
pxefile_addr_r=0x2000000
ramdisk_addr_r=0x3100000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_t
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}e
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; te
script_offset_f=9c0000
script_offset_nor=0xE2FC0000
script_size_f=0x40000
scriptaddr=3000000
serverip=y.y.y.y
soc=zynq
stderr=serial@e0001000
stdin=serial@e0001000
stdout=serial@e0001000
ubifs_boot=env exists bootubipart || env set bootubipart UBI; env exists bootubivol || env set bootubivol boot; if ubi part ${bi
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi
vendor=xilinx
ethaddr, ipaddr and serverip are all set valid value, somehow it will keep trying a different tftp server. With uboot paused, manually issue 'bootcmd' will make it able to load from the desired tftp server. May get lot of network error, but after multiple retries, it should be able to load pxelinux.0, rootfs.cpio.gz.u-boot, zImage, system.dtb, then start the kernel successfully. uname -a =>

Linux xilinx-zc706-2022_2 5.15.36-xilinx-v2022.2 #1 SMP PREEMPT Mon Oct 3 07:50:07 UTC 2022 armv7l GNU/Linux

So it is still running on the ARM core. Still need to figure out how to fix fesvr-zynq issue. Probably need to rebuild fesvr-zynq with petaliux SDK? Need to explore more.

Wednesday, December 20, 2023

RISC-v on ZC706 Evaluation Board - Part IV: petalinux

 One year ago (Dec 2022) I made two posts to try modelling RISC-v on ZC706:

Then later in this April I post RISC-v on ZC706 Evaluation Board - Part III to dive into generating FPGA bit stream with Vivado 2016.2. It is a bit success, but eventually still running into issue: "./fesvr-zynq pk hello" still get "ERROR: No cores found". As mentioned in the old post, likely that I need to setup PetaLinux. After several busy months, now I get some spare time to tackle this.

fesvr-zynq probably was built from rocket-chip/riscv-tools/riscv-fesvr, but per https://github.com/ucb-bar/fpga-zynq/issues/87, the issue likely is not coming from this binary:

zhemao commented Jul 9, 2018

Sorry, I forgot to update all the binaries in the uramdisk.image.gz.

Could you please try the files in the master branch of fpga-images-zedboard? I've tested them on my board and they seem to work. https://github.com/ucb-bar/fpga-images-zedboard.

But likely https://github.com/ucb-bar/fpga-images-zc706 not updated. So likely what I need is using PetaLinux tools to build this uramdisk.image.gz for fpga-images-zc706.

Since I haven't been touching the zc706 board for a while, also it is now connected to a new Linux host, let me refresh the whole thing for reproducing the problem. With zc706 UART connected to Linux, once power up the board, kernel log shows:

 usb 2-10: new high-speed USB device number 7 using xhci_hcd
 usb 2-10: New USB device found, idVendor=0403, idProduct=6014, bcdDevice= 9.00
 usb 2-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 usb 2-10: Product: Digilent USB Device
 usb 2-10: Manufacturer: Digilent
 usb 2-10: SerialNumber: 210251842966
 ftdi_sio 2-10:1.0: FTDI USB Serial Device converter detected
 usb 2-10: Detected FT232H
 usb 2-10: FTDI USB Serial Device converter now attached to ttyUSB0

This ttyUSB0 likely is the Jtag. Per host kernel log ([    5.208150] usb 4-4: cp210x converter now attached to ttyUSB1), the Uart over USB device ttyUSB1 is there no matter the zc706 board is powered on or off. To connect to the Uart, would need terminal like putty(needs XServer) or minicom(runs in shell). I take minicom as I'm connecting the host with ssh. Run: sudo minicom -s to setup serial port.

Once connected, it would prompt zynq login, use root/root which is default credential. If Ethernet cable is connected, then can use ssh to login the board, the default IP is 192.168.1.5 (refer to the fpga-zynq project page).

With the h/w environment ready, now let's start the PetaLinux adventure.

I have downloaded PetaLinux Tools Installer and ZC706 BSP from Xilinx site several months back. The site also provides common images for Embedded Vitis Platforms. And per note:The ‘common image’ packages contain a prebuilt Linux kernel and root file system that can be used with any Zynq™, Zynq™ MP or Versal board for embedded Vitis platform developers. These files need to be copied to an SD flash card along with the platform specific boot image (boot.bin) available from the Vitis™ Embedded Platform page. Also included is the ‘sysroot’ required for embedded Vitis platform application development. The sdk.sh script must to be used to setup the compressed Yocto Project SDK on a Linux development host properly...PetaLinux Tools installation is not necessary to use the common images. Licenses and sources used to create the common image content is provided. This is a bit confusing. Which do we really need? Regarding Vivado v.s. Vitis, Digilent has a page of explanation: Fundamentally, the differences are down to the perspective of the developer using the tool. Vivado offers a hardware-centric approach to designing hardware, while Vitis offers a software-centric approach to developing *both* hardware and software. Sounds like we don't need Vitis stuff? 

To start the journey, I'm following UG1144 - PetaLinux Tools Documentation Reference Guide.

To setup working environment, run:

source <path-to-installed-PetaLinux>/settings.sh

To use PetaLinux SDK, run:

source <path-to-installed-PetaLinux>/components/yocto/buildtools/environment-setup-x86_64-petalinux-linux
The first is creating PetaLinux project with zc706 BSP:
petalinux-create -t project -s <path-to-bsp>

As the user guide said, using -p to specify the platform architecture, such as '-p arm' for Zynq and '-p aarch64' for Zynq UltraScale+ MPSoC, may save a little disk space. Also tftp server is preferred, Without a TFTP service, you cannot download Linux system images to the target system using the U-Boot network/TFTP capabilities. This can be ignored for other boot modes.

The user guide mentioned exporting hardware platform to PetaLinux project, which can be done from Vivado menu File=>Export=>Export Hardware=>choice of 'Pre-synthesis' and 'Include bitstream', no idea, so I selected the 2nd options to include more. This step generates rocketchip_wrapper.xsa file. 

The user guide also mentioned creating project with template, I guess that is for complexity, since I already created project from BSP, I don't see a need of that.

Run 'petalinux-config --get-hw-description ../fpga-zynq/zc706/zc706_rocketchip_ZynqFPGAConfig/rocketchip_wrapper.xsa' to launch system config. There is lot of setting, and likely can keep the default setting per the User Guide.

Run 'petalinux-build' to build images and it will take a while (will perform a lot of download as well), with 4232 tasks in my case.

The project folder will hold pre-built image once created, even before performing the build. Description of images can be found from the README under the root of the project. The build will generate new images to images/linux folder, such as: zynq_fsbl.elf, image.ub, zImage, uImage, u-boot.elf,  system.dtb, and rootfs.tar.gz, which might be the replacement of uramdisk.image.gz? The fpga-zynq project  zc706/fpga-images-zc706 contains files as:
boot.bif
boot.bin
devicetree.dtb
uImage
uramdisk.image.gz
boot_image
|-FSBL.elf
|-rocketchip_wrapper.bit
|-u-boot.elf

So the boot_image folder contains FSBL, FPGA bitstream and U-Boot.

The  uramdisk.image.gz seems is not a normal gzip archive as I cannot open it with 7-zip, therefore cannot confirm whether it is rootfs.tar.gz from the build. Following https://xilinx.github.io/Embedded-Design-Tutorials/docs/2022.1/build/html/docs/Introduction/Zynq7000-EDT/4-linux-for-zynq.html, I packed the boot.bin with following:

cd images/linux
petalinux-package --boot --fsbl zynq_fsbl.elf --fpga system.bit --u-boot u-boot.elf

Then copy the generated "BOOT.BIN" to SD card, yes, the name is all in capital.

Some Acronym for PetaLinux:

FSBL: First Stage BootLoader

PMU: Platform Management Unit, manage and perform the multi-staged booting process

TF-A: Trust Firmware-A, a transparent bare-metal application layer executed in Exception Level 3 (EL3) on the APU.

BIF: Bootgen Image Format

APU: Application Processing Unit

RPU: Realtime Processing Unit

MCS: might stand for Intel Micro Computer Set, which is file ext name for Intel Hex (refer to wikipedia)

Saturday, September 2, 2023

Developing code with WSL: 2 - Install docker

(continue of Developing code with WSL: 1 - Common problem)

The easy way to try docker with WSL would be installing Docker Desktop on host Windows. Some detail can be found from Microsoft tutorial site: Get started with Docker containers on WSL | Microsoft Learn. But if you prefer to decouple Docker with the host OS, just want to install everything under WSL, you can following Docker Linux installation instruction to just install Docker engine, such as instruction here: https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

When run  ~$ docker run hello-world, might get this:

docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.

If google this, may see this got asked on Stack Overflow: ubuntu - docker:Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

The suggestion there is run: systemctl start docker && systemctl enable docker. Then may get another error message:

System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
 

This is due to limitation of older version of WSL which does not support systemd, or systemd flag has not been set in WSL setting. In that case, try: sudo service docker start. Systemd is supported with WSL version 0.67.6 or newer(reference from Microsoft: Systemd support is now available in WSL! - Windows Command Line). As the link mentioned, if checking WSL version with 'wsl --version' failed, it means  you are running the in-Windows version of WSL and need to upgrade to the Store version.

To enable systemd:You will need to edit the wsl.conf file to ensure systemd starts up on boot.Add these lines to the /etc/wsl.conf with sudo:

[boot]
systemd=true

With that, run  ~$ docker run hello-world would get this:

~$ sudo docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
719385e32844: Pull complete
Digest: sha256:dcba6daec718f547568c562956fa47e1b03673dd010fe6ee58ca806767031d1c
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

If you prefer not to use 'sudo' for docker operation, may refer to this 'Ask Ubuntu' post. It works for docker 0.5.3 and up. Basically you would need to add the desired user to 'docker' group, like this:

sudo gpasswd -a $USER docker

Then re-login this user if it is the current user. For WSL, you can run 'logout' and you will automatically get re-login. After login, should be able to run docker command without 'sudo'.