You are here: Documentation » Training » Altera SoC Workshop Series » SoC SW Workshop Series Target Orientation

SoC SW Workshop Series Target Orientation
General advice, tips and tricks for using the default SD card images on the supported development boards.

23 April 2016 - 15:25 | Version 43 | Rod Frazer | SoCSWWorkshop

State:	running

<<<<<<<<<< Jump to Main Workshop Series Landing Page >>>>>>>>>>

Selecting and configuring a supported development board.
Creating a bootable SD card with the workshop image.
Workshop Linux environment overview.
Booting the target development board.
USB serial console interface.
Interacting with the USB gadget mass storage interface.
- On the target:
- On the host:
Interacting with the USB gadget networking interface.
Interacting with the USB gadget serial interface.
- On the target:
- On the host:
SSH terminal connection to target.
- On the host:
SCP file copy to target.
- On the host:
Interacting with the target file systems.
- On the target:
Interacting with the RJ-45 Ethernet network interface.
- With no DHCP server on the network.
- With DHCP server on the network.
Interacting with the target web server.

Selecting and configuring a supported development board.

You will need to obtain and configure one of the supported SoC development boards in order to complete the lab work for this workshop. The list of supported boards and their configuration requirements for the workshop lab environment is available on this page:

SoC SW Workshop Series Board Configuration

Creating a bootable SD card with the workshop image.

Once you have obtained your SoC development board and configured it to run the workshop environment you will need to download the SD card image for that board and program it onto the appropriate SD card for your board. You can download the SD card image and find instructions for programming the SD card on this page:

SoC SW Workshop Series SD Card Images

Workshop Linux environment overview.

The SoC SW Workshop SD card images are a 512MB image that consist of a 1MB 0xA2 partition for holding the preloader, a 256MB FAT partition which contains all the workshop boot material for all of the supported development boards, and a 255MB EXT3 partition which is currently unused.

The boot ROM loads the preloader programmed in the 0xA2 partition, and then the preloader loads the board specific u-boot out of the board specific directory on the FAT partition, then the board specific u-boot runs the u-boot.scr at the root of the FAT partition which loads the board specific RBF file and programs it into the FPGA. Then u-boot loads the board specific device tree blob from the board specfic directory and it loads the zImage and rootfs.img from the root of the FAT partition and it boots the kernel to run from the initramfs image in rootfs.img.

The target boots into the initramfs which is a RAM based file system. The SD card contains a FAT partition and an EXT3 partition which can be mounted, but are not required for the image to run. The USB gadget drivers are loaded and the mass storage and networking servcies are started over USB.

Booting the target development board.

To boot the target development board you can follow this rough procedure:

Program the SD card image onto the SD card as described on the page referenced above.
Insert the programmed SD card into the board
Plug the USB-UART cable into the board.
Plug the USB OTG device cable into the board.
Start a terminal program on your host and bind it to the USB UART interface so you can witness the boot messages from the target console interface.
Power up the board.

The following settings are used by the serial UART on the target:

8 data bits
1 stop bits
no parity
no hardware handshaking
115200 baud rate

Once the target board boots, you should be able to ssh into the target from the development host using the USB gadget network interface provided by the target and you should be able to mount the FAT patition on the SD card from the development host using the USB gadget mass storage device provided by the target. The USB gadget serial interface is also served up from the target, however you must configure a getty on the target first before the ACM interface may be used on your host. Guidance for all these activities is provided below.

USB serial console interface.

You should be able to see the linux boot messages displayed on the USB-UART serial console by using a terminal program on your development host, like Putty, or minicom. You could also use this serial console to interact with u-boot during the early boot phase, and once the target completely boots you should be able to interact with the linux command line prompt.

To run Putty as a terminal emulator for your target serial console connection, you can invoke it with these command line arguments. This assumes that your USB UART driver for the target has resolved to /dev/ttyUSB0.

putty \
   -T "/dev/ttyUSB0" \
   -serial \
   -sercfg 8,1,115200,n,N \
   -fn "Monospace 12" \
   -fg white \
   -bg black \
   -geometry 80x50 \
   -sl 5000 \
   /dev/ttyUSB0 &

If you have problems opening the serial device on your host, something like this:

