Home

How to become a PTXdist Guru Based on the

Contents

1. SECTION fixme config FOO tristate prompt foo help FIXME We ll add two menu entries one for each optional parameter we want to add on demand to the configure pa rameters SECTION fixme config FOO tristate prompt foo help FIXME if FOO config FOO_DEBUG bool prompt add debug noise config FOO_BAR bool prompt build bar endif Note To extend the base name by a suboption name as a trailing component gives PTXdist the ability to detect a change in the package s settings to force its rebuild To make usage of the new menu entries we must check them in the rule file and add the correct parameters f Pengutronix a 4 PTXdist Developer s Manual autoconf FOO_AUTOCONF CROSS_AUTOCONF_USR ifdef PTXCONF_FOO_DEBUG FOO_AUTOCONF enable debug else FOO_AUTOCONF disable debug endif ifdef PTXCONF_FOO_BAR FOO_AUTOCONF with bar else FOO_AUTOCONF without bar endif It is a good practice to add both settings e g disable debug even if this is the default case Sometimes configure tries to guess something and the binary result might differ depending on the build order For example some kind of package would also build some X related tools if X libraries are found In this case it depends on the build order if the X related tools are built or not All the autocheck features are problematic here So if we do not want configure to guess its settin
2. 58 4 f Pengutronix Contents 6 5 3 PTXdist 1LookandFeel lt o o aoco coa e e 59 6 6 Software Installation and Upgrade 2 o e 59 661 ipke Usage MPTXdISE io ocio sd as e 59 6 6 2 Packet Installation lt o coou ao o e e 60 6 6 3 Automatic Packet Download o o 4 2 4 60 66 4 Theipke Command o s a ea mann dapa a ia a A 60 6 7 Downloading Packages from the Web naonao o o e 62 68 Adding Files into the Bulld s s sass a i aca i we m ee de bee ee ea 62 6 8 1 Creating the Rule and Menu File anaona o lt 63 6 8 2 Adapting the Generic Rule File 2 aa ee 63 6 8 3 Adapting the Menu File 2 aoaaa a a ee 63 7 Document Revisions 64 8 Getting help 65 30 Mantes woe cee E h a we doe dd Se a OO a aed hee ed 65 8 1 1 About PTXdist in Particular 2 2 2 4 0s e654 ee eek ee ee ees 65 8 1 2 About Embedded Linux in General 000 eee ee 65 Da NeWSIGOUPS o soa oopa i a A ie ce a ew Rok a R 65 8 2 1 About Linux in Embedded Environments aasa 0000 0 eee eee 65 8 2 2 About General Unix Linux Questions 2 ee ee 65 Bee OSDIR yo Bhs Soe ee o ua ee pta ae CRE Bee eo Bie rs Eee eS 66 84 Commercial Support i osim a A a we en oe ia wa a 66 f Pengutronix 5 1 Welcome to the Embedded World 1 1 First Steps in the Embedded World Once upon in time programming embedded systems was easy all a developer nee
3. 5 31 Default stage rules o monica ae ek ee we ee 49 232 SkippingasStage lt sor mee ee a dye a EW ae oe oY he ee ea 50 5 4 PTXdist parameter reference ee 51 541 S tupand Project Actions e oo gece da Se a a a 51 SA2 BWIGACIONS ic cee eae Ra a AS hae Sea eS a ee a A ia 51 me Clan ee a ER aoe Be eae ee eae eg 52 6 Various Aspects of Daily Work 53 6 1 Using an External Kernel Source Tree 2 o 53 6 1 1 Cloning the Linux Kernel Source Tree o e 53 bz Conigurme PTAS lt oes e e SO cee te dl e e le G 53 61 3 Configuring the PTXdiSt Project socios ir a a aa d aa 53 Git WORCRIOW 203 sacas dl do e ai a bee ee 54 6 2 Discovering Runtime Dependencies o o o 54 6 2 1 Dependencies on Shared Libraries 2 2 e ee 55 6 2 2 Dependencies on other Resources eet ee 55 6 3 Debugging with CPU emulation o o o o 56 6 3 1 Running an Application made for a different Architecture o 56 6 3 2 Debugging an Application made fora different Architecture 56 6 4 Migration between Minor Releases o 57 an Simples Uperade oa os a a a a A eS Ge 57 6 5 Migration between Major Releases e 58 651 Basic CONVERSION sso ci E A RR O a RA A 58 6 5 2 Adaption of Rules Files lt lt ss s c a e e
4. It collects all required source archives into one given single directory To do so the current project must be set up correctly e g the select and platform com mands must be ran prior the export_src step If everything is set up correctly we can run the following commands to get the full list of required archives to build the project again without a internet connection mkdir my_archives ptxdist export_src my_archives PTXdist will now collect all source archives to the my_archives directory Note If PTXdist is configured to share one source archive directory for all projects this step will simply copy the source archives from the shared source archive directory Otherwise PTXdist will start to download them from the world wide web 6 8 Adding Files into the Build Most projects handled by PTXdist are needing more than a simple root filesystem So there is a cause for addi tional files in every project to be automatically installed when the ptxdist go command is running These files could be HTML files to be provided by a web server running on the target or some special kind of configuration files that PTXdist does not support natively Basically we must add two files for this task rules adding_file in This file describes the corresponding menu for this package It is called a menu file rules adding_file make This file describes what to do while the ptxdist go command is running It is called a rule file The name adding_
5. amp Console Tools gt busybox gt Coreutils gt head After activating the head entry we leave the menu and save the new configuration Once again a ptxdist go will build or re build the busybox package due to its configuration change And also once again after finishing its job the following commands let us test the new command ptxdist images configs arm qemu 3 run Log in on the emulated system and simply check with a 26 f Pengutronix 3 PTXdist User s Manual ptx login root login xxx root login on ttyS0 root ptx head etc fstab etc fstab special filesystems proc proc proc defaults 00 debugfs sys kernel debug debugfs defaults noauto 00 devpts dev pts devpts defaults 00 none tmp tmpfs defaults mode 1777 uid 0 gid 0 0 0 none sys sysfs defaults 00 We are done now These simple examples should give the users a quick feeling how things are working in PTXdist and how to modify them Adapting this generic BSP to a different platform with nearly the same features as our reference platforms is possible with this knowledge But most of the time a user needs more detailed adaptions to be able to fit all requirements of the new platform At this point oftime we are no longer ordinary users of PTXdist we become developers now So right now its time to read the PTXdist Developer s Manual f Pengutronix 27 4 PTXdist Developer s Manual T
6. assembler linker and so on select Used to select the current userland configuration which is only required if there is no selected_ptxconfig in the project s main directory This parameter needs the path to a valid ptxconfig It will generate a soft link called selected_ptxconfig in the project s main directory platform Used to select the current platform configuration which is only required if there is no se lected_platformconfig in the project s main directory This parameter needs the path to a valid platformconfig It will generate a soft link called selected_platformconfig in the project s main di rectory collection Used to select the current collection configuration which is only required in special cases This pa rameter needs the path to a valid collection It will generate a soft link called selected_collection in the project s main directory This is an advanced feature rarely used go The mostly used command This will start to build everything to get all the project defined software parts Also used to rebuild a part after its configuration was changed images Used at the end of a build to create an image from all userland packages to deploy the target its flash for example or its hard disk setup Mostly run once per PTXdist revision to set up global paths and the PTXdist behavior All these commands depending on various files a PTXdist based project provides So running the commands make only sense in direc
7. f Pengutronix 35 4 PTXdist Developer s Manual El klibc module init tools in SECTION initramfs xkeyboard config in SECTION multimedia_xorg_data xorg app xev in SECTION multimedia_xorg_app xorg app xrandr in SECTION multimedia_xorg_app host eggdbus in SECTION hosttools_noprompt libssh2 in SECTION networking Porting a new package to PTXdist is finished now To check it right away we simply run these two commands ptxdist clean foo rm rf home jbe my_new_prj state foo x rm rf home jbe my_new_prj packages foo_ rm rf home jbe my_new_prj build target foo 1 1 0 ptxdist targetinstall foo Enroll 4 2 3 Advanced Rule Files The previous example on how to create a rule file sometimes works as shown above But most of the time source archives are not that simple In this section we want to give the user a more detailed selection how the package will be built Adding Static Configure Parameters The configure scripts of various source archives provide additional parameters to enable or disable features or to configure them in a specific way We assume the configure script of our foo example refer to section 4 2 1 supports two additional parameters e enable debug Make the program more noisy It s disabled by default e with bar Also build the special executable bar Building this executable is also disabled by default We now want to forward these options to the configure sc
8. usr bin myapp This command will run the application usr bin myapp built for an armg26 CPU on the build host and is using all library compontents from the current directory For the stdin and out QEMU uses the regular mechanism of the build host s operating system Using QEMU in this way let us simply check our programs There are also QEMU environments for other architectures available 6 3 2 Debugging an Application made for a different Architecture Debugging our application is also possible with QEMU All we need are a root filesystem with debug symbols available QEMU and an architecture aware debugger The root filesystem with debug symbols will be provided by PTXdist the architecture aware debugger comes with the OSELAS Toolchain Two consoles are required for this debug session in this example We start the QEMU in the first console as cd platform versatilepb root debug platform versatilepb root debug qemu arm g 1234 cpu arm926 L usr bin myapp Note PTXdist always builds two root filesystems platform versatilepb root and platform versatilepb root debug platform versatilepb root contains all components without debug information all binaries are in the same size as used later on on the real target while all components in platform versatilepb root debug still containing the debug symbols and are much bigger in size 56 f Pengutronix 6 Various Aspects of Daily Work The added g 1234 parameter lets QEMU wa
9. 29 Contents 42 Adding NeW Packages oi Ge ee b a he a OO ee e ee 29 4241 Rule file Creation s oor gon 2554054404 hee bea Gheeeee deeded wes 30 422 Maket Work lt a a 654 hb 824845 bee ee BS a Ae ee ee REE 31 4 2 3 AdvancedRuleFiles 2 2 0 ee ee 36 EA Patching Packages iaa Wea a a ea ae a wl ee A ea a 41 4 2 5 Creating Patches fora Package o ee 41 4 2 6 Modifying Autotoolized Packages oo e 42 5 PTXdist Reference 44 s1 Variables Referente sia cate a a A a a a A ee 44 ean PIXDISTTOPDIR oscene ae a ea A HERES 44 5 1 2 PTXDIST_WORKSPACE onunu naa 6255 eiedeaue Peas 44 513 PTXDIST SYSROOT ROSS lt uiscci Saale we E oi aea eS le BS 44 Sia PTXDIST SYSROOT HOST 2 coda A ee OR SE He BEA E 44 5 1 5 PINDIST SYSROOTTARGED cis caca doe Ga ee town dee wed 45 SLG CROSS PAM e ek ow Pa ee we ew ee wk a A A 45 517 POSTAT 00 SR dom a shots Bed Gein fw oh Sen ee oh A hy a 45 So ROOTDIR 4 204 wh eR do Ee hon aoe ad A re eae a eh 45 5 2 Rule File Macro Reference ee 45 Sa O ek a A a a et ee oe eed 45 pea A ch Seek E es at ay a a 2 Ek i a 2 eet Bo 2 Be A 46 MOR GOIN 2 So he ahs A E me ea ee me eS a 46 A WIAA ORs oe ee we a a ee OP amp Oe eee 8 ee Nk a E S 46 ok metallLa ema 0 2 Bonds ce amp EE amp we dee we RS ee ree FS 47 BG SEAS soi cided o eek ep bk ee ec dee di oe ee 48 53 Rulefilelayout o 2 0 50 484 ee Se SHG Ce Oe Gece De eM ee we eS 48
10. Due to the fact that we do not have any patch yet we ll start with an empty series file touch patches foo 1 1 0 series Next is to extract the package if already done we must remove it first ptxdist extract foo This will extract the archive and create a symbolic link in the build directory pointing to our local patch directory Working this way will ensure that we do not lose our created patches if we enter ptxdist clean foo by accident In our case the patches are still present in patches foo 1 1 0 and can be used the next time we extract the package again All we have to do now is to do the modification we need to make the package work We change into the build directory and use quilt to create new patches add files to respective patches modify these files and refresh the patches to save our changes We recommend this way when modifying source files But this way is improper when an autotools based buildsys tem itself needs modifications Referto section 4 2 6 on how PTXdist can handle this special task Adding more Patches to a Package If we want to add more patches to an already patched package we can use nearly the same way as creating patches for the first time But ifthe patch series comes from the PTXdist main installation we do not have write permissions to these directories do NEVER work on the main installation directories NEVER NEVER NEVER Dueto the search order in which PTXdist searches for patches for a spec
11. PTXdist uses some global settings independent from the project it is working on These settings belong to users preferences or simply some network settings to permit PTXdist to download required packages boardsetup PTXdist based projects can provide information to setup and configure the target automatically This action let the user setup the environment specific settings like the network IP address and so on projects If the generic projects coming in a separate archive are installed this actions lists the projects a user can clone for its own work clone lt from gt lt to gt This action clones an existing project from the projects list into a new directory The lt from gt argument must be a name gotten from ptxdist projects command the lt to gt argument is the new project and directory name creeated in the current directory menuconfig Start the menu to configure the project s root filesystem This is in respect to userland only Its the main menu to select applications and libraries the root filesystem of the target should consist of menuconfig platform This action starts the menu to configure platform s settings As these are architecture and target specific settings it configures the toolchain the kernel and a bootloader but no userland components Due to a project can support more than one platform this will configure the currently selected platform The shortform for this action is platformconfig menuconfig kernel St
12. directory to the root filesystem call install_copy foo 0 0 0755 usr bin foo 5 2 5 install_alternative Usage call install_alternative lt package gt lt UID gt lt GID gt lt permission gt lt destination gt Installs given files or directories into e the project s platform versatilepb root e the project s platform versatilepb root debug e an ipkg packet in the project s platform versatilepb packages The base parameters and their meanings lt package gt Name of the IPKG the macro should work on lt UID gt User ID in a numerical value the file should use in target s root filesystem lt GID gt Group ID in a numerical value the file should use in target s root filesystem lt permission gt Permission in an octal value the file should use in target s root filesystem The parameter lt destination gt is meant as an absolute path and filename in target s root filesystem PTXdist searches for the source of this file in e the local project e PTXdist s install path f Pengutronix ue 5 PTXdist Reference If the file exists in the local project it will be used for the target root filesystem Ifthe local project does not contain this file the generic file from the PTXdist installation directory will be used If our lt destination gt is etc foo conf PTXdist checks first if projectroot etc foo conf exists Else it uses the file lt ptxdist install path gt generic etc foo conf
13. each package If a package s rule file does not provide a specific stage rule the default stage rule will be used instead Omitting one of the stage rules does not mean that PTXdist skips this stage In this case the default stage rule is used instead get Stage Default Rule Ifthe get stage is omitted PTXdist runs instead STATEDIR package get call targetinfo call touch Which means this step is skipped If the package is an archive that must be downloaded from the web the following rule must exist in this case package _SOURCE call targetinfo call get package extract Stage Default Rule If the extract stage is omitted PTXdist runs instead STATEDIR package extract call targetinfo call clean package _DIR call extract package call patchin package call touch prepare Stage Default Rule If the prepare stage is omitted PTXdist runs a default stage rule depending on some variable settings Ifthe package s rule file defines a package _AUTOCONF variable FOO_AUTOCONF for our foo example PTXdist treats this package as an autotoolized package and runs STATEDIR package prepare call targetinfo call clean package _DIR config cache cd package _DIR package _SUBDIR amp amp package _PATH package _ENV configure package _AUTOCONF call touch f Pengutronix a 5 PTXdist Ref
14. has to be e auditable and e reproducable Embedded developers usually want to know what s in their systems be it that they have to support their software for a long time span something like 10 15 years are usual product lifetimes in automation applications or that they have such a special scenario that they have to maintain their integrated source of their Userland themselves Entering PTXdist f Pengutronix 2 Getting a working Environment 2 1 Download Software Components In order to follow this manual some software archives are needed There are several possibilities how to get these either as part of an evaluation board package or by downloading them from the Pengutronix web site The central place for OSELAS related documentation is http www oselas com This website provides all re quired packages and documentation at least for software components which are available to the public To build OSELAS BSP Pengutronix Generic 2010 01 0 the following archives have to be available on the devel opment host e ptxdist 2010 04 0 tgz e ptxdist 2010 04 0 patches tgz e OSELAS BSP Pengutronix Generic 2010 01 0 tar gz e OSELAS Toolchain 1 99 3 6 tar bz2 If they are not available on the development system yet it is necessary to get them 2 2 PTXdist Installation The PTXdist build system can be used to create a root filesystem for embedded Linux devices In order to start development with PTXdist it is necessary to inst
15. instead In a multiplatform project PTXdist checks first for the file projectroot etc foo conf lt platform name gt and then for projectroot etc foo conf and falls back to the generic one if noone of these files exist 5 2 6 install_link Usage call install_link lt package gt lt point to gt lt where gt Installs a symbolic link into e the project s platform versatilepb root e the project s platform versatilepb root debug e anipkg packet in the project s platform versatilepb packages The parameters and their meanings lt package gt Name of the IPKG the macro should work on lt pointto gt Path and name the link should point to Note This macro rejects absolute paths If needed use relative paths instead lt where gt Path and name of the symbolic link A few usage examples Create a symbolic link as usr lib libfoo so pointing to libfoo so 1 1 0 in the same directory call install_link foo libfoo so 1 1 0 usr lib libfoo so Create a symbolic link as usr bin foo pointing to bin bar call install_link foo bin bar usr bin foo 5 3 Rule file layout Each rule file provides PTXdist with the required steps to be done ona per package base e get extract prepare compile install targetinstall 48 f Pengutronix 5 PTXdist Reference 5 3 1 Default stage rules As for most packages these steps can be done in a default way PTXdist provides generic rules for
16. j qui mt spa jii T allt fut aul ag OSELAS Support OSELAS Training OSELAS Development OSELAS Services How to become a PTXdist Guru Based on the OSELAS BSP Pengutronix Generic arm Pengutronix Pengutronix e K Peiner Stra e 6 8 31137 Hildesheim 49 0 51 21 20 69 17 0 Fon 49 0 5121 20 69 17 55 55 Fax info pengutronix de 2010 Pengutronix Hildesheim Rev 1531 428 gt IUBd U0g Z JOPUOW INO uo 13135 pue 99H NJ Contents 1 Welcome to the Embedded World 1 1 First Steps inthe Embedded World o o e 1 2 FromServertoEmbedded ee ee 13 Linti e Embedded Linux lt sip aacr be eo Pe Bee ee ee See a 2 Getting a working Environment 2 1 Download Software Components a a2 PTXdistinstallation o o gc a we a A a we 221 Wain Partsof PIXdist i ocios eas Gees ee eden bd ee be 223 Extracting the Sources o strone maa a a ME eh ee eS 237 UP MOTSOUIGHOS sx ah es ek Ge ee A Mla Ge ae eee sete ee ke wt a aza Conagua PT AGE se a GS Se ee ee ee el ee ee EA Zae MCAS fine bg e een Bae SR ee Ses SF Bie bare Boe 237 Using Existing Toolenains osos be eee ee eee Oo ae 2332 BuildingaToolenaity lt lt cerda e Be A ae a e 2 3 3 Building the OSELAS Toolchain for OSELAS BSP Pengutronix Generic 2010 01 0 234 Protecting the Toolehall 0 05 sands a e e a e e 2 3 5 Building Additional Toolchains
17. key again There are shortcuts available instead of pressing the Enter key to entera menu we also can press alt s and to leave a menu alt e Also an ESC double hit leaves any menu we are in To select a menu entry we use the Space key This will toggle the selection Or to be more precise and faster we use the key y to select an entry and key n to deselect it To get help for a specific menu topic we navigate vertically to highlight it and horizontally to select the Help entry Then we can press Enter to see the help To search for specific keywords we press the key and enter a word Kconfig then lists all occurences of this word in all menus Meaning of visual feedbacks in Kconfig e Submenus to enter are marked with a trailing gt Note Some submenus are also marked with a leading bracket To enter them we first must select en able them x Entries with a list of selectable alternatives are also marked with a trailing gt e Entries we can select are marked with a leading empty bracket Entries that are already selected are marked with a leading filled bracket x Entries that are selected due to dependencies into other selected entries are marked with a leading e Some entries need a free text to enter they are marked with leading brackets and the free text in it Menus and submenus in Kconfig sectioning There are dozens of entries in the PTXdist configuring menus To handle them they are divided and separate
18. need is a packet system that e offers installation removement of packages e has no big database but a very low overhead e allows packet management features like pre post scripts i e shutdown a web server then upgrade it and start it again ipkg is such a packet system and it is being used in ptxdist Originally developed for the IBM Itsy ipkg is mean while being used on all kinds of embedded Linux projects The concept of ipkg archives is based on the well known Debian packet management format ipkg archives are ar archives containing a tarball with the binary files for the target box plus management scripts which can be run on pre install post install pre rm and post rm So even if no ipkg management utilities are available developers can modify the archives with standard shell and console tools 6 6 1 ipkg Usage in PTXdist PTXdist end users and packet developers don t have to care directly about ipkg Packages are being created during the targetinstall stage then put into the platform versatilepb packages directory After the targetinstall f Pengutronix 3 6 Various Aspects of Daily Work stage of a packet was done this directory contains the ipkg packet itself plus for most packages a directory with the file content The ipkg packets contain the binaries for the root filesystem as well as start stop scripts and meta data about the Unix filesystem permissions when PTXdist creates the root filesystem which is
19. very long and the interesting parts are lost So if we assume the binary tries to open a nonexisting file we can limit the output to all open system calls f Pengutronix 2 6 Various Aspects of Daily Work strace e open usr bin foo open etc 1d so cache O_RDONLY 3 open 1lib libm 2 5 1 so O_RDONLY 3 open 1lib libz so 1 2 3 O_RDONLY 3 open 1lib libc so 6 O_RDONLY 3 E open etc foo conf O_RDONLY 1 ENOENT No such file or directory The binary may fail due to a missing etc foo conf This could be a hint on what is going wrong it might not be the final solution 6 3 Debugging with CPU emulation If we do not need some target related feature to run our application we can also debug it through a simple CPU emulation Thanks to QEMU we can run ELF binaries for other architectures than our build host is 6 3 1 Running an Application made for a different Architecture PTXdist creates a fully working root filesystem with all runtime components in platform versatilepb root Lets assume we made a PTXdist based project for a armg26 CPU Part of this project is our application myapp we are currently working on PTXdist builds the root filesystem and also compiles our application It also installs it to usr bin myapp in the root filesystem With this preparation we can run it on our build host cd platform versatilepb root platform versatilepb root qemu arm cpu arm926 L
20. 4 0 projects tgz If everything goes well we now have a PTXdist 2010 04 0 directory so we can change into it cd ptxdist 2010 04 0 S de 1 total 532 rw r r 1 jb users 18361 Jan 6 14 50 COPYING rw r r 1 jb users 3865 Jan 6 14 50 CREDITS rw r r 1 jb users 115540 Jan 6 14 50 ChangeLog rw r r 1 jb users 57 Jan 6 14 5 INSTALL rw r r 1 jb users 2228 Jan 6 14 50 Makefile in rw r r 1 jb users 4196 Jan 6 14 50 README rw r r 1 jb users 691 Jan 6 14 50 REVISION_POLICY rw r r 1 jb users 63019 Jan 6 14 50 TODO rwxr xr x 1 jb users 28 Jan 6 14 50 autogen sh drwxr xr x 2 jb users 4096 Jan 6 14 50 bin f Pengutronix 3 2 Getting a working Environment drwxr xr x 9 jb users 4096 Jan 6 14 50 config rwxr xr x 1 jb users 213205 Jan 6 16 29 configure rw r r 1 jb users 12539 Jan 6 14 50 configure ac drwxr xr x 10 jb users 4096 Jan 6 14 50 generic drwxr xr x 162 jb users 4096 Jan 6 14 50 patches drwxr xr x 2 jb users 4096 Jan 6 14 50 platforms drwxr xr x 4 jb users 4096 Jan 6 14 50 plugins drwxr xr x 6 jb users 32768 Jan 6 14 50 rules drwxr xr x 8 jb users 4096 Jan 6 14 50 scripts drwxr xr x 2 jb users 4096 Jan 6 14 50 tests 2 2 3 Prerequisites Before PTXdist can be installed it has to be checked if all necessary programs are installed on the development host The configure script will stop if it discovers that something is missing The PTXdist installation is based on GNU autotools so the firs
21. ION missing call install_copy foo 0 0 0755 FOO_DIR foobar dev null call install_finish foo call touch The header of this stage defines some information IPKG needs The important part that we must modify is the call to the install_copy macro refer to section 5 2 for more details about this kind of macros This call instructs PTXdist to include the given file with PID UID and permissions into the IPKG which means to install this file to the target s root filesystem From the previous install stage we know this package installs an executable called foo to location usr bin We can do the same for our target by changing the install_copy line to call install_copy foo 0 0 0755 FOO_DIR foo usr bin foo To check it we just run f Pengutronix al 4 PTXdist Developer s Manual ptxdist targetinstall foo install_init install_init install_init install_init install_init install_init install_fixup install_fixup install_fixup install_fixup install_fixup install_fixup install_copy preparing for image creation ARCH gt 1386 done preinst not available postinst not available prerm not available postrm not available PACKAGE gt foo done PRIORITY gt optional done VERSION gt 1 1 0 done ESECTIONO gt base done AUTHOR gt My Name lt me my org com gt done DESCRIPTION G gt missing don
22. L of basedir This URL tells PTXdist where to download the source archive from the web if not already done If the full URL to download the archive is http www foo com download src foo 1 1 tar gz the basedir part http www foo com download src is to enter here suffix Archives are using various formats for distribution PTXdist uses the suffix entry to select the match ing extraction tool If the archive s full name is foo 1 1 0 tar gz then tar gz is the suffix to enter here package author If we intend to contribute this new package to PTXdist mainline we should add ourname here This name will be used in the copyright note of the rule file and will also be added to the generated ipkg 4 2 2 Make it Work Generating the rule file is only one of the required steps to get a new package The next steps to make it work are to check if all stages are working as expected and to select the required parts to get them installed in the target root filesystem Also we must find a reasonable location where to add our new menu entry to configure the package The generated skeleton starts to add the new menu entry in the main configure menu Running ptxdist menuconfig will show it on top of all other menus entries To be able to implement all the other required steps for adding a new package we first must enable the package for building fine tuning the menu can be the last step Lets start checking the get and extract stage calling them
23. Navigate to entry Proxies and enter the required addresses and ports to access the proxy in the form lt protocol gt lt address gt lt port gt Source Archive Location Whenever PTXdist downloads source archives it stores these archives in a project local manner If we are working with more than one project every project would download its own required archives To share all source archives between all projects PTXdist can be configured to use only one archive directory for all projects it handles Nav igate to menu entry Source Directory and enter the path to the directory where PTXdist should store archives to share between projects Generic Project Location If we already installed the generic projects we should also configure PTXdist to know this location If we already did so we can use the command ptxdist projects to get a list of available projects and ptxdist clone to get a local working copy of a shared generic project 11 f Pengutronix 2 Getting a working Environment Navigate to menu entry Project Searchpath and enter the path to projects that can be used in such a way Here we can configure more than one path each part can be delemited by a colon For example for PTXdist s generic projects and our own previous projects like this usr local lib ptxdist 2010 04 0 projects office my_projects ptxdist Leave the menu and store the configuration PTXdist is now ready for use 2 3 Toolchains Before we can st
24. ROOT_CROSS include for header files and PTXDIST_SYSROOT_CROSS Lib for libraries 5 1 4 PTXDIST_SYSROOT_HOST PTXDIST_SYSROOT_HOST points to a directory tree all host relevant executables libraries and header files are installed to All project s packages built for the host are searching in this directory tree for their depen dencies executables header and library files Use PTXDIST_SYSROOT_HOST bin to install executables PTXDIST_SYSROOT_HOST include for header files and PTXDIST_SYSROOT_HOST 1ib for libraries f Pengutronix a 5 PTXdist Reference 5 1 5 PTXDIST_SYSROOT_TARGET PTXDIST_SYSROOT_TARGET points to a directory tree all target relevant libraries and header files are installed to All project s packages built for the target are searching in this directory tree for their dependencies header and library files These files are for compile time only for example to link a target executable against a target library not for runtime Use PTXDIST_SYSROOT_TARGET include for header files and PTXDIST_SYSROOT_TARGET lib for libraries Other useful variables 5 1 6 CROSS_PATH Use to find cross tools This path must be used to create anything that depends on the target s architecture but needs something running on the host to do the job Examples Creating a jffs2 image from the target s root filesystem This will need a tool running on the host but it will create data or code that runs on or is used on the
25. USB lt gt OHCI HCD support fPengutronn 25 Pengutronix 3 PTXdist User s Manual Note All the listed empty and lt gt above must be activated to get all submenu entries We leave the menu and save the new kernel configuration To start building a new kernel with the new configuration we again run ptxdist go This builds or re builds the kernel because we changed its settings Note If nothing was changed ptxdist goalso will do nothing When PTXdist has finished its job the new bootable kernel can be found at platform versatilepb images linuximage To boot it again in the QEMU emulation the hard disk image must be re created with ptxdist images configs arm qemu 3 run The emulated system should now start with a 2 6 32 based kernel with USB support 3 3 4 Adapting Userland Settings After changing some platform and kernel settings we are now reaching the most interesting area Userland In the userland area we can enable and use all the applications and services PTXdist provides Many of them are working out of the box when enabled and executed on the target side Some need additional runtime configura tion but PTXdist comes with most common configurations for such packages In this simple example we want to add the missing head command to our target s shell First we run ptxdist menuconfig The additional command we want to enable is provided by the Busybox package So we navigate to Shell
26. ackporting rule files from more recent PTXdist revisions to projects that are stuck to an older PTXdist revision for maintenance only 4 1 2 Patch Series There are many packages in the wild that are not cross build aware They fail compiling some files use wrong include paths or try to link against host libraries To be sucessful in the embedded world these types of failures must be fixed If required PTXdist provides such fixes per package They are organized in patch series and can be found in the patches directory within a subdirectory using the same name as the package itself PTXdist uses the utility patch or quilt to apply an existing patch series after extracting the archive So every patch series contains a set of patches and one series file to define the order in which the patches must be applied Note Patches can be compressed 28 f Pengutronix 4 PTXdist Developer s Manual Besides the patches directory at the main installation location PTXdist searches two additional locations for a patch series for the package in question One location is the project s currently used platform directory If the currently used platform is located in configs arm qemu 3 PTXdist searches in configs arm qemu 3 patches lt package name gt If no patch series was found in the platform directory the next location PTXdist it searches for a patch series is the main project directory in patches lt package name gt If both project loc
27. age decides which parts are copied to the root filesystem So compiling and linking of our package will work because everything required is found in the target s sysroot In our example there is a hidden dependency to the math library libm Our new package was built successfully because the linker was able to link our binaries against the libm from the toolchain But in this case the libm must also be available in the target s root filesystem to fulfil the runtime dependency We have to force PTXdist to install 1ibm 1ibmis part of the glibc package but is not installed by default to keep the root filesystem small So it does not help to select the GLIBC symbol to get a libmat runtime The correct solution here is to add a select LIBC_Mto our menu file With all the additions above it now looks like SECTION fixme config FOO tristate select ZLIB if FOO_FOO select LIBXML2 if FOO_BAR select LIBC_M prompt foo help FIXME if FOO config FOO_DEBUG bool prompt add debug noise config FOO_FOO bool prompt build foo config FOO_BAR bool prompt build bar endif Note There are other packages around that do not install everything by default If our new package needs something special we musttake a look into the menu ofthe other package how to force the required components to be installed and add the corresponding selects to our own menu file In this case it does not help to enable the required par
28. al locations do not provide a patch series for the specific package PTXdist falls back to the patches directory at its main installation location This search order can be used to use specific patch series for specific cases e platfom specific e project specific e common case e bug fixing The bug fixing case is used in accordance to a replacement of a rule file If this was done due to a backport and the more recent PTXdist revision does not only exchange the rule file but also the patch series this mechanism ensures that both relevant parts can be updated in the project 4 1 3 Runtime Configuration Many packages are using runtime configuration files along with their executables and libraries PTXdist provides default configuration files for the most common cases These files can be found in the generic etc directory and they are using the same names as the ones at runtime and their install directory on the target side will also be etc But some of these default configuration files are empty due to the absence of a common case The project must provide replacements of these files with a more useful content in every case where the empty default one does not meet the target s requirements PTXdist first searches the project local projectroot etc directory for a specific configuration file and falls back to use the default one if none exists locally A popular example is the configuration file etc fstab The default one comi
29. all the software on the development system This chapter provides information about how to install and configure PTXdist on the development host 2 2 1 Main Parts of PTXdist The most important software component which is necessary to build an OSELAS BSP board support package is the ptxdist tool So before starting any work we ll have to install PTXdist on the development host PTXdist consists of the following parts The ptxdist Program ptxdist is installed on the development host during the installation process ptxdist is called to trigger any action like building a software packet cleaning up the tree etc Usually the ptxdist program is used in a workspace directory which contains all project relevant files A Configuration System The config system is used to customize a configuration which contains information about which packages have to be built and which options are selected Patches Due to the fact that some upstream packages are not bug free especially with regard to cross compi lation it is often necessary to patch the original software PTXdist contains a mechanism to automatically apply patches to packages The patches are bundled into a separate archive Nevertheless they are nec essary to build a working system 8 f Pengutronix 2 Getting a working Environment Package Descriptions For each software component there is a recipe file specifying which actions have to be done to prepare and compile th
30. arket at the beginning of the 1990ies people started to develop an alternative to the large commercial operating systems Linux Linux did never start with a ready to use solution people had a problem searched for a solution but didn t find one Then they started to develop one themselves often several people did this 6 f Pengutronix 1 Welcome to the Embedded World in parallel and in a huge community based evolution mechanism the best solutions found their way into the Linux kernel which over the time formed one of the most reliable and performant kernels available today This develop and evolute mechanism has shown its effectiveness over and over again in the server and desktop market of today 1 2 From Server to Embedded The fact that for most technical problems that might occur it may be possible to find somebody on the internet who has already worked on the same or another very similar problem was one of the major forces behind the success story of Embedded Linux Studies have shown that more than 70 ofthe embedded developers are not satisfied with a black box operating system they want to adapt it to their needs to their special hardware situation which most times is Just Different than anything available Embedded projects are even more variegated than desktop or server projects due to the fact that there exist so many different embedded processors with lots of peripherals out there Linux has evolved from an i386 on
31. art building our first userland we need a cross toolchain On Linux toolchains are no monolithic beasts Most parts of what we need to cross compile code for the embedded target comes from the GNU Compiler Collection gcc The gcc packet includes the compiler frontend gcc plus several backend tools cc1 g Id etc which actually perform the different stages of the compile process gcc does not contain the assembler so we also need the GNU Binutils package which provides lowlevel stuff Cross compilers and tools are usually named like the corresponding host tool but with a prefix the GNU target For example the cross compilers for ARM and powerpc may look like e arm softfloat linux gnu gcc e powerpc unknown 1inux gnu gcc With these compiler frontends we can convert e g a C program into binary code for specific machines So for example if a C program is to be compiled natively it works like this gcc test c o test To build the same binary for the ARM architecture we have to use the cross compiler instead of the native one arm softfloat linux gnu gcc test c o test Also part of what we consider to be the toolchain is the runtime library libc dynamic linker All programs running on the embedded system are linked against the libc which also offers the interface from user space functions to the kernel The compiler and libc are very tightly coupled components the second stage compiler which is used to build normal us
32. art the menu to configure the platform s kernel As a project can support more than one platform this will configure the currently selected platform The shortform for this action is kernelconfig menuconfig u boot v2 barebox This action starts the configure menu for the selected bootloader It depends on the platform settings which bootloader is enabled and to be used as an argument to the menuconfig action pa rameter Due to a project can support more than one platform this will configure the bootloader of the currently selected platform The shortform for this action is platformconfig 5 4 2 Build Actions go This action will build all enabled packages in the current project configurations platform and userland It will also rebuild reconfigured packages if any or build additional packages if they where enabled meanwhile If enables this step also builds the kernel and bootloader image 51 f Pengutronix 5 PTXdist Reference images Most of the time this is the last step to get the required files and or images for the target It creates filesystems or device images to be used in conjunction with the target s filesystem media The result can be found in the images directory of the project or the platform directory 5 4 3 Clean Actions clean The clean action will remove all generated files while the last go run All build packages and root filesystem directories Only the selected configuration files are left untouched Thi
33. ation files projectroot Contains files and configuration for the target s runtime A running GNU Linux system uses many text files for runtime configuration Most of the time the generic files from the PTXdist installation will fit the needs But if not customized files are located in this directory rules If something special is required to build the BSP for the target it is intended for then this directory contains these additional rules patches If some special patches are required to build the BSP for this target then this directory contains these patches on a per package basis tests Contains test scripts for automated target setup Next we will build the OSELAS BSP Pengutronix Generic 2010 01 0 to show some of PTXdist s main features 3 2 2 Selecting a Userland Configuration First of all we have to select a userland configuration This step defines what kind of applications will be built for the hardware platform The OSELAS BSP Pengutronix Generic 2010 01 0 comes with a predefined configuration we select in the following step ptxdist select configs ptxconfig info selected ptxconfig configs ptxconfig 3 2 3 Selecting a Hardware Platform Before we can build this BSP we need to select one of the possible platforms to build for In this case we want to build for the Versatilepb ptxdist platform configs arm qemu 3 platformconfig info selected platformconfig configs arm qemu 3 platformconfig Note Ifyou
34. build an IPKG archive and the root filesystem For each single package one so called rule file exists describing the steps to be done in each stage shown above refer section 5 3 for further details Due to the get stage PTXdist needs a working internet connection to download an archive currently not existing on the development host But there are ways to prevent PTXdist from doing so refer to section 2 2 4 3 2 First steps with PTXdist PTXdist works as a console command tool Everything we want PTXdist to do we have to enter as a command But it s always the same base command PPengutronix 17 Pengutronix 3 PTXdist User s Manual bin foo a T B gt TATAE z L foo tgz foo ipk le R C m N E sbinbar O bar tgz bar ipk TA er Waa TTTS C usr bin baz E baz tgz extract ES a A a E ve al PTXdist Figure 3 2 The build process ptxdist lt parameter gt To run different functions this command must be extended by parameters to define the function we want to run If we are unsure what parameter must be given to obtain a special function we run it with the parameter help ptxdist help This will output all possible parameters ans subcommands and their meaning As the list we see is very long let s explain the major parameters usually needed for daily usage menu This starts a dialog based frontend for those who do not like typing commands It will gain us access to the most com
35. build target foo 1 1 0 test z usr bin bin mkdir p home jbe my_new_prj build target foo 1 1 0 usr bin usr bin install c foo home jbe my_new_prj build target foo 1 1 0 usr bin foo make 3 Leaving directory home jbe my_new_prj build target foo 1 1 0 make 2 Leaving directory home jbe my_new_prj build target foo 1 1 0 make 1 Leaving directory home jbe my_new_prj build target foo 1 1 0 finished target foo install finished target foo install post This install stage does not install anything to the target root filesystem It is mostly intended to install libraries that other programs should link against later on The last stage targetinstall is the one that defines the package s components to be forwarded to the target s root filesystem Due to the absence of a generic way this is the task of the developer So at this point of time we must run our favourite editor and modify our new rule file rules foo make The skeleton for the targetinstall stage looks like this STATEDIR foo targetinstall call targetinfo call install_init foo call install_fixup foo PACKAGE foo call install_fixup foo PRIORITY optional call install_fixup foo VERSION FOO_VERSION call install_fixup foo SECTION base call install_fixup foo AUTHOR My Name lt me my org com gt call install_fixup foo DEPENDS call install_fixup foo DESCRIPT
36. d into logical units The main building blocks in the userland configuration menu are e Host Options Some parts of the project are build host relevant only For example PTXdist can build the DDD debugger to debug applications running on the target e Root Filesystem Settings to arrange target s root filesystem and to select the main C runtime library e Applications Everything we like to run on your target The main building blocks in the platform configuration menu are e Architecture Basic settings like the main and sub architecture the target system uses the toolchain to be used to build everything and some other architecture dependent settings e Linux kernel Which kernel revision and kernel configuration should be used e Bootloader Which bootloader if any should be built in the project e The kind of image to populate a root filesystem into the target system frengutrono 24 Pengutronix 3 PTXdist User s Manual The main building blocks in the board setup configuration menu are e Network Network settings for the target e Host Host setup to be able to reach the target system At this point it could be useful to walk to the whole menus and their submenus to get an idea about the amount of features and applications PTXdist currently supports 3 3 2 Adapting Platform Settings Some parts of the OSELAS BSP Pengutronix Generic 2010 01 0 project are platform specific in contrast to the userland configuration that could be s
37. d verifiability 3 1 1 PTXdist s perception of the world PTXdist works project centric A PTXdist project contains all information and files to populate any kind of target system with all required software components e Specific configuration for Bootloader Kernel Userland root filesystem e Adapted files or generic ones for runtime configuration e Patches for all kind of components to fix bugs or improve features 16 f Pengutronix 3 PTXdist User s Manual Some of these information or files are coming from the PTXdist base installation patches for example but also can be part of the project itself By this way PTXdist can be adapted to any kind of requirement Most users are fine with the information and files the PTXdist base installation provides Development of PTXdist is done in a way to find default settings most user can work with But advanced users can still adaptto their special needs As stated above a PTXdist project consists of all required parts some of these parts are separated by design PTXdist separates a platform configuration from userland configuration root filesystem So platforms can share a common userland configuration but use a specific kernel configuration in their own platform configuration Collecting various platforms into one single project should help to maintain such projects But some platforms do need special userland think about graphic non graphic platforms To be able t
38. ded when he wanted to start a new product was a good toolchain consisting of e acompiler e maybe an assembler e probably an EPROM burning device and things could start After some more or less short time every register of the CPU was known a variety of library routines had been developed and our brave developer was able to do his project with the more and more well known system The controllers had legacy interfaces like RS232 i2c or SPI which connected them to the outside world and the main difference between the controllers available on the market was the number of GPIO pins UARTS and memory ressources Things have changed Hardware manufacturers have weakened the border between deeply embedded micro controllers headless devices with just a few pins and very limited computing power and full blown micropro cessors System structures became much more complicated where our good old controllers have had just some interrupts with some small interrupt service routines we today need complicated generic interrupt infrastruc tures suitable for generic software frameworks Where we ve had some linearly mapped flash ROM and some data RAM we today have multi stage pipeline architectures memory management units virtual address spaces on chip memory caches and other complicated units which is not exactly what the embedded system developer wants program every other day Entering embedded operating systems Although there are still some proce
39. e config FOO_BAR bool prompt build bar endif PTXdist now builds the zlib first and our new package thereafter Managing External Compile Time Dependencies on Demand It is good practice to add only those dependecies that are really required for the current configuration of the package If the package provides the features foo and bar and its configure provides switches to enable disable them independently we can also add dependencies on demand Let s assume feature foo needs the compression library libz and bar needs the XML2 library libxml2 These libraries are only required at runtime if the correspondig feature is enabled To add these dependencies on demand the menu file looks like SECTION fixme config FOO tristate select ZLIB if FOO_FOO select LIBXML2 if FOO_BAR prompt foo help FIXME if FOO config FOO_DEBUG bool prompt add debug noise config FOO_FOO bool prompt build foo config FOO_BAR f Pengutronix 2 4 PTXdist Developer s Manual bool prompt build bar endif Note Do not add these select statements to the correspondig menu entry They must belong to the main menu entry of the package to ensure that the calculation of the dependencies between the packages is done in a correct manner Managing External Runtime Dependencies Some packages are building all of their components and also installing them into the target s sysroot But only their targetinstall st
40. e src home jbe my_new_prj build target foo 1 1 0 foo dst usr bin foo owner 0 group 0 permissions 0755 xpkg_finish xpkg_finish collecting license unknown done creating ipkg package done finished target foo targetinstall finished target foo targetinstall post After this command the target s root filesystem contains a file called usr bin foo owned by root its group is also root and everyone has execution permissions but only the user root has write permissions One last task of this port is still open A reasonable location for the new menu entry in PTXdist s menu hierarchy PTXdist arranges its menus on the meaning of each package Is ita network related tool Ora scripting language Ora graphical application Each of these global meanings have their own submenu where we can add our new entry to We just have to edit the head of our new menu file to add it to a specific global menu If our new package is a network related tool the head of the menu file should look like SECTION networking We can grep through the other menu files from the PTXdist main installation rules directory to get an idea what section names are available rules find name in xargs grep Ht SECTION acpid in SECTION shell_and_console alsa lib in SECTION system_libraries alsa utils in SECTION multimedia_sound apache2 in SECTION networking apache2_mod_python in SECTION networking
41. e yes checking for a thread safe mkdir p bin mkdir p checking for gawk gawk checking whether make sets MAKE yes checking for i1586 unknown linux gnu strip 1586 unknown linux gnu strip checking for 1586 unknown 1inux gnu gcc 1586 unknown linux gnu gcc checking for C compiler default output file name a out configure creating config status config status creating Makefile config status creating ppa_protocol Makefile config status creating config h 32 f Pengutronix 4 PTXdist Developer s Manual config status executing depfiles commands finished target foo prepare At this stage things can fail e The configure script is not cross compile aware e The package depends on external components libraries for example Ifthe configure script is not cross compile aware we are out of luck We must patch the source archive in this case to make it work Refer to section 4 2 6 on how to use PTXdist s features to simplify this task If the package depends on external components these components might be already part of PTXdist In this case we just have to add this dependency into the menu file and we are done But if PTXdist cannot fulfill this dependency we also must add it as a separate package first Ifthe prepare stage has finished successfully the next step is to compile the package ptxdist compile foo make 1 Entering directory home jbe my_new_prj build target foo 1 1 0 make all recu
42. e bash fakeroot command not found will occur and the build stops tar xf OSELAS Toolchain 1 99 3 6 tar bz2 cd OSELAS Toolchain 1 99 3 6 ptxdist select ptxconfigs arm v4t linux gnueabi_gcc 4 3 2_glibc 2 8_binutils 2 18_kernel 2 6 27 sanitized ptxconfig ptxdist go At this stage we have to go to our boss and tell him that it s probably time to go home for the day Even on reasonably fast machines the time to build an OSELAS Toolchain is something like around 30 minutes up to a few hours Measured times on different machines e Single Pentium 2 5 GHz 2 GiB RAM about 2 hours e Turion ML 34 2 GiB RAM about 1 hour 30 minutes Dual Athlon 2 1 GHz 2 GiB RAM about 1 hour 20 minutes Dual Quad Core Pentium 1 8 GHz 8 GiB RAM about 25 minutes Another possibility is to read the next chapters of this manual to find out how to start a new project When the OSELAS Toolchain project build is finished PTXdist is ready for prime time and we can continue with our first project 2 3 4 Protecting the Toolchain All toolchain components are built with regular user permissions In order to avoid accidential changes in the toolchain the files should be set to read only permissions after the installation has finished successfully It is also possible to set the file ownership to root This is an important step for reliability so it is highly recommended 2 3 5 Building Additional Toolchains The OSELAS Toolchain 1 99 3 6 bundle comes wit
43. e hints on how to discover these dependencies f Pengutronix 2 6 Various Aspects of Daily Work 6 2 1 Dependencies on Shared Libraries Getting the missed shared library for example at runtime is something easily done The dynamic linker prints the missing library to the console To check at build time if all other dependencies are present is easy too The architecture specific readelf tool can help us here It comes with the OSELAS Toolchain and is called via arm v4t linux gnueabi readelf this example uses the one coming with the arm vat linux gnueabi toolchain To test the foo binary from our new package FOO we simply run arm v4t linux gnueabi readelf d platform versatilepb root usr bin foo grep NEEDED 0x00000001 NEEDED Shared library libm so 6 0x00000001 NEEDED Shared library libz so 1 0x00000001 NEEDED Shared library libc so 6 We now can check if all of the listed libraries are present in the root filesystem This works for shared libraries too It is also a way to check if various configurations of our package are working as expected e g disabling a feature should also remove the required dependency of this feature 6 2 2 Dependencies on other Resources Sometimes a binary fails to run due to missing files directories or device nodes Often the error message if any that the binary creates in this case is ambiguous Here the strace tool can help us namely to observe the binary at runtime st
44. e software Additionally packages contain their configuration sniplet for the config system Toolchains PTXdist does not come with a pre built binary toolchain Nevertheless PTXdist itself is able to build toolchains which are provided by the OSELAS Toolchain project More in deep information about the OSELAS Toolchain project can be found here http www pengutronix de oselas toolchain index_en html Board Support Package This is an optional component mostly shipped aside with a piece of hardware There are various BSP available some are generic some are intended for a specific hardware 2 2 2 Extracting the Sources To install PTXdist at least two archives have to be extracted ptxdist 2010 04 0 tgz The PTXdist software itself ptxdist 2010 04 0 patches tgz All patches against upstream software packets known as the patch reposi tory ptxdist 2010 04 0 projects tgz Generic projects optional can be used as a starting point for self built projects The PTXdist and patches packets have to be extracted into some temporary directory in order to be built before the installation for example the local directory in the user s home If this directory does not exist we have to create it and change into it cd mkdir local cd local Next steps are to extract the archives tar zxf ptxdist 2010 04 0 tgz tar zxf ptxdist 2010 04 0 patches tgz and if required the generic projects tar zxf ptxdist 2010 0
45. ecessary to have remote shell access to the box either via telnet or if security is an issue by using SSH It is also possible to automate this process by using an intelligent update mechanism The shell is being used to start the necessary commands If the packet was installed the ipkg archive can be removed again 6 6 3 Automatic Packet Download It is also possible to let the embedded system download ipkg packets automatically from a network source with out pushing the packets from the outside In order to do so a valid URL must be written into the etc ipkg conf file In this case one of the wget implementations in PTXdist must be selected either the one in busybox Shell amp Console Tools BusyBox Networking Utilities or the native implementation Networking Tools 6 6 4 The ipkg Command The following sections describe the ipkg features What s Installed on the System To get a list of installed packages use list_installed 60 f Pengutronix 6 Various Aspects of Daily Work ipkg list_installed busy boxe mle leone pala 222 peelliilos AS gdbserver 6 4 clio 26 0 alles 2 5 ipkg 0 99 163 ixp firmware 1 kernel modules 2 6 18 isa 2 027 MEP memedit 0 7 ne urses o5 perl pureftpd 1 0 21 readline 5 0 FOO ENS MOTOS strace 4 5 14 20061101 udev 088 AS Successfully terminated Content of a Package To see what files are in an installed package u
46. enter the base path to the kernel source tree into this menu entry omit the kernel source tree directory name itself The kernel source tree directory to be used in this base path will be setup on a per project base So it will be possible to place more than one kernel source tree in the base path 6 1 3 Configuring the PTXdist Project Now we can setup this kernel source tree to be used in our project PTXdist will handle it in the same way as a kernel part of the project Due to this we must setup Some kind of kernel version e Kernel configuration e Image type used on our target architecture e If we want to build modules Patches to be used or not f Pengutronix dl 6 Various Aspects of Daily Work Let s setup these topics Assumption is here the directory myprj contains a valid PTXdist project We just add the kernel component to it jbe octopus cd myprj jbe octopus myprj ptxdist platformconfig We must enable the Linux kernel entry first to enable kernel building as part of the project After enabling this entry we must enter this entry and e Setting up the kernel version with the name of kernel source tree directory In our case shown above it would be linux 2 6 e Selecting the correct image type in the entry Image Type e Configuring the kernel within the menu entry patching amp configuration Ifno patches should be used on top of the selected kernel source tree we keep the patch series file
47. entry empty As GIT should help us to create these patches for deployment it should be kept empty on default in this first step Select a name for the kernel configuration file and enter it into the kernel config file entry e As we want to use an existing kernel source tree we also must enable the Local kernel tree menu entry Now we can leave the menu and store the new setup The only still missing component is a valid kernel config file now We can use one of the default config files the Linux kernel supports as a starting point To do so we copy one to the location where PTXdist expects it in the current project In a multi platform project this location is the platform directory usally in configs lt platform directory gt We must store the file with a name selected in the platform setup menu kernel config file 6 1 4 Work Flow Now its up to ourself working on the GIT based kernel source tree and using PTXdist to include the kernel into the root filesystem To configure the kernel source tree we simply run jbe octopus myprj ptxdist kernelconfig To build the kernel jbe octopus myprj ptxdist targetinstall kernel To rebuild the kernel jbe octopus myprj ptxdist drop kernel targetinstall jbe octopus myprj ptxdist targetinstall kernel 6 2 Discovering Runtime Dependencies Often it happens that an application on the target fails to run because one of its dependencies is not fulfilled This section should give som
48. er space code is being built against the libc itself For example ifthe target does not contain a hardware floating point unit but the toolchain generates floating point code it will fail This is also the case when the toolchain builds code for i686 CPUs whereas the target is i586 So in order to make things working consistently it is necessary that the runtime libc is identical with the libc the compiler was built against PTXdist doesn t contain a pre built binary toolchain Remember that it s not a distribution but a development tool But it can be used to build a toolchain for our target Building the toolchain usually has only to be done once It may be a good idea to do that over night because it may take several hours depending on the target architecture and development host power 2 3 1 Using Existing Toolchains If a toolchain is already installed which is known to be working the toolchain building step with PTXdist may be omitted 12 f Pengutronix 2 Getting a working Environment The OSELAS BoardSupport Packages shipped for PTXdist have been tested with the OSE LAS Toolchains built with the same PTXdist version So if an external toolchain is being used which isn t known to be stable a target may fail Note that not all compiler versions and combi nations work properly in a cross environment Every OSELAS BoardSupport Package checks for its OSELAS Toolchain it s tested against so using a different t
49. erence If the package s rule file defines a package _CMAKE variable FOO_CMAKE for our foo example PTXdist treats this package as a cmake based package and runs STATEDIR package prepare call targetinfo call clean package _DIR config cache cd package _DIR amp amp package _PATH package _ENV cmake package _CMAKE call touch compile Stage Default Rule If the compile stage is omitted PTXdist runs instead STATEDIR package compile call targetinfo cd package _DIR 88 A package _PATH package _MAKE_ENV MAKE package _MAKE_OPT package _MAKE_PAR call touch Note package _MAKE_PAR can be defined to YES or NO to control if the package can be built in parallel install Stage Default Rule If the install stage is omitted PTXdist runs instead STATEDIR package install call targetinfo cd package _DIR amp amp package _PATH package _MAKE_ENV MAKE package _INSTALL_OPT call touch Note package _INSTALL_OPT is always defined to install if not otherwise specified This value can be replaced by a package s rule file definition targetinstall Stage Default Rule There is no default rule for a package s targetinstall state PTXdist has no idea what is required on the target at runtime This stage is up to the developer only Refer to section 5 2 for further info on how to select files to be included in the targe
50. file was arbitrarily selected We can name these files with any name we like 62 f Pengutronix 6 Various Aspects of Daily Work 6 8 1 Creating the Rule and Menu File To do the installation we need the additional rule file rules adding_file make and rules adding_file in men tioned above These are more or less large files so we should use PTXdist s template mechanism to create these files instead of writing our own The following command must run in a PTXdist project directory ptxdist newpacket simple ptxdist creating a new simple package ptxdist enter packet name adding file ptxdist enter version number ptxdist enter packet author Juergen Beisert Only the packet name is required as it also defines the file name for the menu and rule file The other two ques tions we can answer or left them empty This command creates the new menu and rule file in the project local rule directory 6 8 2 Adapting the Generic Rule File As this rule file is only a generic one we now must add the instructions to do the real job We open rules adding_file make with our favoured editor and navigate to line 56 and or 101 It depends on the use of our files where they should get installed If the files are used at the host side to build other packets the install stage in line 56 and below is the right one Follow the TODO text in the install stage to do the modification If the files are required by the ta
51. files do not need any processing they are ready to use and only must present in the build process or at runtime HTML files for example Refer the section 6 8 for further details on how to use it src make prog This kind of package is built for the target Its intended for development as it does not handle a released archive but a plain source project instead Creating such a package will also create a simple makefile based template project the developen can use as a starting point for development src cmake prog This kind of package is built for the target Its intended for developments based on the cmake buildsystem If the developen is going to develop a QT based application this rule is prepared to compile sources in accordance to the target libraries and their settings Creating such a package will also create a simple template project to be used as a starting point for development font This package is a helper to add X font files to the root filesystem This package does not create an additional IPKG instead it adds the font to the existing font IPGK This includes the generation of the directory index files required by the Xorg framework to recognize the font file src linux driver This kind of package builds an out of tree kernel driver It also creates a driver template to give the developer an easy point to start src stellaris This package is intended for development of firmware for standalone Cortex M3 Stellaris microcontroller
52. gs we must disable everything we do not want If some parts of a package are built on demand only they must also be installed on demand only Besides the prepare stage we also must modify our targetinstall stage Esl call install_copy foo 0 0 0755 FOO_DIR foo usr bin foo ifdef PTXCONF_FOO_BAR call install_copy foo 0 0 0755 FOO_DIR bar usr bin bar endif call install_finish foo call touch Now we can play with our new menu entries and check if they are working as expected ptxdist menuconfig ptxdist targetinstall foo Whenever we change a FOO related menu entry PTXdist should detect it and re build the package when a new build is started Managing External Compile Time Dependencies While running the prepare stage it could happen that it fails due to a missing external dependency For example al checking whether zlib exists failed 38 f Pengutronix 4 PTXdist Developer s Manual In this example our new package depends on the compression library zlib PTXdist comes with a target zlib All we need to do in this case is to declare that our new package foo depends on zlib This kind of dependencies is managed in the menu file of our new package by simply adding the select ZLIB line Afterthis addition our menu file looks like SECTION fixme config FOO tristate select ZLIB prompt foo help FIXME if FOO config FOO_DEBUG bool prompt add debug nois
53. h various predefined toolchains Refer the ptxconfigs folder for other definitions To build additional toolchains we only have to clean our current toolchain project removing the current selected_ptxconfig link and creating a new one frengutrono 14 Pengutronix 2 Getting a working Environment ptxdist clean rm selected_ptxconfig ptxdist select ptxconfigs any_other_toolchain_def ptxconfig ptxdist go All toolchains will be installed side by side architecture dependent into directory opt OSELAS Toolchain 1 99 3 architecture_part Different toolchains for the same architecture will be installed side by side version dependent into directory opt OSELAS Toolchain 1 99 3 architecture_part version_part f Pengutronix 15 3 PTXdist User s Manual This chapter should give any newbie the information he she needs to be able to handle any embedded Linux projects based on PTXdist Also the advanced user may find new valueable information 3 1 How does it work PTXdist supports various aspects of the daily work to develop deploy and maintain an embedded Linux based project Project Handling Quality Management Development Deployment Toolchains Libraries Automated Automated Debugging Tools Testing Production IDE Eclipse Figure 3 1 Objectives in a project The most important part is the development For this project phase PTXdist provides features to ensure repro ducibility an
54. hared between platforms We now want to change the used Linux kernel of our current arm qemu 3 platform It comes with a default linux 2 6 31 and we want to change it to a more recent linux 2 6 32 To do so we run ptxdist menuconfig platform In this Kconfig dialogue we navigate to the entry x Linux kernel gt 2 6 31 kernel version and replace the 2 6 31 value by the 2 6 32 value Now we leave the menu and save the new settings A Linux kernel needs a configuration for being built correctly The OSELAS BSP Pengutronix Generic 2010 01 0 project comes with a prepared configuration in the file configs arm qemu 3 kernelconfig for the 2 6 31 kernel It is always a good idea to start with a known to work kernel configuration So in this case we continue using the configs arm qgemu 3 kernelconfig file even for our new 2 6 32 kernel But due to the update to a more recent kernel revision we should check in the next step if the new kernel supports more or different features for our platform 3 3 3 Adapting Linux Kernel Settings In this section we want to show how to change some Linux kernel settings of our OSELAS BSP Pengutronix Generic 2010 01 0project First of all we run ptxdist menuconfig kernel This command will start the kernel s Kconfig For this example we want to enable USB host support in the kernel To do so we navigate to Device Drivers gt ARUSBASUPpOREA gt lt gt Support for Host side
55. have installed the OSELAS Toolchain at its default location PTXdist should already have detected the proper toolchain while selecting the platform In this case it will output found and using toolchain opt OSELAS Toolchain 1 99 3 arm v4t 1linux gnueabi gcc 4 3 2 glibc 2 8 binutils 2 18 kernel 2 6 27 sanitized bin Ifitfails you can continue to select the toolchain manually as mentioned in the next section Ifthis autodetection was successful we can omit the steps of the section and continue to build the BSP 20 f Pengutronix 3 PTXdist User s Manual 3 2 4 Selecting a Toolchain If not automatically detected the last step in selecting various configurations is to select the toolchain to be used to build everything for the target ptxdist toolchain opt OSELAS Toolchain 1 99 3 arm v4t linux gnueabi gcc 4 3 2 glibc 2 8 binutils 2 18 kernel 2 6 27 sanitized bin 3 2 5 Building the Root Filesystem Content Now everything is prepared for PTXdist to compile the BSP Starting the engines is simply done with ptxdist go PTXdist does now automatically find out from the selected_ptxconfig and selected_platformconfig files which packages belong to the project and starts compiling their targetinstall stages that one that actually puts the com piled binaries into the root filesystem While doing this PTXdist finds out about all the dependencies between the packages and builds them in correct order 3 2 6 What we Go
56. he difference to root is all programs and libraries in this directory still have their debug information present This directory is intended to be used as system root for a debugger To be used by the debugger you should setup your debugger with set solib absolute prefix lt path to workspace gt root debug 21 f Pengutronix 3 PTXdist User s Manual platform versatilepb state Building every package is divided onto stages And stages of one package can de pend on stages of other packages In order to handle this correctly this directory contains timestamp files about finished stages This are the generated files platform versatilepb logfile Every run of PTXdist will add its output to this file If something fails this file can help to find the cause 3 2 7 Creating a Root Filesystem Image After we have built the root filesystem content we can make an image which can be flashed to the target system or copied on some kind of disk media To do so we just run ptxdist images PTXdist now extracts the content of priorly created ipk packages to a temporary directory and generates an image out of it PTXdist supports following image types e hd img contains bootloader kernel and root files in an ext2 partition Mostly used for X86 target systems e root jffs2 root files inside a jffs2 filesystem e uRamdisk a u boot loadable Ramdisk e initrd gz a traditional initrd RAM disk to be used as initrdramfs by the kernel e
57. his chapter will show all or most of the details of how PTXdist works e where are the files stored that PTXdist uses when building packages e how patching works e where is PTXdist fetching a package s runtime configuration files from e how to control a package s build stages e how to add new packages 4 1 PTXdist s directory hierarchy Note Referenced directories are meant relative to the PTXdist main installation location if not otherwise stated If not configured differently this main path is usr local lib ptxdist 2010 04 0 4 1 1 Rule Files When building a single package PTXdist needs the information on how to handle the package i e on how to get it from the source up to what the target needs at runtime This information is provided by a rule file per package PTXdist collects all rule files in its rules directory Whenever PTXdist builds something all these rule files are scanned at once These rule files are global rule files valid for all projects PTXdist uses a mechanism to be able to add or replace specific rule files on a per project base If a rules directory exists in the current project its content is scanned too These project local rule files are used in addition to the global rule files or if they are using the same name as a global rule file replacing the global rule file The replacing mechanism can be used to extend or adapt packages for specific project requirements Or it can be used for bug fixing by b
58. ific package we can copy the global patch series to our local project directory Now we have the permissions to add more patches or modify the existing ones Also quilt is our friend here to manage the patch series If we think that our new patches are valuable also for others or they fix an error it could be a good idea to send these patches to PTXdist mainline 4 2 6 Modifying Autotoolized Packages Autotoolized packages are very picky when automatically generated files get patched The patch order is very important in this case and sometimes it even fails and nowbody knows why To improve a package s autotools based build system PTXdist comes with its own project local autotools to regenerate the autotools template files instead of patching them With this feature only the template files must be patched the required configure script and the Makefile in files are regenerated in the final stages of the prepare step 42 f Pengutronix 4 PTXdist Developer s Manual This feature works like the regular patching mechanism The only difference is the additional autogen sh file in the patch directory If it exists and has execution permissions it will be called after the package was patched while the extract stage is running Its content depends on developer needs for the most simple case the content can be bin bash aclocal ACLOCAL_FLAGS libtoolize force copy autoreconf force NS ELN warnings cro
59. ing the commands step next stepi nexti until and so on Note It might be impossible for GDB to find debug symbols for components like the main C runtime library In this case they where stripped while building the toolchain There is a switch in the OSELAS Toolchain menu to keep the debug symbols also for the C runtime library But be warned This will enlarge the OSELAS Toolchain installation on your harddisk When the toolchain was built with the debug symbols kept it will be also possible for GDB to debug C library functions our application calls so it might worth the disk space 6 4 Migration between Minor Releases 6 4 1 Simple Upgrade To migrate an existing project from within one minor release of the second main release to the next one e g 2 0 0 to 2 0 x we do the following steps my_bsp ptxdist force migrate f Pengutronix ci 6 Various Aspects of Daily Work 6 5 Migration between Major Releases 6 5 1 Basic Conversion To migrate an existing PTXdist 1 project to the new PTXdist 2 the following steps are to be done To convert a PTXdist 1 project into a PTXdist 2 project simply copy your old ptxconfig file into the files selected_ptxconfig and selected_platform After that run my_bsp ptxdist force platformconfig to configure the platform specific part and check if everything is set up correctly and save these settings All in the platform unused symbols will now be discarded and the remaining req
60. it for a GDB connection to run the application In the second console we start GDB with the correct architecture support This GDB comes with the same OS ELAS Toolchain that was also used to build the project In our example we are using the arm v4t linux gnueabi toolchain for our qemu arm CPU arm v4t linux gnueabi gdbtui root debug usr bin myapp This will run a curses based GDB Not so easy to handle we must enter all the commands and cannot click with a mouse but very fast to take a quick look at our application At first we tell GDB where to look for debug symbols The correct directory here is platform versatilepb root debug gdb set solib absolute prefix platform versatilepb root debug Next we connect this GDB to the waiting QEMU gdb target remote localhost 1234 Remote debugging using localhost 1234 New Thread 1 0x40096a7c in _start from root debug lib 1d so 1 As our application is already started we can t use the GDB command start to run it until it reaches main We set a breakpoint instead at main and continue the application gdb break main Breakpoint 1 at 0x100024e8 file myapp c line 644 gdb continue Continuing Breakpoint 1 main argc 1 argv 0x4007f03c at myapp c 644 The top part of the running gdbtui console will always show us the current source line Due to the root debug directory usage all debug information for GDB is available Now we can step through our application by us
61. later flashed into the onboard flash of an embedded system it takes the information from the ipkg packets as the source in order to make sure that the image is consistent to what the packages contain Internally PTXdist always uses ipkg packets to store it s target data However the ipkg functionality is not always exposed to the target itself So in order to use packets navigate to Disk and File Utilities and enable ipkg In the ipkg sub menu make sure that the install etc ipkg conf switch is active This config file is necessary to make ipkg work at runtime system The ipkg tool can only be used in images created by ptxdist images It s not fully working within the platform versatilepb root subdirectory used as NFS root filesystem 6 6 2 Packet Installation A common use case for ipkg packets is to push new software to an already deployed target There must be a communication channel to transfer the packet itself to the embedded system i e by using FTP or a secure connection via SFTP or SSH so it has to be made sure that such a service is installed and configured on the target It is necessary that enough free space is available in order to store the packet itself A good rule of thumb is to have twice the size of the installed package while the packet is being installed the archive as well as it s contents must fit into the system storage This may be a problem on space constrained systems If the packet was transferred it is n
62. ly operating system to a kernel running on nearly every modern 32 bit processor available today x86 PowerPC ARM MIPS m68k cris Super H etc The kernel supplies a hardware abstrac tion layer which lets our brave embedded developer once again concentrate on his very special problem not on handling negligibilities like memory management But Linux is only half of the story Besides the kernel a Linux based embedded system consists of a userland a filesystem containing all the small tools which form a small Unix system Only the combination of the kernel and a Userland let s the developer run normal processes on his x86 development machine as well as on his embedded target 1 3 Linux Embedded Linux Whereas the mainstream developers were always able to use normal Linux distributions like SuSE RedHat Man drake or Debian as a base for their applications things are different for embedded systems Due to the restricted ressources these systems normally have distributions have to be small and should only contain those things that are needed for the application Today s mainstream distributions cannot be installed in less than 100 MiB without major loss of functionality Even Debian probably today the most customizable mainstream distribution cannot be shrunk below this mark without for example losing the packet management which is an essential feature of using a distribution at all Additionally source code for industrial systems
63. manually one after another ptxdist get foo 31 f Pengutronix 4 PTXdist Developer s Manual 2009 12 21 10 54 45 http www foo com download src foo 1 1 0 tar gz Length 291190 284K application x gzip Saving to global_src foo 1 1 0 tar gz XXXXOGncZA IQ A 33S SS SSS SS SSS SSS SSeS SSS 291 x 190 170K s in 1 75s 2009 12 21 10 54 48 170 KB s global_src foo 1 1 0 tar gz saved 291190 291190 This command should start to download the source archive If it fails we should check our network connection and if the URL in use is correct ptxdist extract foo extract archive global_src foo 1 1 0 tar gz extract dest home jbe my_new_prj build target PATCHIN packet foo 1 1 0 PATCHIN dir home jbe my_new_prj build target foo 1 1 0 PATCHIN no patches for foo 1 1 0 available Fixing up home jbe my_new_prj build target foo 1 1 0 configure finished target foo extract In this example we expect an autotoolized source package E g to prepare the build the archive comes with a configure script This is the default case for PTXdist So there is no need to modify the rule file and we can simply run ptxdist prepare foo checking build system type 1686 host linux gnu checking host system type 1586 unknown linux gnu checking whether to enable maintainer specific portions of Makefiles no checking for a BSD compatible install usr bin install c checking whether build environment is san
64. mon parameters to configure and build a PTXdist project menuconfig Starts the Kconfig based project configurator for the current selected userland configuration This menu will give us access to various userland components that the root filesystem of our target should consist of platformconfig Starts the Kconfig based platform configurator This menu lets us set up all target specific set tings Major parts are e Toolchain architecture and revision e boot loader e root filesystem image type e Linux kernel revision Note A PTXdist project can consist of more than one platform configuration at the same time kernelconfig Runs the standard Linux kernel Kconfig to configure the kernel for the current selected platform To run this feature the kernel must be already set up for this platform 18 f Pengutronix 3 PTXdist User s Manual menuconfig collection If multiple platforms are sharing one userland configuration collections can define a subset of all selected packages for specific platforms This is an advanced feature rarely used toolchain Sets upthe path to the toolchain used to compile the current selected platform Without an additional parameter PTXdist tries to guess the toolchain from platform settings To be successful PTXdist depends on the OSELAS Toolchains installed to the opt directory If PTXdist wasn t able to autodetect the toolchain an additional parameter can be given to provide the path to the compiler
65. ng with PTXdist works for the most common cases But if our project requires a special setup we can just copy the default one to the local projectroot etc fstab modify it and we are done The next time PTXdist builds the root filesystem it will use the local fstab instead of the global default one 4 2 Adding new Packages PTXdist provides a huge amount of applications sufficient for the most embedded use cases But there is still need for some fancy new packages This section describes the steps and the background on how to intergrate new packages into the project At first a summary about possible application types which PTXdist can handle PPengutronix 29 Pengutronix 4 PTXdist Developer s Manual 4 2 mb host type This kind of package is builtto run on the build host Most ofthe time such a package is needed if another target relevant package needs to generate some data For example the glib package depends on its own to create some data But if it is compiled for the target it can t do so That s why a host glib package is required to provide these utilities runnable on the build host It sounds strange to build a host package even if on the build host such utilities are already installed But this way ensures that there are no dependencies regarding the build host system target type This kind of package is built for the target cross type This kind of package is built for the build host but creates architecture s
66. nly works if the package uses the default install stage Only in this case an additional folder in platform versatilepb packages will be created for the package and its files For our foo example package this directory is platform versatilepb packages foo 1 1 0 46 f Pengutronix 5 PTXdist Reference The lt destination gt parameter can be e omitted if a directory in target s root filesystem should be created For this case the directory to be created is in the lt source gt parameter e an absolute path and filename with its root in target s root filesysem It must start with a slash If also the lt source gt parameter was given the file can be renamed while copying If the lt source gt parameter was given as a minus sign the lt destination gt is also used to locate the source For our foo example package if we give lt destination gt as usr bin foo PTXdist copies the file platform versatilepb packages foo 1 1 0 usr bin foo Due to the complexity of this macro here are some usage examples Create a directory in the root filesystem call install_copy foo 0 0 0755 home user foo Copy a file from the package build directory to the root filesystem call install_copy foo 0 0 0755 FOO_DIR foo usr bin foo Copy a file from the package build directory to the root filesystem and rename it call install_copy foo 0 0 0755 FOO_DIR foo usr bin bar Copy a file from the package install
67. ns about PTXdist Best time to meet somebody there is at European daytime 8 4 Commercial Support You can order immediate support through customer specific mailing lists by telephone or also on site Ask our sales representative for a price quotation for your special requirements Contact us at Pengutronix Peiner Str 6 8 31137 Hildesheim Germany Phone 49 51 21 20 6917 0 Fax 49 51 21 20 69 17 55 55 or by electronic mail sales pengutronix de 66 f Pengutronix
68. ns how to do something special with PTXdist or general questions about Linux in the embedded world try these 8 1 Mailing Lists 8 1 1 About PTXdist in Particular This is an English language public mailing list for questions about PTXdist See http www pengutronix de mailinglists index_en html how to subscribe to this list If you want to search through the mailing list archive visit http www mail archive com and search for the list ptxdist Please note again that this mailing list is just related to the PTXdist as a software For questions regarding your specific BSP see the following items 8 1 2 About Embedded Linux in General This is a German language public mailing list for general questions about Linux in embedded environments See http www pengutronix de mailinglists index_de html how to subscribe to this list Note You can also send mails in English 8 2 News Groups 8 2 1 About Linux in Embedded Environments This is an English newsgroup for general questions about Linux in embedded environments comp os linux embedded 8 2 2 About General Unix Linux Questions This is a German newsgroup for general questions about Unix Linux programming de comp os unix programming PPengutronix 65 Pengutronix 8 Getting help 8 3 Chat IRC About PTXdist in particular irc freenode net 6667 Create a connection to the irc freenode net 6667 server and enter the chatroom ptxdist This is an English room to answer questio
69. nvironments e Package is broken within a specific feature e Package is vulnerable and needs some fixes e oranything else PTXdist handles patching automatically After extracting the archive PTXdist checks for the existence of a patch directory with the same name as the package If our package s name is foo 1 1 0 PTXdist searches for patches in 1 platform configs arm qemu 3 patches foo 1 1 2 project patches foo 1 1 0 3 ptxdist lt ptxdist installation gt path patches foo 1 1 0 The patches from the first location found are used Note Due to this search order a PTXdist project can replace global patches from the PTXdist installation This can be useful if a project sticks to a specific PTXdist revision but fixes from a more recent revision of PTXdist should be used 4 2 5 Creating Patches for a Package PTXdist uses the utilities patch or quilt to work with patches or patch series We recommend quilt as it can manage patch series in a very easy way For this manual we assume quilt is installed on the build host 41 f Pengutronix 4 PTXdist Developer s Manual Creating a Patch Series for a Package To create a patch series for the first time we can run the following steps We are still using our foo 1 1 0 example package here We create a special directory for the patch series in the local project directory mkdir p patches foo 1 1 0 PTXdist expects a series file in the patch directory Otherwise it fails
70. o 3 PTXdist User s Manual Jl Howdoesit Work osa swa A A RRE A E E eee A 3 1 1 PTXdist s perception of the world o e o 34 2 PIXdist s build process oi a a ee ee ee de 3 2 Firststeps with PISE lt s ee ee ee a a we BO 3 2 1 Extracting the Board Support Package ce 3 2 2 Selecting a Userland Configuration 2 3 2 3 Selecting a Hardware Platform o e e o 3 24 SelectingaToolkchat 2 260 082 2GG 4 kopii a k a ae ee amp 3 2 5 Building the Root Filesystem Content o 326 WhetWe GotNoW ci 444 pasig amp a a a a e aE Es 3 2 7 Creating a Root Filesystem Image 1 ooo 3 2 8 Running all Parts in an emulated Environment QEMU 3 3 Adapting the OSELAS BSP Pengutronix Generic 2010 01 0 Project ee ee ee 33 1 Working with Keonfig soe se sa 2528454 BEN ee ew Re ee e 33 2 Adapting Platform Settings lt gt e Pa da ee a ee E 3 3 3 Adapting Linux Kernel Settings aoa aa 3 3 4 Adapting Userland Settings 2 oo 4 PTXdist Developer s Manual 44 PTXdist s directory hierarchy oia we ed a a A ee oS ati Rule files ssa 2444 64404064 iG a bbw oad thd eed eh ana Patel Series o fc ae desea eA a Se a ee we Pte 4 13 Runtime Configuration lt sc osa s sesa goi pala a ee f Pengutronix 28 28 28 28
71. o also collect this requirement into one single project so called collections are supported With this feature a user can configure a full featured main userland reduced via a collection by some components for a specific platform where it makes no sense to build and ship them PTXdist can handle the following project variations one hardware platform one userland configuration common case one hardware platform various userland configurations various hardware platforms one userland configuration common case various hardware platforms one userland configuration various collections various hardware platforms various userland configuration various hardware platforms various userland configuration various collections 3 1 2 PTXdist s build process When PTXdist is building one part we call it a package of the whole project it is divided into up to six stages get The package will be obtained from its source downloaded from the web for example extract The package archive gets extracted and patched if a patch set for this package exists prepare Many packages can be configured in various ways If supported this stage does the configuration ina way defined in the menu project specific compile The package gets built install The package installs itself into a project local directory This step is important at least for libraries other packages may depend on targetinstall Relevant parts of the package will be used to
72. oolchain vendor requires an additional step Open the OSELAS BoardSupport Package menu with ptxdist platformconfig and navigate to architecture gt toolchain and check for specific toolchain vendor Clear this entry to disable the toolchain vendor check Preconditions an external toolchain must meet e it shall be built with the configure option with sysroot pointing to its own C libraries e it should not support the multilib feature as this may confuse PTXdist which libraries are to select for the root filesystem If we want to check if our toolchain was built with the with sysroot option we just run this simple command mytoolchain gcc v 2 gt 81 grep with sysroot If this command does not output anything this toolchain was not built with the with sysroot option and cannot be used with PTXdist 2 3 2 Building a Toolchain PTXdist handles toolchain building as a simple project like all other projects too So we can download the OSELAS Toolchain bundle and build the required toolchain for the OSELAS BoardSupport Package A PTXdist project generally allows to build into some project defined directory all OSELAS Toolchain projects that come with PTXdist are configured to use the standard installation paths mentioned below All OSELAS Toolchain projects install their result into opt OSELAS Toolchain 1 99 3 Usually the opt directory is not world writeable So in order to build our OSELAS Toolchain into
73. pecific data for the target klibc type This kind of package is built against klibc to be part of an initramfs for the target src autoconf prog This kind of package is built for the target Itis intended for development as it does not handle a released archive but a plain source project instead Creating such a package will also on demand create a small autotools based source template project to give the developer an easy point to start This template is prepared to build a single executable program src autoconf lib This kind of package is built for the target It is intended for development as it does not handle a released archive but a plain source project instead Creating such a package will also on demand create a small autotools libtool based source template project to give the developer an easy point to start This template is prepared to build a single shared library src autoconf proglib This kind of package is built for the target It is intended for development as it does not handle a released archive but a plain source project instead Creating such a package will also on demand create a small autotools libtool based template project to give the developer an easy point to start This template is prepared to build a single shared library and a single executable program The program will be linked against the shared library simple This kind of package is intended to add a few simple files into the build process We assume these
74. race shows all the system calls that the binary or its shared libraries are performing strace is one of the target debugging tools which PTXdist provides in its Debug Tools menu After adding strace to the root filesystem we can use it and observe our foo binary strace usr bin foo execve usr bin foo usr bin foo x 41 vars 0 brk 0 0x8e4b000 access etc 1d so preload R_OK 1 ENOENT No such file or directory open etc 1d so cache O_RDONLY 3 fstat64 3 st_mode S_IFREG 0644 st_size 77488 0 mmap2 NULL 77488 PROT_READ MAP_PRIVATE 3 0 0xb7f87000 close 3 open 1ib 1ib libm 2 5 1 so O_RDONLY 3 read 3 177ELF 1 1 1 O O O O O O O O O 3 O 3 O 1 O O 0p O 000 512 512 mmap2 NULL 4096 PROT_READ PROT_WRITE MAP_PRIVATE MAP_ANONYMOUS 1 0 Oxb7f86000 fstat64 3 st_mode S_IFREG 0555 st_size 48272 mmap2 NULL 124824 PROT_READ PROT_EXEC MAP_PRIVATE MAP_DENYWRITE 3 0 Qxb7f67000 mmap2 0xb7f72000 4096 PROT_READ PROT_WRITE MAP_PRIVATE MAP_FIXED MAP_DENYWRITE 3 xb 0xb7f72000 mmap2 0xb7f73000 75672 PROT_READ PROT_WRITE MAP_PRIVATE MAP_FIXED MAP_ANONYMOUS 1 0 0xb7f73000 close 3 0 open 1lib libc so 6 O_RDONLY z3 read 3 177ELF 1 1 1 O O O O O O O O O 3 O 3 O 1 O O O 332X 1 512 512 fstat64 3 st_mode S_IFREG 0755 st_size 1405859 0 ea Occasionally the output of strace can be
75. rget the targetinstall stage is the correct one For the target we cannot use any simple native copy command we must create an ipkg package instead Uncomment all macro calls here and call the install_copy macro for each file to be installed on the target root filesystem Note There is no restriction where the files are come from to insert them into target s root filesystem We can give any source path and filename If we are using a special directory not already existing on target s root filesystem we must also create it Refer section 5 1 for further details about helpful variables PTXdist provides for the install stage and section 5 2 for further details about IPKG related macros to be used in the targetinstall stage 6 8 3 Adapting the Menu File Refer the section 4 2 1 on howto add more menuentries if required and how to locate this new menu in PTXdist s menu hierarchy frengutronix 63 Pengutronix 7 Document Revisions f Pengutronix 2010 01 08 2010 01 11 2010 01 11 2010 01 20 2010 01 21 2010 04 15 2010 04 16 Initial Revision Section Adding simple Files to the Build Process added Section Variables reference added Section Debugging with CPU emulation added Section PTXdist parameter reference added Section Adding new Packages extended Section Using Existing Toolchains extended x 64 8 Getting help Below is a list of locations where you can get help in case of trouble For questio
76. ript is finished successfully we can now run make All program parts are being compiled and if there are no errors we can now install PTXdist into it s final location In order to write to usr local this step has to be performed as user root 10 f Pengutronix 2 Getting a working Environment sudo make install enter password eel If we don t have root access to the machine it is also possible to install PTXdist into some other directory with the prefix option We need to take care that the bin directory below the new installation dir is added to our PATH environment variable for example by exporting it in bashrc The installation is now done so the temporary folder may now be removed S El cl a rm fr local 2 2 4 Configuring PTXdist When using PTXdist for the first time some setup properties have to be configured Two settings are the most important ones Where to store the source packages and ifa proxy must be used to gain access to the world wide web Run PTXdist s setup ptxdist setup Due to PTXdist is working with sources only it needs various source archives from the world wide web If these archives are not present on our host PTXdist starts the wget command to download them on demand Proxy Setup To do so an internet access is required If this access is managed by a proxy wget command must be adviced to use it PTXdist can be configured to advice the wget command automatically
77. ript when it runs in the prepare stage To do so we must again open the rule file with our favourite editor and navigate to the prepare stage entry PTXdist uses the variable FOO_AUTOCONF as the list of parameters to be given to configure Currently this variable is defined to FOO_AUTOCONF CROSS_AUTOCONF_USR The variable CROSS_AUTOCONF _USR is predefined by PTXdist and contains all basic parameters to instruct configure to prepare for a cross compile environment To use the two additional mentioned configure parameters we supplement this expression as follows FOO_AUTOCONF CROSS_AUTOCONF_USR enable debug with bar 36 f Pengutronix 4 PTXdist Developer s Manual Note We recommend to use this format with each parameter on a line of its own That is easier to read anda diff shows more exactly any change To do a fast check if this addition was successful we run ptxdist print FOO_AUTOCONF prefix usr sysconfdir etc host i586 unknown linux gnu build i686 host linux gnu enable debug with bar Or re build the package with the new settings ptxdist drop foo prepare ptxdist targetinstall foo Adding Dynamic Configure Parameters Sometimes it makes sense to add this kind of parameters on demand only especially a parameter like enable debug To let the user decide if this parameter is to be used or not we must add a menu entry So let s expand our menu Here is its current content
78. root ext2 root files inside an ext2 filesystem root squashfs root files inside a squashfs filesystem e root tgz root files inside a plain gzip compressed tar ball All these files can be found in platform versatilepb images 3 2 8 Running all Parts in an emulated Environment QEMU The OSELAS BSP Pengutronix Generic 2010 01 0 is prepared to give every user a chance to run the results ofthe previous steps even in the absense of real hardware All we need is a working QEMU on our development host Simply run configs arm qemu 3 run This will start QEMU in full system emulation mode and runs the previously built kernel which then uses the generated disk image to bring up a full Linux based system The running system uses a serial device for its communication QEMU forwards this emulated device to the current development host console So we can watch the starting kernel s output and log in on this system Note Log in as user root with no password just enter Leaving this emulated environment happens by entering the key sequence CTRL A X 3 3 Adapting the OSELAS BSP Pengutronix Generic 2010 01 0 Project Handling a fully prepared PTXdist project is easy But everything is fixed to the settings the developer selected We now want to adapt the OSELAS BSP Pengutronix Generic 2010 01 0 project in a few simple settings 22 f Pengutronix 3 PTXdist User s Manual 3 3 1 Working with Kconfig Whenever we modify our projec
79. rsive make 2 Entering directory home jbe my_new_prj build target foo 1 1 0 make 3 Entering directory home jbe my_new_prj build target foo 1 1 0 make 3 Leaving directory home jbe my_new_prj build target foo 1 1 0 make 2 Leaving directory home jbe my_new_prj build target foo 1 1 0 make 1 Leaving directory home jbe my_new_prj build target foo 1 1 0 finished target foo compile At this stage things can fail e The build system is not cross compile aware it tries to execute just created target binaries for example e The package depends on external components libraries for example not detected by configure e Sources are ignoring the endianess of some architectures or using header files from the build host system from usr include for example e The linker uses libraries from the build host system from usr lib for example by accident In all of these cases we must patch the sources to make them work Refer to section 4 2 4 on how to use PTXdist s features to simplify this task In this example we expect the best case Everything went fine even for cross compiling So we can continue with the next stage install ptxdist install foo f Pengutronix 3 4 PTXdist Developer s Manual make 1 Entering directory home jbe my_new_prj build target foo 1 1 0 make 2 Entering directory home jbe my_new_prj build target foo 1 1 0 make 3 Entering directory home jbe my_new_prj
80. s These kind of microcontrollers are running without any operating systems most of the time It also creates a small firmware template to give the developer an easy point to start Rule File Creation To create such a new package we create a project local rules directory first Then we run 30 f Pengutronix 4 PTXdist Developer s Manual ptxdist newpackage lt package type gt If we omit the lt package type gt PTXdist will list all available package types In our first example we want to add a new target type archive package When running the ptxdist newpackage target command PTXdist asks a few questions about this package This information is the basic data PTXdist must know about the package ptxdist creating a new target package ptxdist enter package name foo ptxdist enter version number 1 1 0 ptxdist enter URL of basedir http www foo com download src DexdilstementemesUihalxeree eer eer tar gz ptxdist enter package author My Name lt me my org com gt What we have to answer package name As this kind of package handles a source archive the correct answer here is the basename of the archive s file name If its full name is foo 1 1 0 tar gz then foo is the basename to enter here version number Most source archives are using a release or version number in their file name If its full name is foo 1 1 0 tar gz then 1 1 0 is the version number to enter here UR
81. s is a way to start a fresh build cycle clean root This action will only clean the root filesystem directories All the build directories are left untouched Using this action will regenerate all ipkg packets from the already built packages and also the root filesystem directories in the next go action The clean root and go action is usefull ifthe targetinstall stage for all packages should run again distclean The distclean action will remove all files that are not part of the main project It removes all generated files and directories like the clean action and also the created links in any platform and or select action project to lt target dir gt 52 f Pengutronix 6 Various Aspects of Daily Work 6 1 Using an External Kernel Source Tree This application note describes how to use an external kernel source tree within a PTXdist project In this case the external kernel source tree is managed by GIT 6 1 1 Cloning the Linux Kernel Source Tree In this example we are using the officiall Linux kernel developmen tree jbe octopus git clone git git kernel org pub scm linux kernel git torvalds linux 2 6 E jbe octopus ls 1 Ea drwxr xr x 38 jbe ptx 4096 2009 03 17 10 21 myprj drwxr xr x 25 jbe ptx 4096 2009 03 17 10 42 linux 2 6 Ese 6 1 2 Configuring PTXdist To make PTXdist use of this kernel source tree we run jbe octopus ptxdist setup and navigate to Source Directories Prefix for kernel trees and
82. se files ipkg files udev Package udev 106 is installed on root and has the following files etc init d udev sbin udevtrigger etc udev udev conf etc rc d S00_udev sbin udevd sbin udevsettle Successfully terminated Adding a Package Adding a new packet or replacing an already installed one is done by ipkg install lt package name gt ipk Note the trailing ipk This extension must be given if the package file is already part of the filesystem Otherwise ipkg tries to download it from the URL configured in etc ipkg conf Removing a Package To remove the contents of a package from the running system ensure that nothing from the package is currently in use Find out the precise packet name with f Pengutronix 6 Various Aspects of Daily Work ipkg list and remove it s contents from the runtime system with ipkg remove lt package name gt Upgrading a Package To upgrade a package first remove it s current contents from the runtime system In a second step install the contents of the new ipkg package ipkg list ipkg remove lt package name gt ipkg lt package name gt ipk 6 7 Downloading Packages from the Web Sometimes it makes sense to get all required source archives at once For example prior to a shipment we want to also include all source archives to free the user from downloading it by him herself PTXdist supports this requirement by the export_src parameter
83. ss warnings syntax warnings obsolete warnings unsuppor ted Note This way also still not autotoolized package can be autotoolized We just have to add the common auto tool template files configure ac and Makefile am for example via a patch series to the package source and the autogen sh to the patch directory f Pengutronix i 5 PTXdist Reference 5 1 Variables Reference The following variables are provided by PTXdist to simplify creating rule files Every developer should use these variables in every single line in the rule file to avoid any further adaption when external paths are changed To get their content related to the current project we can simply run a ptxdist print PTXDIST_TOPDIR usr local lib ptxdist 2010 01 0 Replace the PTXDIST_TOPDIR with one of the other generic variables PTXdist provides 5 1 1 PTXDIST_TOPDIR Points always to the installation directory of PTXdist 5 1 2 PTXDIST_WORKSPACE Everything that references PTXDIST_WORKSPACE will use the active projects s folder 5 1 3 PTXDIST_SYSROOT_CROSS PTXDIST_SYSROOT_CROSS points to a directory tree all cross relevant executables libraries and header files are installed to in the current project All project s packages built for the host to create data for the tar get are searching in this directory tree for their dependencies executables header and library files Use PTXDIST_SYSROOT_CROSS bin to install executables PTXDIST_SYS
84. ssors out there like the popular ARM7TDMI based SoCs which can be programmed the good old non operating system way with reasonable effort it in fact is becoming more and more difficult On the other hand legacy I O interfaces like RS232 are in creasingly often replaced by modern plug and play aware communication channels USB FireWire IEEE1394 Ethernet amp friends are more and more directly being integrated into today s microcontroller hardware Whereas some of these interfaces can somehow be handled the old controller style way of writing software the devel oper following this way will not be able to address the security and performance issues which come up with the modern network accessible devices During the last years more and more of the small scale companies which developed little embedded operating systems have been pushed out of the market Nearly no small company is able to support all the different in terfaces communication stacks development tools and security issues out there New interfaces and variants like USB On the Go are developed faster than operating system developers can supply the software for them The result is a consolidation of the market today we see that besides niche products probably only the largest commercial embedded operating system suppliers will survive that development Only the largest commercial There is one exception when the same situation came up in the mainstream computer m
85. t PTXdist is using Kconfig to manipulate the settings Kconfig means kernel con figurator and was mainly developed to configure the Linux kernel itself But it is easy to adapt to use and so popular that more and more projects are using Kconfig for their purposes PTXdist is one of them What is Kconfig It is a user interface to select given resources in a convenient way The resources that we can select are given in simple text files It uses a powerful language in these text files to organize them in a hierarchical manner solves challenges like resource dependencies supports help and search features PTXdist uses all of these features Kconfig supports a text based user interface by using the ncurses library to manipulate the screen content and should work on nearly all host systems For example running PTXdist s menuconfig subcommand in this way ptxdist menuconfig will show the following console output Figure 3 3 Main userland configuration menu 23 Jf Pengutronx 3 PTXdist User s Manual Navigate in Kconfig menu select search To navigate through the configuration tree we are using the arrow keys Up and down navigates vertically in the menu entries Right and left navigates between Select Exit and Help in the bottom part of our visual screen To enter one ofthe menus we navigate to this entry to highlight it and press the Enter key To leave it we select Exit and press the Enter
86. t Now After building the project we find even more sub directories in our project platform versatilepb build cross Contains all packages sources compiled to run on the host and handle target architecture dependend things platform versatilepb build host Contains all packages sources compiled to run on the host and handle archi tecture independend things platform versatilepb build target Contains all package sources compiled for the target architecure platform versatilepb images Generated files for the target can be found here Kernel image and root filesystem image platform versatilepb packages Location for alle individual packages in ipk format platform versatilepb sysroot target Contains everything target architecture dependend libraries header files and so on platform versatilepb sysroot cross Contains everything that is host specific but must handle target architec ture data platform versatilepb sysroot host Contains everything that is only host specific platform versatilepb root Target s root filesystem image This directory can be mounted as an NFS root for example Note Due to only root can create device nodes and the build system must be run as anon root user there is no device node present in this image At least dev console dev null and dev zero should exist Create them as user root manually in order to use this directory as an NFS root platform versatilepb root debug Target s root filesystem image T
87. t directory path gt Removes the given directory lt directory path gt 5 2 4 install_copy Usage call install_copy lt package gt lt UID gt lt GID gt lt permission gt lt source gt lt destination gt Installs given file or directory into e the project s platform versatilepb root e the project s platform versatilepb root debug e anipkg packet in the project s platform versatilepb packages Some of the parameters have fixed meanings lt package gt Name of the IPKG the macro should work on lt UID gt User ID in a numerical value the file should use in target s root filesystem lt GID gt Group ID in a numerical value the file should use in target s root filesystem lt permission gt Permission in an octal value the file should use in target s root filesystem The remaining parameters vary with the use case The lt source gt parameter can be e a directory path that should be created in target s root filesystem In this case the lt destination gt must be omitted The given path must always start with a and means the root of target s filesystem an absolute path to a file that should be copied to target s root filesystem To avoid fixed pathes all pack ages are providing the lt package gt _DIR variable So this parameter in our foo example package can be a FOO_DIR foo a minus sign PTXdist uses the lt destination gt parameter in this case to locate the file to copy from This o
88. t s root filesystem 5 3 2 Skipping a Stage For the case that a specific stage should be skipped an empty rule must be provided STATEDIR package lt stage_to_skip gt call targetinfo call touch Replace the lt stage_to_skip gt by get extract prepare compile install or targetinstall 50 f Pengutronix 5 PTXdist Reference 5 4 PTXdist parameter reference PTXdist is a command line tool which is basicly called as ptxdist lt action args gt options 5 4 1 Setup and Project Actions menu This will start a menu frontend to control some of PTXdist s features in a menu based convenient way This menu handles the actions menuconfig platformconfig Rernel config select platform boardsetup setup go and images select lt config gt This action will select a userland configuration This step is only required in projects where no selected_ptxconfig file is present The lt config gt argument must point to a valid userland configuration file PTXdist provides this feature to enable the user to maintain more than one userland configuration in the same project platform lt config gt This action will select a platform configuration This step is only required in projects where no selected_platform file is present The lt config gt argument must point to a valid platform configuration file PTXdist provides this feature to enable the user to maintain more than one platform in one project setup
89. t thing to be done now is to configure the packet configure This will check your system for required components PTXdist relies on If all required components are found the output ends with Eee checking whether usr bin patch will work yes configure creating config status config status creating Makefile config status creating scripts ptxdist_version sh config status creating rules ptxdist version in ptxdist version 2010 04 configured Using usr local for installation prefix Report bugs to ptxdist pengutronix de Without further arguments PTXdist is configured to be installed into usr local which is the standard location for user installed programs To change the installation path to anything non standard we use the prefix ar gument to the configure script The help option offers more information about what else can be changed for the installation process The installation paths are configured in a way that several PTXdist versions can be installed in parallel So if an old version of PTXdist is already installed there is no need to remove it One of the most important tasks for the configure script is to find out if all the programs PTXdist depends on are already present on the development host The script will stop with an error message in case something is missing If this happens the missing tools have to be installed from the distribution befor re running the configure script When the configure sc
90. target Building a library for the target If this library needs other resources to be built other libraries its configure finds the right information in this path 5 1 7 HOST_PATH Used to find host tools This path must be used to create anything that not depends on the architecture 5 1 8 ROOTDIR ROOTDIR points to the root of the target s root filesystem in the current project Used in very rare cases to create strange packages based on data in target s root filesystem for example 5 2 Rule File Macro Reference Rules files in PTXdist are using macros to get things work Its highly recommended to use these macros instead to do something by ourself Using the macros is portable and such easier to maintain in the case a project should be upgraded to a more recent PTXdist version This chapter describes the predefined macros in PTXdist and their usage Note This list is not complete yet 5 2 1 targetinfo Usage call targetinfo Gives a feedback what build stage is just started Thats why it should always be the first call for each stage For the package foo and the compile stage it will output f Pengutronix 45 5 PTXdist Reference 5 2 2 touch Usage call touch Gives a feedback what build stage is just finished Thats why it should always be the last call for each stage For the package foo and the compile stage it will output finished target foo compile 5 2 3 Clean Usage call clean l
91. that directory we need to use a root account to change the permissions PTXdist detects this case and asks if we want to run sudo to do the job for us Alternatively we can enter mkdir opt OSELAS Toolchain 1 99 3 chown lt username gt opt OSELAS Toolchain 1 99 3 chmod atrwx opt OSELAS Toolchain 1 99 3 We recommend to keep this installation path as PTXdist expects the toolchains at opt Whenever we go to select a platform in a project PTXdist tries to find the right toolchain from data read from the platform configuration settings and a toolchain at opt that matches to these settings But that s for our convenience only If we decide to install the toolchains at a different location we still can use the toolchain parameter to define the toolchain to be used on a per project base PPengutronix 13 Pengutronix 2 Getting a working Environment 2 3 3 Building the OSELAS Toolchain for OSELAS BSP Pengutronix Generic 2010 01 0 To compile and install an OSELAS Toolchain we have to extract the OSELAS Toolchain archive change into the new folder configure the compiler in question and start the build The required compiler to build the OSELAS BSP Pengutronix Generic 2010 01 0 board support package is arm v4t linux gnueabi_gcc 4 3 2_glibc 2 8_binutils 2 18_kernel 2 6 27 sanitized So the steps to build this toolchain are In order to build any of the OSELAS Toolchains the host must provide the tool fakeroot Other wise the messag
92. the PTXdist 1 feeling use the following rules e Omit the platform name e g keep this menu entry empty when running pxtdist platformconfig e Open the selected_platformconfig file with an editor and search for SYSROOT_TARGET SYSROOT_HOST and SYSROOT_CROSS Replace their default settings with For SYSROOT_TARGET PTXDIST_WORKSPACE local PTXCONF_ARCH_STRING For SYSROOT_HOST PTXDIST_WORKSPACE local host For SYSROOT_CROSS PTXDIST_WORKSPACE local cross With these settings you get the same directory structure in a ptxdist 2 project as in ptxdist 1 6 6 Software Installation and Upgrade Root filesystems for Linux are usually built as a flash image and pushed into the respective root medium How ever when working with Embedded Linux systems developers often have the need to e install new packages e remove packages e update packages e add configuration Installation of new packages may for example happen if a developer works on a new piece of application code or if a new library is being written for the embedded system Package updating may be a requirement even during the system s life cycle for example for updating a customer application in the field Conventional Linux distributions like Debian SuSE or Fedora use package systems like RPM or DEB to organize their software packages Unfortunately these methods require huge packet databases in the root system which is bad for space constrained embedded systems So what we
93. torys that contains a PTXdist based project Otherwise PTXdist gets confused and con fuses the user with funny error messages To show the usage of some listed major subcommands we are using a generic PTXdist based project 3 2 1 Extracting the Board Support Package In order to work with a PTXdist based project we have to extract the archive first tar zxf OSELAS BSP Pengutronix Generic 2010 01 0 tar gz cd OSELAS BSP Pengutronix Generic 2010 01 0 PTXdist is project centric so now after changing into the new directory we have access to all valid components total 32 rw r r 1 jb users 252 Jan 5 18 18 ChangeLog rw r r 1 jb users 741 Jan 5 18 18 README drwxr xr x 5 jb users 4096 Jan 5 18 15 configs drwxr xr x 3 jb users 4096 Jan 18 15 documentation drwxr xr x 4 jb users 4096 Jan 18 15 patches drwxr xr x 5 jb users 4096 Jan 18 15 projectroot drwxr xr x 3 jb users 4096 Jan 18 15 protocols drwxr xr x 3 jb users 4096 Jan 18 15 rules aaa a wo fPengutronn 19 Pengutronix 3 PTXdist User s Manual Notes about some ofthe files and directories listed above ChangeLog Here you can read what has changed in this release Note This file does not always exist documentation If this BSP is one of our OSELAS BSPs this directory contains the Quickstart you are currenly reading in configs A multiplatform BSP contains configurations for more than one target This directory contains the re spective platform configur
94. ts in our project configuration because this has no effect on the build order f Pengutronix bi 4 PTXdist Developer s Manual Managing Non Autotool Packages Many packages are still coming with a plain Makefile The user has to adapt it to make it work in a cross compile environment as well PTXdist can also handle this kind of packages We only have to specifiy a special prepare and compile stage Such packages often have no special need for any kind of preparation We can omit this stage by defining this empty rule STATEDIR foo prepare call targetinfo call touch To compile the package we can use make s feature to overwrite variables used in the Makefile With this feature we can still use the original Makefile but with our own cross compile settings Most of the time the generic compile rule can be used only a few settings are required make will be called in this case with cd FOO_DIR 88 FOO_MAKE_ENV MAKE FOO_MAKE_OPT So in the rule file only the two variables FOO_MAKE_ENV and FOO_MAKE_OPT must be set to forward the re quired settings to the package s buildsystem If the package cannot be built in parallel we can also add the FOO_MAKE_PAR NO YES is the default Note FOO is still the name of our example package It must be replaced by the real package name 4 2 4 Patching Packages There can be various reasons why a package must be patched e Package is broken for cross compile e
95. uired symbols and their values are saved to the selected_platform file Repeat the same step with my_bsp ptxdist force menuconfig In this case all for userland configuration unused symbols are discarded from the original ptxconfig file settings and the remaining are saved to the selected_ptxconfig file Check carefully if everything is set up correctly Now you have successfully separated platform and userland configuration This is the main configuration ptxdist 2 uses in a single platform project 6 5 2 Adaption of Rules Files A few adaptions in the project local rules files are required to also migrate them to the new PTXdist infrastructure Variables The names of a few variables have changed e PTXCONF_HOST_PREFIX must be replaced by PTXCONF_SYSROOT_HOST e PTXCONF_ARCH must be replaced by PTXCONF_ARCH_STRING e IMAGEDIR must be replaced by PKGDIR Local Source Handling To retain the old behaviour of ptxdist 1 in handling local sources simply keep the lt packetname gt _SOURCE vari able empty in the corresponding local source rule file At least if you are using Busybox as your shell environment you must check carefully if all settings in the previous Busybox version are still present Each version of Busybox changes various used symbolnames so it could happen that some settings are lost during the transition 8 f Pengutronix 3 6 Various Aspects of Daily Work 6 5 3 PTXdist 1 Look and Feel To keep

Download Pdf Manuals

Related Search

Related Contents

Instruction guide Likorall 242/243/250 - www.liko.com - Hill-Rom  the Tecnai F20 User Manual - LE  aat3123/23a/24 data sheet - Skyworks Solutions, Inc.    

Copyright © All rights reserved. Failed to retrieve file