From f55d8dff351fa8d08e9acc2d5688380b0864d77e Mon Sep 17 00:00:00 2001 From: Peter Korsgaard Date: Sat, 15 Jan 2011 13:01:25 +0100 Subject: [PATCH] docs: remove outdated files Misleading/outdated docs is worse than no documentation. Signed-off-by: Peter Korsgaard --- TODO | 17 --- docs/README | 4 +- docs/README.diskimage | 37 ------ docs/TESTING.html | 67 ----------- docs/U-boot.html | 254 ------------------------------------------ docs/patches.html | 43 ------- scripts/mkpkg | 109 ------------------ 7 files changed, 1 insertion(+), 530 deletions(-) delete mode 100644 TODO delete mode 100644 docs/README.diskimage delete mode 100644 docs/TESTING.html delete mode 100644 docs/U-boot.html delete mode 100644 docs/patches.html delete mode 100755 scripts/mkpkg diff --git a/TODO b/TODO deleted file mode 100644 index bf98fea1b0..0000000000 --- a/TODO +++ /dev/null @@ -1,17 +0,0 @@ -Buildroot2 TODOs - -- fix packages/Makefile.autotools.in to use a package-imposed patchdir - (Ivan Kuten) -- convert all packages that use autoconf to use the infrastructure of - packages/Makefile.autotools.in -- fix setting of flags for packages - -- coreutils: use make install-strip to install the packages. For now, - it fails beause even if we pass STRIP="/path/to/$(ARCH)-strip", the - coreutils build system uses the host strip to strip target - binaries. The ./configure execution done by Buildroot properly - detects the cross-strip, but when running make, build-aux/missing - gets run, complains about aclocal-1.10c and atuomake-1.10c not being - present, and rerun the configuration... with the wrong environment - variables (STRIP= is missing). An autoreconf on this package is - probably necessary. diff --git a/docs/README b/docs/README index e756329b59..974adeb56e 100644 --- a/docs/README +++ b/docs/README @@ -4,15 +4,13 @@ To build and use the buildroot stuff, do the following: 2) select the packages you wish to compile 3) run 'make' 4) wait while it compiles -5) Use your shiny new root filesystem. Depending on which sortof +5) Use your shiny new root filesystem. Depending on which sort of root filesystem you selected, you may want to loop mount it, chroot into it, nfs mount it on your target device, burn it to flash, or whatever is appropriate for your target system. You do not need to be root to build or run buildroot. Have fun! - -Erik - Offline build: ============== diff --git a/docs/README.diskimage b/docs/README.diskimage deleted file mode 100644 index 67a0aad4f0..0000000000 --- a/docs/README.diskimage +++ /dev/null @@ -1,37 +0,0 @@ -# Sample for i386 to create a 6MB disk-image - -# create an image file -dd if=/dev/zero bs=512 count=$((6*1024*1024/512)) of=img -# create a partition (optional) -echo -e "n\np\n1\n\nw\n" | \ - ~/src/busybox/busybox fdisk -C 16065 -H 255 -S 63 ./img -# as root, associate the image with a look-device: -# The offset of 512 comes from the the layout of the image. See -# ~/src/busybox/busybox fdisk -C 16065 -H 255 -S 63 -l ./img for the start -# block and multiply this with the block size (==512). -~/src/busybox/busybox losetup -o 512 /dev/loop/0 /path/to/the/img -# create some filesystem on it, for example ext2 -mkfs.ext2 -m0 -Lslash /dev/loop/0 -# mount it and copy your stuff to it -~/src/busybox/busybox mount -oloop,rw /dev/loop/0 /media/l0 -~/src/busybox/busybox mkdir -p /media/l0/boot/grub -~/src/busybox/busybox cp -a project_build_i386/root/boot/grub/stage? /media/l0/boot/grub/ -~/src/busybox/busybox cp -a project_build_i386/root/boot/bzImage /media/l0/boot/ -~/src/busybox/busybox cat > /media/l0/boot/grub/menu.lst < - -

