1 / 26

Computer System Laboratory

Computer System Laboratory. Lab11 - Porting. Experimental Goal. Understand the basic process of porting and learn how to use Buildroot. Environment. Host System Windows XP Build System VirtualBox + Ubuntu 8.04 Target System Creator XScale PXA270 Software DENX U-Boot source code

dheather
Download Presentation

Computer System Laboratory

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Computer System Laboratory Lab11 - Porting / 26

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

  3. Environment • Host System • Windows XP • Build System • VirtualBox + Ubuntu 8.04 • Target System • Creator XScale PXA270 • Software • DENX U-Boot source code • Buildrootsource code • Buildroot pre-downloaded packages • Vitetris • You can download all software from RSWiki CSL Course Software / 26

  4. 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. / 26

  5. 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 patchfile in Lab5 as an example of OS porting. / 26

  6. 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. Reference: Buildroot: http://buildroot.uclibc.org / 26

  7. 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. / 26

  8. The Process of Buildroot • Compiling process: • Download source files as required. • Configure, build and install the cross-compiling toolchain if an internal toolchain is used, or import a toolchain if an external toolchain is used. • Build selected target packages. • Build a kernel image, if selected. • Build a bootloader image, if selected. • Create a root filesystem in selected formats. • The results are stored in a directory, output/. / 26

  9. 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: dowloadBuildroot 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 / 26

  10. 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. / 26

  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. / 26

  12. 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. / 26

  13. 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”. / 26

  14. 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 / 26

  15. 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. / 26

  16. 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.oflash.o • SOBJS := lowlevel_init.o / 26

  17. 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 # ifdefmachine_arch_type # undefmachine_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 / 26

  18. 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 / 26

  19. 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 Lab4. / 26

  20. 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. / 26

  21. 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 / 26

  22. U-Boot Compilation (2/2) • Step 4: configure Buildroot. Bootloaders  U-Boot = checked U-Boot board name = mtcr270 U-Boot Version = 1.2.0 custom 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. / 26

  23. 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. / 26

  24. 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. / 26

  25. 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. / 26

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

More Related