This may mean that you do not have permissions to interact with the serial device on your host. In that case you could attempt to invoke putty with sudo so that you have root privileges to open the device, or you may wish to install some udev rules to allow a regular user to open the device, like this:

[~]$ cat /etc/udev/rules.d/52-ttyusb.rules
KERNEL=="ttyUSB*", MODE="0666"

Once you have successfully started your terminal program, you can power on your target development board and you should witness the boot messages from u-boot and linux as the board boots.Once you arrive at a linux prompt you can interact with the linux shell as you should normally expect.If you have previously powered your target board on, you may already be booted to a linux prompt and therefore will not witness any of the boot messages that have already passed, in this case you should press the enter key and see that you are actually as the linux command prompt.

Interacting with the USB gadget mass storage interface.

Please note that when you mount the USB gadget mass storage device on your development host as described below, the host believes that it "owns" that disk resource exclusively, and there are no inherent protections available to ensure that the host and the target may safely share the contents of the mass storage device simultaneously. There is a section provided below on this page that describes how to mount the FAT partition of the SD card on the target, if you were to do that simultaneiously with the host having mounted the partition as described in this section, you would be in the state that is warned about here and you should use caution when you find yourself in that state, otherwise you could corrupt the contents of the FAT partition.

On the target:

Your board should boot into linux and start the USB gadget drivers which should allow your development host to connect to the USB gadget as a network device and a mass storage device. The mass storage device should be assigned to the FAT partition of the SD card, which should be /dev/mmcblk0p1. This is done by the following command in the S70usbgadget startup script:

# cat /etc/init.d/S70usbgadget | grep "mmc"
                modprobe g_multi file=/dev/mmcblk0p1 cdrom=0 stall=0 removable=1 nofua=1 iSerialNumber=${SERIALNUMBER} iManufacturer=${MANUFACTURER} iProduct=${PRODUCT} host_addr=${DEV_ADDR}

When your taget boots, you should see the effect of the startup script above after it has started the "g_multi" driver, the sysfs entry for the gadget mass storage device should contain the SD card partition referenced above "/dev/mmcblk0p1":

# cat /sys/devices/platform/soc/ffb40000.usb/gadget/lun0/file
/dev/mmcblk0p1
#

****WARNING****

It should be noted that if your development host were to ever "eject" the mass storage device, this sysfs file entry will be set to NULL instead of the desired partition. For instance if you were to execute this command on your host, where /dev/sdc represents the USB gadget mass storage device:

[~]$ eject -s /dev/sdc
[~]$

Then you would no longer see the SD card partition stored in the sysfs file:

# cat /sys/devices/platform/soc/ffb40000.usb/gadget/lun0/file
#

To recover from this state, and allow the host to regain access to the FAT partition using the USB gadget mass storage device you can execute the following command on your target to restore the partion to sysfs file:

# echo -n "/dev/mmcblk0p1" > /sys/devices/platform/soc/ffb40000.usb/gadget/lun0/file
# cat /sys/devices/platform/soc/ffb40000.usb/gadget/lun0/file
/dev/mmcblk0p1
#

At this point the host should be able to access the USB gadget mass storage device again.

On the host:

First we need to identify which block device represents our USB partition on the host machine.

With the USB OTG cable unplugged, our system has no USB block devices identified.

[~]$ ls -l /sys/block/ | grep "usb"
[~]$ ls -l /sys/class/block/ | grep "usb"
[~]$

When we plug in our USB OTG cable from the target to our host, then we see one USB block device identified in our system.

[~]$ ls -l /sys/block/ | grep "usb"
lrwxrwxrwx 1 root root 0 Jun 8 01:23 sdc -> ../devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:2.4/host9/target9:0:0/9:0:0:0/block/sdc
[~]$ ls -l /sys/class/block/ | grep "usb"
lrwxrwxrwx 1 root root 0 Jun 8 01:23 sdc -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:2.4/host9/target9:0:0/9:0:0:0/block/sdc
[~]$

In this case it appears to be "sdc" so we should have a "/dev/sdc" block device.

[~]$ ls /dev/sdc
/dev/sdc
[~]$

And we should have a partition "sdc" in procfs.

[~]$ cat /proc/partitions | grep "sdc"
 8 32 262144 sdc
[~]$

