COMPUTER SYSTEM

LABORATORYLab11 - Porting

/ 262Lab 11

Experimental Goal•Understand the basic process of porting and learn how to use Buildroot.

2013/12/2

/ 263Lab 11

Environment• Host System

• Windows XP

• Build System• VirtualBox + Ubuntu 8.04

• Target System• Creator XScale PXA270

• Software• DENX U-Boot source code• Buildroot source code• Buildroot pre-downloaded packages• Vitetris

• You can download all software from RSWiki CSL Course Software2013/12/2

/ 264Lab 11

Introduction to Porting• In software engineering, porting is the process of adapting software so that an executable program can be created for a computing environment that is different from the one for which it was originally designed (e.g. different CPU, operating system, or third party library).

•Software is portable when the cost of porting it to a new platform is less than the cost of writing it from scratch.

•The lower the cost of porting software, relative to its implementation cost, the more portable it is said to be.

2013/12/2

Reference: wiki info: porting, http://en.wikipedia.org/wiki/Porting

/ 265Lab 11

Popular Embedded OS Architecture•OS porting only needs to modify OS Port layer for the target platform.• Modify the hardware dependent codes, such as

GPIO, memory mapping, or interrupt control.• You can see the kernel patch file in Lab5 as an

example of OS porting.

2013/12/2

/ 266Lab 11

Introduction to Buildroot•Buildroot is a set of Makefiles and patches that makes it easy to generate a complete embedded Linux system.

• It can generate any or all of a cross-compilation toolchain, a root filesystem, a kernel image and a bootloader image.

• It automates the building process of your embedded system and eases the cross-compilation process.

2013/12/2

Reference: Buildroot: http://buildroot.uclibc.org

/ 267Lab 11

Buildroot Source Code Organization• board/

• contains hardware-specific and project-specific files.• boot/

• contains config options and recipes for various bootloaders.• toolchain/

• contains config options and makefiles to build or import the toolchain.• dl/

• contains necessary packages.• Buildroot will automatically download them, but this process is time-

consuming.

2013/12/2

/ 268Lab 11

The Process of Buildroot•Compiling process:

1. Download source files as required.2. Configure, build and install the cross-compiling toolchain if an internal

toolchain is used, or import a toolchain if an external toolchain is used.

3. Build selected target packages.4. Build a kernel image, if selected.5. Build a bootloader image, if selected.6. Create a root filesystem in selected formats.

•The results are stored in a directory, output/.

2013/12/2

/ 269Lab 11

Toolchain Compilation (1/2)• We now use Buildroot to compile the cross toolchain.• Step 0: install necessary packages.

• % sudo apt-get install bison flex gettext

• Step 1: dowload Buildroot and pre-downloaded packages.• buildroot-2011.11.tar.gz• buildroot-2011.11_dl.tar.gz

• Step 2: extract them, and put pre-downloaded packages dl/ into buildroot-2011.11/.

• Step 3: configure Buildroot.• % make menuconfig

• Target Architecture = arm• Target Architecture Variant = xscale

2013/12/2

/ 2610Lab 11

Toolchain Compilation (2/2)•Step 4: compile. (It will take about 10 ~ 20 mins.)

• You should never use “make -jN” with Buildroot.It does not support top-level parallel make.

• We can find the results in output/host/usr/bin.• Buildroot will use it to compile everything selected.

•Step 5: Append this toolchain directory to PATH.• You have to delete the path of cross-2.95.3 used in Lab6.• We will use it to compile the ported U-Boot later.

2013/12/2

/ 2611Lab 11

Porting U-Boot-1.2.0 to PXA270•Now you will be given the U-Boot-1.2.0 source codes without the configuration file for PXA270.

•Please port it to PXA270.• Modify the hardware-dependent codes to fit the architecture of PXA270.

•Please add the ported U-Boot to Buildroot.• Create a patch.• Configure Buildroot so that it applies the patch before building the U-

Boot.

2013/12/2

/ 2612Lab 11

