computer system laboratory n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Computer System Laboratory PowerPoint Presentation
Download Presentation
Computer System Laboratory

Loading in 2 Seconds...

play fullscreen
1 / 26

Computer System Laboratory - PowerPoint PPT Presentation


  • 114 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Computer System Laboratory' - lindsey


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
experimental goal
Experimental Goal
  • Understand the basic process of porting and learn how to use Buildroot.

/ 26

environment
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 Software

/ 26

introduction to porting
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.

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

/ 26

popular embedded os architecture
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.

/ 26

introduction to buildroot
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

buildroot source code organization
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

the process of buildroot
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

toolchain compilation 1 2
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

toolchain compilation 2 2
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

porting u boot 1 2 0 to pxa270
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

important directories and files for porting
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

modification of u boot 1 2 0 1 7
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

modification of u boot 1 2 0 2 7
Modification of U-Boot 1.2.0 (2/7)
  • Rename memsetup.S to lowlevel_init.Swhich 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

modification of u boot 1 2 0 3 7
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 “#undefCONFIG_INIT_CRITICAL”.
    • Check and correct other common-use settings, such as “CONFIG_BOOTCOMMAND”, “CONFIG_LINUX”, as we do in lab4.

/ 26

modification of u boot 1 2 0 4 7
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

modification of u boot 1 2 0 5 7
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

modification of u boot 1 2 0 6 7
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

modification of u boot 1 2 0 7 7
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.

/ 26

create a patch for u boot
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

u boot compilation 1 2
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

u boot compilation 2 2
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

application porting
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

tetris compilation 1 2
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

tetris compilation 2 2
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

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

/ 26