Testing Buildroot for an Architecture

- -

-

scripts/mkpkg script

-If you want to test the build of a single package you can use the mkpkg script. -

-

-

  • $ scripts/mkpkg PACKAGE
    • -

    -

    -Will make the board, and save the result in a log file. -The log file resides in -

  • $ log/OK/PACKAGE.log.OK
    • -

    -

    -if the build succeeds and in -

  • $ log/OK/PACKAGE.log.FAIL
    • -

    -

    -if it cannot complete. -

    - -

    -By creating an alias -

  • alias mk=scripts/mkpkg
    • -

    -

    -it is enough to type -

  • $ mk PACKAGE
    • -

    -

    -mkpkg will only print out the

    {PACKAGE}......OK

    or

    {PACKAGE}......FAIL

    -depending on success or failure making it easy to get an overview -of the status of this specific architecture. -

    -

    -It is recommended to build a simple board before running the test -to get some basic things done. -

    -

    -

    scripts/buildall.sh script

    -

    -

    -By running this script you will run scripts/mkpkg on -a lot of the packages available in Buildroot. -

    -

    -You need to run the script while in the TOP directory. -I.E: Where you typically run make. -

    -

    -There are a few lacking, for no very good reason, -but these can be easily added. -

    -

    -Note that some packages will not build properly -if you do not enable them using makeconfig. -

    -

    -Examples are: -

  • freetype
    • -
  • socat
    • -

    - - diff --git a/docs/U-boot.html b/docs/U-boot.html deleted file mode 100644 index 7d78e00a5e..0000000000 --- a/docs/U-boot.html +++ /dev/null @@ -1,254 +0,0 @@ - - - - - - Buildroot - U-boot extensions in 2009.01-rc1 - - - - - -
    -
    - -

    U-boot extensions in 2009.01-rc1

    -
    - -

    U-Boot - usage and documentation by Ulf Samuelsson. -

    - - -

    About U-boot

    - [TOP] - -

    - U-Boot is an open source bootloader ported to a multitude of processors. - See (U-Boot Home) - for documentation for vanilla U-Boot. This document only describes - changes compared to the vanilla u-boot. -

    - -

    Board support for at91rm9200dk

    - [TOP] - -

    - "at91rm9200dk" is updated to use a linux like API for gpio. - A new target "at91rm9200dk_df" is defined to support boot from dataflash. -

    - -

    Board support for at91rm9200ek

    - [TOP] - -

    - The "at91rm9200ek" BSP supports booting from a parallel flash. - The "at91rm9200df" BSP supports a generic target booting from dataflash. -

    - -

    Board support for at91sam9g20ek

    - [TOP] - -

    - The "at91sam9g20ek" target with dataflash(card) and NAND boot support. -

    - -

    Minicom extensions

    - [TOP] - -

    - "sx-at91" is a reliable X-Modem application allowing download to the at91rm9200 - based board -

    -

    - "raw-at91" is a download application which will download binary data using minicom. - Typically used to download an environment script. -

    - -

    New command: factory

    - [TOP] - -

    -

    factory

    -

    - -

    - "factory" will set a selected set of environment variables - back to the compile time default. The following will give some - hints on capabilities, but is not yet complete. -

    - -

    - It will generate a set of scripts which will facilitate downloading - the kernel and root file system using tftp and will also - add commands to store into and retrieve from flash -

    - -

    New command: os

    - [TOP] - -

    -

    os

    -

    -

    - "os" computes a new name for the linux kernel -

    - -

    New command: fs

    - [TOP] - -

    -

    fs

    -

    -

    - "fs" computes a new name for the file system -

    - -

    New command: setargs

    - [TOP] -

    -

    setargs

    -

    -

    - "setargs" will create new bootcmd/bootargs combination from - kernel name, filesystem name, and rootfs type. -

    - -

    New command: led

    - [TOP] - -

    -

    led [green | yellow | red | all ] [ on | off ]

    -

    - -

    - "led" will turn on or off the specified (coloured) led -

    - -

    New command: mux

    - [TOP] - -

    -

    mux [spi | mmc ]

    -

    - -

    - "mux" will select how to use the flash card connector on the - at91rm9200dk or at91rm9200ek -

    - -

    New command: ethinit

    - [TOP] - -

    -

    ethinit

    -

    - -

    - "ethinit" can be used to delay the boot of linux, until a valid network - connection has been established. This is useful if the machine is NFS mounting - the root file system and both this machine and the NFS server are powering up - simultaneously. The NFS server could take a lot longer to boot, and waiting - for this to boot may be neccessary for proper operation. -

    - -

    Special environment variables

    - [TOP] - -

    -

    rd

    -

    -

    - rd contains the name of the current root file system - It is autmatically generated from ver and rd-1, rd-2 etc. - The "fs-date" is added at the end. -

    - -

    -

    ver

    -

    -

    - You can handle a number of different root fs by defining ver. - When running fs rd will be assigned from one of: -

      rd-1, rd2, rd-3 ...
    -

    -

    - By defining ver to a number you will - select the appropriate disk name -

    - -

    -

    fs-date

    -

    -

    - "date" part of the root file system name -

    - -

    -

    linux

    -

    -

    - linux contains the name of the current kernel. -

    -

    - It is generated from several environment variables when os is run -

    -

    - A typical name would be "at91sam9263ek-linux-2.6.28-20090105.gz" -

    - -

    -

    hostname

    -

    -

    - "name" part of the kernel file name -

    - -

    -

    kernel-version

    -

    -

    - "version" part of the kernel file name -

    - -

    -

    kernel-date

    -

    -

    - "date" part of the kernel file name -

    - -

    -

    fstype [ ram | flash ]

    -

    - You can have several file system types. - bootargs is created depending on fstype.. -

    - - [TOP] - -
    - - - - diff --git a/docs/patches.html b/docs/patches.html deleted file mode 100644 index 2d886e557e..0000000000 --- a/docs/patches.html +++ /dev/null @@ -1,43 +0,0 @@ - - -

    Buildroot patch structure

    - -

    -

    Keeping track of applied patches

    -Whenever a patch is applied to a source code directory in buildroot, a text file named .applied_patches_list is created inside that source directory. -This file contains a list of all the patch filenames that were applied to that source code, just for reference. -

    - -

    -

    Linux kernel patches

    -The Linux kernel has several patch levels available for it in the buildroot patch system. -Buildroot first downloads the chosen kernel source from the mirror site, followed by any selected minor patch. -Buildroot then extracts the kernel source from the compressed file and applies the minor patch, if one was chosen. -After extracting the source and applying the official minor patch, buildroot looks for more patches in the following locations and in the order shown: - -
      -
    1. a custom, user downloaded kernel patch can be located in $(DL_DIR) and the filename is stored as $(LINUX26_BSP_PATCH)
      2. -
    2. Atmel keeps their official kernel patches in target/device/Atmel/Linux/kernel-patches with subdirectories for each kernel release. -They also keep any board-specific patches in $(BR2_BOARD_PATH)
      3. -
    3. globally available patches are kept in toolchain/kernel-headers
      4. -
    4. IPMI (Intelligent Platform Management Interface) -kernel patches are kept in toolchain/kernel-headers/ipmi
      5. -
    5. LZMA kernel compression support patches are kept in toolchain/kernel-headers/lzma
      6. -
    6. Real-time Linux kernel patches are kept in $(LINUX_RT_SOURCE)
      7. -
    7. Openswan kernel patches are kept in package/openswan
      8. -
    -

    - -

    -

    Package source patches

    - Any patches for the Linux programs supported by buildroot are kept in that program's corresponding package/ directory. -

    - -

    -

    How the patching is done

    -Patches are applied in buildroot by running a shell script called toolchain/patch-kernel.sh with three arguments. The first argument is the target directory -where the source code to be patched is saved. The second argument is the directory where the patch is saved. The third argument is the filename pattern -to match when looking in the patch directory. The third argument can include wildcards to select multiple patch files. -

    - - diff --git a/scripts/mkpkg b/scripts/mkpkg deleted file mode 100755 index 4db0fefbc0..0000000000 --- a/scripts/mkpkg +++ /dev/null @@ -1,109 +0,0 @@ -#!/bin/bash -OK=0 -FAIL=1 -TOPDIR=`pwd` -LOG_FILE=$1.log -LOG_DIR=${TOPDIR}/log/ -LOG=${LOG_DIR}/${LOG_FILE} -DEPENDENCY=${LOG_DIR}/DEPEND/$1.depend.txt - -LOG_OK_DIR=${LOG_DIR}/OK -LOG_FAIL_DIR=${LOG_DIR}/FAIL -LOG_OK_FILE=${LOG_OK_DIR}/${LOG_FILE}.OK -LOG_FAIL_FILE=${LOG_FAIL_DIR}/${LOG_FILE}.FAIL - -mkdir -p ${LOG_DIR} -mkdir -p ${LOG_OK_DIR} -mkdir -p ${LOG_FAIL_DIR} -mkdir -p ${LOG_DIR}/DEPEND - -test=${OK} - -function clean_files() -{ - rm -f ${LOG} - rm -f ${LOG_OK_FILE} - rm -f ${LOG_FAIL_FILE} - rm -f ${DEPENDENCY} -} - -function dirclean () -{ - make $1-dirclean > /dev/null 2>&1 -} - -function process () -{ - make $1 >> ${LOG} 2>&1 || test=${FAIL} - grep "\.tar\." ${LOG} > ${DEPENDENCY} - if [ ${test} = ${OK} ] ; then - mv ${LOG} ${LOG_OK_FILE} - printf "%-16s" "OK" - if [ "${2}X" != "X" ] ; then - printf "%-16s" "\"$2\""; - fi - if [ "${3}X" != "X" ] ; then - printf "%s" "\"$3\""; - fi - echo - else - mv ${LOG} ${LOG_FAIL_FILE} - printf "%-16s" "FAIL" - if [ "${2}X" != "X" ] ; then - printf "%-16s" "\"$2\""; - else - printf "%-16s" "\"\"" - fi - if [ "${3}X" != "X" ] ; then - printf "%s" "\"$3\""; - fi - echo - fi -} - -function build_package () -{ - # echo "BUILD PACKAGE:1=$1 2=$2 3=$3 4=$4 5=$5 6=$6 7=$7" - printf "mk %-32s" "$1" - if [ "$2X" = "X" ] ; then # no parameters - clean_files $1 - dirclean $1 - process $1 "$3" - elif [ "$2X" = "?X" ] ; then # no parameters - clean_files $1 - dirclean $1 - process $1 "$3" - elif [ "$2X" = "OKX" ] ; then # Previous build was OK - clean_files $1 - dirclean $1 - process $1 "$3" - elif [ "$2X" = "FAILX" ] ; then - clean_files $1 - dirclean $1 - process $1 "$3" - elif [ "$2X" = "BROKENX" ] ; then - printf "%-16s" "BROKEN" - if [ "${3}X" != "X" ] ; then - printf "%s" "\"$3\""; - fi - echo - elif [ "$2X" = "DISABLEDX" ] ; then - printf "%-16s" "DISABLED" - if [ "${3}X" != "X" ] ; then - printf "%s" "\"$3\""; - fi - echo - else - printf "%-16s" "?BROKEN" - if [ "${3}X" != "X" ] ; then - printf "%s" "\"$3\""; - fi - echo - fi -} - -#build_package $1 $2 "\"$3\"" -build_package $1 $2 "$3" - - - -- 2.30.2