Now that we know which block device represents our USB partition, we can mount it as follows:

[~]$ mkdir ~/myusbmnt                   # create a directory for our mount point
[~]$ ls ~/myusbmnt                      # initially it will be empty
[~]$ sudo mount /dev/sdc ~/myusbmnt/    # mount our USB partition
[~]$ ls ~/myusbmnt                      # now we should see the contents of the partition
ALTERA_AV_SOC                DE0_NANO_SOC      u-boot.scr
ALTERA_CV_SOC                hdl_src           WS1-IntroToSoC
ARROW_SOCKIT                 ip                WS2-IntroToLinux
board_info                   MACNICA_HELIO_14  WS3-DevelopingDrivers
boot.script                  patches           zImage.socfpga-3.10-ltsi
CRITICALLINK_MITYSOM_DEVKIT  rootfs.img
[~]$ sudo umount ~/myusbmnt             # when we finish with it, we can unmount it
[~]$ ls ~/myusbmnt                      # now our mount point will be empty again
[~]$ rm -rf ~/myusbmnt                  # and we can remove our directory
[~]$

****WARNING****

It should be noted that if you were to ever "eject" the mass storage device on the development host. For instance if you were to execute this command on your host, where /dev/sdc represents the USB gadget mass storage device:

[~]$ sudo eject -s /dev/sdc
[~]$

Then you would not be able to mount the USB mass storage device at all as shown above, instead you would likely get an error message like this:

[~]$ sudo mount /dev/sdc ~/myusbmnt/
mount: no medium found on /dev/sdc
[~]$

In this case, you should follow the advice provided above in the "On the target" section to repair the sysfs entry for the USB gadget mass storage file. Once you repair the sysfs file entry on the target, then you should again be able to mount the USB gadget mass storage device on the host as described above.

Interacting with the USB gadget networking interface.

On the target:

Your board should boot into linux and start the USB gadget drivers which should allow your development host to connect to the USB gadget as a network device and a mass storage device. The network device should be assigned to the usb0 network interface on your target. This is done by the following commands in the S70usbgadget startup script:

# cat /etc/init.d/S70usbgadget | grep "ifconfig"
 /sbin/ifconfig usb0 hw ether ${DEV_ADDR}
 /sbin/ifconfig usb0 192.168.7.1 netmask 255.255.255.0
#

Your board should startup the udhcpd daemon to act as a DHCP server on the target, the target's IP address was assigned manually in the statements above, and the host should allow it's USB network interface to automatically request a DHCP address from the target on the USB network interface. The DHCP daemon is started by the following command in the S70usbgadget startup script on the target:

# cat /etc/init.d/S70usbgadget | grep "start-stop-daemon"
 start-stop-daemon -S -x /usr/sbin/udhcpd -S /etc/udhcpd.conf
#

We can see our USB network interface information on the target with the following command:

# ifconfig usb0
usb0      Link encap:Ethernet  HWaddr 00:07:ED:01:02:03
          inet addr:192.168.7.1  Bcast:192.168.7.255  Mask:255.255.255.0
          inet6 addr: fe80::207:edff:fe01:203/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:580 errors:0 dropped:0 overruns:0 frame:0
          TX packets:507 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:67257 (65.6 KiB)  TX bytes:228297 (222.9 KiB)
#

From the above we can see that our target IP address is 192.168.7.1.

On the host:

First we need to identify which network device represents our USB network on the host machine.

With the USB OTG cable unplugged, our system has no USB network devices identified.

[~]$ ls -l /sys/class/net/ | grep "usb"
[~]$

When we plug in our USB OTG cable from the target to our host, then we see one USB network device identified in our system.

[~]$ ls -l /sys/class/net/ | grep "usb"
lrwxrwxrwx 1 root root 0 Jun 8 02:05 eth1 -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:2.0/net/eth1
[~]$

In this case it appears to be "eth1" so we should have a "eth1" network device.

[~]$ ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 192.168.7.9  netmask 255.255.255.0  broadcast 192.168.7.255
        inet6 fe80::207:edff:fe01:203  prefixlen 64  scopeid 0x20<link>
        ether 00:07:ed:01:02:03  txqueuelen 1000  (Ethernet)
        RX packets 2  bytes 400 (400.0 B)
        RX errors 0  dropped 0  overruns 0 frame 0
        TX packets 4  bytes 600 (600.0 B)
        TX errors 0  dropped 0  overruns 0  carrier 0  collisions 0
