Version: | 2.0.0A |
---|---|
Copyright: | (C)2016 Avnet Silica company |
Date: | 13/02/2015 |
If you are a new user of the Yocto based SDK we suggest you to read the Quick start guide chapter, otherwise, if you want to have a better understanding of specific topics, just jump directly to the chapter that interests you the most.
Furthermore, we encourage you to read the official Yocto Project documentation.
Throughout this guide, there are commands, file system paths, etc., that can either refer to the machine (real or virtual) you use to run the SDK or to the board.
Host
This box will be used to refer to the machine running the SDK
Board
This box will be used to refer to Pengwyn board
However, the previous notations can make you struggle with long lines. In such a case, the following notation is used.
This Box will be used where long lines need to be displayed, as well as with system paths, commands, configuration files, etc.
All related to the host.
It will be used to display code example as well.
The same facility will be used, when needed, for the board.
If you click on select on the top right corner of these two last boxes, you will get the text inside the box selected. We have to warn you that your browser might select the line numbers as well, so, the first time you use such a feature, you are invited to check it.
Sometimes, when referring to file system paths, the path starts with /path/to. In such a case, the documentation is NOT referring to a physical file system path, it just means you need to read the path, understand what it means, and understand what is the proper path on your system. For example, when referring to the device file associated to your USB flash memory you could read something like this in the documentation:
/path/to/your/USB/device
Since things are different from one machine to another, you need to understand its meaning and corresponding value for your machine, like for example:
/dev/sdb
When referring to a specific partition of a device, you could read something like this in the documentation:
/path/to/your/USB/device/partition
Even in this case, the things are different from one machine to another, like for example:
we are referring to the device /dev/sdb and in the specific to the partition 1. To know more details please refer to device files section of the appendix.
This powerful board comes with this beautiful box
Pengwyn takes the power from the mini-USB connector CN6 and/or connector CN1. The board is not shipped with an external power adapter.
The NAND on the board has been programmed to let Pengwyn boot a qt4e-demo-image-pengwyn image generated with Yocto.
What are we waiting for? Lets boot the board!
which you can connect, by means of a mini-USB cable, to your personal computer.
Note
Every operating system has its own killer application to give you a serial terminal interface. In this guide, we are assuming your host operating system is Ubuntu.
On a Linux (Ubuntu) host machine, the console is seen as a ttyUSB***X* device (where X is a number) and you can access to it by means of an application like minicom.
Minicom needs to know the name of the serial device. The simplest way for you to discover the name of the device is by looking to the kernel messages, so:
sudo dmesg -c
dmesg
[ 2614.290675] usb 3-4: >new full-speed USB device number 4 using xhci_hcd
[ 2614.313854] usb 3-4: >New USB device found, idVendor=0403, idProduct=6015
[ 2614.313861] usb 3-4: >New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2614.313865] usb 3-4: >Product: FT230X Basic UART
[ 2614.313868] usb 3-4: >Manufacturer: FTDI
[ 2614.313870] usb 3-4: >SerialNumber: DN002OZI
[ 2614.379284] usbcore: registered new interface driver usbserial
[ 2614.379298] usbcore: registered new interface driver usbserial_generic
[ 2614.379306] USB Serial support registered for generic
[ 2614.379310] usbserial: USB Serial Driver core
[ 2614.387899] usbcore: registered new interface driver ftdi_sio
[ 2614.387914] USB Serial support registered for FTDI USB Serial Device
[ 2614.387997] ftdi_sio 3-4:1.0: >FTDI USB Serial Device converter detected
[ 2614.388029] usb 3-4: >Detected FT-X
[ 2614.388031] usb 3-4: >Number of endpoints 2
[ 2614.388034] usb 3-4: >Endpoint 1 MaxPacketSize 64
[ 2614.388035] usb 3-4: >Endpoint 2 MaxPacketSize 64
[ 2614.388037] usb 3-4: >Setting MaxPacketSize 64
[ 2614.388260] usb 3-4: >FTDI USB Serial Device converter now attached to /dev/ttyUSB0
[ 2614.388288] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
As you can see, here the device has been recognized as /dev/ttyUSB0.
Now that you know the device name, run minicom:
sudo minicom -ws
If minicom is not installed, you can install it with:
sudo apt-get install minicom
then you can setup your port with these parameters:
+-----------------------------------------------------------------------+
| A - Serial Device : /dev/ttyUSB0 |
| B - Lockfile Location : /var/lock |
| C - Callin Program : |
| D - Callout Program : |
| E - Bps/Par/Bits : 115200 8N1 |
| F - Hardware Flow Control : No |
| G - Software Flow Control : No |
| |
| Change which setting? |
+-----------------------------------------------------------------------+
| Screen and keyboard |
| Save setup as dfl |
| Save setup as.. |
| Exit |
| Exit from Minicom |
+--------------------------+
If on your system the device has not been recognized as /dev/ttyUSB0, just replace /dev/ttyUSB0 with the proper device.
Once you are done configuring the serial port, you are back to minicom main menu and you can select exit.
Give root to the login prompt:
Board
pengwyn login: root
and press Enter.
Note
Sometimes, the time you spend setting up minicom makes you miss all the output that leads to the login and you see just a black screen, press enter then to get the login prompt.
Enjoy!
This document will guide you from importing the virtual machine to debugging an Hello World! example on a customized Linux distribution you will generate with OpenEmbedded/Yocto toolchain.
The development environment is provided as a virtual disk (to be used by a VirtualBox virtual machine) which you can download from this page:
Important
Compute the MD5SUM value of the zip file you downloaded and compare it to the golden one you find in the download page.
Uncompress the file, and you will get a .vdi file that is our virtual disk image. The environment contains the SDK for all the boards provided by Architech, Pengwyn included.
For being able to use it, you first need to install VirtualBox (version 4.2.10 or higher). You can get VirtualBox installer from here:
https://www.virtualbox.org/wiki/Downloads
Download the version that suits your host operating system. You need to download and install the Extension Pack as well.
Important
Make sure that the extension pack has the same version of VirtualBox.
Install the software with all the default options.
We need to setup a port forwarding rule to let you (later) use the virtual machine as a local repository of packages.
Note
The virtual machine must be off
Building an entire system from the ground up is a business that can take up to several hours. To improve the performances of the overall build process, you can, if your computer has enough resources, assign more than one processor to the virtual machine.
Note
The virtual machine must be off
The VBox addictions add functionalities to the virtual machine such as better graphic driver and more. It is already installed in the SDK but is important re-install it to configuring correctly the virtual machine with your operating system.
2. Click on the virtual box menu to the voice Devices and select Insert Guest Additions CD Images.... A message box will appear at the start of the installation, click on run button
Important
A working internet connection, several GB of free disk space and several hours are required by the build process
gedit conf/local.conf
EXTRA_IMAGE_FEATURES_append = " tools-debug debug-tweaks"
IMAGE_INSTALL_append = " tcf-agent gdbserver"
or
EXTRA_IMAGE_FEATURES_append = " tools-debug debug-tweaks"
IMAGE_FEATURES_append = " eclipse-debug"
This will trigger the installation of a features set onto the final root file system, like tcf-agent and gdbserver.
bitbake core-image-minimal-dev
At the end of the build process, the image will be saved inside directory:
/home/architech/architech_sdk/architech/pengwyn/yocto/build/tmp/deploy/images/pengwyn
sudo tar -zxf /home/architech/architech_sdk/architech/pengwyn/yocto/build/tmp/deploy/images/pengwyn/core-image-minimal-dev-pengwyn.tar.gz -C /home/architech/architech_sdk/architech/pengwyn/sysroot/
Note
sudo password is: “architech“
To deploy the root file system and the boot partition, first you need a SD card correctly formatted.
This section describes the steps to be followed to create a standalone bootable system on SD card.
Ensure that the following is available:
Warning
Not all computer built-in readers can be used, use USB connected devices instead.
Warning
Your sd-card will be formatted and all the data contained in it will be lost forever!
mkdir -p /home/architech/Desktop/pengwyn-tools
tar -jxf pengwyn-tools-dizzy.tar.bz2 -C /home/architech/Desktop/pengwyn-tools
cd /home/architech/Desktop/pengwyn-tools
sudo ./fast-create-sdcard.sh
Note
sudo fdisk -l
Disk /dev/sdb: 1971 MB, 1971322880 bytes
255 heads, 63 sectors/track, 239 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9bfa2153
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 9 72261 c W95 FAT32 (LBA)
/dev/sdb2 11 239 1839442+ 83 Linux
sudo ./fast-create-sdcard.sh
+------------------------------------------------------------------------------+
| |
| This script will create a bootable SD card. |
| The script must be run with root permissions. |
| |
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
| LIST OF AVAILABLE DRIVES: |
+------------------------------------------------------------------------------+
# major minor size name
1: 8 16 1927168 sdb
Enter Device Number #:
+------------------------------------------------------------------------------+
| |
| This script will create a bootable SD card. |
| The script must be run with root permissions. |
| |
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
| LIST OF AVAILABLE DRIVES: |
+------------------------------------------------------------------------------+
# major minor size name
1: 8 16 1927168 sdb
Enter Device Number #: 1
sdb was selected
sdb1 sdb2
72261 1839442
Mount the partitions
Emptying partitions
Syncing....
+------------------------------------------------------------------------------+
| Copying files now... will take minutes |
+------------------------------------------------------------------------------+
Copying boot partition
Copying file system partition
Copying modules
Syncing....
Un-mount the partitions
Remove created temp directories
Operation Finished
Press ENTER to finish
Make sure everything has been really written to the SD card:
sync
Then unmount the SD card from your computer and plug the SD in the board socket.
First of all, make sure the board can boot entirely from the SD-Card by setting J1 closed and J2 and J3 opened:
Pengwyn takes the power from the mini-USB connector CN6 and/or connector CN1.
Now it’s time to start the serial console.
which you can connect, by means of a mini-USB cable, to your personal computer.
Note
Every operating system has its own killer application to give you a serial terminal interface. In this guide, we are assuming your host operating system is Ubuntu.
On a Linux (Ubuntu) host machine, the console is seen as a ttyUSB***X* device (where X is a number) and you can access to it by means of an application like minicom.
Minicom needs to know the name of the serial device. The simplest way for you to discover the name of the device is by looking to the kernel messages, so:
sudo dmesg -c
dmesg
[ 2614.290675] usb 3-4: >new full-speed USB device number 4 using xhci_hcd
[ 2614.313854] usb 3-4: >New USB device found, idVendor=0403, idProduct=6015
[ 2614.313861] usb 3-4: >New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2614.313865] usb 3-4: >Product: FT230X Basic UART
[ 2614.313868] usb 3-4: >Manufacturer: FTDI
[ 2614.313870] usb 3-4: >SerialNumber: DN002OZI
[ 2614.379284] usbcore: registered new interface driver usbserial
[ 2614.379298] usbcore: registered new interface driver usbserial_generic
[ 2614.379306] USB Serial support registered for generic
[ 2614.379310] usbserial: USB Serial Driver core
[ 2614.387899] usbcore: registered new interface driver ftdi_sio
[ 2614.387914] USB Serial support registered for FTDI USB Serial Device
[ 2614.387997] ftdi_sio 3-4:1.0: >FTDI USB Serial Device converter detected
[ 2614.388029] usb 3-4: >Detected FT-X
[ 2614.388031] usb 3-4: >Number of endpoints 2
[ 2614.388034] usb 3-4: >Endpoint 1 MaxPacketSize 64
[ 2614.388035] usb 3-4: >Endpoint 2 MaxPacketSize 64
[ 2614.388037] usb 3-4: >Setting MaxPacketSize 64
[ 2614.388260] usb 3-4: >FTDI USB Serial Device converter now attached to /dev/ttyUSB0
[ 2614.388288] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
As you can see, here the device has been recognized as /dev/ttyUSB0.
Now that you know the device name, run minicom:
sudo minicom -ws
If minicom is not installed, you can install it with:
sudo apt-get install minicom
then you can setup your port with these parameters:
+-----------------------------------------------------------------------+
| A - Serial Device : /dev/ttyUSB0 |
| B - Lockfile Location : /var/lock |
| C - Callin Program : |
| D - Callout Program : |
| E - Bps/Par/Bits : 115200 8N1 |
| F - Hardware Flow Control : No |
| G - Software Flow Control : No |
| |
| Change which setting? |
+-----------------------------------------------------------------------+
| Screen and keyboard |
| Save setup as dfl |
| Save setup as.. |
| Exit |
| Exit from Minicom |
+--------------------------+
If on your system the device has not been recognized as /dev/ttyUSB0, just replace /dev/ttyUSB0 with the proper device.
Once you are done configuring the serial port, you are back to minicom main menu and you can select exit.
Give root to the login prompt:
Board
pengwyn login: root
and press Enter.
Note
Sometimes, the time you spend setting up minicom makes you miss all the output that leads to the login and you see just a black screen, press Enter then to get the login prompt.
The time to create a simple HelloWorld! application using Eclipse has come.
Note
Use an ethernet cable to connect the board (connector XF1) to your PC. Configure your workstation ip address as 192.168.0.100. Make sure the board can be seen by your host machine:
ifconfig eth0 192.168.0.10
ping 192.168.0.10
If the output is similar to this one:
64 bytes from 192.168.0.100: icmp_req=1 ttl=64 time=0.946 ms
64 bytes from 192.168.0.100: icmp_req=2 ttl=64 time=0.763 ms
64 bytes from 192.168.0.100: icmp_req=3 ttl=64 time=0.671 ms
64 bytes from 192.168.0.100: icmp_req=4 ttl=64 time=0.793 ms
then the ethernet connection is ok. Enable the remote debug with Yocto by typing this command on Pengwyn console:
/etc/init.d/tcf-agent restart
On the Host machine, follow these steps to let Eclipse deploy and debug your application:
/home/architech/architech_sdk/architech/pengwyn/toolchain/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
/home/architech/architech_sdk/architech/pengwyn/sysroot/lib
/home/architech/architech_sdk/architech/pengwyn/sysroot/usr/lib
Important
If debug does not work, check on the board if tcf-agent is running and gdbserver has been installed. You can ignore the message “Cannot access memory at address 0x0”.
This chapter gives an overview on how the SDK has been composed and where to find the tools on the virtual machine.
The SDK provided by Architech to support Pengwyn is composed by several components, the most important of which are:
Regarding the installation and configuration of these tools, you have many options:
The method you choose depends on your level of expertise and the results you want to achieve.
If you are new to Yocto and/or Linux, or simply you don’t want to read tons of documentation right now, we suggest you to download and install the virtual machine because it is the simplest solution (have a look at VM content), everything inside the virtual machine has been thought to work out of the box, plus you will get support.
If performances are your greatest concerns, consider reading Chapter Create SDK.
The development environment is provided as a virtual disk (to be used by a VirtualBox virtual machine) which you can download from this page:
Important
Compute the MD5SUM value of the zip file you downloaded and compare it to the golden one you find in the download page.
Uncompress the file, and you will get a .vdi file that is our virtual disk image. The environment contains the SDK for all the boards provided by Architech, Pengwyn included.
For being able to use it, you first need to install VirtualBox (version 4.2.10 or higher). You can get VirtualBox installer from here:
https://www.virtualbox.org/wiki/Downloads
Download the version that suits your host operating system. You need to download and install the Extension Pack as well.
Important
Make sure that the extension pack has the same version of VirtualBox.
Install the software with all the default options.
We need to setup a port forwarding rule to let you (later) use the virtual machine as a local repository of packages.
Note
The virtual machine must be off
Building an entire system from the ground up is a business that can take up to several hours. To improve the performances of the overall build process, you can, if your computer has enough resources, assign more than one processor to the virtual machine.
Note
The virtual machine must be off
The VBox addictions add functionalities to the virtual machine such as better graphic driver and more. It is already installed in the SDK but is important re-install it to configuring correctly the virtual machine with your operating system.
2. Click on the virtual box menu to the voice Devices and select Insert Guest Additions CD Images.... A message box will appear at the start of the installation, click on run button
The virtual machine provided by Architech contains:
All the aforementioned tools are installed under directory /home/architech/architech_sdk, its sub-directories main layout is the following:
architech_sdk
|
|_ splashscreen
|
|_ spashscreen-interface
|
|_ architech-manifest
|
|_ architech
|
|_ ...
|
|_ pengwyn
|
|_ eclipse
|
|_ qtcreator
|
|_ splashscreen
|
|_ sysroot
|
|_ toolchain
|
|_ workspace
| |
| |_ eclipse
| |
| |_ qt
|
|_ yocto
|
|_ build
|
|_ poky
|
|_ meta-pengwyn
|
|_ ...
pengwyn directory contains all the tools composing the ArchiTech SDK for Pengwyn board, along with all the information needed by the splash screen application. In particular:
The splash screen application has been designed to facilitate the access to the boards tools. It can be opened by clicking on its Desktop icon.
Once started, you can can choose if you want to work with Architech’s boards or with partners’ ones. For Pengwyn, choose ArchiTech.
A list of all available Architech’s boards will open, select Pengwyn.
A list of actions related to Pengwyn that can be activated will appear.
If you have speed in mind, it is possible to install the SDK on a native Ubuntu machine (other Linux distributions may support this SDK with minor changes but won’t be supported). This chapter will guide you on how to clone the entire SDK, to setup the SDK for one board or just OpenEmbedded/Yocto for Pengwyn board.
Architech’s Yocto based SDK is built on top of Ubuntu 12.04 32bit, hence all the scripts provided are proven to work on such a system.
If you wish to use another distribution/version you might need to change some script option and/or modify the scripts yourself, remember that you won’t get any support in doing so.
To install the same tools you get inside the virtual machine on your native machine you need to download and run a system wide installation script:
git clone -b dizzy https://github.com/architech-boards/machine_installer.git
cd machine_installer
./machine_install -g -p
where -g option asks the script to install and configure a few graphic customization, while -p option asks the script to install the required packages on the machine. If you want to install the toolchain on a machine not equal to Ubuntu 12.04 32bit then you may want to read the script, install the required packages by hand, and run it without options. You might need to recompile the Qt application used to render the splashscreen.
At the end of the installation process, you will get the same tools installed within the virtual machine, that is, all the tools necessary to work with Architech’s boards.
If you don’t want to install the tools for all the boards, you can install just the subset of tools related to Pengwyn:
git clone -b dizzy https://github.com/architech-boards/pengwyn-splashscreen.git
cd pengwyn-splashscreen
./run_install
This script needs the same tools/packages required by machine_install
If you have launched machine_installer or run_install.sh script, yocto is already installed. The following steps are useful for understood how the sdk works “under the hood”.
The easiest way to setup and keep all the necessary meta-layers in sync with upstream repositories is achieved by means of Google’s repo tool. The following steps are necessary for a clean installation:
mkdir -p ~/bin
sudo apt-get install curl
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
echo $PATH
export PATH="$PATH:${HOME}/bin"
repo init -u https://github.com/architech-boards/pengwyn-manifest.git -b dizzy -m manifest.xml
repo sync
By the end of the last step, all the necessary meta-layers should be in place, anyway, you still need to edit your local.conf and bblayers.conf to compile for pengwyn machine and using all the downloaded meta-layers.
When you want your local repositories to be updated, just:
repo sync
If you really want to download everything by hand, just clone branch dizzy of meta-pengwyn:
git clone -b dizzy https://github.com/architech-boards/meta-pengwyn.git
and have a look at the README file.
To install Eclipse, Qt Creator, cross-toolchain, NFS, TFTP, etc., read Yocto/OpenEmbedded documentation, along with the other tools one.
The Board Support Package is composed by a set files, patches, recipes, configuration files, etc. This chapter gives you the information you need when you want to customize something, fix a bug, or simply learn how the all thing has been assembled.
This chapter explains how to compile the u-boot.
The bootloader used by Pengwyn board is U-Boot. If you need to modify the bootloader or to recompile it you have two ways to get the sources:
Anyway, we will assume in this guide that u-boot sources will be copied to:
/home/architech/Documents/u-boot
and such directory does not yet exists on your PC. Of course, you are free to choose the path you like the most for u-boot sources, just remember to replace the path used in this guide with your custom path. So, where can we get the sources?
The first way is based on the sources set up by the Yocto build system. However, it is never advisable to work with the sources in the Yocto build directory, if you really want to modify the source code inside the Yocto environment we strongly suggest to refer to the official Yocto documentation. To avoid messing up Yocto recipes and installation, it is desirable to copy the patched u-boot sources you find in the build directory elsewhere. The directory we are talking about is this one:
/home/architech/architech_sdk/architech/pengwyn/yocto/build/tmp/work/pengwyn-poky-linux-gnueabi/u-boot-ti-staging/2014.07-r7+gitrAUTOINC+7e537bfdd2/git/
Replace:
/home/architech/architech_sdk/architech/pengwyn/yocto/build/
all over this chapter with your custom build directory path if you are not working with the default SDK build directory.
The second way is to get the official U-Boot sources and patch them with Pengwyn BSP patches. Pengwyn board uses U-Boot version 2014.07, which can be downloaded from:
cd /home/architech/Documents
git clone -b ti-u-boot-2014.07 git://git.ti.com/ti-u-boot/ti-u-boot.git
mv ti-u-boot u-boot
cd u-boot
git checkout 7e537bfdd261bf8bf444f3ac4d1be3db4ee124e8
Patches are in the Yocto meta-layer meta-pengwyn. You can use them right away if you are working with the SDK:
patch -p1 -d /home/architech/Documents/u-boot/ < /home/architech/architech_sdk/architech/pengwyn/yocto/meta-pengwyn/recipes-bsp/u-boot/u-boot-ti-staging-2014.07/0001-pengwyn.patch
However, if you are not working with the official SDK the most general solution to check them out and patch the sources is:
cd /home/architech/Documents
git clone -b dizzy https://github.com/architech-boards/meta-pengwyn.git
patch -p1 -d /home/architech/Documents/u-boot < /home/architech/Documents/meta-pengwyn/recipes-bsp/u-boot/u-boot-ti-staging-2014.07/0001-pengwyn.patch
Configuration and board files for Pengwyn board are in:
/home/architech/Documents/u-boot/board/ti/am335x/*
/home/architech/Documents/u-boot/include/configs/pengwyn.h
Suppose you modified something and you wanted to recompile the sources to test your patches, well, you need a cross-toolchain. To use it to compile the bootloader or the operating system kernel run:
source /home/architech/architech_sdk/architech/pengwyn/toolchain/environment-nofs
then you can run these commands to compile it:
cd /home/architech/Documents/u-boot/
make pengwyn_config
make -j <2 * number of processor's cores> pengwyn
Once the build process completes, you can find u-boot.img and MLO file inside directory /home/architech/Documents/u-boot.
Like we saw for the bootloader, the first thing you need is: sources. Get them from Bitbake build directory (if you built the kernel with it) or get them from the Internet.
Bitbake will place the sources under directory:
/path/to/build/tmp/work/pengwyn-poky-linux-gnueabi/sitara-linux-ti-staging/3.14.26-r22g+gitrAUTOINC+2489c022b2/git
If you are working with the virtual machine, you will find them under directory:
/home/architech/architech_sdk/architech/pengwyn/yocto/build/tmp/work/pengwyn-poky-linux-gnueabi/sitara-linux-ti-staging/3.14.26-r22g+gitrAUTOINC++XXX/git
If you didn’t build them already with Bitbake or you just want to do make every step by hand, you can always get them from the Internet by cloning the proper repository and checking out the proper hash commit:
cd ~/Documents
git clone -b sitara-ti-linux-3.14.y git://git.ti.com/sitara-linux/sitara-linux.git
cd sitara-linux
git checkout 2489c022b2932432606f897741a71b712e6dbe77
and by properly patching the sources:
cd ~/Documents
patch -p1 -d sitara-linux/ < /home/architech/architech_sdk/architech/pengwyn/yocto/meta-pengwyn/recipes-kernel/linux/sitara-linux-ti-staging-3.14.26/0002-pengwyn.patch
cp /home/architech/architech_sdk/architech/pengwyn/yocto/meta-pengwyn/recipes-kernel/linux/sitara-linux-ti-staging-3.14.26/defconfig ~/Documents/sitara-linux/arch/arm/configs/pengwyn_defconfig
However, if you are not working with the official SDK the most general solution to check them out and patch the sources is:
cd ~/Documents
git clone -b dizzy https://github.com/architech-boards/meta-pengwyn.git
git clone git://git.yoctoproject.org/meta-ti.git
cd meta-ti
git checkout 56ea9223d7a3d3da38dd4fef10b4dfeb0667992d
patch -p1 -d sitara-linux/ < meta-pengwyn/recipes-kernel/linux/sitara-linux-ti-staging-3.14.26/0002-pengwyn.patch
cp meta-pengwyn/recipes-kernel/linux/sitara-linux-ti-staging-3.14.26/defconfig sitara-linux/arch/arm/configs/pengwyn_defconfig
Now that you have the sources, you can start browsing the code from the following files:
~/Documents/sitara-linux/arch/arm/boot/dts/pengwyn-common.dtsi
~/Documents/sitara-linux/arch/arm/boot/dts/pengwyn-dvi.dts
~/Documents/sitara-linux/arch/arm/boot/dts/pengwyn-touch.dts
For build the kernel source the script to load the proper environment for the cross-toolchain:
source /home/architech/architech_sdk/architech/pengwyn/toolchain/environment-nofs
cd ~/Documents/sitara-linux
make pengwyn_defconfig
make menuconfig
and to compile it:
make -j <2 * number of processor's cores> uImage
If you omit -j parameter, make will run one task after the other, if you specify it make will parallelize the tasks execution while respecting the dependencies between them. Generally, you will place a value for -j parameter corresponding to the double of your processor’s cores number, for example, on a quad core machine you will place -j 8.
Once the kernel is compiled, the last build to do is the dtb file. This file permits at the boot time to configure the kernel with a specific hardware configuration. So if you are using a touchscreen you will build the pengwyn-touch.dts file else if you are using a display with dvi connector will be pengwyn-dvi.dts file. In the same directory where you have compiled the kernel launch the command:
make pengwn-touch.dtb
or
make pengwyn-dvi.dtb
By the end of the build process you will get uImage under arch/arm/boot and pengwyn-touch.dtb or pengwyn-dvi.dtb under arch/arm/boot/dts directories.
The most frequent way of customization of the Linux Kernel is to change the .config file that contains the Kernel options. Setup the environment and run:
bitbake virtual/kernel -c cleanall
bitbake virtual/kernel -c menuconfig
a new window, like the following one, will pop-up:
follow the instructions, save and exit, than you ready to generate your preferred image based on your customized kernel. If you prefer, you can build just the kernel running:
bitbake virtual/kernel
At the end of the build process, the output file (uImage.bin), along with the built kernel modules, will be placed under tmp/deploy/images/pengwyn/ inside your build directory, so, if you are building your system from the default directory, the destination directory will be /home/architech/architech_sdk/architech/pengwyn/yocto/build/tmp/deploy/images/pengwyn/.
A Yocto/OpenEmbedded meta-layer is a directory that contains recipes, configuration files, patches, etc., all needed by Bitbake to properly “see” and build a BSP, a distribution, a (set of) package(s), whatever. meta-pengwyn is a meta-layer which defines the customizations to make to TI’s AM335x BSP and Yocto/OpenEmbedded in order to get a working system, tailor made of Pengwyn.
You can get it with git:
git clone -b dizzy https://github.com/architech-boards/meta-pengwyn.git
The machine name for Pengwyn is pengwyn.
The strictly BSP related recipes are located under:
meta-pengwyn/recipes-bsp/u-boot/
meta-pengwyn/recipes-bsp/flash/
meta-pengwyn/recipes-kernel/linux/
The other recipes are there just to customize other aspects of the system or to offer some facility to help you easily manage some task, for example, working with flash memory or partitions.
Pengwyn is powered by a NAND memory, big enough to place a full featured root file system inside of it. However, you might not be interested in how to place the file system inside of it from the beginning and how to mount and unmount it inside your file system. There is a recipe inside meta-pengwyn, pengwyn-flash-utils, that will install three scripts inside the target file system to make the aforementioned tasks easy:
pengwyn_to_flash takes as input files, cleans and formats the NAND flash memory, and finally takes the files you gave him to setup the file system. For more information just run:
pengwyn_to_flash -h
from Pengwyn shell.
pengwyn_mount_flash lets you mount the flash memory partition inside your filesystem (under /mnt/flash) without any effort and, likewise, pengwyn_umount_flash helps you unmounting the partition.
Remember that to install those scripts inside the target, you need to add meta-openmbedded/meta-oe meta layer to your bblayers.conf file. If you are working with Architech virtual machine, you don’t have to worry about that, everything is already in place.
pengwyn-flash-utils won’t be placed by default inside your file system, if you want it you need to add a line like this one to your local.conf file
IMAGE_INSTALL_append = " pengwyn-flash-utils"
Probably the most comfortable way, at least at the beginning, to build a valid SD card is to use file .sdcard that Bitbake emits when builds an image. However, Bitbake prepares a final iso image to write to the medium without any knowledge of its size. If you write the image on an SD card, for example, the first thing you notice is that the file system does not fit the card.
By default, Pengwyn’s Yocto/OpenEmbedded SDK will generate an image <name image>.tar.gz:
The .tar.gz file can be flattened out in your final medium partition (on SD card, flash memory) or on your host development system and used for build purposes with the Yocto Project.
If you want use a new SD card to unpack your image .tar.gz then read the following section else skip it.
This section describes the steps to be followed to create a standalone bootable system on SD card.
Ensure that the following is available:
Warning
Not all computer built-in readers can be used, use USB connected devices instead.
Warning
Your sd-card will be formatted and all the data contained in it will be lost forever!
mkdir -p /home/architech/Desktop/pengwyn-tools
tar -jxf pengwyn-tools-dizzy.tar.bz2 -C /home/architech/Desktop/pengwyn-tools
cd /home/architech/Desktop/pengwyn-tools
sudo ./fast-create-sdcard.sh
Note
sudo fdisk -l
Disk /dev/sdb: 1971 MB, 1971322880 bytes
255 heads, 63 sectors/track, 239 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9bfa2153
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 9 72261 c W95 FAT32 (LBA)
/dev/sdb2 11 239 1839442+ 83 Linux
sudo ./fast-create-sdcard.sh
+------------------------------------------------------------------------------+
| |
| This script will create a bootable SD card. |
| The script must be run with root permissions. |
| |
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
| LIST OF AVAILABLE DRIVES: |
+------------------------------------------------------------------------------+
# major minor size name
1: 8 16 1927168 sdb
Enter Device Number #:
+------------------------------------------------------------------------------+
| |
| This script will create a bootable SD card. |
| The script must be run with root permissions. |
| |
+------------------------------------------------------------------------------+
+------------------------------------------------------------------------------+
| LIST OF AVAILABLE DRIVES: |
+------------------------------------------------------------------------------+
# major minor size name
1: 8 16 1927168 sdb
Enter Device Number #: 1
sdb was selected
sdb1 sdb2
72261 1839442
Mount the partitions
Emptying partitions
Syncing....
+------------------------------------------------------------------------------+
| Copying files now... will take minutes |
+------------------------------------------------------------------------------+
Copying boot partition
Copying file system partition
Copying modules
Syncing....
Un-mount the partitions
Remove created temp directories
Operation Finished
Press ENTER to finish
After a writing operation use always sync command to make sure everything has been really written to the SD card:
sync
Once your (virtual/)machine has been set up you can compile, customize the BSP for your board, write and debug applications, change the file system on-the-fly directly on the board, etc. This chapter will guide you to the basic use of the most important tools you can use to build customize, develop and tune your board.
Bitbake is the most important and powerful tool available inside Yocto/OpenEmbedded. It takes as input configuration files and recipes and produces what it is asked for, that is, it can build a package, the Linux kernel, the bootloader, an entire operating system from scratch, etc.
A recipe (.bb file) is a collection of metadata used by BitBake to set variables or define additional build-time tasks. By means of variables, a recipe can specify, for example, where to get the sources, which build process to use, the license of the package, an so on. There is a set of predefined tasks (the fetch task for example fetches the sources from the network, from a repository or from the local machine, than the sources are cached for later reuses) that executed one after the other get the job done, but a recipe can always add custom ones or override/modify existing ones. The most fine-graned operation that Bitbake can execute is, in fact, a single task.
To properly run Bitbake, the first thing you need to do is setup the shell environment. Luckily, there is a script that takes care of it, all you need to do is:
source /path/to/oe-init-build-env /path/to/build/directory
Inside the virtual machine, you can find oe-init-build-env script inside:
/home/architech/architech_sdk/architech/pengwyn/yocto/poky
If you omit the build directory path, a directory named build will be created under your current working directory.
By default, with the SDK, the script is used like this:
source /home/architech/architech_sdk/architech/pengwyn/yocto/poky/oe-init-build-env
Your current working directory changes to such a directory and you can customize configurations files (that the environment script put in place for you when creating the directory), run Bitbake to build whatever pops to your mind as well run hob. If you specify a custom directory, the script will setup all you need inside that directory and will change your current working directory to that specific directory.
Important
The build directory contains all the caches, builds output, temporary files, log files, file system images... everything!
The default build directory for Pengwyn is located under:
/home/architech/architech_sdk/architech/pengwyn/yocto/build
and the splash screen has a facility (a button located under Pengwyn’s page) that can take you there with the right environment already in place so you are productive right away.
Important
Configuration files are used by Bitbake to define variables value, preferences, etc..., there are a lot of them. At the beginning you should just worry about two of them, both located under conf directory inside your build directory, we are talking about local.conf and bblayers.conf.
local.conf contains your customizations for the build process, the most important variables you should be interested about are: MACHINE, DISTRO, BB_NUMBER_THREADS and PARALLEL_MAKE. MACHINE defines the target machine you want compile against. The proper value for Pengwyn is pengwyn:
MACHINE ??= "pengwyn"
DISTRO let you choose which distribution to use to build the root file systems for the board. The default distribution to use with the board is:
DISTRO ?= "poky"
BB_NUMBER_THREADS and PARALLEL_MAKE can help you speed up the build process. BB_NUMBER_THREADS is used to tell Bitbake how many tasks can be executed at the same time, while PARALLEL_MAKE contains the -j option to give to make program when issued. Both BB_NUMBER_THREADS and PARALLEL_MAKE are related to the number of processors of your (virtual) machine, and should be set with a number that is two times the number of processors on your (virtual) machine. If for example, your (virtual) machine has/sees four cores, then you should set those variables like this:
BB_NUMBER_THREADS ?= "8"
PARALLEL_MAKE ?= "-j 8"
bblayers.conf is used to tell Bitbake which meta-layers to take into account when parsing/looking for recipes, machine, distributions, configuration files, bbclasses, and so on. The most important variable contained inside bblayers.conf is BBLAYERS, it’s the variable where the actual meta-layers layout get specified.
All the variables value we just spoke about are taken care of by Architech installation scripts.
With your shell setup with the proper environment and your configuration files customized according to your board and your will, you are ready to use Bitbake. The first suggestion is to run:
bitbake -h
Bitbake will show you all the options it can be run with. During normal activity you will need to simply run a command like:
bitbake <recipe name>
for example:
bitbake core-image-minimal-dev
Such a command will build bootloader, Linux kernel and a root file system. core-image-minimal-dev tells Bitbake to execute whatever recipe
/home/architech/architech_sdk/architech/pengwyn/yocto/poky/meta/recipes-extended/images/core-image-minimal-dev.bb
you just place the name of the recipe without the extension .bb.
Of course, there are times when you want more control over Bitbake, for example, you want to execute just one task like recompiling the Linux kernel, no matter what. That action can be achieved with:
bitbake -c compile -f virtual/kernel
where -c compile states the you want to execute the do_compile task and -f forces Bitbake to execute the command even if it thinks that there are no modifications and hence there is no need to to execute the same command again.
Another useful option is -e which gets Bitbake to print the environment state for the command you ran.
The last option we want to introduce is -D, which can be in fact repeated more than once and asks Bitbake to emit debug print. The amount of debug output you get depend on many times you repeated the option.
Of course, there are other options, but the ones introduced here should give you an head start.
HOB is a graphical interface for bitbake. To run it, prepare the environment than run hob command or launch Hob using Architech Splashscreen just click on Run hob.
Warning
HOB window will appear.
When you imported the virtual machine you might have changed the number of processors made available to the virtual machine itself. If you did that, you can optimize the build time in this way:
This modification will be available just for the current build directory.
Select pengwyn from the combo-box,
after the recipes have been parsed the section Select a base image will appear and you can choose your preferred image.
Click on Build image
Warning
than the build process will start.
Please note that the build process can last several hours till it finishes.
It might happen that a fetch task gives an error, if so, double check that the virtual machine has a proper network configuration. If the network configuration has been proved correct, the error might mean that the needed server is down for some reason, in that case the only option you have is to wait and try again later.
There are two possible ways to customize an image to build:
Once you selected a predefined image, you can click on View recipes to add/remove recipes and tasks or you can click on View packages to add/remove previously built packages. After the image has been customized you can build your image. If you want to customize every detail you can choose Create your own image from the drop down menu of section Select a base image, than, as previously stated, you can customize the content of your file system and build it.
Eclipse is an integrated development environment (IDE). It contains a base workspace and the Yocto plug-in system to compile and debug a program for Pengwyn. Hereafter, the operating system that runs the IDE/debugger will be named host machine, and the board being debugged will be named target machine. The host machine could be running as a virtual machine guest operating system, anyway, the documentation for the host machine running as a guest operating system and as host operating system is exactly the same.
To write your application you need:
- your board has ip address 192.168.0.10 on interface eth0, and
- your PC has an ip address in the same family of addresses, e.g. 192.168.0.100.
Note
You can create two types of projects: Autotools-based, or Makefile-based. This section describes how to create Autotools-based projects from within the Eclipse IDE. Launch Eclipse using Architech Splashscreen just click on Develop with Eclipse.
To create a project based on a Yocto template and then display the source code, follow these steps:
Note
If the “open perspective” prompt appears, click Yes so that you enter in C/C++ perspective. The left-hand navigation panel shows your project. You can display your source by double clicking on the project source file.
To build the project, select Project→Build Project. The console should update with messages from the cross-compiler. To add more libraries to compile:
Note
All libraries must be located in /home/architech/architech_sdk/architech/pengwyn/sysroot subdirectories.
Connect Pengwyn console to your PC and power-on the board. Once you built the project and the board is running the image, use minicom to run tcf-agent program in target board:
pengwyn login: root
/etc/init.d/tcf-agent restart
On the Host machine, follow these steps to let Eclipse deploy and debug your application:
/home/architech/architech_sdk/architech/pengwyn/toolchain/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
/home/architech/architech_sdk/architech/pengwyn/sysroot/lib
/home/architech/architech_sdk/architech/pengwyn/sysroot/usr/lib
Important
If debug does not work, check on the board if tcf-agent is running and gdbserver has been installed.
The Qt Framework used by this SDK is composed of libraries for your host machine and your target. To compile the libraries for x86 you only need your distribution toolchain, while to compile the libraries for Pengwyn board you need the proper cross-toolchain (see Chapter Cross compiler for further information on how to get it).
First of all you need to compile the cross-toolchain with Yocto:
bitbake meta-toolchain-qte
The recipe builds poky-glibc-i686-meta-toolchain-qte-cortexa8t2hf-vfp-neon-toolchain-qte-1.7.1.sh installation script. You should find the installation script in /home/architech/architech_sdk/architech/pengwyn/yocto/build/tmp/deploy/sdk. The cross-toolchain allows to compile a Qt embedded 4.8.5 application.
To install the toolchain run the following commands:
sudo ./poky-glibc-i686-meta-toolchain-qte-cortexa8t2hf-vfp-neon-toolchain-qte-1.7.1.sh
The installation script will ask to select an installation path.
sudo chown -R architech:architech ~/path/to/toolchain/installed
Before to run Qt creator you must set the environment variables:
source /opt/poky/1.7.1/environment-setup-cortexa8t2hf-vfp-neon-poky-linux-gnueabi
source /opt/poky/1.7.1/sysroots/i686-pokysdk-linux/environment-setup.d/qtopia.sh
Note
Note
/home/architech/architech_sdk/architech/pengwyn/sysroot
sudo tar -zxf /home/architech/architech_sdk/architech/pengwyn/yocto/build/tmp/deploy/images/pengwyn/qt4e-demo-image-pengwyn.tar.gz -C /home/architech/architech_sdk/architech/pengwyn/sysroot/
sudo mkdir -p /path/to/target/usr/local/Trolltech/Pengwyn/
sudo cp -r /usr/local/Trolltech/Pengwyn/* /path/to/target/usr/local/Trolltech/Pengwyn/
sudo mkdir -p ~/architech_sdk/architech/pengwyn/sysroot/usr/local/Trolltech/Pengwyn/
sudo cp -r /usr/local/Trolltech/Pengwyn/* ~/architech_sdk/architech/pengwyn/sysroot/usr/local/Trolltech/Pengwyn/
sudo cp -r /home/architech/architech_sdk/architech/pengwyn/toolchain/sysroots/cortexa8t2hf-vfp-neon-poky-linux-gnueabi/* /home/architech/architech_sdk/architech/pengwyn/sysroot/
If you based your root file system on qt4e-demo-image, be sure you execute this command
/etc/init.d/qtdemo stop
to stop the execution of the demo application.
- your board has ip address 192.168.0.10 on interface eth0, and
- your PC has an ip address in the same family of addresses, e.g. 192.168.0.100.
The purpose of this example project is to generate a form with an “Hello World” label in it, at the beginning on the x86 virtual machine and than on Pengwyn board.
To create the project follow these steps:
Note
Now you can edit your application adding labels and more, how to do this is not the purpose of this guide.
In the next section we will debug our Hello World! application directly on Pengwyn.
scp /home/architech/architech_sdk/architech/pengwyn/workspace/qt/build-QtHelloWorld-pengwyn-Debug/QtHelloWorld root@192.168.0.10:/home/root
gdbserver :10000 QtHelloWorld -qws
/home/architech/architech_sdk/architech/pengwyn/workspace/qt/build-QtHelloWorld-pengwyn-Debug/QtHelloWorld
Press OK button to start the debug.
Yocto/OpenEmbedded can be driven to generate the cross-toolchain for your platform. There are two common ways to get that:
bitbake meta-toolchain
or
bitbake <image recipe name> -c populate_sdk
The first method provides you the toolchain, you need to provide the file system to compile against, the second method provides both the toolchain and the file system along with -dev and -dbg packages installed.
Both ways you get an installation script.
The virtual machine has a cross-toolchain installed for each board, each generated with meta-toolchain. To use it just do:
source /home/architech/architech_sdk/architech/pengwyn/toolchain/environment
to compile Linux user-space stuff. If you want to compile kernel or bootloader then do:
source /home/architech/architech_sdk/architech/pengwyn/toolchain/environment-nofs
and you are ready to go.
Useful commands:
opkg update
opkg list
opkg list-installed
opkg install <package 1> <package 2> ... <package n>
opkg search <file>
opkg info <package>
opkg whatdepends <package>
opkg remove <package 1> <package 2> ... <package n>
With some images, Bitbake (e.g. core-image-minimal) does not install the package management system in the final target. To force Bitbake to include it in the next build, edit your configuration file
/home/architech/architech_sdk/architech/pengwyn/yocto/build/conf/local.conf
and add this line to it:
IMAGE_FEATURES_append = " package-management"
opkg reads the list of packages repositories in configuration files located under /etc/opkg/. You can easily setup a new repository for your custom builds:
sudo apt-get install apache2
sudo ln -s /home/architech/architech_sdk/architech/pengwyn/yocto/build/tmp/deploy/ipk/ /var/www/html/pengwyn-ipk
src/gz pengwyn http://192.168.0.100:8000/pengwyn-ipk/pengwyn
To actually reach the virtual machine we set up a port forwarding mechanism in Chapter Virtual Machine so that every time the board communicates with the workstation on port 8000, VirtualBox actually turns the communication directly to the virtual machine operating system on port 80 where it finds apache waiting for it.
opkg update
This chapter introduces the board, its hardware and how to boot it.
The hardware documentation of Pengwyn can be found here:
http://downloads.architechboards.com/doc/Pengwyn/download.html
Pengwyn takes the power from the mini-USB connector CN6 and/or connector CN1. The board is not shipped with an external power adapter.
On connector CN6 you can also have the serial console, so, during your daily development use, you would just connect your workstation to the board using a mini-USB to connector CN6. If you connect some power hungry device to the board, you can give more power to the board by connecting the power adapter.
which you can connect, by means of a mini-USB cable, to your personal computer.
Note
Every operating system has its own killer application to give you a serial terminal interface. In this guide, we are assuming your host operating system is Ubuntu.
On a Linux (Ubuntu) host machine, the console is seen as a ttyUSB***X* device (where X is a number) and you can access to it by means of an application like minicom.
Minicom needs to know the name of the serial device. The simplest way for you to discover the name of the device is by looking to the kernel messages, so:
sudo dmesg -c
dmesg
[ 2614.290675] usb 3-4: >new full-speed USB device number 4 using xhci_hcd
[ 2614.313854] usb 3-4: >New USB device found, idVendor=0403, idProduct=6015
[ 2614.313861] usb 3-4: >New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2614.313865] usb 3-4: >Product: FT230X Basic UART
[ 2614.313868] usb 3-4: >Manufacturer: FTDI
[ 2614.313870] usb 3-4: >SerialNumber: DN002OZI
[ 2614.379284] usbcore: registered new interface driver usbserial
[ 2614.379298] usbcore: registered new interface driver usbserial_generic
[ 2614.379306] USB Serial support registered for generic
[ 2614.379310] usbserial: USB Serial Driver core
[ 2614.387899] usbcore: registered new interface driver ftdi_sio
[ 2614.387914] USB Serial support registered for FTDI USB Serial Device
[ 2614.387997] ftdi_sio 3-4:1.0: >FTDI USB Serial Device converter detected
[ 2614.388029] usb 3-4: >Detected FT-X
[ 2614.388031] usb 3-4: >Number of endpoints 2
[ 2614.388034] usb 3-4: >Endpoint 1 MaxPacketSize 64
[ 2614.388035] usb 3-4: >Endpoint 2 MaxPacketSize 64
[ 2614.388037] usb 3-4: >Setting MaxPacketSize 64
[ 2614.388260] usb 3-4: >FTDI USB Serial Device converter now attached to /dev/ttyUSB0
[ 2614.388288] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
As you can see, here the device has been recognized as /dev/ttyUSB0.
Now that you know the device name, run minicom:
sudo minicom -ws
If minicom is not installed, you can install it with:
sudo apt-get install minicom
then you can setup your port with these parameters:
+-----------------------------------------------------------------------+
| A - Serial Device : /dev/ttyUSB0 |
| B - Lockfile Location : /var/lock |
| C - Callin Program : |
| D - Callout Program : |
| E - Bps/Par/Bits : 115200 8N1 |
| F - Hardware Flow Control : No |
| G - Software Flow Control : No |
| |
| Change which setting? |
+-----------------------------------------------------------------------+
| Screen and keyboard |
| Save setup as dfl |
| Save setup as.. |
| Exit |
| Exit from Minicom |
+--------------------------+
If on your system the device has not been recognized as /dev/ttyUSB0, just replace /dev/ttyUSB0 with the proper device.
Once you are done configuring the serial port, you are back to minicom main menu and you can select exit.
The boot process of the pengwyn is selected by jumpers J1, J2 and J3. After a Power On Reset (POR) the processor starts executing the internal ROM program. The boot mode is based on information gathered from the SYSBOOT:
Jumper settings
boot sequence | ||||||
---|---|---|---|---|---|---|
J1 | J2 | J3 | 1st | 2nd | 3rd | 4th |
open | open | open | MMC0 | SPI0 | UART0 | USB0 |
open | open | close | EMAC1 | MMC0 | XIP MUX2 | NAND |
open | close | open | Fast ext | EMAC1 | UART0 | Reserved |
open | close | close | UART0 | EMAC1 | Reserved | Reserved |
close | open | open | NAND | NANDI2C | MMC0 | UART0 |
close | open | close | UART0 | SPI0 | XIP MUX2 | MMC0 |
close | close | open | XIP MUX2 | UART0 | SPI0 | MMC0 |
close | close | close | USB0 | NAND | SPI0 | MMC0 |
This procedure will guide you to the installation of the display on the Pengwyn board and the configuration of the software to test it.
If you don’t have a SD card formatted with 2 partitions, one for the boot and one for the root filesystem, create it as in Deploy. Now we want install in rootfs the qt4e-demo-image-pengwyn.tar.gz image.
sudo tar -zxf ~/architech_sdk/architech/pengwyn/yocto/tmp/deploy/images/pengwyn/qt4e-demo-image-pengwyn.tar.gz -C /path/to/sdcard/rootfs
And substitute the pengwyn.dtb with this one:
sudo cp ~/architech_sdk/architech/pengwyn/yocto/tmp/deploy/images/pengwyn/zImage-pengwyn-touch.dtb /path/to/sdcard/boot/pengwyn.dtb
Make sure everything has been really written to the SD card:
sync
Then insert SD card on Pengwyn board and wait Linux start-up. First time, the touch screen calibration is needed, than qt4 demo will start.
Pengwyn networking is powered by TI’s chip AM335x. Under Linux, instead, the default network configuration is:
root@pengwyn:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:18:30:FD:2D:7E
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:56
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
If you want that configuration to be brought up at boot you can add a few line in file /etc/network/interfaces, for example, if you want eth0 to have a fixed ip address (say 192.168.0.10) and MAC address of value 1e:ed:19:27:1a:b6 you could add the following lines:
auto eth0
iface eth0 inet static
address 192.168.0.10
netmask 255.255.255.0
hwaddress ether 1e:ed:19:27:1a:b6
The password for the default user, that is architech, is:
Host
architech
The default password of architech is architech. If you are searching more information about sudo command please refer to sudo section of the appendix.
By default, Ubuntu 12.04 32bit comes with no password defined for root user, to set it run the following command:
Host
sudo passwd root
Linux will ask you (twice, the second time is just for confirmation) to write the password for user root.
Please refer to device files section of the appendix.
The site has limitation in bandwith. Use download manager and do not try to speed up the download. If you try to download fastly the server will broke up your download.
In this page you can find some useful info about how Linux works. If you are coming from Microsoft world, the next paragraphs can help you to have a more soft approach to Linux world.
sudo is a program for Unix-like computer operating systems that allows users to run programs/commands with the security privileges of another user, normally the superuser or root. Not all the users can call sudo, only the sudoers, architech (the default user of the virtual machine) user is a sudoer. When you run a command preceeded by sudo Linux will ask you the user password, for architech user the password is architech.
Under Linux, (almost) all hardware devices are treated as files. A device file is a special file which allows users to access an hardware device by means of the standard file operations (open, read, write, close, etc), hiding hardware details. All device files are in /dev directory. In order to access a filesystem in Linux you first need to mount it. Mounting a filesystem simply means making the particular filesystem accessible at a certain point in the Linux directories tree. In Linux, memory cards are generally named starting with mmcblk. For example if you insert 2 memory cards in 2 different slots of the same computer, Linux will create 2 device files:
/dev/mmcblk0
/dev/mmcblk1
The number identifies a specific memory card. A memory card itself can have one or more partitions. Even in this case, Linux will create a device file for every partition present in the sd card. So, for example if the “mmcblk0” countains 3 partitions, the operating system will add these files under /dev directory:
/dev/mmcblk0 /* device */
/dev/mmcblk0p0 /* first partition */
/dev/mmcblk0p1 /* second partition */
/dev/mmcblk0p2 /* third partition */
Not all devices are named according to the aforementioned naming scheme. For example, usb pens and hard disks are named with sd followed by a letter which is incremented every time a new device gets connected (starting with a), as opposed to the naming scheme adopted by SD cards where a number (starting with 0) was incremented. A machine with an hard disk and two pen drives would tipically have the following devices:
/dev/sda
/dev/sdb
/dev/sbc
Usually /dev/sda file is the primary hard disk (this might depend on your hardware).
As memory cards, the pen can have one or more partitions, so if for example we have a pen drive which has been recognized as sdc, and the pen drive has 2 partitions on it, we will have the following device files:
/dev/sdc /* device */
/dev/sdc1 /* first partition */
/dev/sdc2 /* second partition */
Commands like mount, umount, dd, etc., use partition device files. FIXME mkfs
Warning
When dealing with plug and play devices, it is quite comfortable to take advantage of dmesg command. The kernel messages (printk) are arranged into a ring buffer, which the user can be easly access by means of dmesg command. Every time the kernel recognizes new hardware, it prints information about the new device within the ring buffer, along with the device filename. To better filter out the information regarding the plug and play device we are interested in, it is better if we first clean up the ring buffer:
$ sudo dmesg -c
now that the ring buffer has been emptied, we can plug the device and, after that, display the latest messages from the kernel:
$ dmesg
On the Ubuntu machine (with kernel version 3.2.0-65-generic) this documentation has been written with, we observed the following messages after inserting a pen drive:
[10553.164670] usb 2-1.2: new high-speed USB device number 7 using ehci_hcd
[10553.261991] scsi7 : usb-storage 2-1.2:1.0
[10554.262123] scsi 7:0:0:0: Direct-Access USB DISK 2.0 1219 PQ: 0 ANSI: 0 CCS
[10554.264376] sd 7:0:0:0: Attached scsi generic sg2 type 0
[10554.268203] sd 7:0:0:0: [sdb] 1957888 512-byte logical blocks: (1.00 GB/956 MiB)
[10554.269344] sd 7:0:0:0: [sdb] Write Protect is off
[10554.269358] sd 7:0:0:0: [sdb] Mode Sense: 43 00 00 00
[10554.270177] sd 7:0:0:0: [sdb] No Caching mode page found
[10554.270187] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[10554.274644] sd 7:0:0:0: [sdb] No Caching mode page found
[10554.274655] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[10554.275287] sdb: sdb1
[10554.278257] sd 7:0:0:0: [sdb] No Caching mode page found
[10554.278268] sd 7:0:0:0: [sdb] Assuming drive cache: write through
[10554.278277] sd 7:0:0:0: [sdb] Attached SCSI removable disk
As you can see, the operating system have recognized the usb device as sdb (this translates to /dev/sdb) and its only partition as sdb1 (this translates to /dev/sdb1)
[10554.275287] sdb: sdb1
The most useful command to gather information about mass storage devices and related partitions is fdisk. On the very same machine of the previous example, the execution of this command:
$ sudo fdisk -l
produces the following output:
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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: 0x410fac6e
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 616447 307200 7 HPFS/NTFS/exFAT
/dev/sda2 616448 933025791 466204672 7 HPFS/NTFS/exFAT
/dev/sda3 933025792 966281215 16627712 83 Linux
/dev/sda4 966281216 976756735 5237760 82 Linux swap / Solaris
Disk /dev/sdb: 1002 MB, 1002438656 bytes
223 heads, 37 sectors/track, 237 cylinders, total 1957888 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: 0x00029795
Device Boot Start End Blocks Id System
/dev/sdb1 2048 1957887 977920 b W95 FAT32
The machine has two mass storage devices, a 500GB hard disk and a 1GB USB pen disk. As you can see from the output, sudo fdisk -l command lists information regarding the disks seen by the kernel along with the partitions found on them, disk after disk. The first disk (sda) presented by fdisk is the primary hard disk (where Linux is running), it has 4 partitions, two of which (sda1 and sda2) are used by a Microsoft operating system while the other two (sda3 and sda4) are used by a Linux operating system. The second disk (sdb) depicted by fdisk is an USB disk with a single FAT32 partition (sdb1)
As already stated, in order to access a filesystem in Linux you first need to mount it. Mounting a partition means binding a directory to it, so that files and directories contained inside the partition will be available in Linux filesystem starting from the directory used as mount point.
Suppose you want to read a file named readme.txt which is contained inside the USB disk of the previous example, in the main directory of the disk. Before accessing the device you must understand if it is already mounted. mount is the command that lets you control the mounting of filesystems in Linux. It is a complex command that permits to mount different devices and different filesystems. In this brief guide we are using it only for a very common use case. Launching mount without any parameter lists all mounted devices with their respective mounting points. Every line of the list, describes the name of the mounted device, where it has been mounted (path of the directory in the Linux filesystem, that is the mount point), the type of filesystem (ext3, ext4, etc.), and the options used to mount it (read and write permissions,etc.). Launching the command on the same machine of the previous section example, we don’t find the device /dev/sdb1.
$ mount/dev/sda2 on /media/windows7 type fuseblk (rw,noexec,nosuid,nodev,allow_other,blksize=4096)/dev/sda3 on / type ext4 (rw,errors=remount-ro)proc on /proc type proc (rw,noexec,nosuid,nodev)sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)none on /sys/fs/fuse/connections type fusectl (rw)none on /sys/kernel/debug type debugfs (rw)none on /sys/kernel/security type securityfs (rw)udev on /dev type devtmpfs (rw,mode=0755)devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)none on /run/shm type tmpfs (rw,nosuid,nodev)binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw)vmware-vmblock on /run/vmblock-fuse type fuse.vmware-vmblock (rw,nosuid,nodev,default_permissions,allow_other)gvfs-fuse-daemon on /home/roberto/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=roberto)
This tells us that the USB disk has not been mounted yet.
The mount operation requires three essential parameters: - the device to mount - the directory to associate - the type of filesystem used by the device
Thanks to the previously introduced fdisk command, we know the partition to mount (/dev/sdb1) and the type of filesystem used (FAT32). The directory to bind can be anything you like, by convention the user should mount his own devices under /media or /mnt. We haven’t created it yet, so:
$ mkdir -p /media/usbdisk
At this point, we have the information we need to execute the mounting. To semplify our life, we leave the duty of understanding what filesystem is effectively used by the device to the mount command by using option -t auto (if we would have wanted to tell mount exactly which filesystem to use we would have written -t vfat), like
$ mount -t auto /dev/sdb1 /media/usbdisk
The partition is now binded to /media/usbdisk directory and its data are accessible from this directory.
$ cd /media/usbdisk
$ ls
readme.txt
now we can open the file, read it and, possibly, modify it.
$ gedit readme.txt
When you want to disconnect the device, you need the inverse operation of mount which is umount. This command saves all data still contained in RAM (and waiting to be written on the device) and unbind the directory from the device file.
$ umount /media/usbdisk
Once the directory /media/usbdisk is unmounted it’s empty, feel free to delete it if doesn’t interest you anymore. It is now possible to remove the device from the machine.
What if you wanted to know the amount of free disk space available on a mounted device?
df command shows the disk space usage of all currently mounted partitions. For every partition, df prints its device file, size, free and used space, and the partition mount point. On our example machine we have:
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 16G 11G 4.0G 74% /
/dev/sda2 445G 408G 37G 92% /media/windows7
-h option tells df to print sizes in human readable format.