Lab 11 Department of Computer Science and Information Engineering National Taiwan University Lab11 - Porting 2014/12/9/ 26 1

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Understand the basic process of porting and learn how to use Buildroot. 2014/12/9/ 26 2

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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 SoftwareRSWiki CSL Course Software 2014/12/9/ 26 3

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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. 2014/12/9/ 26 4

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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.patch 2014/12/9/ 26 5

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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. Reference: Buildroot: /12/9/ 26 6

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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. 2014/12/9/ 26 7

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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/. 2014/12/9/ 26 8

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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 tar.gz buildroot tar.gz  buildroot _dl.tar.gz buildroot _dl.tar.gz  Step 2: extract them, and put pre-downloaded packages dl/ into buildroot /.  Step 3: configure Buildroot.  % make menuconfig  Target Architecture = arm  Target Architecture Variant = xscale 2014/12/9/ 26 9

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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 used in Lab6.  We will use it to compile the ported U-Boot later. 2014/12/9/ 26 10

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Now you will be given the U-Boot source codes without the configuration file for PXA270.U-Boot  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. 2014/12/9/ 26 11

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  include/  contains all header files used globally.  When porting boards, there should exist a board configuration file which is called configs/.h.  board/  contains all the specific board initialization files.  An individual directory for each board is supported by U-Boot.  /lowlevel_init.s : sequence of bootstrapping  /u-boot.lds : linker script  Makefile  Modify the top level makefile to specify the new board support. 2014/12/9/ 26 12

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Now we start to port U-Boot.  We can refer to U-Boot in Lab4 which has been ported to PXA270.U-Boot  Copy the following file and directory from U-Boot to U-boot  include/configs/Create_XScale_PXA270.h  board/Create_XScale_PXA270/  And please rename the board name “ Create_XScale_PXA270 ” to “ mtcr270 ”. 2014/12/9/ 26 13

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Rename memsetup.S to lowlevel_init.S which is the filename of bootstrapping in U-Boot  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 2014/12/9/ 26 14

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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 lab /12/9/ 26 15

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Define some configuration in U-Boot  In include/flash.h,  #define INTEL_ID_28F256P30B 0x891C891C  #define FLASH_28F256P30B 0x00BA  In Makefile, add a rule below at line arm pxa mtcr270  In board/mtcr270/Makefile, set to correct name.  OBJS := mtcr270.o flash.o  SOBJS := lowlevel_init.o 2014/12/9/ 26 16

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  In include/asm-arm/mach-types.h, add the following.  At line 739: #define MACH_TYPE_MTCR  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 2014/12/9/ 26 17

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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 #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 2014/12/9/ 26 18

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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.slide 10  You can refer to Lab /12/9/ 26 19

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  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 and modified one.  Use man diff command to see the meaning of the options.  % diff -Naur >.patch  Tip  Use make distclean command to delete all generated files, configures and temporary files before creating patch. 2014/12/9/ 26 20

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Step 1: add your U-Boot information to Buildroot configuration.  % cd buildroot  % 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 tar.bz2 into dl/ directory.  Step 3: put your patch into specific directory.  % mkdir -p board/ /u-boot patches  % cp.patch board/ /u-boot patches/uboot pxa270.patch 2014/12/9/ 26 21

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Step 4: configure Buildroot. Bootloaders  U-Boot = checked U-Boot board name = mtcr270 U-Boot Version = custom patch dir = board/ /u-boot 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. 2014/12/9/ 26 22

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Add an open-source software “tetris” to Buildroot.tetris  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. 2014/12/9/ 26 23

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Step 1: create a new directory in the package directory.  % cd buildroot  % mkdir package/ /  Step 2: make your package available upon configuration.  % cd package  % vim / /Config.in  config BR2_PACKAGE_  bool " "  default n  % vim Config.in  source "package/ / /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. 2014/12/9/ 26 24

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Step 3: create a Buildroot package Makefile.  % vim / /.mk  Please refer to Atmel’s document.Atmel’s document 2014/12/9/ 26 25

Lab 11 Department of Computer Science and Information Engineering National Taiwan University  Port “U-Boot-1.2.0” to PXA270. You have to use Buildroot to build.  Port “Tetris” to Buildroot. 2014/12/9/ 26 26