[~]$

From the above we can see that our host IP address is 192.168.7.9.

Networking between the host and target.

A simple test that we can perform to test the network connectivity between our host and target it to ping each end from the other.

On the target:

# ping -c 4 192.168.7.9
PING 192.168.7.9 (192.168.7.9) 56(84) bytes of data.
64 bytes from 192.168.7.9: icmp_seq=1 ttl=64 time=0.329 ms
64 bytes from 192.168.7.9: icmp_seq=2 ttl=64 time=0.189 ms
64 bytes from 192.168.7.9: icmp_seq=3 ttl=64 time=0.141 ms
64 bytes from 192.168.7.9: icmp_seq=4 ttl=64 time=0.178 ms

--- 192.168.7.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.141/0.209/0.329/0.072 ms
#

On the host:

[~]$ ping -c 4 192.168.7.1
PING 192.168.7.1 (192.168.7.1) 56(84) bytes of data.
64 bytes from 192.168.7.1: icmp_seq=1 ttl=64 time=0.162 ms
64 bytes from 192.168.7.1: icmp_seq=2 ttl=64 time=0.141 ms
64 bytes from 192.168.7.1: icmp_seq=3 ttl=64 time=0.173 ms
64 bytes from 192.168.7.1: icmp_seq=4 ttl=64 time=0.116 ms

--- 192.168.7.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.116/0.148/0.173/0.021 ms
[~]$

Interacting with the USB gadget serial interface.

When the target linux image boots on your development board, there is no getty bound to the USB gadget serial device on the target, so before you can do anything useful with the USB gadget serial interface from your host, you must first bind a getty session to the USB gadget serial interface on the target.

On the target:

The first thing you must do on the target is bind a getty session to the USB gadget serial driver so that the target can present a shell session to the remote host. In this example we do this by creating a shell script that we can run on the target, the shell script will continuously start a getty session and bind it to the USB gadget serial interface represented by /dev/ttyGS0 and it will not require any login on this getty, it will simply start a shell session and use vt100 terminal emulation over the connection. These commands can be used to create the shell script on the target:

# cd /root
# cat <<EOF > start_getty_for_acm.sh
#!/bin/sh

# this script will continuously start a getty session and bind it to the USB
# gadget serial interface device providing the ACM connection to the host.  The
# local device for the USB gadget serial interface is /dev/ttyGS0.

while [ true ]
do
        getty -L -n -l /bin/sh 115200 /dev/ttyGS0 vt100
done
EOF

Once the shell script is created, we can mark it as executable and run it as a background process so that it will continuously restart the getty session on the target if the user on the host ever exits the shell session running through the getty.

# chmod +x start_getty_for_acm.sh
# ./start_getty_for_acm.sh &

On the host:

To run Putty as a terminal emulator for your target USB gadget serial interface connection, you can invoke it with these command line arguments.This assumes that your USB gadget serial driver for the target has resolved to /dev/ttyACM0.

putty \
   -T "/dev/ttyACM0" \
   -serial \
   -sercfg 8,1,115200,n,N \
   -fn "Monospace 12" \
   -fg white \
   -bg black \
   -geometry 80x50 \
   -sl 5000 \
   /dev/ttyACM0 &

If you have problems opening the serial device on your host, something like this:

This may mean that you do not have permissions to interact with the serial device on your host.In that case you could attempt to invoke putty with sudo so that you have root privileges to open the device, or you may wish to install some udev rules to allow a regular user to open the device, like this:

[~]$ cat /etc/udev/rules.d/52-ttyacm.rules
KERNEL=="ttyACM*", MODE="0666"

Once you have successfully connected your terminal program on the host with the target serial interface you should have a standard shell session into the target running over that connection, and you can interact with the target as you would over any standard shell session. If you do successfully open the terminal program on your host but you do not see a shell session being served up by the target, then you may not have properly configured the getty session as described above on the target.

SSH terminal connection to target.

On the host:

Based on the target addressing that we determined above, we can ssh into the target at 192.168.7.1 like this:

