ONetSwitch30

2016-02-02T05:02:34Z

Youkee: /* Overview */

= ONetSwitch30 =

== Overview ==

[[File:1-85.jpg|500px]]

'''ONetSwitch30''' is an All Programmable open networking innovation platform.

'''ONetSwitch30''' is based on the Xilinx Zynq-7000 SoC, and mainly adopts the Gigabit ports. It can achieve a comprehensive experiment platform integrating calculations, storage, networks and interconnection by extension. Both its software and hardware can realize custom programming. Its reference designs are abundant and flexible, can be used to various researches on the evolution of network prototypes, and the development of customized network products. Especially, the features of the miniaturization and low power are adapted to the multi-node network tests and deployments.

[[File:1-86.jpg]]

== Features ==

* General
* Main Silicon ''XC7Z030-2SBG485''
* Power Supply ''DC 12V''
* Primary Config. ''TF card''
* Auxiliary Config. ''QSPI flash/JTAG''
* Processing System
* Processor _Dual ARM Cortex-A9@800MHz_
* Cache ''(L1)32KB Inst. + 32KB Data per core; (L2)512KB; (OCM)256KB''
* DRAM ''DDR3 1GBytes''
* Flash ''Quad SPI flash 256Mb''
* DMA ''8 channel (4 for Programmable Logic)''
* Ethernet ''1x GE RJ45''
* Peripherals ''USB / USB-UART / USB JTAG / TF card''
* Programmable Logic
* FPGA Logic ''125K LCs, Kintex-7, ~1.9M ASIC gates''
* Host I/F ''AMBA AXI4 interconnect, max 100Gbps between PS-PL''
* DRAM ''DDR3 2GBytes''
* Ethernet ''4x GE RJ45''
* Peripherals ''2x PMOD''
* User IO ''user LEDs/push buttons/DIP switch''
* Extension ''mini PCIe for wireless NIC or SSD''

== Block Diagram ==

[[File:1-82.png]]

== Board Layout ==

[[File:1-83.png]]

[[File:1-84.png]]

== Specification ==