Important Directories and Files for Porting• include/

• contains all header files used globally.• When porting boards, there should exist a board configuration file which

is called configs/<target board>.h.• board/

• contains all the specific board initialization files.• An individual directory for each board is supported by U-Boot.

• <target board>/lowlevel_init.s: sequence of bootstrapping• <target board>/u-boot.lds: linker script

• Makefile• Modify the top level makefile to specify the new board support.

2013/12/2

/ 2613Lab 11

Modification of U-Boot 1.2.0 (1/7)•Now we start to port U-Boot.•We can refer to U-Boot-1.1.2 in Lab4 which has been ported to PXA270.

•Copy the following file and directory from U-Boot-1.1.2 to U-boot-1.2.0.• include/configs/Create_XScale_PXA270.h• board/Create_XScale_PXA270/

•And please rename the board name “Create_XScale_PXA270” to “mtcr270”.

2013/12/2

/ 2614Lab 11

Modification of U-Boot 1.2.0 (2/7)•Rename memsetup.S to lowlevel_init.S which is the filename of bootstrapping in U-Boot-1.2.0.

•There are related labels which should be modified in this file.• You can refer to “lowlevel_init.S” from other boards.

• E.g., board/adsvix/lowlevel_init.S

2013/12/2

/ 2615Lab 11

Modification of U-Boot 1.2.0 (3/7)•Delete some unnecessary functions in board/mtcr270/mtcr270.c.• They are from line 140 to line 158.• /* set CPU speed from config block if not already set */

•Adjust the settings in include/configs/mtcr270.h.• Comment out “#define CONFIG_SERIAL_TAG 1”.• Change “#define CONFIG_INIT_CRITICAL” to “#undef CONFIG_INIT_CRITICAL”.

• Check and correct other common-use settings, such as “CONFIG_BOOTCOMMAND”, “CONFIG_LINUX”, as we do in lab4.

2013/12/2

/ 2616Lab 11

Modification of U-Boot 1.2.0 (4/7)•Define some configuration in U-Boot-1.2.0.• In include/flash.h,

• #define INTEL_ID_28F256P30B 0x891C891C• #define FLASH_28F256P30B 0x00BA

• In Makefile, add a rule below at line 2061.mtcr270_config: unconfig

@$(MKCONFIG) $(@:_config=) arm pxa mtcr270

• In board/mtcr270/Makefile, set to correct name.• OBJS := mtcr270.o flash.o• SOBJS := lowlevel_init.o

2013/12/2

/ 2617Lab 11

Modification of U-Boot 1.2.0 (5/7)• In include/asm-arm/mach-types.h, add the following.

• At line 739: #define MACH_TYPE_MTCR270 780• At line 9406:

#ifdef CONFIG_MACH_MTCR270

# ifdef machine_arch_type

# undef machine_arch_type

# define machine_arch_type __machine_arch_type

# else

# define machine_arch_type MACH_TYPE_MTCR270

# endif

# define machine_is_Create_MTCR270() (machine_arch_type == MACH_TYPE_MTCR270)

#else

# define machine_is_MTCR270()(0)

#endif

2013/12/2

/ 2618Lab 11

Modification of U-Boot 1.2.0 (6/7)• In board/mtcr270/mtcr270.c,

• fix “gd->bd->bi_arch_number = MACH_TYPE_MTCR270” at line 95.• Comment out “printf("CPU speed: %dkHz\n", pxa27x_get_freq());” at line 142.

• In include/asm-arm/arch-pxa/pxa-regs.h, fix at line 1272.#define GPLR(x) (*((((x) & 0x7f) < 96) ? &_GPLR(x) : GPLR3))

#define GPDR(x) (*((((x) & 0x7f) < 96) ? &_GPDR(x) : GPDR3))

#define GPSR(x) (*((((x) & 0x7f) < 96) ? &_GPSR(x) : GPSR3))

#define GPCR(x) (*((((x) & 0x7f) < 96) ? &_GPCR(x) : GPCR3))