[~]$ ssh root@192.168.7.1
Warning: Permanently added '192.168.7.1' (ECDSA) to the list of known hosts.

********************************************************************
Welcome to the SoC Workshop

The rootfs is a ram based filesystem built using Buildroot, no changes will survive a reboot

A good place to start is /readme.txt which provides some basic instructions and notes.  To read it, do the following:

less /readme.txt

'q' will quit from the above command

The root password is "password"
********************************************************************
root@192.168.7.1's password:

We enter the password for root which is 'password' and we should be logged in and we can begin interacting with the target.

********************************************************************
Welcome to the SoC Workshop

The rootfs is a ram based filesystem built using Buildroot, no changes will survive a reboot

A good place to start is /readme.txt which provides some basic instructions and notes.  To read it, do the following:

less /readme.txt

'q' will quit from the above command

The root password is "password"
********************************************************************
# pwd
/root
# ls
# touch test
# ls
test
# ls /
bin         home        linuxrc     proc        sbin        var
dev         init        media       readme.txt  sys         www
etc         lib         mnt         root        tmp
examples    lib32       opt         run         usr
# exit
Connection to 192.168.7.1 closed.
[~]$

Now ssh usually uses keys that it stores locally on your host system to ensure the identity of the remote system that you're logging into. You can see the statement above that references "Permanently added '192.168.7.1' (ECDSA) to the list of known hosts." Now if we reboot the target board and attempt to ssh into it again, we're likely to have a problem because every time we reboot the target a new ssh key is getting generated and that does not match what has been stored on our host machine. This effect is caused by the fact that we're booting into a ramfs, which cannot store the generated key from reboot to reboot. We see something like this:

[~]$ ssh root@192.168.7.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
f6:91:ce:67:c3:cb:2d:15:42:71:a7:5d:47:ca:4b:dd.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in ~/.ssh/known_hosts:24
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.

********************************************************************
Welcome to the SoC Workshop

The rootfs is a ram based filesystem built using Buildroot, no changes will survive a reboot

A good place to start is /readme.txt which provides some basic instructions and notes.  To read it, do the following:

less /readme.txt

'q' will quit from the above command

The root password is "password"
********************************************************************
Permission denied (publickey,password).
[~]$

Now to avoid this issue, we can use some command line arguments to ssh to avoid the key storing and authentication altogether. Like this:

[~]$ ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@192.168.7.1
Warning: Permanently added '192.168.7.1' (ECDSA) to the list of known hosts.

********************************************************************
Welcome to the SoC Workshop

The rootfs is a ram based filesystem built using Buildroot, no changes will survive a reboot

A good place to start is /readme.txt which provides some basic instructions and notes.  To read it, do the following:

less /readme.txt

'q' will quit from the above command

The root password is "password"
********************************************************************
root@192.168.7.1's password: 

********************************************************************
Welcome to the SoC Workshop

The rootfs is a ram based filesystem built using Buildroot, no changes will survive a reboot

A good place to start is /readme.txt which provides some basic instructions and notes.  To read it, do the following:

less /readme.txt

'q' will quit from the above command

The root password is "password"
********************************************************************
# ls
# pwd
/root
# exit
Connection to 192.168.7.1 closed.
[~]$

SCP file copy to target.

On the host:

Based on the target addressing that we determined above, we can scp with the target at 192.168.7.1. We can copy a file to the target like this:

[~]$ touch ~/scp_test
[~]$ scp ~/scp_test root@192.168.7.1:/root/scp_test_to_target
Warning: Permanently added '192.168.7.1' (ECDSA) to the list of known hosts.

********************************************************************
Welcome to the SoC Workshop

The rootfs is a ram based filesystem built using Buildroot, no changes will survive a reboot

A good place to start is /readme.txt which provides some basic instructions and notes.  To read it, do the following:

less /readme.txt

'q' will quit from the above command

The root password is "password"
********************************************************************
root@192.168.7.1's password: 
scp_test                                      100%    0     0.0KB/s   00:00    
[~]$

We can copy a file from the target like this:

[~]$ scp root@192.168.7.1:/root/scp_test_to_target ~/scp_test_from_target

********************************************************************
Welcome to the SoC Workshop

The rootfs is a ram based filesystem built using Buildroot, no changes will survive a reboot