For details of the board hardware, please download the [https://github.com/MeshSr/wiki/blob/master/doc/msr-ons30-hwug.pdf ONetSwitch30 Hardware User Guide].

= workflow =
== Overview ==

A bottom-up approach is recommended when developing on the Xilinx Zynq SoC-based ONetSwitch. 
The figure below from [http://www.wiki.xilinx.com/ Xilinx Wiki] shows a high level block diagram of the Xilinx design flow for Zynq AP SoC.

[[File:1-87.png]

For any layer or component in this hierarchy, you can either download the pre-built images for quick use, or modify then generate it by yourself in the way described below.

== Get Prepared ==

* Prepare the Boot Medium 
Xilinx Zynq SoC offers different types for system booting, on your demand. 
Here in the GitHub for an ONetSwitch, '''the SD boot is chosen as default'''. An FAT partition in the size of 512MB is used for storing the boot and kernel images, while an EXT partition typically larger than 1GB is for the root file system and the applications(e.g. OpenFlow switch software). 
For the detailed how-to, please refer to Xilinx Wiki [http://www.wiki.xilinx.com/Prepare+Boot+Medium Prepare Boot Medium]. 

* Setup a Serial Console 
It is a must to use the USB-UART when running an interactive program on the platform or debugging. Here's a helpful link on Xilinx Wiki [http://www.wiki.xilinx.com/Setup+a+Serial+Console Setup a Serial Console]. 

* Get a Linux Environment 
Software development on ONetSwitch requires a Linux environment for easy cross compilation. 
Ubuntu 12.04 LTS x86_64 may lack some needed 32-bit libraries. This can be fixed by installing <tt>ia32-libs</tt>. 
Ubuntu 14.04 LTS x86_64 may also lack some needed 32-bit libraries. This can be fixed by installing <tt>libc6-i386</tt>.
* Install Xilinx Tools 
Xilinx Vivado and SDK must be installed for ONetSwitch development. [http://www.xilinx.com/support/download.html Download] 
Notice that, by 2014 Q4, all our projects are developed with Vivado 2013.4. 
When working in a Linux environment, especially for software developers, remember to setup the environment variables for cross compiler and the Vivado/SDK tools.

<source lang="bash">export CROSS_COMPILE=arm-xilinx-linux-gnueabi-
source <path-to-installation>/Vivado/<version>/settings32.sh # OR
source <path-to-installation>/Vivado/<version>/settings64.sh</source>
== Use Pre-Built Images ==

The pre-built images can be fetched mainly from 
* [https://github.com/MeshSr/common-bin common-bin] 
This repo stores the common FSBL, SSBL(u-boot), Linux kernel(uImage) and root file system(rootfs), as well as the SDN/OpenFlow executables. It is easy to find them in the repo according to the folder and file names. 
The boot loaders are board-dedicated, while the kernel image and the rootfs are applicable to all ONetSwitch boards. 
* ready-to-download 
This is a sub-folder associated with each project, usually contains the FPGA image(system.bit) and the project-specific devicetree blob(devicetree.dtb). 
The boot.bin, which is created by Xilinx SDK, always consists of the common FSBL and u-boot from common-bin above, and the project-specific system.bit.

An example here to prepare for an OpenFlow software switch (ofs-sw) on ONetSwitch30 using pre-built images. 
You need to collect following items and make copies of them to the FAT partition.

| File | Repo | Link | | ---- | ---- | ---- | | boot.bin | onetswitch30 | [https://github.com/MeshSr/onetswitch30/blob/master/ons30-app51-ref_ofssw/ready-to-download/boot.bin ready-to-download/boot.bin] | 
| devicetree | onetswitch30 | [https://github.com/MeshSr/onetswitch30/blob/master/ons30-app51-ref_ofssw/ready-to-download/devicetree.dtb ready-to-download/devicetree.dtb] | 
| kernel | common-bin | [https://github.com/MeshSr/common-bin/blob/master/kernel/uImage kernel/uImage] |

You need also to extract the compressed rootfs to the EXT partition and then put the application images to somewhere in the extracted folder structure. 
In this example, some runtime libs are required so the sw-lib is copied as well.

| File | Repo | Link | | ---- | ---- | ---- | | rootfs (EXT) | common-bin | [https://github.com/MeshSr/common-bin/blob/master/rootfs/rootfs_ext4.tar.gz rootfs/rootfs_ext4.tar.gz] | | sw-lib | common-bin | [https://github.com/MeshSr/common-bin/tree/master/lib lib/*]| | sw-app | common-bin | [https://github.com/MeshSr/common-bin/tree/master/ofs-sw ofs-sw/*] |

Notice that, all the boot.bin are prepared to start the kernel in the EXT partition, using the pre-built u-boot with suffix -ext.elf in its file name. If you want to simply run all in an FAT partition, rootfs as uramdisk and the u-boot with suffix -ram.elf. The FPGA image should be used in the boot.bin regeneration.

| File | Repo | Link | | ---- | ---- | ---- | | system.bit | onetswitch30 | [https://github.com/MeshSr/onetswitch30/blob/master/ons30-app51-ref_ofssw/ready-to-download/res/onetswitch_top.bit ready-to-download/res/onetswitch_top.bit] | | fsbl | common-bin | [https://github.com/MeshSr/common-bin/blob/master/fsbl/fsbl-ons30.elf fsbl/fsbl-ons30.elf] | | u-boot (FAT) | common-bin | [https://github.com/MeshSr/common-bin/blob/master/u-boot/u-boot-ons30-ram.elf u-boot/u-boot-ons30-ram.elf] | | u-boot (EXT) | common-bin | [https://github.com/MeshSr/common-bin/blob/master/u-boot/u-boot-ons30-ext.elf u-boot/u-boot-ons30-ext.elf] | | rootfs (FAT) | common-bin | [https://github.com/MeshSr/common-bin/blob/master/rootfs/uramdisk.image.gz rootfs/uramdisk.image.gz] |

== Build the System ==

=== Zynq Hardware Design ===

The Zynq hardware design generates the system.bit, defining the ARM CPU settings in Zynq PS and the FPGA bitstream in Zynq PL. 
* Create IP cores and hardware design * Configure the processor * Add and integrate IP cores * Generate the bitstream * Export the hardware design to SDK

The entire process is implemented in Xilinx Vivado tool. See more information in our [https://github.com/MeshSr/wiki/wiki/Guide-Hardware-Design Hardware Design Guide].

=== Zynq Software Design ===

The Zynq software design introduces several steps to build up an entire embedded system, from boot loader to Linux kernel, including * First stage boot loader, FSBL * Second stage boot loader, SSBL, using u-boot * Root file system, rootfs * Device tree * Linux kernel

The process needs Xilinx SDK, and working environment in Linux with cross compiler installed. See more information in our [https://github.com/MeshSr/wiki/wiki/Guide-Software-Design Software Design Guide].

=== Application Design ===

The applications, often the final target what we want, run on top of the OS (Linux as we mentioned above, or any others from 'bare-metal' to Android.) 
For SDN/OpenFlow application, we have done following and hope to get more from you. 
* A vSwitch running a CPqD ofsoftswitch13 ported to ARM [https://github.com/MeshSr/ofs-sw <tt>ofs-sw</tt>] 
* An FPGA accelerated OFS, with both HW and SW flow tables [https://github.com/MeshSr/ofs-hw <tt>ofs-hw</tt>]

== Integrate and Test ==

=== Prepare the Boot Image ===

The boot image, boot.bin, is created in Xilinx SDK, by assembling the FSBL, the FPGA image, and the SSBL in sequence. 
1. Select 'Xilinx Tools' from the SDK menu 
2. Choose 'Create Zynq Boot Image', a pop-up appears 
3. Add ''fsbl.elf'', ''system.bit'', ''u-boot.elf'' sequentially 
4. Click 'Create Image' and wait for the generation 
5. Rename the output binary to ''boot.bin''

=== Use the Test Sequence ===

Project-specific test sequence is provided as a demo. It mainly shows the usage of the board and the features of the application. 
Try the test sequence and check the results.

= Prepare Boot Medium =

== Input Files Required ==

# [https://raw.githubusercontent.com/MeshSr/onetswitch30/master/ons30-app11-ref_nic/ready-to-download/boot.bin Precompiled boot.bin for Reference NIC demo]
# [https://github.com/MeshSr/common-bin/tree/master/kernel Precompiled uImage]
# [https://github.com/MeshSr/common-bin/tree/master/rootfs rootfs]

== Output Files Produced ==

# bootable SD card

== Task Description ==

The following instructions are taken from the OMAPPedia wiki.

The following instructions assume a Linux system. Furthermore, most commands require root permissions. After completing this steps the SD card holds two partitions which can be read/written under Linux. Windows can - if at all - only access the FAT partition; but even this seems to depend on the card reader/driver used.

Insert SD card and figure out the corresponding device. The last lines of the dmesg output should tell you under which device file the inserted SD card is available in the system. dmesg

Warning: The following commands will use '/dev/sdX' to refer to the SD card device. Replace this with the actual device on your system. Executing the following commands on the wrong device may corrupt your data on other file systems. Also, all data on your SD card will be destroyed.

The fdisk utility does not seem to erase the first few bytes of the first sector in the card when the partition table is saved. Use dd to erase the first sector. <tt>dd if=/dev/zero of=/dev/sdX bs=1024 count=1</tt>

Calculate the new_cylinders value <tt>fdisk -l /dev/sdX</tt>

The output should look similar to this > Disk /dev/sdb: 8068 MB, 8068792320 bytes 
249 heads, 62 sectors/track, 1020 cylinders, total 15759360 sectors 
Units = sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

Look for the size of the device in bytes and calculate the new number of cylinders using the following formula, dropping all fractions: > new_cylinders = <size> / 8225280

For the example output given above, we would write down '''new_cylinders = 8068792320 / 8225280 = 980'''.

Partition the SD card. We will create two partitions on the SD card. One 200 MB sized boot partition. And a second partition taking the remaining space on the SD card.

<tt>fdisk /dev/sdX</tt>

The dd command should have wiped all existing partition tables, if this is not the case, delete all existing partitions on the SD card. >Command (m for help): 
Partition number (1-4): 1 
Repeat this for all valid partitions numbers.

<blockquote>Now configure the sectors, heads and cylinders of the SD card. 
Command (m for help): x 
Expert command (m for help): h 
Number of heads (1-256, default 30): 255 
Expert command (m for help): s 
Number of sectors (1-63, default 29): 63 
Expert command (m for help): c 
Number of cylinders (1-1048576, default 2286): <new_cylinders calculated from above> 
Command (m for help): r
</blockquote>
Now the actual partitions can be created 
>Command (m for help): n 
Partition type: 
p primary (0 primary, 0 extended, 4 free) 
e extended 
Select (default p): p 
Partition number (1-4, default 1): 1 
First sector (2048-15759359, default 2048): 
Using default value 2048 
Last sector, +sectors or +size{K,M,G} (2048-15759359, default 15759359): +200M

Command (m for help): n 
Partition type: 
p primary (1 primary, 0 extended, 3 free) 
e extended 
Select (default p): p 
Partition number (1-4, default 2): 2 
First sector (411648-15759359, default 411648): 
Using default value 411648 
Last sector, +sectors or +size{K,M,G} (411648-15759359, default 15759359): 
Using default value 15759359

Now, set the bootable flag and partition IDs >Command (m for help): a 
Partition number (1-4): 1

Command (m for help): t 
Partition number (1-4): 1 
Hex code (type L to list codes): c 
Changed system type of partition 1 to c (W95 FAT32 (LBA))

Command (m for help): t 
Partition number (1-4): 2 
Hex code (type L to list codes): 83

Check the new partition table and write the changes >Command (m for help): p

Disk /dev/sdb: 8068 MB, 8068792320 bytes 
249 heads, 62 sectors/track, 1020 cylinders, total 15759360 sectors 
Units = sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disk identifier: 0x920c958b

Device Boot Start End Blocks Id System 
/dev/sdb1 * 2048 411647 204800 c W95 FAT32 (LBA) 
/dev/sdb2 411648 15759359 7673856 83 Linux

Command (m for help): w 
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x 
partitions, please see the fdisk manual page for additional 
information. 
Syncing disks.

Create file systems on the new partitions <tt>mkfs.vfat -F 32 -n boot /dev/sdX1 mkfs.ext4 -L root /dev/sdX2</tt>

Mount the boot partition <tt>mkdir -p /mnt/boot mount /dev/sdX1 /mnt/boot</tt> Copy the boot.bin or contents of the release archive to the SD card, e.g. <tt>cp boot.bin /mnt/boot/</tt>

Unmount the SD card <tt>umount /mnt/boot</tt>

The SD card can now be removed and transferred over to the target platform.

== Ref: ==

# http://www.wiki.xilinx.com/Prepare+Boot+Medium

= Quick Start =

=== Intro ===

An ONetSwitch enables users in different development roles to build a complete networking system in a single node. Users can build the embedded system either from scratch, or based on some pre-built images. 
In either way, getting-started projects would help you * to get acquainted with the board and its components 
* to make quick hardware tests on the main silicon and its peripherals 
* to understand the usage and be ready for next-stage development

=== Project List ===

* [https://github.com/MeshSr/wiki/wiki/GSG-ZynqPSTest Zynq PS Test] 
''Project to verify the clocks, resets, memories, etc at the ARM CPU side.'' 

* [https://github.com/MeshSr/wiki/wiki/GSG-IBERT IBERT] 
''Project to verify the rate and SI of the transceivers using PRBS generator.'' 

* [https://github.com/MeshSr/wiki/wiki/GSG-MACLoopBack MAC Loopback] 
''Project to verify the PHYs and the MACs on each of the Ethernet ports.'' 

* [https://github.com/MeshSr/wiki/wiki/GSG-PCIeRootEnum PCIe Enumeration] 
''Project to verify the Mini PCIe and the configuration of PCIe Root Complex.'' 

* [https://github.com/MeshSr/wiki/wiki/GSG-QDRIIMemTest QDRII+ Memory Test] 
''Project to verify the calibration of PL QDRII+ SRAM, with traffic generator.'' 

* [https://github.com/MeshSr/wiki/wiki/GSG-DDR3MemTest DDR3 Memory Test] 
''Project to verify the calibration and read/write operations on PL DDR3 SDRAM.''

The table below shows the applicability.

[[File:1-87.jpg]]

Mbed BLE Sensors Tag

2015-11-24T01:56:07Z

Youkee:

== Introduction ==

This is a shield to add a RS485 level shift to the UART of Raspberry Pi. Moreover, it also breakout the rest headers for easy access.

It's a new version which compatible with Raspberry Pi B+ .

[[File:RS485 V3 for RPi_1.jpg]]

[[File:RS485 V3 for RPi_2.jpg]]

[[File:RS485 V3 for RPi_3.jpg]]

== Schematics ==

*[https://s3.amazonaws.com/linksprite/Shields/RS485_RPI/RS485+Shield+for+RPi+B%2B.PDF schematics]

== Usage ==

The UART on Raspberry Pi is on P1 and shown below:

[[File:RPI UART.png]]

The UART is /dev/ttyAMAO, it defaults to output system log. But if user wants to use this UART to connect to other modules through UART, for example, GPS module, we need to change the configuration.

The detailed steps are as following:

We need to modify two files: /boot/cmdline.txt and /etc/inittab.

Modify /boot/cmdline.txt:

Replace the original content:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

With:

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Modify /etc/inittab:

Comment out the last line of /etc/inittab. To comment out, it simply addess a '#'.

$ sudo vi /etc/inittab
#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Save the changes, and reboot. We will get an UART with baud rate of 115200.

== Resources ==

*[http://learn.linksprite.com/raspberry-pi/shield/user-tips-of-rs485-shield-for-rpi/ User Guide of RS485 Shield for Raspberry Pi]