#define GRER(x) (*((((x) & 0x7f) < 96) ? &_GRER(x) : GRER3))

#define GFER(x) (*((((x) & 0x7f) < 96) ? &_GFER(x) : GFER3))

#define GEDR(x) (*((((x) & 0x7f) < 96) ? &_GEDR(x) : GEDR3))

#define GAFR(x) (*((((x) & 0x7f) < 96) ? &_GAFR(x) : ((((x) & 0x7f) < 112) ? &GAFR3_L : &GAFR3_U)))

#else

2013/12/2

/ 2619Lab 11

Modification of U-Boot 1.2.0 (7/7)•Disable the warning “target CPU does not support interworking” when compiling.• % vim cpu/pxa/config.mk

PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu)

PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,)

PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call …)

•After the modification, please use the new toolchain as in slide 10 to compile this U-Boot and copy it to PXA270.• You can refer to “mt-crpxa270_config.sh” in Lab4.

2013/12/2

/ 2620Lab 11

Create a Patch for U-Boot•Now we would like to automatically compile the U-Boot by Buildroot, so we have to create a patch.

•Use diff command to create the file containing the differences between U-Boot-1.2.0 and modified one.• Use man diff command to see the meaning of the options.• % diff -Naur <old dir> <new dir> > <your patch name>.patch

•Tip• Use make distclean command to delete all generated files, configures

and temporary files before creating patch.

2013/12/2

/ 2621Lab 11

U-Boot Compilation (1/2)• Step 1: add your U-Boot information to Buildroot configuration.

• % cd buildroot-2011.11

• % vim boot/uboot/Config.in…

config BR2_TARGET_UBOOT_1_2_0

bool "1.2.0"

…

config BR2_TARGET_UBOOT_VERSION

string

…

default "1.2.0" if BR2_TARGET_UBOOT_1_2_0

• Step 2: put u-boot-1.2.0.tar.bz2 into dl/ directory.• Step 3: put your patch into specific directory.

• % mkdir -p board/<patch path>/u-boot-1.2.0-patches

• % cp <your patch name>.patch board/<patch path>/u-boot-1.2.0-patches/uboot-1.2.0-0001-pxa270.patch

2013/12/2

/ 2622Lab 11

U-Boot Compilation (2/2)•Step 4: configure Buildroot.

Bootloaders U-Boot = checkedU-Boot board name = mtcr270U-Boot Version = 1.2.0custom patch dir = board/<patch path>/u-boot-1.2.0-patches

•Step 5: compile.•The resulting u-boot.bin is in output/images/.•Tip

• The name of the patch is determined by support/scripts/apply-patches.sh.

2013/12/2

/ 2623Lab 11

Application Porting•Add an open-source software “tetris” to Buildroot.•You need to use Lab3’s arm-unknown-linux-gnu-* toolchain to compile tetris.

•However, Buildroot’s external toolchain option does not work.• For simplicity, you can set tetris’s cross compiler directly.• Do not forget to compile tetris as statically linked.

2013/12/2

/ 2624Lab 11

Tetris Compilation (1/2)• Step 1: create a new directory in the package directory.

• % cd buildroot-2011.11

• % mkdir package/<software type>/<software name>

• Step 2: make your package available upon configuration.• % cd package

% vim <software type>/<software name>/Config.in

config BR2_PACKAGE_<SOFTWARE_NAME>bool "<software name>"

default n

• % vim Config.in

• source "package/<software type>/<software name>/Config.in"

• The position where you insert the reference to your packages decides where the entry in menu system is going to be later on.

2013/12/2

/ 2625Lab 11

Tetris Compilation (2/2)•Step 3: create a Buildroot package Makefile.

• % vim <software type>/<software name>/<software name>.mk

• Please refer to Atmel’s document.

2013/12/2

/ 2626Lab 11

Lab Requirement•Port “U-Boot-1.2.0” to PXA270. You have to use Buildroot to build.

•Port “Tetris” to Buildroot.

2013/12/2