A good place to start is /readme.txt which provides some basic instructions and notes.  To read it, do the following:

less /readme.txt

'q' will quit from the above command

The root password is "password"
********************************************************************
root@192.168.7.1's password: 
scp_test_to_target                            100%    0     0.0KB/s   00:00    
[~]$

We can verify the copy occurred as we expect like this:

[~]$ ls ~/scp_test*
~/scp_test  ~/scp_test_from_target
[~]$ rm ~/scp_test_from_target 
[~]$

Now scp usually uses keys that it stores locally on your host system to ensure the identity of the remote system that you're logging into. You can see the statement above that references "Permanently added '192.168.7.1' (ECDSA) to the list of known hosts." Now if we reboot the target board and attempt to scp with it again, we're likely to have a problem because every time we reboot the target a new scp key is getting generated and that does not match what has been stored on our host machine. This effect is caused by the fact that we're booting into a ramfs, which cannot store the generated key from reboot to reboot. We see something like this:

[~]$ scp ~/scp_test root@192.168.7.1:/root/scp_test_to_target
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
7a:aa:76:55:7b:89:a1:8a:a5:b7:dd:da:50:19:c8:eb.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in ~/.ssh/known_hosts:24
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.

********************************************************************
Welcome to the SoC Workshop

The rootfs is a ram based filesystem built using Buildroot, no changes will survive a reboot

A good place to start is /readme.txt which provides some basic instructions and notes.  To read it, do the following:

less /readme.txt

'q' will quit from the above command

The root password is "password"
********************************************************************
Permission denied (publickey,password).
lost connection
[~]$

Now to avoid this issue, we can use some command line arguments to scp to avoid the key storing and authentication altogether. Like this:

[~]$ scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ~/scp_test root@192.168.7.1:/root/scp_test_to_target
Warning: Permanently added '192.168.7.1' (ECDSA) to the list of known hosts.

********************************************************************
Welcome to the SoC Workshop

The rootfs is a ram based filesystem built using Buildroot, no changes will survive a reboot

A good place to start is /readme.txt which provides some basic instructions and notes.  To read it, do the following:

less /readme.txt

'q' will quit from the above command

The root password is "password"
********************************************************************
root@192.168.7.1's password: 
scp_test                                      100%    0     0.0KB/s   00:00    
[~]$ scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@192.168.7.1:/root/scp_test_to_target ~/scp_test_from_target
Warning: Permanently added '192.168.7.1' (ECDSA) to the list of known hosts.

********************************************************************
Welcome to the SoC Workshop

The rootfs is a ram based filesystem built using Buildroot, no changes will survive a reboot

A good place to start is /readme.txt which provides some basic instructions and notes.  To read it, do the following:

less /readme.txt

'q' will quit from the above command

The root password is "password"
********************************************************************
root@192.168.7.1's password: 
scp_test_to_target                            100%    0     0.0KB/s   00:00    
[~]$ ls ~/scp_test*
~/scp_test  ~/scp_test_from_target
[~]$ rm ~/scp_test*
[~]$

Interacting with the target file systems.

Please note that when you mount the SD card FAT partition on your development target as described below, the target believes that it "owns" that disk resource exclusively, and there are no inherent protections available to ensure that the host and the target may safely share the contents of the FAT partition simultaneously. There is a section provided above on this page that describes how to mount the FAT partition as a USB gadget mass storage device on the host, if you were to do that simultaneiously with the target having mounted the FAT partition as described in this section, you would be in the state that is warned about here and you should use caution when you find yourself in that state, otherwise you could corrupt the contents of the FAT partition.

The target boots into an initramfs root file system, however there are three partitions on the SD card which you can interact with as block devices, the preloader partition 0xA2, a FAT partition and an EXT3 partition.

On the target:

Our SD card is recognized as /dev/mmcblk0 in our target system. We should see these device nodes for the SD card and each partition on it.

# ls /dev/mmcblk0*
/dev/mmcblk0    /dev/mmcblk0p1  /dev/mmcblk0p2  /dev/mmcblk0p3
#

We can also see these in the sysfs.

# ls /sys/class/block/mmcblk0 | grep mmc
mmcblk0p1
mmcblk0p2
mmcblk0p3
#

We can use fdisk to see what the partition formats are:

# fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 3980 MB, 3980394496 bytes
4 heads, 16 sectors/track, 121472 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1              65        8256      262144   b Win95 FAT32
Partition 1 does not end on cylinder boundary
/dev/mmcblk0p2            8257       16384      260096  83 Linux
Partition 2 does not end on cylinder boundary
/dev/mmcblk0p3              33          64        1024  a2 Unknown
Partition 3 does not end on cylinder boundary

Partition table entries are not in disk order
#

So now that we know how our partitions are mapped, we can mount them and interact with them:

# mkdir /mnt/fat
# mkdir /mnt/ext3
# mount /dev/mmcblk0p1 /mnt/fat
# mount /dev/mmcblk0p2 /mnt/ext3
kjournald starting.  Commit interval 5 seconds
EXT3-fs (mmcblk0p2): using internal journal
EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode
# ls /mnt/fat
ALTERA_AV_SOC                board_info
ALTERA_CV_SOC                boot.script
ARROW_SOCKIT                 hdl_src
CRITICALLINK_MITYSOM_DEVKIT  ip
DE0_NANO_SOC                 patches
MACNICA_HELIO_14             rootfs.img
WS1-IntroToSoC               u-boot.scr
WS2-IntroToLinux             zImage.socfpga-3.10-ltsi
WS3-DevelopingDrivers
# ls /mnt/ext3
lost+found
# umount /mnt/fat
# umount /mnt/ext3/
# ls /mnt/fat
# ls /mnt/ext3
# rm -rf /mnt/fat
# rm -rf /mnt/ext3/
#

If we wish to interact with the preloader partition, type 0xA2, we can't really mount it because there's no formal file system on it, but we can interact with it as a block device.

# dd if=/dev/mmcblk0p3 bs=64k count=1 | strings | grep "SPL"
1+0 records in
1+0 records out
U-Boot SPL 2013.01.01 (May 18 2015 - 13:42:31)
#

Interacting with the RJ-45 Ethernet network interface.

With no DHCP server on the network.

When you boot the target while connected to a network with no DHCP service available on the network, the target should come up and the Ethernet link should come up, but there is no network configuration applied to the "eth0" network interface. For instance:

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:07:ED:5C:44:A6
          inet6 addr: fe80::207:edff:fe5c:44a6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:1494 (1.4 KiB)
          Interrupt:152 Base address:0x8000

#

To manually configure the eth0 interface you can issue an "ifconfig" command like this:

# ifconfig eth0 10.42.0.181 up
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:07:ED:5C:44:A6
          inet addr:10.42.0.181  Bcast:10.255.255.255  Mask:255.0.0.0
          inet6 addr: fe80::207:edff:fe5c:44a6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:1494 (1.4 KiB)
          Interrupt:152 Base address:0x8000

#

And now you should be able to interact over the network, like this where we have a remote host at 10.42.0.1:

# ping -c 4 10.42.0.1
PING 10.42.0.1 (10.42.0.1) 56(84) bytes of data.
64 bytes from 10.42.0.1: icmp_seq=1 ttl=64 time=1.67 ms
64 bytes from 10.42.0.1: icmp_seq=2 ttl=64 time=0.807 ms
64 bytes from 10.42.0.1: icmp_seq=3 ttl=64 time=0.893 ms
64 bytes from 10.42.0.1: icmp_seq=4 ttl=64 time=0.872 ms

--- 10.42.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.807/1.060/1.671/0.355 ms
#

If you happen to boot your target prior to connecting to the Ethernet network, the network configuration will not be applied, just as above. When you ultimately connect the Ethernet cable into the network you should see this as the link comes up:

# libphy: stmmac-1:01 - Link is Up - 1000/Full

The network interface is still not configured but at this point you can manually configure it using the "ifconfig" command just as we showed above.

With DHCP server on the network.

When you boot the target while connected to a network with DHCP service available on the network, the target should come up and the Ethernet link should come up, and the network configuration applied to the "eth0" interface should have been retrieved by the DHCP client, so you should have an IP address and be ready to interact with the network. For instance:

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:07:ED:5C:44:A6
          inet addr:10.42.0.181  Bcast:10.42.0.255  Mask:255.255.255.0
          inet6 addr: fe80::207:edff:fe5c:44a6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:744 (744.0 B)  TX bytes:1536 (1.5 KiB)
          Interrupt:152 Base address:0x8000

# ping -c 4 10.42.0.1
PING 10.42.0.1 (10.42.0.1) 56(84) bytes of data.
64 bytes from 10.42.0.1: icmp_seq=1 ttl=64 time=0.823 ms
64 bytes from 10.42.0.1: icmp_seq=2 ttl=64 time=0.805 ms
64 bytes from 10.42.0.1: icmp_seq=3 ttl=64 time=0.817 ms
64 bytes from 10.42.0.1: icmp_seq=4 ttl=64 time=0.941 ms

--- 10.42.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.805/0.846/0.941/0.062 ms
#

If you happen to boot your target prior to connecting to the Ethernet network, the network configuration will not be applied.

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:07:ED:5C:44:A6
          inet6 addr: fe80::207:edff:fe5c:44a6/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:580 (580.0 B)
          Interrupt:152 Base address:0x8000

#

When you ultimately connect the Ethernet cable into the network you should see this as the link comes up:

# libphy: stmmac-1:01 - Link is Up - 1000/Full

At this point the network interface is still not configured.

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:07:ED:5C:44:A6
          inet6 addr: fe80::207:edff:fe5c:44a6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:698 (698.0 B)  TX bytes:1606 (1.5 KiB)
          Interrupt:152 Base address:0x8000

#

We can run the "ifup" command to bring up the "eth0" interface and query the DHCP server for our local configuration like this:

# ifup eth0
udhcpc (v1.22.1) started
Sending discover...
Sending select for 10.42.0.181...
Lease of 10.42.0.181 obtained, lease time 3600
deleting routers
adding dns 10.42.0.1
#
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:07:ED:5C:44:A6
          inet addr:10.42.0.181  Bcast:10.42.0.255  Mask:255.255.255.0
          inet6 addr: fe80::207:edff:fe5c:44a6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2731 (2.6 KiB)  TX bytes:3358 (3.2 KiB)
          Interrupt:152 Base address:0x8000

#

And now we can use the network just as before.

# ping -c 4 10.42.0.1
PING 10.42.0.1 (10.42.0.1) 56(84) bytes of data.
64 bytes from 10.42.0.1: icmp_seq=1 ttl=64 time=0.944 ms
64 bytes from 10.42.0.1: icmp_seq=2 ttl=64 time=0.872 ms
64 bytes from 10.42.0.1: icmp_seq=3 ttl=64 time=0.867 ms
64 bytes from 10.42.0.1: icmp_seq=4 ttl=64 time=0.927 ms

--- 10.42.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.867/0.902/0.944/0.045 ms
#

Interacting with the target web server.

The lighttpd web server is running on the workshop target. To see the web server contents point your browser to the IP address of your target board once you have a valid network connection between your development host and target. This content is served up from the /www/pages directory on the target system, and should look something like this in your web browser:

<<<<<<<<<< Jump to Main Workshop Series Landing Page >>>>>>>>>>

This website is using cookies. More info. That's Fine

SoC SW Workshop Series Target Orientation General advice, tips and tricks for using the default SD card images on the supported development boards.

<<<<<<<<<< Jump to Main Workshop Series Landing Page >>>>>>>>>>

Selecting and configuring a supported development board.

Creating a bootable SD card with the workshop image.

Workshop Linux environment overview.

Booting the target development board.

USB serial console interface.

Interacting with the USB gadget mass storage interface.

On the target:

On the host:

Interacting with the USB gadget networking interface.

On the target:

On the host:

Networking between the host and target.

On the target:

On the host:

Interacting with the USB gadget serial interface.

On the target:

On the host:

SSH terminal connection to target.

On the host:

SCP file copy to target.

On the host:

Interacting with the target file systems.

On the target:

Interacting with the RJ-45 Ethernet network interface.

With no DHCP server on the network.

With DHCP server on the network.

Interacting with the target web server.

<<<<<<<<<< Jump to Main Workshop Series Landing Page >>>>>>>>>>

Attachments ($count)

SoC SW Workshop Series Target Orientation
General advice, tips and tricks for using the default SD card images on the supported development boards.